Software Engineering

Skills needed to handle a software project

• Technical knowledge of software engineering, tools and the application domain.
• Planning and estimation of effort, time, cost and resources.
• Leadership and team building: motivating people and resolving conflicts.
• Communication with clients, team and management, including negotiation and presentation.
• Risk management and problem solving, and decision making under uncertainty.
• Time management and organisation, with ability to monitor progress.
• Quality focus, including ethical and professional judgement.

Project management activities

1. Project planning: defining scope, goals, schedule and deliverables, and preparing the project plan.
2. Cost and effort estimation: using techniques such as COCOMO, function points and expert judgement.
3. Scheduling: breaking work into tasks, setting dependencies and durations (Gantt charts, PERT/CPM) and allocating resources.
4. Risk management: identifying, analysing and planning for risks, then monitoring them.
5. Staffing and team management: selecting, organising and motivating the team.
6. Monitoring and control: tracking progress against the plan, taking corrective action and reporting.
7. Quality management: reviews, standards and quality assurance.
8. Configuration and change management: controlling versions and changes.
9. Proposal writing and reporting: writing project proposals and periodic reports to stakeholders.

COCOMO (Constructive Cost Model), proposed by Barry Boehm (1981), is an algorithmic model to estimate effort, development time and staffing from the estimated size of the software in thousands of delivered source instructions (KDSI/KLOC).

Basic COCOMO

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

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

Intermediate COCOMO

Adds 15 cost drivers (product, hardware, personnel, project attributes) rated from very low to extra high. The nominal effort is multiplied by the effort adjustment factor (EAF), e.g. $E = a_i (KLOC)^{b_i} \times EAF$ (with $a$ = 3.2, 3.0, 2.8 for organic, semi-detached, embedded).

Detailed COCOMO

Applies the intermediate model to each module and each phase of the life cycle separately, and sums the results.

COCOMO II

Updated for modern practices (reuse, prototyping, component-based development) with three submodels: application composition, early design and post-architecture.

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

Project classes (Basic COCOMO)

• Organic: small teams, familiar environment, well-understood requirements (size up to about 50 KLOC).
• Semi-detached: mixed experience, medium size and complexity (up to about 300 KLOC).
• Embedded: tight hardware, software and operational constraints; complex, large projects.

Basic COCOMO equations

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

Average staff $= E/D$.

Example: organic project of 32 KLOC: $E = 2.4(32)^{1.05} \approx 2.4 \times 38.0 \approx 91.3$ PM; $D = 2.5(91.3)^{0.38} \approx 2.5 \times 5.55 \approx 13.9$ months; staff $\approx 91.3/13.9 \approx 6.6$ persons.

Intermediate COCOMO multiplies the nominal effort by an Effort Adjustment Factor from 15 cost drivers (product, hardware, personnel and project attributes such as required reliability, complexity, analyst capability, tool use). Its nominal equation is $E = a_i(KLOC)^{b_i} \times EAF$.

Detailed COCOMO applies the cost drivers phase by phase (planning, design, coding, integration and test) for each module/subsystem.

Merits: well documented, repeatable, early estimate. Demerits: depends on an accurate KLOC estimate, ignores some factors, and needs calibration to the local environment.

Attributes of good software

• Maintainability: it can evolve to meet changing customer needs.
• Dependability and security: reliable, safe and secure; it does not cause damage on failure and resists malicious access.
• Efficiency: it does not waste system resources such as memory and processor cycles; good response and processing time.
• Acceptability (usability): understandable, usable and compatible with the systems its users use.

Key challenges

• Heterogeneity: systems must work across different platforms, networks and legacy systems.
• Business and social change: software must be developed and changed quickly as business needs change.
• Security and trust: protecting systems from attack and making users trust remote services.
• Scale: building everything from small embedded devices to very large systems.
• Delivery: reducing delivery time while maintaining quality, cost and schedule.

A software process model is a simplified, abstract representation of a software development process, describing the order of activities (specification, design, implementation, validation, evolution) and how they are related.

Types: waterfall model, incremental development, prototyping, spiral model, V-model, RAD, reuse-oriented (component-based) model, and agile methods (XP, Scrum).

Agile methods

Agile methods are incremental approaches that deliver working software in short iterations and welcome changing requirements. Principles: customer involvement, incremental delivery, people over process, embrace change and maintain simplicity. They stress working software over documentation and collaboration with the customer. Examples: Extreme Programming (pair programming, test-first, small releases, refactoring) and Scrum (sprints, product backlog, daily stand-up). They suit small to medium projects with rapidly changing requirements.

Software prototyping

A prototype is an early, partial version of the system used to demonstrate concepts, elicit and validate requirements and try design options. Steps: establish objectives, define functionality, develop the prototype, evaluate it with users. Types are throwaway and evolutionary. Benefits: reduced misunderstanding of requirements, better user involvement and early detection of design problems. Drawbacks: users may expect the prototype to become the product, and poor quality may be carried into the final system.

Software requirements are descriptions of the services the system provides and its constraints. Types:

• User requirements: statements, in natural language and diagrams, of what services the system should provide and the constraints under which it must operate; written for customers and users.
• System requirements: detailed descriptions of the functions, services and constraints, written for developers and as a basis for design and contract.

By nature, requirements are also classified as functional, non-functional and domain.

Functional requirements: statements of services the system should provide, how it reacts to particular inputs and how it behaves in particular situations. Example: "A user shall be able to search the catalogue by author."

Non-functional requirements: constraints on the services or the system as a whole, such as performance, reliability, security, usability, portability and standards. Example: "The system shall respond within 2 seconds."

Domain requirements: requirements that come from the application domain and reflect its characteristics and rules, which may be functional or non-functional. Example: a library system must follow a standard interface for copyright-protected documents; a train control system must obey braking-distance rules.

User requirements: high-level abstract requirements understandable by non-technical stakeholders, e.g. "The system shall generate monthly management reports."

Software design concepts

Design is the process of converting requirements into a blueprint for implementation. Key concepts: abstraction (hiding detail and showing essentials), modularity, information hiding, refinement (stepwise elaboration), architecture, functional independence, refactoring and design patterns.

Modularization

Modularization divides the software into separately named and addressable components called modules, which are integrated to satisfy the requirements. Benefits: manageability, parallel development, easier testing, maintenance and reuse.

Cohesion vs coupling

Good design has high cohesion and low coupling.

Importance of UI design

The user interface is what the user sees and uses, so system success depends heavily on it. A poor UI leads to user errors, frustration, low productivity and even rejection of the software. A good UI:

• makes the system easy to learn and use and reduces training cost;
• reduces user errors and their consequences;
• improves user satisfaction and productivity;
• gives a competitive advantage, since users judge the system by its interface.

How UI design is visualised

UI design is visualised and refined in stages:

1. User analysis: identify users, tasks and environment.
2. Sketches and storyboards: paper drawings showing screen flow.
3. Wireframes and mock-ups: layouts of screens, controls and navigation.
4. Prototypes: interactive versions built with tools to test with users.
5. Evaluation: usability testing and feedback, then iterate.

Interaction styles used are direct manipulation, menu selection, form fill-in, command language and natural language. Design follows principles such as user familiarity, consistency, minimal surprise, recoverability, user guidance and user diversity.

Why maintenance is a major component

Software maintenance is the modification of software after delivery to correct faults, improve performance or adapt it to a changed environment. It is a major part of the SDLC because:

• most software lives for years, and requirements and environments keep changing;
• maintenance typically consumes 60-70% or more of total life-cycle cost, far more than initial development;
• software must be kept useful and competitive, while errors found only in use must be fixed;
• poor structure and documentation make change costly over time.

Types of maintenance

1. Corrective maintenance: fixing bugs and faults discovered after release.
2. Adaptive maintenance: modifying the software to work in a changed environment, such as a new OS, hardware or regulation.
3. Perfective maintenance: adding new features or improving performance and usability on user request.
4. Preventive maintenance: restructuring and updating to make future maintenance easier and prevent faults (refactoring).

Configuration management (CM) is the discipline of identifying, organising, controlling and tracking changes to software items (source code, documents, data, builds) throughout the life of a system, so that the evolving product stays consistent and reproducible.

Main activities: configuration identification, version control, change control, build management (system building), release management, and configuration status accounting and audit.

Importance

• Controls change: software changes constantly, and CM ensures changes are reviewed, approved and recorded.
• Version control: keeps track of versions and releases, and allows rollback to an earlier working version.
• Supports teamwork: prevents team members overwriting each other's work and manages parallel development.
• Consistency and traceability: ensures the right components make up each build, and links changes to requirements and faults.
• Quality and cost: avoids confusion and rework, helps reproduce faults and supports audits and standards compliance.

ISO quality standards

