hcl whitepaper: best practices from safety standards for creation of robust and reliable software

8/10/2019 HCL Whitepaper: Best practices from Safety Standards for creation of robust and reliable software

1/13

Best Practices from Safety Standards forCreation of Robust and Reliable Software

N o v e m b e r 2 0 1 1


2/13

Best Practices from Safety Standards for Creation of Robust and Reliable Software |November 2011

2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.

TABLE OF CONTENTS

Abstract ............................................................................................. 3

Abbreviations .................................................................................... 4

Market Trends/Challenges ................................................................ 5

Solution ............................................................................................. 6

Conclusion....................................................................................... 10

Reference ........................................................................................ 11

Author Info ....................................................................................... 11


3/13



3

Abstract

Mission-critical software has become very reliable and robust by

adhering to high quality safety standards in the development

lifecycle. An example of mission-critical software, also called safetycritical, is the software implemented in passenger aircraft, or in

control systems operating nuclear and chemical plants. Safety

critical software includes those applications whose malfunction can

cause multiple deaths. Conventional software applications, i.e.

applications that are not critical and more commonly used, can be

made as robust and reliable as mission-critical software by following

the simple best practices required for mission-critical software with

very little or no additional effort. Though there are mandatory

procedures prescribed by safety standards that can require

significant additional effort, the focus of this paper is to highlight

practices that can be implemented in any project with very little

additional effort. By that process, every software implemented can

achieve a very low probability of failure. Also, it becomes easier for

organizations that develop software, be it software service providers

or OEMs, to easily adhere to an ever-expanding list of safety

standards across domains. In fact, for organizations already

practicing CMMi standards, the migration to robust software

development is not a major upgrade. This paper describes the best

practices that can be adopted in each of the major development

cycle milestones, including requirements, design, coding and

testing. These are considered from a safety standpoint, and are not

intended to describe the software lifecycle.


4/13



4

Abbreviations

Sl.

No.

Acronyms(Page

No.)

Full form

1 CMM Capability Maturity Model, Level 3

2 CRC Cyclic Redundancy Checks

3 OEM Original Equipment Manufacturer

4 RACI Responsible, Approver, Consulted, Informed


5/13


6/13



6

Solution

1. Brief Insights into Safety Standards

Safety standards are defined for specific domains:

o IEC 61508is the safety standard followed by

industrial automation OEMs to build control systems

managing chemical plant operations

o IEC 61513safety standards for equipment

controlling operations in nuclear power plants

o DO 178Aeronautical standards governing flight

software

o ISO 26262Safety standards for the automotive

industry

Though they are industry specific, the underlying requirement in all

these standards is, by and large, common (will not use the word

same here, as there are some variations). They recommend, or in

other words are more suited for Waterfall or the V lifecycle

development lifecycle, though there are cases where Agile

practitioners have embraced these standards.

The sections below describe the best practices that can be adapted

from these safety standards into each major phase of the

development lifecycle of any conventional project.

The assumption here is that organizations already follow basic

processes for software development. The erstwhile CMM level 3can be considered a basic software process.

2. Absorbing the Best Practices

2.1 Project Planning

Project planning for mission-critical projects is very similar to

conventional projects. Other than the usual project management

content, they need to ensure that the project plan includes:

o Clear entry and exit criteria for each phase of a

project, the deliverables on completion of each

phase, the verification plan of phase document and

quality audits that will be performed for each phase

o Skill mapping and RACI chart. Skill Mapping to

describe the skills required (as rows) to implement

the project against the project team members

(columns) and the level of proficiency (Expert,

Practitioner, beginner, NA) to be filled for each cell.

A RACI chart should accompany the skill mapping

table to indicate responsibility levels.

Though there are safety

standards for each industry

vertical, they all share many

requirements in common


7/13



7

2.2 Requirements Phase

2.2.1 Requirement classification

Conventional project execution follows a requirement template. It

should have a unique requirement ID, requirement description,

assumptions and priority. It is similar to a safety-critical project;

however, each requirement needs to be classified as:

o Critical requirement

o Critical support requirement

o Non critical requirement

This can also be incorporated for conventional projects with

following intentions:

