Transcript PowerPoint 演示文稿

ソフトウェア開発及びソフトウェア
プロジェクトマネジメント（II）
北京航空航天大学软件学院
马
平
博士 副教授
[email protected]
第2回 ソフト開発のドキュメンテーショ
ン




ドキュメンテーションの重要性
ドキュメントの種類
ドキュメントの作成と記載内容
ドキュメントの品質管理
ドキュメンテーションの
重要性


ドキュメンテーションの重要性と位置づけ
ドキュメンテーションの考え方
ドキュメンテーションの
重要性と位置づけ
ソフトウェアを購入あるいは開発依頼
したり、使用したり、開発・保守を行ったり、
開発過程を管理するのに必要な文書の
すべてをドキュメントとする。
ドキュメンテーションの構成



顧客向けのドキュメント
ソフトウェア開発者のためのドキュメント
ソフトウェアの運用・保守を行うためのドキュメント
ドキュメンテーションの
重要性


ドキュメンテーションの重要性と位置づけ
ドキュメンテーションの考え方
ドキュメンテーションの
考え方


ソフトウェアの開発、保守のために・・・厳密さ
ソフトウェアを利用するために・・・わかりやすさ
ドキュメントの目的別分類
（厳密さ）
 内部仕様書（機能仕様書など）
 保守書（内部構造説明書など）
（わかりやすさ）
 システム開発計画書（提案書）
 外部仕様書（マニュアル）
 保守書（システムメッセージ＆コード集など）
ドキュメンテーション




ドキュメンテーションの重要性
ドキュメントの種類
ドキュメントの作成と記載内容
ドキュメントの品質管理
ドキュメントの種類
顧客向けのドキュメント
 システム開発計画書
顧客に対して基本構想、システムの概要開発条件、
開発体制を説明する計画書
 外部仕様書マニュアル
顧客がソフトウェアを使用するために必要な説明書
（１）解説書
（２）機能説明書
（３）文法書
（４）使用手引き書
（５）操作手引き書
ドキュメントの種類
開発者のためのドキュメント
内部仕様書

ソフトウェアの機能、構造などを説明するものであり、開発者のためのドキュメント。

（１）基本仕様書

（２）機能仕様書

（３）構造仕様書

（４）論理仕様書

（５）ソース プログラム

（６）単体テスト仕様書

（７）結合テスト仕様書

（８）綜合テスト仕様書
開発管理・作業手順書

ソフトウェアを開発するうえでの作業標準・管理きじゅんなどを決めたドキュメント

（１）プロジェクト開発計画書

（２）プロジェクト完了報告書

（３）工程管理規準書

（４）作業手順書
メモ的ドキュメント

ソフトウェア開発者が、日常備考録的に作成するドキュメント
ドキュメントの種類
運用・保守者ためのドキュメント
保守書

ソフトウェアを運用・保守するためのドキュメント

システム操作手引書

システム・メッセージ＆コード集

内部構造説明書

問題解析手引書

データエリア
運用日誌
定期点検記録
ドキュメントの作成時期
要求分析・計画
（生産工程）
要求分析→計画
（作成ドキュメント）

開発プロジェクト基本計画書

システム開発計画書（提案書）

プロジェクト開発計画書

基本仕様書

工程管理基準書
ドキュメントの作成時期
設計
（生産工程）
機能設計→構造設計→論理設計
（作成ドキュメント）

作業手順書

機能仕様書

外部仕様書

構造仕様書

論理仕様書
製造
（生産工程）
プログラミング→テスト→綜合テスト
（作成ドキュメント）

（１）ソースプログラム

（２）単体テスト仕様書

（３）保守書

（４）結合テスト仕様書

（５）外部仕様書

（６）綜合テスト仕様書

（７）保守書
ドキュメントの作成時期
検査
（生産工程）
検査・評価
（作成ドキュメント）

検査仕様書

プロジェクト完了報告書
運用・保守
（生産工程）
運用・保守
（作成ドキュメント）

運用日誌

定期点検記録
ドキュメンテーション
ドキュメンテーションの重要性
 ドキュメントの種類
 ドキュメントの作成と記載内容
 ドキュメントの品質管理

ドキュメントの作成と記載内容



顧客向けのドキュメント
開発者のためのドキュメント
保守者のためのドキュメント
顧客向けのドキュメント


