ア	コードの実際の付番は、コードの処理方法に詳しいシステム設計担当者が行うべきである。
イ	コードの属性とけた数は、コンピュータの内部処理効率に重点を置いて設計すべきである。
ウ	コードの入力ミスが業務に重大な影響を及ぼすと判断されるときは、検査文字(チェックディジットなど)を採用すべきである。
エ	コードの保守方法(追加、廃止、変更など)については、運用テストの段階で決めるべきである。

ア	下位のモジュールから上位のモジュールへと、順次結合してテストする。
イ	上位のモジュールから下位のモジュールへと、順次結合してテストする。
ウ	モジュールの内部構造に注目して、テストする。
エ	モジュールの内部構造を考慮することなく、仕様書どおりに機能するかどうかをテストする。

ア	解決困難なバグに直面して，その後のテストが進捗していない。
イ	バグが多く摘出され，テスト項目の消化実績が上がらなくなった。
ウ	バグの摘出が止まっており，テストは収束している。
エ	バグの摘出数とテスト項目の消化数が一致し，未解決バグ数が滞っている。

ア	COCOMO の使用には、自社における生産性のデータ収集が不可欠である。
イ	開発要員の技量が異なるので、過去に開発したプログラムの規模は見積りの参考になるが、工数は参考にならない。
ウ	工数の見積りは、作業の進捗管理に有効であるが、ソフトウェアの品質管理には関係しない。
エ	ファンクションポイント法による見積りでは、プログラムステップ数を把握する必要がある。

平成16年度春季問題