ソフトウェア個人開発プロセス手順書

version 0.4

目次


目的

本書は、ソフトウェア開発の実際の作業に則しながら 品質を保証する手順のテンプレートです。
本書は、筆者の開発手順をモデリングしただけであり、 作業を強制するものではないので、代わりになる方法があれば その方法を行っても構いません。
本書は、2001 年に ISO 9001 の 『4.4 設計管理』 『4.5 文章およびデータの管理』 に対応する品質システムとして適合することを目標としています。

本書で向上する品質とは具体的に、次のことです。

参考文献

品質システム構築の手引き
飯塚悦功監修 ソフトウェア ISO 9000 シリーズ研究会編集
ISBN4-8171-6070-5 日科技連 ¥2000

プロセスの順番について、サンプルについて

場合によってはプロセスの順番を変えたほうが 効率がいい場合がありますし、 各自の判断で順番を変えたところで 品質が下がることはまずないと考えています。 ですので、本書で書かれているすべてのプロセスの順番は、 一般的な手順を示しているだけで、厳密に従う必要はありません。 従う必要があるのは、出力(各文章、項目、プログラムなど)を そろえることです。

本書に書かれているサンプルの書式は、必要事項を踏まえたサンプルであり、 必ずしも同じ体裁である必要はありません。


開発手順

開発は、次の手続きを繰り返して進んでいきます(スパイラル開発)。 1周の構成として、計画、作成、試験の終了に順番があるだけで、 実際は開始の時点から、計画、作成、試験が同時に平行して行われます。 ただし、各フェーズで作成する内容は明確に決めています (見積もり作成、入出力設計イベント設計など)。 特にフィードバックを得るために1周目を小さくすることを プロトタイピングと呼びます。 開発規模が小さいために、1周で済む場合は、試験終了後すぐに 出荷モードに入ります。 1周ごとに明確なマイルストーンを設けます。 現バージョンの開発規模が小さいために、各種書類を1枚にまとめたり、 レビューを一度に行うことは構いません。

  1. 計画
  2. 作成
  3. 試験

上のスパイラルとは独立して以下の手順を行います。


文章管理

オンライン文章(HTML)は、文章名(またはファイル名)と更新日付で 文章を識別します。プロジェクトに特有でない一般的な文章は、 特定のフォルダ(サブフォルダ)にマスターとしてまとめます。 通常、そのマスターへリンクを張るようにしておきます。
バージョン番号は文章のどこか、またはファイル名に必ず記述します。
ペーパー文章は、一般的な台帳と文章番号による管理をします。

承認欄(査閲覧)は文章のどこかに必ず記述します。
承認者(責任者)が承認の根拠となる裏づけ情報を利用できるように 文章には参考文献や設計の根拠などを記述します。

自分以外が作成したオンライン文章は、 チームで共有するハードディスクに入れて管理しておきます。
バックアップもとっておきます。
フォルダの構成は自由としますが、なるべく深くならないようにします。
ペーパー文章に直接メモを書くとバージョンが 上がったときに消えてしまうので、別紙のメモに書くようにします。
常に最新版のみを参照するようにします。
ペーパー文章とオンライン文章の好みが分かれるので、 なるべく両方をもらうようにします。 (コストや秘密保持の場合を除く)

発行手順(バージョン固定)

社外に提出するとき、社内レビューを行ったとき、 長い間更新を通知していなかったときに通知したときなど、 自分以外の人に文章が渡ったときにバージョンを固定します。 バージョンを固定の手続きは以下のようにします。

  1. リンクしている文章はコピーを作成して、 1つのフォルダ(ディスク)に全ての文章が入っているようにする
  2. 文章の内容を確認する。必要ならレビューを開催する
  3. バージョンを固定する(承認する、発行する)

非公式的な公開のときは、バージョンに「作成中」が わかるように記述します。


承認

承認は責任者が確認したことを示すことです。

責任者が確認したことを証明するレベルを次のようにします。

通常の文章に記述するのは、Level 1 の証明で十分です。
ただし、重要なミーティングでは Level 1 では不十分なので、 レベルの高い証明も一緒に提示します。そのために、 レベルの高い証明をマスターとして保管しておきます。

プロジェクトにより、通常の文章に記述するものと、マスターとして 保管しておくもののレベルを決めておきます。 (通常は、Level 1 と Level 3 にします)。


