/

JIS C 0508-7:2017 電気・電子・プログラマブル電子安全関連系の機能安全―第７部：技術及び手法の概観 | ページ 20

次のページ
94
C 0508-7 : 2017 (IEC 61508-7 : 2010)
        検査の間,検査を円滑に進める役割をもつ進行役が検査結果を正式に記録することが望ましい。
      結果は,全ての検査員のコンセンサスを得ることが望ましい。欠陥は,a) 検収前に是正を必要とす
      るもの,又はb) 所定の時間若しくはマイルストーンで是正を要するものに分類する。特定した欠
      陥は,検査完了後に続いて是正するために,作成者に知らせることが望ましい。特定した欠陥の数
      及び範囲に応じて,進行役はソフトウェア生成物を更に検査する必要があるかを決定する場合があ
      る。

参考文献

: Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN
0321313798, 9780321313799
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,
9783827372574
The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and
Sons, 2004, ISBN 0471469122, 9780471469124
Fagan, M. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15, 3
(1976): 182-211
C.5.15 ウォークスルー(ソフトウェア)
注記 この技術及び手法は,JIS C 0508-3の表B.8で引用されている
目的 : 仕様と実装との間の不一致を明らかにする。
説明 : ウォークスルーは,ソフトウェア要素の作成者が,対等な技術者との立会いの下で,ソフトウェア
要素内の欠陥を発見する目的で実施する,非形式技術である。これは,ソフトウェア開発ライフサ
イクルのいずれかの段階で作成する特定のソフトウェア要素について実施してもよい。
安全関連系が仕様に示す要求事項に適合していることを確実にするために安全関連系で規定した
機能を調査及び評価する。製品の実装及び使用に関して疑わしい点がある場合,解決できるように
文書化する。形式的検査と対照的に,作成者はウォークスルーに参加する。

参考文献

: Software Engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN
0321313798, 9780321313799
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,
9783827372574
The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and
Sons, 2004, ISBN 0471469122, 9780471469124
C.5.16 設計レビュー
注記 この技術及び手法は,JIS C 0508-3の表B.8で引用されている。
目的 : ソフトウェア設計の欠陥を明らかにする。
説明 : 設計レビューは,設計要求事項及び設計の能力が設計要求事項を満たすことができるかを評価し,
問題点及びソリューションを特定するための,ソフトウェア設計の形式,文書化,包括的及び系統
的なソフトウェア設計の調査である。
設計レビューは,入力要求事項を基準として設計状態を評価する手段,及び更なる改善の可能性

――――― [JIS C 0508-7 pdf 96] ―――――

                                                                                             95
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
      を特定する手段となる。開発ライフサイクル活動が進み,主要な詳細設計マイルストーンに到達す
      るのに応じて,設計レビューを行うことによって,全てのインタフェース面をレビューし,設計が
      確実に要求事項を満たすように設計の検証を行うことを確実にし,最も適切な設計が安全要求事項
      と整合していることを確実にすることが望ましい。こうしたレビューは,主として,設計者の作業
      を検証することを意図しており,確認及び精緻化の活動として取り扱うことが望ましい。
        “スニーク回路解析”などの厳密な検査技術は,想定外パス又はロジックフロー,意図しないア
      ウトプット,不正タイミング,望ましくないアクションなどのような,ソフトウェアの不正挙動を
      検出するために用いてもよい。

参考文献

: Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN
0321313798, 9780321313799
Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,
9783827372574
The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and
Sons, 2004, ISBN 0471469122, 9780471469124
IEC 61160: 2005,Design review
Space Product Assurance, Sneak analysis−Part 2: Clue list, ECSS-Q-40-04A Part 2. ESA
Publications Division, Noordwijk, 1997, ISSN 1028-396X,
http://www.everyspec.com/ESA/ECSS-Q-40-04APart-214981/
C.5.17 プロトタイピング及びアニメーション
注記 この技術及び手法は,JIS C 0508-3の表B.3及び表B.5で引用されている。
目的 : 指定された制約条件に照らして,システムを実装する実行可能性をチェックする。誤解点を明確に
させるため,システムの仕様作成者の解釈を使用者に連絡する。
説明 : システム機能の一つのサブセット,制約条件及び性能要求事項を選択する。高水準ツールを用い
て,一つのプロトタイプを製作する。この段階においては,ターゲットコンピュータ,実装言語,
プログラムサイズ,保守性,信頼性,可用性などの制約条件を考慮する必要はない。プロトタイプ
は使用者の判定基準に照らして評価し,システム要求事項はこの評価を考慮に入れて部分改修して
もよい。

参考文献

: Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,
9780201596205
C.5.18 プロセスシミュレーション
注記 この技術及び手法は,JIS C 0508-3の表A.7,表C.7,表B.3及び表C.13で引用されている。
目的 : ソフトウェアシステムの機能を,外界とのインタフェースとともに,実世界をいかなる点において
も全く変更させることなくテストする。
説明 : テストを唯一の目的とする被制御機器(EUC)の挙動を模擬するシステムを作成する。
シミュレーションは,ソフトウェアだけでも,ソフトウェアとハードウェアとの組合せでもよい。
ただし,次の条件を満たす必要がある。

――――― [JIS C 0508-7 pdf 97] ―――――

96
C 0508-7 : 2017 (IEC 61508-7 : 2010)
      − インプットは,EUCを実際に据え付けたときに存在する入力と同等のものを備える。
      − テスト下のソフトウェアからのアウトプットに対して,制御するプラントを忠実に再現する方
          法で応答する。
      − テスト下のシステムが対処しなければならない挙動不安定が生じるような,オペレータのイン
          プットに対する備えをもつ。
        ソフトウェアをテストする場合,シミュレーションは,インプット及びアウトプットを備えたタ
      ーゲットハードウェアであってもよい。

参考文献

: EmStar : An Environment for Developing Wireless Embedded Systems Software. J Elson et al.
http://cens.ucla.edu/TechReports/9emstar.pdf
A hardware-software co-simulator for embedded system design and debugging. A. Ghosh et al. In Proceedings
of the IFIP International Conference on Computer Hardware Description Languages and Their
Applications, IFIP International Conference on Very Large Scale Integration, 1995. IEEE, 1995, ISBN
4930813670, 9784930813671
C.5.19 性能要求事項
注記 この技術及び手法は,JIS C 0508-3の表B.6(性能テスト)で引用されている。
目的 : ソフトウェアシステムの実証可能な性能要求事項を確立する。
説明 : 明白,暗黙の区別なく,全ての一般的で具体的な性能要求事項を規定するために,システム及びソ
フトウェアの両方の要求仕様の解析を実施する。
各性能要求事項を,次の事項を決めるために順番に調査する。
− 達成するための成功判定基準
− 成功判定基準に対する測定方法の有無
− このような測定の潜在的正確さ
− 測定値を推定することができるプロジェクト段階
− 測定を行うことができるプロジェクト段階
その後,性能要求事項,成功判定基準及び候補となる測定方法の一覧を得るために,各性能要求
事項の実行可能性を解析する。主目的を,次に示す。
− 各性能要求事項が,一つ以上の測定と関わりをもつ。
− 可能なら,開発のできるだけ早期において用いることができる,正確で効率のよい測定方法を
選択する。
− 必須の性能要求事項,任意の性能要求事項及び成功判定基準を規定する。
− 可能な場合,複数の性能要求事項に単一の測定方法を用いることが望ましい。

参考文献

: Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,
9780201596205
C.5.20 性能モデリング
注記 この技術及び手法は,JIS C 0508-3の表B.2及び表B.5で引用されている。
目的 : システムの動作能力が,規定した要求事項を十分満たすことを確実にする。

――――― [JIS C 0508-7 pdf 98] ―――――

                                                                                             97
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
説明 : 要求仕様には,特定機能に対する処理時間及び応答要求事項を,恐らく全システムリソースの使用
      に対する制約条件と組み合わせて考えることが含まれている。提案したシステム設計を,次の事項
      によって,規定した要求事項と照合する。
      − システム処理のモデル,及びシステム処理の相互作用を設計する。
      − 各処理によるリソースの使用,例えば,プロセッサ時間,通信帯域幅,記憶装置などを決める。
      − 平均及び最悪の場合の条件下での,システムへの要求頻度分布を決める。
      − 個々のシステム機能についての平均及び最悪の場合の条件下での,処理時間及び応答時間を計
          算する。
        単純なシステムの場合は,解析的解決策で十分なこともあるが,より複雑なシステムの場合は,
      正確な結果を得るために,何らかの形のシミュレーションが更に適切なことがある。
        詳細モデルを作成する前に,全ての処理についてのリソース要求量を合計した,比較的単純な“リ
      ソース予算”チェックを用いることができる。要求量が設計したシステム容量を超えた場合,設計
      は実行不可能である。設計がこのチェックに合格した場合であっても,性能モデルは,リソース不
      足のために極端な遅延及び応答時間となることを示す場合がある。このような状況を避けるために,
      技術者は,リソース不足の確率が低減されるように,全リソースのある割合(例えば,50 %)でシ
      ステムを設計することが多い。

参考文献

: Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,
9780201596205
C.5.21 アバランチ及びストレステスト
注記 この技術及び手法は,JIS C 0508-3の表B.6で引用されている。
目的 : テスト対象が通常の作業負荷に容易に耐えることを示すために,テスト対象に例外的に高い作業負
荷をかける。
説明 : アバランチ及びストレステストに適用することができる,様々なテスト条件がある。幾つかのテス
ト条件を,次に示す。
− ポーリングモードで作業している場合,テスト対象への単位時間当たりのインプットを,通常
条件よりもはるかに多く,変化させる。
− オンデマンドで作業する場合,テスト対象への単位時間当たりの作動要求数を,通常条件より
も増やす。
− データベースのサイズが重要な役目を果たす場合,そのサイズを通常条件よりも大きくする。
− 影響を及ぼす装置は,それぞれ,これらの最大速度又は最小速度に設定する。
− 極端な事例の場合,全ての影響要因を,できるだけ同時に境界条件に入れる。
これらのテスト条件によって,テスト対象の時間挙動を評価することができ,負荷変化の影響を
観察することができる。さらに,内部バッファ,動的変数,スタックなどの正しい大きさを確認す
ることができる。

参考文献

: Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,
9780201596205

――――― [JIS C 0508-7 pdf 99] ―――――

98
C 0508-7 : 2017 (IEC 61508-7 : 2010)
C.5.22 応答タイミング及びメモリ制約
    注記 この技術及び手法は,JIS C 0508-3の表B.6で引用されている。
目的 : システムが時間的要求事項及びメモリ要求事項を満たすことを確実にする。
説明 : システム及びソフトウェアについての要求仕様には,全システムリソースの使用に対する制約条件
      と組み合わせた,特定機能についてのメモリ及び応答要求事項を含む。
        平均及び最悪の場合の条件下における要求頻度分布を決めるために,解析を実施する。この解析
      には,各システム機能についてのリソースの用途及び経過時間の推定値が必要となる。これらの推
      定値は,幾つかの方法,例えば,既存システムとの比較,又はタイム クリティカル システムのプ
      ロトタイピング及びベンチマークの実施によって得ることができる。
C.5.23 影響解析
    注記 この技術及び手法は,JIS C 0508-3の表A.8(部分改修)で引用されている。
目的 : ソフトウェアシステムの変更又は機能強化が,そのソフトウェアシステムの他のソフトウェアモジ
      ュール及び他のシステムに及ぼす影響を求める。
説明 : ソフトウェアの部分改修又は機能強化を実施する前に,その部分改修又は機能強化がそのソフトウ
      ェアに及ぼす影響を求めるために,さらに,どのソフトウェアシステム及びソフトウェアモジュー
      ルに影響を及ぼすかを求めるために,解析を実施することが望ましい。
        解析が完了した後,そのソフトウェアシステムの再適合確認に関する決定が必要になる。この決
      定は,影響を受けるソフトウェアモジュールの数,致命度及び変更の性質によって異なる。考えら
      れる決定を,次に示す。
      − 変更したソフトウェアモジュールだけを再適合確認する。
      − 影響を受ける全てのソフトウェアモジュールを再適合確認する。
      − システム全体を再適合確認する。

参考文献

: Requirements Engineering. E. Hull, K. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794
C.5.24 ソフトウェア構成管理
注記 この技術及び手法は,JIS C 0508-3の表A.8で引用されている。
目的 : ソフトウェア構成管理とは,幾つかのグループになった開発製品を変更した場合,これらの製品の
グループの整合性を確実にすることである。構成管理は,一般に,ハードウェア及びソフトウェア
の両方の開発に適用する。
説明 : ソフトウェア構成管理は,開発全体を通じて用いられる技術である(JIS C 0508-3の6.2.3参照)。
本質的に,この管理には,全ての重要な製品の全てのバージョンの作成,及び様々な製品の様々な
バージョン間の全ての関係の生成を文書化する必要がある。この結果から得た文書類によって,開
発者は,一つの製品(特に,要素のうちの一つ)の変更が他の製品に及ぼす影響を求めることがで
きる。特に,システム又はサブシステムは,要素バージョンの整合性がある組合せから,信頼でき
る形で再構築することができる。

参考文献

: Software engineering: Update. Ian Sommerville, Addison-Wesley Longman, Amsterdam; 8th ed., 2006, ISBN
0321313798, 9780321313799

――――― [JIS C 0508-7 pdf 100] ―――――

次のページ PDF 101

JIS C 0508-7:2017の引用国際規格 ISO 一覧

  • IEC 61508-7:2010(IDT)

JIS C 0508-7:2017の国際規格 ICS 分類一覧

JIS C 0508-7:2017の関連規格と引用規格一覧

規格番号
規格名称

ページ