version 0.4
目次
本書は、ソフトウェア開発の実際の作業に則しながら
品質を保証する手順のテンプレートです。
本書は、筆者の開発手順をモデリングしただけであり、
作業を強制するものではないので、代わりになる方法があれば
その方法を行っても構いません。
本書は、2001 年に ISO 9001 の
『4.4 設計管理』
『4.5 文章およびデータの管理』
に対応する品質システムとして適合することを目標としています。
本書で向上する品質とは具体的に、次のことです。
- 顧客の希望に合ったものを開発すること
- 顧客が現状を把握できること
- 完成時期を予測できること
- 欠陥が少ないこと
- すばやく開発すること
- 要求や作業の漏れをなくすこと
- 開発者の能力を向上すること
参考文献
-
品質システム構築の手引き
飯塚悦功監修 ソフトウェア ISO 9000 シリーズ研究会編集
ISBN4-8171-6070-5 日科技連 ￥2000
|
場合によってはプロセスの順番を変えたほうが
効率がいい場合がありますし、
各自の判断で順番を変えたところで
品質が下がることはまずないと考えています。
ですので、本書で書かれているすべてのプロセスの順番は、
一般的な手順を示しているだけで、厳密に従う必要はありません。
従う必要があるのは、出力（各文章、項目、プログラムなど）を
そろえることです。
本書に書かれているサンプルの書式は、必要事項を踏まえたサンプルであり、
必ずしも同じ体裁である必要はありません。
開発は、次の手続きを繰り返して進んでいきます（スパイラル開発）。
１周の構成として、計画、作成、試験の終了に順番があるだけで、
実際は開始の時点から、計画、作成、試験が同時に平行して行われます。
ただし、各フェーズで作成する内容は明確に決めています
（見積もり作成、入出力設計、イベント設計など）。
特にフィードバックを得るために１周目を小さくすることを
プロトタイピングと呼びます。
開発規模が小さいために、１周で済む場合は、試験終了後すぐに
出荷モードに入ります。
１周ごとに明確なマイルストーンを設けます。
現バージョンの開発規模が小さいために、各種書類を１枚にまとめたり、
レビューを一度に行うことは構いません。
- 計画
- 作成
- 試験
上のスパイラルとは独立して以下の手順を行います。
オンライン文章（HTML）は、文章名（またはファイル名）と更新日付で
文章を識別します。プロジェクトに特有でない一般的な文章は、
特定のフォルダ（サブフォルダ）にマスターとしてまとめます。
通常、そのマスターへリンクを張るようにしておきます。
バージョン番号は文章のどこか、またはファイル名に必ず記述します。
ペーパー文章は、一般的な台帳と文章番号による管理をします。
承認欄（査閲覧）は文章のどこかに必ず記述します。
承認者（責任者）が承認の根拠となる裏づけ情報を利用できるように
文章には参考文献や設計の根拠などを記述します。
自分以外が作成したオンライン文章は、
チームで共有するハードディスクに入れて管理しておきます。
バックアップもとっておきます。
フォルダの構成は自由としますが、なるべく深くならないようにします。
ペーパー文章に直接メモを書くとバージョンが
上がったときに消えてしまうので、別紙のメモに書くようにします。
常に最新版のみを参照するようにします。
ペーパー文章とオンライン文章の好みが分かれるので、
なるべく両方をもらうようにします。
（コストや秘密保持の場合を除く）
発行手順（バージョン固定）
社外に提出するとき、社内レビューを行ったとき、
長い間更新を通知していなかったときに通知したときなど、
自分以外の人に文章が渡ったときにバージョンを固定します。
バージョンを固定の手続きは以下のようにします。
- リンクしている文章はコピーを作成して、
１つのフォルダ（ディスク）に全ての文章が入っているようにする
- 文章の内容を確認する。必要ならレビューを開催する
- バージョンを固定する（承認する、発行する）
非公式的な公開のときは、バージョンに「作成中」が
わかるように記述します。
承認は責任者が確認したことを示すことです。
責任者が確認したことを証明するレベルを次のようにします。
- Level 1. オンライン文章（の印刷）の承認欄
- Level 2. 受領書のコピー
- Level 3. ペーパー文章の承認欄の確認印
- Level 4. 電子受領書を発行した者のメールソフトの記録
- Level 5. 電子承認
- Level 6. ペーパー文章の承認欄の証明印
- Level 7. 承認者自身の確認
通常の文章に記述するのは、Level 1 の証明で十分です。
ただし、重要なミーティングでは Level 1 では不十分なので、
レベルの高い証明も一緒に提示します。そのために、
レベルの高い証明をマスターとして保管しておきます。
プロジェクトにより、通常の文章に記述するものと、マスターとして
保管しておくもののレベルを決めておきます。
（通常は、Level 1 と Level 3 にします）。
開発体制表、スケジュール表、作業スタック、要求履歴、作業履歴、
数値データを開発管理帳（計画書兼品質記録）にまとめます。
文章がかなり流動的であるため、オンライン文章として作成します。
開発管理帳は、基本的にプロダクト（製品）に含めません。
- 記述項目 -
1.はじめに
- 各書類へのリンクを記述する
- 完了予定時期を示す（第４章参照でも可）
- 書名、ケースバイケースの読み方の説明
- 読むにあたって必要な用語や記述方についての説明
2.プロジェクト名
- プロジェクト番号があれば、それも記述します。
- プロジェクト名が決まっていない場合は、仮の名前を付けておきます。
開発者（有資格者、適切な担当者）と責任者（管理職）を明示する。
顧客（依頼元、製品発注元）やサポートグループなどのも明示する。
過去の開発者や助言をいただける人も明示する。
それらの連絡先も明示する。
社名、部署、担当者名、電話番号、e-mailアドレス。
|
責任者を明確にしておくことで、助言や対処などが得られるようにする。
そのために、連絡先が重要。
開発者が変更になった場合は、過去の開発者として残しておく。
|
締め切り（目標日）やイベントのように日付か決まるものは、
スケジュール表としてまとめる。
自分のスケジュールと対外スケジュールを分けるとよい。
スケジュールは、あまり厳密にすると、そのときの優先順位が
反映されなくなるのでほどほどに。
レビュー等、開発手順をスケジュールに入れる。
ただし、開発初期では、日付を厳密に決めなくてよいが、
数日前には日時を厳密に決めておき、レビューの開催場所や
受け渡し場所を確保しておく。
スケジュールは、定期的に更新します。その際、バージョン管理をします。
開発が遅れている場合は、被害が大きくなる前に早めに顧客に通知します。
済んだスケジュールは、スケジュール表を更新しても記述します。
|
スケジュールをバージョン管理することで、是正処置の資料になります。
|
作業できる時間も永久にあるわけではないので、
優先順位順に作業項目を並べた作業スタックを利用します。
一日の作業内容を計画するときに見ます。
作業スタックにも数値データを使用することができます。
優先順位[高],[中]の残り作業時間も添えます（単位は week）。
実行が正式でないものは、優先順位[低]に入れる。
作業スタックに作業を入れる際、締め切りが決まっているものは、
スケージュールにも記述する。
懸念事項も作業スタックに入れる。（調査のため）
作業スタックは、プロジェクトごとに分けるとよい。
特にバグリストは分けるとよい。（バグリストは公開することが多いため）
作業スタックの項目には時効を作ってもよい。
[サンプル]
自分以外から要求があったら、要求内容をリストに日付順で追加します。
要求履歴は、要求があったことを忘れないため、
要求があったことを確認するためにとります。
作業スタックでも確認が取れますが、
日付で整理されているほうが確認を取りやすいためです。
記述項目は次の通り。
- 日付
- 要求対象、要求内容、対処方法
- 要求者
- 優先順位
- 状況欄
優先順位は以下のようにランク付けする
- [高] 至急修正しなければならないもの
- [中] 通常の修正事項
- [低] 余裕があれば修正するもの（コストパフォーマンス的にも）
- [-] 処置事項無し
- [簡] 優先順位に関わらず、すぐに修正することができ、すぐに修正するもの
レビューやミーティングがあったとき、
リストにレビューが開催されたことを要求内容の項目に記述して、
その資料にリンクできるようにしておきます。
（そのとき、要求者は[-]、優先順位は、最も高い優先順位か[簡]、
状況欄は n/m 分数表示で、すべて完了したら [完了] にします。）
完了と未完がすぐ分かるように、状況欄に未完マーク（■）
を付けるとよいでしょう。
進捗状況の大体の把握のために数値データを用いる。
（その際、Knowledge Take! アプリケーションのカウント機能を使用するとよい。）
ただし、以下に述べる方法は、明確に定義され、一般的に使われている
ものではないが、筆者の経験上、進捗状況の把握には妥当であると判断している。
- 機能定義の進捗状況 : 完了, 一部完了, 未定義, 見積もり, 網羅度
- 関数作成の進捗状況 : 完了, 一部作成, 未作成, 見積もり, 網羅度
- 試験の進捗状況 : バグ累積数, 完了, 一部完了, バグ(Lv1/2/3), 未試験, 見積もり, 網羅度
- 作業スタックの消化状況 : 残り(高/中/低）, 見積もり
まだ１つも手をつけていない場合、「仕様作成中」と記述します。
それぞれ、機能、関数、試験項目の数を記述します。
状況欄に見積もりを記述しているなら、機能、関数、試験項目の見積もり時間の合計を記述します。
進捗状況のパーセントは、完了数:x1, 試験の一部完了数:x0.8,
機能/関数の一部完了数:x0.5、バグ数:x0.5 の重みを付けます。
網羅度は、以下の記号を用います。
- [A] 完了数も十分になり、以後、追加が無いと思われるもの
- [B] 様々なケースを考え、考えた時間が十分あるとき
- [C] 少し考えた程度
ただし、カバレッジ・ツールがある場合、そのデータも記述します。
作業スタックの消化状況は、作業項目の残り数を
優先順位別に記述します。優先順位[高]と[中]が完了することを目標にします。
- [高] 優先的に行う作業
- [中] 通常の作業
- [低] 余裕があれば行うもの、次期版で対応するもの
バージョンフィックスしたときは、進捗状況を記録しておきます。
新バージョンでも同じ試験仕様書兼報告書を使う（更新する）ので
進捗状況を計るときに必要になるためです。
[サンプル]
1.はじめに
- 書名の記述
- ケースバイケースの読み方の説明
- 読むにあたって必要な用語や記述方についての説明、
（技術的なことは、9章で説明する）
2.適用範囲
- 開発の関連文章の明示（文章番号も明記）
この場合、計画書、試験仕様書兼報告書、性能報告書を指す。
- 準拠文章の明示
開発するものの全体や部分について、
完全に満たしている仕様。
- 参考文献、参考文章
開発において参考になる資料や書籍などについて記述する。
旧バージョンも記述する。
- 動作環境
MPU、OS、使用ライブラリについて記述。
仕様作成の段階では暫定となることもある。
最終環境が入手できないときは、開発時の動作環境も記述する。
3.目的、要求定義
- 要求内容の明示と、その要求に応える機能と対応付けをする。
- 要求する性能も記述する。
- 開発方針も記述してよい。
4.全体の構成
- 全体の構成
外部の末端までの概略を示す。図は必須。
- 内部構成
内部の構造の概略を示す。図は必須。
構造が単純な場合は省略可能
- 開発環境
コンパイラ名、バージョンの記述。
仕様作成の段階では暫定となることもある。
- 開発規模
開発の初期では、予想値を書く。
開発途中では、現状値も一緒に書く。
5.使い方
- リンク方法
ライブラリファイルやヘッダファイルの一覧。
- コンパイル方法
コンパイルする場所（フォルダ）。
設定マクロの解説。
- 各機能の実行手順
関数の呼び出し順序やデータの設定の仕方についての概略。
多くの機能がある場合は、「6.機能説明」で解説する。
（そのように記述する）
6.機能説明
- 単機能の場合は、本章は省略可
- それぞれの機能について以下の項目を記述する
- 概要
- 説明（詳細）
- 関連する関数、または、使い方（関数の呼び出し順序）
7.関数の説明
- ユーザが使う関数のみ記述する
- それぞれの関数について以下の項目を記述する
- 書式（プロトタイプ形式、引数の説明）
- 補足（ユーザが意識する必要が無いものは記述しなくてよい）
8.構造体の説明
- ユーザが使用する構造体のみ記述する
- ユーザがメンバ変数を操作しない場合は、
カプセル化されているとして詳細の解説はしなくてよい。
この場合、構造体一覧に簡単に記述するだけでよい。
9.補足、解説
- エラーコード一覧、エラーコードの取得方法の説明
- 構成ファイル一覧、提供する全ファイルの構成
- その他、技術的な解説や、ヒント
- 用語説明
- 制限事項
履歴
- ユーザに影響がある部分の修正内容を記述する
- 必要に応じて、日付や変更者を記述する
- 可能な場合には、変更の性質（？）を明確にする
[サンプル]
1.はじめに
2.適用範囲
3.試験対象、目的
- 「（試験対象の名称）を試験します。」だけ記述しても構いません。
- 特定のバージョンや機能のみ試験する場合は、そのことを記述します。
- 特に目的がある場合のみ、目的を明示します。
- 試験対象の基本仕様書へのリンク
- 特に記述すべき、行わない内部モジュールの試験については、
「（内部の試験）は本書の範囲では、行っていません」と記述します。
- 使用時の環境と同じ場合は、「基本仕様書の記述と同じです。」でも可。
- そうでない場合は、図示すること。
- 「（本書）の方針に従います。」と記述するだけで構いません。
- 顧客との取り決めが特にある場合、具体的に記述します。
- 特有の試験方針（試験をしていないケース）がある場合、
記述します。
- 主に検査器具の使い方（へのリンク）を示します。
検査器具の妥当性についても記述します。
（実績による妥当性の判断、または妥当性を示す文章へリンク）
- 一般的な場合、「（デバッグ環境）で実行する」だけで構いません。
ただし、デバッグ環境の使用方法を自体を記述するか、リンクを
記述するようにします。
- チェック方法は、「（本書）の方針に従います。」と
記述するだけで構いません。
- 最初に、試験項目の説明を記述します。
テストを行っていないケースがあれば、その理由も記述します。
- 基本仕様書の機能説明の項目ごと（機能ごと）に試験グループを作成します。
- 被試験関数は、試験の対象となる関数の名前です。
- 前提関数は、被試験関数を呼出す前に呼出す必要がある関数の名前です。
- 条件一覧は、各テスト項目を実施する際に、
網羅する必要がある条件を列挙したものです。
表の右の列にコンマで区切られた値が各条件です。
それぞれの行の中から１つ条件を選んで、
すべての組合せを試験します。
- それぞれの試験項目に対して、TP関数（テストプログラムの関数）、
テストケース、チェック項目、状況欄を記述します。
- 状況欄には、一般的な記述内容以外に以下の内容も記述します。
- バグが発見された項目には目立つように★マークをつけます。
程度の違いによってバグのレベル分けをします。
- Level-1 : 見た目に少し影響のあるもの、または無いもの
- Level-2 : 回避策のある致命的なバグ
- Level-3 : 回避策の無い致命的なバグ
- Level-不明 : チェック・プログラムによって、バグの存在のみがわかっているもの
- 状況（バグ等）の説明に別途文書がある場合は、その文章へのリンクを記述します。
1.はじめに
2.適用範囲
- 各テスト項目ごとに、状況欄を作る。
- 試験項目がわかるようになっていれば、それぞれの状況欄に対応する
試験項目番号を記述する必要は無い。
- 大項目ごとに別の試験者が試験した場合は、フォーマットが異なっていても良い。
- 自動テストの出力結果をコピーするか、リンクする。
- 出力結果には日付を証明するものを付けるとよい
- 出力結果は、OK のみの簡単なものでも構わないが、
信用性を持たせるために各テスト項目の出力値を書くと良い
主にバグの対処について。
信頼性の参考資料となる。
仕様の変更については、仕様書の履歴に記述する。
性能向上の記録
重要な設計上の特性がすぐに分かるように構成を工夫する。
output ... 計画書（優先順位）
要求内容をある程度まで明確にしてから、見積もりに入ります。
公式な要求定義の手順
- 企画立案準備
- ニーズの調査、目的と期間の明示
- 仕様の素案を作成、参考資料を用意
- レビューを行う
- 目の前の目的から究極の目的までをミーティング、
目の前の目的から現実的な対処方法をブレイン・ストーミング
- レビュー記録を作成
設計、実装、試験まで考えて実現可能な対応策まで絞り込む、
工数的に実現できないものは「見送り」とする
ボトムアップかトップダウンかは T 型に行う
バージョンアップ時の公式な要求定義の手順
- 企画立案準備
- 新しいニーズの調査
- 前のバージョンで見送られた機能を仕様に入れるかどうかを、
要求履歴やレビュー記録を参考に検討する
- 仕様の素案を作成、参考資料を用意
- レビューを行う
- レビュー記録を作成
前のバージョンの要求履歴やレビュー記録は使用しなくなるので、
全ての要求内容を新しいレビュー記録に記述する
- メールやペーパーで要求内容の具体的な内容を聞く
- そのメールやペーパーを要求履歴に追加する
- レビューのときに、それまでの要求履歴を確認してもらう
見積もり
期間見積もりは、担当者が判断した週数を扱います。
１〜３週程度に分解した機能に対して見積もりを行い、
それらの期間を合計したものを全体の見積もりとすると精度がよくなります。
１〜２週間程度の誤差であれば認められることが多いので週数を扱う。
開発期間を見積もるときは、LOC に変換しない。
|
見積もりは、ここ３個月
見積もりの考慮事項
品質がよいものを要求しているかどうかをヒアリングしておいて、
見積もりに反映させます。
顧客満足度を基準に要求を定義しますが、
実際の作業は自分の学習などが反映されるものなので
自己満足度を満たす作業も見積もっておきます。
見積もりのフィードバック
過去の見積もりと、実際にかかった時間を比較して
次回の見積もりにフィードバックします。
何度も見積もっていると、見積もりが短いことが多いことに気づくと思います。
そのため、見積もった値にある程度の倍率をかけて、増えた期間を
予備期間にしておくとよいでしょう。
output ... 基本仕様書
[
第１シス技・標準]
基本仕様書は、機能概要と、インターフェイスを
定義するのが目的です。
そのためには、アルゴリズム（詳細設計）や、
TP のラフ・コーディングなどを行うとよいでしょう。
基本仕様書が完成するのは、プログラムが完成するときと同じです。
しかし、それではいつプログラミングを始めたらいいか分からないので、
仕様書完成レベルの基準を示して、それに対するアクションも示します。
表.仕様書完成レベル
| Level | 状態 | アクション |
|---|
| 1
| 2.適用範囲、3.目的、要求定義、4.全体の構成 が完成し、
6.機能説明、7.関数の説明 の概要が完成した |
機能優先順位レビューを行う |
| 2
| すべての項目を一通り完成した |
インターフェイス・レビューを行って
コーディングを開始する |
| 3
| コーディングして仕様の変更が少なくなった |
仮完成 |
大きなスケジュールの遅れや実現不可能などの理由により、
仕様を変更したり仕様から削除する場合、次の手順を踏む。
- 変更内容の具体化、変更後の文章を作成（修正ではない）
- 要求履歴やレビュー記録の状況欄に
「変更予定」または「見送り予定」と記述する
- 責任者や顧客に報告する。重大な変更の場合は承認をもらう。
- 変更前の文章をどこかにまとめておき、変更後の文章に入れかえる
- 仕様書の履歴を記述する
- 要求履歴やレビュー記録の状況欄に「変更」または「見送り」と記述する
◆
設計 〜 各担当による機能実現の手段
設計変更は、すべて仕様書の履歴に記録するが、
工数がかかる大きな変更のみ、実施前に有権限者に報告する。
前回の承認者と変わった場合、前回の承認者にも報告する。
ソフトウェアは、データを操作することなので、
データとプロセスを明確にすること。
あとは、規模（構造ツリーの位置）の問題のみ。
参考文献
-
オブジェクト指向方法序説 基盤編
J.Martin, J.Odell 著
ISBN4-8101-8592-3 トッパン ￥5800
|
|
前回の承認者にも報告するのは、顧客に不当な変更が無かったことを
示すためらしい。
|
何かを出力する（データを参照される）ために各モジュールが
存在しているものと考えて、あとで修正が生じにくくなるように、
必要な入力データを洗い出してインターフェイスを定義する
方法を示します。
1.出力属性の洗い出し 〜 システム全体から考える
ユーザや他のモジュールが必要とするデータを出力属性として
列挙します。ただし、出力属性は、適切なモジュール（クラス）に
割り当てるようにします。
2.入出力ツリーの作成 〜 各モジュールごとに考える
出力属性を計算するのに必要なデータを入力属性として
ツリー状に列挙します。入力属性が、モジュール内部の
出力属性か、モジュール外部の出力属性かに関わらず列挙します。
入力属性が重なった場合（コモン・オブジェクト）は、
ツリーのノード間でリンクします
（リンク先は属性よりオブジェクトのほうが良い）。
入力属性として、次のような視点があります。
（チェックリストとして使用できます）
- Parameter: 計算の元となるデータ、定数
- Attribute, Status: オブジェクトの属性や状態
- Identifier: 名前、識別子、アドレス、位置、ハンドル
- Storage, Table: Identifier から様々なさまざまなデータや
実際に使われるデータを取得できるもの
- Relation, Element: 関連するもの、構成要素、内部、外部
- Number: 要素数、最大要素数、サイズ
- Display: 出力結果を出力する媒体
- Default: デフォルト値
(2.)で作成した入出力ツリーのうち、
自分のモジュール（クラス）の属性には☆印をつけます。
他のモジュールから参照する属性には★印をつけます。
★印を付けた属性は、適切なオブジェクトの属性や状態になるように
グループ分けしてデータ・インターフェイスを定義します。
4.入出力ツリーの更新要求
外部/内部インターフェイスが決まったら、その担当する
モジュールの出力属性に追加してもらうように要求します。
追加した属性に対して必要な入力属性が新たに洗い出す
必要があるので 2. に戻ります。
5.実装
入出力ツリーができたら、ソースコードにします。
数値や文字列といった単純なデータでなければ、クラスにします。
ツリーのリーフ（末端）のデータは、メンバ変数にします。
ツリーのノード（非末端）のデータは、メンバ関数にします。
ただし、コモン・オブジェクトより下のデータは、
メンバ変数とメンバ関数の両方にします。
複数になるデータは、コンテナにします。その際、
システムによっては記憶領域の管理が必要になります。
設計しようとしているオブジェクトがどのように操作されるかを、
考えられる多くのプロセスで考え、汎用的になるようにします。
どのようなプロセスであれ、設計しようとしている
オブジェクトの操作のされ方（ライフサイクル）は、
以下のような流れになります。
上の流れのうち、どこに区切りを置いて関数とするかを決めるのが
イベント設計です。
関数インターフェイスの作成の基準はタイミングです。
オブジェクトに対する入力または出力の属性の組み合わせが関連深く、
ケースによって変化しないタイミングで、
関数インターフェイスを作成します。
また、他のオブジェクトの属性を入力している場合、
その属性が変化したときをイベント発生とし、
そのタイミングで関数インターフェイスを作成します。
イベントを設計したら、設計したオブジェクトを使用するオブジェクトに、
設計に合わせるように要求します。
なるべく変更を生じなくするには、インターフェイスを
合わせるためのクラスを間にはさむとよいでしょう。
-
入力属性が集まって何かを表現しているときなど、
一度に設定しないと意味が無いものは、入力属性が多くなります。
そのような場合は、多くの引数を持つ関数か、
各メンバを公開している構造体を引数に持つ関数を設計します。
いくつかの設定ステップを踏んで入力が完了するスタイルに
なることもあります。その場合、サンプルが重要になります。
入力属性が多くても、Identifier と Storage を指定する場合は、
引数は少なくて済みます。
-
入力属性が複雑になっているときは、複数のオブジェクトの
属性にグループ分けします。そして、そのオブジェクトを
引数に持つ関数を作成します。
-
入力属性を指定する関数は、入力属性の種類によって
関数を分けます。種類が異なると引数の数が変わることが
よくあるので、同じ関数にすると、有効な引数と無効な引数が
できてしまい、ややこしくなります。
-
入力属性が外部のオブジェクトの属性に対応する場合は、
そのオブジェクトを引数に取ります。
入力オブジェクトの型によって関数を分けます。
ただし、入力引数を Msg 型にした場合は、種類によって
分ける必要はありません。
-
何度も入力したり出力したりして、ある特定のオブジェクトと
関連が深い場合は、引数で入力オブジェクトを毎回指定するのではなく、
初期化や設定によって関連付けさせておきます。
-
多くの属性を出力することになっても、
基本的に１つの属性を出力する関数だけを作成しておいて、
入力するプロセス（またはオブジェクト）が、それらの
関数を何度も呼び出すようにします。
-
あまりに出力属性が多い場合は、一部のメンバ変数を公開するのも
１つの手です。
たとえば、前半の n個のメンバ変数を公開するようにします。
ただし、公開したとしてもメンバ変数の値は直接変えないで
設定関数を呼び出すようにします。
プログラムコードを、詳細仕様書となるように可動性のあるコードを記述します。
C 言語のコードは「オブジェクト記述法 COOL」に従うことで、
オブジェクト指向の恩恵を受けられるようにします。
開発が制御不能にならないように、
以下の同期安定化プロセスを一通り実行するまで
別の作業をなるべくしないようにします。
- 作業スタックの確認
- リビルドする
- 動作を確認する（メインとなるソースを参照しながら）
- バックアップを取る
- 旧版と新版を #if で分ける
- 旧版をビルド＆クイックテストする
- 新版を作成する
- 設定ミスがあったとき、アサートされるようにする
- 手動テストを記録する
- ドキュメントを更新する
- 作業履歴に追加、または仕様書の履歴に追加する
詳細仕様の検討は、関連するプロセス（関数）やデータ（変数）の
仕様を確認しながら行うので、関連するコードを頻繁に参照することに
なります。そのコストを減らすための１つの方法として、
Knowledge Take! アプリケーションを使用します。
モジュールの再利用を促進するために、Module Mixer
アプリケーションを使用します。
正しいバージョンの設定、依存するモジュールのリンク、
ファイル・ディレクトリの調整、
必要なヘッダファイルのインクルード、
メイクファイルの作成など、再利用する際にかかる作業を
自動化することにより工数を削減します。
output ... 試験仕様書兼報告書（試験報告書）
手順は、テストプログラム作成を参照
プログラミング（詳細仕様作成）の段階で、試験仕様書兼報告書の
記述を開始し、動作確認程度の初期の試験
を同時に行います。
（基本動作の正常試験を動作確認と呼びます）。
試験の進捗状況は、数値データを使用します。
試験仕様書の記述範囲は、妥当性確認事項と
試験結果報告まで含みます。
初期テストケース考案のヒント
- 初期テストでは、通常の動作ができるまでの多くのバグをつぶす
ことがメインになります。よって、仕様書に書かれていることが
実現されているかを試験するブラックボックステストを行います。
- リリース版とデバッグ版の両方をテストします。
詳細テストケース考案のヒント
- 詳細テストでは、隠れたバグを見つけることがメインになります。
よって、内部の分岐に注目した網羅度を基準に考える
ホワイトボックステストを行います。
- 弱い詳細テストでは、内部モジュールの網羅度を考慮しません。
- 極限の値を指定するテスト、エラー入力のテスト、デフォルト入力のテスト
- 長時間耐久テスト
- リソースが少ない状態のテスト
- すべてのテストケースで正常な結果が出れば終了としますが、
顧客と試験仕様書兼報告書をレビューすることによって決定します。
終了条件は、たとえば、レベル３のバグが無いこと、などが考えられます。
顧客がいない場合は、責任者と相談します。
十分な試験が行われたかどうかの判定を、
レベル１のバグが残っていることとして試験を強化させることが
考えられます。
- その他、試験対象特有の試験方針を記述します。
- 上記のテストプログラムのテンプレートを使用した場合、
結果が正常なら、Errors_log グローバル変数に、
Errors_okLabel グローバル変数の文字列が記入されます。
- 問題が残ってしまったテストケースについては、
状況の欄に「見送り」と記述します。
- 試験完了の予定日よりすぎてしまった場合、
スケジュール表を修正します。
- 最終実行環境（評価ボード等）で試験を行うこと。
最終実行環境が入手できないときは、別の環境で進める。
- デグレードしていないことの確認は、テストプログラムを
全て実行することで行う。
用語説明
- 試験, テスト : 検査と妥当性確認をまとめて試験またはテストと呼びます。
- 検査 : 達成しなければならないことを論理的、
数値的に示すことです。
- 妥当性 : 数値で確認できないなど、論理的には説明できないが
感覚的に適切であるとき、妥当であると言います。
妥当性を明文化するには、その適切である方法（目で確認するなど）を記述します。
- 目的, 方針 : 目的はゴール、方針はゴールまでの行き方です。
- 基本条件一覧 : 基本的な設定条件の一覧です。ただし、
テストケースによって変更されることがあります。
参考文献
-
ソフトウェア・テストの技法
Glenford J. Myers 著
ISBN4-7649-0059-9 近代科学社 ￥2700
|
- 内部モジュール（ハード）の試験は、対象となる試験仕様書には
記述しなくても構わない理由は、内部がどうであれ外部から見たときに
仕様を満たせばよいからです。
- 試験用の数値がソースコードにのみ書かれることを許可した理由は、
テストケースの仕様書にテストプログラムの関数名が書かれており、
仕様書からたどることができるためです。
- テストの結果の値をすぐ確かめられるようにする理由は、
データ見せて顧客を納得させるためです。
|
output ... 試験仕様書兼報告書（試験報告書）
試験項目ごとのプロセス
以下は、テストプログラムがまだ作成されていないときのプロセスです。
- テストケースの確認
- テストプログラムのコーディング
- コンパイル
- テスト実施、手動チェック
- デバッグ
- バグの記録を作業履歴へ
- 試験報告書の状況欄を更新
チェック方法
- チェック項目には、妥当性確認事項を含めます。
- チェックするために必要な妥当なデータは次のように取得します。
- 手動計算による結果との比較
- 別のプログラム（電卓、エクセル）の結果との比較
- 他のアルゴリズムとの比較
- 妥当なデータとの比較は次のように行います。
- 自動テスト
プログラム内部で出力結果をチェックします。
ソースの修正により他の影響がないかチェックします。
自動テストは、開発中に何度も実行するので
バグのある部分はチェックしないようにします。
リリースするときにバグが残っているかどうかに注意します。
- 手動テスト
自動テストとは反対に、出力結果を目で見て確認することです。
ツールを用いて確認しやすい形にします。
リリース版のみ行います。
テストプログラムのコツ
- テストプログラムの関数は、ほとんどがユースケースです。
ですので、メソッドやオブジェクトの再利用とは異なり、
コピー＆ペーストの再利用をしないとプログラムが複雑になります。
- テストプログラムを試験の詳細仕様として扱っても構いません。
つまり、妥当性確認のための試験用の数値がソースコードにのみ
書かれることもあります。
- データとテスト内容を一緒の関数に入れておきます。
- テストプログラムには、サブ関数をなるべく作らないようにします。
- １つのテストケースに複数の試験関数（データ）がある場合、
その意味を仕様書に記述、またはソースにコメントします。
- 試験の判定のみ使うであろうメソッドは、
試験対象のオブジェクトに追加しても構いません。
ただし、#define ERRORS_CUT_DEBUG_TOOL でカットできるようにします。
- テストの結果の値は、実行してすぐ確かめられるようにします。
- テストの結果が正常の場合、それが確かめられるようにします。
- 単純な入力と出力の関係がある（複雑な計算をしない）モジュールを
スタブにして開発を後回しにするとよいでしょう。
状況欄は、各文章中に含まれる要求項目や試験項目の状況を示す欄です。
この欄を活用するためには、オンライン文章の特徴である修正が容易である
ことが条件になります。
未完了時, 見送り時の記述
状況欄には、現状（バグ状況など）を把握するためのメモと、
完了するまでの見積もりを記述します。
見積もりは、「見積もり=2hours」のように記述します。
見積もりを予想できない場合は、「見積もり不能」にします。
現バージョンで作業する工数が避けない場合は、「見送り」と記述します。
納期までにバグが取れないと予想される場合は、「仕様化」と記述します。
基本仕様作成が完了していない機能の詳細設計など、
後工程の項目が未確定の場合、後工程を含めた見積もりを行います。
詳細設計が完了していない関数の試験項目など、前工程が残っている場合、
設計に付いては設計の状況欄、試験については試験の状況欄のように、
前工程と別々に見積もりを行います。
完了時の記述
記述する内容は次の通り
- 「完了」の記述（明確なら記述不要）
- 担当者（実施者、試験者）
- 完了日
テストした人が一人だったり、試験項目の大項目ごとに明確に分かれている場合は、
そのことを本章のどこかに記述し、状況の欄に試験者を記述しなくても構いません。
テストが済んだ日付がすべて同じだったり、試験項目の大項目ごとに明確に分かれている場合は、
そのことを本章のどこかに記述し、状況の欄に日付を記述しなくても構いません。
以上から、最も簡単な完了を示す記述は、次のようになります。
- 全項目の担当者を示す文章
- 全項目の完了日を示す文章
- 各項目の状況欄（チェック欄）のチェックマーク
内部α版リリース
- コンパイラ動作確認（リビルド）
- 実行ファイルの動作確認
- バージョン・フィックス
- 出荷準備（ファイル構成の整理）
- バックアップ
外部β版リリース
- 自動テスト
- バージョン・フィックス
- 出荷準備
- リリース時、配布先は、（株）と略さない。
- 他のお客に関するメモを公開しない。
[START_OF_PRIVATE]〜[END_OF_PRIVATE], [THIS_IS_PRIVATE] は公開しない。
- コピーライト表示する
- プロダクト名、バージョン番号の埋め込み
- 標準ディレクトリ構成にする（マスターの作成）
- バックアップ
外部正式版リリース
- 仕様固定
- 手動テスト＆中期デバッグ
- レビュー記録のレビュー（インベントリ）
- 残りの要求、指摘事項、バグの見送り検討
- サンプルの稼動状況から妥当性を確認
- 各文章の承認、各レビューの完了の確認
- 出荷準備
- リリース時、配布先は、（株）と略さない。
- 他のお客に関するメモを公開しない。
[START_OF_PRIVATE]〜[END_OF_PRIVATE], [THIS_IS_PRIVATE] は公開しない。
- コピーライト表示する
- プロダクト名、バージョン番号の埋め込み
- 標準ディレクトリ構成にする（マスターの作成）
- 最終テスト
- バックアップ
バグを早期に発見できるように予防をしておくことで、
強固なアプリケーションを作成します。
コメントによりケアレスミスを予防する
関数の機能や引数の説明をコメントにすること、
わかりやすい関数名や数式を書いて、
ケアレスミスの出にくいように作成します。
ASSERT トラップをしかけておく
処理の事前条件、事後条件に対応する ASSERT トラップを
できるだけ多く記述します。
また、未対応の部分にも警告が表示されるようにしておきます。
コンパイラを活用する
コンパイラのワーニングレベルをあらかじめ高くしておきます。
プロトタイプ宣言をしておきます。
掛け算など通常の式を書いても最適化がかかるのに、
シフト演算など読みにくいコードを書かない。
デバッグの作業は、以下のように法則化することができます。
その際に必要となるツールを Errors モジュールにまとめています。
- エラーを発生させ、再現性を確認する
エラーであることを無視してプログラムが実行されないように、
プログラムがエラーであることを示す動作（エラー関数を呼び出すなど）
を行わせる。また、エラーの再現性を持った条件を
容易に再現できるような特別な main 関数を用意する
（後に、テストプログラムとして流用する）。
ハードの完全なリセットとソフトの再構築（リビルド）を行って
再現性があるか確認する。
- 正常な値と異常な値の違いを認識し、エラーが発生する条件を洗練する
エラーが発生する最小限のデータ構成を作る。
プロセッサが通ったことを示すダミーデータをつけて調べる。
必要なら、別ケースで正常に動くデータのすべてとツールで比較する。
仕様やプログラムを確認し、データ構成自体が正当なものか検討する。
時系列（タイミング）にも注意する。
データの値とデータの格納場所（アドレス）に注意する。
- エラーの原因となるコードの位置を突き止める
まず、初期化を疑う。
それから正常な値が伝播しているコード位置と、異常な値が伝播して
いるコード位置を見ながら、２分検索アルゴリズムのように、
原因を特定していく。前回動いていた部分から追加した
部分をカットしたり、修正した部分を戻したりする。
似た出力データに対して通っているコードを区別するために
片方のコードのデータに目印をつける。
値を変化させているものを疑う。
疑っているものが合っていると仮定して推理する。
場合によってはサブモジュールの単体テストを作成する。
- エラーの原因に近い個所でエラーが発生するようにする
今後同じ原因でエラーが起きたときに、同じ原因追求を行う必要が
無くなるように、原因に近いところで ASSERT します。
- 修正と再確認と記録
バグを修正する。
修正したら、もう一度テストする。
今回発生したバグをテストケースに追加した後、
従来合格したテストをもう一度行う。
この再テストの工数を減らすためにテストプログラムやテストデータを
蓄積していく。
再びミスしないような仕組みを検討する。
バグの記録を作業履歴へ。
マルチタスク、マルチプロセッサ環境のデバッグ
マルチタスク、マルチプロセッサ環境では、
関数を追跡してもタイミング（他のプロセス）によって動作が異なってくるので、
上記の方法で発見することができないことがあります。
ウェイトをかけたときのみ動作する場合、
他のプロセスの動作が完了する前に次の要求を出していたり、
動作をキャンセルする要求を出している可能性があります。
ビジー状態を確認しているかチェックしたり、
次の要求を出すまでのプログラムの一部をカットしてみてください。
output ... レビュー記録（要求定義）
レビューは開発手順のマイルストーンごと、または
定期的（約２ヶ月間隔）に開催する。
- 準備
- 少しでも関係あると思われる日と全員に開催通知メール
（兼計画書、計画は後記のレビュー実施項目とする）
- 資料の用意（オンライン＆ペーパー）
- オンラインで自前に確認させるとよい。
修正中なら、オンライン版は開催30分前にダウンロードするように連絡する。
- 以下のレビュー実施の項目の確認、レビュー記録用紙を準備
- レビュー実施
- 非公式な要求定義による要求履歴の追加分の確認
- ウォークスルー（資料を読む）
- 指摘事項をレビュー記録に記録しながら進める
- 時間が少ない場合、概要を読んだ後、
ソフトウェアの構造から見たトップダウンでウォークスルー
- 一通り確認するまで、指摘事項はメモにとって後で指摘する
（メモ帳を配布しておく）
- 質問事項はすぐに受ける。
- （各書類のレビュー項目を参照）
- 基本仕様書：ISO 品質特性のチェック、
機能性、信頼性、使用性、効率性、保守性、移植性
- コード：構造体ツリー、関数ツリー
- ブレイン・ストーミング（自由な質疑応答）
- 今後の進め方、優先順位の決定
- レビュー完了判定（合否判定基準は一般的に使われているものを参考にする）
- レビュー後
- 計画書の変更(?)
（レビューを参照）
簡単な、関数コールツリー、構造体ツリーを用意する。
記述の仕方
- フォーマットやファイル形式は自由だが、必要な項目を含むこと。
- 文章番号、レビュー対象、開催日時、場所、出席者の記述
- レビューの主な着眼点があれば、記述。
- レビュー方法とその程度を記述。（ウォークスルー、シミュレーションなど）
- 確認事項、指摘事項、発案事項、懸念事項の記述
- 以上に関して、指摘対象と対処方法を決める。
ただし、すでに文脈に含まれている場合は明示しなくてよい。
- 処置者がすべてレビュー記録の記述者と同じでないなら、
処置者を指摘事項ごとに記述する。
- 必要なら備考の欄を加える
- 優先順位は以下のようにランク付けする
- [高] 至急修正しなければならないもの
- [中] 通常の修正事項
- [低] 余裕があれば修正するもの（コストパフォーマンス的にも）
- [-] 処置事項無し
- [簡] 優先順位に関わらず、すぐに修正することができ、すぐに修正するもの
レビュー直後の査閲基準
- 文章番号、レビュー対象、開催日時、場所、出席者の記述
- 各項目（行）について
- 指摘対象、指摘事項、対処方法について触れられていること。
- １文で指摘事項と対処方法の両方が含まれていてもよい。
- 確認項目（対処方法がないもの）の場合、
優先順位の欄に [-] が付いていること。
- 具体的な対処方法が見つからない場合、対処方法を
考えておくなどの対処方法が考えられる。
- 優先順位が、高・中・低の場合、優先順位が妥当であること。
- その他、気づいたこと
指摘事項の完了基準
- 状況欄には、指摘した問題が解決した時点（対処方法を実施した
時点ではない）で『完了』とし、完了日を記述する。
- 別のレビュー記録や要求履歴に全ての内容を引き継いでいる場合も
『完了』とする。
- 実施の確認や実施を見送るかどうかは、
出荷モードで行う。
（任意の時期にレビューしてもよい）。
状況欄の欄には「見送り予定」または「見送り」と記述する。
- 最終版（全ての状況欄が『完了』となっているもの）の
査閲、承認は、その完了を確認したものとする。
- 完了と未完がすぐ分かるように、状況欄に未完マーク（■）
を付けるとよい。
誰にでも分かる概要を示す。
詳細にたどりつけるようにリンク（文章、人）を張っておく。
- プロジェクト一覧
- 実績
- 問題点
- 予定
4.4 設計管理
| 項番 |
要求事項 |
対処方法・対応文章 |
| 4.4.1 一般 |
製品の設計を管理し、検証する手順を文章化し、維持すること |
開発管理帳で設計を管理し、試験仕様書兼報告書などのレビューで検証する |
| 4.4.2 設計および開発の計画 |
設計・開発の活動とその実行責任を明確にした計画書を作成すること |
→ 開発体制表 |
| 設計および開発の活動は、有資格者に割り当てること |
→ 開発体制表 |
| 計画書は、設計の進展の応じて更新すること |
開発体制表、スケジュール表、作業スタック を更新する |
| 4.4.3 組織上および技術上のインターフェイス |
異なったグループが設計を行う場合、インターフェイスを明確にし、
情報は文章で伝達し、定期的に確認すること |
開発体制表 で連絡先を確認し、設計でインターフェイスを明確にし、
各種文章をレビューや配布などして伝達する |
| 4.4.4 設計へのインプット |
設計にインプットする要求事項は、文章化し、
その選択の適切性を確認すること |
要求履歴、レビュー記録 で文章化し レビューで確認する |
| 不完全な要求事項は責任者間で解決すること |
要求履歴、レビュー記録、基本仕様書（要求定義）を元に責任者が行う |
| 設計へのインプットには、契約内容の確認の結果を考慮に入れること |
要求履歴、レビュー記録 と 基本仕様書（要求定義） に
矛盾が無いかレビューする |
| 4.4.5 設計からのアウトプット |
設計からのアウトプットは文章化し、
検証および妥当性確認ができる表現とすること |
基本仕様書とリンクしたプログラム（詳細仕様）と
試験仕様書兼報告書で妥当性確認をする |
| 設計インプットの要求事項を満たしていること |
要求履歴、レビュー記録 と 基本仕様書、試験仕様書兼報告書、
評価報告書を比較する |
| 合否判定基準を含むか引用していること |
レビュー完了判定 |
| 重要な設計上の特性を明確にしていること |
評価報告書の構成を工夫する。基本仕様書の制限事項を記述する |
| 設計アウトプット文章は、発行前に確認すること |
文章管理の発行手順に従う |
| 4.4.6 デザイン・レビュー |
設計結果の文章に基づく審査を計画し、実施すること |
レビューをスケジュールに記述し、実施する |
| 参加メンバーには、全ての部門の代表者だけでなく、
必要に応じて他の専門家も含めること |
→レビューの召集 |
| 設計審査の記録は維持すること |
→レビュー記録 |
| 4.4.7 設計検証 |
設計アウトプットが設計インプットの要求事項を満たしていることを
確実にするための検証を行うこと |
レビューと試験を行う（単体試験、結合試験） |
| 設計検証の手段は記録すること |
テストプログラムを設計検証の手段の記録とする |
| 4.4.8 設計の妥当性確認 |
製品が使用者のニーズ・要求事項に適合していることを確実にするため、
設計の妥当性確認を行うこと |
テストプログラムの結果を試験仕様書兼報告書に記録しておいて、
出荷モードのレビューで妥当性確認を行う |
| 4.4.9 設計変更 |
全ての設計変更は、明確にし、文章化し、確認し、
実施前に有権限者が承認すること |
→仕様変更 |
4.5 文章およびデータの管理
| 項番 |
要求事項 |
対処方法 |
| 4.5.1 一般 |
この企画の要求事項に関連する全ての文章およびデータ
（外部からの文章を含む）を管理する手順を文章化し、維持すること |
本書に相当 |
| 4.5.2 文章およびデータの承認および発行 |
文章は、有権限者が適切性を確認し、承認すること |
各書類に承認欄を作って承認する（→文章管理） |
| 文章の最新版を明確にする管理手順を定め、
旧版文章の誤試用を防ぐこと |
基本的に文章はオンラインで発行し、タイムスタンプで判断する（→文章管理） |
| 適切な文章の適切な版が使用できるようにし、
旧版は使用部門から撤去するか、適切に識別されていること |
すべての文章にはバージョン番号をつける。
バージョンフィックスを行ったら関係者に配布する。（→文章管理） |
| 4.5.3 文章及びデータの変更 |
文章の変更は、別途指示が無い限り、最初に確認及び承認を行った
同一の機能・組織が確認し承認すること |
→設計 |
| 指定された機能・組織は、確認及び承認の根拠となる
裏づけ情報を利用できること |
→文章管理 |
| 可能な場合には、変更の性質を明確にすること |
→基本仕様書の履歴 |
written by Masanori Toda from Mar.2.1999