計画書開発管理帳品質記録

開発体制表スケジュール表作業スタック要求履歴作業履歴、 数値データを開発管理帳計画書品質記録)にまとめます。 文章がかなり流動的であるため、オンライン文章として作成します。

開発管理帳は、基本的にプロダクト(製品)に含めません。

- 記述項目 -

1.はじめに

2.プロジェクト名

3.開発体制表

4.スケジュール表&数値データ

5.作業スタック

6.要求履歴


開発体制表

開発者(有資格者、適切な担当者)と責任者(管理職)を明示する。
顧客(依頼元、製品発注元)やサポートグループなどのも明示する。 過去の開発者や助言をいただける人も明示する。

それらの連絡先も明示する。
社名、部署、担当者名、電話番号、e-mailアドレス。

責任者を明確にしておくことで、助言や対処などが得られるようにする。 そのために、連絡先が重要。 開発者が変更になった場合は、過去の開発者として残しておく。


スケジュール表

締め切り(目標日)やイベントのように日付か決まるものは、 スケジュール表としてまとめる。
自分のスケジュールと対外スケジュールを分けるとよい。
スケジュールは、あまり厳密にすると、そのときの優先順位が 反映されなくなるのでほどほどに。

レビュー等、開発手順をスケジュールに入れる。 ただし、開発初期では、日付を厳密に決めなくてよいが、 数日前には日時を厳密に決めておき、レビューの開催場所や 受け渡し場所を確保しておく。

スケジュールは、定期的に更新します。その際、バージョン管理をします。
開発が遅れている場合は、被害が大きくなる前に早めに顧客に通知します。 済んだスケジュールは、スケジュール表を更新しても記述します。

スケジュールをバージョン管理することで、是正処置の資料になります。


作業スタック

作業できる時間も永久にあるわけではないので、 優先順位順に作業項目を並べた作業スタックを利用します。
一日の作業内容を計画するときに見ます。

作業スタックにも数値データを使用することができます。
優先順位[高],[中]の残り作業時間も添えます(単位は week)。

実行が正式でないものは、優先順位[低]に入れる。

作業スタックに作業を入れる際、締め切りが決まっているものは、 スケージュールにも記述する。
懸念事項作業スタックに入れる。(調査のため)
作業スタックは、プロジェクトごとに分けるとよい。 特にバグリストは分けるとよい。(バグリストは公開することが多いため)
作業スタックの項目には時効を作ってもよい。


要求履歴

[サンプル]

自分以外から要求があったら、要求内容をリストに日付順で追加します。

要求履歴は、要求があったことを忘れないため、 要求があったことを確認するためにとります。 作業スタックでも確認が取れますが、 日付で整理されているほうが確認を取りやすいためです。

記述項目は次の通り。

優先順位は以下のようにランク付けする

レビューやミーティングがあったとき、 リストにレビューが開催されたことを要求内容の項目に記述して、 その資料にリンクできるようにしておきます。 (そのとき、要求者は[-]、優先順位は、最も高い優先順位か[簡]、 状況欄は n/m 分数表示で、すべて完了したら [完了] にします。)

完了と未完がすぐ分かるように、状況欄に未完マーク(■) を付けるとよいでしょう。


数値データ

進捗状況の大体の把握のために数値データを用いる。 (その際、Knowledge Take! アプリケーションのカウント機能を使用するとよい。)
ただし、以下に述べる方法は、明確に定義され、一般的に使われている ものではないが、筆者の経験上、進捗状況の把握には妥当であると判断している。

まだ1つも手をつけていない場合、「仕様作成中」と記述します。
それぞれ、機能、関数、試験項目の数を記述します。 状況欄に見積もりを記述しているなら、機能、関数、試験項目の見積もり時間の合計を記述します。
進捗状況のパーセントは、完了数:x1, 試験の一部完了数:x0.8, 機能/関数の一部完了数:x0.5、バグ数:x0.5 の重みを付けます。
網羅度は、以下の記号を用います。

ただし、カバレッジ・ツールがある場合、そのデータも記述します。

作業スタックの消化状況は、作業項目の残り数を 優先順位別に記述します。優先順位[高]と[中]が完了することを目標にします。

バージョンフィックスしたときは、進捗状況を記録しておきます。 新バージョンでも同じ試験仕様書兼報告書を使う(更新する)ので 進捗状況を計るときに必要になるためです。