システム開発計画書
外部仕様書（マニュアル）
システム開発計画書
システム開発計画作成作業
項目一覧
（作業スケジューリング）
作業項目の決定、作業量推定、作業レベル決定、要員・日程計画作成
（ニーズの分析）
要求仕様書の理解、資料収集、設計条件の把握
（問題点の把握）
実現のための技術レベル、難易度、信頼性、拡張性、安全性、オペレーション
（システムの構想）
目的、設計条件、対象業務、設計範囲、オペレーション、処理方法、機能分担、データフロー、
性能
（ソフトウェア仕様）
機能構成、ファイル構成、入出力
（ハードウェア仕様）
コンフィギュレーション、機器仕様
（見積作業）
要員工数、開発期間、システム構成と費用、ソフトウェア規模、ハードウェア設計・調達、テスト
用設備・仕様コンピュータ時間、教育・保守
（ドキュメンテーション）
システム開発計画書、内容・書式チェック、社内検討会
システム開発計画書
内部仕様書（機能仕様書など）
 保守書（内部構造説明書など）
 システム開発計画書（提案書）
 外部仕様書（マニュアル）
 保守書（システムメッセージ＆コード集など）

外部仕様書（マニュアル）





読者の作業環境と情報ニーズの把握
マニュアル体系の設計
各マニュアルの構成
各マニュアルに記載する情報の内容
用語、スタイル、詳細度の検討
各マニュアルの構成
そのマニュアルの読者の作業は何か
①作業内容
②作業の性格の属性
 どのような情報を必要とするのか

マニュアル作成手順








読者の分析 読者の作業分析
↓
作業ごとの情報ニーズの分析
↓
記載項目の洗い出し
↓
記載項目の体系化・順序づけ
↓
記載内容の洗い出し
目次
↓
記載内容の順序づけ
↓
執筆
得られる効果（１）
マニュアルの構成面に対する検査・
品質管理もできるようになり、結果
的にマニュアル品質向上につながる。
得られる効果（２）
マニュアル体系、構成の品質向上が
見られる。また、手順を明確にした
ことでマニュアル作成の効率化の効
果も得られる。
得られる効果（３）
顧客のニーズに基づいたマニュアル
作成を行うという意識への転換がは
かられる。
各マニュアルに記載する
情報の内容
（説明書）

ソフトウェアの性格

必要ハードウェア

データベースなどの概要

性能
（機能説明書）

コンポーネントの機能

入出力業務

制御方式

例外処理
（文法書）

命令、コマンドなどの構文規則

オペランドやパラメータの書方
（仕様手引き書）

コンポーネントの目的

入出力方法

制御方法

データベースの利用方法
（操作手引き書）

オペレーションの方法

エラー表示とそれに対する処置方法
用語の検討


同じプロジェクト内で同一の内容を表現するのに異
なった用語が使われていることがある
一般に使われていない用語については、用語集を作
る。
ドキュメントの作成と記載内容
顧客向けのドキュメント
 開発者のためのドキュメント
 保守者のためのドキュメント

開発者のためのドキュメント


内部仕様書
開発管理・作業手順書
内部仕様書






基本仕様書
機能仕様書
構造仕様書
論理仕様書
ソースプログラム
テスト仕様書
基本仕様書






目的
対象業務
開発条件
ソフトウェアの概要
プログラム構成
ハードウェア構成
目的


どうなシステムであれば明確な目的をもたなければな
らない。
目的をあいまいにしたまま設計をはじめると、満足な
システムはできない。
対象業務


ソフトウエア開発者の立場で対象業務を明確にし、適
用範囲がどこまでであるのかを設定する。
性能目標をCPU優先にしなければならないとか、端
末の応答時間を優先するといった選択は、業務を明
確にしておかなければ誤ってしまう。
開発条件




コンピュータの共通使用可能
開発用言語
開発支援用ソフトウェア
開発場所
ソフトウェアの概要（１）


必要処理能力の推定・評価
システムの信頼性の目標設定
ソフトウェアの概要（２）
システムの信頼性の目標設定
システム稼動率（avalability）
A=MTBF/(MTBF+MTTR)
ただし、Aは稼働率、MTBFは平均故障間隔、
MTTRは平均修復時間。
ソフトウェアの概要（３）





