Software Engineering

Difference between verification and validation

Software inspection process

An inspection is a formal peer review in which a team examines a software artefact (requirements, design, code) to find defects without executing it. It can find many errors in one pass, and errors do not hide other errors as they do in testing.

Roles: author, moderator (leader), reader, recorder, and inspectors (reviewers).

Steps

1. Planning: moderator selects the team, schedules the meeting, and ensures entry criteria (the product is complete and compiles).
2. Overview: author explains the purpose and background of the product.
3. Individual preparation: each inspector studies the material using a checklist of common errors (uninitialised variables, loop bounds, interface mismatches, etc.).
4. Inspection meeting: the reader paraphrases the material; inspectors raise defects; the recorder logs them. No solutions are discussed and meetings are kept to about two hours.
5. Rework: author fixes the defects found.
6. Follow-up: moderator verifies that all defects are fixed, or decides on re-inspection.

Output is an inspection report listing defects by severity, used also for process improvement.

Difference between verification and validation

Software inspection process

An inspection is a formal, structured peer review of a software artefact (requirements, design or code) by a small team, aimed at finding defects before testing. Because it is static, many defects can be found in one session, and errors do not mask each other.

Roles: author, moderator, reader, recorder and inspectors.

Process

1. Planning: moderator checks entry criteria, selects the team and schedules the meeting.
2. Overview: author briefs the team about the artefact.
3. Individual preparation: inspectors study the artefact using a checklist of common faults.
4. Inspection meeting: the reader walks through the artefact, defects are raised and logged by the recorder; no fixes are discussed; the meeting lasts at most about two hours.
5. Rework: author corrects the defects.
6. Follow-up: moderator verifies fixes and decides if re-inspection is needed; defect data is used for process improvement.

System modeling is the process of developing abstract models of a system, each presenting a different view or perspective of it. Models are usually expressed in a graphical notation such as UML. They help analysts understand the functionality of the system, communicate with customers, and document the requirements before implementation. Models can be built for an existing system (to clarify what it does) or for a new system (to explain proposed requirements and design).

Perspectives and models

1. Context (external) model: shows the system boundary and its environment, i.e. other systems and users it interacts with.
2. Interaction model: shows interaction between the user and the system, or between components. Use case diagrams and sequence diagrams are used.
3. Structural model: shows the organisation of the system or the structure of data: class diagrams, object diagrams.
4. Behavioural model: shows the dynamic behaviour. Data-flow diagrams model data-driven processing; state machine diagrams model event-driven behaviour.

Example: library management system

• Context model: the library system interacts with the Member, the Librarian and an external Payment system.
• Use case model: use cases are "Search book", "Issue book", "Return book" and "Pay fine", with the Member and Librarian as actors.
• Sequence model for "Issue book": Librarian enters member id; system checks membership; system checks book availability; system records issue and due date; confirmation is returned.
• Class model: classes Member, Book, Loan and Librarian, where a Member has zero or more Loans and each Loan refers to one Book.
• State model: a Book has states Available, Issued and Reserved, with transitions "issue", "return" and "reserve".

System models give a shared understanding, reveal missing or inconsistent requirements early, and serve as a basis for design.

Software process model

A software process model is a simplified, abstract description of a software development process. It defines the activities (specification, design, implementation, validation, evolution), their order and the way they are related. Examples are waterfall, incremental, spiral, prototyping and agile models.

Waterfall model

The waterfall (classic life-cycle) model is a linear, sequential model in which each phase must be completed before the next begins, and the output of one phase becomes the input of the next:

1. Requirements analysis and definition: gather and document the system's services, constraints and goals.
2. System and software design: define the overall architecture and detailed design.
3. Implementation and unit testing: write code in units and test each unit.
4. Integration and system testing: integrate units and test the whole system against requirements.
5. Operation and maintenance: install the system, fix errors and improve it.

Each phase ends with approved documents (sign-off), and there is limited feedback to earlier phases.

Merits

• Simple, easy to understand and manage.
• Phases are well defined, with clear milestones and deliverables.
• Good documentation produced at every phase.
• Works well for small projects with stable, well-understood requirements.
• Easy to plan, schedule and monitor progress.

Demerits

• Inflexible: changing requirements after the process has started is difficult and costly.
• Customers see a working product only late in the cycle.
• Errors in requirements or design are discovered late, in testing, when they are expensive to fix.
• High risk and uncertainty; not suited to large, complex or long projects.
• Little feedback or customer involvement between phases.

Risk is an uncertain event or condition that, if it occurs, has a negative effect on the project, product or business. Risk management is the process of identifying, analysing, planning for and monitoring risks.

Types of risks in software projects

1. Project risks affect the schedule or resources, for example staff turnover, loss of an experienced developer, management change, unrealistic deadlines, budget cuts.
2. Product (technical) risks affect quality or performance of the software, for example failure of a purchased component to perform as expected, defects in reused code, underestimated size, performance problems, difficult technology.
3. Business risks affect the organisation developing or buying the software, for example a competitor introducing a better product first, change in market or customer priorities, loss of funding.

By the source, risks are also grouped as technology, people, organisational, tools, requirements (changes in requirements) and estimation risks.

Risk analysis stage (risk management process)

The risk management process has four stages: risk identification, risk analysis, risk planning and risk monitoring.

In risk analysis, each identified risk is assessed to judge:

• Probability (likelihood) that it will occur, usually rated very low, low, moderate, high or very high.
• Consequences / impact if it occurs: catastrophic, serious, tolerable or insignificant.

The two are combined (risk exposure = probability x impact) to rank the risks, so that management concentrates on those that are most serious. The analysis is largely judgement based on the project manager's experience, and a table of risks with probability and effect is produced. Typical high-priority risks continue to the planning stage, where avoidance, minimisation or contingency strategies are prepared, while minor risks are monitored.

Software requirements describe what the system should do and the constraints under which it operates. They are classified as follows.

1. Functional requirements

Statements of the services the system should provide, how it should react to particular inputs and how it should behave in particular situations. They describe functionality in terms of inputs, processing and outputs.

Examples (online library): the system shall allow a member to search books by title or author; the system shall let the librarian issue and return books; the system shall calculate fines for late returns.

2. Non-functional requirements

Constraints on the services or functions offered by the system, which concern how well it works and the quality attributes rather than specific features. They apply to the system as a whole and often matter more than individual functions. Categories are:

• Product requirements: performance, reliability, usability, security, portability, efficiency.
• Organisational requirements: standards, development process, delivery, implementation constraints.
• External requirements: legal, ethical, interoperability.

Examples: a search must return results within 2 seconds; the system shall be available 99.9 percent of the time; passwords must be stored encrypted.

3. Domain requirements

Requirements that come from the application domain of the system rather than from the users' needs, reflecting characteristics and constraints of that domain. They may be functional or non-functional, and are often expressed in domain terminology that developers may not understand, so missing them can make the system unusable.

Examples: a library system must follow the national copyright and cataloguing standards (e.g. MARC); a train protection system must compute braking distance using the specified deceleration formulas; a banking system must comply with the central bank's rules on transactions.

Rapid prototyping is the quick construction of a working model of (part of) a system early in the process, so that users and developers can experiment with it, clarify requirements and find design problems before the full system is built. The aim is to produce the prototype in a very short time and at low cost, so it must use techniques and tools that are faster than normal development. The prototype is often thrown away or evolved into the final system.

Rapid prototyping techniques

1. Dynamic high-level languages: languages such as Python, Smalltalk, Lisp or Prolog offer powerful built-in data types, dynamic typing, garbage collection and interactive execution, so a program is written and changed in far fewer lines and little time. Their run-time efficiency is poor, which does not matter for a prototype.
2. Database programming: a database language (SQL, 4GL, report and form generators, spreadsheets) includes data management, query, form and report facilities. Business systems can be prototyped by defining tables, screens and reports instead of coding algorithms.
3. Component and application assembly (reuse): the prototype is built by plugging together existing components, COTS packages, libraries or application skeletons, with glue code between them. Only the missing parts are written, which saves much time.
4. Visual (GUI) programming and screen painters: user-interface builders let the developer draw windows, menus and forms and attach simple behaviour. Because most user concerns are about the interface, this gives a quick, demonstrable model. Paper prototypes and wireframes are an even cheaper version.
5. Throw-away (exploratory) prototyping: a quick-and-dirty model is built to understand unclear requirements and is discarded; the real system is then engineered properly.
6. Evolutionary prototyping: the first prototype is built on a well-understood part of the requirements and is refined repeatedly with user feedback until it becomes the final system.
7. Incremental prototyping: the system is split into independent parts, each prototyped separately and finally merged into the whole.

Advantages: reduces requirement risk, gives early user feedback and training, and finds missing functions early. Limitations: the prototype may lack performance, security or documentation, and users may press to deliver it as the final product.

Formal specification is the expression of the system requirements or design in a language with a precisely defined syntax and mathematical semantics (for example Z, B, VDM, algebraic specification). Because it is based on sets, logic and functions, it removes the ambiguity of natural language, can be analysed for consistency and completeness, and allows the implementation to be proved correct against it. It is especially used for safety-critical and security-critical systems, and it is the basis of cleanroom development.

Advantages: finds errors and omissions early, forces a precise understanding, reduces later testing effort and supports verification. Disadvantages: needs mathematical skill, is hard for customers to read, and is costly for large user-interface-heavy systems.

Interface specification

Large systems are decomposed into subsystems whose interfaces must be agreed before the subsystems are developed independently. An interface specification defines the services each subsystem or component offers, and it hides the internal implementation. A formal interface specification is precise enough that the user of the interface needs no knowledge of the code, and the implementer knows exactly what must be provided.

Interfaces are usually specified as abstract data types or objects, with:

1. Signature (syntax): the operation names, parameters and result types.
2. Behaviour (semantics): the effect of each operation, given by pre-conditions (what must be true before the call) and post-conditions (what is true after it), plus invariants for the data.

Algebraic approach (used for interface specification): the behaviour of an abstract type is defined by equations relating operations. A specification has four parts: Introduction (name, sorts, imports), Description (informal), Signature (operations with types) and Axioms (equations).

Example, a stack:

Sort Stack
imports Integer
Operations
  create : -> Stack
  push   : Stack x Integer -> Stack
  pop    : Stack -> Stack
  top    : Stack -> Integer
  empty  : Stack -> Boolean
Axioms
  empty(create) = true
  empty(push(s, i)) = false
  top(push(s, i)) = i
  pop(push(s, i)) = s

Here the operations are divided into constructors (create, push) and inspectors (top, empty), and the axioms give the value of each inspector applied to each constructor, which makes the specification complete.

Model-based form (Z/B style): the state is a set-theoretic model and each operation has a pre- and post-condition. For the same stack with state $s$ a sequence: push: post $s' = s \frown \langle x\rangle$; pop: pre $s \neq \langle\rangle$, post $s' = front(s)$.

Steps in interface specification: identify the objects and operations, specify the signatures, write pre/post-conditions or axioms, define exceptions, and then check for completeness and consistency. Interface specification also fits with interface types: procedural interfaces, data-structure interfaces and representation interfaces.

Architectural design is the early design stage that identifies the main structural components of a system and the relationships between them. The output is the architecture, a model of how the system is organised, which affects its performance, security, availability and maintainability.

Activities of the architectural design process

1. System structuring: the system is divided into principal subsystems and the communications between them are identified (usually shown with block diagrams).
2. Control modelling: a general model of the control relationships between the parts is established, e.g. centralised control (call-return, manager) or event-based control (broadcast, interrupt-driven).
3. Modular decomposition: each identified subsystem is decomposed into modules, choosing between an object-oriented or a function-oriented (data-flow) decomposition.