基本仕様書の記述項目

[サンプル]

1.はじめに

2.適用範囲

3.目的、要求定義

4.全体の構成

5.使い方

6.機能説明

7.関数の説明

8.構造体の説明

9.補足、解説

履歴


試験仕様書兼報告書の記述項目

[サンプル]

1.はじめに

2.適用範囲

3.試験対象、目的

4.試験環境

5.試験終了条件

6.試験手順

7.試験項目

試験報告書の記述項目

試験報告書は、他人が作成した仕様の試験や デグレードしていないかの試験など、試験仕様を流用する場合に 試験を行ったことを示す書類です。
手動テストを行う前に、手動テストの報告の章を参考にして チェックリストを作成しておきます。
1.はじめに

2.適用範囲

3.手動テストの報告(あれば)

4.自動テストの報告(あれば)


作業履歴

主にバグの対処について。 信頼性の参考資料となる。 仕様の変更については、仕様書の履歴に記述する。


評価報告書

性能向上の記録

重要な設計上の特性がすぐに分かるように構成を工夫する。


分析 〜 現状の理解と目的と対応の分析


見積もり作成

output ... 計画書(優先順位)

要求内容をある程度まで明確にしてから、見積もりに入ります。

公式な要求定義の手順

  1. 企画立案準備
  2. レビューを行う

バージョンアップ時の公式な要求定義の手順

  1. 企画立案準備
  2. レビューを行う

非公式な要求定義の手順

  1. メールやペーパーで要求内容の具体的な内容を聞く
  2. そのメールやペーパーを要求履歴に追加する
  3. レビューのときに、それまでの要求履歴を確認してもらう

見積もり

期間見積もりは、担当者が判断した週数を扱います。
1〜3週程度に分解した機能に対して見積もりを行い、 それらの期間を合計したものを全体の見積もりとすると精度がよくなります。
1〜2週間程度の誤差であれば認められることが多いので週数を扱う。
開発期間を見積もるときは、LOC に変換しない。

見積もりは、ここ3個月

見積もりの考慮事項

品質がよいものを要求しているかどうかをヒアリングしておいて、 見積もりに反映させます。
顧客満足度を基準に要求を定義しますが、 実際の作業は自分の学習などが反映されるものなので 自己満足度を満たす作業も見積もっておきます。

見積もりのフィードバック

過去の見積もりと、実際にかかった時間を比較して 次回の見積もりにフィードバックします。 何度も見積もっていると、見積もりが短いことが多いことに気づくと思います。 そのため、見積もった値にある程度の倍率をかけて、増えた期間を 予備期間にしておくとよいでしょう。

モジュール分担の分析


基本仕様作成

output ... 基本仕様書

[ 第1シス技・標準]

基本仕様書は、機能概要と、インターフェイスを 定義するのが目的です。 そのためには、アルゴリズム(詳細設計)や、 TP のラフ・コーディングなどを行うとよいでしょう。

基本仕様書が完成するのは、プログラムが完成するときと同じです。 しかし、それではいつプログラミングを始めたらいいか分からないので、 仕様書完成レベルの基準を示して、それに対するアクションも示します。

表.仕様書完成レベル
Level状態アクション
1 2.適用範囲、3.目的、要求定義、4.全体の構成 が完成し、 6.機能説明、7.関数の説明 の概要が完成した 機能優先順位レビューを行う
2 すべての項目を一通り完成した インターフェイス・レビューを行って コーディングを開始する
3 コーディングして仕様の変更が少なくなった 仮完成


仕様変更

大きなスケジュールの遅れや実現不可能などの理由により、 仕様を変更したり仕様から削除する場合、次の手順を踏む。

  1. 変更内容の具体化、変更後の文章を作成(修正ではない)
  2. 要求履歴やレビュー記録の状況欄に 「変更予定」または「見送り予定」と記述する
  3. 責任者や顧客に報告する。重大な変更の場合は承認をもらう。
  4. 変更前の文章をどこかにまとめておき、変更後の文章に入れかえる
  5. 仕様書の履歴を記述する
  6. 要求履歴やレビュー記録の状況欄に「変更」または「見送り」と記述する

設計 〜 各担当による機能実現の手段

