Software Engineering

Current trends in software engineering

• Agile and DevOps – short iterations, continuous integration and continuous delivery (CI/CD), close developer-operations collaboration.
• Cloud computing and cloud-native design – microservices, containers (Docker, Kubernetes), serverless.
• Artificial intelligence and machine learning – AI-assisted coding, automated testing, intelligent applications and MLOps.
• Low-code/no-code platforms – faster development by non-programmers.
• Mobile-first and cross-platform development – web apps, PWAs, Flutter/React Native.
• Security-first development (DevSecOps) – security built into every stage.
• Open-source and component reuse – reuse of libraries, APIs and frameworks.
• Big data, IoT and edge computing, and blockchain for specialised domains.
• Service-oriented and API-driven architecture.

Software as a Service (SaaS)

SaaS is a delivery model in which software is hosted centrally by a provider and accessed by users through a web browser or API, usually on subscription (examples: Gmail, Google Workspace, Salesforce, Zoom, Office 365).

Significance of SaaS

1. No installation or maintenance by the customer; updates are applied centrally and instantly.
2. Lower upfront cost – pay-as-you-go or subscription instead of buying licences and hardware.
3. Scalability and availability – resources scale with demand.
4. Accessibility – usable from any device and location.
5. Faster release cycles – one version to support, enabling continuous delivery and quick feedback.
6. Predictable revenue for vendors and easy integration through APIs.
7. Collaboration – shared data and real-time teamwork.

Challenges: dependence on internet connectivity, data security and privacy, vendor lock-in, limited customisation, and compliance with data-location laws.

SaaS is therefore a major trend because it changes software from a product into a continuously evolving service, shaping how modern software is built, tested, deployed and sold.

Project estimation technique

A project estimation technique is a systematic method of predicting the size, effort (person-months), duration and cost of a software project before or during development. Estimates support planning, scheduling, budgeting and bidding. Common techniques are:

• Expert judgment / Delphi – experts estimate and refine through rounds.
• Analogy – compare with similar past projects.
• Size-based (LOC, Function Points) – estimate size, then convert to effort.
• Algorithmic/parametric models – COCOMO, Putnam (SLIM).
• Work Breakdown Structure (bottom-up) – estimate each task and sum.

Basic COCOMO (Constructive Cost Model)

Proposed by Barry Boehm (1981), Basic COCOMO estimates effort and development time purely as a function of program size in KLOC (thousands of delivered lines of code). Projects are classified into three modes:

1. Organic – small teams, well-understood problem, familiar environment (e.g. payroll, inventory), size up to about 50 KLOC.
2. Semi-detached – mixed experience, intermediate complexity (e.g. compilers, database systems), about 50-300 KLOC.
3. Embedded – tight hardware, software and operational constraints (e.g. flight control, real-time systems), large size.

Equations

$E = a \,(KLOC)^b \quad \text{person-months}$

$D = c \,(E)^d \quad \text{months}$

$N = \frac{E}{D} \quad \text{(average staff)}$

Example. An organic project of 32 KLOC:

$E = 2.4 \times 32^{1.05} \approx 2.4 \times 38.05 \approx 91.3 \text{ PM}$

$D = 2.5 \times 91.3^{0.38} \approx 2.5 \times 5.56 \approx 13.9 \text{ months}$

$N = 91.3 / 13.9 \approx 6.6 \text{ persons}$

Merits: simple, quick, repeatable, good for early rough estimates. Limitations: depends on an accurate KLOC estimate, ignores cost drivers such as team capability, tools and reliability (handled by Intermediate and Detailed COCOMO), and is calibrated on old data.

Software safety is a software quality assurance activity that focuses on identifying and assessing potential hazards that may affect software negatively and cause an entire system to fail. Many systems (aircraft, medical devices, nuclear plants, railway control) are safety-critical: software failure can cause injury, loss of life or environmental damage.

Approach

1. Identify hazards early using hazard analysis techniques (fault tree analysis, FMEA).
2. Classify hazards by severity and probability (catastrophic, critical, marginal, negligible).
3. If hazards are software-related, specify safety requirements and design features to eliminate or control them (interlocks, redundancy, fail-safe design, exception handling, watchdog timers).
4. Verify with reviews, testing and model checking.

Fault tree analysis starts with an undesirable event and works backward to find causes, using logic gates (AND/OR), to see which combinations lead to the hazard.

Distinction: software reliability concerns failures in general, while safety concerns only failures that lead to mishaps; a reliable system may be unsafe, and a safe system may be unreliable.

CORBA (Common Object Request Broker Architecture) is a standard defined by the Object Management Group (OMG) that enables software components written in different languages and running on different machines to communicate as if they were local objects. It is a middleware for distributed object-oriented systems.

Main components

• ORB (Object Request Broker) – core that locates objects, delivers requests and returns results transparently.
• IDL (Interface Definition Language) – language-neutral definition of object interfaces; compiled into client stubs and server skeletons in languages such as C++, Java or Python.
• GIOP/IIOP – protocol for ORB-to-ORB communication over TCP/IP.
• Object services – naming, event, transaction, security and life-cycle services.
• Common facilities and application objects.

Working: the client invokes a method on a stub, the ORB marshals the request across the network to the server's skeleton, which calls the implementation and returns the result.

Advantages: language and platform independence, location transparency, reusability and interoperability. Disadvantages: complex, heavy, specification differences between vendors; largely replaced by web services and REST.

Software engineering ethics

Software engineers have wide influence on people, so their work must follow ethical and professional responsibility beyond the law. The ACM/IEEE Software Engineering Code of Ethics lists eight principles:

1. Public: act consistently with the public interest.
2. Client and employer: act in the best interests of client and employer, consistent with the public interest.
3. Product: ensure that products meet the highest professional standards.
4. Judgment: keep integrity and independence in professional judgment.
5. Management: managers promote an ethical approach to development and maintenance.
6. Profession: advance the integrity and reputation of the profession.
7. Colleagues: be fair and supportive to colleagues.
8. Self: take part in lifelong learning and promote an ethical approach to practice.

