원전 사이버보안 위험 관리 단계

출처:  Formal Works Inc.

Avoiding Top Mistakes in Safety Critical Software Development

Mistake #1: Forgetting to Conduct Requirements Reviews Often
"Review Requirements Early and Often – Make use of Lean and Agile"

• Conduct more frequent iterative reviews
• Review requirements in smaller batches
• Increase quality by having more thorough reviews & defined criteria
• Use collaborative techniques during review

Mistake #2:  Forgetting to Use Safety-Critical Requirements Checklists
"Make use of checklists when performing requirements reviews"


Mistake #3 Not Reviewing Software Requirements in Context
"Review Requirements with their traces in context."


Mistake #4– Neglecting Traceability
"When creating new requirements, tests cases, or code:"

• Establish the required traces immediately, not later when you need to demonstrate those traces to the auditor
• Make traceability updates mandatory for review of Requirements, Code, & Tests 
• Two-way traceability for:
• Requirements to Code Functions
• Code Functions to Tests
• Requirements to Tests 

Mistake #5: Neglecting Transition Criteria 

Mistake #6– Forgetting the Safety-Critical Software Lifecycle

Mistake #7 – Safety “Before & During”: Neglecting to Apply Safety  Standards BEFORE Software Development then During!

Mistake #8 – Neglecting Independence

• Independence refers to the Correctness process (reviews and verification) 
• Required Independence increases as criticality  increases
• Not providing required Independence necessitates development rework
• If future criticality level changes and Independence lacking:  rework.
• Recommendation:  even when Independence is not required, do it:  better review and insurance against future critical level increase

Mistake #9 – Inadequate Plans or not Following!

• Plans that are not compliant to standards
• Lack of checklists
• E.g. Code reviews without requirements traceability to code
• Plans are not complete prior to starting associated developments
• Plans not QA approved
• Plans too detailed, requiring extreme customization for each project

Mistake #10 - Lack of Automated Testing = Expen$ive Regression Test 

• Testing is a “life-of-product” continual activity
• Testing costs exceed development costs, over product lifetime
• Guilty-until-proven innocent regression: retest everything unless you can ensure no side effects
• Best regression test strategy?  Retest everything (only practical via automated testing)

Mistake #11: When to “Verify”?

Traditional Software Engineering Sequence:

Recommended “Best Practice” Software Engineering Sequence:

출처: www.afuzion.com

Safety-Critical Requirements

Safety Critical Definitions

• Software Requirement: “Measurable software processing that is necessary.”
• Safety-Critical Software Requirement: “A necessary aspect within a system whose anomalous behavior could negatively impact safety.” 

Safety-Critical Systems - Basic Facts

• “Safety-critical” encompasses many domains: Industrial, Automotive, Aerospace, Nuclear, Medical, etc. 
• Software size and complexity are rapidly increasing
• Yesterday’s non-safety-critical is becoming tomorrow’s safety-critical due to IoT, integration/connectivity, etc. 
• Requirements are  needed to guide development, identify hazard detection/mitigation, and assess implementation.

Safety-Critical Requirements –Background

• Experts say majority of safety-critical failures stem from requirements. 
• Safety-critical requirements include Safety aspects, but not exclusively: also address Functional, Performance, etc. 
• Most safety-critical requirements specifications are incomplete: lack complete hazard prevention/mitigation. 
• Need requirement identification, specification, verification, and management.

출처: www.afuzion.com