Other related activities are choosing an architectural style or pattern, distributing the system over machines, and evaluating the architecture against non-functional requirements.

Abstract machine (layered) model

The abstract machine model, also called the layered model, organises the system into a series of layers. Each layer provides a set of services to the layer above it and acts as an abstract machine whose implementation uses the services of the layer below. The innermost layer is closest to the hardware or the platform; the outermost layer is the user-facing application.

+--------------------------------+
|  User interface                |  layer 4
+--------------------------------+
|  Application services          |  layer 3
+--------------------------------+
|  Core / utility services       |  layer 2
+--------------------------------+
|  System support (OS, database) |  layer 1
+--------------------------------+

Examples: the OSI seven-layer network model, a version management system (configuration management on top of object management, on top of a database, on top of the OS), and the layered structure of operating systems.

Advantages

• Supports incremental development: when a layer interface changes only the adjacent layer is affected.
• A layer can be replaced by another one with the same interface, which helps portability across platforms.
• Dependencies are localised and easy to understand.

Disadvantages

• Strict layering is hard to achieve; high-level layers may need to call low-level ones directly.
• Performance suffers because a request may pass through many layers.
• Choosing the right layers is difficult.

Modular decomposition is the architectural design step in which each subsystem is broken down into smaller modules, each performing a defined part of the work. The modules are the building blocks of the design; they should be highly cohesive internally and loosely coupled to each other so that they can be developed, tested and changed independently. The decomposition also shows how the modules interact. There are two main models: the object-oriented model and the function-oriented (data-flow, pipeline) model.

Object-oriented model of decomposition

The system is decomposed into a set of loosely coupled objects, each with its own private state and a set of operations. Objects communicate by calling operations (sending messages) of other objects through their public interfaces. Instead of dividing the system by function, it is divided by the real-world entities and concepts of the problem.

Features

1. Objects encapsulate state and the operations that act on it, so the representation is hidden.
2. Objects are instances of classes, and classes can be organised with inheritance.
3. Objects are independent, so an implementation can change without affecting others.
4. Objects can be distributed and run in parallel.

Example, invoice processing system. Objects: Customer, Receipt, Invoice, Payment. Invoice has attributes (invoiceNo, date, amount, customer) and operations issue(), sendReminder(), acceptPayment(); Customer has operations createAccount(), updateDetails(). Invoice.acceptPayment() calls Payment.record() and Receipt.issue().

Customer 1 ---- * Invoice 1 ---- * Payment
                    |
                    1
                 Receipt

Advantages

• Easy maintenance and change, because objects are loosely coupled.
• Objects mirror real entities so the design is understandable.
• Objects (and classes) are reusable.

Disadvantages

• A caller must know the identity of the object it uses; changing the identity affects all callers.
• Complex entities may be difficult to represent as objects.

Function-oriented (pipeline) model, for contrast: the system is a series of functional transformations of input data to output data, as in data-flow diagrams and batch processing.

Use case diagram is a UML behavioural diagram that shows the functions (use cases) a system provides and the external users or systems (actors) that interact with them. It is one of the first models made in object-oriented development, during requirements analysis.

Importance of the use case diagram

1. Captures functional requirements from the user's point of view in a simple graphic, without implementation details.
2. Communication tool: customers, users, analysts and developers can all understand it, which helps to agree on the scope of the system.
3. Defines the system boundary and identifies the actors, showing what is inside and outside the system.
4. Basis for design and later models: classes, sequence and activity diagrams are derived from the use cases.
5. Basis for test cases and planning: each use case scenario gives test cases, and use cases help estimate effort and prioritise releases.
6. Finds missing requirements early, through relationships such as include and extend, which show common and optional behaviour.

Notations: actor (stick figure), use case (ellipse), system boundary (rectangle), association (line), <<include>> (mandatory reuse of another use case), <<extend>> (optional behaviour), and generalisation.

Use case diagram for a library system

Actors: Member, Librarian, Administrator.

+--------------------------- Library System ---------------------------+
|                                                                      |
|   (Search book) <---------- Member                                   |
|   (Reserve book) <--------- Member                                   |
|   (Issue book) <----------- Librarian                                |
|        |  <<include>>                                                |
|        v                                                             |
|   (Verify membership)                                                |
|   (Return book) <---------- Librarian                                |
|        .  <<extend>>                                                 |
|        v                                                             |
|   (Calculate fine) -- (Pay fine) <---- Member                        |
|   (Add / remove book) <---- Librarian                                |
|   (Manage members) <------- Administrator                            |
|   (Generate reports) <----- Administrator                            |
|                                                                      |
+----------------------------------------------------------------------+

• Member takes part in Search book, Reserve book, Pay fine and (via the librarian) borrowing and returning.
• Librarian handles Issue book, Return book and Add/remove book.
• Issue book includes Verify membership; Return book is extended by Calculate fine when the book is returned late.
• Administrator does Manage members and Generate reports.

Cleanroom software development is a formal, defect-prevention-oriented software process in which software is developed under statistical quality control so that it contains almost no defects when it is first delivered to testing. The name comes from the clean rooms of semiconductor manufacturing: errors are prevented by rigorous method rather than removed by repeated debugging. It was developed at IBM (Harlan Mills) and is used for high-reliability systems. The key idea is that defects are avoided by formal specification and mathematical verification, and are not tested out afterwards.

Characteristics (key strategies)

1. Formal specification: the system is specified using a state-transition model, with the behaviour defined by mathematical functions (box structure specification).
2. Incremental development: the system is divided into increments that are specified, developed and certified one by one. Each increment is about 20 KLOC or less, and is planned using an incremental schedule.
3. Structured programming: limited control constructs (sequence, selection, iteration) and stepwise refinement are used, so that programs can be verified.
4. Static verification: the developed code is inspected and verified by rigorous reviews and mathematical correctness proofs (team reviews), not by executing it. The developers do not run the code themselves.
5. Statistical testing: the integrated increment is tested by an independent team using test cases drawn from an operational profile, i.e. in proportion to expected actual usage. Failure data are used to estimate reliability (for example with MTTF).
6. Separate teams: the specification, development and certification (testing) teams are independent.

Cleanroom process teams: specification team, development team and certification team.

Advantages: very low defect rates, fewer failures in the field, lower maintenance cost, and certified reliability measures. Disadvantages: needs a high level of mathematical skill and training; developers and managers may resist not running their code; the approach is not suited to systems without a clear specification, and it is not widely used.

Path testing is a white-box (structural) testing technique in which test cases are designed so that every independent execution path through a program's control flow is exercised at least once. The program is first converted to a flow graph (nodes for statements or blocks, edges for control flow). The number of independent paths gives the minimum number of test cases required.

Steps

1. Draw the flow graph from the code.
2. Compute the cyclomatic complexity $V(G)$, which equals the number of independent paths: $V(G) = E - N + 2 = P + 1 = R$ where $E$ = edges, $N$ = nodes, $P$ = predicate (decision) nodes, $R$ = regions.
3. List a basis set of independent paths (each introduces at least one new edge).
4. Design a test case for each path with its expected output, and execute them.

Example

int largest(int a, int b, int c) {
1    int max = a;
1    if (b > max)
2        max = b;
3    if (c > max)
4        max = c;
5    return max;
}

Flow graph nodes: 1 (max = a; test b > max), 2 (max = b), 3 (test c > max), 4 (max = c), 5 (return). Edges: 1→2, 1→3, 2→3, 3→4, 3→5, 4→5, so $E = 6$, $N = 5$.

$V(G) = 6 - 5 + 2 = 3$

Check by predicates: there are 2 decisions, so $P + 1 = 3$.

Basis set of independent paths

• Path 1: 1 – 3 – 5
• Path 2: 1 – 2 – 3 – 5
• Path 3: 1 – 3 – 4 – 5

(The path 1–2–3–4–5 is not independent; it is a combination of these.)

Test cases

Merits: guarantees every statement and branch executes at least once, and gives a measure of testing effort. Limitations: it does not detect missing functions, and the number of paths explodes with loops.

(a) Reliability validation

Reliability validation is the process of checking that a system meets its specified reliability requirement, which is measured with statistical methods. It involves exercising the system and observing failures. It is part of dependability validation.

Its process has four steps:

1. Operational profile: study the existing or similar system and build a profile of how the system will be used, i.e. classes of input and their probability of occurrence.
2. Test data preparation: generate a large set of test data that follows the operational profile, so that testing is representative of real use.
3. Testing: run the system with the data and record the number and time of failures (and the classification of their severity).
4. Compute reliability: use the failure data with a reliability metric and decide whether the system is acceptable. If not, the system is corrected and tested again.

Metrics: POFOD (probability of failure on demand), ROCOF (rate of occurrence of failure), MTTF (mean time to failure) and availability. The reliability growth model predicts when the required level will be reached.

Problems: the operational profile is uncertain, high reliability requires a huge amount of testing, and statistical uncertainty applies in the measurement.

(b) Reverse engineering

Reverse engineering is the process of analysing an existing system (usually the code or the binary) to recover its design and specification, and to produce a higher-level representation of it, without changing the system. It is used when documentation is missing or lost, for maintenance of legacy systems, and as the first step of re-engineering.

Activities:

1. Study the code and the data structures (source or object code) to extract details.
2. Recover the data, process and architectural design: ER diagrams, data-flow diagrams, structure charts, class diagrams.
3. Recover requirements and specification from the design.
4. Produce documentation, such as the call graph, cross-reference and control flow listings.

Tools: disassemblers, decompilers, code analysers and visualisers, program-slicing tools. Reverse engineering is done at different abstraction levels: implementation, structure, functional and domain.

Uses: understanding legacy software, recovering lost documentation, finding security flaws, and checking interoperability. Legal issues and copyright need to be considered.

Software configuration management (SCM) is the discipline of identifying, organising and controlling changes to the software and its related items (code, documents, test data, tools) throughout the life cycle, so that the integrity and traceability of the product are maintained. The items controlled are called software configuration items (SCIs).

Detailed tasks in the SCM process

1. Configuration identification: the SCIs are identified, uniquely named and organised (e.g. SRS_v1.2, Login.java 2.4). Items are classified as baselined items (frozen, change only through formal control) and non-baselined items. Version numbers and a naming convention are defined. Example: in a banking project, the SRS, design document, source files and test plan are each an SCI with an identifier.
2. Version control: the versions and variants of each SCI are stored in a repository and managed with check-in/check-out, branching and merging (e.g. Git). The tool records who changed what and when. Example: release 1.0 is maintained on a branch while 2.0 is developed on another.
3. Change control: a formal procedure governs each change: a change request is submitted, its impact is evaluated, the Change Control Board (CCB) approves or rejects it, then the change is made, tested, and the item is checked in again. Example: a customer asks for a new fee in the bank system; the CCB assesses effort and risk before approving.
4. Configuration auditing: verifies that the changes were made correctly and the baseline contains what it should. A formal technical review checks technical correctness, and a configuration audit checks that the change was made as approved, the standards were followed and the related items were updated.
5. Configuration status reporting (accounting): records and reports what happened: what changes were made, by whom, when, and what the effect was. It supplies the status of the baseline to all stakeholders.
6. Build and release management: the correct versions of the items are assembled into a build, which is then released. Example: nightly builds from the main branch, tagging release 1.0.

Baseline: a specification or product that has been formally reviewed and agreed, and which serves as the basis for further development; it can be changed only through the formal change control procedure.

