Software Engineering

CS专业课学习笔记

ソフトウェア工学紹介

ソフトウェア工学とは

• コンピュータ・ソフトウェアの開発，運用，保守における生産性と品質の向上を実現するための技術体系や学問体系
• 品質Qが高いソフトウェアを，低いコストCで，短い／決められた納期Dで生産するため技術

大規模ソフトウェア開発が難しいの原因:

• 生産物の規模が増加
• 人員の増加 ステークホルダ(stakeholder)間の調整が困難に
  • ソフトウェアの開発とその成果物にかかわりのあるすべての人のことをステークホルダーと呼ぶ
• 長期化
• 社会的な役割の変化 止められないシステム

• プログラムの規模を測る指標として，プログラムの行数SLOCがよく使われる
• プロジェクトが期日から遅れると，残業や休日勤務が定常化し，関係者が疲弊しプロジェクトがさらに遅れる状態をデスマーチ(death march)と呼ぶ

ソフトウェアライフサイクルに関して

• ソフトウェアシステムに置き換えられる活動やしくみを調べ，何をつくるのかを明らかにする $\Rightarrow$ 要求分析・定義
• どのような資源（ハードウェア・ソフトウェア）を使ってどのように実現するのかを検討し決定する $\Rightarrow$ 設計
• 作成したソフトウェアが意図したものとなっていることを部分から全体にいたって検査，確認する $\Rightarrow$ テスト
• 運用中のシステムの不具合に対応し，機能や性能の改善・拡張を施す $\Rightarrow$ 保守

ソフトウェア開発工程

waterfall model

ウォーターフォールモデル：工程順に滝を水が上流から下流に向かって流れるように開発をすすめる方法

工程毎にレビュー等を行い次工程に進んで良いか確認（前工程に戻ることをなるべく避ける）

V字型モデル

• 要求分析からプログラミングまで段階的に設計を詳細化（段階的詳細化; stepwise refinement）
• 単体テストから運用テストまで段階的にモジュール，サブシステム，システム，業務へと統合（段階的統合化; stepwise integration）

期間と工数

要求定義から外部設計，内部設計へと進めていくに従って必要な工数（人数×期間）が大きくなり，プログラミングで最も大きくなる

利点と欠点

利点

• 開発の進捗管理(progress management)がしやすい
• 多人数の共同作業となる大規模システムの開発でも実績がある

欠点

• 机上では要求事項や設計の詳細化・明確化には限界がある
• 要求事項も時々刻々と変化する
• 大量のドキュメントの作成を必要とする

spiral model

スパイラルモデル: 各工程でリスクを分析し、次工程の一部をプロトタイプとして実装することでリスクを回避する考え方

プロトタイプ

プロトタイピング(prototype)の例

• 要求分析・定義の前に
  • ユーザインタフェースのプロトタイプ（試作品）を作ることでユーザの要求を確認し大きな手戻りを防ぐ
• 設計の前に
  • 難易度の高いアルゴリズムをプロトタイピングすることで実現可能性を確認

agile process model

アジャイルプロセスモデル: 早期にリリースし，ユーザとの協力関係によりプロダクトを成長させていく方法

エクストリームプログラミング(XP)がアジャイルプロセスを実践する手法として有名

• 短期開発の反復
• テスト計画先行(test first)
• ペアプログラミング(pair programming)
• 連続同時レビューテスト
• 随時リファクタリング

SCRUM

要求分析・定義

• 業務フロー図(workflow diagram)
• ユースケース図(use-case diagram)
• ユースケースシナリオ(use-case scenario)

• 顧客が求めていること(why)を把握し，何を作るか(what)を明らかにすること．
• どのように作るか(how)はこの段階では議論しない（設計工程以降）

• 要求仕様書に，想定するユーザの教育レベルや経験，技術的知識といったユーザ特性を記載することがある

要求と要求仕様の違い

• 要求(Requirements): 顧客が求めているもの(機能要求/非機能要求)
• 要求仕様(Requirements specification): 要求を具体的に記述したもの

要求仕様が満たすべき性質

• 完全性（=モレがない; complete）
  • 要求が漏れると設計段階以降で手戻りが発生して，設計が進まなかったり，再設計が必要になる．
• 非曖昧性（=明確; unambiguous，検証可能$\Rightarrow$できるだけ数値化）
  • あいまいな言葉を使うと最終的に要求を満たしたソフトウェアが出来たかどうか検証できない
• 無矛盾性(consistent)

要求獲得

要求獲得の手法:

• 資料収集（業務フロー図）
• インタビュー
• アンケート
• ブレーンストーミング
• 現場観察
• プロトタイピング
• ユースケースシナリオ
• ゴール指向分析
• 問題フレーム（プロブレムフレーム）

業務フロー図

業務フロー図(workflow diagram)：組織内の役割間の関連がわかるように作業や連絡の手順・流れを図示したもの

利用者（顧客）の現状の業務フローを把握し，どこをシステム化対象とするか認識あわせを行う

ゴール指向分析（目的展開）

ゴール指向分析(目的展開)：ゴール（目標）を達成するために，ブレークダウンしていき要求を系統的に整理する方法

• AND分解：部分ゴールが全て満たされると上位が満たされる
• OR分解：下位ゴールのいずれかが満たされると上位のゴールが満たされる

ユースケース図

ユースケース図：システムの機能を表すユースケースとアクターの関係を表現したもの

• アクター：システムに働きかける人や外部システム
• ユースケース：システムの機能（働き）

ユースケースシナリオ

目的: システムがどのように作用するかをステークホルダーに理解してもらうため

• シナリオ(scenario)演劇脚本のように，だれが，どういう状況で，いつ，何をすると，状況がどう変わるかを記述したもの
• だれが？
  • アクターと呼ばれる．一般利用者，管理者など人間であることが多いが，外部システムや機械の場合もある．
• どういう状況で，状況どう変わるか？
  • 事前条件，事後条件を明らかにする．
• いつ？
  • この動作を起こすきっかけとなる事象（トリガ）
• 何をして？
  • 一連の動作（アクション）．正常な動作系列の他に，代替的な動作系列，例外的な動作系列がある．
  • 画面は重要であるが，この段階では画面設計は行わない

シナリオを記述する際に、基本フロー，代替フロー，例外フロー三つに分けて書く。

• 基本フロー
  • ユースケースの実行に伴って起きるアクターとシステムとの間のやり取り(イベントフロー)のうち，正常に処理が進んだ場合を記述．
• 代替フロー
  • イベントフローのうち，途中でユーザが別のアクションをとった場合などに分岐する，メインフローの代わりとしてはたらく手順を記述．
  • 代替フローを実行しても事後条件は満たされる．
• 例外フロー
  • イベントフローのうち，ユースケースの実行を断念しなければならないような場合の手順を記述．ユーザから見えるシステムのエラーで，代替するフローがない例外のもの
  • 例外フローを実行した場合，事後条件は満たされない

注意点:

• 主語は「アクター」または「システム」とし，文頭に持ってくる
• 述語は入力する，指示する，検証する，促す，通知する，表示する
• 基本フローと代替フローの番号を対応づける
  • 基本シナリオ： 2
  • – 代替シナリオ： 2a, 2a1, 2a2, 2へ戻る
• 詳細化しすぎない
  • システムはブラックボックスとして扱う
  • 画面設計はしない
  • 細かな項目や属性は箇条書きにする

ユースケースの特長

• ユースケース・モデリングは、システムの機能要求を把握するための技法
• ユースケースは見積もり・スケジューリングなどの基盤としても使用できる
• ビジネスユーザーに理解しやすいことから、開発者とエンドユーザーの意思疎通に役立つ
• ユースケースの代替フローによってシステムの頑健性を強化することができる

要求の仕様化

• データフローモデル(data flow model)
• 状態遷移モデル(state transition model)
• 実体関連モデル(entity relationship model; ER model)

構造化分析の考え方

• 誰が見ても（顧客，設計者，プログラマから見ても）分かりやすく，曖昧性が低い形を仕様記述
• 段階的詳細化 + 図示

構造化分析の手法: デ・マルコ(DeMarco)の手法

• データフロー図(DFD; Data Flow Diagram)
  • 顧客や設計者に分かりやすくデータや処理の流れを説明
• データ辞書(DD; Data Dictionary)
  • データ項目の漏れや認識違いを防ぐ
• ミニスペック(Mini Specification)
  • 処理手続きを文章や疑似プログラムで表現

データフロー図(DFD)

データフロー図(DFD): 対象物（データ）を処理する順序を図示する手法

• 入力，出力されるデータと処理の流れを明記

データフロー図の詳細化：全体文脈図(context diagram)から，処理(process)を段階的に詳細化したDFDを作成

課題3.1

「ネット販売業務（会員管理業務）」のデータフロー図（DFD）を書きなさい

ネット販売業務（会員管理業務）の要求記述:

• 注文者は，事前に会員情報を新規に登録する
  • 新規登録において，会員管理機能は，会員情報を受け取ると，その注文者がすでに会員であるか検査する．会員情報とは，会員の氏名，住所，電話番号，初期パスワードをあわせたデータをいう
  • もし会員でなかったら，会員番号を発行し，会員情報とともに会員情報ファイルに登録する
  • 会員であれば，登録済みである旨を注文者にメッセージ通知する
• 注文者は，会員情報を変更することができる
  • 会員管理機能は，注文者から受け取ったログイン情報を会員情報ファイルと照合することで会員認証を行う．ログイン情報とは注文者の会員番号とパスワードをあわせたデータをいう
  • 会員認証に成功すると，会員管理機能は，注文者から注文者情報を受け取り，会員情報ファイルに登録する

データ辞書

データ辞書(Data Dictionary): データ項目が他のデータや値からどのように構成されるかを言語生成規則のように表現する手法

ミニスペック

ミニスペック：最下位の処理（バブル）について内容を文章や疑似プログラムとして表現したもの

状態遷移モデル

状態遷移図：「状態」をノードとし，「事象（イベント）」による「状態の遷移」をノードとノード間とエッジで表したもの

• 箱 $\Rightarrow$ 状態
• 矢印付きの線 $\Rightarrow$ 状態遷移
• 状態遷移のラベル $\Rightarrow$ 事象と動作の組($\phi$は出力なしを意味する)

課題3.2

スマートフォン（通話機能）の状態遷移図を書きなさい

決定表（ディシジョンテーブル）

決定表（decision table)：複雑な条件を整理して，行動を記述するための表

例：受講者が20名以上で，受講料が1人3万以上の場合は，コーヒーを無料で出します．コーヒーはパソコンのある研修室では出しません．受講者が20名以上の場合はコーヒーを出します．受講料が3万円未満の場合はコーヒーは有料です．

• 決定表を作成することで，仕様があいまいな箇所を発見できる

実体関連モデル（ERモデル）

実体関連モデル(entity relationship model; ERモデル) = 実体（エンティティ）間の関係を図示したもの

実体 = システム内に存在する管理対象の人，もの，お金，場所など

オブジェクト指向分析

• オブジェクト指向分析(object-oriented analysis)：実世界のモデルをソフトウェアで表現するために「オブジェクト」を構成単位としてソフトウェアを構築する枠組み

オブジェクト

定義:

• 人間が認知できる具象的あるいは抽象的な「モノ」（に対するコンピュータ内の表現）
• 属性（データ）とそのデータに対する操作（メソッド）を一つにまとめたもの

メリット

• 手続き型：プログラマーがデータ型を意識して，適切な手続き（関数）を選ぶ必要がある
• オブジェクト指向：オブジェクトが自分自身のデータの操作方法を知っているので，メッセージを送るだけで良い

基本概念

メッセージパッシング

メッセージパッシング(Message passing)：機能を呼び出すのではなく，オブジェクトにメッセージを送ることで処理を依頼する考え方

• 実世界の問題解決に近い業務モデルを表現可能（プログラマも楽）

カプセル化

カプセル化：データ（属性）とそれに特化した操作（メソッド）をまとめてモジュール化すること

• データや操作の隠ぺい／公開を制御できる
• 外部に公開された操作（外部インタフェース）しか許可されないので，利用側は内部構造が変わっても影響を受けない．

クラスとインスタンス

クラス：共通する属性（データ変数）や操作（メソッド）を持つオブジェクトを抽象化したもの（ひな形）

インスタンス：クラスを指定して生成される具体的なオブジェクト（属性の値だけが異なる）

• データの構造と操作が同じインスタンスを簡単に作る仕組み

継承

継承(inheritance): クラスを階層化し，親クラス（上位クラス）のもつ属性・操作を子クラス（下位クラス）の属性・操作として共有することで冗長性を削減する仕組み

• 差分のみ定義すれば良いので，ソフトウェアの再利用が容易になる

ポリモーフィズム(polymorphism)

ポリモーフィズム：同じメッセージを送っても，それを受け取るオブジェクトにより異なる動作をする特性

• メッセージに対するメソッドを実行時に関連づけることを動的結合という

統一モデリング言語UML

• なぜモデリング言語（図式化）が必要？
  • 要求仕様化における曖昧性を排除したり，完全性を高めるため
• OMG(Object Management Group) という民間標準化団体が整理統合し，2005年にISO/IEC 19501として国際標準規格化
• 2011年8月にUML 2.41リリース

クラス図(class diagram)

クラスの構造（属性や操作）とクラスの静的な関係を示す図

オブジェクトの関係

• 構成集約：部分オブジェクトが唯一の全体オブジェクトに属し，全体オブジェクトの生成，消滅をともにすることを示す
• 共有集約：部分オブジェクトが複数のオブジェクトから共有される．

汎化(generarization)

集約(aggregation)

多重度の考え方

クラス図の例：会議予約システム

演習4.1

(1) 以下のオブジェクト間の関係(part-of, is-a)をクラス図で表しなさい．構造（属性・操作）の記述は省略して構いません．