情報の流れ
情報の管理方式
マンマシン・インタフェース
システムの制御方式
システムの構成
プログラム構成



汎用ソフトウェアの完備度と利用
既存ユーティリティの完備度と利用
開発するプログラムの機能要件
（機能・構成・動作条件）
ハードウェア構成


システム開発計画書に基づいて必要機器、性能など
を見積もる。
テスト（デバッグ）用ハードウェア構成についても、見
積もりを忘れてならない。
基本仕様書の記載項目







名称：ソフトウェアにふさわしい名前
目的：ソフトウェア開発の背景と動機
対象業務：対象業務の概要と適用範囲
開発条件：ソフトウェア開発にあたっての前提条件
ソフトウェアの概要：ソフトウェアの特徴と基本方式
プログラム構成：目的とするソフトウェアを実現するた
めに必要なプログラムの構成
ハードウェア構成：当該ソフトウェアが対象とする業務
を遂行するのに必要なハードウェ
ア構成
内部仕様書
基本仕様書
 機能仕様書
 構造仕様書
 論理仕様書
 ソースプログラム
 テスト仕様書

機能仕様書
（機能）

処理方式

データ形式

アプリケーション

ユーティリティ
（性能）

応答時間

メモリ容量

処理量（単位時間当たりの処理件数など）
（入力情報）

作業指示方法

データの入力方法

他コンピュータからの情報入力方法
（出力情報）

伝票

他コンピュータへの情報

操作のガイダンス
機能仕様書
（操作方式）

作業指示

保守

異常対策

エラーチェック
（異常処理対策）

エラー通知方法

障害記録のとり方

リカバリ方法

応急処置方法

問題の切り分け方法
（ハードウェア）

コンピュータ

周辺装置

回線

端末

特殊機器
機能（１）




ソフトウェアの機能
ユーザが扱う情報（データ）の内容と形式
関連するパッケージ・ユーティリティとの関係
交換性：以前の仕様製品からの移行を考える場合
機能（２）




情報（データ）の処理方式とプログラムの構成
依頼性目標と信頼性構造の方式
ソフトウェア開発で採用する標準
制約・制限事項
性能（１）



CPU時間（科学計算のような場合）
プロセス時間（オンラインで処理される業務のような場
合）
主記憶容量
性能（２）




補助記憶装置の容量
周辺装置へのアクセス時間
端末の応答時間
印刷装置の印刷速度・台数
入力情報・出力情報（３）







データの妥当性のチェック
データのシーケンスのチェック
文法のチェック
入力の容易性
不必要なデータが出力されていないか
必要なデータが利用しやすく出力されているか
見やすいフォーマットか
操作方式（１）




システム運用・管理者の操作
システムスタート・リスタート法
データの管理・保管方法
障害発生による対処方法
操作方式（２）






エンドユーザの操作
入出力機器の検討・選択
各種機器での操作方法
画面形式の決定（ディスプレイの場合）
メッセージ・フォーマットの決定
準備すべき操作マニュアルの設計
異常処理対策





異常状態の検出方法
異常発生の経時記録方法
バックアップ方法と範囲
リカバリ方法
ハードウェア
異常状態の検出方法
システムの異常やソフトウェア使用者
の誤りに対し、どのような状態を異常
とみなすかを設定する。また、状態の
レベルについても設定する。
異常発生の経時記録方法（１）
異常状態が発生した場合、その状態
が検出されることも重要であるが、
異常状態にいたるまでの経緯の情報
が大切である。その情報がなければ、
障害の回復やバックアップが行なえ
ないが多い。
異常発生の経時記録方法（２）
それらの経緯記録をプログラム内の
特定データエリアに行うのか、ロギ
ング・ファイルのような特定の磁気
記録装置のファイルに行うのかを決
定する。また、どのようなタイミン
グ（時期間隔）で行なうのかも決定
する。
バックアップ方法と範囲



バックアップすべき対処：メモリの状態
バックアップ周期
バックアップ媒体の二重化
リカバリ方法

バックアップすべき対処：
異常状態から正常状態に復元する方法
であり、システムを停止せずにできる
とか、バックアップしたものの復元方
法などを定める。
ハードウェア
システムのもつべき諸機能を具体化
するのに必要なハードウェアについ
て、明確に設定しておかなければな
らない。
内部仕様書
基本仕様書
 機能仕様書
 構造仕様書
 論理仕様書
 ソースプログラム
 テスト仕様書

