Personal Blogs

Author

Article

Year

Read

Tuohey

Benefits and Effective Application of Software Engineering Standards

2002

12-Aug-12

Key words

Quality Management, medical device, software development standard,

Summarizing comments

The primary purpose of this paper (Tuohey, 2002) is to document lessons learned and insights gained over several years in applying software engineering standards in the Aerospace sector. This article triggered my interest as it relates to sw engineering environments which need to address safety issues. Coming from the medical device industry and now working in defense industry I expected to engage easily with this article and be able to compare and contrast my own insights with the ones presented by Tuohey.

One of the first observation Tuohey mentions is the application of software engineering standards within the context of other system aspects. In the NCIA Nato Programming Centre, this is certainly the case and we typically do not treat software engineering so differently than system engineering.

RTCA/DO-178B is a standard widely used in the aerospace factor. I do not know if our Air Command and Control Systems are compliant with this standard, but I am certain the standard applied by ` is pretty alike to RTCA/DO-178B. Specifically as RTCA/DO-178B targets data link communications.  In (RTCA/DO-178B, 1992), software is viewed as part of a wider system or equipment and the primary focus is on certifying that system or equipment. The standard recognizes 5 categories for systems based on their impact in case of failure, comparable to the safety levels within the medical device industry. Systems or parts of the system which provides higher risk severity, are subject to more and tougher process and documentation criteria.

The second standard introduced is the ESA PSS-05-0 (1991), which is said to be more directive and specific, to the level of to the level of prescribing the use of specific document templates. There is no  safety level and it is left to the interpreter to decide what level of tailoring is suitable for the systems under development. I consider this an invitation to treat every part of the system alike.

The third standard introduced is IEC 61508-3 as a product safety standard, but the author quickly recognizes that it is highly compatible to RTCA/DO-178B. The last standard is the one that I am most familiar with: the USA Food & Drugs Administration’s guidelines for medical device software, particular the different documentation requirements for 510(k) premarket submissions of minor, moderate or major level of concern medical device software. Tuohey claims the flow chart to determine your level of concern is clear. It probably is; it was just that I was tasked to argue that Pie Medical Imaging’s products were considered a ‘minor level of concern’ and I had to try to find arguments to justify this conclusion. Therefor I probably have struggled with this flow chart to decide on the ‘level of concern’.

I actually have difficulties to see the lessons learned aspect of applying these standards. Tuohey refers to an article by T. McGibbon (1999) how software Levels C and D “fit” in the context of investigations of the business case for software process improvements, particularly in terms of providing guidance on how to prioritize improvement measures. McGibbon reports significant benefits due to collective software improvement measures such as moving an organization from CMM Level 1 to Level 2. McGibbon also reports on the results of some specific process improvements and finds, in particular, very substantial benefits (better and earlier detection of errors, savings in test and integration, improved teamwork, etc.) due to the introduction of inspections.

Tuohey recognizes that the standards are predominantly targeting implementation at the level of a single software development project, whereas the organization-wide implementation is considered widely as important.  The article continues with lists of process improvement aspects, which I do not consider to fit that well.

On a number of occasions, I have been confused by the title of an article related to standards. How often does a title talk about the benefits of a standard, but then in the main body predominantly talk about the benefits of the activities that the standard has mentioned. I don’t necessarily need a cooking book to be able to prepare food and still my family’s hunger. I do not need a software development standard telling me to manage my requirements to actually manage and meet them in my software product. What is the contribution of these reference documents? I see their benefits in pre-defining the arrangements as a bench mark to tailor and adapt the activities, in the defined terminology they provide to communicate the actual arrangements and in their ability to provide confidence that the work will be done up to a desirable quality.

Interesting quotes

“In the past, rigorous software engineering standards were imposed mainly on certain kinds of software development, particularly those with safety impact or with stringent reliability requirements or of a clearly mission-critical nature (such as the onboard control of an unmanned satellite)”

“there is a need to apply and extend what has been learned in applying strict software engineering standards in relatively specialized areas to much wider fields”

Actions

Due date

Status

1. Read and summarize

14-Aug-12

Done

2. Read McGibbon (1999) A business case for software process improvement revised—measuring return on investment from software engineering and management, Air Force Research aboratory contractno. SP0700-98-4000, http://dacs.dtic.mil/techs/roispi2, Data & Analysis Center for Software (DACS), ITT Industries, Advanced Engineering and Sciences Division, 775 Daedalian Drive, Rome, NY 13441-4909

01-Sep-12

Open