Category Archives: Thoughts on Standards

The System according to ISO, a short pedantic story

A System has a life cycle (“evolution of a system, product, service, project or other human-made entity from conception through retirement” ISO 15288), which embraces a 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” ISO 15288). Stages of that life cycle contain execution instances of processes (“set of interrelated or interacting activities which transforms inputs into outputs” ISO 9000). Processes always have a purpose (“high level objective of performing the process and the likely outcomes of effective implementation of theĀ  process” ISO 12207) and an outcome (“observable result of the successful achievement of the process purpose” ISO 12207) and typically these are a deliverable of some sort or another related to the system or the system itself in a new state (e.g., designed, integrated, verified, validated). The purpose always addresses a stakeholder objective (e.g., satisfy a need, achieve a goal). An organization (e.g., corporation, a business, a team) has commonality with a system. They meet many elements of the definition of a system (“combination of interacting elements organized to achieve one or more stated purposes” ISO 15288).

Entities perform processes, this is a role that an entity is responsible for. The responsibility is typically assigned by governance that controls the process (e.g., a contract, an activity, a task, a procedure). The execution of a process requires resources (“asset that is utilized or consumed during the execution of a process” ISO 15288). Resources might be schedule, budget, tools, facilities, people, etc… A resource has a role in the execution of a process. Roles perform or enable (when they are consumed by the process) process activities.
Execution of a thread of activities constitutes a process execution and delivers an outcome.

A system may require other systems during its life cycle and depends on their execution of processes, for which they are responsible, to accomplish a stage in its life cycle. These systems are “Enabling Systems” (“system that supports a system-of-interest during its life cycle stages but does not necessarily contributeĀ  directly to its function during operation” ISO 15288).
One such enabling system is the Test System. While it is unlikely to play a role in the System of Interest in its operational context, it is a key role in the development stage of the System of Interest.
The test system provides services (“A system may be considered as a product or as the services it provides” ISO 15288) by performing processes. Obviously its key service is the “Test Service”. This service can be instantiated to provide specialized services such as integration, verification and validation services. These are elements of their parent processes. A test system has a number of elements that serve as resources to execute the processes for which it is responsible. These elements are things such as Facilities, Tools, Specifications, etc…

Perhaps if the ISO standards did not have such a high cost of entry, more people would avail themselves of the resource. I was fortunate enough to work for a corporation that made them available to me and I used that opportunity to learn as much as I possibly could.

My frustration is with the proliferation of jargon that obfuscates communication. INCOSE, ISTQB, IREB all have some level of harmonization with the ISO standards and the lexicon of the systems and software development domains. In my mind, mastery of the lexicon of the relevant domains is important to effective communications.

Why do I bother with this; because you can look at the world from a certain perspective and you find things have more in common than they have differences. Abstraction can reveal the commonality. Commonality helps reveal patterns and patterns are reusable. Human beings, for reasons I do not claim an understanding, insist on differentiating themselves and the things they create from other things and they guard them fervently. My success has always been in finding the commonality, identifying the pattern and reusing a solution I’ve previously employed with success. Often my solutions come from others that have gone before me. I do not pride myself on my inventions though I have a few, rather I pride myself in my humility to embrace the ideas others have forged.