Comments
Transcript
富士通のソフトウェア品質保証活動 - A Lifelong Software Tester (生涯
富士通のソフトウェア品質保証活動 事例3 特別企画［ソフトウェアの品質保証］ 吉田 征 検査 部長 辰巳敬三 第三試験課 ［→ エ動 . . . � ....ヽ’さ� � [ V E 図1 ” � 第三試験課長 動l m F 渡辺真吉 )逼 ー 2 富士通棘ソフトウェア開発本部ソフトウェア事業部検査部 推 進 運 動］ 品質保証体制 開 1. はじめに 本稿では， 富土通におけるソフトウェアの品質 保証活動について述べる。 生 産活動が高度 化していく過程は Plan →Do → Check→Action という管理のサイクルの回転と してとらえることができる。当社においては， こ の管理のサイクルに対応した以下の4つの基本概 念に沿ってソフトウェア開発に取り組んでいる。 O 源流での管理 (Plan) 0 0 目標による管理 (Do) 以降では， この考え方に基づくソフトウェア品 質保証活動の実際を，当社汎用コンピュ ー ク（主 にM シリ ー ズ）の甚本ソフトウェア開発部門（以 降当開発本部と呼ぶ）の活動を通じて示すこと にする。 2. 'ノフトウェアの品質保証体制 図1に示すのは当開発本部の体制てある。ソフ トウェアのライフサイクルに対応した開発ライン の部門と，これらを支援するスクッフ部門が置か れた組織に対して， 統括会議· 委員会からトップ ダウンの指示・目標が提示され，従業員個々が参 ソフトウェア開発の各段階における目標値を 加する各種運動がポトムアップの形で支援すると 設定し，その目標の達成を推進する。 デ ー タに基づく管理 (Check) いう体制としている。 統括会議は，製品企画や開発計画を審議する 具体的事実やデ ー クに甚づいた判断が品質管 「企画会議」，工程進捗上の問題を審議する 「エ 理の基本であり， ソフトウェア開発過程で得 程会議」， 品質状況を監視する「品質会議」の3 つからなっており， これらの会議を開発本部全体 られる情報をできるだけ目に見える品質デ ー タとして把握し分析する。 o POCA の回転 (Action) 標準化と品質管理 Vol 41 1988 2 生産物 品質の基本は初期工程で決まるものであり， 開発計画／開発 目標というソ フトウェア 開発 の源流からの管理を重視する。 PDCA を回転させ，より根本的な原因にさ かの阿った再発防止策を追求する。 29 •詳細設計書 ・レピュ ー 報告書 •試験仕様書’成績書 ・機能設計書 •構成設計書 •試験計画書 図2 •試験仕様書 •試験成績瞥 • テストセット ヽ ・検査成績書 ソフトウェアの開発工程 の目標の設定と評価，開発技術の普及・定惜など の開発プロセスを目に見えるようにしていくこと の具体的な活動は，各部門の代表者から構成され る委員会を中心として推進している。 が大切である。当開発本部においてはソフトウェ 3. の PDCA 回転の軸と位置付けている。さらに， 統括会議で提起された問題の解決，・開発本部全体 •鯛査報告書 • 基本設計書 ソフトウェアの開発工程 ソフトウェアの開発を進めるにあたっては， そ 30 ア開発工程を図2のように定義し，各工程ごとに 作業や生産物を規定している。また，マニュアル については， それ自体が重要なソフトウェアであ り，プログラムの開発工程とは別にマニュアル作 標準化と品質管理 Vol 41 1988 2 表1 品質目標 実 施 計 画 ＿ ‘ �し ドキュメンテー ション ツ ール （マニュアル推考 ・ 査読ツ ー ル ． 開発ドキュメント作成ツ ー ル） プログラム管理ツ ー ル（履歴管理· 構成管理ツ ー ル） [ j} 自動テストツ ー ル エラ ー管理ツ ー ル エラ ー解析ツ ール 提供管理ツ ー ル 開発計画書の記載項目 プログラムの位置付け ， 開発効果， 市湯性などの妥当性 ユ ー ザ要望の吸収状況 ， 機能の過不足 目標値 ， 比較対象， 測定時期 ， 測定方法の妥当性 前製品との互換方針の妥当造互換対象 ， 互換項目の妥当性 目標値および根拠の妥当性， 実施計画から見た実現可能性 機能と比較した規模の妥当造部品化／再利用計画 ユ ー ザ提供時期の妥当性， 実現可能性 生産性， 予算との一致性， エ数配分の的確さ ， 外注率， クロ ー ズ化率 レピュー 量 ， テスト量パグ検出数の妥当性 （工程別標準との比較） 品質向上／開発効率化のための重点実施項目の十分性 用いる開発技術・作業標準の妥当性 当面の組織， 作業分j且 ， その後の展開方針 開発目的 実現すべき機能 性能目標 互換性 信頼性 開発規模・言語 開発工程 所要工数・計算機時間 レピュー ・ テスト実施計画 作業方針 開発技術・作業標準 開発体制 管理部門は，それぞれの立場からこの開発計 定する。 また，後続する設計· プログラミング・試験の プロジェクト管理技術 （工程管理ツ ー ル ・ 品質分析ツ ー ル） 各工程完了時には「エ程完了報告書」として開発 教 計画に対する実績報告が行われ，開発計画書と同 育 様に関連部門の審査を受ける仕組みとしている。 i 人 なお，開発計画書や工程完了報告書に記載され 』 間 9 標準化(SWN) 図3 た情報はデ ー クペ ー ス上に蓄積し，品質基準，生 、 高信頼性運動(QCサ ークル） 産性の見積もり基準の設定などに用いている。 ソフトウェアの開発環境 5.2 品質目標の設定 成工程を定義して作業を明確化している。 5. このソフトウェアの開発工程は． 計画に始ま 品質管理においては、 その管理基準（品質目 品質保証のための基本的活動 標）を設けることが基本である。当開発本部で り， 設計・プログラミング・・試験という実行の段 5.1開発工程の管理 階を経て製品 評価に至るという 1 つの PDCA の サイクルを形成しているが，さらに おのおのの は，この目標を以下の単位で定め． おのおのにつ いて POCA の回転を図っている。表 2 に示すの 工 程 で も POCA が 回転す る よ う に ． 計画． 設 ソフトウェア製品の開発計画は 「品質目標」と 「目標達成のための実施計画」からなっている。 この開発計画において， その目標がユ ー ザの要求 部門がその報告を行う仕組み（後述の開発計画 た製品はユ ー ザに満足を与えることはできない 書／工程完了報告書）を設けている。 し，また，いかにすぐれた目標でも実施計画に不 都合があれば，その目標を達成することはできな い。すなわち，·品質の基本は計画のよしあしすな 計，プログラミング， 試験の各工程完了時に開発 4. ソフトウェアの開発環境 よりも低いものであれば，当然ながらできあがっ ウェア），および人間が身につけるべき開発技術 わち計画品質で決まるといっても過言ではなく， 源流での管理が重要である。「開発計画書制度」 はこの計画品質の評価および向上をねらいとして （人）の3 つであり， この3 つに瘤目して開発環 おり， 次のように運用している。 ソフトウェアの品質保証活動を支えるのは，開 発設備（ハ ー ドウェア）， 支援ツ ー ル（ソフト 境を整備することが必要である。当開発本部で 0 は．「品質の上流工程での作り込み」「機械化（技 術のツ ー ル化）による品質の均 ー化」「機械化を 整備を図っている。図3 に開発環境を示す。 標準化と品質管理 Vol 41 1988 2 0 は開発本部全体の目標として設定しているもので ある。 0 品質目標の例 且標値の：砂ぇ方 目標項目 レピュー 実施量 '' 。設計 ， プログラミングの各工程ごとに ， プログラム規模I K行当たりのレピュ ー最（エ数） を目標値以上とする。 開 発 エラ ー 。プログラミング ， テストの各工程こ•と 検出数 に ， プログラム規模IK行当たりのエ ラ ー検出数を目標値以上とする。 階 マニュアル ，マニュア ル100ペ ー ジ当たりのレピュ 一実施置を目標値以上とする。 c ユ ー ザクレ ー ム数(Iユ ー ザ ． 半年あた 総合品質 り）を基準値以下とする。 信頼性 製 品 出 保 守 後 マニュアル ，製品提供後のプログラムのエラ ー発生 数(10 K行・半年あたり）を基準値以下 とする。 原因判明済エラ ーによるトラブル発生 数を基準値以下とする， 。デグレードの発生件数を基準値以下と する。 。 。不備のために差し替えるページ数を基 準値以下とする， 開発段階の品質デ ー クは開発計画書／工程完了 開発本部単位（半年ごとに見直し） 報告書によって 「生産物の鳳」「所要工数」「計算 開発本部品質目標の設定・評価．目標達成の 機等の演源使用批」「テスト項目数」「検出エラ ー 数」という形で収集されるが，さらに，試験工程 ー ための施策の設定とフォロ O製品単位（エ程ごとに見直し） 以降になると，「ソフトウェア障害レボ ー ト」に 前述の開発計画書，工程完了報告書 ー ル単位（週ご 0 モジュ とに見直し） よりエラ ー の現象や修正情報に加えてエラ ー 分析 工程会議品質管理簿， 品質デ ー タベ ー ス， 高信頼性運動 のための情報が収集される。製品検査では，障害 レボ ー トに加えて，テスト結果や製品評価結果な どの検査実績が品質デークとして収集される。製 品出荷後は， ユー ザから受け付けるクレ ーム，機 能追加などの要求などが品質デー タとしてデ ー ク 開発部門は基本設計が完了した時点で，プロ ジェクトの計画を所定の「開発計画書」にま とめる。開発計 画書の記載項目 を表 1 に示 5.3 品質情報の管理 ソフトウェアの開発プロセスは， 各プロセスに ベ ー スに蓄積される。 一連の開発プロセスの中で 対応した形で定義・収集される品質デ ー タにより これらの品質デ ー タを計測することにより，各プ 関連製品の開発部門， 検査部門，技術部門， クとその流れである。 す。 促進する設備の充実」をねらいとして開発環境の 表2 画を審査する。開発計画はこの審査の後に確 37 計測される。図 4 は当開発本部における品質デ ー 32 ロセス間での比較，前 製品の品質デークとの比較 を可能としている。 標準�化と品質管理 Vol 41 1988 2 ェ孟□ ェ矛孟「 エ矛后戸 二〕 ァスト実績 巴戸実績：出；；実績• • 作業工数 し――j L__」 図6 F=i マニュアル 高信頼性運動の活動モデル 5.5高信頼性運動 (QCサ ー クル） 当社では，QCサ ー クルを，単に品質を管理す るものではなくさらに一歩前進して「信頼性を高 めるもの」という主旨から 「高信頼性運動」と呼 んで，その活動を展開している。 ソフトウェア製品の開発においては，固6に示 障害管•理情報 ・フログラム障害情報 ・マニュアル不備情報 すように開発計画書／工程完了報告書制度と連動 図4 計画 品質データの流れ ブログラミングテスト 設計 した形で高信頼性運動を展開することにより、製 品の品質向上に役立てている。活動に関する基本 製品検査 見積もリハン ［仕様書作成規約][ コーディング規約 ドフック 1 ・［ プログラムの文体 ］ ］ r YPSブログラム作成規約 レピュー、規約I レヒュー技術ハンドプック 添ば訊謬j 1 保守 ， エ程完了報告密 三［ 的な考え方は以下のとおりである。 ー マをグ 0 工程密惰•本務改善•技術開発型テ ー ルー プ活動テ マとする。 0 運動をトレ ー ニング，チャレンジの場と考 l フィ―ルトサホート 作業マニュアル 0 テスト仕様書作成規約 ） 品質保証活動 ここでは， 品質保証活動を支える技術面の取り 組みのいくつかを紹介する。 製 品受け渡し手 続 き 障害レポー ト／要望連絡票手続き 6.1プロジェクト診断 「プロジェクト診断」は， ソフトウェアの開発 計画／工程完了状況を定量的品質デ ー タにより診 技術文書作成基準．ソフトウェア用語集．工程区分規定．外注規定．ハードウェア設備規定 SWN規格の例 5.4標準化 標準化とはそのときの最高の技術を全体に適 用 ， 普及， 定隋させることであるという認識の 元，「設計仕様の統一」「技術の蓄積 ・伝達」「管 理の容易化・手続きの円滑化」を目的として， 各種 の 技 術 標 準／作 業 標 準 を SWN(Software Nor標準化と品質管理 Vol 41 1988 2 テ ー マに展開し，開発完了時に総合評価す る。 6.'ノフトウェア生産現場における [マニュア）頃成技術（執筆編） Jしマニ→戸り立旦臼[ 図5 え，結果だけでなく目標 ，過程も評価する。 重点目標（トップダウンの目標提示）を個々の men)規格として定めている。主なSWN規格を 図 5 に示す。なお ， 標準そのものは， 開発環境の 変化に応じて柔軟に対応していくべきものである ため，SWN委員会を中心に定期的な見直しを行 ハ標準化の維持・推進を図っている。 33 断し，早期に問題点を検出することを目的として いる。前述した開発計画書／工程完了報告書制度 の運用を通じて多数のプロジェクトの開発実績デ ー タが蓄積されているが ， これらのデ ー クにはあ る程度標準的な値が存在している。プロジェクト 診断は 個々の評価項目に対して標準値と計画 値 （あるいは実績値） との離れ具合を 「悪い」「や 34 や良い」「良い」の3段階で評点付けした後，各 評価項目に重み付けして算出した総合点により 行っている。図7は自動的に出力される診断票の 例である。診断結果の悪いものは，そのプロジェ クトに問題がある可能性が高いことから，定性的 な分析を行い， 必要な処騰をとるように検査部門 から開発部門へ勧告を行っている。 7 つの設計原理 設計およびレビュ ー の段階では， エ ラ ー を作り 込まないための 7 つの設計原理（表 3) を指針と して掲げ，技術の普及 ・ 定瘤を図っている。開発 技術の追求においては エ ラ ー の統計的分析は必ず しも妥当ではなく， エ ラー の作り込みの過程をつ ぶさに分析することが エ ラ ー 予防の技術の発見に つながっていく。これら 7 つの原理は，このよう な問題意識から， エ ラー の1件1件を対象に 0 それらを作り込んだ過程，そしてそれらを作 6. 2 り込んだ開発者の思考過程を分祈する。 その分析の中から ， 同じ過ちを 2 度と犯さ ず，かつ，人間の能力に過大な期待を抱くこと のない設計・プログラミング技術を追求す る。 という分析（エ ラ ー の深層的分析） を行い， そこ から普遍的な原理として得た現場の知恵である。 0 6.3ソフトウェア開発履歴分析 プログラミング（コ ー ディング） 工程以降の段 階に入ると， 実際のソー スモジュ ー ルに基づいて 開発状況を把握するのが 実際的である。ソフト ウェア開発履歴 分析( ASDGEM)は， ソ ー スモ ジュ ー ル管理ツ ー ル(OEM)が自動的に記録する ソ ー スモジュ ー ル更新履歴デ ー タ（「更新日」「更 標準化と品質管理 Vol 41 1988 2 ソフトウェアの品質保証［特麗釜肩 ］ プロジェク 開計No. K1196 卜診断票 サプシステム XX X エディション EIO 報告工程 開発完 プログラム yy y 評価日 87 .06.29 パー ジョン ＇，、'心... ,..' 納 期 単 純 原理 同型原理 I 対 称原理 I①工程遅延 階 層原理 資I②クロー ズ化率 源 使I③計算機使用時間の 性 線 型原理 率I④計算機時間の見積り楕度 明証原理 用 叫®生産性（標準値との比較） 産 安 全原理 性 1 ⑥生産性（計画値との比較） ⑦設計書(FD+SD)レピュ ー の十分性 の 出 ⑨ ‘ノ ースレピュ ーの十分性（エ ;. .'./•:が 意｀ ；味へ:}心 高級なテクニックを使わず ． 単純に素人っ ぽくプログラミングするということ。 同じことは同じようにや ることにこだわり ． 例外は 設けないようにすること。 上があれば下 ． 右があれば左 ， アクティプ があればインアクテイプというような対称 性にこだわるということ， も のごとの主従関係． 前後関係． 本末関係 などの階層関係を常に意識するということ。 構造化プログラミングの考え方もこの原理 の一部である。 ある機能は ， いくつかの機能の重ね合わせ によって実現されている（線型結合的である） のがよいとすること。 少しでも不透明なロジックは証明しておく ように努めること ． どうしても証明できな いときや証明しにくいときには ， そのロジ ックあるいはそれが拠っている基本方式を 捨てることを党悟すること。 必然性のないところや曖昧なところは ， ち よっとル ー ズに ， 安全サイドで設計してお くというようなこと。 の出力例を示す。ASDGEMの特長としては以下 のことがあげられる。 ー タを利用するた 0 自動的に記録される更新デ ） ク ぐ ー m ー 15 E3 性 当率 妥出 のュ ピ 娑 文 グ レ パの ス 一出 ソ i 食 ⑲ ⑭ 数の パグ 念 i （ 性 分 十 検出 妥当 検 期 早 妥当性 グ ゞ I ⑫ め，開発担当者に負担をかけることなく，開 発作業が把握可能である。 0 開発プロジェクトとソフトウェアの実態を視 覚的にとらえることができる。 6.4テスト項目設計支援システム 試験および製品検査工程では外部仕様に基づく テ ストによりソフトウェアの妥当性が検証され る。テ ストを体系的に かつ漏れのないように行 うために， テ スト項目の作成においては以下のテ スト項目設計手順を定めている。 0 テ スト要因分析 プログラムの動作環境を規定する要因（「因 子」と呼ぶ） と因子の取りうる値（ 「状態」 と呼ぶ） を分析し，所定のテ スト要因分析表 を作成する。 0 テ スト項目設定 テ スト要因分析表上の各因子ごとにテ ストす る状態の選択を行い，テ スト項目を作成する。 しかし， 大規模なソフトウェアのテ ストにおい ては，構成プログラムおのおのに関する知識， 各 種ハ ー ドウェアに関する知識など広範囲にわたる 知識をテ スト担当者が持つ必要があり，単にテ ス 卜項目設計の方法論だけでは解決できない問題が ある。医9に示すテ スト項目設計支援システム で WEEKLY AMOUNT OF WORK. ADDED/DELETED LINES AND UPDATES 週間作業量の歴史変化 10 1@開発規模の増減 ADDED 5 追加／ 削 除行 数 規 模 7つの設計原理 新回数」「総投入行数」「総削除行数」「有効行 数」など） を各種のグラフに表現することによ り，分析作業を支援している。図8にASDGEM ,, 〗,；⑧設計審(DD)レピュ ー の十分性 ,i 表3 •1;?.,<f>,原理ぐ VOi LOI 目 No. 評価項目 邑 藩 OO暉］ 訂⑭テスト(CT+ST)の十分性 （標準値との比 較） 卜 ⑬テスト(CT+ST)の十分性 （計画値との比較） 数 -5 更新回数 0 0 20100 :I空 図7 1/86 図8 標準化と品質管理 Vo/ 41 1988 2 35 36 ASDGEMの出力例 標準化と品質管理 Vol. 41 1988. 2 表4 c l , c2, ...... , ck 設 査読 • 修正 執筆 ・ 査読 • 修正 ・ マ ニ ュ ア ルの執筆 ・ 編集 • 原稿のチ ェ ッ ク お、よ び修正 旦 当者 マ ニ ュ ア ルの印刷 マニ ュ ア ル 不備の分析 と そ の対策の検討結果 マニュ 者 _1 _ ン ジ ニ ア リ ン グ に お け る 特長は， マニ ュ ア ル の企 画 ・ 設計工程 を明確に し た こ と で あ る 。 ま た， 作成す る こ と で， 手順に沿 っ た マ ニ ュ ア ル設計が 者 当 j BI 0 才 卜 行 え る よ う に し て い る 。 以下 は プル ー プ リ ン ト に ？ テス ト項目表 ー デー タ ペ ス ,IIIし r lllJ - 制約条件 I 排他 I a2 I o3 冠 日 bl 上を図 っ て い る 。 0 テ ス ト 要因 を デ ー ク ベ ー ス に蓄積 し ， テ ス ト 要因分析時に関 連す る 要因 を 自動的に検索 ・ O 動的 に テ ス ト 要因分析表 を作成す る 機能 標準化と品質管 理 Vol. 4 1 1 988 2 ー ル と 読者の ニ ー ズ （ 情報 ニ 4) ズ の 分析 リ ス ト ） マ 5) 各 マ ニ ュ ア ル に記載す る 情報の 内容 中川 徹 • ほ か ( 1984 ) : ソ フ ト ウ ェ ア 開発履歴分 ―一 方法論 と 適用箪例 • 第 4 回 ソ フ ト ウ ェ ア 生産 に お け る 品質 管理 シ ン ポ ジ ウ ム 発 表報文集， pp. 9-15, 日 本科学技術連盟 6) 7. おわ り に Tatsumi, K. ( 1987) : Test Case Design Support System. International Conference on Quality Con ・ trol , JUSE 以上紹介 し た の が， 富士通の基本 ソ フ ト ウ ェ ア 開発部門 の品質保証活動に関す る 考 え 方 と そ の事 例であ る 。 紙数の関係で十分な説明がで き な か っ ス ト 項 目 設定基準 (「 2 つ の 因 子間ですべて た が， 詳細 に つ い て は参考文献を参照 し て い た だ の組み合わせが 1 つ 以上 あ る こ と 」） に 従 っ き た い。 品質に対す る 考 え 方は技術の進歩や社会 て， テ ス ト 項 目 を 自 動的に生成す る 機能 状況の変化 に 伴 っ て よ り 高度化 し て お り 、 ソフ ト ウ ェ ア の 品質保証活動 も よ り 高度な段階へ と 進ん 6.5 ド キ ュ メ ン テー シ ョ ン ・ エ ン ジニア リ ン グ 日 本科学技術連盟 日 野克重 ( 1985) : ゾ フ ト ウ ェ ア障害の予防 と 分祈 （ 高信頼性運動 と し て ） . Engineers, No. I, pp. 6-10, 日 本科学技術連盟 析 (ASDG EM) ｀ 表示す る 機能 0 コ マ ン ド ， JCL な ど の外部仕様 を 解析 し ， 自 読者の プ ロ フ ィ したテ O 実験計画法 に お け る 直交配列表 を 応用 橋本典子、 谷 口 重光， 小林克己， 吉田 征 ( 1 987) : ソ フ ト ウ ェ ア開発過程の定屈的品質デー ク を 用 い た 自 動診断の試み． 第 7 回 ソ フ ト ウ ェ ア 生産 に お 0 用語， 文体， 詳細度 な ど テ ス ト 項 目 設計支 援 シ ス テ ム は， 以下に 示す機能 に よ り ， テ ス ト 項 目 の質の向 3) け る 品 質管理 シ ン ボ ジ ウ ム 発 表 報 文 巣 ， pp. 85- ニ ュ ア ル の体系 （ 各 マ ニ ュ ア ルの位置付 け ） O 各 マ ニ ュ ア ル の構成 （ 情報の説明順序） 者 当 ス 卜 図9 本品質管理学会 日 本能率協会編 ( 1 985) : 富士通の高信頼性迎勁 日 本能率協会 92, 0 ゜？J 担 � 2) る。 ー テn テ ス ト 項 目 2 l a2 l b3 l o2 く参考文献〉 森田昭憲 ， 苅田 栄 ( 1 984) : ソ フ ト ウ ェ ア品質 の と ら え 方 ． 品質 Vol. 1 4 , No. 12, pp. 89-93, 日 ー プ リ ン ト に基づいて マ ニ ュ ア ル本体が作成 さ れ O 9991」 rーー1j - p al I b2 I c l 1) 記載す る 情報で あ り ， 引 き 続 く 執筆工程で は プル テ ス ト 項 目 設定画面 テス ト項目 1 ． マ 呼ぶ所定の様式 に ま と め， こ の プ ）レ ー プ リ ン ト を 制約条件 I 排他 I a l ソ フ ト ウ ェ ア 製品 を 提供 し て い く 所存であ る 。 の作業 と 技法 を 示す。 ド キ ュ メ ン テ ー シ ョ ン ・ エ ニ ュ ア ル の 企画 ・ 設計の手順を プ ル ー プ リ ン ト と 制約条件設定画面 に 至 る 段 階 ま でPDCA を 回転 さ せ， よ り 高品質の ア ル作成工程 と 各工程で適用す べ き 技術を体系化 し た も ので あ る 。 表 4 に 各工程 当 o2 b2 ・ に基づ き ， O 日旦 戸 a2 rIIIL r __1J 状態 ー 2 cl bl ・ マ ニ ュ ア ル に 基づ く 検査 印 刷 は， ご[ p al 試 験 」 テ ス ト 要因分析画面 状態 ー 1 c' 'C 、 技 確化） ・ 情報 ニ ー ズの十分性の チ ェ ッ ク お よ ぴ追加 • 体系 ・ 構成の チ ェ ッ ク お よ び修正 三 a C 情報の体系化 （読者に対する情報の見せ方の明 設計書 外部仕様入力画面 �Ii� 計 j j 戸 三□ b I, b2, ...... , bi 者 状態 a l , a2, … .... a, 〇 , ？ I 因子 ： a .., ; P -< i ; r -o 練 熟 卜 11 竺 、：： 91119 fIIIJ - 関連要因 テ ス ト 知緻入力画面 冠 口 テ ス ト 要因 プー タ ペ ー ス マ ニ ュ アル作成工 程 と 技法 業 · •作 , ・ , 」 、・ ,..... • 読者の立場 と ソ フ ト ウ ェ ア に対す る 対応の分析 • 作業の分析 • 作業に対す る 情報 ニ ー ズの分析 7) 8) 根岸寛明， 吉田哲三 ( 1 986) : ド キ ュ メ ン テ ー シ ョ ン エ ン ジ ニ ア リ ン グ に よ る マ ニ ュ ア ル作成 ． 第27 回 プ ロ グ ラ ミ ン グ シ ン ボ ジ ウ ム 報告集 ， pp. 169180, 情報処理学会 石井康男 ・ 編 ( 1 986) : ソ フ ト ウ ェ ア の検査 と 品質 保証 日 科技連出版社 で い かねばな ら な い。 今後 と も 開発組織か ら個人 「 ド キ ュ メ ン テ ー シ ョ ン ・ エ ン ジ ニ ア リ ン グ」 37 38 標準化と 品質管理 Vol 4 1 1 988. 2