Terms and definitions

Term	Definition
Application/Solution Governance Board	A board with members from the business and the technical development teams that provide governance over an application or solution. Such boards may include technical and non-technical sub-committees and may include members related to enabling or dependent systems/applications.
Architecting	Process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle [5].
Architecture	Fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [5].
Architecture Description (AD)	A work product used to express an architecture [5].
Architecture Description Language (ADL)	Any form of expression for use in architecture descriptions, for example the Unified Modelling Language (UML) or ArchiMate [5].
Architecture Framework	Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders (e.g. The Open Group Architecture Framework (TOGAF), Generalised Enterprise Reference Architecture and Methodologies (GERAM), Kruchten’s 4+1 view model) [5].
Architecture View	A work product expressing the architecture of a system from the perspective of specific system concerns. A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns [5].
Architecture Viewpoint	A work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns. In other words, a viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [5].
Business	An organisational unit that owns a solution, system or application and usually sponsors its development, maintenance and support and is as one of its important stakeholders.
Concern	Interest in a system relevant to one or more of its stakeholders [5].
Enterprise Architecture	There are two definitions for enterprise architecture: 1. The organizing logic for business processes and IT infrastructure reflecting the integration and standardisation requirements of the firm’s operating model. [Source: MIT Centre for Information Systems research] 2. A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives [6]. This level of architecture is associated with the highest level of abstraction and lowest level of details, as opposed to Solutions Architecture and Software Architecture.
Enterprise Architecture Board	A cross-organization board to oversee the implementation of the enterprise architecture. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall enterprise architecture [6].
Development Activity	A set of activities with a goal to develop and deliver a ‘single’ release of a system or solution in its production environment.
Life cycle	Evolution of a system, product, service, project or other human-made entity from conception through retirement [7].
Life cycle model	Framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding [7]. The life cycle processes are based on principles of ownership (a process is associated with a responsibility) and modularity. That is, the processes are: a) Strongly cohesive, meaning that all the parts of a process are strongly related; b) Loosely coupled, meaning that the number of interfaces among the processes is kept to a minimum [4]. In a way, this SDLC handbook tries to describe DET’s systems life cycle model.
Model Kind	Conventions for a type of modelling. Examples of model kinds include data flow diagrams, class diagrams, Petri nets, balance sheets, organization charts and state transition models [5].
Pre-Verification Environment	An environment used for Business Acceptance Testing. Majority of the business units know this environment as Zone 2. Some areas of the organization call it Quality Assurance (QA) or User Acceptance Test (UAT) environment.
Process	A set of interrelated or interacting activities which transforms inputs into outputs [7].
Process outcome	An observable result of the successful achievement of the process purpose [7].
Process purpose	A high level objective of performing the process and the likely outcomes of effective implementation of the process [7].
Process View	A representation of a set of processes in a life cycle (or process model) to provide visibility to a significant concept or thread that cuts across the processes of the life cycle. Unlike a process, the description of a process view does not include activities and tasks. Instead, the description includes guidance explaining how the outcomes can be achieved by employing the activities and tasks of the various processes in an existing process model or models [3].
Process Viewpoint	What a process view conforms to. A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines how to construct and use a view (by means of an appropriate schema or template). It could be viewed as binoculars from which a process can be viewed and what is seen through it forms the view [3].
Project	An endeavour with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements [7].
Quality assurance	All the planned and systematic activities implemented within the quality system, and demonstrated as needed, to provide adequate confidence that an entity will fulfil requirements for quality [7].
Release	A particular version of a configuration item, system or application that is made available for a specific purpose (for example, test release) [7].
Release Risk	Degree to which the use of a release causes uncertainty on intended objectives.
Release Unit	A release unit describes the portion of a service or IT infrastructure that is normally released together according to the organisation’s release policy [8].
SDLC Track	An SDLC Track is a traversal of SDLC stages with the goal to deliver a production release. For each release scope type, a different track may be taken throughout the SDLC.
SDLC Track Processes	The processes that are specific to SDLC tracks and have to performed at the beginning of each development activity irrespective of the scope type of the release. Such processes include “Life Cycle Model Management Process”, “Preliminary Information Classification Process”, “Preliminary Cloud Assessment Process”, and “Risk Assessment Process”.
Software Architecture	The high level structure of a software system, the discipline of creating such structures, and the documentation of these structures. This level of architecture is associated with the highest level of implementation-related details and is concerned with the software architectural design patterns and paradigms (e.g. the SOLID principles).
Solution Architecture	A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks [6]. Alternatively, solution architecture (SA) is an architectural description of a specific solution. SAs combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture (ESA) [Gartner (2013)]. Alternatively, defined as the architecture of a solution, where a solution is a system that offers a coherent set of functionalities to its environment. As such, it concerns those properties of a solution that are necessary and sufficient to meet its essential requirements [Greefhorst].
Stage	A period within the life cycle of an entity that relates to the state of its description or realization [7].
Stakeholder	Individual or organization having a right, share, claim or interest in a system or in its possession of characteristics that meet their needs and expectations [7].
System	A collection of components that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities [1].
Systems Development Technical Risk	The technical risk in systems development activities is the degree of uncertainty on the magnitude of difference between the actual and optimal design solutions. In this definition, the magnitude of difference is measured either by internal metrics of software quality or time or cost of design. From this standpoint, addressing technical risk management means to identify the magnitude of difference between optimal and current solutions, and minimize that difference as much as possible. Some example factors include multiple wishes in one requirement, inappropriate representation of requirements, untraceable requirements, notes and assumptions in requirements, unfeasible, unclear or untestable requirements, changes in requirements, adding requirements in late phases, inadequate architectural solutions, simple design mistakes, unrealistic time and cost estimates, over-flexible design which may make the solution difficult to maintain, dependence on external supplied components, dependency on other tasks, real-time performance shortfalls, error-prone, unmaintainable or unmanageable code, insufficient or ineffective testing, low number of builds on the integration branch, underestimating the delivery, mismanaging software variants, underestimation of defect turnaround time, and missing key-specialist in development [9].
Systems Development Business Risk	Systems Development Business Risk is the effect (either positive or negative) of uncertainty on business objectives caused due to the use of an IT/ICT system or solution which is under development. Business Risk management is the coordination of activities that direct and control the department with regard to risks (AS/NZS ISO 31000:2009 Risk management).
User	An individual or group that benefits from a system during its utilization [7].
Validation	Validation in a life cycle context is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives [7]. The Validation process determines that the right product is built [1].
Verification	Verification in a life cycle context is a set of activities that compares a product of the life cycle against the required characteristics for that product. This may include, but is not limited to, specified requirements, design description and the system itself [7]. The Verification process determines that the product is built right [1].