ISO (International Organization for Standardization) publishes international standards for quality management systems so that organisations can consistently deliver products that meet customer and regulatory requirements.

ISO 9000 is the family of quality-management standards. It gives the fundamentals and vocabulary: customer focus, leadership, involvement of people, process approach, continual improvement, evidence-based decision making and relationship management.

ISO 9001 is the standard that specifies the requirements for a quality management system, against which an organisation is certified. It is the most general model, covering design, development, production, installation and servicing. For software, ISO 9001 is applied through the guideline ISO 90003. It requires documented procedures, quality manuals, process control, audits, corrective actions and review.

Black box testing

Tests the functionality without knowledge of internal code, using only inputs and expected outputs from the specification. Techniques: equivalence partitioning, boundary value analysis, decision tables, state transition and cause-effect graphing. Performed by testers; it finds incorrect or missing functions and interface errors.

White box testing

Tests the internal structure and logic of code, with test cases derived from the code. Techniques: statement coverage, branch (decision) coverage, condition and path coverage, basis path testing using cyclomatic complexity $V(G) = E - N + 2$, and loop testing. Performed by developers; it finds logic errors and untested paths.

Requirements elicitation and analysis is the process of discovering requirements from stakeholders and the domain, then classifying, negotiating and documenting them. Main techniques:

1. Interviews: closed (fixed questions) or open (free discussion) sessions with stakeholders; effective for understanding the overall problem, but domain jargon can hide tacit knowledge.
2. Questionnaires and surveys: collect views from many users quickly and cheaply, though answers are limited.
3. Observation / ethnography (task analysis): analysts watch users do their work in context, revealing implicit requirements people cannot articulate.
4. Scenarios and use cases: describe interactions between users and the system step by step and show actors and goals; they make requirements concrete.
5. Prototyping: a quick working model that users evaluate to refine unclear requirements.
6. Joint Application Development (JAD) / workshops / brainstorming: structured group sessions of users and developers that produce agreement fast.
7. Document and system analysis: studying existing forms, reports, manuals and old systems.
8. Viewpoint-oriented analysis: collecting requirements from different stakeholder viewpoints and resolving conflicts.
9. Requirements reuse / domain analysis: reusing requirements of similar systems.

After elicitation, analysis includes classification, conflict resolution, prioritisation and validation; the results are recorded in the SRS (Software Requirements Specification).

Software engineering is an engineering discipline concerned with all aspects of software production, from initial specification through development to maintenance after deployment. It applies systematic, disciplined and quantifiable principles, methods and tools to build reliable, cost-effective software.

Challenges

• Heterogeneity: software must run on different platforms, devices, networks and integrate with legacy systems.
• Business and social change: business conditions change rapidly, and software must change and be delivered quickly.
• Security and trust: software is exposed through the internet and must be protected, and users must trust it.
• Scale: systems range from tiny embedded devices to large, distributed, internet-scale systems.
• Delivery time and cost: pressure to deliver faster at lower cost without lowering quality.
• Changing requirements and complexity: requirements evolve, and large systems are hard to understand and test.

Extreme Programming (XP) is an agile method that takes recognised good practices, such as iterative development and testing, to extreme levels. New versions may be built several times a day and delivered to customers every few weeks, and all tests must pass for each build.

Principles and how they accelerate development

• Incremental planning: requirements recorded as user stories; the stories to include in a small release are chosen by priority, so useful software is delivered early.
• Small releases: the minimal useful functionality is released first and increments are added often, giving fast feedback.
• Simple design: only enough design to meet current needs, which avoids wasted effort.
• Test-first development: tests written before code and run automatically, so faults are found early.
• Refactoring: continuous code improvement keeps the code easy to change.
• Pair programming: two developers share a workstation, giving continuous review and shared knowledge.
• Collective ownership: anyone can change any code, so there are no bottlenecks.
• Continuous integration: work is integrated and tested after each task, avoiding late integration problems.
• Sustainable pace: no excessive overtime, which maintains quality.
• On-site customer: a customer representative is part of the team, reducing misunderstanding and rework.

Together these reduce documentation, rework and delay, thus accelerating delivery.

Quality assurance (QA) is the set of planned, systematic activities (standards, processes, reviews, audits and testing) carried out to give confidence that the software product meets specified quality requirements. It focuses on preventing defects by improving the process, not only detecting them.

Staged representation of CMM

The Capability Maturity Model (CMM/CMMI) staged representation rates an organisation's overall process maturity at one of five levels: 1 Initial, 2 Managed (Repeatable), 3 Defined, 4 Quantitatively Managed, 5 Optimizing. Each level has a set of process areas that must be satisfied before moving up.

I would recommend the staged representation when:

• the organisation is new to process improvement and needs a clear, proven roadmap of what to improve first;
• it wants an overall maturity rating or certification level, for example to satisfy a client or tender;
• it wishes to compare itself with other organisations or suppliers using a single number;
• processes are immature, so improvement should be step by step, building a foundation (such as project management at level 2) before advanced practices;
• management wants to improve the whole organisation uniformly rather than selected process areas.

Architectural design is the design process for identifying the sub-systems making up a system and the framework for sub-system control and communication. Its output is a description of the software architecture, which affects performance, security, availability and maintainability.

Layered model

The system is organised into layers, each providing services to the layer above and using services of the layer below. A layer depends only on the layer immediately beneath it, so each layer can be replaced if its interface stays the same, which supports portability and incremental development. Disadvantages: strict layering is hard to achieve, and performance may suffer due to passing through several layers.

Example: a generic web/information system:

1. User interface (presentation layer)
2. User interface management, authentication and authorisation
3. Core business logic / application functionality
4. System support (database, OS, utilities)

Another example is the OSI network model. In a library system: UI → search/borrow logic → data access → database and operating system.

Verification vs validation

Why software inspection is effective

Inspection is a formal, static peer review of requirements, design or code by a team following a checklist. It is effective because:

• it finds errors without executing the program, so one error does not hide others as in testing;
• it can be applied to incomplete versions and non-executable artefacts such as specifications and designs;
• it also checks quality attributes such as standards compliance, portability and maintainability;
• reviewers bring varied experience and knowledge of common error types, using checklists;
• it finds errors early when they are cheaper to fix, and reports show it finds a high percentage (60-90%) of defects;
• it spreads knowledge across the team.

Software reengineering is the restructuring or rewriting of part or all of a legacy system, without changing its functionality, so that it is easier to maintain and understand. It involves reverse engineering, program restructuring, data restructuring and forward engineering.

Advantages

• Reduced risk compared with new development.
• Lower cost than rewriting from scratch.
• Improved maintainability, structure and documentation.
• Extends the life of valuable legacy systems and allows migration to new platforms.
• Better performance and easier adaptation to change.

Source code translation

The program is converted automatically from an old programming language to a modern one (for example COBOL to Java), or from one version to another. It is used when hardware or compilers become obsolete or skilled staff are unavailable. Steps: analyse and map the constructs, translate, restructure and re-test; manual fixes are usually needed.

Reverse engineering

Reverse engineering analyses the existing software to recover its design and specification from its code, creating higher-level representations. Steps: read code, extract program structure, data structures and control flow, and produce documentation, structure charts, data models and requirement descriptions. It is the first step of reengineering and is supported by automated tools, and it provides understanding before changes are made.

Software quality management (SQM) is the set of activities that ensure software reaches the required level of quality, by defining standards and procedures and checking that they are followed during development. It aims at a culture of quality in the organisation.

Activities

1. Quality assurance: establishing the organisational standards and procedures that lead to high quality, and a quality plan.
2. Quality planning: selecting suitable procedures and standards for a project and defining the quality plan.
3. Quality control: checking that development staff follow the process, using reviews, inspections and testing to find defects.
4. Reviews and inspections: examining documents and code for defects.
5. Software measurement and metrics: collecting and analysing data to assess product and process quality.
6. Standards: defining and applying product standards (documentation, coding) and process standards (such as ISO 9001).
7. Audits and process improvement: assessing compliance and improving the process (e.g. CMM).

A software process model is a simplified, abstract representation of a software process, showing the activities, their order and their relationships.

Types: waterfall, incremental, prototyping, spiral, V-model, RAD, reuse-oriented and agile models (XP, Scrum), and the unified process.

Spiral model

The spiral model, proposed by Boehm, represents the process as a spiral of loops. Each loop has four sectors: objective setting, risk assessment and reduction, development and validation, and planning of the next loop. The radial dimension is the cumulative cost, the angle shows progress. Risk is explicitly considered.

Accommodating waterfall in the spiral

A project with well-understood requirements and low risk can be run through a spiral with one loop per phase of the waterfall: feasibility, requirements, design, implementation, testing. Each loop completes a phase with its deliverable and review, in sequence. The spiral thus reproduces the waterfall as a special case where risk analysis finds no major risk, with the added risk checkpoints.

