自称週末ファーマーの国家試験受験記

自己啓発の延長なのか、自己実現の手段なのか、はたまた意地の張り合いか。生きているうちに“何か”を成し遂げたいから走り続けているような感じがする

第131話 経営情報システム22 ソフトウエア開発

今回から、ソフトウエア開発に入ります。改めてレビューして腑に落ちるところがあればいいけれど・・・。

ソフトウエア開発ってことは開発者側の視点で話を進めていこうとするわけだ。
つまりは、計画→実行(作成)→テスト→フォローみたいな感じになるのだろうか。各工程の中にいろんな手法があるんだろうけれど、なにせこのへんは素人だからなぁ。こころしてかかろう。
・・・などと考えていた。

スピテキを読んでみた。

1.ソフトウエア開発の手順
 利用者をユーザ、開発側をベンダと呼ぶらしい。
ソフトウエア開発は、大枠から小さい部分へ詳細化して詰めていく。だからユーザに対する要求を整理することが大事だという。ユーザ側とベンダ側との綿密な合意(要件定義)ができていないとユーザの考えていたものと完成品とに差異が生じることになりかねない。こういった基本計画から始めて、
基本計画→ソフトウエア設計→プログラミング→テスト→運用・保守 という手順を踏んでいく。

2.システム導入プロジェクト
 ユーザの要件定義を済ませた後で、ユーザの要望を満たすシステムが実現可能かどうかを評価する。これをフィジビリティスタディ(FS)という。「適合性評価」と訳され、システム化構想あるいはシステム化全体計画が実現可能なものかどうかを評価することになる。この結果に基づき、具体的なシステム導入のプロジェクト計画を作成する。
 システム導入の目的を明確化した上でプロジェクトを推進する。そしてプロジェクト組織が構成され、そこには発注者側の情報システム部門やエンドユーザの代表者、システムインテグレータなどが携わり、設計や開発等を行う。
 開発工程では、工程が進むにつれて対象が分割され、詳細化される。
外部設計→内部設計→プログラム設計→プログラミングといった具合だ。

3.開発モデル
 ここではシステム開発の大枠の流れを把握する。
1)ウォータフォールモデル
 計画→設計→プログラミング→テスト→運用と順に行っていくモデルである。大規模なソフトウエア開発に適したモデル。特徴は「前の工程に後戻りしない」ことである。

 ウォータフォールモデル → 大規模な開発向き。後戻りしない

(実際の現場では、後戻りする場合も考えられるんだろうけれど)後戻りしないため、プロジェクト(以下、PJ)管理がやりやすい。一方で、柔軟性に欠けるという欠点もある。

2)プロトタイプモデル
 試作品(プロトタイプ)を作成してユーザが評価するというプロトタイピングの技法を、主要な技術として位置づけたモデルである。開発者はユーザの要求をもとにプロトタイプを作成し、これをユーザとともに評価する。ユーザから改訂要求があればプロトタイプを修正する。このような試行錯誤を繰り返してユーザの満足するシステムを開発する。なお、比較的小規模な開発に限定されるなどの課題がある。

 ●プロトタイプ → 小規模な開発向き

3) スパイラルモデル
 システムを複数のサブシステムに分け、基本となるサブシステムをウォータフォールモデルの方法で開発してユーザに試用してもらい、その結果を反映させて次のサブシステムを開発するのを繰り返していくモデル。

4)RAD(Rapid Application Development)
 システムの設計、開発からテストに至る工程を、プロトタイピングやCASEツールなどの手法を用いてエンドユーザを含む少人数のチームで担当し、開発期間を短縮する手法。無制限に設計・開発・テストのサイクルを繰り返さないように、タイムボックスと呼ばれる一定の開発期間をあらかじめ設定しておく。

 ●RAD → タイムボックスと呼ばれる期間を設定

4.開発アプローチ
 システム開発においては、システム化の対象となる業務を分析する必要がある。この分析をどのような観点から行うかがアプローチ手法ということである。
1)POA:プロセス指向アプローチ
 Process Oriented Approach の略で、業務処理プロセスに着目するアプローチ方法。各業務処理が何を入力して、どのように加工し、何を出力するのかに注目して分析・設計を行い、システム化していく。
業務の流れをDFD(Data Flow Diagram)を使って表現する。このアプローチは、処理パターンが定型的な業務に向いている

 POA → 業務処理プロセス・DFD・定型的業務向き

2)DOA:データ指向アプローチ
 Data Oriented Approach の略で、どんなデータを必要とするかに着目するアプローチ方法。E-Rモデルを使って分析・設計していく。DOAは、DWHを使ったシステムや、対象業務が定型/非定型な場合にも有効。必要なデータは、業務や人によって異なるので、まずは誰が利用するのかを明確にすることがポイント。

 DOA → どんなデータが必要か・E-Rモデル

3)OOAオブジェクト指向アプローチ
 Object Oriented Approach の略。DOAPOAを併せ持つ方法。つまり、データと手続両方に着目して分析・設計していく方法。オブジェクトとは、データと手続を一体化したもの。UMLを使って分析・設計する。オブジェクト指向では、データと手続を一体化して捉えることで、開発現場の生産性向上を目的としている。

 OOA → データと手続を一体化(カプセル化)・UML

OOAに関連して、オブジェクト指向の概念を表す代表的な用語について確認しておきましょう。

カプセル化
 データと手続(メソッド)をオブジェクトとして一体化すること。
カプセル化された場合、データと手続が一体化しているので、オブジェクト外部から直接にデータを操作することは出来ない。
インヘリタンス(継承)
 オブジェクトの共通する性質を抽象化したものをクラスという。また、いくつかのクラスの共通部分を抽出して、新たなクラスを定義することを汎化という。インヘリタンスとは、上位クラスで定義したデータや手続を下位クラスでそのまま利用できることをいう。
ポリモルフィズム
 同じメッセージを送っても受け取るオブジェクトによって振る舞いが異なること。

ここまでで一区切りだからここでおしまい。

続く。