むかし，プログラムの構造を示すために，幾つかの表記法がありました．典型的には流れ図なのですが，それ以外にもNSチャートやHCPなど沢山の表記法がありました．私が所属していた会社ではHIPOといわれる表記法を用いていました．90年代の初め頃は，まだ手書きで書くケースも多く，テンプレートを大事に使っていました．
HIPOは，その名の通り「入力ー処理ー出力」というかたちでプログラムの構造を記載します．記述全体が階層構造をとるので，hierarchy plus input-process-outputとなり，頭文字をとってHIPOです．入力と出力で処理を押さえるのは分かりやすいので，プログラム記述以外にも，ソフトウェアプロセスの記述をするときにも良く用いられています．入出力が文書で，処理の部分が実際の開発活動になります．
さて，今回は，ISO 26262-6 を成果物から見てみたいと思います．26262では，ライフサイクルを構成する要素として，フェーズという云い方をしています．フェーズを更に分割したものがサブフェーズになります．ソフトウェアライフサイクルプロセスの規格であるISO/IEC 12207(Systems and software engineering – Software life cycle processes)では，プロセス粒度に従って，プロセス／アクティビティ／タスクという使い分けをします．12207のアクティビティはプロセス粒度としては26262のサブフェーズに近く，タスクがそれより細かな単位となります．ちなみに，26262では，アクティビティはフェーズを横断する活動に対して名付けています．安全アクティビティ（safety activity）がその例です．
***
各サブフェーズと成果物の関係を記述してみました（成果物一覧は，Annex A にもあります．ただ，このあとのハードウェアソフトウェアインターフェイス仕様の他に，おそらくtypeと思われる間違いがあります．統合テスト報告の参照番号です）．
ソフトウェアレベル（Part 6）のサブフェーズ毎に，入力と出力を記載しています．入力側で網掛けになっている部分は，システムレベル（Part 4）から来ているものです．このほかに並行して開発されるハードウェアレベルからの情報もあるのですが，ここでは，prerequisites 即ち，先行するフェーズで必ず作成されている成果物に限定しています．出力側の網掛けの部分は，ソフトウェア開発レベルの出力となるものです．成果物が沢山あるようですが，多くは各サブフェーズで洗練・詳細化（refine）されて，後続のサブフェーズに受け渡されています．ソフトウェアレベルで新規に作成されるものはプログラムを含めて12種類でしょうか．
かなり複雑なのですが，幾つかのタイプがあることが見て取れます．
(1) ソフトウェア開発レベル外部から来て更新されるもの
安全計画は，最初のサブフェーズ（6-5）とソフトウェアアーキテクチャ設計（6-7）で更新され，全てのサブフェーズで参照されます．少し奇妙なのは，ハードウェアーソフトウェアインターフェイス仕様で，安全要求の仕様（6-6）で更新されるのですが，次のアーキテクチャ設計（6-7）では，そちらを参照せずに更新前のものを参照しています．そのほかでは，後続するサブフェーズでは，更新されたものを参照しているにもかかわらずです．サブフェーズレベルでの平行性を意図しているようにも思えないので，すこし不思議な規定です（ちなみにDIS版には入っていなくて，FDIS版から6-7に追加されています，Part-5 のハードウェアレベルでは正しいようです）．
(2) ソフトウェアレベルだけで繰り返し更新され，出力されるもの
代表的なのがソフトウェア検証計画です．最初のサブフェーズ（6-5）で作られた後，後続の多くのサブフェーズで更新されます．
フェーズに関連した名称を与えることで，複雑な参照線を避けることができます．例えば，単体テスト（6-9）で作られるのはソフトウェア単体検証仕様書として，統合テストで使用されるのは，ソフトウェア統合検証仕様書である．その上で，別途文書体系を規定する．この方式の方が一般には見通しが良くなると思うのですが，同名の文書を繰り返し更新することで，文書の内部構造を推量させるというポリシーのようです．そのために，一覧表にするとかなり複雑な参照線となっています．前回書いたようにDIA（Development Interface Agreement）によるOEMーサプライヤの切断を考えると，ソフトウェアに関しては，成果物の参照線を多数横断することになるので，その整理が大変だろうと思います．
***
さて，今回は上記に関連する他の論点もしておこうと思います．まず，機能安全が達成されていることを確認するための手段として，セーフティケースがキーになります．そのことは，Part-2 の管理にあります．気づきにくいのですが，セーフティケースは，今回見た成果物をエビデンスとして参照することになります．丁度，フェーズ／サブフェーズをまたいで串刺しにするような形になるのではと思います．もう一つは，上記の様々な成果物と既存成果物との関係です．機能安全に特化した規格で，それによって担保されている安全性を明確化するということですと，分かりやすいのです．しかし，例えば，ソフトウェアアーキテクチャ設計サブフェーズの記述を見ると，非ー機能安全部分の要求についても同一プロセスで扱うとありますので，あくまでこれまでの規定を包含するということなのだろうと思います．A-SPICEで「確証」という話しもそこから来ているのでしょう．この方式だと，容易に破綻しそうな気もします（例えば，上位の概念を考えます．一般の安全性も機能安全の上位概念ですし，Dependabilityは更に広く，ここには安全性の他に機密性といった多くの概念を含みます）．本来は，機能安全を如何に*分離*してモデル化／実現／確認できるか，に特化した方が良いのではと思います．この議論は，先のセーフティケースによる串刺しを含めて，ソフトウェアアーキテクチャ設計を例に，また続けようと思います．
***
さて，HIPOをはじめとするプログラムの構造表現を，何故，余り書かなくなったかです．一番は，そのときに発生する労力の問題かと思います．一度でも書いたことのある人なら分かるのですが，修正にとても弱い．考えながら最初に書くときは良いのですが，なかなか書き直す気になりません．しかし，安全に関するところですと，自動化の助けを借りることで，記載する必要性があるのではと思っています．プロセスのチェックだけでは，安全性を担保するエビデンスとはなりづらいように思います．
（nil）