Accommodating prototyping in the spiral

When requirements or technical aspects are uncertain, the risk assessment sector in early loops calls for building a prototype to reduce risk. Early loops produce prototypes (concept, then requirements prototype) which are evaluated by the user and refined, while later loops, once risks are resolved, follow the waterfall-style development of the real system. So prototyping is used in early loops to reduce risk, and the waterfall-like phases are used in later loops, making the spiral a meta-model that includes both.

A software requirement is a description of a service the system must provide or a constraint on it, reflecting the needs of customers and users.

Functional vs non-functional requirements

Functional requirements of an online examination system

• Admin registers examiners and students and manages courses.
• User login and authentication.
• Examiner creates, edits and deletes questions and exams.
• Student views available exams and takes the exam within a time limit.
• System evaluates objective answers automatically.
• Examiner grades subjective answers.
• Student views results; the system generates result reports.

Use case diagram

 Actors: Admin, Examiner, Student        System boundary: Online Examination System

 Admin     --- Manage users          (include) Login
 Admin     --- Manage courses        (include) Login
 Examiner  --- Create/edit questions (include) Login
 Examiner  --- Create exam
 Examiner  --- Grade subjective answers
 Examiner  --- Generate report
 Student   --- Register
 Student   --- Take exam             (include) Login
 Student   --- Submit answers        (extends Take exam)
 Student   --- View result
 Take exam --- Auto-evaluate answers (include)

In the diagram, the three actors (Admin, Examiner, Student) are drawn as stick figures outside the system rectangle, with ovals for the use cases above inside it. The Login use case is included by the use cases that require authentication.

(a) Risk management is the process of identifying risks that threaten the project, product or business, assessing their probability and impact, planning to avoid or minimise them, and monitoring them throughout the project.

Risk management process

Risk identification -> Risk analysis -> Risk planning -> Risk monitoring
        |                    |                |                 |
  list of risks      prioritised list    avoidance/       risk assessment
                                         minimisation plans   (loop back)

1. Risk identification: find project, product and business risks (staff turnover, requirement changes, technology failure, schedule slip).
2. Risk analysis: assess the probability (low to very high) and consequence (catastrophic to insignificant) of each risk and prioritise.
3. Risk planning: make plans to avoid the risk, minimise its effect, or provide a contingency plan if it happens.
4. Risk monitoring: regularly assess the risks, check whether probability or effect has changed, and discuss them at progress meetings.

(b)

Good programming practices: use meaningful names; follow coding standards and consistent style; write comments and documentation; keep functions small and modular (single responsibility); avoid global variables and deep nesting; handle errors and exceptions; avoid duplicate code (DRY); validate input; use version control; review code and test early; refactor.

CASE (Computer-Aided Software Engineering) is software that supports software process activities such as requirements, design, programming and testing, to improve productivity and quality.

Types:

• Upper CASE: support early activities (requirements and design), e.g. diagram editors such as Rational Rose, Visible Analyst.
• Lower CASE: support implementation, testing and maintenance, e.g. compilers, debuggers, Selenium or JUnit for testing.
• Integrated (I-CASE): cover the entire life cycle.
• By functionality: tools (single task such as a compiler), workbenches (a set of tools for a phase such as a testing workbench), and environments (support the whole process, e.g. Eclipse).

The waterfall model is a linear sequential life-cycle model in which each phase must be completed and approved before the next one begins, flowing downward like a waterfall.

Activities

1. Requirements analysis and definition: the services, constraints and goals are established with users and written in a specification.
2. System and software design: requirements are allocated to hardware/software; the software architecture, interfaces and data structures are designed.
3. Implementation and unit testing: the design is coded as programs or units, and each unit is tested.
4. Integration and system testing: units are integrated and the system is tested against requirements, then delivered.
5. Operation and maintenance: the system is installed and used, and errors are corrected and enhancements made.

Drawbacks

• Inflexible: it is difficult to accommodate changing requirements once the process has started.
• Working software appears only late in the process, so errors are found late and are costly.
• Customer involvement is limited; the customer must state all requirements up front.
• High risk for large, complex or long projects where requirements are unclear.
• Heavy documentation and no overlap between phases.
• Suitable only when requirements are well understood and stable.

CASE (Computer-Aided Software Engineering) refers to software tools that automate and support activities of the software development process, from requirements to maintenance.

Importance of CASE tools in the SDLC

• Requirements and analysis: tools to capture, trace and model requirements (use case and data flow diagrams) and check consistency.
• Design: UML modelling, ER and structure chart editors, code generators from models.
• Implementation: editors, compilers, debuggers, and automatic code generation increase productivity.
• Testing: automated test tools, test data generators and coverage analysers.
• Maintenance: reverse engineering, restructuring and configuration management tools.
• Project management: estimation, scheduling and tracking.

General benefits: increased productivity and shorter development time, better quality and fewer errors, consistent documentation and standards, easier communication and reuse, and lower maintenance cost. Limitations are the cost of the tools and training and the need for process fit.

Modularization is the process of dividing a software system into separate, named and independently addressable components (modules), each performing a specific function, which are integrated to meet requirements. It makes systems easier to understand, develop in parallel, test, maintain and reuse.

Cohesion vs coupling

Example: A module calculateSalary() which only computes salary has functional (high) cohesion; a module Utility that includes printing, file reading and tax calculation has coincidental (low) cohesion.

For coupling: if module A passes only the needed values (e.g. amount) to B, it is data coupling (low, good). If A modifies B's internal variables, or both share global data, it is content or common coupling (high, bad).

Good design: high cohesion and low coupling.

Programming languages

A programming language is a formal language of instructions used to write programs for a computer. Types by level:

• Machine language: binary instructions executed directly by the CPU.
• Assembly language: mnemonics that an assembler converts to machine code.
• High-level languages: English-like, machine independent, translated by compilers or interpreters (C, Java, Python).
• Fourth-generation languages (4GL): non-procedural languages such as SQL and report generators.

Paradigms include procedural, object-oriented, functional and logic programming.

Software development tools

• Editors and IDEs: code editing and navigation, e.g. VS Code, Eclipse.
• Compilers, interpreters and assemblers: translate source code.
• Debuggers: locate and fix errors (gdb).
• Linkers and loaders; build tools: make, Maven.
• Version control tools: Git, SVN.
• Testing tools: JUnit, Selenium.
• Modelling and design tools: UML tools (CASE).
• Profilers and static analysers: find performance and code quality problems.
• Project management and documentation tools: Jira, Doxygen.

Verification checks that the software correctly implements its specification: "Are we building the product right?" It uses static techniques such as reviews, walkthroughs and inspections.

Validation checks that the software satisfies the customer's actual needs: "Are we building the right product?" It uses dynamic testing of the running system, ending with acceptance testing.

Black box vs white box testing

Software quality assurance (SQA) is a set of planned, systematic activities that ensure software processes and products conform to standards and requirements. Main activities:

1. Establishing standards and the SQA plan: defining standards (such as ISO 9001, IEEE) and procedures. Example: coding standard requiring naming conventions and comments.
2. Technical reviews and inspections: peer review of requirements, design and code to find defects early. Example: a code inspection with a checklist before integration.
3. Testing: planning and executing unit, integration, system and acceptance tests. Example: boundary value tests for an age field.
4. Process monitoring and audits: checking that the process is followed. Example: auditing that each change has an approved change request.
5. Change and configuration control: managing versions and changes so that quality is not degraded.
6. Measurement and metrics: collecting defect density, coverage and similar data to assess quality. Example: defects per KLOC.
7. Defect reporting and tracking: recording faults, analysing causes and ensuring they are fixed.
8. Record keeping and reporting to management; training and risk management.

Challenges facing software engineering

• Heterogeneity: systems must operate across different networks, platforms, devices and with legacy systems, requiring integration techniques.
• Business and social change: businesses and society change fast, so software must be developed and evolved quickly. Traditional techniques are often too slow.
• Security and trust: as software is accessible through the web, it must be protected from attack and users must be able to trust it.
• Scale: systems range from small embedded programs to huge systems of systems, and methods must scale.
• Reduced delivery time and cost: pressure to deliver faster and cheaper while keeping quality.
• Changing requirements, complexity and legacy maintenance, plus the shortage of skilled engineers.

Professional and ethical responsibility

Software engineers have wider responsibilities than technical skills. They must behave honestly and ethically, in a way that respects the profession.

Issues of professional responsibility

• Confidentiality: respect the confidentiality of employers and clients, whether or not a formal agreement exists.
• Competence: do not misrepresent level of competence or knowingly accept work beyond capability.
• Intellectual property rights: know local laws on patents and copyright, and protect the property of employers and clients.
• Computer misuse: do not use technical skills to misuse others' computers (unauthorised access, viruses).

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

