これは

放送大学大学院文化科学研究科の「ソフトウェア工学」という授業で使われる「ソフトウェア工学」という教材書籍を自分なりにまとめたものです.

第 4 章では, 「ソフトウェアプロセス」について, その手法や評価基準について述べられていました.

  • ソフトウェア開発のプロセスについて
  • プロセスとプロダクトへの関心は時期によって交互訪れる
  • 軽快 (アジャイル) なプロセスが注目されている→プロダクトもプロセスも大事
  • ウォーターフォール型とアジャイル型
  • プロセスプログラミング (あまり研究は行われず, プロセスを何らかの形式に従って記述する重要性に目が向けられるようになった)
  • CMMI (ソフトウェア開発プロセスを 5 段階評価するもの)
  • SPIN (地域単位で組織されるプロセス改善活動ネットワーク)
  • ISO 9000, ISO 12207, ISO 9001, ISO 90003

尚, 本まとめについては, 以下の Github リポジトリで管理しており, 加筆修正はリポジトリのみ行います.

inokappa/software_engineering
software_engineering - 放送大学大学院文化科学研究科 / ソフトウェア工学
GitHub

github.com

4. ソフトウェアプロセス

はじめに

  • ソフトウェアを開発するプロセスを「ソフトウェアプロセス」と呼ぶ
  • プロセスの良し悪しによって, プロダクトの品質が左右されるので, ソフトウェアプロセスをいかに設計し構築するかは, 設計・構築に劣らず重要である

1. プロセスとプロダクト

(1) ライフサイクルモデル

  • 開発対象のプロダクトと, それを開発するプロセスとは, 車の両輪のような関係
  • 良いプロセスから良いプロダクトが生まれる
  • 落水型 (ウォーターフォール) のライフサイクルモデルがソフトウェアのプロセスモデルのはしり

(2) ソフトウェアプロセス研究の隆盛

  • 1980 年代後半から 1990 年代前半にかけて, ソフトウェアプロセスが改めて注目された
    • 1987 年 ICSE で Leon Osterweil が行った「ソフトウェアプロセスもソフトウェアである」というタイトルの基調講演
      • プログラムのコーディング, コンパイル, テスト, コーディングの繰り返しを手続きとして書くことが出来る
      • プロセスプログラミング
      • プロセスモデルやプロセス記述言語を開発する必要がある
    • 1987 年に提唱された, カーネギーメロン大学ソフトウェア工学研究所による Capability Maturity Model
      • ソフトウェア開発組織が実施している開発プロセスを 5 段階で評価する
      • 米国国防省が導入するソフトウェアの調達先の信頼度を評価する背景があった為, 米国のソフトウェア企業に対するインパクトは大きかった

(3) プロセスからアーキテクチャへ

  • ソフトウェアプロセスからソフトウェア・アーキテクチャへ
  • 1996 年に出版された, Mary Shaw と David Garlan 共著「ソフトウェア・アーキテクチャ」

(4) プロセスとプロダクトへの関心の交替

  • プロセスに関心が高まる時期と, プロダクトに関心が高まる時期とが交互に訪れる傾向がある
  • 2010 年代は, プロセスの関心が復活しつつある
  • XP (extreme programming) 等で採用されている軽快なプロセスが注目される等, プロセス復活の兆しはある
  • プロダクトも大事, プロセスも大事

2. ライフサイクルモデル

(1) ライフサイクルモデルの意味

  • ソフトウェアのライフサイクル
    • ソフトウェアの開発が計画されてから, 設計開発が実施され, 運用が始まり, その後, 保守や機能変更・拡張が繰り返され破棄されるまでの歩み
  • ライフサイクルモデルで重要なポイント
    • ライフサイクルを幾つかの段階 (フェーズ) に分けて, それらの前後関係を定める
    • 各フェーズの開始・終了条件と, その結果としての成果物 (文書, プログラム, テストケース等)の形式・内容の明確化
  • SLCP (ソフトウェアのライフサイクルプロセス)
    • 国際基準 ISO/IEC 12207:1995
    • 日本標準 JIS X 0160-1996
    • SLCP に基づいた「ソフトウェアを中心としたシステムの取引に関する共通フレーム」が IPA の下に設置された「システム開発取引の共通フレーム検討委員会」によって 1994 年に公表され, 2007 年に改訂版が出されている