o Critical RequirementThose requirements thesoftware must perform. Can also be called Core

requirements. For example, in a web-based remote

monitoring application, the data analysis will be a

critical requirement

o Critical Support RequirementAdditional

requirements that are not core requirements, but

indirectly contribute to the functioning of core

requirements. In the above example, the ability to

zoom the data to a wider scale or compress it to

see a larger span can be considered as a support

requirement. The application can be still be used fordata analysis without this function, or with the

function disabled. Hence, it is called a support

function.

o Non critical requirementFeatures of software that

are not related to the core requirements

So, by this classification, the priority and importance of each of

software modules becomes more explicit. Design and testing can be

based on types of above classifications.

2.2.2 Failure mode event analysis (FEMA)

For mission-critical applications, FEMA on requirements is done toanalyze the effect of functionality failure. For conventional projects,

too, the same can be applied to all critical requirements to identify

any missing requirements. Performing a good FEMA after

completion of requirements gathering usually adds 5-10% new

requirements not previously envisioned, and many times, checks if

defined requirements are flawed or not.

2.2.3 Mandatory usage of software tools to maintain requirements

Tools and Pre existing

software selection need to

justified as they can introduce

defects into product

Graceful degradation can be

effective technique during

resource crunch

Requirements to be classified

based on their criticality

FEMA done on requirements

can throw up new

requirements and determine ifexisting requirements are

flawed


8/13



8

Though Microsoft Word or Excel may appear sufficient to capture

requirements, usage of specific requirement gathering tools, e.g.

DOORS, will help in maintaining the requirements. Requirements

tend to get deleted or modified, or new requirements added.

Maintaining traceability becomes time consuming without tools, andincreases the possibility of errors.

2.2.4 Forward and Reverse Traceability

Decomposed requirements should have a reference to the Parent

requirement, and more importantly, all requirements IDs should

include a forward traceability to section in high-level design, low-

level design and test cases. It should also have a reverse

traceability to the Parent document (it could be from multiple

sources) from which requirements are gathered

It is mandatory to maintain forward and reverse traceability for each

phase of software development high-level design, low-leveldesign, coding, unit test cases, and integration test cases.

2.3 High Level Design

2.3.1 Tools and pre-existing software

It is good practice to select software tools (compilers, static code

analysis or performance test tools) or any pre-existing software

(Real Time operating system or any 3rd party library) that are

proven. The design document should justify the usage of such tools,

preferably providing previous usage experience to substantiate its

credibility. This is done to ensure the tools and/or pre-existing

software do not introduce any defects into the product.

2.3.2 Design modularity

Design needs to be highly modular. Independent activities must be

grouped into different tasks/processes. The core activities (that

defines the product) and non core activities should run in different

tasks. The function names used in these tasks should be uniquely

named, even if they perform the same work. Avoid or use to bare

minimum global variables

2.3.3 Diagnostics

Provision to diagnose faults is a major activity for safety-critical

applications. For conventional projects, even if not explicitly stated

in requirements, a re-visit on diagnostics and ways to retrieve log

information will make the design comprehensive.

2.3.4 Graceful degradation

The safety standards suggest many techniques to enhance fault

tolerance the ability to continue to perform normal operations on

occurrence of fault. For conventional projects, that may not be very

important or may be expensive to implement. One useful technique


9/13



9

that can be largely applied to many conventional projects is graceful

degradation. At times when the resources are constrained, when

resources could be processing capability or hard disk space or any

other dynamically varying computing parameter that could affect the

quality of software performance, a provision should be made toswitch off non-critical or less critical tasks to allow the core tasks to

be performed. The switched-off task can be reinitiated once the

resources crunch threat lessens or disappears.

2.3.5 CRC check

For embedded applications, use of CRC data checking when data is

transferred across independent functioning modules is

recommended. As there are proven standard CRC libraries

available, incorporating them will not be time-consuming, and at the

same time, can effectively address data corruption.

2.3.6 Abundant use of UML diagramsModule design should be supported by documenting class

diagrams, activity diagrams, state transition diagrams and data flow

diagrams.

2.3.7 FEMA on Design

A FEMA done on design considerations can bring out the flaws in

design.