Main ethical issues: confidentiality of client data, competence (not accepting work beyond one's ability), respect for intellectual property and copyright, and no misuse of computers (viruses, unauthorised access). Ethical dilemmas arise when a developer disagrees with a decision of the employer, for example on safety or privacy.

Hierarchy of software testing

Software testing is organised hierarchically, from the smallest unit up to the whole system and then the user:

1. Unit testing – individual functions, classes or modules.
2. Integration testing – groups of modules and their interfaces.
3. System testing – the complete, integrated system against requirements (functional and non-functional).
4. Acceptance testing – the customer validates the system (alpha, beta, user acceptance).

Each lower level must be reasonably stable before the next level begins, giving the V-model correspondence: unit testing verifies detailed design, integration testing verifies architectural design, system testing verifies requirements specification, and acceptance testing validates user needs.

Relationship between levels and hierarchy

Yes, they are the same idea seen from two views. The levels of testing (unit, integration, system, acceptance) form the hierarchy: the scope of the test grows and the viewpoint moves from the programmer to the user at each step. Lower levels are mainly white-box, higher levels mainly black-box. A defect not found at a lower level is more expensive to find at a higher one, so the hierarchy ensures bugs are caught progressively and early. Types of testing such as regression, performance or security cut across the levels.

Levels of testing

Testing is performed at several levels, each with a different scope:

1. Unit testing – tests each module, function or class separately, mostly by the developer using white-box methods and stubs/drivers.
2. Integration testing – tests the interfaces and interaction among integrated modules (top-down, bottom-up, sandwich, big-bang).
3. System testing – tests the complete integrated system against the specified requirements, including performance, security, recovery and stress.
4. Acceptance testing – done by the customer to decide whether the system is acceptable; alpha and beta testing.

Relationship with types of testing

Levels answer "what is being tested" (scope), while types answer "how or why it is tested" (technique or objective): white box, black box, functional, regression, performance, load, stress, security, usability. Types are applied across levels:

• White-box testing is chiefly used at unit and integration level.
• Black-box functional testing is used at system and acceptance levels.
• Regression testing is repeated at every level after a change.
• Performance, stress and security testing belong mostly to system level.
• Usability and alpha/beta testing belong to acceptance level.

So the two dimensions are related but not the same: each level selects suitable types, and one type may appear at several levels.

Agile methods

Agile is a family of iterative and incremental software development approaches based on the Agile Manifesto (2001). They value:

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

Software is delivered in short iterations (1-4 weeks) with continuous customer feedback, so requirements can change late in development. Examples include Scrum, Kanban, XP and Crystal.

Extreme Programming (XP)

XP is the Agile method that focuses on engineering practices and high-quality code. It fits Agile because it implements the manifesto values directly:

• Small releases and iterations: working software is delivered frequently.
• Planning game: customer stories are chosen and estimated each iteration (customer collaboration).
• User stories: lightweight requirements instead of heavy documents.
• Pair programming: two developers work at one machine, giving continuous review.
• Test-driven development and continuous integration: tests are written first and the code is integrated several times a day.
• Refactoring and simple design: the design is improved continuously to accommodate change.
• Collective code ownership, coding standards, sustainable pace, on-site customer.

XP's values of communication, simplicity, feedback, courage and respect support Agile's emphasis on adaptability. It is best suited to small teams with changing requirements.

Design patterns

A design pattern is a general, reusable solution to a commonly occurring problem in software design. It is a template, not finished code, that records proven practice. Patterns (popularised by the Gang of Four) are grouped as creational, structural and behavioural. They improve reuse, maintainability and shared vocabulary among developers.

1. Singleton (creational)

Ensures a class has only one instance and gives a global access point to it.

class Logger {
    private static Logger instance;
    private Logger() {}
    public static Logger getInstance() {
        if (instance == null) instance = new Logger();
        return instance;
    }
}

Examples: logger, configuration manager, database connection pool.

2. Factory (creational)

Defines an interface for creating objects, letting a factory method decide which concrete class to instantiate, so client code does not depend on concrete classes.

interface Shape { void draw(); }
class Circle implements Shape { public void draw(){ System.out.println("Circle"); } }
class Square implements Shape { public void draw(){ System.out.println("Square"); } }
class ShapeFactory {
    static Shape create(String type) {
        if (type.equals("circle")) return new Circle();
        return new Square();
    }
}
// Shape s = ShapeFactory.create("circle");

3. Observer (behavioural)

Defines a one-to-many dependency: when a subject changes state, all its registered observers are notified and updated automatically.

interface Observer { void update(String news); }
class NewsAgency {
    private java.util.List<Observer> list = new java.util.ArrayList<>();
    void subscribe(Observer o) { list.add(o); }
    void publish(String news) { for (Observer o : list) o.update(news); }
}

Examples: event handling in GUIs, newsletter subscription, model-view in MVC.

Encapsulation

Binding data (attributes) and the methods that operate on it into a single unit (class) and hiding the internal state behind access modifiers (private data with public getters and setters). Example: a BankAccount class keeps balance private and changes it only through deposit() and withdraw().

Inheritance

A mechanism by which a subclass acquires the attributes and behaviour of a superclass, forming an "is-a" hierarchy. Example: Savings and Current accounts inherit from Account, adding their own features.

Polymorphism

The ability of one interface or method name to take many forms: overloading (compile time) and overriding (run time). Example: calculateInterest() behaves differently for Savings and Current objects, though called through an Account reference.

Significance in OOAD

• Encapsulation: gives information hiding and modularity, reduces coupling, protects data integrity, and lets the implementation change without affecting users of the class.
• Inheritance: models generalisation/specialisation seen in analysis and class diagrams, promotes reuse and removes duplicated code.
• Polymorphism: allows flexible, extensible designs where new subclasses can be added without changing existing code (open/closed principle), and supports design patterns.

Together they make object-oriented systems modular, reusable, maintainable and closer to real-world models.

Importance of code readability

Code is read far more often than it is written, so readable code:

• makes maintenance and modification easier and cheaper, as most software cost lies in maintenance;
• lowers the chance of bugs and makes debugging and code review faster;
• helps team collaboration and quick onboarding of new developers;
• improves reusability and long-term quality;
• reduces dependency on the original author.

Techniques to improve readability

1. Meaningful names for variables, functions and classes (totalMarks, not x).
2. Consistent coding standards and formatting: indentation, spacing, brace style.
3. Small, single-purpose functions and avoiding deeply nested logic.
4. Useful comments and documentation explaining why, not what; avoid obvious comments.
5. Avoid magic numbers; use named constants.
6. Remove duplication (DRY) and dead code; refactor regularly.
7. Modular design with clear separation of concerns.
8. Code reviews and linters/formatters to enforce style.
9. Keep lines and files reasonably short and group related code logically.

Software engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, i.e. engineering applied to software (IEEE definition). It covers all aspects of software production from specification through to maintenance, with the aim of producing high-quality software on time and within budget.

Attributes of good software

1. Maintainability: the software can be modified to meet changing customer needs, since change is inevitable.
2. Dependability and security: it must be reliable, safe and secure, and must not cause physical or economic damage on failure; malicious users must not be able to access or damage it.
3. Efficiency: it should not waste system resources such as memory and processor cycles; it covers response time, throughput and memory utilisation.
4. Acceptability (usability): it must be understandable, usable and compatible with the systems its users already use, so that users accept it.
5. Correctness / functionality: it does what its specification requires.
6. Portability and reusability: it can run in different environments, and its components can be reused.

Example: a banking application must be dependable (no loss of transactions), efficient (fast response), maintainable (easy to add new rules) and usable by bank staff.

Requirement

A requirement is a description of what a system should do, the services it provides and the constraints on its operation. It reflects the needs of customers for a system that serves a certain purpose. Requirements engineering is the process of finding out, analysing, documenting and checking these.

Functional vs non-functional requirements

Both are essential: functional requirements define the system's features, and non-functional requirements decide whether the system is actually usable and acceptable.

Examples

• Verification: Inspecting the SRS and design of an online shopping system to confirm that every stated requirement (cart, payment, order tracking) is covered, or code-reviewing a module against the design.
• Validation: Running the shopping system with real users in user acceptance testing to see whether they can search, order and pay as they expect, or executing test cases to check a login actually works.

Both are needed: verification ensures correct construction, validation ensures the result is what the user wanted.

Software maintenance is the modification of a software product after delivery to correct faults, improve performance or adapt it to a changed environment. It is essential because software never stays static after release, and in most systems maintenance consumes 60-70% of the total life-cycle cost.

Why it is essential, with types and examples

1. Corrective maintenance: fixing bugs found after delivery. Example: correcting a wrong interest calculation in a banking app.
2. Adaptive maintenance: changing the software to work in a new environment. Example: updating a mobile app for a new Android version or a new payment gateway.
3. Perfective maintenance: adding features or improving performance and usability on user request. Example: adding a fingerprint login or faster search to an existing app.
4. Preventive maintenance: restructuring or refactoring to avoid future problems and make the code easier to maintain. Example: refactoring legacy code to reduce complexity.

Further reasons

• Business needs, laws and regulations change (for example a VAT rate change).
• Hardware, operating systems and technologies become obsolete.
• Users find new requirements only by using the software.
• Without maintenance, software quality and reliability decay (Lehman's laws of software evolution), and the system loses value.

Hence maintenance keeps software useful, reliable and competitive throughout its life, making it an essential SDLC phase.

Use case diagram: Hostel Management System

 +---------------------------------------------------------------+
 |                 Hostel Management System                       |
 |                                                                |
 |   (Register / Apply for Room) <-----------------+            |
 |   (View Room Availability)                       |            |
 |   (Pay Fee) ---------------------------------+   |            |
 |   (Room Allocation) --<<include>>--> (Check Availability)     |
 |   (Manage Students)         (Room Allocation) <<extend>>      |
 |   (Manage Rooms)             (Change/Cancel Allocation)       |
 |   (Generate Reports)                                           |
 +---------------------------------------------------------------+
   Student ---> Apply for Room, View Availability, Pay Fee
   Warden/Admin ---> Room Allocation, Manage Students, Manage Rooms, Reports
   Accountant ---> Pay Fee verification

Actors: Student, Warden/Admin, Accountant. Main use cases: Apply for Room, View Room Availability, Room Allocation, Pay Fee, Manage Students, Manage Rooms, Generate Reports. "Room Allocation" <<include>> "Check Availability" and <<include>> "Verify Fee Payment"; "Change Room" <<extend>> "Room Allocation".

Use case description: Room Allocation

Main flow

1. The warden opens the list of pending room applications.
2. The warden selects a student's application.
3. The system verifies the student's fee payment and eligibility.
4. The system displays vacant rooms matching the student's preference.
5. The warden selects a room and bed.
6. The system records the allocation, updates the room occupancy and the student record.
7. The system generates an allocation slip and notifies the student.

Alternative flows

• 3a. Fee unpaid: the system rejects the request and asks for payment.
• 4a. No vacant room: the application is placed on a waiting list.

Postconditions: The room is marked occupied (or its occupancy count increased) and the student is linked to the room.

A sequence diagram shows the interactions between objects in time order. Participants: Passenger, UI (Booking Page), Booking Controller, Train Database, Payment Gateway.

Passenger     UI          BookingController     TrainDB       PaymentGateway
   |  search(from,to,date)  |                        |             |
   |----------->|           |                        |             |
   |            | findTrains(from,to,date)           |             |
   |            |---------->|                        |             |
   |            |           | queryTrains()          |             |
   |            |           |----------------------->|             |
   |            |           |<--- train list --------|             |
   |            |<-- list --|                        |             |
   |<-- show trains --------|                        |             |
   | select train, class, seats                      |             |
   |----------->| checkAvailability()                |             |
   |            |---------->| getSeats()             |             |
   |            |           |----------------------->|             |
   |            |           |<-- seats available ----|             |
   |<-- seat map/fare ------|                        |             |
   | enter details & confirm|                        |             |
   |----------->| bookTicket(details)                |             |
   |            |---------->| holdSeats()            |             |
   |            |           |----------------------->|             |
   |            |           | makePayment(amount)                  |
   |            |           |------------------------------------->|
   |            |           |<--------- payment success -----------|
   |            |           | confirmBooking(), save PNR           |
   |            |           |----------------------->|             |
   |            |<-- ticket/PNR --------|             |             |
   |<-- e-ticket shown + SMS/email -----|             |             |

Explanation

1. The passenger enters source, destination and date; the UI asks the controller, which queries the train database and returns the list of trains.
2. The passenger selects a train and class; the controller checks seat availability in the database and returns the seat map and fare.
3. The passenger confirms the passenger details; the controller temporarily holds the seats.
4. The controller calls the payment gateway; on success it confirms the booking, stores the ticket and generates a PNR.
5. The UI shows the e-ticket and sends an SMS or email confirmation.

Alternative (alt fragment): if no seats are available or the payment fails, the seats are released and an error message or waiting-list option is returned to the passenger.

Software Quality Assurance (SQA)

SQA is a set of planned and systematic activities applied throughout the software process to ensure that the software and its processes conform to the specified requirements and standards. It includes standards and procedures, reviews and audits, testing, defect and change control, and measurement and reporting. It is process-oriented and aims at preventing defects.

Importance of SQA

• Improves product quality and customer satisfaction.
• Detects defects early, which reduces the cost of rework and maintenance.
• Increases reliability and reduces risk of failure.
• Ensures compliance with standards, contracts and regulations.
• Provides management with visibility of the project's progress and quality.
• Improves the development process continuously.

Quality standards

1. ISO 9001 (and ISO/IEC 90003): A general quality management system standard. An organisation must define documented processes, focus on the customer, perform internal audits and take corrective actions for continuous improvement. ISO/IEC 90003 applies it to software.
2. CMMI (Capability Maturity Model Integration): A process improvement model that rates an organisation on five maturity levels: Initial, Managed, Defined, Quantitatively Managed and Optimising. Each level adds more disciplined and measured process areas such as requirements management, project planning and risk management.

(Other examples: ISO/IEC 25010 for product quality, IEEE standards.)

Verification

Verification checks that the software is built correctly according to its specification and design ("Are we building the product right?"). It uses static techniques such as reviews, walkthroughs, inspections and static analysis, without running the code.

Validation

Validation checks that the finished software satisfies the user's real needs and intended use ("Are we building the right product?"). It uses dynamic techniques: executing the software through unit, integration, system and acceptance testing, including beta testing with real users.

How they ensure reliability

Reliability is the probability of failure-free operation for a specified time in a specified environment. V&V contribute as follows:

1. Early defect removal: Reviews of requirements and design find errors before they reach code, so fewer faults exist in the final product.
2. Fault detection through testing: Execution against test cases exposes failures, which are fixed, and re-tested (regression testing), raising the failure-free time.
3. Conformance to specification: Verified code matches requirements, avoiding failures due to misunderstood or missing functions.
4. Operational profile testing: Validation using realistic usage scenarios measures reliability (for example MTBF, failure rate) and shows if the target is met.
5. Confidence and measurement: Defect density and failure data feed reliability growth models, and release is decided on a reliability target.

Thus verification prevents faults and validation removes remaining ones, together delivering dependable software.

Spiral model: A risk-driven, evolutionary model proposed by Boehm. The project passes repeatedly through four quadrants: determine objectives, identify and resolve risks (with prototyping), develop and test, and plan the next loop. Each loop produces a more complete version.

Incremental model: The requirements are partitioned and the system is built, tested and delivered in successive increments, each adding functionality; the first increment is the core product.

More adaptable to changing requirements

The Spiral model is more adaptable. Requirements are re-examined and prototypes evaluated in every loop, and risk analysis explicitly considers changing or unclear requirements. The Incremental model also copes with change in later increments, but its overall architecture and the scope of the core increment are fixed early, so major changes are harder.

Software re-engineering

Software re-engineering is the examination, analysis and restructuring of an existing (legacy) system to reconstitute it in a new, more maintainable form without changing its functionality. It is used when a system is still valuable but costly to maintain.

Main activities: inventory analysis, document restructuring, reverse engineering (recovering design from code), code restructuring, data restructuring and forward engineering (rebuilding with modern design or technology). Example: converting a COBOL billing system into a Java web application.

Version control and software evolution

Software evolves through many changes. A version control system such as Git records every change, which helps in:

• History and traceability: every commit stores who changed what and why, so any earlier version can be retrieved or compared (git log, git diff).
• Branching and merging: features, fixes and experiments are developed in parallel branches (git branch, git merge) without disturbing stable code.
• Collaboration: many developers work on the same project through remote repositories (git push, git pull), with pull requests and code review.
• Rollback and recovery: faulty changes can be undone (git revert, git reset).
• Release management: tags mark released versions, supporting multiple maintained versions.
• Configuration management: it controls changes systematically, supporting re-engineering by making restructuring safe and reversible.

Thus version control gives disciplined, safe management of software as it evolves.

The RMMM plan (Risk Mitigation, Monitoring and Management) is a document, either part of the project plan or a separate set of risk information sheets, that records how project risks are handled.

• Risk Mitigation: steps taken to reduce the probability or impact of a risk before it occurs. Example: for high staff turnover, document work well, assign backup staff and cross-train team members.
• Risk Monitoring: tracking the project to see whether the risk is becoming more likely, watching risk indicators and assessing whether the mitigation is working. Example: watching team morale and absenteeism.
• Risk Management (contingency planning): actions taken after the risk has become real, to limit its damage. Example: use the backup staff and reassign tasks.

For each risk the plan records its description, probability, impact, mitigation steps, monitoring factors and contingency plan, with the owner. Preparing an RMMM plan is useful, but an extensive RMMM costs effort; it should be proportional to the risk exposure, which is highest for risks with high probability and high impact.

Human Computer Interaction (HCI) is the study of how people interact with computer systems and the design of interfaces that are usable, efficient and satisfying. It combines computer science, psychology, design and ergonomics.

Goals: usability, safety, utility, efficiency, learnability and user satisfaction.

Design principles

• Consistency of terminology, layout and actions.
• Visibility of system status and immediate feedback.
• Error prevention, with clear messages and easy recovery (undo).
• Minimal memory load: recognition rather than recall.
• Shortcuts for expert users and simplicity for novices.
• Aesthetic and minimalist design (Shneiderman's eight golden rules; Nielsen's heuristics).

Interface types: command line, menu-driven, graphical (GUI), touch, voice and gesture interfaces.

Process: user and task analysis, prototyping, usability evaluation and iteration.

Importance: A good interface reduces errors, training time and cost, and increases productivity and acceptance of the software.

A class diagram is a UML structural diagram showing the classes of a system, their attributes and operations, and the relationships between them. It is the main static model used in object-oriented analysis and design.

Class notation: a rectangle with three compartments: class name, attributes and operations. Visibility symbols: + public, - private, # protected.

+-------------------+
|     Student       |
+-------------------+
| - id : int        |
| - name : String   |
+-------------------+
| + enroll(c:Course)|
| + getName()       |
+-------------------+

Relationships

• Association: a plain line, with multiplicity (for example one Teacher teaches many Students: 1..*).
• Aggregation: "has-a", whole-part where the part can exist alone (hollow diamond).
• Composition: strong whole-part where the part cannot exist without the whole (filled diamond).
• Generalisation (inheritance): a hollow-triangle arrow from subclass to superclass.
• Dependency: dashed arrow showing one class uses another.
• Realisation: dashed line with hollow triangle from a class to an interface.

Uses: modelling the domain and design, forward and reverse engineering, and communication among developers.

Software engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. It aims to produce reliable, high-quality software economically and on schedule.

Key differences between Software Engineering and System Engineering

Five attributes of good software

1. Maintainability: easy to modify as needs change. Example: adding a new tax rule to payroll software with small changes.
2. Dependability and security: reliable and safe, and protects against misuse. Example: a banking app that never loses a transaction and resists hacking.
3. Efficiency: uses processor, memory and time sparingly. Example: a search engine returning results in milliseconds.
4. Acceptability / usability: understandable, usable and compatible with the user's environment. Example: a mobile wallet with simple screens that users adopt readily.
5. Portability and correctness: works on different platforms and does what the specification requires. Example: a web app running on Chrome, Firefox and mobile browsers.

Software specification

Software specification (requirements engineering) is the process of establishing what services are required from the system and the constraints on its operation and development. Its stages are feasibility study, requirements elicitation and analysis, requirements specification (writing the SRS) and requirements validation. The output is the Software Requirements Specification (SRS).

Using UML diagrams to represent behaviour

UML behavioural diagrams model what the system does.

1. Use case diagram: shows the system's functionality from the user's viewpoint. It consists of actors (users or external systems), use cases (ellipses for functions) and relationships (association, <<include>>, <<extend>>). It captures the functional requirements and system boundary. Example: in an online shop, the Customer actor has use cases Search Product, Place Order and Make Payment.
2. State diagram (state machine): shows the states of one object and the events that cause transitions between them, with start and end states and guard conditions. It specifies the life cycle behaviour of an object. Example: an Order moves Placed, Paid, Shipped, Delivered or Cancelled.
3. Activity diagram: a flowchart-like diagram showing the flow of activities in a process, with actions, decisions, forks/joins (parallel activities) and swimlanes for responsibility. It models a use case's workflow or business process. Example: the order process from checking stock to payment and dispatch.

Together, they give a clear, visual and unambiguous description of the required behaviour, from external functions (use case) to object states and process flow, helping communication between customers and developers.

Software testing

Software testing is the process of executing a program with the intent of finding errors and checking that it meets the specified requirements. It shows the presence of defects, not their absence, and evaluates quality.

Levels of testing

1. Unit testing: tests the smallest units (functions, methods, classes) in isolation, usually by developers with white-box techniques. Example: testing that a calculateTax() function returns the right value for various inputs.
2. Integration testing: tests the interfaces and interactions between combined modules (top-down, bottom-up, big-bang). Example: checking that the Order module passes the right data to the Payment module.
3. System testing: tests the complete integrated system against the SRS for functional and non-functional behaviour (performance, security, load). Example: testing the whole e-commerce site from login to checkout on a test server.
4. Acceptance testing: the customer or user checks whether the system meets business needs and can be accepted, as alpha testing (at the developer's site) and beta testing (at the user's site). Example: bank staff running real daily transactions on the new software before approval.
5. Regression testing: re-running earlier tests after a change to make sure that modifications have not broken existing functionality. Example: after fixing a bug in the discount feature, re-testing cart and billing.

(Other levels: smoke, performance and security testing.)

Test case

A test case is a set of test inputs, execution conditions and expected results developed for a particular objective, such as exercising a program path or verifying compliance with a requirement. A test case typically has an ID, description, preconditions, input data, steps, expected result, actual result and pass/fail status.

Example: Login test. Input: username ram, password wrong; expected result: error "Invalid password"; no access granted.

Black box vs white box testing

Examples

• Black box: for an age field accepting 18-60, test 17, 18, 60 and 61 (boundary values) and check only the accepted or rejected output.
• White box: for if (a > b) max = a; else max = b; design tests so that both branches execute (for example a=5,b=3 and a=2,b=7) to get 100% branch coverage.

Defect amplification

Defect amplification is the phenomenon in which an error introduced in one development step passes into the next step and is multiplied (amplified), because each new step builds on the defective work and adds its own new errors. Thus an undetected design error can produce several coding errors. The later a defect is found, the more it costs to fix.

Defect amplification model (each stage of development)

              Defects from previous step
                        |
          +-------------v--------------+
          |   Development step         |
          |  +----------+              |
 Errors   |  | Defects  |-> Passed through (not detected)  --->
 passed   |  | amplified|-> Amplified defects (x factor)   --->  To next step
 through->|  +----------+              |
          |  Newly generated defects --+--->
          |  Percent efficiency of     |
          |  error detection (review)--+---> Defects detected and removed
          +----------------------------+

Each step receives defects from the previous step, passes some through unchanged, amplifies some, and adds newly generated ones; the review/testing at that step detects and removes a percentage of them, given by its error detection efficiency.

Defect removal

Defect removal is the set of activities (reviews, inspections, walkthroughs, testing) that find and eliminate defects at each stage before they reach the next stage.

How reviews reduce errors

• They detect defects early (requirements, design) when the cost of removal is lowest.
• Detection at each step stops errors from propagating, so amplification is reduced.
• They are able to find 50-90% of errors before testing begins.
• Example: with no review, 10 requirement errors might amplify to 30 design errors and 90 code errors; a review with 70% efficiency at each step cuts the defects passed on to a small fraction.
• Reviews also improve team understanding, adherence to standards and the overall quality and reliability of the product, and reduce rework, cost and schedule.

Reliability

Software reliability is the probability of failure-free operation of a program for a specified time in a specified environment. It is measured by Mean Time Between Failures:

$MTBF = MTTF + MTTR$

where MTTF is the mean time to failure and MTTR is the mean time to repair.

Availability

Availability is the probability that the system is operating and available when needed at a given instant:

$\text{Availability}=\frac{MTTF}{MTTF+MTTR}\times100\%$

Relationship

1. Dependence: Availability depends on reliability (MTTF) and on maintainability (MTTR). A system is available only if it is not failing and can be quickly repaired.
2. Reliability alone is not enough: A system may fail rarely (high reliability) but if each repair takes a long time, availability is low. Conversely, a system that fails often but recovers in seconds can still have high availability.
3. Improving reliability (larger MTTF) raises availability; reducing repair time (smaller MTTR) also raises availability even if reliability is unchanged.
4. Example: with MTTF = 999 hours and MTTR = 1 hour, availability $=\frac{999}{1000}=99.9\%$; if MTTR rises to 10 hours, availability falls to $\frac{999}{1009}\approx99.0\%$ though reliability is unchanged.
5. Interdependence among components: In a system of components, the failure of one interdependent component can reduce the reliability of the whole. For series components, system reliability is $R=R_1R_2\cdots R_n$ (always less than the weakest component), while redundancy (parallel components) $R=1-(1-R_1)(1-R_2)$ raises both reliability and availability.
6. Both are dependability attributes: along with safety and security, they decide the dependability of the system, and improving one often requires cost trade-offs with another.

Hence reliability concerns how long the system works between failures, availability concerns how much time it is usable, and the two are linked through failure rate and repair time.

Object-oriented concepts can be applied to project management by treating the project as a collection of cooperating objects, which improves modularity, reuse and control.

Key OOP concepts and their project-management meaning

• Object – a self-contained entity with data and behaviour. In a project: a Task, Resource, Milestone, Risk, Team member or Deliverable, each with attributes (name, start date, cost) and operations (assign, update, complete).
• Class – a template for similar objects, e.g. a Task class from which all tasks are created; standard templates for plans, reports and reviews.
• Encapsulation – each object hides its internal details and exposes a defined interface; teams/modules work independently and changes stay local.
• Inheritance – specialised classes reuse general ones, e.g. DevelopmentTask and TestingTask inherit from Task; project plans and checklists are reused across projects.
• Polymorphism – the same operation behaves differently by object type, e.g. estimateEffort() for coding, testing or documentation tasks.
• Abstraction – managers view the project at a high level (work packages) without every detail.
• Association/aggregation – a Project is composed of Phases; Tasks use Resources.

Benefits: better organisation of work breakdown, reuse of plans, easier change management, clearer responsibilities, tracking and estimation per object, and natural fit with object-oriented development (incremental, iterative models).

Alpha testing is acceptance testing performed by internal staff or selected users at the developer's site in a controlled environment, before the product is released outside. Beta testing is performed by real end users at their own site in the real environment, on a nearly final version, before general release.

Alpha testing

Advantages: finds major bugs early; developers can observe and reproduce failures directly; controlled setup; reduces risk before exposing the product to customers. Disadvantages: limited real-world conditions; testers know the product well so may miss usability issues; time-consuming and cannot cover all use scenarios.

Beta testing

Advantages: tests under real conditions and varied hardware/software; genuine user feedback on usability and requirements; reduces product failure risk after release; improves customer satisfaction. Disadvantages: no control over the environment or testers; bugs are harder to reproduce; feedback may be late, inconsistent or incomplete; releasing an immature product may harm reputation.

Proof of correctness in Cleanroom Software Engineering

Cleanroom software engineering aims at defect prevention rather than defect removal. In the Cleanroom, correctness of each component is demonstrated by formal reasoning during correctness verification rather than by executing the code. Each program's specification is written as a function or box structure (black box, state box, clear box), and the design is refined step by step. For every control structure (sequence, selection, iteration) the team applies correctness questions and proves that the code implements its specification:

• Sequence: do the statements in order together achieve the specified function?
• Selection (if/else): does each branch, under its condition, produce the specified result and cover all cases?
• Iteration (loop): does the loop terminate, is the initial condition correct, does each pass keep the invariant, and does the exit state give the required result?

The proof is carried out by the developers as a team review (structured, mathematically based inspection). Programs are not unit tested by developers; only statistical usage testing is done by an independent team.

Difference from traditional defect detection

Software configuration management (SCM) is the discipline of identifying, organising and controlling changes to software work products throughout the life cycle.

Why SCM is needed

• Software changes continuously; uncontrolled changes cause chaos and defects.
• Many people work on the same files; SCM avoids overwriting and conflicts.
• It maintains multiple versions and releases and allows rollback.
• It ensures integrity, traceability and consistency among requirements, design, code and tests.
• It improves productivity, quality and accountability, and reduces cost of change.

SCM activities

1. Configuration identification – identify and name the configuration items (documents, source code, test data) and their versions, and set baselines.
2. Version control – manage different versions of items using a repository, check-in/check-out, branching and merging (e.g. Git).
3. Change control – a formal process: a change request is submitted, evaluated for impact and cost, approved or rejected by the Change Control Board, implemented, and verified.
4. Configuration auditing (status verification) – checks that the change was properly made, that the item matches its baseline, and that standard procedures were followed (formal technical review and configuration audit).
5. Configuration status reporting – records and reports what changed, who changed it, when, and what else is affected.
6. Build and release management – constructs the software from the right versions and manages deliveries.

Good software is judged not only by what it does but by its quality attributes. The essential attributes are:

• Maintainability – easy to modify to meet changing needs; written and documented clearly.
• Dependability and security – reliable, safe and secure; does not cause damage on failure and resists malicious attacks.
• Efficiency – uses memory, processor time and other resources economically, with good response time.
• Acceptability (usability) – understandable, usable and compatible with the systems its users already use.
• Correctness – meets its specification and user requirements.
• Portability and reusability – works on different platforms and its components can be reused.
• Testability and robustness – easy to test and handles invalid input and errors gracefully.

The relative importance of these attributes varies with the application (for instance safety is critical in avionics, response time in games). Delivering these attributes reduces maintenance cost and increases user satisfaction.

A technical review is a planned, structured evaluation of a software work product (requirements, design, code, test plan) by a group of technical peers to find defects and verify conformance to specifications and standards, before the defects propagate to later phases.

Objectives: uncover errors in function, logic and implementation; verify that the product meets requirements; ensure it follows standards; make projects more manageable by finding problems early.

Types: walkthroughs (informal, led by author), inspections (formal, with checklists and defined roles), and formal technical reviews (FTR).

Process: planning and preparation (reviewers study the material), review meeting (usually 3-5 people, limited to about two hours, focus on the product not the producer), recording issues, and a review summary report with the decision: accept, accept with modification, or reject.

Benefits: early defect detection (cheaper to fix), improved quality, knowledge sharing among team members, and reduced rework and testing effort.

Role of a software engineer

A software engineer applies engineering principles to build software systematically and economically. Key roles are:

• Gather and analyse requirements with customers and write specifications.
• Design architecture, data and interfaces.
• Write, review and debug code and integrate components.
• Test the software (unit, integration) and verify its quality.
• Document the system and prepare user manuals.
• Maintain and enhance the software after delivery.
• Estimate, plan and work in a team, following standards and processes.
• Manage configurations, risks and ethics (professional responsibility).

Attributes of a good software engineer

1. Technical competence – strong programming, design and analytical skills; knowledge of tools, methods and domain.
2. Problem-solving ability and logical thinking.
3. Communication skills – to understand users and explain to team and customers, orally and in writing.
4. Teamwork and cooperation.
5. Creativity and adaptability – learning new technologies quickly.
6. Attention to detail and quality orientation.
7. Discipline, time management and responsibility.
8. Ethics and integrity – honesty, confidentiality, respect for intellectual property and public safety.
9. Patience and openness to feedback.

Role of specification in software quality

A software specification is a precise description of what the software must do and the constraints under which it works. It affects quality because:

• It is the common reference between customer and developer, reducing misunderstanding.
• Quality is defined as conformance to requirements; without a specification, correctness cannot be judged.
• It supports design, test-case derivation and acceptance testing (verification and validation).
• Defects in requirements are the costliest; a good specification finds them early.
• It controls scope and change, and supports maintenance and estimation.

Types of specification

1. Informal specification – natural language (English text). Easy to write and read but ambiguous. Example: "The system shall allow a student to register for a course."
2. Semi-formal specification – structured notations and diagrams such as DFD, ER diagrams, UML use cases, decision tables. Example: a use-case diagram for an ATM.
3. Formal specification – mathematical notation with precise syntax and semantics (Z, VDM, B). It is unambiguous and can be proved. Example: a stack specified as pre and postconditions, e.g. pop: pre: stack not empty, post: size reduced by 1.
4. Operational (functional) specification – describes behaviour as a process or model of the system (what happens step by step).
5. Descriptive (declarative) specification – describes properties the system must satisfy (axioms, invariants) without saying how.
6. Functional vs non-functional – services provided (withdraw cash) versus constraints (response time under 2 s, security).

Test case

A test case is a set of inputs, preconditions, execution steps and expected results developed to verify a particular feature or requirement of the software. A typical test case has: ID, description, preconditions, input data, steps, expected result, actual result and pass/fail status.

Example: Test login; input: valid username and wrong password; expected result: "Invalid password" message and no access.

Types of testing

• Unit testing – tests individual modules or functions in isolation (usually white box).
• Integration testing – tests interfaces between combined modules (top-down, bottom-up, big-bang).
• System testing – tests the complete integrated system against requirements.
• Acceptance testing – by the customer to decide acceptance; includes alpha and beta testing.
• White box (structural) testing – uses internal code logic: statement, branch, path coverage.
• Black box (functional) testing – tests functionality without knowing code: equivalence partitioning, boundary value analysis.
• Regression testing – retests after changes to ensure no new defects.
• Performance testing – load, stress and volume testing.
• Usability, security and compatibility testing.
• Static vs dynamic testing – reviewing without execution versus executing the code.

Verification checks whether the product is built correctly: "Are we building the product right?" It checks that each phase output conforms to the previous phase's specification, using reviews, inspections and walkthroughs (static, no execution).

Validation checks whether the right product is built: "Are we building the right product?" It checks that the final software meets the customer's actual needs, by executing the software through testing and user acceptance (dynamic).

White box vs black box testing

Both are complementary; neither alone gives complete confidence.

Software Quality Assurance (SQA) is a set of planned and systematic activities applied throughout the software process to ensure that the software and the process meet defined quality standards. It focuses on preventing defects through process control, not just finding them.

Role of SQA in quality management

• Establishes quality standards, procedures and metrics for the project.
• Ensures the chosen process is followed and improves it.
• Detects defects early via reviews and audits, reducing cost of rework.
• Gives management visibility of product and process quality.
• Ensures deviations are documented and resolved.
• Builds customer confidence and reduces maintenance cost.

SQA activities

1. Preparing an SQA plan – goals, standards, audits, reviews, tools and metrics.
2. Participating in process description – checking the process against organisational standards.
3. Reviewing software engineering activities – verifying compliance with the defined process.
4. Auditing work products – checking for conformance to defined standards.
5. Ensuring deviations are documented and handled according to procedure.
6. Technical reviews (FTR) – to find errors early.
7. Testing – a multi-tiered testing strategy.
8. Change control and configuration management.
9. Security and safety management, and risk management.
10. Measurement and reporting – collecting quality metrics and keeping records.

Software reliability is the probability of failure-free operation of a program for a specified time in a specified environment. Availability is the probability that the software is operating according to requirements at a given time.

Measuring reliability

Failure data are collected during testing and operation and used to compute:

• Mean Time To Failure (MTTF) – average time between failures while running.
• Mean Time To Repair (MTTR) – average time to fix a failure and restore service.
• Mean Time Between Failures (MTBF):

$MTBF = MTTF + MTTR$

• Failure rate $\lambda = 1/MTTF$ (failures per unit time).
• Reliability for time $t$ (constant failure rate):

$R(t) = e^{-\lambda t}$

• Probability of failure on demand (POFOD) and rate of occurrence of failures (ROCOF) are also used.
• Reliability growth models (Musa, Jelinski-Moranda) predict reliability using failure history.

Measuring availability

$\text{Availability} = \frac{MTTF}{MTTF + MTTR} \times 100\%$

Example: MTTF = 400 hours, MTTR = 10 hours:

$A = \frac{400}{410} \times 100 \approx 97.6\%, \qquad MTBF = 410 \text{ h}$

Systematic approach: (1) define operational profile, (2) record failures and repair times during testing, (3) compute MTTF, MTTR, MTBF, failure rate, (4) compute reliability and availability, (5) compare with the target and improve (more testing, fault removal, fault tolerance).

Risk is an uncertain event or condition that, if it occurs, has a negative effect on project objectives such as cost, schedule or quality. A risk has two characteristics: uncertainty (it may or may not happen) and loss (consequences if it happens). Risks are classed as project, technical and business risks, or known, predictable and unpredictable.

Risk management is the systematic process of identifying, analysing and controlling risks. Its steps are:

1. Risk identification – list threats using checklists, brainstorming and past project experience (product size, staff, technology, customer, business impact).
2. Risk analysis/projection (assessment) – estimate the probability of occurrence and impact for each risk; compute risk exposure:

$RE = P \times C$

where $P$ is probability and $C$ is cost of loss. Rank risks by exposure. 3. Risk planning (mitigation) – decide a strategy:

• Avoidance – change plans to eliminate the risk.
• Minimisation/mitigation – reduce probability or impact.
• Contingency planning – prepare a fallback if it occurs.
• Transfer/acceptance – insurance, outsourcing, or accept it.

4. Risk monitoring and control – track risks, trigger contingency plans, reassess regularly.

The result is documented in a Risk Mitigation, Monitoring and Management (RMMM) plan or risk table. Example: staff turnover (probability 70%, high impact) mitigated by documentation, pair programming and backup staff.

Object-oriented paradigm

The object-oriented (OO) paradigm views a system as a collection of interacting objects, each combining data (attributes) and operations (methods). Its main principles are:

• Encapsulation and information hiding
• Abstraction
• Inheritance (reuse through class hierarchies)
• Polymorphism (one interface, many forms)
• Modularity and message passing between objects.

It supports reuse, easier maintenance, and a natural mapping from the real world to the software.

Recursive/parallel model

The OO life cycle is not strictly linear; the recursive/parallel model (also called the "recursive/parallel" or evolutionary OO process) works as follows:

1. Analysis – perform OO analysis to identify classes and relationships using requirements and use cases.
2. Design – design the classes, their interfaces and architecture; define system and object design.
3. Recursive nature – the process is iterated repeatedly: after analysing and designing a small part, the team goes back and refines analysis and design as new classes and information emerge. Each pass produces more refined, reusable components.
4. Parallel nature – once classes are identified, different teams can design, implement and test different classes at the same time, as long as their interfaces are defined; work in different areas proceeds in parallel and is integrated later.
5. Components are placed in a class library; reused classes are pulled from it, and new classes are added for later reuse.
6. Implementation, testing and integration follow, again incrementally.

Benefit: faster development, early feedback and strong reuse. Cost: needs careful interface definition and coordination.

Formal Technical Review (FTR) is a structured quality assurance activity carried out by software engineers (peers) to uncover errors in function, logic or implementation, verify that the software meets its requirements and standards, and ensure it is developed uniformly and manageably. Forms include walkthroughs and inspections.

FTR meeting: involves the producer, review leader, reviewers and a recorder; usually 3-5 people, preparation of no more than about two hours each, meeting of no more than two hours, focusing on one work product. At the end the group decides to accept, accept with modifications, or reject the product.

Guidelines for review

1. Review the product, not the producer – keep the tone constructive, not personal.
2. Set an agenda and maintain it – keep the meeting on schedule.
3. Limit debate and rebuttal – record issues and take them off-line.
4. Identify problem areas, but do not attempt to solve every problem at the meeting.
5. Take written notes – the recorder writes down issues.
6. Limit the number of participants and insist on advance preparation.
7. Develop a checklist for each product to be reviewed.
8. Allocate resources and schedule time for FTRs.
9. Conduct meaningful training for all reviewers.
10. Review early reviews – review the review process itself.

Static testing examines the software without executing it. It includes reviews, walkthroughs, inspections and static code analysis of requirements, design and code. It is a verification activity, done early, finds defects such as missing requirements, standard violations and unreachable code, and is cheap.

Dynamic testing executes the program with test inputs and compares the actual with the expected output. It is a validation activity, done after code is available, and finds runtime failures, performance, memory and behaviour problems. It includes unit, integration, system and acceptance testing, using black box and white box techniques.

The two are complementary and are used together for better quality.

Cleanroom software engineering is a formal, team-oriented approach that emphasises defect prevention instead of defect removal, producing software with certified reliability. The name comes from the clean rooms of semiconductor manufacturing.

Main elements

• Formal specification using box structures (black box, state box, clear box).
• Incremental development – the software is built as increments, each developed and certified separately.
• Correctness verification – the code is verified mathematically and by team review instead of unit testing by developers.
• Statistical usage testing – an independent team tests with random cases drawn from the expected usage profile.
• Certification – failure data are used with a reliability model to estimate MTTF and certify quality.

Benefits: very low defect rates, higher productivity in the long run, and measurable reliability. Limitations: needs formal skills, training and time, and the community resists a no-unit-testing policy.

Attributes of good software

• Maintainability – can evolve to meet changing needs.
• Dependability and security – reliable, safe, secure; no damage on failure.
• Efficiency – economical use of memory, processor and time.
• Acceptability/usability – understandable, usable and compatible with other systems.
• Correctness – conforms to requirements.
• Portability, reusability, testability and robustness.

Challenges of software engineering

1. Heterogeneity – systems must run across different networks, platforms, devices and legacy systems and integrate with them.
2. Business and social change – need for rapid change and quick delivery in response to new markets and technologies.
3. Security and trust – protecting systems from attacks and keeping user trust, especially in remote/web systems.
4. Scale – developing systems of very small to very large and ultra-large size.
5. Changing requirements – customers' needs change during development.
6. Cost, schedule and quality pressure – estimating accurately and delivering on time and within budget.
7. Complexity and invisibility – software is intangible, hard to measure and manage.
8. Legacy systems – maintaining and modernising old software.
9. Skilled manpower and ethics – shortage of trained engineers and professional responsibility.

Software specification is the process and the resulting document that states precisely what the software must do (functional requirements) and the constraints it must satisfy (non-functional requirements, interfaces). It is the agreement between the customer and the developer and the base for design, testing and maintenance.

Types of specification

1. Informal – written in natural language; easy but ambiguous.
2. Semi-formal – structured notations such as DFDs, ER diagrams, UML diagrams, decision tables and use cases; clearer, still not mathematically exact.
3. Formal – mathematical languages (Z, VDM, B, Larch); unambiguous, supports proof and automatic checking, but needs expertise.
4. Operational – describes the desired behaviour as a model of how the system operates (state machines, Petri nets, process models).
5. Descriptive (declarative) – describes required properties through axioms, logic and algebra.
6. Functional and non-functional, and user vs system requirements.

Uses of specification

• Communication and contract between customer and developer.
• Basis for design and implementation.
• Basis for test cases and acceptance criteria (verification and validation).
• Estimation of cost, time and effort and project planning.
• Controlling changes and scope.
• Reference for maintenance and documentation.
• Early detection of omissions and inconsistencies.

Load testing checks how the system behaves under expected and peak-normal workloads, such as a specified number of concurrent users or transactions. It measures response time, throughput, resource use (CPU, memory) and finds bottlenecks, ensuring the system meets performance requirements. Example: testing an online exam site with 5,000 simultaneous users to see that pages load within 3 seconds.

Stress testing pushes the system beyond its normal capacity limits (extreme loads, low resources such as memory or disk, many users) to find the breaking point, to see how it fails and whether it recovers gracefully without losing data. Example: raising the same site to 20,000 users until it crashes, then checking recovery.

Both are types of performance testing, performed with tools such as JMeter or LoadRunner.

Test case – a set of inputs, execution conditions and expected results created to check a particular requirement or program path. It includes ID, description, preconditions, input data, steps, expected result, actual result and status.

Comparison of alpha and beta testing

Alpha testing Advantages: early detection of major defects; developers observe failures directly; controlled; lowers risk before wider exposure. Disadvantages: simulated environment; limited users and scenarios; testers are biased by product knowledge; consumes development time.

Beta testing Advantages: real conditions and diverse configurations; direct user feedback; better usability and satisfaction; reveals issues missed in-house. Disadvantages: no control over testers or environment; bugs hard to reproduce; feedback may be slow or poor; could harm reputation if the product is unstable.

Software Quality Assurance (SQA) is a systematic set of planned activities applied throughout the software process to provide confidence that the software and its process conform to defined quality standards and requirements.

ISO 9126 quality characteristics (now succeeded by ISO/IEC 25010):

1. Functionality – suitability, accuracy, interoperability, security, compliance.
2. Reliability – maturity, fault tolerance, recoverability.
3. Usability – understandability, learnability, operability, attractiveness.
4. Efficiency – time behaviour and resource utilisation.
5. Maintainability – analysability, changeability, stability, testability.
6. Portability – adaptability, installability, co-existence, replaceability.

SQA activities

• Preparing the SQA plan.
• Participating in the development of the project's software process description.
• Reviewing software engineering activities to verify compliance with the defined process.
• Auditing designated work products for conformance.
• Ensuring that deviations are documented and handled.
• Conducting formal technical reviews and the testing strategy.
• Change control and configuration management.
• Collecting metrics, keeping records and reporting results to management.
• Risk, safety and security management.

Formal Technical Review (FTR) is a structured peer review of a software work product, conducted to find errors in function, logic or implementation, check conformance to requirements and standards, and make development more manageable. Walkthroughs and inspections are forms of FTR.

FTR meeting guidelines

• Meeting of 3-5 people with advance preparation (not more than about two hours each) and a meeting duration of less than two hours.
• Participants: producer, review leader, reviewers (one of whom acts as recorder).
• Review the product, not the producer; keep a constructive tone.
• Set and keep to an agenda; limit debate and rebuttal.
• Identify problems but do not try to solve all of them in the meeting.
• Take written notes of every issue.
• Use a checklist; train the reviewers; schedule resources for reviews.

Review reporting process

At the end of the meeting all attendees decide whether to (1) accept the product without further modification, (2) reject it due to serious errors, or (3) accept it provisionally (minor errors to be corrected, no further review needed). All attendees sign off to show participation. Two documents are produced:

1. Review issues list – identifies problem areas and acts as a checklist for the producer's corrective actions.
2. Review summary report – answers what was reviewed, who reviewed it, and what the findings and conclusions were; it is a single page, becomes part of the project record and is sent to the project leader and others.

The review leader checks that the action items on the issues list have been fixed.

Definitions

• Reliability – probability of failure-free operation for a stated time; measured by MTTF/MTBF and failure rate.
• Availability – probability that the system is up and working when needed:

$A = \frac{MTTF}{MTTF + MTTR}$

• Serviceability (maintainability) – ease and speed with which the system can be diagnosed, repaired and restored; measured by MTTR.

Relationship

Availability combines the other two: it rises when MTTF increases (higher reliability) or MTTR decreases (better serviceability).

Example: MTTF = 100 h, MTTR = 10 h gives $A = 100/110 = 90.9\%$. Improving serviceability so MTTR = 1 h gives $A = 100/101 = 99.0\%$ without any change in reliability. A highly reliable system with extremely long repair time can still have poor availability.

Interdependence

They are related but not identical. They are interdependent in the sense that availability depends on both, and design choices affect all (redundancy improves reliability and availability; modular design and diagnostics improve serviceability; but added complexity may lower reliability). Yet reliability and serviceability can be improved independently, so they are separate attributes that jointly determine availability, often grouped as RAS.

Cleanroom process

Cleanroom software engineering is a formal, incremental approach focused on defect prevention through mathematically based specification, correctness verification by the team and statistical usage testing, resulting in software of certifiable reliability. The development team does not run unit tests; an independent certification team tests.

Cleanroom development process (tasks)

1. Increment planning – the project is divided into increments, each a deliverable subset.
2. Requirements gathering – informal customer requirements are collected.
3. Box structure specification – formal specification using black box (behaviour), state box (state data) and clear box (procedural design).
4. Formal design – refinement of specification into design with clear boxes in a stepwise manner.
5. Correctness verification – the team proves the design and code using correctness questions and review; no unit testing.
6. Code generation, inspection and verification – code is derived from the clear box and inspected.
7. Statistical test planning – a usage profile of probable use is prepared.
8. Statistical use testing – test cases are randomly generated from the usage profile and run.
9. Certification – the increment is certified.

Cleanroom certification process

1. Create usage scenarios and assign probabilities (usage model).
2. Generate test cases from the model by random selection.
3. Execute the tests and record failures and time of failure.
4. Feed the failure data into a reliability model (e.g. a reliability growth model) to compute MTTF.
5. Compare with the target; if reliability is acceptable the increment is certified, otherwise errors are corrected and testing continues.

Jobs (responsibilities) of a software project manager

• Project planning – define scope, objectives, estimate size, effort, cost and schedule.
• Team management – recruit, motivate, assign tasks, and resolve conflict.
• Project scheduling and tracking – set milestones, monitor progress and take corrective action.
• Risk management – identify, assess and mitigate risks.
• Quality management – ensure reviews, testing and standards are followed.
• Configuration and change control.
• Resource and budget management.
• Communication – with the customer, management and team; reporting status.
• Requirement negotiation and customer relationship.
• Process improvement and delivering the product in time, on budget.

SPMP (Software Project Management Plan)

The SPMP is the document, prepared early by the project manager (based on IEEE 1058), that defines how the project will be managed. Its main contents are:

1. Introduction – project overview, scope, deliverables, definitions.
2. Project organisation – process model, team structure, roles and responsibilities.
3. Managerial process plan – objectives, priorities, assumptions, risk management, monitoring and control.
4. Technical process plan – methods, tools, techniques, standards.
5. Work packages, schedule and budget – work breakdown structure, effort and cost estimates, task dependencies, Gantt/PERT charts, resource allocation.
6. Supporting plans – configuration management, quality assurance, verification and validation, testing, training, documentation.
7. Risk management plan and delivery/maintenance plan.
8. Appendices – references, change history.

Concepts and elements of the object model

Major elements (essential):

1. Abstraction – focus on the essential characteristics of an object relevant to the viewpoint, ignoring details.
2. Encapsulation – binding data and operations together and hiding the implementation behind an interface.
3. Modularity – decomposing the system into cohesive, loosely coupled modules (classes).
4. Hierarchy – ranking of abstractions: inheritance (is-a) and aggregation (part-of).

Minor elements:

5. Typing – enforcing that objects of different classes are not interchanged improperly.
6. Concurrency – objects can be active at the same time.
7. Persistence – objects outlive the process that created them.

Basic constructs: object (state, behaviour, identity), class (blueprint), message passing, polymorphism.

Object Oriented Design (OOD)

OOD is the process of turning the analysis model into a design of classes, objects, their attributes, methods, relationships and interactions, giving a system architecture (class, sequence and state diagrams, packages). It covers system design (subsystems, architecture), object design (class interfaces, algorithms) and data/persistence design.

Importance

• Models the real world naturally and is easy to understand.
• Reuse through inheritance and class libraries.
• Encapsulation makes changes local, so maintenance is easier.
• Supports modular, parallel development and incremental delivery.
• Better reliability and extensibility.
• Reduces complexity of large systems and cost over time.

Lines of Code (LOC) is a size measure of software counting the number of source lines in a program. It is used as a basis for productivity, quality and effort estimation, often expressed in KLOC (thousand lines of code).

Metrics derived

$\text{Productivity} = \frac{LOC}{\text{person-month}}, \quad \text{Quality} = \frac{\text{defects}}{KLOC}, \quad \text{Cost} = \frac{Rs}{LOC}$

It is also the input to models such as COCOMO.

Advantages: easy to count and automate, direct, widely used.

Disadvantages:

• Depends on programming language and coding style (e.g. 100 lines of assembly may equal 10 lines of a high-level language).
• Not known until coding is finished, so estimating it early is hard.
• Penalises concise, well-designed code; rewards verbose code.
• Ignores complexity, design and documentation effort.
• Counting rules (comments, blank lines, declarations) vary.

An alternative, language-independent measure is the Function Point.

Defect amplification is the phenomenon in which an undetected error made in one development step is passed on and multiplied (amplified) in later steps, because new errors are generated from it. For example, a flaw in the requirements produces several design errors, each of which can yield several coding errors.

Defect amplification and removal (DAR) model

Each development step is represented as a box:

• Errors from previous step come in.
• Errors passed through (undetected) are carried forward.
• Amplified errors are those increased by a factor $x$ in this step.
• Newly generated errors are added in the step.
• Percent efficiency of error detection shows what share of the errors is found by review/testing at that step.
• Errors passed to next step = errors that escape detection plus new errors.

Illustration: if 10 errors enter design, amplification is 1.5, 25 new errors are made, and review is 50% effective, then errors passed on = $(10 \times 1.5 + 25) \times (1 - 0.5) = 20$.

Removal: reviews and inspections at each stage (formal technical reviews) raise detection efficiency. Studies show that conducting reviews at every step drastically reduces errors reaching testing, and hence reduces cost of correction (an error costs far more to fix in later stages).

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, i.e. the application of engineering to software. It covers requirements, design, coding, testing, maintenance, project management and quality assurance, with the aim of producing reliable, efficient software within time and cost.

System engineering deals with the whole system, which has hardware, software, people, data, procedures and the environment, and works out how these elements work together to meet the overall needs.

Differences

Example: ATM banking system. System engineers decide the whole system: cash dispenser hardware, card reader, network link to the bank, security procedures, and user interaction, and allocate functions between hardware and software. Software engineers then take the allocated software requirements (PIN verification, transaction processing, balance update, user interface) and design, code and test the ATM software.

Qualities of a good specification

• Clear and unambiguous – each statement has one interpretation.
• Complete – covers all functions, constraints and interfaces.
• Consistent – no contradictions among requirements.
• Correct – accurately reflects the user's needs.
• Verifiable/testable – compliance can be demonstrated.
• Traceable – each requirement can be tracked to its source and to design and tests.
• Modifiable – easy to change while keeping structure.
• Understandable by both customers and developers.
• Precise and concise, and ranked by importance/stability.
• Abstract – states what, not how (design-independent).

Operational specification

An operational specification describes the system by a model of how it behaves or operates: it specifies the required behaviour by giving an abstract, executable (or simulatable) model of the system, so that the system's behaviour can be seen by running or tracing the model. Its types include:

1. Data Flow Diagrams (DFD) – show processes, data flows and stores.
2. Finite state machines / state transition diagrams – show states and events that cause transitions (e.g. a lift controller).
3. Petri nets – model concurrency and synchronisation.
4. Decision tables and decision trees – show conditions and actions.
5. Process models/ flowcharts / pseudocode and use-case scenarios – step-by-step behaviour.

Advantage: easy to understand and to simulate and validate with users. Disadvantage: may over-specify design and is harder to prove properties from than descriptive (axiomatic) specification.

Test case – a set of inputs, preconditions, steps and expected outputs designed to check a specific requirement or path of a program, together with the actual result and status.

Test case design techniques

1. Black-box techniques (based on specification)
   • Equivalence partitioning – divide inputs into valid and invalid classes; test one value per class.
   • Boundary value analysis – test at and around the edges, e.g. for range 1-100 test 0, 1, 2, 99, 100, 101.
   • Decision table testing, cause-effect graphing, state transition testing, error guessing.
2. White-box techniques (based on code structure)
   • Statement coverage, branch/decision coverage, condition coverage, path coverage, basis path testing (cyclomatic complexity), loop testing, data-flow testing.
3. Experience-based – error guessing, exploratory testing.

Alpha testing is done by internal staff or selected users at the developer's site in a controlled environment. Advantages: finds major bugs early, developers can observe and fix failures immediately. Disadvantages: not in a real environment, limited scenarios, testers may be biased.

Beta testing is done by real users at their own site on a near-final version. Advantages: real-world conditions and configurations, genuine feedback on usability, wider coverage. Disadvantages: no control over environment or testers, defects hard to reproduce, late or poor feedback, risk to reputation.

Software quality activities are the planned, systematic actions taken during the software process to build quality in and to verify that the software and the process satisfy defined standards. Together they form Software Quality Assurance (SQA), carried out by an independent SQA group.

SQA activities in detail

1. Prepare an SQA plan for the project: evaluations, audits and reviews to be performed, standards, procedures, error reporting, documents to produce and the amount of feedback.
2. Participate in the development of the project's software process description, reviewing it for consistency with organisational policy and standards.
3. Review software engineering activities to verify compliance with the defined software process; identify, document and track deviations.
4. Audit designated software work products to verify compliance with those defined as part of the process; report results to management.
5. Ensure that deviations in work and work products are documented and handled according to a documented procedure.
6. Record any non-compliance and report it to senior management; noncompliance items are tracked until resolved.
7. Apply technical methods and tools, conduct formal technical reviews, and perform multi-tiered testing.
8. Control change – manage configuration so changes are made in a controlled way.
9. Measure – collect metrics to track quality and improve.
10. Keep records and reporting, and manage risk, safety and security.

These activities provide management with objective evidence of product and process quality.

Formal Technical Review (FTR) is a structured peer review of a software work product (specification, design, code) that aims to find errors in function, logic or implementation, check conformance to requirements and standards, and make the project more manageable. Walkthroughs and inspections are variations. It involves a producer, review leader, reviewers and a recorder; 3-5 people, preparation of up to about two hours each, and a meeting of no more than two hours.

Guidelines for review

1. Review the product, not the producer.
2. Set an agenda and maintain it.
3. Limit debate and rebuttal; take disagreements off-line.
4. Enunciate problem areas but do not attempt to solve every problem at the meeting.
5. Take written notes.
6. Limit the number of participants and insist on advance preparation.
7. Develop a checklist for each product to be reviewed.
8. Allocate resources and schedule time for FTRs.
9. Conduct meaningful training for all reviewers.
10. Review the earlier reviews to improve the review process.

Record keeping and reporting

During the review the recorder notes all issues raised. At the meeting's end the attendees decide to accept the product, reject it, or accept it provisionally, and sign off. Two documents are produced:

• Review issues list – identifies problem areas in the product and serves as an action-item checklist to guide the producer's corrections.
• Review summary report – a single page recording what was reviewed, who reviewed it, and the findings and conclusions.

The summary report becomes part of the project historical record and is sent to the project leader and other interested parties. The review leader makes sure the items on the issues list are corrected, and the records are kept for process improvement and audits.

Defect amplification and removal

Defect amplification is the effect by which an error introduced in an early development step (for example requirements or design) is passed on to the next step, where it is multiplied into several further errors. Some defects are passed through unchanged, some are amplified, and new defects are also added in each step. Defect removal is done by reviews, inspections and testing at the end of each step, each with a certain removal efficiency. Defects that escape removal are carried into the next step.

Model (diagram)

Each development step is shown as a box with:

• defects coming in from the previous step,
• defects passed through (not amplified),
• defects amplified (each producing a multiple of errors, by an amplification factor),
• new defects generated in this step,
• defects detected and removed (by percentage efficiency),
• defects passed on to the next step.

 Preliminary design        Detailed design             Code / Unit test          Integration & system test
+----------------+        +----------------+          +----------------+        +-------------------+
| errors passed  |  10    | errors passed  |  15 ...  | errors passed  |        | errors passed     |
| amplified 1:x  |------->| amplified 1:x  |--------->| amplified 1:x  |------->| to customer       |
| new errors     |        | new errors     |          | new errors     |        | (field defects)   |
|  [Review: 50%] |        |  [Review: 60%] |          |  [Test: 40%]   |        |  [Test: 50%]      |
+----------------+        +----------------+          +----------------+        +-------------------+

Example. Suppose 10 defects enter preliminary design with no review. They are amplified 1:1.5 giving 15 and 25 new ones are added, so 40 enter detailed design. With no review all pass on, and the count keeps growing. If a review with 60% efficiency is introduced at each step, only 40% of defects pass on, so the number reaching testing and the customer drops sharply.

Cost associated with the process

• The cost of finding and fixing a defect rises steeply the later it is found. A defect found in requirements or design may cost one unit to fix; in coding about 5-10 units; in testing about 20-50 units; after release 100 or more units (rework, redesign, retesting, redeployment, customer loss).
• Because amplification multiplies the number of defects as they travel, an early defect that is not removed creates many later defects, each of which must be fixed at a higher unit cost.
• Review and inspection activities cost effort themselves, but removing defects early is much cheaper than removing the amplified defects later. So the total cost of quality is lower when defects are removed at each step.

Conclusion. The model shows that defect removal activity must be placed in every phase; the extra cost of early reviews is repaid by the much larger cost avoided in testing and maintenance.

Software reliability

Software reliability is the probability that software will operate without failure for a specified period of time in a specified environment. It is measured by Mean Time To Failure (MTTF), Mean Time Between Failures (MTBF = MTTF + MTTR) and failure rate $\lambda$.

For a constant failure rate, the reliability function is

$R(t) = e^{-\lambda t}$

Software availability

Availability is the probability that the software is operating according to requirements at a given point in time, i.e. the fraction of time the system is up:

$A = \frac{MTTF}{MTTF + MTTR}$

where MTTR is the Mean Time To Repair. Reliability depends only on the failure rate, while availability also depends on how quickly the system is restored.

Software reliability model (diagram)

A reliability growth model follows the failure-rate curve over the life of the software:

Failure
rate
 |\
 | \
 |  \__
 |     \___
 |         \_______________  <- stable (useful life) region
 |
 +------------------------------------> Time (testing / debugging)
  Testing & debugging phase     Operational phase

During testing, failures are observed and faults fixed, so the failure rate falls (reliability grows) until it reaches a stable level. Models such as Jelinski-Moranda, Basic Execution Time and Musa-Okumoto use observed failure data to estimate remaining faults and predict reliability.

Steps of using the model: collect failure data, fit the model, estimate $\lambda$, MTTF and R(t), and decide whether the reliability goal is reached or more testing is needed.

Difference: reliability is "does not fail for time t"; availability is "is working when needed". A system that fails often but is repaired in seconds may have high availability yet low reliability.

Function point (FP) approach

Function Point Analysis (Albrecht) measures software size from the functionality delivered to the user, independent of programming language. It is computed from five information domain counts:

• External Inputs (EI): user inputs that update data
• External Outputs (EO): reports, screens, messages
• External Inquiries (EQ): online input-output requests
• Internal Logical Files (ILF): logical groups of data kept by the system
• External Interface Files (EIF): data shared with other systems

Steps

1. Count each domain and classify as simple, average or complex.
2. Multiply by the weights to get the Unadjusted Function Points (UFP).

3. Rate the 14 general system characteristics $F_i$ (0 to 5) and compute the Value Adjustment Factor:

$VAF = 0.65 + 0.01 \sum F_i$

4. Compute

$FP = UFP \times VAF$

Example. A system has 20 inputs, 15 outputs, 10 inquiries, 4 files and 2 interfaces, all of average complexity, and every $F_i = 3$.

$UFP = 20(4) + 15(5) + 10(4) + 4(10) + 2(7) = 80 + 75 + 40 + 40 + 14 = 249$

$\sum F_i = 14 \times 3 = 42, \quad VAF = 0.65 + 0.42 = 1.07$

$FP = 249 \times 1.07 = 266.43 \approx 266$

If the team's productivity is 5 FP per person-month, effort is about $266/5 \approx 53$ person-months. Hence FP gives size, from which effort, cost and schedule are estimated.

Risk management

A risk is an uncertain event that, if it occurs, harms the project's cost, schedule or quality. Risk management is the process of identifying, analysing and controlling risks. Its steps are:

1. Risk identification: list project, technical and business risks (checklists, brainstorming), e.g. staff turnover, changing requirements, unrealistic schedule.
2. Risk analysis/projection: estimate the probability of each risk and its impact; compute risk exposure = probability x cost of loss, and rank the risks.
3. Risk planning: decide avoidance, mitigation (reduce the chance or impact), or contingency plans.
4. Risk monitoring and control: track risk indicators, check whether mitigation works, and update the risk table (RMMM plan: Risk Mitigation, Monitoring and Management).

Software Configuration Management (SCM) activities

SCM manages change to software work products throughout their life so that they stay consistent. Main activities:

1. Configuration identification: identify the configuration items (code, documents, test data) and give each a unique name and version number.
2. Version control: keep and manage different versions of items and the repository (e.g. Git).
3. Change control: a change request is submitted, evaluated for impact, approved or rejected by the Change Control Board, implemented, tested and recorded.
4. Configuration auditing: verify (technical review and configuration audit) that the change was made correctly and the baseline is complete and consistent.
5. Configuration status reporting: record and report what changed, who made the change, when, and what else was affected.

Together these prevent chaos when many people change the software, and allow earlier versions to be rebuilt.

Object Oriented Design (OOD)

Object Oriented Design is the design phase in which the system is modelled as a set of interacting objects. Each object combines data (attributes) and behaviour (methods), and belongs to a class. The analysis model produced from requirements is converted into a design with classes, their relationships (association, aggregation, inheritance), interfaces, and the interaction between objects, usually using UML (class, sequence, state diagrams).

Main concepts: abstraction, encapsulation, inheritance, polymorphism, modularity.

Design activities: identify objects and classes, define attributes and operations, define relationships, design interfaces and messages, and refine with design patterns.

Importance in software development

• Modularity and reuse: classes and components can be reused across projects, saving time and cost.
• Easy maintenance: encapsulation hides internal details, so a change in one class has little effect on others.
• Extensibility: inheritance and polymorphism let new features be added without changing existing code.
• Real-world modelling: objects map naturally to real entities, which helps communication between users and developers.
• Reduced complexity: large systems are divided into small, understandable objects.
• Better quality and reliability: well-tested classes are reused, and data is protected.
• Consistency from analysis to code: the same object model is used in analysis, design and implementation.

COCOMO model

COnstructive COst MOdel (Barry Boehm, 1981) is an algorithmic model to estimate effort, development time and staff from the size of the software in KLOC (thousands of lines of code). Projects are classified as:

• Organic: small, simple, experienced team
• Semi-detached: medium size, mixed experience
• Embedded: large, tight hardware and operational constraints

Basic COCOMO equations

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

Number of people = $E / D$.

Levels: Basic (size only), Intermediate (adds 15 cost drivers such as reliability, complexity, experience) and Detailed (applies drivers phase by phase). COCOMO II adds early-design and post-architecture models using function points and scale factors.

Software Engineering

Software engineering is the systematic, disciplined and quantifiable approach to the development, operation and maintenance of software; it applies engineering principles to produce reliable, economical software that works on real machines (IEEE definition).

Roles in software engineering

• Project manager: plans, schedules, controls cost and risk
• Business/requirements analyst: gathers and documents requirements
• System architect/designer: designs architecture, modules and data
• Programmer/developer: writes and unit tests code
• Tester/QA engineer: verifies and validates the software
• Configuration manager: controls versions and changes
• Maintenance engineer: fixes and enhances the delivered system
• Technical writer and support staff: documentation and user training

Attributes of good software

• Maintainability: can be changed to meet changing needs.
• Dependability and security: reliable, safe, and secure; does not cause damage on failure and resists malicious users.
• Efficiency: does not waste memory or processor time; good response time.
• Acceptability (usability): understandable, usable and compatible with the systems users already have.

Other attributes are portability, correctness, and reusability. Trade-offs usually exist among them, e.g. higher security may reduce efficiency.

Software specification

Software specification (requirements engineering) is the process of understanding and defining what services are required from the system and the constraints on its operation and development. The output is the Software Requirements Specification (SRS) document, which forms the agreement between customer and developer. Its activities are feasibility study, elicitation and analysis, specification, and validation.

Types of specifications

1. User requirements: natural-language statements and diagrams, written for customers and managers, describing the services and constraints in terms they understand.
2. System requirements: detailed, structured descriptions of the services, functions and operational constraints, written for developers; they define exactly what is to be implemented.
3. Functional requirements: what the system should do: services, inputs and outputs, behaviour for particular inputs (e.g. "the system shall allow a student to register for a course").
4. Non-functional requirements: constraints on the system such as performance, reliability, security, usability, portability. They are product, organisational or external requirements.
5. Domain requirements: come from the application domain and reflect its characteristics, e.g. banking rules or legal standards.
6. Interface specification: how the system interacts with other systems, hardware and users.

Specifications can be written in natural language, structured language, graphical notations (use cases) or mathematical (formal) notation.

Test case

A test case is a set of test inputs, execution conditions and expected results developed to verify a particular feature or path of the program. Typical fields: test case ID, description, preconditions, input data, steps, expected output, actual output and pass/fail status.

Integration testing vs unit testing

The paper leaves the second type open; the usual comparison is with unit testing.

Advantages of integration testing: detects interface errors between modules; checks that combined modules meet requirements; finds problems early in incremental integration.

Disadvantages: needs stubs and drivers, so more effort; locating the source of a fault is harder; big-bang integration delays testing until all modules are ready.

Advantages of unit testing: errors are found early and cheaply, easy to debug, and can be automated.

Disadvantages of unit testing: cannot find interface or system-level errors, and writing drivers costs time.

Software quality

Software quality is the degree to which software conforms to its stated functional and performance requirements, to documented development standards, and to the implicit characteristics expected of all professionally developed software. It covers correctness, reliability, efficiency, usability, maintainability and portability.

Software Quality Assurance (SQA)

SQA is a set of planned, systematic activities applied throughout the software process to give confidence that the product meets quality requirements and that the process and standards are followed. It is about preventing defects, not just detecting them.

Activities of the SQA team

1. Prepare an SQA plan for the project (standards, reviews, audits, records).
2. Take part in developing the project's software process description and check that it matches organisational policy.
3. Review software engineering activities to verify compliance with the defined process.
4. Audit designated work products to verify compliance with the defined standards.
5. Ensure that deviations in the work and products are documented and handled by a defined procedure.
6. Record any non-compliance and report it to senior management.
7. Conduct and support formal technical reviews, inspections and walkthroughs.
8. Apply software testing strategy and measure quality using metrics.
9. Control change and manage configuration with the SCM team.
10. Keep records and report to management.

Defect amplification and removal

Defect amplification is the multiplication of errors as they flow from one development step to the next. An error made in an early step (requirements or design) that is not detected will be passed on, and each such error can generate several more in later steps (design to code). At each step defects are of three kinds: passed through, amplified, and newly generated. Defect removal is carried out by reviews and tests at the end of each step, and each activity has a percentage removal efficiency. Errors that are not removed go to the next step.

Importance of the model in quality assurance

• It shows quantitatively how many errors reach the customer, with or without reviews.
• It justifies early reviews and inspections: a review with 50-60% efficiency in each phase cuts the number of defects in the end product sharply.
• It helps SQA decide where to put review and testing effort, and compare the efficiency of various techniques.
• It reduces cost: the cost of fixing a defect rises steeply with time, so early removal is cheaper than late removal.
• It supports process improvement, because the defect data collected per phase identifies weak phases.
• It improves the final quality, reliability and customer satisfaction, and lowers the maintenance burden.

Software reliability as an important quality attribute

Software reliability is the probability of failure-free operation for a stated time in a stated environment. I agree that it is among the most important quality attributes, because users judge software first by whether it works correctly whenever needed. Other attributes such as efficiency or good looks are of little value if the system fails.

Examples

• Safety-critical systems: an aircraft flight control system or a hospital patient-monitoring/radiation machine. A failure can cost lives; the Therac-25 accidents were caused by software faults.
• Banking and e-commerce: an ATM or online payment system that fails midway can debit money without delivering service, causing financial loss and loss of trust.
• Telecommunication and power grids: need very high availability; failures disrupt millions of users.
• Nepali context: an examination result or online form system that crashes at peak load frustrates thousands of students.
• Space missions: the Ariane 5 failure (1996) was caused by an overflow software error, costing hundreds of millions of dollars.

Why it matters

1. Failures cause loss of life, money, data and reputation.
2. Unreliable software has high maintenance and support costs.
3. Reliability affects other qualities: availability, safety and security.
4. Customers keep trusting and buying reliable products.

How it is achieved: fault avoidance (good design, standards), fault detection by reviews and testing, fault tolerance (redundancy, exception handling), and measuring MTTF/MTBF.

Hence reliability is a main attribute, though the level needed depends on the type of system.

Why project estimation is necessary

• To decide whether the project is feasible and to quote a price.
• To prepare the budget, schedule and staffing plan.
• To allocate resources and avoid cost and schedule overruns.
• To manage risk and negotiate with the customer.
• As a baseline for tracking progress and for process improvement.

COCOMO model

COCOMO (Boehm) estimates effort and time from size in KLOC, depending on the project class (organic, semi-detached, embedded).

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

Levels: Basic, Intermediate (15 cost drivers adjust the effort) and Detailed.

Example. An organic project of 32 KLOC.

$E = 2.4(32)^{1.05}$

$32^{1.05} = e^{1.05 \ln 32} = e^{1.05 \times 3.4657} = e^{3.639} \approx 38.06$, so

$E = 2.4 \times 38.06 \approx 91.3 \text{ person-months}$

$D = 2.5(91.3)^{0.38}$

$91.3^{0.38} = e^{0.38 \times 4.514} = e^{1.715} \approx 5.56$, so

$D = 2.5 \times 5.56 \approx 13.9 \text{ months}$

$\text{Staff} = E/D = 91.3/13.9 \approx 6.6 \approx 7 \text{ persons}$

COM vs DCOM

COM (Component Object Model) is Microsoft's binary standard that lets software components written in different languages communicate on the same machine. DCOM (Distributed COM) extends COM so that components can communicate across different computers over a network, using RPC.

Both use interfaces identified by GUIDs, support language independence, and reference counting for object lifetime.

Responsibilities of a software project manager

1. Project planning: define scope, objectives, work breakdown, schedule and milestones.
2. Estimation: estimate size, effort, cost and duration using techniques such as COCOMO and function points.
3. Resource and staff management: select, organise, motivate and train team members; assign tasks.
4. Risk management: identify, analyse, mitigate and monitor risks.
5. Project monitoring and control: track progress against plan, take corrective action, manage cost and schedule.
6. Communication and coordination: liaise with customer, senior management and team; hold meetings; prepare status reports.
7. Requirements and scope management: handle changing requirements and scope creep through change control.
8. Quality management: ensure standards, reviews and testing are carried out so quality goals are met.
9. Configuration management: make sure versions and baselines are controlled.
10. Documentation: ensure that proper documents and records are maintained.
11. Conflict resolution and leadership: resolve team issues and keep morale high.
12. Delivery and closure: deliver on time, obtain customer acceptance, and review lessons learned.

Test case

A test case is a set of inputs, execution conditions and expected results prepared to test a particular feature or path, with fields such as ID, description, input, expected output, actual output and status.

Functional testing (black box)

Tests the software against its functional requirements without looking at the code. Test cases are derived from the specification using techniques such as equivalence partitioning, boundary value analysis, decision tables and cause-effect graphs. It checks whether each function gives the correct output for the given input.

Structural testing (white box)

Tests the internal structure and logic of the code. Test cases are chosen to cover statements, branches, conditions and paths (basis path testing using cyclomatic complexity, data-flow testing, loop testing). Needs knowledge of the source code and is done mainly by developers, e.g. unit testing.

Domain testing

Tests whether the program correctly handles the input domain, i.e. the set of valid values for each variable. Inputs are partitioned into valid and invalid sub-domains, and test points are chosen on the boundaries (on, just inside, just outside). It finds errors in conditions that define the domain such as wrong relational operators ($<$ vs $\le$) and off-by-one errors.

Non-functional testing

Tests the quality attributes rather than the functions: performance, load and stress testing, security, usability, compatibility, reliability, recovery and portability testing. For example, checking that a page loads within 2 seconds for 1000 concurrent users.

Cost of a software defect using the defect amplification model

In the defect amplification model, each development step receives defects from the previous step, passes some through, amplifies others (each producing several new errors), adds newly generated errors, and removes a fraction through reviews or tests. The number of defects therefore grows as they move downstream if they are not removed.

Cost view

The cost to fix a defect depends on the phase where it is found. Let the unit cost in requirements/design be 1. Typical relative costs are:

Total cost of defects = sum over phases of (number of defects removed in that phase x unit cost of that phase).

Example. 10 defects arise in design. Without review they are amplified 1:3 in coding to 30, plus 10 new ones giving 40. If found in testing at cost 20 each, cost = $40 \times 20 = 800$ units. With a design review of 50% efficiency, 5 are fixed at cost $5 \times 1 = 5$; the remaining 5 amplify to 15 plus 10 new = 25, and testing costs $25 \times 20 = 500$, total 505 units, a clear saving.

Conclusion: the model shows that cost rises both because the number of defects grows (amplification) and because the unit cost of repair rises with time, so defects should be removed in the phase where they are introduced.

Given: EI = 50, EO = 40, EQ = 35, ILF = 6, EIF = 4. Average weights: EI 4, EO 5, EQ 4, ILF 10, EIF 7.

Unadjusted function points

$UFP = 50(4) + 40(5) + 35(4) + 6(10) + 4(7)$

$UFP = 200 + 200 + 140 + 60 + 28 = 628$

Value adjustment factor. All 14 complexity adjustment factors are 3, so $\sum F_i = 14 \times 3 = 42$.

$VAF = 0.65 + 0.01 \times 42 = 1.07$

Function points

$FP = UFP \times VAF = 628 \times 1.07 = 671.96 \approx 672$

So the system has about 672 function points.

Testing strategies

A testing strategy gives a road map of what steps are conducted, when, and how much effort and time they need. It begins with testing of small units and moves outward to the whole system ("testing in the large"). Verification asks "are we building the product right?" and validation asks "are we building the right product?".

Levels of the strategy

1. Unit testing: tests each module/function in isolation (white box), using drivers and stubs.
2. Integration testing: tests the interfaces of combined modules: top-down, bottom-up, sandwich or big-bang; regression tests after each integration.
3. Validation (acceptance) testing: checks the software against customer requirements; alpha testing at the developer's site and beta testing at the customer's site.
4. System testing: tests the whole system with other elements: recovery, security, stress and performance testing.

Characteristics of a good strategy: formal technical reviews before testing, testing starts at the component level, different techniques at different times, done by developers and an independent test group, and debugging is included.