設計変更は、すべて仕様書の履歴に記録するが、 工数がかかる大きな変更のみ、実施前に有権限者に報告する。 前回の承認者と変わった場合、前回の承認者にも報告する。

ソフトウェアは、データを操作することなので、 データとプロセスを明確にすること。 あとは、規模(構造ツリーの位置)の問題のみ。

参考文献

オブジェクト指向方法序説 基盤編
J.Martin, J.Odell 著
ISBN4-8101-8592-3 トッパン ¥5800

前回の承認者にも報告するのは、顧客に不当な変更が無かったことを 示すためらしい。


入出力設計

何かを出力する(データを参照される)ために各モジュールが 存在しているものと考えて、あとで修正が生じにくくなるように、 必要な入力データを洗い出してインターフェイスを定義する 方法を示します。

1.出力属性の洗い出し 〜 システム全体から考える

ユーザや他のモジュールが必要とするデータを出力属性として 列挙します。ただし、出力属性は、適切なモジュールクラス)に 割り当てるようにします。

2.入出力ツリーの作成 〜 各モジュールごとに考える

出力属性を計算するのに必要なデータを入力属性として ツリー状に列挙します。入力属性が、モジュール内部の 出力属性か、モジュール外部の出力属性かに関わらず列挙します。 入力属性が重なった場合(コモン・オブジェクト)は、 ツリーのノード間でリンクします (リンク先は属性よりオブジェクトのほうが良い)。 入力属性として、次のような視点があります。 (チェックリストとして使用できます)

3.データ・インターフェイスの定義

(2.)で作成した入出力ツリーのうち、 自分のモジュールクラス)の属性には☆印をつけます。 他のモジュールから参照する属性には★印をつけます。

★印を付けた属性は、適切なオブジェクト属性状態になるように グループ分けしてデータ・インターフェイスを定義します。

4.入出力ツリーの更新要求

外部/内部インターフェイスが決まったら、その担当する モジュールの出力属性に追加してもらうように要求します。 追加した属性に対して必要な入力属性が新たに洗い出す 必要があるので 2. に戻ります。

5.実装

入出力ツリーができたら、ソースコードにします。 数値や文字列といった単純なデータでなければ、クラスにします。 ツリーのリーフ(末端)のデータは、メンバ変数にします。 ツリーのノード(非末端)のデータは、メンバ関数にします。 ただし、コモン・オブジェクトより下のデータは、 メンバ変数とメンバ関数の両方にします。 複数になるデータは、コンテナにします。その際、 システムによっては記憶領域の管理が必要になります。


イベント設計

設計しようとしているオブジェクトがどのように操作されるかを、 考えられる多くのプロセスで考え、汎用的になるようにします。 どのようなプロセスであれ、設計しようとしている オブジェクト操作のされ方(ライフサイクル)は、 以下のような流れになります。
生成→入力→出力→変更→出力→後始末→開放
上の流れのうち、どこに区切りを置いて関数とするかを決めるのが イベント設計です。

関数インターフェイスの作成の基準はタイミングです。
オブジェクトに対する入力または出力の属性の組み合わせが関連深く、 ケースによって変化しないタイミングで、 関数インターフェイスを作成します。 また、他のオブジェクト属性を入力している場合、 その属性が変化したときをイベント発生とし、 そのタイミングで関数インターフェイスを作成します。

イベント設計したら、設計したオブジェクトを使用するオブジェクトに、 設計に合わせるように要求します。 なるべく変更を生じなくするには、インターフェイスを 合わせるためのクラスを間にはさむとよいでしょう。

簡単なオブジェクトイベント設計

入力属性が多いオブジェクトイベント設計

出力属性が多いオブジェクトイベント設計

入力オブジェクトの構成が変えにくい場合のイベント設計


詳細仕様作成(プログラミング)

ソースファイルのテンプレート(テキストファイル)

プログラムコードを、詳細仕様書となるように可動性のあるコードを記述します。 C 言語のコードは「オブジェクト記述法 COOL」に従うことで、 オブジェクト指向の恩恵を受けられるようにします。
開発が制御不能にならないように、 以下の同期安定化プロセスを一通り実行するまで 別の作業をなるべくしないようにします。

  1. 作業スタックの確認
  2. リビルドする
  3. 動作を確認する(メインとなるソースを参照しながら)
  4. バックアップを取る
  5. 旧版と新版を #if で分ける
  6. 旧版をビルド&クイックテストする
  7. 新版を作成する
  8. 設定ミスがあったとき、アサートされるようにする
  9. 手動テストを記録する
  10. ドキュメントを更新する
  11. 作業履歴に追加、または仕様書の履歴に追加する