Ethical dilemmas arise when a person disagrees with a policy (e.g. a safety-critical system released untested), and the engineer should act in line with the code.

Capability Maturity Model (CMM) is a framework developed by the SEI (Carnegie Mellon University) to assess and improve the maturity of an organization's software development process. It grades an organization on a five-level scale, each level building on the one below.

Levels and key process areas (KPAs)

Alpha vs Beta testing

Software maintenance is the modification of a software product after delivery to correct faults, improve performance or other attributes, or adapt it to a changed environment. It is often the most costly phase of the life cycle (commonly 60 percent or more of total cost).

Types of maintenance

1. Corrective maintenance: fixing bugs and errors discovered after release (e.g. a crash on a particular input).
2. Adaptive maintenance: modifying the software to work in a changed environment, such as a new operating system, hardware or law (e.g. updating tax rules).
3. Perfective maintenance: adding new features or improving performance and usability at users' request.
4. Preventive maintenance: restructuring or documenting the code to prevent future problems and improve maintainability (e.g. refactoring).

Reengineering process

Reengineering is the examination and alteration of an existing system to reconstitute it in a new, better form, without changing its functionality. It is used when the system is still valuable but hard to maintain.

Activities:

1. Inventory analysis: list all applications with their age, business value, maintainability and criticality; select candidates for reengineering.
2. Document restructuring: create or update missing documentation to the level actually needed.
3. Reverse engineering: analyse the code to recover design, data and process information (data, architectural and procedural design), often with tools.
4. Code restructuring: rewrite poorly structured code (e.g. remove GOTOs, simplify control flow) without changing behaviour, then review and test.
5. Data restructuring: analyse and redesign data architecture and data structures, convert formats and schemas.
6. Forward engineering: use the recovered design information to rebuild the system with modern tools, languages and architecture, improving quality and performance.

Result: a more maintainable system with a cleaner design, up-to-date documentation and lower future maintenance cost.

Software engineering is the systematic, disciplined and quantifiable application of engineering principles to the development, operation and maintenance of software, so that reliable, efficient and economical software is produced within time and budget.

Software life cycle model is a descriptive and diagrammatic representation of the series of phases (requirements, design, coding, testing, deployment, maintenance) through which software passes.

Need for life cycle models

• Structured approach: gives the team a defined set of activities and their order, avoiding ad hoc "build and fix" development.
• Common understanding: all members and the customer share the same view of the process and the stage reached.
• Project planning and control: each phase has defined entry/exit criteria and deliverables, so progress can be tracked, scheduled and measured.
• Quality and risk management: reviews and verification at the end of each phase find defects early, when they are cheap to fix; some models (e.g. spiral) explicitly manage risk.
• Resource allocation and cost estimation: effort and staff can be assigned phase-wise.
• Maintainability: well-documented phases make later changes easier.
• Model selection fits the project: waterfall for stable requirements, prototype/incremental/spiral for uncertain or risky ones.

Configuration management (CM) is the discipline of identifying, organizing and controlling changes to the software products (code, documents, test data, tools) during development and maintenance. Its main activities are configuration identification, version control, change control, configuration auditing and status reporting. It ensures that the correct versions of items are used, changes are tracked and approved, and the system can be rebuilt reliably.

Five levels of CMM and their important features

1. Level 1, Initial: unpredictable, ad hoc process; little is defined; success depends on individuals.
2. Level 2, Repeatable: basic project management (planning, tracking, requirements management, configuration management, quality assurance); earlier successes can be repeated on similar projects.
3. Level 3, Defined: the process is documented, standardized and integrated across the organization; training programs and peer reviews exist.
4. Level 4, Managed: detailed metrics of process and product quality are collected; the process is quantitatively understood and controlled.
5. Level 5, Optimizing: continuous process improvement through quantitative feedback, defect prevention and adoption of new technologies.

Modular design is a design approach in which the software is divided into separate, named, independently developed components called modules, each performing a well-defined part of the overall function, and integrated to meet the requirements. Good modules have high cohesion (elements within a module belong together) and low coupling (few dependencies between modules), with a clear interface and information hiding.

When to implement it

• During the architectural/high-level design phase, after requirements are analysed, for any non-trivial system.
• Especially when the system is large or complex, several people or teams work in parallel, parts are to be reused, or the system is expected to change often.

How to implement it

1. Decompose the problem top-down (functional or object-oriented) into subsystems and then modules.
2. Make each module do one well-defined task (functional independence, high cohesion).
3. Minimize coupling: pass only necessary data through simple interfaces, avoid global data and control coupling.
4. Apply information hiding: expose only the interface, hide internal data and algorithms.
5. Keep modules of manageable size and a sensible fan-in/fan-out in the structure chart.
6. Define interfaces first, then code and unit-test modules independently, and integrate step by step.

Benefits: easier understanding, parallel development, easier testing and debugging, reuse and simpler maintenance.

Coding standards are a set of agreed rules and guidelines on how source code is written within an organization or project. Their aim is to make code uniform, readable, less error-prone and easy to maintain, regardless of which programmer wrote it.

Typical contents

• Naming conventions: meaningful names for variables, functions and classes; consistent style (camelCase, UPPER_CASE for constants); global names capitalized, local names lowercase.
• Layout and formatting: consistent indentation, brace placement, line length, spacing and one statement per line.
• Commenting: a header comment for each module (purpose, author, date, modification history, inputs/outputs), and comments explaining non-obvious logic rather than restating the code.
• Language usage rules: avoid GOTO, avoid deeply nested constructs, do not use a variable for multiple purposes, avoid obscure tricks and side effects, limit function length and number of parameters.
• Error handling: every error condition must be checked and handled; return codes and exceptions used consistently.
• File and module organization: one module per file, standard order of declarations, limits on module size.
• Security and portability rules: validate inputs, avoid unsafe functions, avoid platform-specific features where possible.

Coding guidelines vs standards: standards are mandatory and checkable; guidelines are recommended practices left to programmer's discretion.

Benefits: better readability, easier code review and debugging, simpler maintenance, uniform appearance across the team, fewer defects and faster onboarding. Compliance is verified by code reviews, inspections and static analysis tools.

The Software Requirements Specification (SRS) is called the black box specification because it describes the system purely from the outside: what the system must do (inputs, outputs and the externally visible relationship between them) without saying how it is to be designed or implemented internally. Like a black box, only the behaviour at the interface is visible; the internal structure is hidden.

Consequences:

• It treats the system as a function that maps inputs to outputs, so it specifies the external behaviour, performance, constraints and interfaces only.
• It contains no design or implementation decisions (no data structures, algorithms or language choices), leaving the designer free to choose them.
• It can be used for validation: the system can be tested against it by supplying inputs and checking outputs, without looking at the code.

Example: For an ATM cash withdrawal, the SRS states: "If the user enters a valid PIN and requests an amount that is a multiple of Rs 500 and not more than the balance and the daily limit, the system shall dispense that amount and print a receipt with the new balance; otherwise it shall display an error message." It does not say whether the balance check uses a hash table, a database index or which sorting method is used; those internal details are left to the design.

Project management is the application of knowledge, skills, tools and techniques to project activities so that a software project is completed on time, within budget and with the required quality. It covers planning, organizing, staffing, directing, monitoring and controlling, risk management and communication.

Project planning

Planning is done at the start, before development, and produces the project plan. Activities:

1. Define scope and objectives.
2. Estimate size, effort, cost and duration (e.g. using COCOMO or function points).
3. Identify tasks, resources and staffing.
4. Identify risks and quality, configuration and change plans.
5. Prepare the schedule and the Software Project Management Plan (SPMP).

Example: For an online shopping site, estimated size 20 KLOC; estimated effort 50 person-months; team of 5 gives about 10 months; risks such as payment-gateway integration are listed with mitigation.

Project scheduling

Scheduling distributes the estimated effort over the project timeline: tasks are identified, dependencies and durations assigned, and resources allocated. Tools are the work breakdown structure, Gantt chart (bars against time) and PERT/CPM network (critical path = longest path, which decides project duration).

Example:

Paths: A-B-C-E = 3+4+6+3 = 16 weeks (critical path); A-B-D-E = 3+4+3+3 = 13 weeks. So the project takes 16 weeks, and task D has 3 weeks of slack. Delaying any critical task delays the project.

Software requirement analysis and specification

Requirements engineering has two main parts. Requirements analysis studies the gathered requirements to understand the customer's real needs, remove ambiguity, inconsistency, incompleteness and conflicts, and to model the problem (e.g. with data flow diagrams, use cases, ER diagrams). Requirements specification records the analysed requirements in a precise, organized document, the Software Requirements Specification (SRS), which serves as the contract between customer and developer and the basis for design, testing and maintenance.