Benefits: avoids confusion between versions, enables rollback, supports team work, and gives traceability and quality.

Agile software development is an iterative and incremental approach in which requirements and solutions evolve through collaboration between self-organising cross-functional teams and the customer. It is based on the Agile Manifesto (2001), which values:

• individuals and interactions over processes and tools,
• working software over comprehensive documentation,
• customer collaboration over contract negotiation,
• responding to change over following a plan.

Principles: customer satisfaction through early and continuous delivery, welcome changing requirements, deliver working software frequently (weeks), daily collaboration between business people and developers, motivated individuals, face-to-face communication, working software as the measure of progress, sustainable pace, technical excellence, simplicity, self-organising teams and regular reflection and adjustment.

Methods and practices: Extreme Programming (pair programming, test-driven development, continuous integration, small releases, refactoring, user stories), Scrum (sprints of 2-4 weeks, product backlog, daily stand-up, sprint review and retrospective, with roles of product owner, scrum master and team), Kanban and others.

Comparison with prototyping

In short, agile builds the real product in small steps with the customer, while prototyping builds a model to learn what the product should be.

Verification and validation (V&V) are checking processes to ensure that the software conforms to its specification and meets the needs of the customer.

Comparison

Why validation is difficult

1. Requirements are incomplete or wrong. Validation compares software with what users really need, which is not written down exactly and may be misunderstood or may change. There is nothing precise to compare with, unlike verification which compares with a written specification.
2. Users' needs are hard to express and differ among stakeholders. Different users disagree, and many needs are implicit and appear only on actual use.
3. Exhaustive testing is impossible. The number of inputs, states and paths is enormous, so testing shows the presence of faults but never their absence.
4. Non-functional properties such as usability, performance and reliability are hard to measure and the real operating environment is difficult to reproduce.
5. Needs change during development, so a system correct at delivery may be wrong for today's needs.
6. Real validation needs customer time and realistic data, which are expensive.

Example: a hospital billing system is verified against an SRS that says "compute bill = sum of item charges", and all tests pass. In validation, hospital staff find that insurance discounts, which nobody wrote in the SRS, are also required, so the system, though correct to its specification, is not what the users need. Finding this needed real users operating the system.

Good software is judged by the following characteristics, which are grouped as product attributes.

1. Correctness / functionality: it does what the specification and users require, and gives correct results.
2. Maintainability: it can be changed easily to fix faults, to adapt to a new environment or to meet changing needs. It should be well structured, documented and readable.
3. Dependability (reliability, safety, security): it does not fail often, and does not cause damage when it fails; it should be protected against malicious use. Reliability is measured by MTTF or ROCOF.
4. Efficiency: it does not waste system resources such as processor time and memory, and has good response time and throughput.
5. Usability (acceptability): it has an understandable, convenient interface and documentation that the intended users can learn and use without much effort, and it is compatible with other systems they use.
6. Portability: it can be transferred to run on another hardware or operating system with little effort.
7. Reusability: its components can be used in other applications.
8. Testability and flexibility/scalability: it is easy to test and can grow and be extended.
9. Timeliness and cost-effectiveness: it is delivered on time and within budget.

The relative importance depends on the type of software; for example, safety and reliability dominate in an aircraft control system, while usability and efficiency matter in a game.

Requirements engineering (RE) is the process of finding out, analysing, documenting and checking the services that a customer requires from a system and the constraints under which it operates and is developed. The process has four main activities, which are usually iterative and overlap.

1. Feasibility study: a short study to decide whether the proposed system is worth building: technical, economic, operational and schedule feasibility. The output is a feasibility report recommending whether to proceed.

2. Requirements elicitation and analysis: requirements are gathered from stakeholders (users, managers, domain experts) by interviews, questionnaires, observation (ethnography), workshops, scenarios and use cases, and prototypes. They are classified, conflicts between stakeholders are negotiated, and requirements are prioritised.

3. Requirements specification: the agreed requirements are written down clearly as user requirements (natural language, diagrams, for the customer) and system requirements (detailed, for developers), forming the SRS document. Functional and non-functional requirements are both specified.

4. Requirements validation: the requirements are checked for validity, consistency, completeness, realism and verifiability. Techniques: requirements reviews, prototyping and test-case generation. Errors found here are cheap to correct.

5. Requirements management (running through all stages): changes in requirements are tracked and controlled during development, with traceability between requirements and design, code and tests.

Feasibility study -> Elicitation & analysis -> Specification -> Validation
                              ^                                    |
                              +------------- feedback ------------+

Software quality assurance (SQA) is a set of planned and systematic activities applied throughout the software process to provide confidence that the software product and the process used to build it conform to the specified requirements and standards. It covers the whole process, not only testing, and so it is preventive rather than just detective.

SQA activities

1. Preparing an SQA plan (standards, reviews, audits, metrics, tools to be used).
2. Applying technical methods and tools, and following standards such as ISO 9001 or CMMI.
3. Conducting formal technical reviews, inspections and walkthroughs of work products.
4. Testing at all levels (unit, integration, system, acceptance).
5. Enforcing standards and procedures, and auditing for compliance.
6. Change control, and recording and tracking defects and their correction.
7. Measuring quality with metrics (defect density, MTTF, code coverage) and reporting to management.

Example: in a project to build an online library system, the quality team defines a coding standard and an SQA plan. The SRS and design are reviewed in a walkthrough, and 12 ambiguities in the SRS are found and fixed before coding. Code inspections check naming and unit test coverage of at least 80%. A defect log is kept, and in a release audit the team notes that defect density is 0.8 per KLOC, which is below the target of 1, so the release is approved. If it exceeded the target, the release would be held back and corrective action taken.

Benefits: fewer defects, lower rework cost, customer confidence, and predictable delivery.

The Software Requirements Specification (SRS) is the official document that states what the system should do. It is used by customers, developers, testers and maintainers. A commonly used structure is that of IEEE 830:

1. Introduction

• 1.1 Purpose of the document
• 1.2 Scope of the product
• 1.3 Definitions, acronyms and abbreviations
• 1.4 References
• 1.5 Overview of the rest of the document

2. Overall description

• 2.1 Product perspective (relation to other systems)
• 2.2 Product functions (summary)
• 2.3 User characteristics
• 2.4 Constraints (hardware, regulatory, design limits)
• 2.5 Assumptions and dependencies

3. Specific requirements

• 3.1 External interface requirements (user interface, hardware, software, communication)
• 3.2 Functional requirements (each feature or use case with inputs, processing and outputs)
• 3.3 Performance requirements
• 3.4 Design constraints
• 3.5 Software system attributes (reliability, availability, security, maintainability, portability)
• 3.6 Other requirements (database, legal)

4. Appendices and index: sample data, glossary, analysis models, and a list of possible future changes.

A good SRS is correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable and traceable.

COCOMO (Constructive Cost Model), proposed by Barry Boehm, estimates effort, development time and staffing of a software project from its size in thousands of delivered source lines (KLOC). Basic COCOMO uses:

$E = a\,(KLOC)^b \ \text{person-months},\qquad D = c\,E^{d}\ \text{months},\qquad N = E/D\ \text{persons}$

Intermediate COCOMO multiplies effort by an effort adjustment factor from 15 cost drivers (product, hardware, personnel and project attributes).

Example. An organic-mode project of 32 KLOC.

Effort: $E = 2.4\,(32)^{1.05} = 2.4 \times 38.06 \approx 91.3\ \text{person-months}$

Development time: $D = 2.5\,(91.3)^{0.38} = 2.5 \times 5.56 \approx 13.9\ \text{months}$

Average staff: $N = \frac{E}{D} = \frac{91.3}{13.9} \approx 6.6 \approx 7\ \text{persons}$

Cost, if the average monthly cost of a person is Rs 60,000: $\text{Cost} = 91.3 \times 60{,}000 \approx \text{Rs } 54{,}78{,}000$

So the project needs about 91 person-months, about 14 months, a team of about 7 people, and roughly Rs 54.8 lakh. The same size in semi-detached mode would give $E = 3.0 \times 32^{1.12} \approx 3.0\times 48.5 \approx 146$ person-months, showing how project mode affects the estimate.

Reuse-based software engineering is an approach in which software is built mainly by assembling existing, tested software components, rather than writing everything from scratch. The reuse can be at the level of function, class, component, application system or whole system.

Process: requirements specification, then component analysis (search for components that match), requirements modification (adapt requirements to the available components), system design with reuse, then development and integration (write the glue and the missing code), and system validation.

Forms of reuse

• Component-based development (components with standard interfaces such as EJB, .NET).
• COTS product integration, application frameworks, service-oriented systems, program libraries.
• Application system reuse, e.g. configurable ERP.
• Design patterns and product lines.

Example: an online shop is built using an existing payment gateway API, an authentication library, a database and a web framework like Django. The team writes only the product catalogue and business rules. Delivery is faster and cheaper than developing all modules.

Advantages: faster delivery, lower cost, increased reliability (components already tested), reduced risk, standards compliance and effective use of specialists. Problems: components may not exactly fit requirements, finding and understanding components is hard, there is a lack of source control over the components (maintenance dependency), compatibility and licensing issues, and the "not-invented-here" attitude.

Version control is the process of managing the different versions of software configuration items, so that every change is recorded and any earlier version can be retrieved. It is a part of software configuration management and is supported by tools such as Git, SVN and CVS.

Process

1. Create a repository: all project items (source, documents) are stored in a central repository (or distributed repositories) that records every version.
2. Check-out / clone: a developer takes a working copy of the latest version. In locking systems the item is locked; in modern systems several developers can edit in parallel.
3. Modify: the developer changes the files in the working copy, tests them locally, and may create a separate branch for a new feature or a release.
4. Check-in / commit: the change is saved to the repository with a log message. The system assigns a new version number (e.g. 1.3 to 1.4) and stores the change as a delta.
5. Merge: changes from branches or from several developers are merged. Conflicts are detected and resolved manually.
6. Tagging / baselining: stable versions are given a name (tag) such as release-1.0, forming a baseline.
7. Review, history and rollback: the history of who changed what and when is available, differences between versions can be compared, and the project can be reverted to an earlier version if a change causes a fault.

Version naming: major.minor.patch (e.g. 2.1.3). Terms: repository, trunk, branch, merge, tag, revision.

Benefits: teamwork without overwriting, traceability, backup, parallel development and release management.

Prototyping model is a software process model in which a working model (prototype) of the system, or of part of it, is built early, shown to the users, and refined repeatedly until the requirements are well understood. The steps are: quick requirements gathering, quick design (focusing on user-visible aspects such as input and output), building the prototype, customer evaluation, refinement of the requirements and the prototype, and finally development of the real product (or evolution of the prototype).

How prototyping helps in developing software

1. Clarifies unclear and incomplete requirements. Users find it easier to react to a working model than to read a document, so missing and misunderstood requirements are found early.
2. Reduces risk. Technical issues such as feasibility, performance and interface are explored early, before large investment.
3. Improves user involvement and satisfaction. Users see and feel the system, which creates a sense of ownership.
4. Reduces rework and cost. Errors in requirements are cheaper to correct on a prototype than in delivered code.
5. Helps design and training. The user interface can be tried, and the prototype can be used for demonstration and training and as the basis for test cases.
6. Gives early evidence that the project is progressing.

Limitations: it may be built carelessly and then used as the final product; users may expect the final system's speed and quality; additional effort and cost are needed; and the scope may keep growing.

Evolutionary vs throw-away prototype