• スマートフォン，画面，電池，センサ，指紋センサ，GPSセンサ
• 通信端末，スマートフォン，ガラケー，iPhone，Androidスマホ，Galaxy S10

classDiagram
    スマートフォン  *-- 画面
    スマートフォン  *-- 電池
    スマートフォン  *-- センサ
    センサ  <|-- 指紋センサ
    センサ  <|-- GPSセンサ

classDiagram
    通信端末 <|-- スマートフォン
    通信端末 <|-- ガラケー
    スマートフォン <|-- iPhone
    スマートフォン <|-- Androidスマホ
    Androidスマホ <|-- Galaxy S10

(2) (1)で作成したクラス図に，is-a, part-ofの関係でつながるオブジェクトをそれぞれ1個以上考えて， 追記しなさい．part-of関係には多重度も記入しなさい．

classDiagram
    スマートフォン  "1" *-- "*" 画面
    スマートフォン  "1" *-- "*" 電池
    スマートフォン  "1" *-- "*" カメラ
    スマートフォン  "1" *-- "*" センサ
    センサ  <|-- 指紋センサ
    センサ  <|-- GPSセンサ
    センサ  <|-- 重力センサ
    センサ  <|-- 距離センサ
    センサ  <|-- 光センサ

classDiagram
    通信端末 <|-- スマートフォン
    通信端末 <|-- ガラケー
    スマートフォン <|-- iPhone
    スマートフォン <|-- Androidスマホ
    Androidスマホ <|-- huawei p40 pro
    Androidスマホ <|-- Galaxy S10

インタフェース

インタフェース(interface)：システムと外界との連係において守らなければいけない手順・規則・制約条件を宣言するもの（インスタンス化できない）

• 属性を持たない

classDiagram
  class センサ{
      << interface >>
      +start()
      +get_data()
  }
  class GPSセンサ{
      +location
      +time
      +start()
      +get_data()
  }
  class 温度センサ{
      +temperature
      +start()
      +get_data()
  }
  センサ <|-- GPSセンサ
  センサ <|-- 温度センサ

インタフェースは属性を持たないので, クラスの箱は2層で表している

オブジェクト図(object diagram)

オブジェクト図：ある時点でのインスタンスの状態とインスタンス間の関係を示す図

パッケージ図(package diagram)

パッケージ(package)：クラスなどの要素をグループ化し，それらの名前空間となるもの

名前空間(namespace)：同じ名前がでてきたら同じものを指すことを保証する空間

• javaであればpackage, C++であればnamespaceを使って名前空間を定義する

ユースケース図(use-case diagram)

ユースケース図：システムの機能を表すユースケースとアクターの関係を表現したもの

• アクタとユースケースを結ぶ線で相互作用の存在を示す
• ユースケースの内容は，ユースケースシナリオとして記述することが多い

状態機械図(state machine diagram)

• 基本は構造化分析の状態遷移モデルと同じ
• 状態機械図：オブジェクトの状態が相互作用の中でどのように遷移していくかを示す図

例:

コミュニケーション図(communication diagram)

コミュニケーション図：時間的な流れよりもメッセージのやり取りに基づくオブジェクト群のアーキテクチャを示す図

シーケンス図(sequence diagram)

シーケンス図：オブジェクト間の相互作用の時系列を表現

分岐処理alt(alternative)

繰り返し処理loop

条件判断opt (option)

演習4.2

「ネット通販システム」の注文確認・購入処理について，シーケンス図を作成しなさい

sequenceDiagram
  顧客 ->> ネット販売システム: 注文確認
  ネット販売システム ->> 注文: 注文内容を取得
  注文 ->> カート: 合計金額を取得
  loop
    カート ->> 商品: 価格を取得
    商品 -->> カート: 
  end
  カート ->> カート: 合計金額の計算
  カート -->> 注文: 合計金額
  注文 -->> ネット販売システム: 注文内容
  ネット販売システム -->> 顧客: メッセージ表示
  顧客 ->> ネット販売システム: 購入処理
  alt 支払い済み
    ネット販売システム ->> ネット販売システム: 商品発送依頼
    ネット販売システム ->> 注文: 削除
    注文 ->> カート: 空にする
    ネット販売システム ->> 商品管理: 在庫更新
    ネット販売システム -->> 顧客: 購入成功
  else 支払状況確認に失敗
    ネット販売システム -->> 顧客: 購入失敗
  end

モデリング手法（図）の種類と役割

Class diagrams

参考链接

 classDiagram
      Animal <|-- Duck
      Animal <|-- Fish
      Animal <|-- Zebra
      Animal : +int age
      Animal : +String gender
      Animal: +isMammal()
      Animal: +mate()
      class Duck{
          +String beakColor
          +swim()
          +quack()
      }
      class Fish{
          -int sizeInFeet
          -canEat()
      }
      class Zebra{
          +bool is_wild
          +run()
      }

Defining Relationship

classDiagram
classA --|> classB : Inheritance
classC --* classD : Composition
classE --o classF : Aggregation
classG --> classH : Association
classI -- classJ : Link(Solid)
classK ..> classL : Dependency
classM ..|> classN : Realization
classO .. classP : Link(Dashed)

Labels on Relations

classDiagram
classA <|-- classB : implements
classC *-- classD : composition
classE o-- classF : association

Cardinality / Multiplicity on relations

• 0..1: Zero or one
• 1: Only 1
• 0..1: Zero or One
• 1..*: One or more
• *: Many
• n: n {where n>1}
• 0..n: zero to n {where n>1}
• 1..n: one to n {where n>1}

classDiagram
    Customer "1" --> "*" Ticket
    Student "1" --> "1..*" Course
    Galaxy --> "many" Star : Contains

State diagrams

Start and End

stateDiagram-v2
    [*] --> s1
    s1 --> [*]

Composite states

stateDiagram-v2
    [*] --> First
    First --> Second
    First --> Third

    state First {
        [*] --> fir
        fir --> [*]
    }
    state Second {
        [*] --> sec
        sec --> [*]
    }
    state Third {
        [*] --> thi
        thi --> [*]
    }

Notes

stateDiagram-v2
    State1: The state with a note
    note right of State1
        Important information! You can write
        notes.
    end note
    State1 --> State2
    note left of State2 : This is the note to the left.

Concurrency

stateDiagram-v2
    [*] --> Active
    state Active {
        [*] --> NumLockOff
        NumLockOff --> NumLockOn : EvNumLockPressed
        NumLockOn --> NumLockOff : EvNumLockPressed
        --
        [*] --> CapsLockOff
        CapsLockOff --> CapsLockOn : EvCapsLockPressed
        CapsLockOn --> CapsLockOff : EvCapsLockPressed
        --
        [*] --> ScrollLockOff
        ScrollLockOff --> ScrollLockOn : EvCapsLockPressed
        ScrollLockOn --> ScrollLockOff : EvCapsLockPressed
    }

Sequence diagrams

Notes