1) 計画駆動型モデル
  • ライフサイクル全体を見通した計画をプロジェクト開始時に立てて, それに従ってなるべく手戻りがないようにプロセスを進めるモデル
  • 落水型がその代表

2) 軽快型モデル
  • 軽快 (agile) なプロセスとすることを第一義とするモデル
  • 文章よりコードに重点を奥
  • 小規模, 短期間な開発とユーザーへの引き渡しを繰り返し, 要求や周辺環境の変化に対応しやすいことを強調
  • 極端プログラミング (XP プログラミング)

(2) 計画駆動型モデル

1) 落水型
  • 落水 (waterfall) 型は, 最も早い時期に提唱されたライフサイクルモデル
  • 現在でも多くの開発組織が標準的な工程をこれに基づいている
  • 前のフェーズに戻るような手戻りが無いことが落水型と呼ばれる所以
  • 変形として, V 型の形状を持った V 型ライフサイクルモデルもある
  • ISO/IEC 12207 で既定されている多くのプロセスのうちの開発プロセスは, この V 型モデルが基本となっている

2) プロトタイピング型
  • 1980 年前後に提唱された
  • 落水型で最も困難で且つ重要なものが, 要求を抽出してそれを要求仕様としてまとめる分析フェーズ
  • 要求定義の問題点
    • 要求を関係者から適切に引き出すことが難しい
    • 要求の結果を曖昧さのない形で要求仕様として記述することが容易ではない
  • 実際に動くシステムを作る前に, ユーザーがシステムの動作を理解出来るようなユーザー・インターフェースを持ったプロトタイプを作成する
  • プロトタイプを利用することで, ユーザーは要求の誤解や不足に気付き, 開発者はプロトタイプに改良を加えることで要求の理解を深める
  • プロトタイプは通常は使い捨て, 本番のシステムはゼロから作り直す

3) らせん型
  • 落水型のように上流から下流に一気に推し進めるのではなく, 分析・設計から運用までのフェーズを何回かに分けて繰り返す
  • Barry Boehm のらせん型ライフサイクルモデルはよく知られている
  • リスクを制御しながら徐々にシステムを進化させていくプロセスである
  • サイクルの回数は 1 つのサイクルで残ったリスクの大きさによって判断する, というのが Boehm の主張である

(3) 軽快型モデル

  • 開発サイクルを 2 〜 4 週間と極端に短くしてサイクルが終わる度にユーザーに提供するライフサイクルモデルが軽快型の基本概念である
  • 軽快 (agile), ムダの無い (lean) プロセスという表現もある
  • 軽快宣言 (agile manifesto)
    • プロセスやツールより個人とその間の相互作用を重視
    • 文書よりもプログラムを重視
    • 顧客との契約交渉よりも共同作業を重視
    • 計画順守より変化に対応

1) 極端プログラミング (XP)
  • extream programming (XP) は Kent Beck 等によって提唱されたソフトウェア開発手法
  • 1 ~ 2 週間という短い期間を単位とした開発を反復する
  • 出来る限り簡素化した機能を順に開発していく
  • XP の開発手法としての特徴
    • テスト駆動開発
      • 開発に際して, 自動的に実行可能なテストを作成する
      • プログラムはそのテストが通るように作成していく
      • テストが実質的な仕様の役割を果たす
    • ペア・プログラミング
      • 二人一組の単位で開発を行う
      • 一人がコードを書き, もう一人がチェックしながら, 共同で作業する
    • 再構成 (refactoring)
      • 小さい単位で開発を重ねていくと, システム全体の構造が劣化する
      • 頻繁に再構成して, 機能は変わらないが内部構造が整い, 効率も優れたシステムに作り替えていく
    • スクラム
      • スプリントと呼ばれる一ヶ月単位のプロセスを繰り返すことで, プロジェクtおが構成されている
      • 開発チームは各スプリントの前に顧客と打ち合わせを行い, 仕事の優先順位を決め, それに基づいて次のスプリントで実施する開発内容を決定する
      • スクラムは要求が変化しやすい製品 (Web サービス等) の開発に向いている