Functional vs non-functional requirements

Library management system

Functional requirements

1. Search books: a member shall be able to search the catalogue by title, author, ISBN or subject, and see the availability.
2. Issue and return books: the librarian shall be able to issue a book to a valid member (limited to the allowed number of books), record the due date, and record the return of a book.
3. Fine calculation: the system shall calculate a fine for each overdue day when a book is returned late, and shall record the payment.

(Others: reserve books, manage members, generate reports.)

Non-functional requirements

1. Performance: a search result shall be displayed within 3 seconds for a catalogue of up to 100,000 records, with 100 concurrent users.
2. Security: only authenticated users can use the system; the librarian and the members have different access rights, and passwords are stored encrypted.
3. Usability and availability: a new librarian shall be able to learn the basic operations within 2 hours of training, and the system shall be available 99% of the time during library hours.

(Others: portability, backup and recovery, reliability.)

Software configuration management (SCM) is the set of activities to identify, control and report on the changes made to software and its related work products throughout their life, so that the product remains consistent and traceable.

Activities carried out in SCM

1. Configuration identification: identifying the software configuration items (SCIs: source code, SRS, design, test cases, user manual, tools) and giving each a unique name and version number. Baselines are defined at milestones, e.g. an approved SRS is a baseline. Example: SRS v1.0 and PaymentModule 2.3.

2. Version control: managing the multiple versions and variants of the items using a repository and tool (Git, SVN). It supports check-in/check-out, branching, merging, tagging of releases, history and rollback. Example: the production release 1.0 is maintained on a branch while 2.0 is developed on the main line.

3. Change control: the formal process of handling change requests.

   • A change request (CR) is submitted and logged.
   • The impact on cost, schedule and other items is analysed.
   • The Change Control Board (CCB) approves, rejects or defers it.
   • Approved changes are assigned, implemented, tested and reviewed, and the item is checked in and the baseline updated. This prevents uncontrolled, chaotic changes.

4. Configuration auditing: formal technical reviews and configuration audits verify that the approved changes have been made, that no other change was introduced, that standards were followed and that related items were updated consistently.

5. Configuration status reporting (status accounting): recording and reporting information on the configuration, such as what changes were made, who made them, when and why, which versions make up each baseline, and the effect. It keeps all stakeholders informed.

6. Build and release management: creating the build from the correct versions of the items and preparing and distributing releases.

Why SCM is required

• Software changes continuously, and uncontrolled changes cause confusion and errors.
• Many developers work on the same files, so conflicts and overwriting must be avoided.
• It keeps track of which version is in which customer's hands, for support and bug fixing.
• Allows recovery of an earlier stable version when a change fails.
• It provides traceability and audit evidence for quality standards (ISO, CMMI).
• It improves productivity and product quality and reduces cost of rework.

Agile software development is a group of iterative, incremental methods in which software is delivered in short cycles (iterations or sprints of 1-4 weeks) by small, self-organising, cross-functional teams working closely with the customer. It accepts that requirements change and favours working software, collaboration and quick feedback over heavy documentation and rigid plans, as stated in the Agile Manifesto.

Key features

• Short iterations each producing a working increment.
• Customer is involved throughout; frequent feedback.
• Welcomes changing requirements, even late.
• Face-to-face communication, daily meetings.
• Continuous testing and integration; simple design and refactoring.
• Minimal but sufficient documentation.

Common methods: Scrum (product backlog, sprint, daily stand-up, review, retrospective), Extreme Programming (pair programming, TDD, small releases), Kanban, Feature-Driven Development.

Applications (where it is suitable)

• Projects whose requirements are unclear or likely to change, such as web and mobile applications, start-up products and e-commerce.
• Small to medium sized products developed by a small co-located team.
• Custom software with an engaged customer who can give continuous feedback.
• Products that must reach the market quickly, with frequent releases.
• It is also used to scale in large organisations with frameworks like SAFe.

Less suitable: safety-critical systems needing extensive documentation and formal verification (e.g. avionics), very large distributed teams, and fixed-price contracts with fixed specifications.

Software engineering is thus a part (sub-discipline) of system engineering, which decides what the software must do within the system.

Software quality assurance (SQA) is a planned and systematic set of activities that gives confidence that a software process and its products conform to the specified requirements and standards. It covers the whole life cycle, not only testing, and is aimed at preventing defects rather than only detecting them.

Main activities of SQA

• Defining quality standards and procedures (for example ISO 9001, CMMI, IEEE standards) that the project must follow.
• Quality planning: deciding which quality attributes (reliability, maintainability, usability, efficiency) matter and how they will be measured.
• Reviews and inspections of requirements, design and code to find defects early.
• Testing and verification/validation at each stage.
• Process monitoring and software measurement (defect density, review effectiveness, test coverage).
• Configuration and change control so that only approved changes enter the product.
• Audits and reporting of non-compliance to management, with corrective action.

Quality management levels

• Quality assurance: establishing the framework of organisational processes and standards.
• Quality planning: selecting the standards and procedures for a particular project.
• Quality control: checking that the project team follows the planned procedures, through reviews and tests.

Importance: it reduces the cost of fixing errors (a defect found in requirements is far cheaper to fix than one found after release), improves customer satisfaction, and makes development predictable.

Example: before coding a banking application, a team holds a design review against the standard checklist, runs code inspections, and measures defects per KLOC. If the measure exceeds the target, corrective action is taken before release.

A behavioral model describes the dynamic behaviour of a system as it executes, that is, how it responds to stimuli (data or events) from its environment. It complements structural models, which show only the static organisation. There are two main kinds of stimuli, and so two kinds of behavioral model.

1. Data-driven models (data-flow diagrams, activity diagrams) show the sequence of actions involved in processing input data to produce output. They are useful in business systems where processing is a sequence of transformations.

2. Event-driven models (state machine models) show how the system responds to external and internal events. The system is modelled as a set of states; events cause transitions between states. In UML these are drawn as state diagrams.

Example: simple microwave oven (state machine)

            full power / half power
   +---------------------------------------+
   |                                       v
[Waiting] --(set time)--> [Number set] --(start)--> [Operation]
   ^   ^                        |                       |
   |   |                    (door open)             (timer / cancel)
   |   +---- [Disabled] <-------+                       |
   +-------------------------------------------------- +

• Waiting: displays the current time; on pressing a power button it moves to Half power or Full power.
• Number set: a time has been entered; the door must be closed to start.
• Operation: the oven cooks, the light turns on and the timer counts down. When the timer reaches zero (or Cancel is pressed) it returns to Waiting.
• Disabled: entered when the door is open; cooking cannot start until the door is closed.

Each state is a rounded box, each arrow is labelled with the event causing the transition. Such models help specify and verify real-time and embedded systems before implementation.

Component-based software engineering (CBSE) is an approach in which systems are built by assembling pre-existing, independently developed components rather than coding everything from scratch. It emerged from the need for faster development and reuse.

Component: an independent, replaceable unit of software that encapsulates its implementation and exposes functionality only through well-defined interfaces. Properties: standardised, independent, composable, deployable, documented.

Essentials of CBSE

1. Independent components fully specified by their interfaces.
2. Component standards (for example CORBA, JavaBeans/EJB, .NET/COM) so components can interoperate.
3. Middleware providing support for component integration, communication and transactions.
4. A development process geared to reuse.

CBSE process

• Requirements outline, then identification of candidate components.
• Modify requirements according to the discovered components.
• Architecture design.
• Component identification and qualification (does it meet functional and non-functional needs?).
• Component adaptation (wrappers) and composition (sequential, hierarchical, additive).
• Testing and integration, then system update when components are replaced.

Component interfaces: a provides interface lists services the component offers; a requires interface lists services it needs from others.

Advantages: reduced development time and cost, higher quality (components are tested through reuse), easier maintenance by replacement, and specialisation of effort.

Disadvantages: loss of control over component evolution, difficulty finding and trusting suitable components, integration mismatches, and performance overhead.

Example: an online shop assembling a third-party payment gateway, a search component and a shopping-cart component into one application.

Assumptions: actors are Customer, Admin and Payment Gateway (external). A customer searches movies, selects a show, chooses seats, pays and receives an e-ticket. The admin manages movies and shows.

Use case diagram

                 +--------- Online Movie Ticketing System ---------+
                 |                                                  |
 Customer -------|--> (Register / Login)                            |
    |            |--> (Search movies)                               |
    |            |--> (View show times)                             |
    |            |--> (Select seats) ..<<include>>..> (Check availability)
    |            |--> (Book ticket) ..<<include>>..> (Make payment) ----> Payment Gateway
    |            |--> (Cancel booking)                              |
    |            |--> (Receive e-ticket)                            |
                 |                                                  |
 Admin ----------|--> (Manage movies)                               |
                 |--> (Manage shows and prices)                     |
                 |--> (View sales reports)                          |
                 +--------------------------------------------------+

Sequence diagram: booking a ticket

Customer      WebUI        BookingCtrl      ShowDB       PaymentGateway
   |  search    |               |              |               |
   |----------->|  getShows()   |              |               |
   |            |-------------->| query        |               |
   |            |               |------------->|               |
   |            |               |<-- shows ----|               |
   |<-- list ---|<--------------|              |               |
   | select seats               |              |               |
   |----------->| checkSeats()  |------------->|               |
   |            |               |<-- available-|               |
   | confirm+pay|               |              |               |
   |----------->| pay(amount)   |------------------------------>|
   |            |               |<------------ success ---------|
   |            |               | reserve(seats)-->            |
   |            |               |------------->|               |
   |<-- e-ticket (confirmation) |              |               |

Messages go top to bottom in time order; the booking controller coordinates seat checking, payment and seat reservation. If payment fails, no reservation is made and an error is shown to the customer.

Reverse engineering is therefore usually the first stage of a reengineering project: the legacy system is first understood and documented, then restructured (source code translation, data reengineering, program restructuring) and finally forward-engineered into the new system.

Basic COCOMO equations, with size $S$ in KLOC:

$E = a\,S^{b}\ \text{(person-months)},\qquad D = c\,E^{d}\ \text{(months)}$

Organic: $a=2.4,\ b=1.05,\ c=2.5,\ d=0.38$. Semidetached: $a=3.0,\ b=1.12,\ c=2.5,\ d=0.35$. Here $S=400$.

Organic

$E = 2.4\times 400^{1.05} = 2.4\times 539.7 \approx 1295\ \text{person-months}$

$D = 2.5\times 1295^{0.38} \approx 2.5\times 15.23 \approx 38.1\ \text{months}$

Semidetached

$E = 3.0\times 400^{1.12} = 3.0\times 820.9 \approx 2463\ \text{person-months}$

$D = 2.5\times 2463^{0.35} \approx 2.5\times 15.38 \approx 38.5\ \text{months}$

(Check: $\ln 400 = 5.9915$, so $400^{1.05}=e^{6.2911}\approx 539.7$ and $400^{1.12}=e^{6.7105}\approx 820.9$.)

Software configuration management (SCM) is the discipline of identifying, organising and controlling changes to software products throughout the life cycle. Because requirements, design, code and documents change continually, SCM ensures that changes are made in a controlled, traceable way and that the team always knows which versions make up a given release.

Main SCM activities and how they support change