Peer review of the design by a competent person outside the project

team needs to be performed, and a design checklist needs to be

prepared.

2.4 Coding

As coding standards are followed by conventional projects, it is

good practice to use a static code analyzer (QAC, fxCop) to check

the code for any violations with respect to coding standards.

2.5 Testing

2.5.1 Negative testing

If it is not possible to test simulate the inputs to test all scenarios -- a

separate code branch in the source code repository should be

maintained, with the negative scenarios seeded as input. However,

this may require significant additional effort, and needs to be

followed only when the usual testing did not identify all possible

defects, even after executing a comprehensive list of test cases.

The same situation applies for code coverage testing. Though

mandatory for safety-critical applications, it can prove to be a

significant drain on effort if not provisioned in the estimation stage.

2.6 Release Notes

Negative Testing can be

significant effort consumer


10/13



10

Its a good practice to list all unresolved defects, and more

importantly, suggest alternatives when a user experiences the

defect.


11/13



11

Conclusion

Safety standards like IEC61508 and DO 178 have proved to be

successful. Products created by complying with these standards

have proved to be reliable with a low probability of failure.

Obviously, all conventional software creators would like their

software to perform as reliably as safety-critical applications without

incurring major additional effort or cost. By following the best

practices from these safety standards, conventional software, too,

can become more predictable and robust with little additional effort.

These best practices raise the bar for software quality.

The best practice raises the

bar for software quality.


12/13



12

Reference

1 IEC 61508 -3, Ed 2.0, 2010

Author Info

Mahesh Subramaniam, ERS, Industrial

Practice, has over 20 years of experience on

control systems engineering, software

development and IT project management. His

current interests include safety-critical

applications and condition monitoring.


13/13

Hello, Im from HCLs Engineering and R&D Services. We enabletechnology led organizations to go to market with innovative products &solutions. We partner with our customers in building world class

products & creating the associated solution delivery ecosystem to helpbuild market leadership. Right now, 14500+ of us are developingengineering products, solutions and platforms across Aerospace andDefense, Automotive, Consumer Electronics, Industrial Manufacturing,Medical Devices, Networking & Telecom, Office Automation,Semiconductor, Servers & Storage for our customers.

For more details contact [email protected]

Follow us on twitter http://twitter.com/hclers and our bloghttp://ers.hclblogs.com/

Visit our website http://www.hcltech.com/engineering-services/

About HCLAbout HCL TechnologiesHCL Technologies is a leading global IT services company, workingwith clients in the areas that impact and redefine the core of theirbusinesses. Since its inception into the global landscape after its IPO in1999, HCL focuses on 'transformational outsourcing,' underlined byinnovation and value creation, and offers integrated portfolio of servicesincluding software-led IT solutions, remote infrastructure management,engineering and R&D services and BPO. HCL leverages its extensiveglobal offshore infrastructure and network of offices in 26 countries toprovide holistic, multi-service delivery in key industry verticals includingFinancial Services, Manufacturing, Consumer Services, Public Servicesand Healthcare. HCL takes pride in its philosophy of 'Employee First,

Customer Second' which empowers our 77,046 transformers to createa real value for the customers. HCL Technologies, along with itssubsidiaries, had consolidated revenues of US$ 3.5 billion (Rs. 16,034crores), as on 30 June 2011 (on LTM basis). For more information,please visit www.hcltech.com

About HCL EnterpriseHCL is a $6 billion leading global technology and IT enterprisecomprising two companies listed in India - HCL Technologies and HCLInfosystems. Founded in 1976, HCL is one of India's original IT garagestart-ups. A pioneer of modern computing, HCL is a globaltransformational enterprise today. Its range of offerings includesproduct engineering, custom & package applications, BPO, IT

infrastructure services, IT hardware, systems integration, anddistribution of information and communications technology (ICT)products across a wide range of focused industry verticals. The HCLteam consists of over 85,000 professionals of diverse nationalities, whooperate from 31 countries including over 500 points of presence inIndia. HCL has partnerships with several leading global 1000 firms,including leading IT and technology firms. For more information, pleasevisit www.hcl.com

hcl whitepaper: best practices from safety standards for creation of robust and reliable software

Documents