Best Practices from Safety Standards forCreation of Robust and Reliable Software        November 2011
Best Practices from Safety Standards for Creation of Robust and Reliable Software |November 2011                          ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |    November 2011                      ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |     November 2011                     ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |     November 2011                     ...
Best Practices from Safety Standards for Creation of Robust and Reliable Software |     November 2011                     ...
Hello, I’m from HCL’s Engineering and R&D Services. We enabletechnology led organizations to go to market with innovative ...
Upcoming SlideShare
Loading in …5
×

HCL Whitepaper: Best practices from Safety Standards for creation of robust and reliable software

531 views
452 views

Published on

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 “safety
critical,” 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.

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
531
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

HCL Whitepaper: Best practices from Safety Standards for creation of robust and reliable software

  1. 1. Best Practices from Safety Standards forCreation of Robust and Reliable Software November 2011
  2. 2. Best Practices from Safety Standards for Creation of Robust and Reliable Software |November 2011 TABLE OF CONTENTS Abstract ............................................................................................. 3 Abbreviations .................................................................................... 4 Market Trends/Challenges ................................................................ 5 Solution ............................................................................................. 6 Conclusion....................................................................................... 10 Reference ........................................................................................ 11 Author Info ....................................................................................... 11 © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.
  3. 3. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 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 “safety critical,” 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. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.3
  4. 4. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 Abbreviations Acronyms Sl. (Page Full form No. No.) 1 CMM Capability Maturity Model, Level 3 2 CRC Cyclic Redundancy Checks 3 OEM Original Equipment Manufacturer 4 RACI Responsible, Approver, Consulted, Informed © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.4
  5. 5. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 Market Trends/Challenges When creating software, it is the goal of any organization to make the software robust, defect-free and less prone to failure. But, even with software processes in place, software does crash, much to the displeasure of end users. Today, organizations release software for use after adequate testing, when defects are minimal or trivial, and after defect density is stabilized, Despite that, they cannot provide a guarantee on the probability of software failure or the possibility of a The emphasis here is to defect surfacing during operation. Safety standards focus on these absorb the best practices that issues, and attempt to ensure that software is reliable. Almost all will not have a major impact on safety standards classify developed software into 3 or 4 levels, the effort required to create the depending of the level of reliability. Note: safety-critical software software must comply with stringent basic requirements, even to be classified at the lowest levels. So, by following best practices in conventional software projects, a high level of reliability can be achieved. The emphasis here is to absorb the best practices that will not have a major impact on the effort required to create the software -- developing a strict- compliance, safety-critical application can be much more expensive than conventional projects. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.5
  6. 6. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 Solution 1. Brief Insights into Safety Standards Safety standards are defined for specific domains: o IEC 61508 – is the safety standard followed by industrial automation OEMs to build control systems managing chemical plant operations o IEC 61513 – safety standards for equipment controlling operations in nuclear power plants Though there are safety standards for each industry o DO 178 – Aeronautical standards governing flight vertical, they all share many software requirements in common o ISO 26262 – Safety 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 3 can 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. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.6
  7. 7. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 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 Requirements to be classified based on their criticality o Non critical requirement This can also be incorporated for conventional projects with following intentions: o Critical Requirement – Those requirements the software must perform. Can also be called Core requirements. For example, in a web-based remote monitoring application, the data analysis will be a Tools and Pre existing critical requirement software selection need to o Critical Support Requirement – Additional justified as they can introduce requirements that are not core requirements, but defects into product 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 for data analysis without this function, or with the function disabled. Hence, it is called a support function. o Non critical requirement – Features 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. FEMA done on requirements can throw up new 2.2.2 Failure mode event analysis (FEMA) requirements and determine if For mission-critical applications, FEMA on requirements is done to existing requirements are analyze the effect of functionality failure. For conventional projects, flawed too, the same can be applied to all critical requirements to identify any missing requirements. Performing a good FEMA after Graceful degradation can be completion of requirements gathering usually adds 5-10% new effective technique during requirements not previously envisioned, and many times, checks if resource crunch defined requirements are flawed or not. 2.2.3 Mandatory usage of software tools to maintain requirements © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.7
  8. 8. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 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, and increases 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-level design, 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 rd (Real Time operating system or any 3 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 © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.8
  9. 9. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 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 to switch 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 diagrams Module 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. Negative Testing can be significant effort consumer 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 © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.9
  10. 10. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 It‟s a good practice to list all unresolved defects, and more importantly, suggest alternatives when a user experiences the defect. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.10
  11. 11. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 Conclusion Safety standards like IEC61508 and DO 178 have proved to be The best practice raises the successful. Products created by complying with these standards bar for software quality. 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. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.11
  12. 12. Best Practices from Safety Standards for Creation of Robust and Reliable Software | November 2011 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. © 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.12
  13. 13. Hello, I’m from HCL’s 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 classproducts & 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 eootb@hcl.comFollow 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.comAbout 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 Indias 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, ITinfrastructure 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

×