1. Configuration identification: every item (requirements document, design, source file, test case, build script) is named and versioned as a configuration item. A baseline is a formally approved set of items, for example the SRS baseline after requirements review.
2. Version control: stores all versions of each item, supports branching and merging so parallel work (new features and bug fixes) does not collide, and lets the team roll back (Git, SVN).
3. Change control: a formal process for a change request: request submitted, impact analysed (cost, schedule, affected items), change control board approves or rejects, change implemented and tested, baseline updated. This prevents uncontrolled changes (scope creep).
4. Configuration status accounting: records what changed, when and by whom.
5. Configuration auditing and review: checks that the approved changes were really made and the baseline is consistent.
6. Build and release management: builds the system from specific versions, and records exactly which versions went into each release.

Support at different life-cycle stages

• Requirements: a new customer requirement creates a change request; the SRS version moves from 1.0 to 1.1, and traceability shows which design and code items are affected.
• Design/Coding: developers work on branches; merges are reviewed and conflicts resolved.
• Testing: bugs found are logged as change requests, fixes are tracked, and test results are tied to the exact build.
• Maintenance: patches can be applied to the released version 1.0 while version 2.0 is developed on another branch.

Example: In an online banking project, after release 1.0 the bank asks for two-factor login. A change request is raised, the board approves it after impact analysis (login module, database, SRS), a feature branch is created, the work is tested and merged into the main line, and release 1.1 is tagged. If the new login fails in production, version control allows rollback to 1.0. Without SCM, the team might overwrite files, lose track of which code is in production, or release untested changes.

Requirements engineering (RE) is the process of finding out, analysing, documenting and checking the services a system should provide and the constraints on it.

Main activities

1. Feasibility study: decides whether the proposed system is worthwhile technically, financially and operationally, and whether it can be built within budget and time.
2. Requirements elicitation and analysis: discovering requirements by interviews, questionnaires, observation (ethnography), scenarios, use cases and prototyping. The requirements are classified, conflicts negotiated and priorities set.
3. Requirements specification: writing the agreed requirements in a document (the SRS) in natural language, structured form, or models, as user requirements (high level) and system requirements (detailed).
4. Requirements validation: checking that they are valid, consistent, complete, realistic and verifiable, using reviews, prototyping and test-case generation.
5. Requirements management: tracking changing requirements, with traceability and change control, throughout the project.

These activities are iterative rather than strictly sequential.

Desirable characteristics of a good SRS (IEEE 830)

• Correct: every requirement states something the system must really do.
• Unambiguous: each requirement has only one interpretation.
• Complete: includes all functional, non-functional, interface and design constraints.
• Consistent: no requirement conflicts with another.
• Ranked for importance/stability: priorities are given.
• Verifiable: a finite, cost-effective test can show it is met.
• Modifiable: well structured, with no redundancy.
• Traceable: each requirement is uniquely identified and traceable to its source and to design and tests.

Example (library system)

• Poor: "The system should be fast and user friendly."
• Good: "REQ-4.2: The system shall display the search results for a book title within 3 seconds for a catalogue of up to 100,000 records." This is unambiguous, measurable and verifiable.
• "REQ-3.1: The system shall allow a librarian to issue a book only to a member whose membership is active." This is a clear, uniquely identified, testable functional requirement.

A good SRS reduces rework, forms the basis of the contract, design, testing and estimation.

Architectural views

A single diagram cannot show every aspect of a software architecture, so several complementary views are used. Krutchen's 4+1 model suggests:

1. Logical view: key abstractions (objects/classes) and their relationships; shows functional requirements.
2. Process view: runtime processes, their interactions and concurrency; shows performance and availability.
3. Development (implementation) view: how software is decomposed into modules and components for developers.
4. Physical (deployment) view: hardware nodes and how components are distributed over them.
5. +1 Use-case (scenario) view: ties the four views together through scenarios.

Conceptual architecture views (module, component-and-connector, allocation views) serve the same purpose. Views are linked and used for design, communication with stakeholders, and analysis.

1. Layered architecture

The system is organised as layers, each providing services to the layer above and using services from the layer below.

+---------------------------+
|  Presentation / UI        |
+---------------------------+
|  Business logic           |
+---------------------------+
|  Data access              |
+---------------------------+
|  Operating system / DB    |
+---------------------------+

Supports incremental development and portability (a layer can be replaced if its interface is kept). Drawbacks: clean separation is difficult, and performance suffers through several layers. Example: OSI network model, web applications.

2. Repository architecture

All shared data is held in a central repository (database) that all subsystems access; subsystems do not communicate directly.

 [Editor] [Compiler] [Debugger]
      \       |       /
       +--------------+
       |  Repository  |
       +--------------+

Efficient for sharing large amounts of data; subsystems need not know about each other, and backup/security is centralised. Drawback: the repository is a single point of failure and bottleneck, and data model changes affect every subsystem. Example: IDEs, CASE tools, banking databases.

3. Pipe and filter architecture

Processing is a series of filters that transform data; pipes carry the data from one filter to the next.

Input --> [Filter 1] --pipe--> [Filter 2] --pipe--> [Filter 3] --> Output

Simple, supports reuse of filters and easy addition or reordering of stages, and concurrent execution. Drawbacks: unsuitable for interactive systems, data format must be agreed between filters. Example: Unix command pipelines (cat f | grep x | sort), compilers, data processing batch systems.

Software engineering ethics are the moral principles and professional responsibilities that govern the conduct of software engineers. Because software affects the safety, privacy and finances of people, engineers must act responsibly beyond technical skill and the law.

Responsibilities

• Confidentiality: respecting the confidentiality of employers and clients, whether or not a formal agreement exists.
• Competence: not misrepresenting one's level of competence or accepting work beyond one's ability.
• Intellectual property rights: respecting patents, copyrights and licences.
• Computer misuse: not using technical skills to misuse others' computers (for example spreading viruses or unauthorised access).

ACM/IEEE Code of Ethics principles: act in the public interest; act in the best interest of client and employer consistent with public interest; ensure products meet the highest professional standards; maintain integrity and independence in professional judgement; managers promote ethical management; advance the integrity of the profession; be fair and supportive to colleagues; take part in lifelong learning.

Examples

1. A developer is asked to hide a known security flaw in a banking application to meet a release deadline. Public interest and honesty require reporting the flaw and refusing to ship it silently.
2. An engineer who worked for a company copies its source code to use in a competitor's product, violating intellectual property and confidentiality.
3. A developer claims experience in safety-critical medical software that he does not have, which violates competence.

Ethical dilemmas occur when the engineer disagrees with company policy, or when the employer acts unethically, for example building a system that is unsafe. The engineer should then raise concerns, and if unresolved may need to resign or whistle-blow.

A prototype is an early, partial version of the system used to clarify requirements or explore design. There are two approaches.

Evolutionary prototyping gets a working system to customers sooner; throw-away prototyping lowers the risk of building the wrong thing, and the final system is then built using a conventional process.

In practice most projects use a mix of both.

Functional requirements describe what the system should do: the services, functions and behaviour, and how it reacts to particular inputs. Example: "The system shall allow a user to log in with a username and password" or "The library system shall allow members to reserve books".

Non-functional requirements (NFRs) describe constraints on the services or the system as a whole, or qualities: performance, reliability, security, usability, portability, capacity, standards and legal constraints. Example: "The system shall respond to any query within 2 seconds" and "The system shall be available 99.9% of the time".

Which is more critical? Non-functional requirements are generally more critical. Functional shortcomings can often be worked around or patched, but if a non-functional requirement is not met, the entire system may be useless: an air traffic control system that is too slow or insecure, or an unreliable banking system, cannot be used however many functions it has. NFRs also affect the architecture of the whole system, so they are expensive to change later, and they can generate many related functional requirements (for example a security requirement leads to login and encryption functions). Still, both are needed: without correct functions the system has no purpose.

Release testing is the process of testing a particular release of a system that is intended for use outside the development team (usually the customer or users). Its main aim is to convince the supplier that the system is good enough for release, by showing that it delivers the specified functionality, performance and dependability and does not fail during normal use. It is a black-box testing process: tests are derived from the system specification (requirements-based testing, scenario testing, performance testing), and the testers need not know the code. It is usually done by a separate team that was not involved in development.

System testing is the testing of the integrated system after components have been combined, to find defects arising from interactions between components and subsystems, and to check that the components are compatible and interact correctly.

Legacy system: an old software or hardware system, built with outdated technology (for example COBOL on a mainframe), that is still used by an organisation because it performs critical business functions. It is often poorly documented, hard to maintain, and difficult to integrate with modern systems, but replacing it is costly and risky.

A legacy system typically consists of: system hardware, support software (OS, compilers), application software, application data, business processes, and business policies and rules embedded in the code.

Importance

1. Embodies business knowledge: years of business rules and exceptions are encoded in the code and are rarely written elsewhere, and cannot easily be recovered.
2. Business critical: banks, insurance firms, airlines and governments depend on them daily (for example mainframe transaction processing).
3. Proven reliability: it has been tested in use for years and is stable.
4. High replacement cost and risk: rewriting is expensive, may take years, and a failed replacement can halt operations. Specifications are often missing.
5. Data value: it holds large volumes of valuable historical data.
6. Evolution options: since scrapping is rarely justified, they are maintained, wrapped with new interfaces/services, reengineered or gradually replaced, depending on their business value and quality.

Decision: a system with low quality but high business value is kept and reengineered; low value and low quality systems are scrapped.

Assumptions: actors are Passenger, Admin and Payment Gateway. Passengers search buses, view seats, book and pay, and cancel. Admin manages buses, routes and schedules.

Use case diagram

                  +------- Online Bus Ticketing System -------+
 Passenger -------|--> (Register / Login)                      |
    |             |--> (Search buses by route and date)        |
    |             |--> (View seat layout)                      |
    |             |--> (Book ticket) ..<<include>>..> (Make payment) --> Payment Gateway
    |             |--> (Cancel ticket) ..<<extend>>.. (Refund) |
    |             |--> (Print / download ticket)               |
 Admin -----------|--> (Manage buses and routes)               |
                  |--> (Manage schedules and fares)            |
                  |--> (View booking reports)                  |
                  +--------------------------------------------+

Class diagram

+-----------------+        +------------------+        +----------------+
| Passenger       |1     * | Booking          |*      1| Schedule       |
|-----------------|--------|------------------|--------|----------------|
| passengerId     |        | bookingId        |        | scheduleId     |
| name, phone     |        | bookingDate      |        | departureTime  |
| email, password |        | status           |        | fare           |
|-----------------|        | totalAmount      |        |----------------|
| register()      |        |------------------|        | getAvailable() |
| login()         |        | confirm()        |        +-------+--------+
| searchBus()     |        | cancel()         |                |* 
+-----------------+        +----+--------+----+                |1
                              1 |        | *            +------+--------+
                       +--------+--+  +--+--------+     | Bus           |
                       | Payment   |  | Seat      |     |---------------|
                       |-----------|  |-----------|     | busNo, type   |
                       | paymentId |  | seatNo    |*   1| capacity      |
                       | amount    |  | isBooked  |-----| route         |
                       | method    |  +-----------+     +---------------+
                       | pay()     |
                       | refund()  |
                       +-----------+

Relationships: a Passenger makes many Bookings; each Booking is for one Schedule, has one Payment and one or more Seats; a Bus has many Seats and many Schedules. Admin is a separate user class with addBus(), updateSchedule() and generateReport().

A behavioral model shows the dynamic behaviour of a system when it is executing, that is, how it responds to stimuli from its environment. Two kinds of stimuli give two kinds of models.

1. Data-driven modelling shows the sequence of actions in processing input data into output, usually with data-flow diagrams or UML activity diagrams. It is typical of business data-processing systems.

