スポンサードリンク
こんにちは、ももやまです。
今回からソフトウェアに関するお話しを少ししていきましょう。
初回となる今回は、
- ソフトウェアの一生
- 様々なソフトウェアの開発工程
の2つについて説明していきます。
スポンサードリンク
１．ソフトウェアライフサイクル
(1) ソフトウェアの一生（ライフサイクル）を見てみよう
まずは、ソフトウェアの一生を見ていきましょう。
とは言ってもいきなりソフトウェアの話をされてもわかりにくいと思うので、お店の新メニューを作る流れで例えて説明していきましょう。
Step1. 企画プロセス
システムの導入を計画するプロセスです。
具体的には、経営事業の目的（目標）を達成するために必要なシステムの方針、およびシステムを実現するためのシステム化計画をたてます。
お店の新メニューを作る流れで例えると、どんな新メニューであれば人気が出るかを考えるのが企画プロセスです。
Step2. 要件定義プロセス
どんな機能が必要なのかを利害関係者*1から聞きだすプロセスです。
要件というと難しい言葉に聞こえるかもしれませんが、「システムに必要な条件」だと思ってもらえばOKです。
具体的に要件定義は、
- 利害関係者の識別
（どの工程でどの関係者が関わってくるのか） - 要件の識別
（要件を利害関係者からもれなく聞き出す） - 要件の評価
（2で聞き出した要件に矛盾点やあいまいな点がないかを確認） - 要件の合意
（3で見つかった矛盾点やあいまいな点を解決する方法を利害関係者に説明し、合意を得る）
の4ステップで行われます。
新メニューを作る流れの場合、新メニューの具体的な材料、レシピなどを他の人と一緒に考えるのが要件定義プロセスに該当します。
Step3. 開発プロセス
要件定義プロセスで合意を得た要件を踏まえて、実際にシステム・ソフトウェア製品を開発していきます。
新メニューを作る流れの場合、実際に料理を作るのが開発プロセスに該当します。
これはわかりやすいですね。
Step4. 運用プロセス
実際に開発プロセスで作成したシステム／ソフトウェアを運用します。
新メニューを作る流れだと実際にメニューに追加してお客さんに食べてもらうのが運用プロセスに該当します。
Step5. 保守プロセス
開発したシステム／ソフトウェアに、
- プログラムのバグ（欠陥）の修正
- システムの機能改善
- 仕様の変更
- 定期メンテナンス
を行うのが保守プロセスです。
新メニューを作る流れだとお客さんからの指摘を受けてレシピなどをリニューアルするのが保守プロセスに該当します。
なお、1度完成したソフトウェアは、
- システムの運用（Step4）
- システムのメンテナンス（Step5）
の2つをシステムを使わなくなるまでずっと繰り返します。
以上の5つのプロセスをまとめると、下の図が出来上がります。
スポンサードリンク
２．主なシステム開発手法
ここからは、主なシステム開発の手法、つまりシステム開発をしていくときの流れについてです。
とは言ってもいきなりシステムのお話をするのは少し難しいので、また料理に例えて説明していきます。
皆さんが料理を作るとき、大まかにですが
- 献立を考える
- 材料・レシピを用意
- 調理開始
- 味見
- 完成！
のようなある程度の流れがありますよね。
ですが、細かな流れというのは人それぞれによって少し異なりますね。
何かしらのシステムを開発するときも料理のときと同じく、
- 企画（案を考える）
- 要件定義（やり方を決める）
- 開発
- チェック
- 完成！
のある程度の流れがあるのですが、開発手法によって細かな流れが微妙に変わってきます。
第2章では、
- 主な開発手法の特徴
- その開発手法の長所・短所
について説明していきます。
(1) ウォーターフォールモデル（Watarfall Model）
(i) ウォーターフォールモデルとは
日本国内のシステム開発で最も使われるモデルです。
ウォーターフォールモデルの大きな特徴は
- それぞれの工程を順番に進めていく
- 工程が完了しない限り次の工程には進まない
の2点です*2。
ウォーターフォールモデルでの開発の流れを細かに書くと、
- 要件定義 [システム要件定義]（目標のシステムに向けて具体的にユーザーの要求を定義）
- 外部設計 [ソフトウェア要件定義]（システム利用者の立場から、ユーザーからの要件をもとにシステムの機能を決めていく）
- 内部設計 [ソフトウェア方式設計]（システム開発者側の立場から、外部設計の要件をシステム上でいかに効率よく動作させるか*3を考える）
- プログラム設計 [ソフトウェア詳細設計]（それぞれのプログラムの動作、処理の流れを詳細に考える）
- プログラミング [開発]（実際に開発する）
- 各種テスト*4
の6ステップです*5。
（細かくどんなことをするかは次回のPart02で説明します）
（プログラム設計は書かれていない参考書も多かったので上の図では省いています）
ちなみに、IT業界では上流工程・下流工程という言葉がよく出てきます。
実はこの上流・下流はウォーターフォールモデルから出てきた言葉なのです。
(ii) 長所・短所
ウォーターフォールモデルの長所と短所を見ていきましょう。
☆長所☆
- それぞれの工程を完了させてから次の工程に進むため、管理がしやすい
- 目標（成果物）が明確になる
☆短所☆
- 最終段階にならないと利用者側がシステムを確認することができないため、利用者の要求は十分に反映されない
（段階の後戻りは想定されてない） - 後工程になればなるほどしわ寄せが集中する
（前工程で時間を使いすぎると後工程で時間がなくなる）
イマイチ実感がわかないなと思った人は、料理をレシピの順番通りに作ることを想像してみましょう。
レシピの順番通りに作るので、順番に関しては余計な（効率よく料理を作るためにレシピの順番を入れ替えたりする）ことは考えなくてもよい点は長所です。
しかし、実際に味を確認するのは最終段階に入ってからなので、思った料理と違うと思った（言われた）場合でも後戻りするができないという点が短所となります。
(2) プロトタイピングモデル (Prototype Model)
(i) プロトタイピングモデルとは
プロトタイプモデルでは、開発の初期でいったん試作品（プロトタイプ）を作り、試作品を利用者に確認してもらい、利用者の要求を聞いてから要求に沿ったプログラムを作ります。
料理で例えると、いったん試食品を作り、食べる人の意見を聞いてから改めて料理を作っていくのがプロトタイプモデルです。
特に不確実性の高いシステムを作る場合は有効な方法となります。
(ii) 長所・短所
☆長所☆
- 利用者の要求を聞いてからシステムを作るため、段階の後戻りを防ぐことができる
（「あれは違う」、みたいなことが起こりにくい） - 開発の終盤で「あ、これ無理や」とはならない
☆短所☆
- 手間がかかる（大規模なシステム開発には向かない）
- 利用者の要求を聞く分、スケジュールの遅延が発生する可能性がある
また料理に例えてみましょう。
いったん試食品を作るので、試食品を食べた感想から「入れる材料、手順などを調整する」ことで思った通りの味にすることができるのが長所です。
しかし、試食品を作る分の手間が余計にかかってしまう点が短所となります。
(3) スパイラルモデル(Spiral Model)
スパイラルモデルとは、
- システムをいくつかのサブシステムに分解
- 分解したサブシステムごとに開発を進めていく
- 分割したシステムを徐々に拡大していくことで完成させていく
の特徴を持ったシステム開発方法で、
- ウォーターフォールモデル
- プロトタイピングモデル
の2つをいい所どりしたシステム開発手法です。
具体的には、
- サブシステムごとにテスト、利用者のチェックが入るので後戻りしてしまう可能性が低い
- 利用者の声が次のサブシステム開発にも反映される
などのメリットを得ることができます。
なお、具体的な処理手順としては、
- （1つ目の）サブシステムの設計→プログラミング→テスト
- （2つ目の）サブシステムの設計→プログラミング→テスト
- （3つ目の）サブシステムの設計→プログラミング→テスト
- 以後すべてのサブシステムが完成するまで繰り返す
のように行われます。
[☆余談☆]
渦を巻くようにして徐々にシステムが完成していくのでスパイラルモデルと名付けられています。（スパイラル＝渦巻上の）
(4) アジャイル (Agile)
より短い期間で迅速に開発を行う手法の総称をアジャイルと呼びます。
アジャイルの大きな特徴として、「短期間で動作するプログラムを開発する」作業を反復させ、利用者の要求に応えながらシステムを作成していきます。
XP (エクストリーム・プログラミング)
アジャイルの代表的の開発手法の1つにXP (eXtreme Programming) があります。
XPでは、既存手法よりもより柔軟性が高い開発を実現するためにいくかの方針が定められています。
代表的な6つの方針に、
- テスト駆動開発
（システムを実装する前に、まずテストを作り、テストに合格するように実装していく） - ペアプログラミング
（2人1組でプログラミングを行う。2人のうちの1人がコードを書き、もう1人がサポートしていく*6） - リファクタリング
（1回完成させたプログラムのコードを改善する。） - 継続的インテグレーション
（単体テストに合格したプログラムに対し、すぐに結合テストを行う*7） - ソースコードの共有
（作ったコードはチーム内全員で共有する） - YAGNI (You Aren't Going to Need It)
（必要ではない機能は一切実装しない。必要な機能のみを実装する）
があります。（上4つは特に重要！）
スポンサードリンク
３．練習問題
では、今回説明した内容を復習するために、基本情報の問題を3問ほど解いてみましょう。
練習1
ソフトウェアライフサイクルを、企画・要件定義・開発・運用・保守のプロセスに区分したとき，企画プロセスの目的はどれか。
[基本情報技術者平成25年春期 午前問64]
ア：新しい業務のあり方や運用をまとめた上で、業務上実現すべき要件を明らかにすること。
イ：事業の目的、目標を達成するために必要なシステムに関係する要求事項の集合とシステム化の方針、及びシステムを実現するための実施計画を得ること。
ウ：システムに関する要件について技術的に可能であるかどうかを検証し、システム設計が可能な技術要件に変換すること。
エ：システムの仕様を明確化し、それを基にIT化範囲とその機能を具体的に明示すること。
練習2
システム開発におけるウォータフォールモデルの説明はどれか。
[基本情報技術者平成21年春期 午前問45]
ア：一度の開発ですべてを作るのではなく、基本的なシステムアーキテクチャの上に機能の優先度に応じて段階的に開発する。
イ：開発工程を設計、実装、テストなどに分け、前の工程が完了してから、その成果物を使って次の工程を行う。
ウ：試作品を作り、利用者の要求をフィードバックして開発を進める。
エ：複雑なソフトウェアを全部最初から作成しようとするのではなく、簡単な部分から分析、設計、実装、テストを繰り返し行い、徐々に拡大していく。
練習3
XP(Extreme Programming)において、実践することが提唱されているものはどれか。
[基本情報技術者平成27年春期 午前問51]
ア：構造化設計
イ：テストツールの活用
ウ：ペアプログラミング
エ：ユースケースの活用
４．練習問題の答え
解答1
正解：イ
ア：新しい業務のあり方や運用をまとめた上で、業務上実現すべき要件を明らかにすること。
→ 要件定義プロセスに該当します。
イ：事業の目的、目標を達成するために必要なシステムに関係する要求事項の集合とシステム化の方針、及びシステムを実現するための実施計画を得ること。
→ 正解です。企画プロセスに該当します。
ウ：システムに関する要件について技術的に可能であるかどうかを検証し、システム設計が可能な技術要件に変換すること。
→ 要件定義プロセスに該当します。
エ：システムの仕様を明確化し、それを基にIT化範囲とその機能を具体的に明示すること。
→ 要件定義プロセスに該当します。
解答2
正解：イ
ア：一度の開発ですべてを作るのではなく、基本的なシステムアーキテクチャの上に機能の優先度に応じて段階的に開発する。
→ インクリメンタルモデルの説明です。（今回は説明していませんが…）
イ：開発工程を設計、実装、テストなどに分け、前の工程が完了してから、その成果物を使って次の工程を行う。
→ 正解です。ウォーターフォールモデルの特徴
- 前の工程が完成してから次の工程に進む
- 工程が完了しない限り次の工程には進まない
を抑えておきましょう。
ウ：試作品を作り、利用者の要求をフィードバックして開発を進める。
→ プロトタイプモデルの説明です。
エ：複雑なソフトウェアを全部最初から作成しようとするのではなく、簡単な部分から分析、設計、実装、テストを繰り返し行い、徐々に拡大していく。
→ スパイラルモデルの説明です。スパイラルモデルは、システムを簡単な部分に分解してから徐々に拡大していきます。
解答3
正解：ウ
XPの1つである「ペアプログラミング」は頻出なので必ず頭にいれておきましょう！
５．さいごに
今回は、ソフトウェア設計分野における
- ソフトウェアライフサイクル
- 開発工程
について説明しました。
まだIT企業などで実務経験をしたことがない人*8には少し難しいかもしれませんが、「ソフトウェアの開発工程」と「料理の調理工程」は似た部分も多いので、わからなければ料理で考えるのがおすすめです。
次回は、
- それぞれの開発工程で具体的にどんなことをするのか
- テストはどんなことをするのか
の2つの部分を説明していきたいと思います。
*1:顧客、取引先のことを指しています。なお厳密に説明すると、業務を行う上で影響を受ける関係者のことをいいます。別名「ステークホルダー」。
*2:ちなみにウォーターフォールモデルという名前は、それぞれの工程を「水が高いところから低いところへ落ちるように」順番に進めていくところから名づけられました。
*3:具体的には、外部設計で作成した機能をプログラム単位に分割することで処理の流れを明確にしたり、外部設計で作成したデータをファイルやデータベースに変換したりします。
*4:単体テスト、結合テスト、システムテストの順に行われます。テストの順番は作る時とは逆（下流→上流）というのを頭に入れておけばOKです。
*5:2, 3, 4の設計部分を1つにまとめて4ステップとして説明している参考書も多数あります。
*6:個人的にもペアプログラミングのやり方ってお勧め（1人のときよりもバグが見つけやすくなる）なので機会があればお友達と2人でペアプログラミングするのもいいでしょう。
*7:小さいテストに合格したら、すぐにより大きなテストを実施するということで、時間を短縮化します
*8:私もないのです…。
関連広告・スポンサードリンク