3. プロセス記述

ソフトウェアのプロセスをどう構築するはという問題の鍵は, プロセスの記述の方法にある.

(1) プロセスプログラミング

  • プロセスをプログラムのように記述する
  • Osterweil が当初提案した方法は手続き型のプログラミング言語に準拠したものだったが, 関数型や論理型等の言語に基づいた記述方法が提案された
  • プロセスプログラミングの最終的な目標は, プロセスの自動化にあったとみることが出来る
  • ソフトウェアプロセスは人間の関与が大きな比重を占める為, プログラムのように自動化出来る部分は限定的
  • プロセスプログラミングの研究は, プロセスを中心とした開発環境構築に重点が移った
  • プロセスを何らかの形式に従って記述するこの重要性に目が向けられるようになった

(2) 規範型と観察型のプロセス記述

  • プロセス記述の二つの目的
    • 規範型
      • 準拠すべきプロセスを示す
      • プロジェクトの開始時に採用されるプロセスモデルは, システムの規模や特徴, 開発組織の特製等に応じて, 規範型プロセスか, それをカスタマイズしたものとすることが通常である
      • ISO/IEC 12207 (開発, 取得, 供給, 運用, 保守, 支援)
      • 支援プロセス (文書化プロセス, 構成管理プロセス,品質保証プロセス)
    • 観察型
      • 実際の開発組織で行われているプロセスを観察し, それを評価・改善するために記述するプロセス
      • プロセスを観察して分析する研究には, 文化人類学的なアプローチによるもの等が工夫されている

4. プロセス評価と改善

プロセス記述の目的の 1 つとして, プロセスの評価があるが, 評価を行うには, 評価基準が必要となる為, いくつかの評価基準が定められている.

(1) CMMI

  • 1987 年にカーネギーメロン大学ソフトウェア工学研究所が CMM (Capability Maturity Model) を発表
  • ソフトウェア開発プロセスを 5 段階で評価するもの
  • 国防総省等の政府が調達するシステムの納入業者をこの基準で選別するという意図があった
  • ハードウェアを含めたシステムを対象とするもの等の種類が別れたが, 現在では CMMI (Capability Maturity Model Intergration) という形に統合されている
  • CMMI
    • 開発用
    • サービス用
    • 調達用
  • 開発用 CMMI では, 22 のプロセス領域が定義されている
    • プロセス管理分野
    • プロジェクト管理分野
    • エンジニアリング分野
    • 支援分野
  • 各プロセス領域と開発組織のプロセス全体に対して, 5 段階の円熟度を評価する仕組みがある
    • レベル 1 初期 (Initial)
    • レベル 2 反復可能 (Repeatable)
    • レベル 3 既定義 (Defined)
    • レベル 4 管理下 (Managed)
    • レベル 5 最適化 (Optimizing)

(2) SPIN

  • SPIN (Software and Systems Process Improvenment Network)
  • 地域単位で組織されるプロセス改善の活動ネットワーク
  • 米国には 40 拠点, 米国外には約 40 ヶ国 80 拠点, 日本にも東京に拠点がある

(3) ISO 9000

  • ISO 12207 がソフトウェアプロセスに関する規格
  • ISO 9000 シリーズは品質管理, 品質保証のシステムに関する規格, この制度の基準文書は ISO 9001 である
  • ISO 9001 は一般の製品に対して, 二者間契約で製造供給される場合につき, その供給者が有すべき品質システムの要求事項を定めている
  • ISO 90003 は ISO 9001 をソフトウェアの開発/設計, 供給, 保守に適用する為の手引として作られた規格

参考リンク

元記事はこちら

「ソフトウェア工学 「第 4 章 ソフトウェアプロセス」のまとめ」