An SRS typically contains: introduction (purpose, scope, definitions), overall description, functional requirements, non-functional requirements (performance, security, reliability, usability), external interface requirements, design constraints and appendices. A good SRS is correct, unambiguous, complete, consistent, verifiable, modifiable and traceable.

Methods of requirement gathering (elicitation)

1. Interviews: structured or unstructured conversations with stakeholders; good for detailed information but time-consuming and subject to personal bias.
2. Questionnaires/surveys: written questions sent to many users; cheap for large groups, but limited depth.
3. Observation (ethnography/task analysis): watching users in their working environment to learn real processes that they may not articulate.
4. Document analysis: studying existing forms, reports, manuals and the current system.
5. Brainstorming and JAD (Joint Application Development) workshops: group sessions that generate and agree on requirements quickly.
6. Prototyping: building a quick mock-up so users can react to it and refine needs.
7. Use cases and scenarios: describing interactions between actors and the system to find functional needs.

In practice, several methods are combined, because each reveals different kinds of requirements.

Test case design techniques

A test case consists of an input, preconditions, and the expected output. The design aim is to find the maximum number of faults with the minimum number of test cases. The main techniques are:

1. Black-box (functional) techniques: tests are derived from the specification without looking at the code.

• Equivalence class partitioning: input domain is split into valid and invalid classes; one representative from each class is tested. E.g. for age 18 to 60: classes below 18, 18 to 60, above 60.
• Boundary value analysis: test at and next to the boundaries, e.g. 17, 18, 19, 59, 60, 61.
• Cause-effect graphing / decision table testing: combinations of conditions mapped to actions.
• State transition and error guessing are also used.

2. White-box (structural) techniques: tests are derived from the code structure.

• Statement coverage: every statement executed at least once.
• Branch (decision) coverage: every branch true and false at least once.
• Condition and path coverage: all conditions or independent paths (basis path testing with cyclomatic complexity $V(G) = E - N + 2$) are exercised.
• Data flow and loop testing.

Top-down vs bottom-up integration

• Top-down: start with the main control module, add lower modules using stubs. Advantages: major design and control flaws are found early, a working skeleton exists early. Disadvantages: needs many stubs, and low-level modules are tested late.
• Bottom-up: start with the low-level modules (using drivers), build upward. Advantages: no stubs, easy test-condition setup for the lowest modules, can start early and in parallel. Disadvantages: the program as a whole does not exist until the last module is added, so design flaws appear late.

Best choice: neither is universally best. For most projects top-down is preferred because top-level control and interface errors are the costly ones and are detected earliest. Bottom-up is better when the low-level utility or hardware-related modules are critical or the design is object-oriented with many reusable components. Often a combined (sandwich) approach is used.

Software engineering faces several challenges:

1. Heterogeneity: systems must run across different platforms, devices, networks and legacy systems and be integrated with them.
2. Business and social change (delivery): business needs change quickly, so software must be built and delivered faster, with shorter time to market.
3. Security and trust: software must be protected from attacks and be trustworthy, as it is embedded in critical areas such as banking, health and transport.
4. Scale: from tiny embedded devices to very large, internet-scale, distributed systems.
5. Changing and unclear requirements: customers often do not know exactly what they want and requirements keep changing.
6. Cost and schedule estimation: estimates of effort and time are frequently inaccurate, leading to overruns.
7. Quality and reliability: producing correct, maintainable, efficient software with limited testing resources.
8. Maintenance and legacy systems: old systems must be kept running and evolved at high cost.
9. Skilled people and teamwork: lack of trained staff, communication problems and distributed teams.
10. Rapid technology change: new languages, frameworks, cloud and AI demand continuous learning and adaptation.

Extreme Programming (XP) is an agile software development methodology that stresses customer satisfaction, frequent small releases, teamwork and responsiveness to changing requirements. It takes good engineering practices to the extreme level.

Core values/principles: communication, simplicity, feedback, courage and respect.

Key practices

• Planning game: customer writes user stories; the team estimates them and plans the release and iterations.
• Small releases: a working system is delivered every few weeks.
• Simple design: do the simplest thing that works; avoid designing for the future.
• Test-driven development: write unit tests before code; all tests must pass.
• Pair programming: two programmers work on one machine, giving continuous review.
• Refactoring: continuously improve the code structure without changing behaviour.
• Continuous integration: code is integrated and tested many times a day.
• Collective code ownership: anyone can change any code.
• Coding standards, metaphor, sustainable pace (40-hour week) and on-site customer.

Significance: XP reduces the cost of change, finds defects early through constant testing, keeps the customer involved, and improves code quality and morale. Its practices (TDD, CI, refactoring, user stories) have been absorbed into modern agile and DevOps methods such as Scrum. It works best for small to medium teams and projects with vague or changing requirements, and is less suitable for large, safety-critical or geographically distributed projects.

Regression testing is the re-execution of previously run tests on a modified program to confirm that the changes (bug fixes, enhancements, configuration changes) have not introduced new faults or broken existing functionality. It is done mainly during maintenance and at every build in iterative development.

Designing regression test cases

The regression suite is built and kept from existing tests, and handled by these strategies:

1. Retest all: run the whole existing suite. Safe but expensive.
2. Regression test selection: choose only the tests that exercise the modified code and the parts affected by it (impact analysis, using traceability between requirements, code and tests).
3. Test case prioritization: order tests so those with the highest risk, coverage or fault-finding history run first.
4. Test suite minimization: remove redundant or obsolete tests.

The suite comprises:

• tests covering the changed or fixed component (including a new test reproducing the fixed bug),
• tests of components that interact with it, and
• a representative sample of tests of the unchanged functionality (sanity/smoke tests).

New tests are added for new features, outdated ones are updated, and the suite is automated with tools (JUnit, Selenium) so it can run repeatedly at low cost.

User interface (UI) design is the process of designing the means by which users interact with the software: screens, menus, forms, icons, commands, messages and feedback. The goal is a UI that is easy to learn and use and helps users achieve their tasks effectively.

Main principles

• User familiarity: use terms and concepts familiar to users, not computer jargon.
• Consistency: the same operations, layouts, colours and terminology throughout.
• Minimal surprise: the system behaves as the user expects.
• Recoverability: provide undo, confirmation for destructive actions and error recovery.
• User guidance: meaningful feedback, helpful error messages and context-sensitive help.
• User diversity: accommodate novices and experts, and users with disabilities (accessibility).
• Simplicity and minimal memory load: show options rather than require recall; keep the interface uncluttered.
• Visibility of system status: inform users about what is happening.

Impact on user experience and success

A well-designed UI increases usability, satisfaction and productivity, reduces training time, support cost and user errors, and encourages adoption and retention. Users judge a product largely by its interface, so a good UI gives competitive advantage, whereas a poor one causes frustration and abandonment, however powerful the functionality may be.

Programming languages are the notations in which the design is expressed as executable code (e.g. Java, Python, C, C++). Development tools are the software utilities that support building, analysing and managing that code through the whole life cycle: editors/IDEs, compilers, debuggers, build tools (Maven, Make), version control (Git), testing frameworks (JUnit), profilers and CASE tools.

Relationship

• A language alone gives only the means of writing instructions; tools make the writing, checking, running and managing efficient.
• Each language comes with its own ecosystem of tools (compilers/interpreters, package managers, libraries, IDE plugins), and the choice of language influences which tools can be used.
• Tools in turn exploit language features, e.g. static type checking, linters and refactoring tools rely on the language's syntax and semantics.

How they complement each other

• The language provides abstraction, structure and expressiveness (modules, classes, types); tools enforce, automate and verify them (static analysers, formatters, code generators).
• IDEs with syntax highlighting, code completion and debuggers raise productivity and reduce errors.
• Version control and build tools support teamwork, integration and release.
• Testing and profiling tools measure quality and performance of the code written in the language.

Together they improve productivity, quality, maintainability and portability of software. A good selection considers the problem domain, team skills, available libraries and tool support.

The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI), is a framework for evaluating and improving the maturity of an organization's software process. It defines five maturity levels, each a plateau on the way to a disciplined, continuously improving process.

1. Level 1, Initial: the process is ad hoc and chaotic; success depends on individual effort; schedules, costs and quality are unpredictable.
2. Level 2, Repeatable: basic project management is established (planning, tracking, requirements management, configuration management, quality assurance), so successes can be repeated on similar projects.
3. Level 3, Defined: a standard, documented software process is used across the organization, with training and peer reviews; it is tailored for each project.
4. Level 4, Managed: detailed process and product metrics are collected; the process and quality are quantitatively measured and controlled.
5. Level 5, Optimizing: continuous process improvement driven by quantitative feedback, defect prevention and the introduction of innovative ideas and technologies.