構造仕様書




コンポーネントの構造と制御
内部インタフェース
外部インタフェース
異常処理のための取り決め
コンポーネントの構造と制御

ソフトウェアの物理的な構造について記述することで
ある。

ソフトウェアを構成するコンポーネント間の制御の流
れについても記述する。
外部インタフェース（１）




ソフトウェアの名前
ソフトウェアの機能概要
呼び出し形式
受渡しパラメータとその状態
外部インタフェース（２）



受渡しデータ（あるいはファイル）
使用する機能の範囲
その特記事項
内部インタフェース
～共用データ



構造：図示する。
値と意味：値のとる範囲とそれぞれの値の意味を設定
する。
変遷：複数のコンポーネントによりデータの値が変更
される場合、その値の推移を明示する。
内部インタフェース
～共用モジュール
ソフトウェア全体で共用に使用する
モジュールの機能と、そのモジュー
ルに対する入出力の受渡し条件を明
確にする。
異常処理のための取り決め





エラー処理コンポーネントへの制御の受渡し方法
エラーのレベル
エラーコードとそれに対応したカバリ（処置）内容
メッセージ規約
エラー検出コンポーネントへ復帰
記載項目











モジュール名称
データファイル
改訂履歴
処理フロー
機能・処理概要
データフロー
入力機能
メモリマップ
出力機能
制約条件
異常処理とその通知方法メッセージ
内部仕様書
基本仕様書
 機能仕様書
 構造仕様書
 論理仕様書
 ソースプログラム
 テスト仕様書

論理設計手順１
コンポーネントを構成する個別機能
（サブコンポーネント）の構造を設
計する。さらに、サブコンポーネン
トを実現するための処理モジュール
の構造も設計し、そのモジュール相
互の制御データの受渡し方法を決定
する。
論理設計手順２～３


処理モジュールとの処理手順を設計する。
サブコンポーネントの構成と処理モジュールの処理内
容をまとめて、論理仕様書を作る。
論理設計


機能単位設計
サブコンポーネントが備える機能を実現するためのモ
ジュールの関係を明らかにするため。
処理単位設計
各モジュールの処理手順を明確にするため。
論理仕様書


機能単位設計
処理単位設計
機能単位設計
機能単位設計では、機能の内容を明確に
するとともに、その機能を実現するため
のモジュール構成や、関連するサブコン
ポーネントとのインタフェースを明確にする。
機能単位設計





機能内容
モジュールの構成
関連サブコンポーネントとのインタフェース
データ
特記事項
処理単位設計
処理単位設計




処理単位設計では、それぞれのモジュールの処理手順を設計し、次の
工程であるプログラミング作業の助けとする。このため処理単位設計で
は、プログラミング作業に必要な事項をもれなく記述しなければならな
い。記載項目の例を、以下に示す。
モジュールの機能
モジュールの呼び出し形式・・・・・・モジュールを呼び出すときに受け渡
しするパラメータとその意味について、また呼び出すときと戻るときの状
態も記述する。
診断情報・・・・・・このモジュールで検出するエラーについて、そのエ
ラー番号、出力するメッセージ、エラー意味、エラーのレベル、エラー発
生後の処理内容を記述する。
データ・・・・・・モジュールで使用するデータについて、データの構造、
データの各項目の意味、データの内容の変遷について記述する。
内部仕様書
基本仕様書
 機能仕様書
 構造仕様書
 論理仕様書
 ソースプログラム
 テスト仕様書

ソースプログラム（１）






モジュール名称
作成者
作成日、更新日
入力データ
出力データ
版権表示
ソースプログラム（２）
機能概要など







モジュール名称：モジュール規約を設け、それに名前を書く
版権表示：モジュール名 COPYRIGHT 会社名
2004/12/05
機能概略説明：モジュールの機能概略を書く
インタフェース：呼び出し形式、復帰時の状態
入出力ファイル：入力データの性質・媒体、出力データの性
質・媒体
診断情報：出力するエラーコードとエラーメッセージ
内部手続きの構成：内部手続きの構成を視覚に書く。
内部仕様書
基本仕様書
 機能仕様書
 構造仕様書
 論理仕様書
 ソースプログラム
 テスト仕様書