Example (order processing DFD): Customer sends Order to process 1 "Validate order", which reads Customer file and passes the Valid order to process 2 "Check stock" (reads Stock file), then to process 3 "Generate invoice", which outputs an Invoice to the Customer.

Customer --order--> (Validate) --valid order--> (Check stock) --> (Generate invoice) --invoice--> Customer

2. Event-driven modelling shows how the system responds to external and internal events. The system has states and events cause transitions between them; it is drawn as a state machine diagram.

Example (microwave oven)

 [Waiting] --(select power)--> [Power set] --(set time)--> [Time set] --(start, door closed)--> [Operation]
     ^                                                                                           |
     +------------------------ (timer expires / cancel) -----------------------------------------+
 [Operation] --(door opened)--> [Disabled] --(door closed)--> [Waiting]

The model makes clear how the system must behave in each state, for example that cooking cannot begin with the door open. Behavioral models are used in analysis and design, especially for real-time and embedded systems.

COCOMO (Constructive Cost Model), proposed by Barry Boehm (1981), is an algorithmic, empirical model that estimates the effort, development time and staffing of a software project from its size in thousands of delivered lines of code (KLOC). It has three levels: Basic, Intermediate and Detailed.

Basic COCOMO

$E = a\,(KLOC)^{b}\ \text{person-months},\qquad D = c\,E^{d}\ \text{months},\qquad N = \frac{E}{D}\ \text{persons}$

Intermediate COCOMO multiplies the nominal effort by an effort adjustment factor (EAF), the product of 15 cost drivers in four groups: product (reliability, database size, complexity), computer (execution time, storage constraints), personnel (analyst and programmer capability, experience) and project (tools, schedule). Its equations are $E = a(KLOC)^b \times EAF$ with different constants (organic $a=3.2$).

Detailed COCOMO applies the cost drivers separately to each phase (design, code, test) and each module.

Example: organic project of 32 KLOC: $E = 2.4\times 32^{1.05} \approx 2.4\times 38.0 = 91$ person-months, $D = 2.5\times 91^{0.38}\approx 14$ months, staff $\approx 6.5$ persons.

COCOMO II adapts the model to modern practices (reuse, object points, function points, early design and post-architecture models).

Limitations: depends on an accurate size estimate early, subjective cost driver ratings, and it is calibrated on past projects.

Importance of software pricing

Software price is not simply the development cost plus profit; it is a business decision influenced by many factors. Pricing matters because:

• It determines the revenue and profit of the organisation and whether the project is financially viable.
• Under- or over-pricing: underpricing leads to losses, overpricing loses the contract to competitors.
• A fixed price contract needs an accurate cost estimate to avoid loss, while for cost-plus contracts the price affects customer trust.
• It decides market entry strategy: a low price may be set to win the market or to gain experience in a new domain (market opportunity).
• It reflects the risk and uncertainty of requirements, and the costs of maintenance and support, and it is used to negotiate scope, schedule and payment terms.

Factors affecting pricing: market opportunity, cost estimate uncertainty, contractual terms (who owns source code), requirements volatility, financial health of the developer, and the effort cost (salaries, hardware, travel, training, overheads).

COCOMO cost modelling technique

COCOMO is an empirical algorithmic model for estimating effort and schedule from size:

$E = a\,(KLOC)^{b}\ \text{person-months},\qquad D = c\,E^{d}\ \text{months}$

The constants depend on project class: organic ($a=2.4,\ b=1.05,\ c=2.5,\ d=0.38$), semidetached ($3.0,\ 1.12,\ 2.5,\ 0.35$) and embedded ($3.6,\ 1.20,\ 2.5,\ 0.32$). Intermediate COCOMO multiplies effort by an effort adjustment factor from 15 cost drivers (product, hardware, personnel, project attributes); Detailed COCOMO works phase by phase. COCOMO II extends this with object/application points, reuse and early design models.

Cost estimate then feeds the price: cost = effort $\times$ monthly staff cost + other costs, and price = cost + overhead + profit margin.

Disadvantages of COCOMO

1. Needs an accurate estimate of KLOC at the beginning, which is hard to get.
2. Ignores the customer's skills, cooperation and many soft factors; subjective rating of cost drivers.
3. Its coefficients are calibrated on old project data and may not suit the organisation or modern development (agile, reuse, CASE tools) without recalibration.
4. Does not deal well with requirements change, unclear requirements or non-functional factors, and treats effort as a smooth function of size.
5. Counting lines of code depends on the language and coding style; productivity differs, so the same function can have a very different size.
6. Gives only a rough estimate, with an error that can be large in early stages.

Assumptions: actors are User (registered reader), Admin, and an external Rating/Book database. A user registers, rates and reviews books, browses, and receives recommendations generated from his or her ratings and the ratings of similar users (collaborative filtering) plus genre preferences. The admin manages the book catalogue and users.

Use case diagram

                  +---------- Book Recommendation System ----------+
 User ------------|--> (Register / Login)                           |
   |              |--> (Search / browse books)                      |
   |              |--> (Rate and review book)                       |
   |              |--> (Set genre preferences)                      |
   |              |--> (View recommendations)                       |
   |              |        ..<<include>>..> (Generate recommendations)
   |              |--> (Add to reading list)                        |
 Admin -----------|--> (Manage books and categories)                |
                  |--> (Manage users)                               |
                  |--> (Update recommendation model)                |
                  +-------------------------------------------------+

Class diagram

+---------------+ 1     * +----------------+ *     1 +---------------+
| User          |---------| Rating         |---------| Book          |
|---------------| gives   |----------------|         |---------------|
| userId        |         | ratingId       |         | bookId        |
| name, email   |         | score (1-5)    |         | title, author |
| password      |         | review         |         | genre, isbn   |
| preferences   |         | date           |         | avgRating     |
|---------------|         +----------------+         |---------------|
| register()    |                                    | getDetails()  |
| login()       | 1     * +----------------+         +-------+-------+
| rateBook()    |---------| ReadingList    |* contains *      |
| search()      |         +----------------+------------------+
+------+--------+
       | uses 1
       v
+----------------------+ 
| Recommender          |  recommend(user): List<Book>
|----------------------|  computeSimilarity(u1, u2)
| algorithm            |  updateModel()
+----------------------+
 Admin (extends User): addBook(), removeBook(), manageUsers()

Sequence diagram: view recommendations

User      WebUI       Controller    Recommender      Database
 | login    |             |              |              |
 |--------->| authenticate|              |              |
 |          |------------>| verify------------------->  |
 |          |<--------------------- ok -----------------|
 | request recommendations              |              |
 |--------->| getRecs(userId)            |              |
 |          |------------>| recommend(userId)           |
 |          |             |------------->| getRatings() |
 |          |             |              |------------->|
 |          |             |              |<-- ratings --|
 |          |             |              | computeSimilarity,
 |          |             |              | rank books   |
 |          |             |<-- bookList -|              |
 |          |<-- display --|             |              |
 |<-- recommended books --|              |              |

The recommender reads the user's and other users' ratings, finds similar users or similar genre books, ranks unseen books by predicted rating, and returns the top few to display.

Software process model

A software process is the set of related activities that lead to the production of a software product. A software process model is an abstract, simplified representation of such a process, presented from a particular perspective (workflow, data-flow or role/action), that defines the order of activities and how they are organised. Generic models include:

• Waterfall: separate sequential phases (plan-driven).
• Incremental development: specification, development and validation interleaved, delivering increments.
• Reuse-oriented (integration and configuration): system assembled from existing components.
• Others: spiral, prototyping, agile (Scrum, XP), and the Rational Unified Process.

Software process activities

1. Software specification (requirements engineering): defining what services are required and the constraints. Sub-stages are feasibility study, requirements elicitation and analysis, requirements specification and requirements validation. The output is the SRS.
2. Software design and implementation: converting the specification into an executable system. Design covers architectural design, interface, component and database design; implementation is programming and debugging. These are often interleaved.
3. Software validation (verification and validation): showing that the system conforms to its specification and meets customer needs. Includes reviews and inspections and testing at stages: component (unit) testing, system (integration) testing and acceptance (customer) testing.
4. Software evolution (maintenance): modifying the system after delivery to correct faults, adapt to new environments or add new features as business needs change.

Supporting activities include project management, configuration management, quality assurance and documentation. In practice, these activities overlap and are repeated, and the chosen process model determines how they are arranged.

Risk management is the process of identifying risks to the project, assessing their impact and probability, planning to avoid or minimise them, and monitoring them during the project. A risk is a probable event that may threaten the schedule, cost or quality.

Risk categories: project risks (schedule, resources: staff turnover), product risks (quality or performance: components fail to perform), and business risks (a competitor releases first).

Risk management process

1. Risk identification: list possible risks using checklists, brainstorming and past experience. Types: technology (database too slow), people (key staff leave), organisational (management restructure), tools, requirements (changes), estimation (size underestimated).
2. Risk analysis: assess the probability (very low to very high) and effect (insignificant, tolerable, serious, catastrophic) of each risk.
3. Risk planning: draw up strategies, either
   • avoidance (reduce probability, for example buy a proven component rather than develop it),
   • minimisation (reduce impact, for example document work and train backup staff),
   • contingency plans (what to do if the risk occurs, such as a reserve budget).
4. Risk monitoring: regularly reassess each risk and its indicators (for example missed deadlines, staff complaints), and review at progress meetings, adjusting the plans.

A risk register records each risk, probability, impact, mitigation and owner.

Example: staff turnover is rated "moderate probability, serious impact". Mitigation: share knowledge, pair programming and documentation. Contingency: use contractors if someone leaves.

Software maintenance is the modification of software after delivery to correct faults, improve performance or other attributes, or adapt it to a changed environment. It is one of the most important activities because:

1. It consumes most of the life-cycle cost: for long-lived systems, maintenance typically accounts for about 60 to 80 percent of total cost, far more than initial development.
2. Software must change to stay useful: business rules, laws, hardware, operating systems and user needs change (Lehman's law of continuing change), and a system that is not maintained becomes obsolete.
3. Errors remain after delivery: testing cannot find every fault, so corrective maintenance is needed.
4. Protects the investment: maintaining an existing system is usually cheaper and less risky than replacing it.
5. User satisfaction and competitiveness: new features and better performance keep users and the business competitive.

Types of maintenance

• Corrective: fixing bugs found in use (about 17 percent).
• Adaptive: adapting to a new environment, such as a new OS or database (about 18 percent).
• Perfective: adding or improving functions and performance at user request (about 65 percent).
• Preventive: improving structure and documentation to ease later change.

Example: a bank's internet-banking application was delivered in 2015. Later, it needed (a) a fix for an interest-calculation error (corrective), (b) an update to run on the latest mobile OS (adaptive), (c) new mobile wallet payment features and two-factor authentication requested by customers (perfective), and (d) code restructuring to simplify future changes (preventive). Without maintenance the bank would have lost customers, faced security and regulatory problems, and had to rebuild the system at a much greater cost.

A design pattern is a reusable, tested solution to a commonly occurring problem in software design. It is not finished code but a description of the problem, the core of its solution, and the consequences of using it, abstracted so that it can be applied in many situations. Patterns capture the experience of skilled designers (the Gang of Four catalogue, for example) in a form others can reuse.

A pattern description normally has four essential elements:

• Name – a meaningful handle such as Observer or Factory Method.
• Problem description – the situation and conditions where the pattern applies.
• Solution description – the classes/objects, their relationships and responsibilities, given as a template rather than concrete code.
• Consequences – the results and trade-offs of applying the pattern.

Role in object-oriented design

• Patterns exploit object-oriented features such as abstraction, inheritance, polymorphism and encapsulation, so they show how to use them well.
• They give designers a common vocabulary: saying "use an Observer here" conveys a whole design in a few words.
• They promote reuse of design experience instead of re-inventing solutions, which reduces errors and design time.
• They make designs flexible and maintainable, e.g. Strategy and Factory let behaviour or object creation change without modifying client code (open/closed principle).
• They help in documenting a design and in understanding existing systems.
• Typical categories: creational (Singleton, Factory), structural (Adapter, Facade) and behavioural (Observer, Strategy).

Example: the Observer pattern lets a model object notify several views automatically when its state changes, without the model knowing the concrete views.

Application of architecture: a web-based e-commerce / online shopping system using a layered architecture.

Software architecture is the fundamental organisation of a system – its components, their relationships and the principles guiding its design and evolution. A well-chosen architecture directly decides performance, security, availability and maintainability.

In an online shopping system, a layered architecture is used:

1. Presentation layer – web/mobile user interface: browsing products, cart, checkout.
2. Application (business logic) layer – order processing, pricing and discounts, inventory checks, payment orchestration.
3. Data access / persistence layer – accesses the database and hides SQL details.
4. Database layer – stores customers, products, orders and payments.

 Browser / Mobile App
        |
 [ Presentation Layer ]
        |
 [ Business Logic Layer ]
        |
 [ Data Access Layer ]
        |
 [ Database ]

How the architecture helps

• Maintainability: a layer can be changed (e.g. a new UI) without touching the others.
• Security: sensitive data sits in the innermost layer behind the business layer, and payment handling is localised.
• Performance and availability: the business layer can be replicated behind a load balancer, and frequently read product data cached.
• Reuse and testing: each layer can be tested independently.

The same architecture is also used in banking systems, library systems and many enterprise applications.

Structural vs behavioural models

Importance of the behavioural model

• It shows how the system responds at run time to stimuli – either input data or external events – so it captures the functionality the user actually sees.
• Data-driven models (data-flow, activity diagrams) show the processing steps from input to output, which helps in understanding end-to-end processing.
• Event-driven models (state diagrams) show how the system moves between states in response to events, which is vital for real-time and embedded systems.
• It helps in requirements analysis and validation because users and developers can check the described behaviour together.
• It provides a basis for designing and testing: sequences and states give test cases and highlight missing or incorrect behaviour early.
• It improves communication between analysts, designers and clients.

The requirements engineering (RE) process is the set of activities used to discover, analyse, document and maintain the requirements of a system. Its main activities are:

1. Feasibility study – checks whether the proposed system is technically, financially and operationally worth building, within budget and schedule. The result is a short report recommending go/no-go.
2. Requirements elicitation and analysis – derives requirements by consulting stakeholders, studying existing systems and documents, interviews, observation, scenarios and prototypes. Requirements are then classified, prioritised and conflicts negotiated.
3. Requirements specification – writes the agreed requirements as a document (SRS) using natural language, structured language or models. User requirements are written for customers; system requirements in more detail for developers.
4. Requirements validation – checks the requirements for validity, consistency, completeness, realism and verifiability, using reviews, prototyping and test-case generation. Errors found here are far cheaper to fix than later.
5. Requirements management – tracks and controls changes to requirements throughout development because requirements keep changing. It involves change control, traceability and version control.

The process is iterative: the activities are interleaved and repeated, not strictly sequential, and the output is the approved SRS that serves as the basis for design and testing.

Principles of agile development (from the Agile Manifesto)

• Customer involvement – customers are closely engaged, providing and prioritising requirements and evaluating each iteration.
• Embrace change – expect requirements to change and design the system so that change is accommodated.
• Incremental delivery – software is developed in small increments, each delivering working functionality, with the customer specifying the content.
• Maintain simplicity – keep both the software and the process simple, and actively remove complexity.
• People, not process – trust the skills of the team and let them work in their own way, without prescriptive processes.

Agile development techniques

• User stories – requirements written as short scenarios ("As a student I want to..."), which are prioritised and broken into tasks.
• Extreme Programming (XP) practices – pair programming (two developers on one machine), test-first development with automated unit tests, continuous integration, refactoring, collective ownership, small releases, a sustainable pace, and an on-site customer.
• Scrum – work is done in fixed-length sprints (2–4 weeks) from a prioritised product backlog; roles are Product Owner, Scrum Master and Team; events are sprint planning, daily scrum, sprint review and retrospective.
• Refactoring – continuously improving code structure without changing behaviour.
• Test-driven development – writing the test before the code.

These techniques give rapid delivery of useful software and are best suited to small and medium projects with changing requirements.

1. System engineering

System engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining a socio-technical system as a whole, not just its software. A system includes hardware, software, people, procedures and the operating environment, so the engineer must consider all of them together.

Main stages: requirements definition (including overall system requirements), system design (partitioning requirements to hardware, software and people), subsystem development, system integration, system installation, and operation and evolution (maintenance, finally decommissioning). Emergent properties such as reliability, safety, security and performance depend on the interaction of all parts and can only be assessed for the whole system. Because several disciplines (software, electrical, mechanical, human factors) take part, the process needs close coordination and early agreement on interfaces.

2. Release testing

Release testing is the testing of a particular release of the system intended for use outside the development team, usually by customers. Its aim is to convince the supplier that the system is good enough for use – that it delivers the specified functionality, performance and dependability and does not fail during normal use.

• It is a black-box testing process: tests are derived from the system specification, without knowledge of the code, and often done by a separate testing team.
• It is a form of system testing, including requirements-based testing (each requirement has at least one test), scenario testing (realistic usage stories), and performance testing (load/stress until the system degrades).
• Differs from development testing, which is aimed at finding defects, whereas release testing is mainly validation.

Software testing

Software testing is the process of executing a program with the intent of showing that it does what it is intended to do (validation) and of discovering defects before it is put into use (defect testing). Testing can only show the presence of errors, never their absence. It is one part of the broader verification and validation (V&V) process.

The software testing process

1. Test planning – decide the scope, strategy, resources, schedule and the test environment; identify what is to be tested and the pass/fail criteria.
2. Test design – derive test cases (input plus expected output) using techniques such as equivalence partitioning, boundary value analysis, structural (white-box) coverage and requirements-based testing.
3. Test environment setup and test data preparation.
4. Test execution – run the tests, preferably automated, recording actual results.
5. Result analysis – compare actual against expected output; each mismatch is reported as a defect.
6. Defect fixing and re-testing – developers correct the fault; the failed tests are repeated and regression tests are run to ensure nothing else broke.
7. Test reporting and closure – summarise coverage, defects found and remaining risk.

Testing is staged: development testing (unit, component, system), release testing and user testing (alpha, beta, acceptance).

Development testing vs release testing

Test-Driven Development (TDD)

TDD is an approach in which tests are written before the code. The cycle is: (1) write a small automated test for a new piece of functionality; (2) run it and watch it fail; (3) write the minimum code to make it pass; (4) run all tests; (5) refactor, then repeat.

How it improves quality:

• Every piece of code is covered by at least one test, so code coverage is high.
• The developer must understand the requirement clearly first, which gives a better-defined interface and simpler design.
• The accumulated suite works as regression testing, so refactoring and changes are safe.
• Defects are found immediately, when they are cheapest to fix.
• The tests act as living documentation.

Example: for a isLeapYear(year) function, first write the test:

def test_leap():
    assert is_leap_year(2024) is True
    assert is_leap_year(1900) is False
    assert is_leap_year(2000) is True

It fails because the function does not exist. Then write the code:

def is_leap_year(y):
    return y % 4 == 0 and (y % 100 != 0 or y % 400 == 0)

The tests now pass; extra cases (e.g. 2023) are added and the code refactored with confidence.

Architectural design decisions

Architectural design is the creative process of identifying the sub-systems of a system and the framework for their control and communication. Since there is no single template, the architect answers a series of questions:

• Is there a generic application architecture that can act as a template for the system?
• How will the system be distributed across hardware cores/servers?
• Which architectural patterns or styles are appropriate?
• What approach will be used to structure the system (components, sub-systems)?
• How will the structural components be decomposed into sub-components?
• What strategy will be used to control the operation of the components?
• What architectural organisation is best for the non-functional requirements (performance, security, safety, availability, maintainability)?
• How will the architecture be documented and evaluated?

Trade-offs are inevitable: e.g. large-grained components improve performance but reduce maintainability; redundancy improves availability but raises cost; localised critical features improve security but hurt performance.

a) Model-View-Controller (MVC)

Separates the presentation and interaction from the system data. The system has three logical components:

• Model – manages data and business logic.
• View – defines and manages how data is presented to the user.
• Controller – manages user interaction (keys, mouse clicks) and passes it to the view and model.

   user input            updates
 User ----------> Controller ----------> Model
   ^                  |                    |
   |                  | selects            | state change
   |                  v                    | notification
   +------------- View <-------------------+
        displays

It is used when there are multiple ways to view and interact with the same data, as in web frameworks. Advantage: data can change independently of its representation. Disadvantage: extra code and complexity for simple models.

b) Client-Server

A distributed model where functionality is organised into services, each delivered from a separate server. Clients request services and use them. Components are servers, clients and a network.

 Client 1 \                 / Web server
 Client 2 --- Network ----- - File server
 Client 3 /                 \ Database server

Advantage: servers can be distributed and replicated; general functionality is available to many clients. Disadvantage: each service is a single point of failure, performance depends on network, and management of servers may be scattered.

c) Pipe and Filter

A data-processing system in which each processing step is a filter that transforms its input data and passes the output to the next filter through a pipe. Processing is data-driven and may be sequential or concurrent.

 Input --> [Filter A] --pipe--> [Filter B] --pipe--> [Filter C] --> Output

Used in compilers, batch data processing, UNIX shell pipelines, and payroll systems. Advantages: easy to understand, reuse of filters, simple to add transformations, supports concurrency. Disadvantages: a common data format must be agreed, and it is unsuitable for interactive systems.

Project management

Project management is the discipline of planning, organising, monitoring and controlling software projects so that the software is delivered on time, within budget and meeting the required quality. It is needed because software is intangible, flexible and often unique, and the project is always constrained by cost and schedule.

Project management activities

1. Project planning – decide what is to be done, the resources, the schedule, work breakdown into tasks and milestones, and produce the project plan.
2. Project scheduling – estimate the effort and time for each task (e.g. with COCOMO or expert judgement), assign people, define dependencies and draw bar charts / activity networks.
3. Cost estimation and budgeting – estimate effort, hardware and travel costs and the price to the customer.
4. Risk management – identify, analyse, plan for and monitor risks that could affect the project or product.
5. Staffing and people management – select and motivate the team, organise teamwork, communication and conflict resolution.
6. Project monitoring and reporting – compare progress with the plan, report to management and the customer, and take corrective action.
7. Quality management – set quality standards and ensure reviews and testing take place.
8. Configuration and change management – control versions of code and documents, and manage requested changes.
9. Proposal writing – the initial document that describes objectives and how they will be achieved.

Risk management process

Risk is the probability that an adverse circumstance will occur multiplied by its consequences. The process has four stages:

1. Risk identification – list possible project, product and business risks (e.g. staff turnover, requirements change, underestimated size, technology failure) using checklists and brainstorming.
2. Risk analysis – assess the probability (very low, low, moderate, high, very high) and the seriousness of consequences (insignificant, tolerable, serious, catastrophic) of each risk.
3. Risk planning – draw up avoidance strategies (reduce probability), minimisation strategies (reduce impact) and contingency plans (what to do if it happens).
4. Risk monitoring – regularly check the risks and the indicators, reassess them and update plans.