An organization moves from level to level by satisfying the key process areas of each level.

Versioning (version control) in software engineering is the practice of assigning identifiers to successive states (versions, revisions, releases) of software items such as source code, documents and configuration files, and managing and recording the changes between them. It is a core part of configuration management and is done with tools such as Git, SVN or Mercurial.

Concept

• Each change produces a new version identified by a number (e.g. 2.1.3 = major.minor.patch) or a hash/revision ID.
• The history of each item is stored with who changed what, when and why.
• Branching allows parallel lines of development (features, bug fixes, releases) and merging combines them.
• Tagging marks released baselines.
• Variants and releases of a product can be tracked separately.

Importance

• Change tracking and history: it is possible to see, compare and audit every change.
• Rollback: a faulty change can be reverted to a stable earlier version.
• Collaboration: many developers work on the same codebase concurrently without overwriting each other's work, with conflicts detected at merge.
• Parallel development: features, hot-fixes and releases proceed in branches.
• Release management and maintenance: old versions in use at customer sites can be reproduced and patched; builds are reproducible.
• Backup and traceability: links changes to requirements and defect reports.
• Quality: supports code reviews and continuous integration.

CASE (Computer-Aided Software Engineering) tools are software tools that automate or support the activities of the software life cycle, such as analysis, design, coding, testing, documentation and project management. They provide a repository, diagramming, code generation and consistency checking, thereby improving productivity and quality.

Types of CASE tools

• Upper CASE tools: support the early phases (planning, requirements, analysis and design). Examples: Visible Analyst, Enterprise Architect, Rational Rose, draw.io for DFD, ER and UML diagrams.
• Lower CASE tools: support the later phases (coding, testing, maintenance). Examples: compilers, debuggers, code generators, JUnit, Selenium, SonarQube.
• Integrated CASE (I-CASE): cover the whole life cycle with a shared repository, e.g. IBM Rational suite.
• By function: diagramming, prototyping, documentation, configuration management (Git, SVN), project management (MS Project, Jira), testing and reengineering tools.
• By scope: tools (single task), workbenches (a set of integrated tools for one phase) and environments (support across phases).

Features

• Central repository (data dictionary) storing all project information
• Diagramming and modelling support (DFD, ER, UML)
• Automatic consistency and completeness checking of models
• Code and report/document generation
• Prototyping and simulation
• Version and configuration control
• Team collaboration and traceability

Benefits

• Higher productivity and faster development
• Improved quality through early error detection
• Standardized, up-to-date documentation
• Easier maintenance and reuse
• Better communication within the team and with the customer
• Reduced cost of changes

Drawbacks are the cost of tools, training and the learning curve.

Use across the life cycle

Requirements validation

Requirements validation checks that the documented requirements actually define the system the customer wants, and that they are correct, complete, consistent, realistic and verifiable. It is done before design, because errors found later cost far more to fix.

Checks performed: validity (does the system really need this function?), consistency (no conflicting requirements), completeness (all functions and constraints are covered), realism (feasible with available technology and budget), verifiability (testable) and traceability.

Methods:

• Requirements reviews/inspections/walkthroughs by developers, clients and users
• Prototyping so users can try the system
• Test case generation from the requirements; if a test cannot be written, the requirement is likely unclear
• Automated consistency analysis using CASE tools
• Checklists

Challenges: users cannot always visualize the system, stakeholders disagree, requirements keep changing, the reviews are time-consuming, and subtle conflicts are hard to spot.

Example: "The system shall be user-friendly" fails validation because it cannot be verified; it is rewritten as "A new user shall be able to place an order within 3 minutes of training".

Requirements specification

It is the process of writing the agreed requirements down unambiguously in the Software Requirements Specification (SRS). It forms the contract between client and developer and the base of design, testing, estimation and maintenance.

Contents: introduction, overall description, functional requirements (often as use cases or "The system shall..." statements), non-functional requirements (performance, security, usability), interface requirements and constraints.

Methods/notations: structured natural language, templates, graphical models (DFD, UML use case, ER), decision tables and formal specifications (Z, VDM) for critical systems.

Challenges: natural language is ambiguous, balancing detail with readability, keeping the document consistent as changes occur, and separating what from how.

Example: "FR-3: When a registered borrower submits a valid book ID, the system shall record the loan and set the due date to 14 days later."

Significance: validated and well-specified requirements reduce rework, cost and schedule overruns, and give the basis for acceptance testing and customer satisfaction.

Modular decomposition is the process of breaking a software system into smaller, manageable, interrelated parts (subsystems and modules) according to a chosen strategy, so that each module can be designed, implemented, tested and maintained separately. Approaches include function-oriented decomposition (each module performs a function, top-down refinement) and object-oriented decomposition (each module is a class/object encapsulating data and operations). At the architecture level, subsystems are decomposed into modules.

Importance

• Manages complexity by "divide and conquer".
• Parallel development by several programmers or teams.
• Easier testing and debugging, as modules are tested in isolation.
• Maintainability: changes are localized to a few modules.
• Reuse of modules across projects.
• Better understanding and estimation of the project.

Guiding principles

1. High cohesion: a module should do one thing, with all its elements closely related.
2. Low coupling: minimal and simple dependencies between modules (data coupling preferred over control, common or content coupling).
3. Information hiding: the internals are hidden behind a stable interface.
4. Abstraction: users of a module see only what it does.
5. Single responsibility and functional independence.
6. Appropriate size and fan-in/fan-out: not too big, not too many tiny modules; a limited number of subordinates per module.
7. Well-defined interfaces and a hierarchical structure.

Example

An online banking system is decomposed into modules: Authentication, Account Management, Fund Transfer, Transaction History and Notification. Fund Transfer calls Account Management through a defined interface (debit(acc, amt), credit(acc, amt)) and hides how balances are stored. If the notification channel changes from SMS to email, only the Notification module changes. In object-oriented form the same split gives classes User, Account, Transfer, Notifier.

Key challenges facing software engineering

1. Heterogeneity: software must work across varied platforms, devices and legacy systems.
2. Delivery pressure: businesses demand faster delivery and quick response to change.
3. Trust and security: protecting against attacks and ensuring dependable software, especially in critical applications.
4. Scale: building systems from tiny embedded ones to huge distributed ones.
5. Changing requirements and inaccurate estimation of cost and time.
6. Maintaining quality and managing legacy systems and rapidly changing technologies.

Attributes of good software

• Maintainability: it can be evolved to meet changing needs.
• Dependability and security: reliable, safe, and secure; no physical or economic damage in case of failure; protected from malicious users.
• Efficiency: does not waste memory or processor time; good response time and resource utilization.
• Acceptability (usability): understandable, usable and compatible with the systems its users already use.
• Also correctness, portability and reusability.

Model-View-Controller (MVC) is an architectural pattern that separates an application into three interconnected components so that data, presentation and control logic are independent.

• Model: holds the application data and business logic/rules; it notifies the views when its state changes. It is independent of the user interface.
• View: displays the model's data to the user (screens, HTML pages, charts). There can be multiple views of the same model.
• Controller: receives user input (clicks, requests), interprets it, and updates the model and/or selects the view.

Flow: the user acts on the View, which sends the event to the Controller; the Controller updates the Model; the Model changes state and informs the View, which refreshes the display.

Advantages: separation of concerns, multiple views of the same data, parallel development by UI and logic teams, easier testing and maintenance, and reuse of the model.

Disadvantages: added complexity for simple applications, and many updates between components.

Example: in a web shop, the Model is Product and Order classes with the database; the View is the product listing page; the Controller handles "Add to cart" requests. Frameworks such as Spring MVC, Django and Laravel use this pattern.

Human-Computer Interaction (HCI) is the study of how people interact with computers and of the design of interactive systems that are usable, useful and satisfying. It draws on psychology, ergonomics, design and computer science.

Role of HCI in user interface (UI) design