テスト仕様書



単体テスト仕様書
結合テスト
総合テスト
開発者のためのドキュメント


内部仕様書
開発管理・作業手順書
開発管理・作業手順書




プロジェクト開発計画書
プロジェクト完了報告書
工程管理基準書
作業手順書
プロジェクト完了報告書
プロジェクト完了報告書は、プロジェクト開発計画書に
対応づけて作成する。品質管理、納期管理を目的とし
て、本プロジェクト完了報告書を活用するためには、
各工程の終わりに報告書を作り、計画書との差異分
析を行うべきである。
開発管理・作業手順書




プロジェクト開発計画書
プロジェクト完了報告書
工程管理基準書
作業手順書
工程管理基準書





プロジェクト管理体系
報告者と報告の場・時期
計画変更の手続きと決定者
工程完了と判断する基準（各工程ごとに）
工程管理に必要な定型帳票
開発管理・作業手順書
 プロジェクト開発計画書



プロジェクト完了報告書
工程管理基準書
作業手順書
作業手順書







権表示：モジュール名 COPYRIGHT 会社名 2004/12/05
機能概略説明：
（概要）１．作業手順書の作成
２．作業手順書の概要
(作業方法)１．仕様書の作成

盛り込むべき内容

ドキュメンテーション規定
２．デザインレビュー

作業内容

方法

報告
３．プログラミング

コーディング規約
作業手順書







４．ソースコードレビュー

レビューの観点

方法

報告
５．テスト

項目設定方法

エラーの通知方法

テスト環境

エラーの修正方法

評価
（生産物の管理）１．仕様書
２．プログラム・ライブラリ

プロジェクト・ライブラリ/個人ライブラリ

世代管理

プログラムの修正方法
（協議事項）１．協議事項
２．協議日程
（帳票）・
作業報告書

レビュー結果報告書

エラー通知票

チェックリスト類

会議録

質問・要望票
ドキュメントの作成
と記載内容



顧客向けのドキュメント
開発者のためのドキュメント
保守者のためのドキュメント
ドキュメントの品質管理
内部仕様書レビュー
 「手順１」仕様書の位置付けをはっきり理解する。
 「手順２」仕様書の全体の構成を見直す。
 「手順３」内容の検証を行う。このとき、チェックリストを使用する。
 「手順４」さらに一段階前の仕様書の内容が、正しく詳細化され
ているかどうかを見直す。
 「手順５」修正個所の再確認を行う。
ドキュメントの品質管理
マニュアルの検査








企画：１．読者の立場とソフトウェアに対する対応の分析
２．作業の分析
３．作業に対する情報ニーズの分析
設計：１．情報の体系化（読者に対する情報のみせ方の明確化）
設計査読・修正：１．情報ニーズの十分性チェックおよび追加
２．体系・構成のチェックおよび修正
書き・査読・修正： １．マニュアルの書き・編集
２．原稿のチェック（文書作成基準レベルのチェック）およ
び修正
検査：マニュアルに基づく製品検査
印刷：マニュアルの印刷
評価：印刷結果のチェック
流通：マニュアルの在庫管理
保守管理法






「手順１」プロジェクトリーダは、ドキュメントのマスタコピーを入
手する
「手順２」プロジェクトリーダは、そのドキュメントを検討し、改訂
が必要な個所に印をつける。
「手順３」プロジェクト要員が要求された変更を処理し、ドキュメ
ントの改訂の原稿を作る。
「手順４」プロジェクトリーダは作られたドキュメントを検討し、関
係部門から修正の承認をもらう。
「手順５」改訂の通知添付資料をつけてライブラリに提出する。
「手順６」ドキュメンテーション・ライブラリは改訂を処理する。
保守管理法
内部構造説明書：
（構成）１．内部論理説明書
２．実行論理説明書
（概要）プログラムの内部構造、実行論理を記述したもので、
ソースプログラム解読のための副読本。
問題解析手引書：
(構成） １．システムデバッギング手引書
２．コンポーネントデバッギング手引書
（概要）システムやコンポーネントの異常や障害の診断方法を
記述したもので、何が発生したかを診断するための手
引書。
データエリア：
（概要）共通データエリアの説明。