はじめての設計をやり抜くための本【設計編】第2章設計の目的⑥設計のアプローチ
◆外部設計と内部設計
基本的に設計工程の分け方について統一した定義はない
【当該書籍での分け方】
・外部設計≒基本設計、機能設計、概要設計
・内部設計≒詳細設計、プログラム設計
◆外部設計、内部設計の定義
・外部設計
システムの具体的な外部仕様を設計する作業。外部仕様とは、システムがユーザーや外部システムに対して提供する機能やインターフェイスのこと。
システムの設計では、入力と出力を明確にすることが基本となる。外部設計は、このシステムの入力と出力を明確にすることである。Webアプリケーションであれば、入出力がWebブラウザの画面でその間にDBが仲介する。
よって、画面設計とDB論理設計を主に外部設計として行う。また、アーキテクチャ設計も外部設計と並行して行うことがある。
・内部設計
外部設計では入力と出力が決まるので、内部設計では入力と出力の間で行う内部処理を設計する。具体的なソフトウェア内部の設計やデータの処理方法や管理方法、並列処理方法、トランザクション方法を設計する。また、DBの物理設計なども設計する。他にCRUD（create[新規登録]、read[読み出し]、update[更新]、delete[削除]）も行う。
外部設計、内部設計、アーキテクチャ設計
◆外部設計と内部設計の違い
●外部設計
外部設計はシステムの具体的な外部仕様を設計する作業。外部仕様とは、システムがユーザーや外部システムに対して提供する機能やインターフェイスのこと。外部設計ではシステムの入力と出力を明確にする。主な外部仕様の対象は「画面」「外部システムI/F」「コマンド/バッチ」「帳票」「DB」
ユースケースと概念モデルをもとにこれらを設計する。
●内部設計
外部設計で入力と出力が決まるので、内部設計では入力と出力の間で行う内部処理を設計する。
設計する内容としては、
・具体的なソフトウェア内部の設計
・データ処理方法や管理方法
・並列処理方法
・トランザクション方法
・DB物理設計
●オブジェクト指向設計とは
オブジェクト指向プログラミングを設計の作業にも応用した手法。
設計のいくつかある目的のうち、最も重要なことが「要件定義の内容をシステムでどのように実現するか検討する」こと。そしてシステムがどのような機能を提供するのかの概要を定義する。これをプログラミングするには機能を細分化する必要がある。この細分化の方法がオブジェクト指向設計と構造化設計では異なる。
●フローチャート
構造化設計の手法。従来の構造化設計では、機能の細分化をフローチャートやDFDで記述していた。フローチャートは開始から終了までの流れとして記述する。処理の流れが具体的に順番に記述できる。
欠点として処理の細分化はできるが共通化ができない。「データを格納する」という処理ができない。（フローチャートからは共通化できるかどうか判断できないため）また、フローチャートはデータを表現しないため「データを格納する」、「注文を格納する」のデータや注文の中身が何かは判断できない。フローチャートを書くよりもプログラミングした方が早い。
DFD
構造化設計の手法。インターフェースとDBの間の処理を記述できる。
特徴は処理間にデータを記述することにより、処理の入力と出力が表現できる。また、処理を外部インターフェースから呼び出すことができ、処理を共通化するように記述できる。
構造化設計の欠点
仕様の変更に弱い。商品情報の価格の構造が変更されると「入力チェック」処理、「注文を格納」処理に影響が出る。つまり仕様変更は処理全体に影響する。上記の例では「入力チェック」処理と「注文を格納」処理が関数であれば関数名や関数の引数と戻り値、それぞれの処理の呼び出し方は変わらないが処理の実装が変わる。
オブジェクト指向プログラミングの特徴
オブジェクト指向は構造化設計の欠点を解決するために機構を取り入れています。「クラス」、「継承」、「ポリモーフィズム」、「インスタンス化」。
●クラス
クラスとはデータと処理を一つの定義にしたもの。また、クラスに含まれるデータを「属性」、「メンバ変数」、「フィールド」と呼び、処理のことを
「操作」、「メソッド」と呼ぶ。クラスはフィールドを隠蔽することができる（カプセル化）。このカプセル化により、クラスはメソッドのシグネチャ（メソッド名、引数、戻り値）を公開し、フィールドの構造が変わってもメソッドのシグネチャが変わらなければ、クラスの呼び出し元には変更の影響はない。このようなクラスのメソッドとシグネチャのことをインターフェースと呼ぶ。
継承
クラスを拡張するための機構。
【継承の目的】
・オーバーライド：スーパークラスのメソッドをサブクラスで実際使用する定義に置き換えること。
・オーバーロード：スーパークラスが持っていないメソッドを新たに定義すること。全く新しいメソッドを追加できるし、スーパークラスと同じメソッド名で引数だけ変えることができる
上図の例ではItemクラスを継承してDiscountItemクラスを定義している。
継承は処理の共通化・再利用の手法。DiscountItemクラスはItemクラスを継承することにより、新しくクラスを定義するよりもプログラミングするソースコード量が少ない。
ポリモーフィズム
継承の考え方をさらに進め、クラスのインターフェースは同じままで実装だけを変えることでメソッドの呼び出し元に影響を与えずに実装クラスを変えること
◆オブジェクト指向設計の特徴
どのようなクラスがあるかクラス図で定義し、クラス間のメッセージパッシング（クラス間でメッセージが受け渡されること）をシーケンス図で定義する
●情報共有のための設計
設計の目的の一つとして、開発プロジェクトにおける関係者間での情報共有があります。開発プロジェクトでのコミュニケーションは重要であり、コミュニケーションが上手く行ってない開発プロジェクトは失敗することが多い。情報量も相手も少し多めにコミュニケーションを行い、「コミュニケーションの遊び」を作るようにする。
●設計者に関わる関係者
設計者にとってのコミュニケーションは設計内容や課題の情報共有。
設計者の関係者としての関心事
・プロジェクトマネージャーは設計作業の進捗や課題
・要件定義者は設計作業が要件定義に従って行われているかどうか
・設計メンバーは自分たちの成果物を見たい
・顧客は設計作業の成果物や進捗
※皆忙しく、自分の仕事は終わったと思いがち。
上記関係者に、設計成果物や課題を参照できるように次の手段を行う。
・レビューなどの打ち合わせを行う
・メールで送付する
・共有フォルダに置く
◆設計と見積り
見積りは要件定義の結果を元に行う事が多い。ユーザー企業が要件定義を行い、システム開発会社は要件定義の結果を分析し、開発を受けるための金額や期間や条件を見積る。
見積りは要件定義の後だけでなく、開発途中でも開発規模のメトリクス（評価指標）として計測する。メトリクスとはソフトウェアの開発規模や品質を測定するための指標。これにより、仕様の膨らみや技術的な難易度を管理できる。
見積りはPMの領域だが、設計者としても開発規模の視点を持つことは重要である。理由は外部仕様や技術的な難易度を開発現場で直接感じるため。
設計者が開発規模が当初の見積りと比べて増減があると感じた場合にはPMにアラームを出す必要がある。また、設計者が外部仕様などを設計する時に見積りの感覚が無いとユーザーとの調整ができない。外部設計を行うことはユーザーの機能追加への圧力と開発側の当初の見積りに抑えようとする圧力との調整になる。
初期の見積りで合意した開発規模を上回ることは開発側だけでなく、ユーザーにとっても不利益になる。初期の見積りを上回った場合でも開発会社に予備費用（バッファ）があればその範囲内で開発できるが、予備費用を上回る開発規模になると開発会社としても期間を延ばし、追加費用請求する。その結果ユーザー企業にとって不利益になり、システムのリリースの遅れがビジネスの遅れに直結する。
LOCと人月
従来はLOC（Lines Of Code：ソースコードの行数）で見積りを行っていた。
システムを開発するにはLOCがどれぐらいになるかPMの過去の経験や勘で算出した。問題点として、PMの過去の経験や勘を頼りにするので、経験したことがない要因があると見積ることができない。
●見積りの手順
①開発規模の見積り
②開発工数の見積り
③開発金額の見積り
①開発規模の見積り
【開発規模】は従来のLOCではソースコードの行数で表していた。現在ではプログラミング言語がさまざまあり、標準APIも充実しているため以前では難しいプログラミングも比較的簡単に記述できる。
②開発工数の見積り
開発工数は人月で表す。人月とは1人の開発者が1ヶ月で開発できる作業量を表す。1ヶ月は営業日ベースで20日。つまり1人月=20人日で、1人日=8時間とすれば1人月=160人時間となる。
人月の考え方はソフトウェア開発には適さないと考えられている。ただし、開発金額の計算では人月の単位が便利なため現在でも使われている。
【開発工数】は開発規模に作業量を掛け合わせて計算する。技術的な難易度は係数で調整する。
③開発金額の見積り
【開発金額】は開発工数に人月あたりの人件費を掛け合わせて計算する。
人月あたりの人件費は社員のランクや外部協力会社などによって異なる。
①開発規模を割り出し、
②その①に単位開発工数を掛け合せて開発工数（人月）を算出する。
③開発工数に人月あたりの人件費を掛け合せる ＝開発金額が算出される。
PMBOKでの代表的な見積り方法
１．ファンクション・ポイント法
→後述
２．類推見積り
→過去の同様なシステム開発の事例をもとに見積る（経験と勘）
３．パラメトリック見積り
→多数の計算式に値をあてはめて計算
４．ストーリー・ポイント見積り
→ユーザーストーリーを実現するのに必要な作業規模を相対的なポイントで見積る
５．ワイドバンド・デルファイ
→複数回見積りを作成して、見積りのたびにディスカッションを行う。ディスカッションした結果に基づいて再見積もりを繰り返すことで制度を高める。
◆ファンクションポイント法
見積り手順を上記したが手順の中で一番重要なのは開発規模をどのように見積るか。
LOCによる開発規模の見積り結果はプログラミング言語に依存する。ファンクションポイント（FP）法はプログラミング言語に依存しない。
「システムのデータと機能の数から開発規模を計測する。」
単位：FP、FP数が多ければ開発規模が大きい、FP数が小さければ開発規模は小さい。そして、FP数は「データファンクション」と「トランザクションファンクション」から求めます。
データと外部との相互作用をもとに、FP数という開発規模を計測する。
システムのFP数はデータファンクションとトランザクションファンクションのFP数を合算することで求められる。
●データファンクション（DF）
システムが内部で管理するデータ。主にデータベースを指す。（たまにファイル）※ログファイルのようなものは含まない。
*ファンクションの対象は機能要件のみ。
FP数は機能要件の規模が反映される。
非機能要件はFP数には含めない。（機能要件から計算したFP数とは合算しない）
理由は、品質目標が高ければテストを多く行う必要がある。また、技術的に難易度が高ければ調査工数が必要になる。このように品質目標や技術要件によって工数が変わるので最終的な見積りには非機能要件も含まれる必要がある。しかし、非機能要件は技術的な話題が多く設計工程に依存するため。
データファンクションはシステムによって更新されるかどうかで種類が分かれる
・内部論理ファイル・・・システムによって参照・更新されるデータファンクションで具体的にはシステムで管理するDBのこと。
・外部インターフェースファイル・・・システムから参照されるデータファンクションで具体的にはシステム外部にある読み取り専用のデータのこと。
データファンクションの複雑さを決める
・データ項目数（DET）→DBの列数 ※Tel1とTel2では１つとみなす。
・レコード種類数（RET）→データの種類。通常は１つだがサブクラス等があればその種類の数
複雑さが決定後、複雑さを「低・中・高」の3段階に評価する。
データ項目数とレコード種類数から複雑さを「低・中・高」に評価できたら
下図を用いてFP数を計算します。下図ではデータファンクションのファンクションタイプごとに、複雑さに応じた掛率を定義している。
データファンクションの数と複雑さに応じた掛率をかけることで、FP数が算出される。
例えば、複雑さ「中」の内部論理ファイルが２つ、複雑さ「低」の外部インターフェースファイルが１つではFP数は「2 × 10 + 1 × 5 = 25」になる。
（データファンクションのみ）
●トランザクションファンクション（TF）
TFはシステムが外界との相互作用を行うこと。システムが外界と行うデータの入力や出力のこと。
データの入出力の種類により外部入力（EI）、外部出力（EO）、外部照会（EQ）に分類できる。
・外部入力：システムが外部からデータを受け取りシステムの内部のデータファンクションなどに格納するTF。例えば、画面や外部システムからのデータの受信。
・外部出力：システムがDFの格納されているデータをシステムの外部に出力するTF。ただし、データをシステム外に出力する時にデータの加工（データの計算、画像処理、別データの作成→画面への表示、帳票出力など）を行う。
・外部照会：システムがDFに格納されているデータをシステムの外部に出力するTF。外部照会と外部出力の違いは出力するデータを加工するかどうか。
外部照会はデータを加工しない。
TFの注意事項
・TFは１つ１つの画面ではない。１つの外部入力に入力画面、確認画面、完了画面３つの画面が存在しても、１つのTFとする。
・TFは重複しないように気をつける。検索画面は多くの画面から呼び出されるが同じ検索項目と処理であれば１つとして扱う。
・TFはデータ項目数（DET）と関連ファイル数（FTR）の２つで複雑さを評価する。
*データ項目数（DET）：TFで入力や出力をするデータの項目数。画面で言えば画面を構成する動的な画面入出力項目。画面に表示するエラーメッセージやボタンを項目数にカウントする。
*関連ファイル数（FTR）TFを実行する時に更新や参照などで呼び出すデータファンクションの数。1回のTFで同じDFを何度も呼び出す場合でも１つとしてカウントする。
TFの複雑さが、データ項目数と関連ファイル数を使って決まったら、複雑さを「低・中・高」の３段階に評価する。複雑さの評価は下記の表とする。
データ項目数と関連ファイル数から複雑さを「低・中・高」に評価できたら下記の表でFP数を計算する。TFの数と複雑さに応じた掛け率を掛けることでFP数が算出される。例えば、複雑さ「中」の外部入力が２つ、複雑さが「低」の外部出力（EO）が２つ、複雑さが「低」の外部照会が３つあるとすれば、FP数は「２ × ４ + ２ × ４ + ３ × ３ = ２５」となる。
FP数抽出のポイント
ファンクションポイント法が適用できるのは外部設計が終了後のため要件定義直後ではをそのまま適用することはできない。要件定義直後の見積りに適用するためには試算法か概算法のどちらかの方法を用いる。
●試算法
FP試算数＝３５ × ILFの数 + １５ × EIFの数
※ILF：内部論理ファイル、EIF：外部インターフェイスファイル
試算法はTFの数がわからずDFの数だけ分かる場合に、概算を見積る場合に使用する。
●概算法
DFの数だけではなく、TFの数も推測で分かる場合に使用する。
そのため試算法よりも正確に見積ることができる。
概算法ではTFを「中」、DFを「低」とする期待値を設定する。
TFは要件定義の成果物であるユースケースや外部設計の成果物である画面から求める。
◆設計とテスト
●テストの種類
・単体テスト：プログラム単位のテスト。クラスのメソッド単位で行う。
また、ホワイトボックステストとブラックボックステストがある。
ホワイトボックステストでは処理に応じて条件分岐などの網羅性を担保する。ブラックボックステストではメソッドの入力である引数の組み合わせと
出力である戻り値を評価する。
・結合テスト：複数のプログラムを結合したテスト。クラスを結合して画面からDBまでの１つの機能をテストしたり、さらに複数の機能を連携させ、画面遷移に沿ってテストする。ブラックボックステストが基本。
・システムテスト：システム全体を対象にしたテスト。全てのユースケースが開発され、それら全てを対象にテストする。個々の機能は完成した後、ユースケース記述に沿ってテストする。ブラックボックステストである。
単体テストでも結合テストでもシステムテストでもテストケースを作成するには何が正しいプログラムの挙動か知らなければならない。ボタンを押した時にどのような処理、表示がされるかは画面設計書を見る必要がある。
そのため、設計とテストは密接に関係している。テストの品質を決めるのは設計である。設計の品質が悪い状態で品質の良いテストを行うのは難しい。
ここまでで【設計編】⑥設計のアプローチを終わります。
次回は第3章外部設計の手法①外部設計とはについて記載します。
この記事が気に入ったらサポートをしてみませんか？