sequenceDiagram
    Alice->John: Hello John, how are you?
    Note over Alice,John: A typical interaction

Loops

sequenceDiagram
    Alice->John: Hello John, how are you?
    loop Every minute
        John-->Alice: Great!
    end

Alt

sequenceDiagram
    Alice->>Bob: Hello Bob, how are you?
    alt is sick
        Bob->>Alice: Not so good :(
    else is well
        Bob->>Alice: Feeling fresh like a daisy
    end
    opt Extra response
        Bob->>Alice: Thanks for asking
    end

sequenceNumbers

sequenceDiagram
    autonumber
    Alice->>John: Hello John, how are you?
    loop Healthcheck
        John->>John: Fight against hypochondria
    end
    Note right of John: Rational thoughts!
    John-->>Alice: Great!
    John->>Bob: How about you?
    Bob-->>John: Jolly good!

ソフトウェア設計

システムから設計要素への分割

• モジュール：システムの構築に利用可能な構成部品
• サブシステム：システムの構成要素で，他のサブシステムにより提供されるサービスに依存しない独自のオペレーションを有するシステム
• インタフェース（界面、接触面）：システムの構成要素と構成要素又はユーザとの接続部分

標準的な設計仕様書

ソフトウェア要求仕様書に記載された要求を満たすために，ソフトウェアシステムがどのように構造化されるかを示すもの

ソフトウェア設計の4つの側面

• 概略設計（アーキテクチャ設計）：ソフトウェアの全体構造と組立てを記述する
• 詳細設計： 各モジュールの振る舞いやインタフェースを記述する
• 対象設計： 与えられた要求に対応する具体的なソフトウェアを設計する
• パターン設計： 複数の対象設計で共通的に使えるモジュールやその組み合わせ方を設計する．メタレベルの設計活動

アーキテクチャ設計（概略設計）：ソフトウェアの基本構造を定義

• アーキテクチャは，元来建築学や建築様式を意味する用語．コンピュータシステム，ネットワークなど様々な「モノ」に対する設計思想，基本設計，基本構造を意味する．

要求割り付け

要求割り付け(requirements allocation): 個々の要求を満足させるために，要求をサブシステムに割り付けること

考慮すべき品質特性:

• 実行時の品質特性に与える影響：
  • 効率性（処理速度，応答時間）
  • 安全性（セキュリティ）
  • 信頼性（耐障害性）
  • 使用性（使い易さ）
• 開発時の品質特性に与える影響：
  • 保守性（拡張性，変更容易性）
• 運用時の品質特性に与える影響：
  • 可搬性（新しいデバイス・OSへの対応）

ソフトウェアアーキテクチャ

ソフトウェアアーキテクチャ：複数の対象設計で共通的に用いることができる構造と組み合わせ方を類型化（パターン化）したもの．アーキテクチャパターンともよぶ．

代表的なソフトウェアアーキテクチャ（パターン設計）:

• 論理ビュー（モジュール構造）･･･モジュールの分割方法と相互作用
  • 階層モデル：三層モデル，仮想マシンモデル
  • MVCモデル
• 実行ビュー（プロセス構造） ･･･プロセスの分割方法と通信方法
  • データフローモデル：バッチ処理，パイプ・フィルタ
  • コントロールモデル：集中型，イベント駆動型
• 配置ビュー（プロセス配置）･･･プロセスのコンピュータへの配置方法
  • クライアントサーバモデル，集中処理，水平分散処理

階層モデル：三層モデル

階層モデル：機能を層状に上位から下位に並べて配置したモデル．データや制御は隣接する層の間のみ，階層を越えるやりとりはしない

三層モデル：データ層，ビジネス層，プレゼンテーション層に分割

• 利点：(1) 階層ごとに段階的に開発可能，(2) 階層を変更したときの影響範囲が隣接した階層に限定される
• 欠点：余計な処理，不要な作業が発生

階層モデル：仮想マシンモデル

仮想マシンモデル：システムを階層化して各階層でそれぞれのサービスを提供

• 利点：アプリでハードウェアやOSに依存しない機能を利用可能

MVCモデル

• Model: 問題固有のデータと機能

• View: 情報の表現

• Controller: システムに対するユーザ操作や外界からのイベントの処理

• 長所: (1) データと表示の一貫性を保証，(2) 同一モデルに対して複数のビューが使える

データフローモデル：バッチ処理

データフローモデル：入力データを処理して出力を生成する変換機能により構成されるモデル

バッチ処理: 特定の時刻に多量の蓄積データを一気に処理する即時性が求められない処理で有効．対話的なシステムには適さない．

• 利点：理解が容易，モジュールを再利用可能

データフローモデル：パイプ・フィルタ

パイプ・フィルタ: プロセスの出力と入力をパイプでつなぎデータストリームを処理するアーキテクチャ

• 利点：組み合わせ変更による柔軟性，並列処理による効率性
• 欠点：状態情報の共有が高価，例外処理

コントロールモデル：集中型コントロールモデル

コントロールモデル：サブシステム間の制御に着目したモデル

集中型コントロールモデル：１つのサブシステムが他のサブシステムの開始，停止などのすべてを受け持つ．並行システムに適用可能

コントロールモデル：イベント駆動型コントロールモデル

イベント駆動型コントロールモデル：各サブシステムが他のサブシステムあるいはサブシステムの外部で発生したイベントに対して応答

• ブロードキャストモデル：サブシステムは，特定のイベントが発生したときに処理を開始する．異なるコンピュータ上のサブシステムをネットワークで統合する場合に効果的．
• 割り込み駆動型モデル：イベントのタイプ毎にイベントハンドラーが定義される．イベントへの高速な応答が重要なリアルタイム処理に適用可能．

クライアントサーバモデル

クライアントサーバモデル：ユーザ側のクライアントとセンタ側のサーバに機能を分散（垂直分散）

• 利点：(1) 構築が容易，保守性が高い（アプリやDBの更新が容易）, (2) 機種やOSに依存しない構成を実現しやすい

集中処理：あらゆる機能とデータを1箇所に集中．高い信頼性と安定性が求められるシステムに適している．

水平分散処理：同一機能を複数のサーバに分散配置．負荷分散を図り，スケーラビリティを高める

構造化設計

モジュール設計：ソフトウェアを構成部品に分割し，構造化する作業

モジュール化の利点:

• モジュール単位で抽象化することで，部品を組み合わせるようにソフトウェアを構成できる
• モジュール単位で独立しているので並列開発，再利用可能

構造化設計：DFD(データフロー図)からモジュールを抽出

• 処理（データ変換）：図の楕円に対応する。モジュール（関数，手続き，サブルーチン）
• 流入するデータ：引数
• 流出するデータ：戻り値、又は結果を与える引数

よくないモジュール分割の例：一つのモジュールに複数の機能・役割が含まれている（多くのデータ変換を含む）

代表的なモジュール分割技法:

• データの流れに着目した分割技法
  • STS分割
  • TR分割
  • 共通機能分割
• データの構造に着目した分割技法
  • ジャクソン法
  • ワーニエ法

STS分割

STS分割(source/transform/sink decomposition)：データが変換される箇所（最大抽象点という）を見つけて，入力処理，変換処理，出力処理に３分割し，それらを制御するモジュールを主モジュールとして配置する方法

• 最大抽象入力点：入力とはいえない点まで抽象化された
• 最大抽象出力点：初めて出力データといえる形を示す

TR分割

TR分割(Transaction decomposition): トランザクションを入力するモジュール，属性毎に振り分けるモジュール，トランザクションごとの処理モジュールに分割

• トランザクション処理：入力データが与えられると，そのデータに関連する一連の処理を行う

eg. 基本給の更新，手当の更新，控除の更新に関する伝票を個別に入力し，給与計算用のファイルを更新する

共通機能分割

共通機能分割：STS分割，TR分割などで分割されたモジュールの中に共通する機能を持ったモジュールがある場合，それを共通モジュールとして独立させる

ジャクソン法(Jackson method)

ジャクソン法(JSP: Jackson Structured Programming)：データ構造に基づいてモジュール分割を行う方法

• 入力・出力データの構造を木構造(JSP木)で表現し，出力データ構造を基本形としてプログラム構造を作成

ワーニエ法(Warnier method)

ワーニエ法(Warnier method)：入力データ構造を元に「いつ，どこで，何回」という考え方でプログラム全体をブレイクダウンし，展開していく

課題8.1

課題8.2

モジュール分割の評価

複雑なプログラムも複数のモジュールに分割することで，分かり易く，保守しやすくなる．

モジュール分割の「良さ」を評価する基準:

• モジュール強度: モジュール内の関連性の強さ
• モジュール結合度: モジュール間の関連性の強さ

モジュール強度

モジュール強度(cohesion)：モジュールの機能・役割の凝集度の程度を示す

モジュール結合度

モジュール結合度(coupling)：モジュール間の関連性の程度を示す

デザインパターン

デザインパターン：様々なプログラムで再利用できる汎用的な設計に名前をつけカタログ化したもの（自分でコーディングが必要）

• オブジェクトの生成
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton
• オブジェクトの構造
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade
  • Flyweight
  • Proxy
• オブジェクトの振る舞い
  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

Compositeパターン：再帰的な構造を表現．個々のオブジェクトとオブジェクトを合成したものを一様に扱うことができる

フレームワーク

共通機能を提供するソフトウェア：

• ライブラリ：共通的に使われる関数や機能を一つのファイルにまとめたもの ．動的リンクライブラリと静的リンクライブラリがある
• ミドルウェア：OSとアプリケーションプログラムの間の中間的な処理・動作を行うソフトウェア．アプリ側が制御ループを持つ
• フレームワーク：アプリケーションプログラムの開発に必要とされる共通機能を土台として提供するソフトウェア

ミドルウェアの例:

• データベース管理システム
  • データを組織化し管理，効率的に検索する共通機能を提供
  • MySQL, PostgreSQL
• Webサーバ
  • HTTP要求を解釈し，HTMLコンテンツを応答する機能を提供
  • Apache HTTP server, nginx
• アプリケーションサーバ
  • Webアプリケーションの実行に必要な共通機能を提供
  • WebSphere Application server
• 統合運用管理
  • システム内のサーバやNWを監視する機能を提供
  • JP1, HP OpenView

フレームワーク：ドメインに対応した再利用性の高いアプリケーション(AP)の枠組み

• 問題（アプリケーション）ドメイン：特定ビジネスや組み込みなど
  • Salesforce アプリケーションフレームワーク
• 解決（ソリューション）ドメイン
  • Webアプリケーション(Ruby on Rails, Spring framework), GUI(Qt)
• ホットスポット：個々のAPに応じてカスタマイズする部分
  • 抽象クラスのサブクラスに記述する属性・メソッドとしてコンポーネントをはめこむ．
• フローズンスポット：フレームワークに組み込まれており変更できない部分

プログラミング

プログラミング工程の目的:

• 設計工程で小さく分割されたモジュール仕様をコンピュータ入力可能な表現に変換すること
• コーディングだけでなく単体テストを行ってモジュールとしての正常動作を確認するところまでがプログラミング

構造化プログラミング(STRUCTURED PROGRAMMING)

構造化プログラミングの導入背景:

• 大規模ソフト開発の問題
  • 生産物の規模が増加し，複雑になると，バグが見つけにくくなる，影響範囲が分からなくなる
  • 開発担当者間のコミュニケーション不足

誰が読んでも「分かりやすい」プログラムが必要（信頼性が高く，保守も容易）

1968年~1971年ダイクストラ(Dijkstra)やヴィルト(Wirth)らが構造化プログラミングを提唱

構造化プログラミングとはプログラムを構造的に書く上での指針（考え方）

• 制御構造 (control structure)
  • GOTO文を際限なく使うとスパゲティプログラムになるので避けよう
  • 逐次，選択，反復の3種類のブロック（=構造を組み立てる要素）で構成すると，ブロックの入り口と出口が一つになり，上から下に読めるから読みやすい
• データ構造 (data structure)
  • 全てのデータを一次元的に並べるだけだと解析しづらいので避けよう
  • 配列，構造体を使って構成する
• 段階的詳細化（stepwise refinement）
  • いきなり細かい処理の記述をせずに，プログラムの処理概要から段階的に詳細化していこう

構造化定理 (structured program theorem)

どのような制御を持つプログラムでも，逐次（順次，順接），選択（分岐），反復の三つの基本構造の組み合わせで表すことができる

GOTO文不要論

ダイクストラ(Dijkstra)は，goto文をむやみやたらと使うと，分かりにくいプログラムになるので，なるべく使わないようにしよう！

• goto文を使っても良い場合もある
• 最近の高級言語にはtry-except, continue, breakなどの構文があるためgoto使う場面は減少

コーディング規約 (CODING STANDARD)

目的:

可読性や保守性を高める

規約の概要:

• 変数や関数の命名規則
  • 分かり易い名前にする
  • キャメルケース(getFileName())，スネークケース(get_file_name())
• コーディングの規則
  • コメントの記載内容
  • 空白文字，インデント，改行の入れ方
• 禁止事項
  • 大域変数やgoto文の禁止
• その他
  • 著作権表記

ソフトウェア開発ツール

統合開発環境(IDE; Integrated Development Environment): ソフトウェア開発を支援するツール（道具）を連携させて実行するソフトウェア開発環境

• プロダクトを閲覧・編集するツール
  • エディタ: ソースコードを編集
• プロダクトを解析・検査するツール
  • デバッガ: プログラムの一部だけを実行させたり，特定の変数の変化を追跡
    • eg. gdb, valgrind
  • 性能解析ツール（プロファイラ）: プログラムの実行を通して情報を収集することでプログラムの性能を解析するためのツール
    • 実行時間やメモリ使用量を最適化するために，どの関数でどのくらいの処理時間，メモリを消費しているかの情報を収集する
• プロダクトを変換するツール
  • コンパイラ: ソースコードをコンピュータで実行可能な実行コードに変換
    • eg. gcc, g++, cl
  • 文書生成ツール: ソースコードからモジュール仕様書を自動生成するツール
    • eg. Javadoc, Doxygen
• プロダクト群を管理するツール
  • バージョン管理ツール: コンピュータ上で複数の人で作成・編集されるファイルの変更履歴を管理するためのツール
    • 任意の時点におけるファイルやディレクトリの内容を「リポジトリ」と呼ばれるデータベースに記録
    • 過去の状態や変更内容を確認できる
    • 変更前の状態に復元できる
    • 別の人が同時に一つのファイルを編集して問題が起きないように制御する（ロックをかける）
  • git, Subversion, RCS, CVSなどが用いられている

プログラミング言語の種類

低水準言語

• 機械語: CPUが直接解釈・実行できるデータ
• アセンブリ言語: 機械語と1対1に対応するニモニック(Mnemonic)と呼ばれる人が解釈・記憶しやすい英単語や記号を用いてプログラムを記述する言語
• アセンブラ: アセンブリ言語を機械語に変換するプログラム

高水準言語(プログラミングパラダイム)

プログラミングパラダイム: プログラムの論理，制御，データ構造の捉え方や表現の仕方

代表的な分類:

• – 手続き型プログラミング: コンピュータの処理手順を命令文で記述する
  • eg. FORTRAN, COBOL, BASIC, PASCAL, C, Ada, Java
• 関数型プログラミング: 複数の関数の組み合わせ（合成）によって処理を記述する
  • eg. Lisp, Scheme, Haskell
• 論理型プログラミング: 入出力関係を述語論理（事実と規則）で記述する
  • eg. Prolog

ドメイン特化言語

• SQL: データベース検索
• R, matlab: データ解析
• PHP, CSS, HTML: Web向け

スクリプト言語

スクリプト言語: アプリケーションソフトウェアの動作内容を、台本（スクリプト）のように記述し制御するための簡易的なプログラミング言語

• GUIのプロトタイピングや，データ解析など，ソフトウェア部品を組み合わせて，比較的小規模のプログラムを作成する場合に良く使われる
• （基本的には）ソースコードが開示されるので，有償の商用ソフトウェアでの利用は少ない
• eg. Python, Ruby, Perl, Tcl, JavaScript

テスト

ソフトウェアの品質管理

欠陥はなるべく早期に除去するのが鉄則（品質は上流工程で作り込む）

• 後工程になればなるほど修正に多大なコストがかかる
  • システムテストの過程で設計書にバグを発見した場合，内部設計書，ソースコードの修正が発生するだけでなく，テストのやり直しが必要

ソフトウェアの品質向上に向けた活動:

ソフトウェアテスト

テストに対する考え方

人間は必ずミスをするから，欠陥が全く無いプログラムはない

プログラムが正しいことを確かめるのではなく，欠陥を見つけるためにテストを行う

テストのプロセス

テストの種類

• 単体テスト(unit test): モジュールレベルで入力に対して期待する結果が得られるかをテストする（関数やクラスの単位）
• 結合テスト(integration test): コンポーネント間の相互作用をテストする
• システムテスト(system test): システム全体の振る舞いをテストする．非機能要求（性能，効率，信頼性，セキュリティ，ユーザビリティなど）

単体テスト

単体テストの分類:

• ホワイトボックステスト: ソフトウェアの内部仕様やプログラムコードに基づいてテストを行う
  • 内部設計書, ソースコード
• ブラックボックステスト: ソフトウェアの外部仕様，すなわち入出力の振る舞いだけに基づいてテストを行う
  • 外部設計書, 要求定義書

テストケース：入力データと期待される出力結果の組のこと

しかし、すべての入力パターンをテストできないため、入力パターンを減らす必要がある

制御パステスト法：ソースコードの制御パスを網羅的に実行するようテストケースを作成する

ソースコードの網羅性（カバレッジ）

単体テストのやり方

ドライバ：必要な引数を設定してテスト対象モジュールを呼び出すテスト用ツール

スタブ(stub)：テスト対象モジュールから呼び出されるダミーモジュールで，再び制御を対象モジュールに返す

テスト実行を自動化するxUnit

単体テストを自動化するフレームワーク(CppUnit, jUnitなど)

ルールに従ってテスト用プログラムを書いておくと単体テストが自動化できる

プログラムを修正した後の回帰テストで威力を発揮

決定表(decision table)

決定表(decision table): 条件の組み合わせに対する各アクションの可否を真理値で示す表

同値分割法

同値分割：入力データの値集合を，プログラムの振る舞いに対する影響が同じとみなせるものは同じ部分集合に分割する

• 有効同値：有効な入力データの値の集合
• 無効同値：無効な（エラーとして扱う）入力データの値の集合

部分集合の特定要素を代表値として，テストケースを作成する方法

境界値分析法

境界値分析法: 同値分割の境界値を使ってテストケースを作成する方法

同値分割とセットで使われる

課題10.1

課題10.2

課題10.3

• 回帰テスト
  • 開発中のソフトウェアにバグが見つかったので，一部のモジュールを変更しバグを除去した．変更箇所が正しく変更されていることを確認した上で，変更していない元のソフトウェアに意図しない影響を与えていないこと，副作用としてバグを作り込んでいないことを確認した
• ストレステスト
  • メモリー不足の状況では適切にエラーメッセージを出力して停止することを確認した
  • 24時間，連続運転をする運用に耐えうることを確認した
• ユーザビリティテスト
  • 数名のユーザにソフトウェアを試用してもらい，使い勝手についてアンケートに答えてもらった
• アドホックテスト
  • 開発者以外のソフトウェア技術者に，テスト仕様書を作成しないで，ソフトウェアをランダムに操作してもらった
• パフォーマンステスト
  • サーバ処理のレスポンスタイムを測定し要求性能を満たすことを確認した

結合テスト

結合テスト項目表

設計仕様書に記載された仕様どおりにプログラムが動作することを確認

状態遷移テスト

状態遷移テスト：状態遷移マトリックスのとおりにソフトウェアが動作しているかチェック

その他のテスト技法:

アドホックテスト: やみくもにテストする．アドリブテスト，ランダムテスト，モンキーテストなどと呼ばれる

システムテスト

• パフォーマンステスト(performance test)：応答時間や処理時間が要求どおりかテストする
• ストレステスト(stress test)：長期間の運用やメモリ不足の状況でも問題が起きないかテストする
• ユーザビリティテスト(usability test)：ユーザにとっての使いやすさ，習得の容易性を確認する

回帰テスト

回帰テスト(regression test): テスト済みのソフトウェアに変更が加えられたとき，変更箇所が正しく変更されていることと変更していない元のソフトウェアに意図しない影響を及ぼしていないこと（サイドエフェクトバグ，デグレード）を検証・確認すること

信頼度成長曲線

信頼度成長曲線：テストの進捗（時間経過）を横軸に，検出したバグの数を縦軸にしたグラフ（バグ管理図，バグ曲線などとも呼ぶ）

• テストを終了して良いかの判定に用いる

信頼度成長曲線の解釈

欠陥分析

欠陥分析：欠陥の数をカウントするだけでなく，欠陥の発生箇所や要因を分析することが重要

類似した欠陥の除去や，今後のプロセス改善（再発防止），品質向上の手がかりとなる

• 修正箇所，修正内容 $\Leftarrow$ 類似バグは他にないか？
• 欠陥混入工程 $\Leftarrow$ どこで除去すべきバグだったか？
  • 要求定義，設計，プログラミング，テスト
• 欠陥原因 $\Leftarrow$ 今後どんな対策を行えばよいか？
  • 設計，インタフェース，データ定義，論理，データ処理
• 重要度
  • 極めて重要，重要，普通

レビュー

レビューの代表的な方法：

その他のレビュー手法:

• ピアレビュー：同僚(peer)によるレビュー
  • ウォークスルー，インスペクションはピアレビューの一種
• ペアプログラミング: エクストリームプログラミング（XP）の実践項目の一つ
  • 2人で1台のコンピュータを使い共同でプログラムを作成する
  • レビューの一種

ソフトウェア品質特性

• 国際標準規格ISO 9126(ISO/IEC 25010, JIS X 25010)による品質モデル
• 開発後の品質評価だけでなく，非機能要求を定義する際に利用

機能性(functionality)

要求された機能を正しく果たすこと

• 適切性(suitability)：ソフトウェアが適用される業務・作業の目的に応じた適切な機能を提供すること
• 正確性(accuracy)/正当性(correctness)：機能が正しく満足できる結果・効果をあらわすこと
• 相互運用性(interoperability)：システムの他の部分（人を含む）とうまく相互作用できること
• セキュリティ(security)：ソフトウェアに対する偶発的または故意による不当なアクセスを排除すること
• 適合性(compliance)：果たす機能が法規や規格を遵守していること

信頼性(reliability)

正常に稼働すること

• 成熟性(maturity)：動作不良を起こす頻度が低いこと
  • MTBF(mean time between failure)が長いこと
  • 稼働実績が長く潜在的な故障原因が取り除かれた，いわゆる「枯れた」ソフトウェアは成熟性が高い
• 障害許容性(fault tolerance)：障害が起きても完全な機能不全とはならず，ある程度満足できる動作を維持できること（フェイルソフト）．障害発生時にはより安全な動作に倒すこと（フェイルセイフ）もある．
• 回復性(recoverability)：動作不良からの回復が早いこと
  • MTTR(mean time to repair)が短いこと
• 適合性(compliance)：達成すべき信頼性が法規や規格を遵守していること

使用性(usability)

使いやすいこと

• 理解性(understandability)：利用者にとってソフトウェアの果たす役割と適用のしかたが分かり易いこと
• 習得性(learnability)：使い方が習得しやすいこと
• 操作性(operability)：ユーザインタフェースが扱い易いこと
• 魅力性(attractiveness)：利用者の嗜好にあわせられるようなユーザインタフェース(look and feel)であること
• 適合性(compliance)：使用性が法規や規格を遵守していること．GUIガイドラインなど

効率性(efficiency)

動作が速く，無駄がないこと．性能(performance)ともいえる

• 時間効率性(time behavior)：応答時間や処理時間が速いこと
• 資源効率性(resource behavior)：余計なメモリ・ディスク容量を使ったり，ネットワークを占有したりしないこと
• 適合性(compliance)：達成すべき性能が法規や規格を遵守していること

保守性(maintenability)

障害発生や要求・環境の変化に応じたソフトウェアの改訂を行いやすいこと

• 解析性(analyzability)：動作不良の原因や改訂すべき箇所が識別しやすいこと（ログ出力など）
• 可変性(changeability)：目的とする改良・改訂のための変更作業が容易であること
• 安定性(stability)：変更が目的とする改良・改訂以外に予期せぬ影響を及ぼさないこと
• 試験容易性(testability)：変更の妥当性が確認しやすいこと
• 適合性(compliance)：保守性が法規や規格を遵守していること

可搬性(portability)

ソフトウェアを他の（組織的，ハードウェア的，ソフトウェア的）環境に移しやすいこと．移植性ともいう

• 順応性(adaptability)：異なる環境での稼働性をあらかじめ備えること
• 設置性(installability)：インストールしやすいこと
• 共存性(co-existence)：他のソフトウェアと同じ環境で同時に稼働できること
• 置換性(replaceability)：同じ目的をもつ他のソフトウェアの代わりに使える可能性を持つこと
• 適合性(compliance)：移植性が法規や規格を遵守していること．OSやシステムソフトとの適合性

利用品質

利用者が製品を使うにあたっての品質(quality in use)

• 有効性(effectiveness)：業務に役立っていること
• 生産性(productivity)：業務の生産性向上に役立っていること
• 安全性(safety)：利用者の業務や資源にマイナスの効果を及ぼさないこと
• 満足性(satisfaction)：このソフトウェアの導入によって満足が得られていること

プロダクトとプロセスの管理

プロジェクト管理の概要

プロジェクト管理(project management)：開発保守のプロセス（=工程，作業手順）が定められた目的，方針，規程に従って実行されることを確実にするための活動

プロジェクトとは独自の成果物、サービスを創造するための期限のある活動
定常業務とは期限を定めることなく継続して行う活動

PMBOK

PMBOK(project management body of knowledge): プロジェクトマネジメント協会(PMI)が発行する、「プロジェクトマネジメント知識体系ガイド」

PMP(Project Management Professional)：PMIが認定しているプロジェクトマネジメントの国際資格

PMBOK 9つの知識エリア

• 統合管理: プロジェクト計画の策定，実施，変更管理
• スコープ管理: スコープ（プロジェクトで実施される作業やプロジェクトの成果物）に関する定義，検証，変更管理
• 時間管理: スケジュールの作成，作業順序の決定，所要時間の見積もり，進捗管理
• コスト管理: リソース計画，コストの見積もりと予算化
• 品質管理: 品質（信頼性，使用性，保守性など）の評価と保証
• 人材管理: 組織構成，開発要員の調達，チーム編成や育成
• コミュニケーション管理: 情報の共有化，コミュニケーションの確立，実績報告
• リスク管理: リスクの洗い出し，リスクの定量化，リスク対策
• 調達管理: 機器の調達，発注先の選定，契約

時間管理（タイムマネジメント）

時間管理（タイムマネジメント）目的：プロジェクトを所定の時期に完了させること

ガントチャート(Gantt chart)：プロジェクトを管理するために、作業項目を木構造で階層を表示し、全体の作業の流れおよび進捗状況を表したもの

作業分解構造: WBS

WBS(work breakdown structure): プロジェクトを作業項目（タスク）に分解

ガントチャート作成

• 作業項目（タスク）ごとに担当者と期間（見積もり）を割り当てていき，スケジュールを作成
  • マイルストン（▲）：作業項目の節目となるイベント

PERT図

PERT図(program evaluation and review technique): 作業項目（タスク）の時間的な前後関係をネットワークとして表現

• 節点（ノード）：開始イベント，終了イベント
• 矢印：タスクとその所要時間

PERT図の作成方法:

1. WBSの作成
2. タスクの所要時間を見積もる
3. タスクの順序関係を設定する
4. PERT図（アローダイアグラム）を作成する
5. 最短所要時間を算出する
6. 重点作業項目の洗い出し

課題11.1

タスクリストの作成

gantt
    title Gantt Diagram
    %% this is a comment
    dateFormat  YYYY-MM-DD
    section タスク
    日程候補リストアップ                      :a1, 01-01, 2d
    行き先候補リストアップ                    :a2, 01-01, 2d
    メンバにアンケートをとる                   :a3, after a1  , 4d
    アンケートに基づいて日程・行き先を決定      :a4, after a3  , 1d
    宿泊候補リストアップ                       :a5, after a4  , 2d
    宿泊場所決定                              :a6, after a5  , 3d
    交通手段を予約                            :a7, after a6  , 1d
    旅費見積を作成                            :a8, after a7  , 3d
    メンバから旅費を集金                       :a9, after a6  , 7d
    宿泊費を前払いする                         :a10, after a9  , 1d
    旅行にいく                                :a11, after a10  , 5d

進捗管理

進捗管理：プロセスの実行（実働）が計画に沿っているかを監視（モニタリング）し，計画からのずれが小さくなるよう制御すること

• 90%完了症候群：進捗を定量的に報告できるようにする

ソフトウェア工数見積もり

ボトムアップ法：分解した要素を積み上げる. タスク分解し, それぞれの工数を積み上げる方法

トップダウン法(KKD法)：プロジェクトの特性，作業内容が類似している過去のプロジェクトから類推する

係数モデル見積もり: 開発規模にプロダクト・プロセスの性質（難易度，要求される品質など）や開発チームの能力などを係数として反映させた数式に基づいて見積もる

代表的な例：COCOMO (COnstructive COst MOdel)

• Boehmが開発したソースコード行数(SLOC)による手法(1981)
• アセンブラやCOBOLでの開発向き

開発工数（人月） $= 3.0 * (KSLOC)^{1.12} *$ 調整係数

ソースコード行数SLOC(source lines of code): コメント行は除いたソースコードの行数．LOC, ステップ数とも呼ばれる．測定が容易なので規模を把握するためによく用いられる．

• ステップカウンタと呼ばれるツールを使う

1
2
3
4
5
6

// コメント行や括弧のみの行を除いてカウントするので，SLOCは3行
int s = 0;
for(int i = 1; i <= n; i++)
{
  s += i;
}

ソフトウェアメトリックス

• ソースコード行数, LOC(lines of code), SLOC(source lines of code)
• サイクロマティック複雑度(cyclomatic complexity): モジュールの複雑さを表す指標(MaCabe指標).制御フロー図のエッジに囲まれた閉領域の数に対応する
  • $e - n + 2p$(n: ノード数，e: エッジ数, p: 独立成分数)
• C&Kメトリクス：オブジェクト指向設計における複雑さの指標

• 穴がたくさんあると複雑になり、プログラムのバグが生じやすい

サイクロマティック複雑度の解釈

プロセスの評価と改善

CMMI(capability maturity model integration): ソフトウェア開発能力に関する成熟度モデル

• ソフトウェアの生産性と品質を高めるには，プロセスが重要

構成管理

計画どおりにプロジェクトが進むことは希で，多くの変更(仕様変更，メンバー変更，スケジュール変更，成果物変更(構成管理))を余儀なくされる

特に，プロジェクトスコープの変更は，コスト，期間，スケジュールに大きな影響を及ぼす

• 変更管理委員会: 顧客を含めたチーム全体で変更に伴う影響範囲を慎重に検討する

構成管理: コンポーネント（物理的にはファイル）の存在と相互の構成関係およびそれらの変遷（バージョン）を認識すること

構成管理対象物: ソースコード, 仕様書, 設計書, テスト仕様書, マニュアル, 付加情報

バージョンとリビジョン

• バージョン：OSやハードウェアなど環境の違いに対応したり，機能や性能，UIなどの違いを並存させるために枝分かれするもの
  • Windows版，Mac版
  • Office 2013
• リビジョン：修正や拡張により以前のバージョンに置き換わるもの
  • iOS8.4

ファンクションポイント法

ファンクションポイント法(FP法)：ソフトウェアに含まれる機能の数（ファンクションポイント）により，ソフトウェアの規模を測定する手法

1970年後半 IBMのAllan J. Albrechtが提唱．IFPUG(International Function Point User Group)によって計測方法の標準化が行われていて, 要求仕様（外部仕様）と一部の概念設計がかたまった段階で使える手法

ファンクションの計測

データファンクション: 内部論理ファイル(ILF) + 外部インタフェーファイル(EIF)

• データファンクションの複雑度を判定するために，ファイルのデータエレメントタイプ(DET)とレコードエレメントタイプ(RET)を算出する
• ファイルの複雑度を求める
• 複雑度からファイルのFP値を求める

トランザクションファンクション: 外部入力(EI) + 外部出力(EO) + 外部照会(EQ)

• 要素処理の複雑度を判定するために，要素処理のデータエレメントタイプ(DET)とファイルタイプリファレンス(FTR)を数える
• 要素処理の複雑度を求める
  • EIにおける複雑度
  • EO, EQにおける複雑度
• 複雑度から要素処理のFP値を求める

Gantt diagrams

gantt
    title A Gantt Diagram
    %% this is a comment
    dateFormat  YYYY-MM-DD
    section Section
    A task           :a1, 2014-01-01, 30d
    Another task     :after a1  , 20d
    section Another
    Task in sec      :2014-01-12  , 12d
    another task      : 24d

gantt
       dateFormat                :YYYY-MM-DD
       title                     :Adding GANTT diagram functionality to mermaid
       section A section
       Completed task            :done,    des1, 2014-01-06,2014-01-08
       Active task               :active,  des2, 2014-01-09, 3d
       Future task               :         des3, after des2, 5d
       Future task2              :         des4, after des3, 5d

       section Critical tasks
       Completed task in the critical line :crit, done, 2014-01-06,24h
       Implement parser and jison          :crit, done, after des1, 2d
       Create tests for parser             :crit, active, 3d
       Future task in critical line        :crit, 5d
       Create tests for renderer           :2d
       Add to mermaid                      :1d

       section Documentation
       Describe gantt syntax               :active, a1, after des1, 3d
       Add gantt diagram to demo page      :after a1  , 20h
       Add another diagram to demo page    :doc1, after a1  , 48h

       section Last section
       Describe gantt syntax               :after doc1, 3d
       Add gantt diagram to demo page      :20h
       Add another diagram to demo page    :48h