詳細仕様の検討は、関連するプロセス(関数)やデータ(変数)の 仕様を確認しながら行うので、関連するコードを頻繁に参照することに なります。そのコストを減らすための1つの方法として、 Knowledge Take! アプリケーションを使用します。

モジュールの再利用を促進するために、Module Mixer アプリケーションを使用します。 正しいバージョンの設定、依存するモジュールのリンク、 ファイル・ディレクトリの調整、 必要なヘッダファイルのインクルード、 メイクファイルの作成など、再利用する際にかかる作業を 自動化することにより工数を削減します。


試験仕様作成試験方針

output ... 試験仕様書兼報告書試験報告書

手順は、テストプログラム作成を参照

プログラミング(詳細仕様作成)の段階で、試験仕様書兼報告書の 記述を開始し、動作確認程度の初期の試験 を同時に行います。 (基本動作の正常試験を動作確認と呼びます)。 試験の進捗状況は、数値データを使用します。 試験仕様書の記述範囲は、妥当性確認事項と 試験結果報告まで含みます。

初期テストケース考案のヒント

詳細テストケース考案のヒント

試験終了条件

用語説明

参考文献

ソフトウェア・テストの技法
Glenford J. Myers 著
ISBN4-7649-0059-9 近代科学社 ¥2700

  • 内部モジュール(ハード)の試験は、対象となる試験仕様書には 記述しなくても構わない理由は、内部がどうであれ外部から見たときに 仕様を満たせばよいからです。
  • 試験用の数値がソースコードにのみ書かれることを許可した理由は、 テストケースの仕様書にテストプログラムの関数名が書かれており、 仕様書からたどることができるためです。
  • テストの結果の値をすぐ確かめられるようにする理由は、 データ見せて顧客を納得させるためです。


テストプログラム作成

output ... 試験仕様書兼報告書試験報告書

テストプログラムのテンプレート(テキストファイル)

試験項目ごとのプロセス

以下は、テストプログラムがまだ作成されていないときのプロセスです。

  1. テストケースの確認
  2. テストプログラムのコーディング
  3. コンパイル
  4. テスト実施、手動チェック
  5. デバッグ
  6. バグの記録を作業履歴
  7. 試験報告書状況欄を更新

チェック方法

テストプログラムのコツ


状況欄

状況欄は、各文章中に含まれる要求項目や試験項目の状況を示す欄です。
この欄を活用するためには、オンライン文章の特徴である修正が容易である ことが条件になります。

未完了時, 見送り時の記述

状況欄には、現状(バグ状況など)を把握するためのメモと、 完了するまでの見積もりを記述します。

見積もりは、「見積もり=2hours」のように記述します。
見積もりを予想できない場合は、「見積もり不能」にします。
現バージョンで作業する工数が避けない場合は、「見送り」と記述します。
納期までにバグが取れないと予想される場合は、「仕様化」と記述します。

基本仕様作成が完了していない機能の詳細設計など、 後工程の項目が未確定の場合、後工程を含めた見積もりを行います。
詳細設計が完了していない関数の試験項目など、前工程が残っている場合、 設計に付いては設計状況欄試験については試験状況欄のように、 前工程と別々に見積もりを行います。

完了時の記述

記述する内容は次の通り

テストした人が一人だったり、試験項目の大項目ごとに明確に分かれている場合は、 そのことを本章のどこかに記述し、状況の欄に試験者を記述しなくても構いません。
テストが済んだ日付がすべて同じだったり、試験項目の大項目ごとに明確に分かれている場合は、 そのことを本章のどこかに記述し、状況の欄に日付を記述しなくても構いません。
以上から、最も簡単な完了を示す記述は、次のようになります。


出荷モード

内部α版リリース

  1. コンパイラ動作確認(リビルド)
  2. 実行ファイルの動作確認
  3. バージョン・フィックス
  4. 出荷準備(ファイル構成の整理)
  5. バックアップ

外部β版リリース

  1. 自動テスト
  2. バージョン・フィックス
  3. 出荷準備
  4. バックアップ