Example – a college information system project:

Risks are reviewed at each milestone and the register updated.

Requirements elicitation (also called requirements discovery) is the process of gathering information from stakeholders and other sources to find out what the system must do, what constraints apply and what the domain is. It is difficult because stakeholders often do not know exactly what they want, express requirements in their own terms, conflict with each other, and requirements change.

Elicitation techniques

• Interviews – formal or informal discussions with stakeholders. Closed interviews use a fixed list of questions; open interviews explore issues freely. They are good for the overall picture but poor at capturing domain knowledge that people take for granted.
• Ethnography / observation – the analyst observes people at work in their environment to understand actual practices; it finds implicit requirements not mentioned in interviews.
• Questionnaires and surveys – used to collect views from a large number of users cheaply.
• Scenarios and use cases – describe typical interactions with the system, which helps stakeholders relate to real situations and uncovers detail.
• User stories – short descriptions of a need, used in agile development.
• Prototyping – a quick working model is shown to users so they can react and clarify needs.
• Brainstorming and workshops (JAD) – group sessions to generate and agree on ideas.
• Document and existing-system analysis – study of manuals, forms, reports and current software.

In practice, a combination of techniques is used, and the output is then analysed, classified, prioritised and negotiated.

Given size = 320 KLOC.

(a) Organic mode

$E = 2.4\,(320)^{1.05}$

$\ln 320 = 5.7683$, so $320^{1.05} = e^{6.0567} \approx 426.98$.

$E = 2.4 \times 426.98 \approx 1024.8 \text{ person-months}$

$T = 2.5\,(E)^{0.38} = 2.5\,(1024.8)^{0.38}$

$1024.8^{0.38} = e^{0.38 \times 6.9321} = e^{2.6342} \approx 13.93$, hence

$T = 2.5 \times 13.93 \approx 34.8 \text{ months}$

Average staffing $= E/T = 1024.8/34.8 \approx 29$ persons.

(b) Embedded mode

$E = 3.6\,(320)^{1.20}$

$320^{1.20} = e^{1.2\times 5.7683} = e^{6.9220} \approx 1014.3$.

$E = 3.6 \times 1014.3 \approx 3651.6 \text{ person-months}$

$T = 2.5\,(E)^{0.32} = 2.5\,(3651.6)^{0.32}$

$3651.6^{0.32} = e^{0.32 \times 8.2029} = e^{2.6249} \approx 13.80$, hence

$T = 2.5 \times 13.80 \approx 34.5 \text{ months}$

Average staffing $\approx 3651.6/34.5 \approx 106$ persons.

The embedded project needs about 3.6 times the effort for the same duration because of its tight hardware and operational constraints.

Incremental development vs integration and configuration

Stages of integration and configuration: requirements specification, software discovery and evaluation, requirements refinement, application system configuration, and component adaptation and integration.

Suitability for large-scale enterprise systems

Large enterprise systems (ERP, banking, government) are best built by integration and configuration, often combined with incremental delivery. Reasons: these systems largely implement standard business processes already covered by mature products; reuse reduces development cost, risk and time to deploy; the components are already tested and proven reliable; and vendors provide support. Entirely custom incremental development of such a size would be slow and expensive. The drawbacks – loss of control and vendor dependency – are accepted and managed through careful selection of components and by writing custom code only for the specialised parts.

Assumptions: the actors are Customer, Restaurant, Delivery Rider and Payment Gateway; the admin manages the platform. Customers browse restaurants, order, pay online and track delivery.

Context model

A context model shows the system boundary and the external entities it interacts with.

 +----------+   order, payment details    +---------------------+   order request, status   +------------+
 | Customer | --------------------------> |                     | ------------------------> | Restaurant |
 |          | <-------------------------- |   Online Food       | <------------------------ |            |
 +----------+  confirmation, tracking     |   Delivery System   |   acceptance, menu update +------------+
                                          |                     |
 +----------+   delivery assignment       |                     |   payment request         +-----------------+
 |  Rider   | <-------------------------- |                     | ------------------------> | Payment Gateway |
 |          | --------------------------> |                     | <------------------------ |                 |
 +----------+  location, delivery status  +---------------------+   payment status          +-----------------+

Use case diagram

                        +-----------------------------------------------+
                        |        Online Food Delivery System            |
                        |                                               |
 +----------+           |   (Register / Login)                          |
 | Customer |-----------|   (Browse restaurants and menu)               |
 +----------+           |   (Place order)  ---<<include>>--> (Make payment)   ----- Payment Gateway
      |                 |   (Track order)                               |
      +-----------------|   (Rate and review)                           |
                        |                                               |
 +------------+         |   (Manage menu)                               |
 | Restaurant |---------|   (Accept / reject order)                     |
 +------------+         |   (Update order status)                       |
                        |                                               |
 +----------+           |   (Accept delivery)                           |
 |  Rider   |-----------|   (Update delivery location)                  |
 +----------+           |   (Confirm delivery)                          |
                        |                                               |
 +----------+           |   (Manage users and restaurants)              |
 |  Admin   |-----------|   (Generate reports)                          |
 +----------+           +-----------------------------------------------+

Relationships: Place order includes Make payment; Place order is extended by Apply coupon (optional). The Payment Gateway is a secondary (external system) actor.

Software quality management is the set of activities that ensures software meets its required level of quality: defining quality standards and procedures, applying them throughout the process, and checking that they are followed. It is concerned with both the product (reliability, usability, efficiency, maintainability) and the process used to develop it, and is organised independently of the project team.

Relationship between the three terms

• Quality management (QM) is the overall umbrella: setting the quality policy, objectives, standards, planning and responsibilities. It includes QA and QC.
• Quality assurance (QA) is process-oriented and preventive. It establishes the framework of organisational procedures and standards (e.g. coding standards, review procedures, ISO 9001) so that quality products result. QA asks "are we building the product right?".
• Quality control (QC) is product-oriented and detective. It applies the procedures to specific products: reviews, inspections, and testing to find defects in the actual deliverables. QC asks "did we build the right product, free of defects?".

 Quality Management
   |-- Quality Assurance : defines standards and processes (prevention)
   |-- Quality Control   : checks the products against them (detection)

Examples

• QM: the company decides that all projects must meet ISO 9001 and fewer than 1 defect per KLOC at release, and allocates a QA team.
• QA: defining a code-review checklist, a coding standard, and a requirement that every module pass a design review; auditing projects to see the process is followed.
• QC: running unit and system tests, conducting a code inspection of a module and recording defects found, and rejecting a build that fails the test suite.

Model-Driven Architecture (MDA)

MDA is a model-focused approach to software design and implementation, proposed by the OMG, in which models rather than programs are the main output of development. Programs are generated automatically from the models. It uses a series of models at different levels of abstraction:

• Computation Independent Model (CIM) – models the domain and system requirements without computational detail.
• Platform Independent Model (PIM) – models the operation of the system independent of any implementation platform, typically with UML structure and behaviour diagrams.
• Platform Specific Model (PSM) – a transformation of the PIM, one for each target platform (Java EE, .NET, etc.), with platform detail added.

Transformations between the models are automated by tools, ending in executable code.

How it helps in system modeling

• Separates the business logic from technology, so the same PIM can target different platforms.
• Gives a clear, standardised way to move from abstract requirements through design to code.
• Domain experts can contribute at the model level without programming knowledge.
• Models become the primary, always up-to-date documentation.

Advantages

• Platform independence and portability; easy migration when technology changes.
• Faster development and fewer coding errors because code is generated.
• Improved consistency and documentation; models can be reused.

Disadvantages

• Generated code needs expert tools which can be expensive; tools are immature for complex systems.
• Abstract models are not always the best way to express non-functional requirements such as performance.
• Savings are smaller for long-lived systems where implementation effort is mainly in testing and maintenance, and the transformation rules may not suit specific platforms.
• Requires skilled modelers and organisational change.

Implementation issues are the practical concerns, beyond programming itself, that affect how a design is turned into a working system and which are not usually covered in programming textbooks. Besides architecture and design, the implementation stage must deal with reuse, configuration management and host-target development, among others (open-source use, for instance).

1. Reuse

Modern software is built largely by reusing existing code. Reuse can be at several levels: the abstraction level (design patterns), object/function level (library components), component level (frameworks, packaged components) and system level (reusing a complete application). Reuse saves time and money and increases reliability since components are already tested, but it has costs: time to find and assess components, adaptation, licensing, and maintenance problems when the reused component changes.

2. Configuration management

Because many people change many versions of components, the changes must be managed. Configuration management (CM) covers:

• Version management – tracking the versions of each component and preventing developers from overwriting each other's changes (e.g. Git).
• System integration – defining which versions of components make up each system version and building it.
• Problem tracking – recording and tracing bug reports and their resolution.
• Release management – preparing software for external release and tracking the versions in use.

Tools such as Git, Subversion and Jenkins/Maven support CM and continuous integration.

3. Host-target development

Most software is developed on one computer (the host) and run on another (the target). The host has the development environment (IDE, compilers, debuggers, test tools), while the target may be different hardware – an embedded device or a mobile phone. Issues include: needing a simulator or emulator to test, cross-compilation, remote debugging, and differences in performance and environment. The development platform provides tools for editing, build, debugging and project support. For distributed systems, the target platform choice (and middleware) must be decided early and deployment planned.

Types of software maintenance

Which consumes the most resources?

Perfective maintenance consumes the most – typically around 50% or more of total maintenance effort (corrective about 20%, adaptive about 25%, preventive the least). The reason is that as software is used, users continually discover new needs and ask for new features, improvements and better performance, and business requirements keep evolving. Each enhancement requires understanding the existing code, changing design, coding, and complete regression testing, so the total effort is large. Since a system's useful life is long, these evolving requests accumulate over the years.

a) Open-source development

Open-source development is an approach in which the source code of a software system is made publicly available and volunteers are invited to participate in its development. Open-source software is released under licences (such as GPL, Apache, MIT) that permit use, study, modification and redistribution.

• Examples: Linux, Apache, MySQL, Firefox, Python.
• Licences: GNU GPL is a reciprocal licence – derived work must also be open; BSD/MIT are non-reciprocal and permit closed derivatives.
• Companies use open source by reusing components, or by releasing their own product as open source to gain community contributions, increase adoption and reduce development cost.
• Issues: legal compliance with licences, management of contributions by a core team, support for the product, and sustainability of the community.
• Advantages: low cost, transparency, rapid bug fixing through many reviewers, freedom from vendor lock-in. Disadvantages: uneven quality or documentation, limited formal support, security concerns for poorly maintained projects.

b) Agile project management

Agile project management applies the agile principles to planning and controlling a project. The standard approach is Scrum:

• Roles: Product Owner (represents the customer, maintains the backlog), Scrum Master (facilitates, removes obstacles) and a self-organising Development Team.
• Artifacts: product backlog (prioritised list of features), sprint backlog (items chosen for the sprint), and the potentially shippable product increment.
• Events: sprint (fixed 2-4 weeks), sprint planning, daily stand-up (15 minutes), sprint review with the customer, and sprint retrospective.

Features: short iterations with fixed time-boxes, incremental delivery, continuous customer feedback, team decision making, and progress shown with burn-down charts. Planning is done for the next iteration only, and the plan changes as understanding grows. It works well for small, co-located teams with changing requirements, but scaling to large or distributed teams and fixed-price contracts is difficult.