HKIE Professional Assessment - Information Discipline key terms

A staged framework covering feasibility, requirements, design, build, testing, deployment and maintenance, used to plan and control a software project from inception to retirement.

The practice of linking each requirement forward to design elements, code and tests, and backward to its source, so coverage and change impact can be verified.

A sequential delivery approach in which each phase completes before the next begins, with limited rework, suited to stable requirements and contract-driven projects.

An iterative approach delivering working increments in short cycles, guided by continuous customer feedback, prioritised backlogs and adaptive planning rather than fixed upfront specification.

A lightweight agile framework using fixed-length sprints, defined roles such as product owner and scrum master, and ceremonies including daily stand-up, sprint review and retrospective.

The smallest release that delivers real user value and allows validated learning, used to test assumptions cheaply before committing to full-scale build.

Formal testing against agreed criteria, performed by or for the customer, to confirm a delivered system meets business requirements before it is accepted into service.

Specific, testable conditions that a deliverable must satisfy to be accepted by the user, typically written alongside each requirement or user story.

A nominated group that reviews, approves, defers or rejects proposed changes to a baselined system or project, balancing benefit against cost, risk and schedule.

The disciplined identification, control, status accounting and audit of system components and their versions, ensuring the correct items are built, released and supported.

A tool-supported practice that records every change to source code or documents, enabling history review, branching, merging and rollback to earlier states.

An engineering practice where developers merge small changes frequently and each merge triggers automated build and test, exposing integration defects early.

A pipeline discipline keeping software in a deployable state at all times, with automated build, test and release steps so deployment to production is routine and low-risk.

A collaborative culture and toolchain that unites development and operations teams to shorten delivery cycles, automate releases and improve production reliability through shared ownership.

An operations discipline applying software engineering to run production systems, using service level objectives, error budgets and automation to balance reliability against change velocity.

A contract between a service provider and customer defining measurable service commitments such as availability, response time, support hours and remedies for shortfall.

The average elapsed time to restore service after an incident, a key reliability indicator that measures resilience rather than the frequency of failure alone.

The process for detecting, logging, prioritising, resolving and reviewing service disruptions, restoring normal operation quickly and capturing lessons to prevent recurrence.

A structured investigation, often using techniques such as the five whys or fishbone diagrams, to identify underlying causes of a fault rather than treating symptoms.

A maintained log of identified project or system risks, each with likelihood, impact, owner and mitigation action, reviewed regularly through the project lifecycle.

Documented arrangements for maintaining or restoring critical business functions during and after disruption, covering people, premises, systems, data and communications.

The technical subset of continuity planning describing how IT services and data are restored after a major failure, including backup, standby sites and activation procedures.

The maximum acceptable duration that a business process or system may remain unavailable after disruption, driving the design of recovery capability and standby arrangements.

The maximum acceptable amount of data loss measured in time, determining how frequently backups or replication must occur to meet business expectations.

An approved, frozen snapshot of requirements, design or configuration against which subsequent change is measured and controlled through formal change procedures.

A holistic description of an organisation's business, data, application and technology layers, used to align IT investment with strategy and guide controlled evolution.

A widely used cyclic method for developing and governing enterprise architecture, running from architecture vision through business, information systems and technology layers to migration planning.

An ontology that classifies architecture artefacts by stakeholder perspective and by interrogative dimension such as data, function, network, people, time and motivation.

A design style exposing business capabilities as loosely coupled, discoverable services with defined contracts, so they can be reused and composed across systems.

An architectural style decomposing an application into small independently deployable services, each owning its data and communicating over lightweight network protocols.

A defined contract allowing one software component to request services from another, specifying operations, data formats, authentication and error behaviour.

Packaging an application with its dependencies into an isolated, portable runtime image that behaves consistently across development, test and production environments.

On-demand delivery of computing resources over a network with self-service provisioning, elasticity and measured usage, offered as infrastructure, platform or software services.

Abstracting physical computing resources so multiple isolated virtual machines or environments share the same hardware, improving utilisation and operational flexibility.

Software that stores data in tables with defined relationships and enforces integrity through keys and constraints, queried using a structured query language.

Structuring relational tables to eliminate redundant data and update anomalies, progressively applying rules of increasing strictness known as normal forms.

Four guarantees for reliable transactions: atomicity, consistency, isolation and durability, ensuring that partial or conflicting updates do not corrupt stored data.

A principle stating that a distributed data system cannot simultaneously guarantee consistency, availability and partition tolerance, so designers must choose trade-offs.

A consistency model in which replicas may temporarily diverge but converge over time, accepted where availability and partition tolerance outweigh immediate consistency.

Copying data across multiple nodes or sites to improve read performance, availability and disaster resilience, with mechanisms to propagate and reconcile updates.