Process & Safety Management — SW-Development Air Traffic Management

My direct client was an IT-department of a national air traffic management authority. They develop software to serve the own air traffic controlling demands. In addition, they sell customised variants and individualised implementations to other international ATM authorities.

An international air traffic management authority was the end client of my client. They planed to replace their own system with a new, enhanced one. For this, they ordered from my client individual customisation. The challenges for the dev team of my client were

• to implement all operational procedures valid for the target airspace (80% functionality of the system to be rebuilt).
• to keep the existing system architecture design;
• to fulfill operational safety requirements for the existing and added/rebuilt functionality system-wide;
• to set up an SW development process compliant to DO-178B, DO-178C/ED-12C in addition to their own, ISO 9000 certified, quality management system, and process model.

My responsibility as an external consultant was

• to design, implement, and document for the project a system development process with all artifacts needed to be compliant with DO-178B, DO-178C/ED-12C, and the existing process model of my client. (Process Management);
• to implement, monitor, and verify activities needed for the safety validation process (Safety Management);
• to assist and coach the dev team in applying the new/changed processes (Coaching);
• to facilitate, moderate, and document SW safety workshops.

Safety Management Responsibilities

To fulfill the safety requirements we implemented joined workshops with developers, designers, and testers. In these workshops, we analysed the existing SW implementation as well as the planned changes resp. new implementations to be compliant with safety objectives given by the end client. The workshop method to investigate systems safety was a combination of

• repeatedly 5-Why-Questions drilled down from architectural design, code (component, module-level implementation)
• imagining worst case scenarios: "What is the consequence if function X /code segment Y in module Z fails?", or "Which components/functional code has to fail, that safety objective n.m.l is not fulfilled?"

The insight and results of these safety workshops led directly to new or changed functional requirements and/or test cases. I monitored and tracked their status with a DOORS database.

Process Management Responsibilities

The process model I designed and implemented covered

• the safety objectives for all development and testing activities;
• additional activities, roles, and artifacts needed for DOD/ED compliance.