• Understanding users: HCI methods (user analysis, task analysis, personas) discover who the users are, their goals, skills, limitations and context, so the UI fits them.
• Providing principles and guidelines: consistency, feedback, visibility, error prevention, minimal memory load, and Nielsen's heuristics guide design decisions.
• Models of human behaviour: knowledge of human perception, memory and cognition (e.g. Fitts' law, limits of short-term memory) shapes layout, menus and information amount.
• Usability evaluation: prototyping, usability testing and heuristic evaluation find problems early and drive iterative improvement.
• Accessibility and diversity: ensures use by novices, experts and users with disabilities.
• Choosing interaction styles: menus, forms, command language, direct manipulation, touch or voice.

Result: interfaces that are easy to learn, efficient, less error-prone and satisfying, which improve productivity and acceptance of the software.

Software re-engineering is the examination, analysis and restructuring of an existing (legacy) software system to reconstitute it in a new, more maintainable form, without changing its functionality. It is used when a system is valuable but has poor structure, outdated technology or poor documentation, and is cheaper than rewriting from scratch.

Re-engineering process

Existing system
      |
Inventory analysis
      |
Document restructuring
      |
Reverse engineering  --->  recovered design / specification
      |
Code restructuring
      |
Data restructuring
      |
Forward engineering
      |
Re-engineered system

1. Inventory analysis: list applications and select those worth re-engineering by business value, age and maintainability.
2. Document restructuring: produce or update the necessary documentation.
3. Reverse engineering: analyse the code and recover its design, data and specifications.
4. Code restructuring: clean up the source code (control-flow simplification, naming) without altering behaviour.
5. Data restructuring: redesign data structures and database schema.
6. Forward engineering: regenerate the system with a modern design, tools and platform, and test that it behaves as the original.

Cohesion is the degree to which the elements within a single module belong together (intra-module strength). Coupling is the degree of interdependence between different modules (inter-module strength). Good design aims at high cohesion and low coupling.

Example of cohesion

• Low (coincidental): a module Utility containing printReport(), calculateTax() and openFile().
• High (functional): a module calculateTax() that does only tax computation.

Example of coupling

• High (common coupling): two modules read and modify the same global variable balance; a change in one breaks the other.
• Low (data coupling): transfer(fromAcc, toAcc, amount) calls debit(acc, amount), passing only the required data parameters.

The Software Project Management Plan (SPMP) is the document prepared at the start of a project (after the feasibility study and SRS) that describes how the project will be managed, so that it is completed on time, within budget and with quality. It is the main reference for the manager, the team and the customer to track progress.

Typical contents

1. Introduction: project overview, objectives, scope, deliverables, definitions.
2. Project estimation: size (LOC/function points), effort, cost and duration, using models such as COCOMO.
3. Project organization and staffing: team structure, roles, responsibilities, and resource requirements (people, hardware, software tools).
4. Schedule: work breakdown structure, task dependencies, milestones, Gantt/PERT charts.
5. Risk management plan: identified risks, probability and impact, mitigation and contingency plans.
6. Quality assurance plan: standards, reviews, inspections and testing.
7. Configuration management plan: version control and change control procedure.
8. Project tracking and control: monitoring, reporting and review mechanisms.
9. Communication, training and delivery/maintenance plan.

Importance: it gives a roadmap, helps in resource allocation, enables early detection of deviations and gives a base for contractual commitments. It should be updated as the project changes.

Spiral model

Proposed by Barry Boehm (1986), the spiral model is a risk-driven, evolutionary process model that combines the iterative nature of prototyping with the controlled, systematic aspects of the waterfall model. The project is represented as a spiral: each loop is one phase of the software process, and the radius represents the cumulative cost. Each loop passes through four quadrants:

1. Objective setting (planning): determine the objectives, alternatives and constraints for this phase and gather requirements.
2. Risk analysis and resolution: identify and assess risks; resolve them with prototyping, simulation, benchmarking or other analysis. If risks are too high, the project may be stopped.
3. Development and validation (engineering): develop and test the next level of the product (concept, requirements, design, code).
4. Review and planning: the customer evaluates the result, and the plan for the next loop is made.

The innermost loop typically covers concept feasibility, then requirements, then design, and later loops build the final product. Each pass produces a more complete version.

Advantages: explicit risk management, flexible to changing requirements, early prototypes and constant customer feedback, suitable for large systems.

Disadvantages: needs risk-assessment expertise, can be costly and time-consuming, complex to manage, and not suitable for small projects.

Recommended for

• Large, complex, high-risk projects
• Projects with unclear or evolving requirements
• Projects using new technology or where cost and risk evaluation is important
• Long-term projects where major changes are expected and releases are done in stages (e.g. defence, banking or telecom systems)
• Not suited to small, low-risk projects with well-understood requirements, where waterfall or incremental is cheaper.

Requirements elicitation and analysis

This is the process of finding out what the system's stakeholders need and then refining and organizing those needs into agreed requirements. The generic steps are:

1. Requirements discovery (elicitation): interact with stakeholders (users, managers, domain experts) and study documents to collect needs and domain information.
2. Requirements classification and organization: group related requirements into clusters (e.g. by subsystem) and organize them logically.
3. Requirements prioritization and negotiation: conflicts between stakeholders are identified and resolved; requirements are ranked by importance (e.g. MoSCoW).
4. Requirements specification: the agreed requirements are documented formally (SRS) for the next development phase.

The process is iterative, and every cycle refines understanding. Analysis includes checking for ambiguity, incompleteness and feasibility.

Interviews

Formal (closed or open, structured) or informal conversations with stakeholders. Closed interviews use pre-set questions; open interviews explore issues freely. They reveal what users do, their problems and expectations and the domain terms. Limitations: users may use domain jargon, forget implicit knowledge, or be biased; hence interviews are combined with other methods.

Scenarios

A scenario is a narrative description of how the system is used in a particular situation: the starting situation, normal flow of events, what can go wrong, other concurrent activities and the end state. Scenarios are easy for users to understand and comment on, so they help elicit detailed, concrete requirements and uncover exceptional cases. Example: "A borrower logs in, searches for a book, reserves it; if the book is unavailable, the system offers to join a waiting list."

Use cases

A use case describes a set of interactions between an actor (user or external system) and the system to achieve a goal, drawn as a UML use case diagram and described textually (actor, preconditions, main flow, alternative flows, postconditions). Each scenario is an instance of a use case. Use cases identify the actors and functions of the system, give a high-level view for stakeholders and the base for design and test cases. Example: Borrow Book (actor: Member) with included Check Availability.

Together, interviews gather raw needs, scenarios give them concrete context, and use cases organize them into a structured functional model.

(a) COCOMO model

COCOMO (Constructive Cost Model), by Barry Boehm, is an algorithmic model that estimates the effort (person-months), development time (months) and average staffing of a software project from its estimated size in KLOC. Basic COCOMO uses

$E = a\,(KLOC)^b, \qquad D = c\,E^d, \qquad \text{Staff} = E/D$

with constants depending on the project class:

Intermediate COCOMO multiplies the effort by an adjustment factor from 15 cost drivers (reliability, complexity, personnel capability, tools, etc.); Detailed COCOMO applies the drivers phase-wise.

Significance: it gives an early, repeatable and quantitative estimate for budgeting, scheduling and staffing, allows comparison of alternatives (e.g. effect of team capability), and shows that effort grows non-linearly with size ($b > 1$). It depends on an accurate size estimate and must be calibrated for local conditions.

(b) Black-box vs white-box testing

System engineering is the interdisciplinary process of defining, designing and managing a complete system, which may consist of hardware, software, people, data, documentation and procedures, so that its elements work together to meet stakeholder needs. For computer-based systems it involves determining system requirements, allocating functions to hardware, software, people and database, and then integrating and testing the whole. Software engineering is one part of it, taking over once software requirements have been allocated.

Types of software

1. System software: manages and supports the computer hardware, e.g. operating systems, device drivers, compilers, utilities.
2. Application software: performs specific tasks for users, e.g. word processors, payroll, banking systems.
3. Engineering/scientific software: number crunching for science and engineering, e.g. simulation, CAD, MATLAB.
4. Embedded software: resides in a product to control hardware, e.g. in washing machines, cars, medical devices.
5. Product-line software: a reusable solution for many customers, such as inventory control, word processing or multimedia.
6. Web/mobile applications: websites and apps delivered over the web or on mobile devices.
7. Artificial intelligence software: uses non-numerical algorithms, e.g. expert systems, pattern recognition, machine learning.
8. Real-time software: responds within strict time limits, e.g. air traffic control.
9. Generic vs customized software: generic products are sold on the open market; customized software is developed for a specific customer.

Online Library Management System: use case diagram (borrowing and returning books)

Actors: Member (borrower), Librarian, Payment/Notification service (secondary actor).

Use cases: Login, Search Book, Borrow Book, Return Book, Renew Book, Pay Fine, Reserve Book, Manage Books and Members (Librarian), Send Notification.

 Member -----> (Login)
   |-------> (Search Book)
   |-------> (Borrow Book)   <<include>> (Login), <<include>> (Check Availability)
   |-------> (Return Book)   <<extend>>  (Pay Fine)
   |-------> (Renew Book)
   |-------> (Reserve Book)
 Librarian --> (Manage Books/Members), (Approve Borrow/Return)
 Notification Service <-- (Send Notification)

Use case description: Borrow Book

Use case description: Return Book

Fault detection capability of black-box and white-box testing

Conclusion: the two are complementary. Black-box testing is better at finding faults of omission and requirement mismatch, while white-box testing is better at finding faults of commission within the code. A good test strategy applies both (grey-box) to maximize fault detection.

Test cases for login functionality of a Hospital Management System

Preconditions: the system is running; the valid user is registered, e.g. username dr.sharma, password Hosp@123, role Doctor.

Status of each test: Pass/Fail is recorded after execution.

Role of re-engineering in extending software life

Re-engineering restructures and modernizes an existing system without changing its function. Evaluated against the aim of extending life:

• Restores maintainability: old systems degrade as repeated changes make the code complex. Restructuring code and data, and updating documentation, makes further changes possible and cheaper, so the system stays useful longer.
• Cheaper than replacement: rewriting a large legacy system is costly and risky, and loses embedded business knowledge. Re-engineering reuses valuable logic at a fraction of the cost and risk.
• Adapts to new technology: migrating to new languages, platforms, databases or architectures (e.g. mainframe to web or cloud) keeps the system compatible with its environment, avoiding obsolescence.
• Recovers lost knowledge: reverse engineering rebuilds design and documentation that were missing, reducing dependence on departed staff.
• Improves quality and performance: removes dead code and defects, and improves reliability and efficiency.
• Enables new features and integration: a cleaner structure allows easier enhancement and interfacing with modern systems.

Limitations: it cannot fix a fundamentally unsuitable architecture, requires time and expertise, risks introducing new defects (needs thorough regression testing), and beyond some point replacement becomes more economical.

Judgement: where the system still has high business value but poor quality, re-engineering is an effective and economic way to extend its life; for low-value systems retirement or replacement is better.

Validation is the process of evaluating the software at the end of development (or a phase) to check that it meets the customer's actual needs and intended use; it answers "Are we building the right product?" It is done by dynamic testing, such as system and acceptance testing (alpha and beta), and by reviews with users. It is distinct from verification ("Are we building the product right?"), which checks conformance of each phase's output to its specification, usually through reviews and inspections.

Types of maintenance

1. Corrective: fixes faults found after delivery (e.g. patching a bug that crashes the report module).
2. Adaptive: modifies the software for changes in its environment such as a new operating system, hardware or regulations.
3. Perfective: enhances functionality or improves performance and usability on user requests (e.g. adding an export feature).
4. Preventive: restructures or documents the software to make future maintenance easier and avoid problems (e.g. refactoring, updating documents).

Corrective maintenance is typically around 20 percent of the effort, while perfective maintenance is the largest share.

(a) ISO 9000

ISO 9000 is a family of international standards on quality management systems published by the International Organization for Standardization. ISO 9001 is the standard against which organizations are certified. It specifies the requirements for a quality system that ensures a company consistently provides products and services meeting customer and regulatory requirements. For software, ISO 9000-3 gives guidelines to apply it to development, supply and maintenance.

Key points:

• Based on principles such as customer focus, leadership, process approach, involvement of people and continual improvement.
• Requires documented procedures, a quality manual, records, management review and internal audits.
• Certification is granted by an accredited external body after an audit and is renewed periodically.
• Merits: improves customer confidence, process discipline and competitiveness, and is often required for tenders.
• Demerits: it emphasizes documentation and conformance to the organization's own defined process, not product quality directly; it does not define the level of process quality, unlike CMM.

(b) White-box testing

White-box (glass-box or structural) testing designs test cases using knowledge of the internal code structure and logic. The tester examines paths, branches, conditions and loops to make sure they behave correctly.

Techniques:

• Statement coverage: every statement is executed at least once.
• Branch/decision coverage: each decision takes both true and false outcomes.
• Condition and path coverage.
• Basis path testing using cyclomatic complexity $V(G) = E - N + 2$, which gives the number of independent paths.
• Loop and data-flow testing.

Merits: finds logic errors and dead code, and gives measurable coverage. Demerits: needs programming expertise and source code, is costly for large programs, and cannot find missing functionality. Mostly applied during unit testing.

(c) CASE tool

CASE (Computer-Aided Software Engineering) tools are software applications that support and automate activities of the software life cycle, such as requirements capture, analysis and design modelling, code generation, testing, configuration management and project management.

• Types: upper CASE (analysis and design), lower CASE (coding, testing), integrated CASE (whole life cycle).
• Features: central repository, diagram drawing (DFD, ER, UML), consistency checking, code and document generation.
• Examples: Enterprise Architect, Rational Rose, StarUML, Git, JUnit, MS Project.
• Benefits: higher productivity, better quality and documentation, easier maintenance and communication. Costs: purchase price and training.

Layered architectural model

The layered architecture organizes the system into a hierarchy of layers, where each layer provides services to the layer above and uses services of the layer below. Layers are built on the abstraction principle and each has a well-defined interface, so that a layer can be replaced if its interface is kept.

Typical layers (from top):

1. User interface / presentation layer
2. Application/business logic layer
3. Core services / data access layer
4. System support (operating system, database, network)

Examples: the OSI network model and 3-tier web applications.

Advantages: separation of concerns, easier maintenance and replacement, portability (only the lowest layer is platform dependent), reuse, and incremental development. Disadvantages: clean separation is difficult in practice, performance overhead due to passing through several layers, and changes to a low layer can propagate upward.

Main activities of requirements engineering

1. Feasibility study: decides whether the system is technically, economically and operationally worthwhile.
2. Requirements elicitation and analysis: gathering requirements from stakeholders (interviews, observation, scenarios, use cases), classifying, prioritizing and resolving conflicts.
3. Requirements specification: documenting requirements precisely in the SRS.
4. Requirements validation: checking the requirements for correctness, completeness, consistency and realism through reviews and prototyping.
5. Requirements management: controlling changes to the requirements during the project and maintaining traceability.

Characteristics of a good SRS

• Correct: every requirement stated is one that the system must meet.
• Unambiguous: each requirement has only one interpretation.
• Complete: includes all functional, non-functional and interface requirements.
• Consistent: no conflicts among requirements.
• Verifiable: each requirement can be tested objectively.
• Modifiable: well structured so that changes can be made easily without redundancy.
• Traceable: every requirement is uniquely identified and can be traced to its source and to design and test.
• Ranked for importance/stability.
• Understandable by customer and developer, and design independent (black-box specification).

Challenges in software project scheduling

• Inaccurate estimation: size, effort and duration are hard to estimate early because requirements are uncertain.
• Changing requirements force rescheduling.
• Task dependencies and parallelism: identifying dependencies and the critical path is hard; adding people to a late project does not proportionally speed it up (Brooks' law).
• Resource constraints: shortage or uneven availability of skilled staff and tools.
• Risks and unforeseen events: staff turnover, technical problems, third-party delays.
• Intangibility of software: progress is difficult to measure objectively.
• Pressure to meet unrealistic deadlines, and balancing time, cost and quality.
• Integration and communication overhead in large or distributed teams.

Technique 1: Work breakdown structure with Gantt chart

The project is broken into tasks; each gets a duration and start and end dates. A Gantt chart shows tasks as horizontal bars on a time axis, with milestones.

The project finishes at the end of week 16. It is simple and gives a clear view of progress, but does not show dependencies strongly.

Technique 2: PERT/CPM network (critical path method)

Tasks are drawn as a network showing dependencies; the longest path through the network is the critical path and decides the project duration. In PERT, the expected time of a task is

$t_e = \frac{O + 4M + P}{6}$

where $O$ is optimistic, $M$ most likely and $P$ pessimistic time.

Example:

Path A-B-C-E = 3+4+6+3 = 16 weeks; path A-B-D-E = 3+4+3+3 = 13 weeks. The critical path is A-B-C-E, so the project needs 16 weeks. Task D has a slack of $16 - 13 = 3$ weeks and can be delayed without affecting the finish, whereas any delay in A, B, C or E delays the project. Managers focus resources on critical tasks.

Principles of agile software development

Agile methods follow the Agile Manifesto, which values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The key principles are:

1. Customer involvement: customers are closely involved, providing and prioritizing requirements and evaluating iterations.
2. Incremental delivery: software is delivered in small, frequent increments (weeks), with customers specifying the requirements for each.
3. People, not process: the skills of the team are recognized and the team is free to work its own way.
4. Embrace change: expect requirements to change, and design the system to accommodate this.
5. Maintain simplicity: simplify both the software and the process; eliminate unneeded complexity.
6. Also: sustainable pace, face-to-face communication, technical excellence, self-organizing teams and regular reflection.

How Extreme Programming (XP) implements them

In XP, user stories are written on cards, estimated and scheduled; developers write tests first, code in pairs, integrate several times a day, and release small working increments for customer feedback. The values of communication, simplicity, feedback, courage and respect underlie these practices.