トレーサビリティとタグ 〜TOPPERSカーネルを題材に〜

TOPPERSカーネルの仕様書やソースコードの中に，【NGKI0001】とか［NGKI0002］といった文字列が入っているのをご覧になっているでしょうか？この記事では，このような文字列が何を意味しているかと，その目的について説明したいと思います。

## タグの使用例

例として，[TOPPERS第3世代カーネル（ITRON系）統合仕様書](https://www.toppers.jp/documents.html#tgki_spec)の以下の記述を取り上げましょう。

> カーネルには，静的APIにより，少なくとも1つのタスクを登録しなければならない．タスクが登録されていない場合には，コンフィギュレータがエラーを報告する【NGKI0033】．

この記述の2つ目の文は，コンフィギュレータの仕様を規定するものです。ここにある```【NGKI0033】```という文字列は，この仕様に```NGKI0033```という識別名を付けるという意味で，```NGKI0033```をタグと呼んでいます。

次に，[TOPPERS/ASP3カーネル](https://www.toppers.jp/asp3-kernel.html)のソースコード中で```NGKI0033```という文字列を探すと，以下のコードが見つかります（このコードは，コンフィギュレータの一部で，Rubyで記述されています）。

```kernel/task.trb
# タスクが1つも登録されていない場合［NGKI0033］
if $cfgData[:CRE_TSK].size() == 0
  error("no task is registered")
end
```

ここにある```［NGKI0033］```という文字列は，このコードが```NGKI0033```を参照しているという意味で，具体的には，このコードが```NGKI0033```の仕様を実装していることを示しています。仕様に短い識別名であるタグを付けることで，短い記述で仕様を参照することが可能になります。

さらに，[TOPPERS/ASP3カーネル](https://www.toppers.jp/asp3-kernel.html)のテストプログラム（具体的には，コンフィギュレータのテスト）中で```NGKI0033```という文字列を探すと，以下のコードが見つかります。

```test_cfg/pass2_obj1.cfg
/* タスクが1つも登録されていない場合［NGKI0033］*/
```

ここで```NGKI0033```を参照しているのは，このテストケースが，```NGKI0033```の仕様をテストしていることを示しています。

このようにタグを使用することで，仕様とそれを実装するコードやテストケースを関連付けることができます。

## トレーサビリティとは？

このように，設計ドキュメントやコードの間を関連付けることを，トレーサビリティと言います。

トレーサビリティは，高い信頼性を求められるソフトウェア開発では必要とされています。例えば機能安全規格（IEC 61508やISO 26262など）では，高い安全性が要求されるシステムを開発する場合には，以下のトレーサビリティを取ることが要求されています。

* V字開発モデルの左上から下に向かってのトレーサビリティ

具体的には，要求仕様から外部仕様，外部仕様からアーキテクチャ設計，アーキテクチャ設計から詳細設計，詳細設計からソースコード（設計書が何段階あるかは，プロジェクトによって異なります）の間を関係付けます。これにより，ある要求がどのように設計され，どのように実現されたかを追跡することができます。

* V字開発モデルの左から右に向かってのトレーサビリティ

具体的には，要求仕様と受入れテスト，アーキテクチャ設計と結合テスト，詳細設計と単体テスト（この対応も，プロジェクトによって異なります）の間を関係付けます。これにより，ある要求または設計が，どのように検証されたかを追跡することができます。

![トレーサビリティのイメージ図](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/919375/8f60e1a5-49fe-c88e-5277-9f3104833ca4.png "トレーサビリティのイメージ")

この他に，設計と関連文書（規格文書，開発プロセス規定，コーディング規約など）を関連付けるトレーサビリティも有用です。

なお，タグを付ける方法は，トレービリティを取る方法の1つに過ぎません。例えば，詳細設計書に関数名が書いてある場合には，詳細設計とソースコードの間の関連付けは自明ですので，タグを付ける必要はありません。また，タグを使わずにトレービリティを管理するツールも存在します（タグを使ってトレーサビリティを管理するツールもあります）。

## トレーサビリティの目的

トレーサビリティを正確に取ることは，かなりの手間がかかります。にもかかわらず，トレーサビリティを取ることが要求されるのは，次の2つの理由があるためです。

#### (1) 実装・検証に漏れがないことをわかり易く示す

トレーサビリティが取れていると，ある要求事項が，漏れなく設計・実装され，検証されていることを，容易に示すことができます。

このことは，ソフトウェアが大規模になるほど重要になります。膨大な設計書，ソースコード，テストケースを渡されて，それをレビューしろと言われたことのことを想像してみてください。

前述の機能安全規格では，高い安全性を要求されるシステムは，第三者評価が求められています。安全なシステムが開発されたかを第三者が確認するためには，トレーサビリティが取れていないと，非常に大きい工数を要してしまいます。

#### (2) 設計変更時の影響分析を容易にする

ある要求が変更になった場合に，その影響が設計やソースコード，テストケースのどこに影響するかの分析を容易にすることができます。その結果，ソフトウェアの変更工数が削減できます。派生開発が多い組込みシステム開発では，変更工数の削減が特に重要になります。

また，ある設計を変更する時に，それがどの要求に影響を与えるかの分析も容易になります。性能向上などの目的で設計変更することはあると思いますが，その結果，ある要求が満たされなくなるような状況を防ぐ効果があります。

## TOPPERSカーネルの現状

最初に例示した通り，TOPPERSカーネルの仕様書やソースコードの中には，トレーサビリティのためのタグが記述されていますが，上で説明したほどしっかりしたトレーサビリティは取れていないのは現状です。

まず，TOPPERSカーネルには要求仕様書がありませんし，設計書も部分的にしかできていません。TOPPERS第3世代カーネル（ITRON系）統合仕様書には，網羅的にタグを付けてありますが，ソースコードやテストケースは部分的にしかタグを付けていません。また，上述した「ドキュメントの作成中のトレーサビリティを取る」も実践できていません。

ここまで読まれて気付かれた方もいると思いますが，実は，設計書なしに，外部仕様とソースコードを関連付けようとしている点に無理があります。設計書の中にタグを埋め込み，外部仕様と設計，設計とソースコードを関連付けるトライアルも行っていますが，まだ極めて部分的にしかできていないのが現状です。

TOPPERSカーネルは，良いソフトウェア開発の見本にしたいと考えており，このような不十分な点も徐々に改善していきたいと考えています。