外部正式版リリース

  1. 仕様固定
  2. 手動テスト&中期デバッグ
  3. レビュー記録のレビュー(インベントリ)
  4. 出荷準備
  5. 最終テスト
  6. バックアップ


予防

バグを早期に発見できるように予防をしておくことで、 強固なアプリケーションを作成します。

コメントによりケアレスミスを予防する

関数の機能や引数の説明をコメントにすること、 わかりやすい関数名や数式を書いて、 ケアレスミスの出にくいように作成します。

ASSERT トラップをしかけておく

処理の事前条件、事後条件に対応する ASSERT トラップを できるだけ多く記述します。 また、未対応の部分にも警告が表示されるようにしておきます。

コンパイラを活用する

コンパイラのワーニングレベルをあらかじめ高くしておきます。 プロトタイプ宣言をしておきます。 掛け算など通常の式を書いても最適化がかかるのに、 シフト演算など読みにくいコードを書かない。


デバッグ

デバッグの作業は、以下のように法則化することができます。
その際に必要となるツールを Errors モジュールにまとめています。

  1. エラーを発生させ、再現性を確認する
    エラーであることを無視してプログラムが実行されないように、 プログラムがエラーであることを示す動作(エラー関数を呼び出すなど) を行わせる。また、エラーの再現性を持った条件を 容易に再現できるような特別な main 関数を用意する (後に、テストプログラムとして流用する)。 ハードの完全なリセットとソフトの再構築(リビルド)を行って 再現性があるか確認する。

  2. 正常な値と異常な値の違いを認識し、エラーが発生する条件を洗練する
    エラーが発生する最小限のデータ構成を作る。 プロセッサが通ったことを示すダミーデータをつけて調べる。 必要なら、別ケースで正常に動くデータのすべてとツールで比較する。 仕様やプログラムを確認し、データ構成自体が正当なものか検討する。 時系列(タイミング)にも注意する。 データの値とデータの格納場所(アドレス)に注意する。

  3. エラーの原因となるコードの位置を突き止める
    まず、初期化を疑う。 それから正常な値が伝播しているコード位置と、異常な値が伝播して いるコード位置を見ながら、2分検索アルゴリズムのように、 原因を特定していく。前回動いていた部分から追加した 部分をカットしたり、修正した部分を戻したりする。 似た出力データに対して通っているコードを区別するために 片方のコードのデータに目印をつける。 値を変化させているものを疑う。 疑っているものが合っていると仮定して推理する。 場合によってはサブモジュールの単体テストを作成する。

  4. エラーの原因に近い個所でエラーが発生するようにする
    今後同じ原因でエラーが起きたときに、同じ原因追求を行う必要が 無くなるように、原因に近いところで ASSERT します。

  5. 修正と再確認と記録
    バグを修正する。 修正したら、もう一度テストする。 今回発生したバグをテストケースに追加した後、 従来合格したテストをもう一度行う。 この再テストの工数を減らすためにテストプログラムやテストデータを 蓄積していく。 再びミスしないような仕組みを検討する。 バグの記録を作業履歴へ。

マルチタスク、マルチプロセッサ環境のデバッグ

マルチタスク、マルチプロセッサ環境では、 関数を追跡してもタイミング(他のプロセス)によって動作が異なってくるので、 上記の方法で発見することができないことがあります。
ウェイトをかけたときのみ動作する場合、 他のプロセスの動作が完了する前に次の要求を出していたり、 動作をキャンセルする要求を出している可能性があります。 ビジー状態を確認しているかチェックしたり、 次の要求を出すまでのプログラムの一部をカットしてみてください。


レビュー

output ... レビュー記録(要求定義)

レビューは開発手順のマイルストーンごと、または 定期的(約2ヶ月間隔)に開催する。

  1. 準備
  2. レビュー実施
  3. レビュー後
  4. 計画書の変更(?)


コーディング・レビュー

レビューを参照)
簡単な、関数コールツリー、構造体ツリーを用意する。


レビュー記録

記述の仕方

レビュー直後の査閲基準

指摘事項の完了基準


進捗報告

誰にでも分かる概要を示す。
詳細にたどりつけるようにリンク(文章、人)を張っておく。

  1. プロジェクト一覧
  2. 実績
  3. 問題点
  4. 予定


ISO-9001 の要求事項との対応

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