このトピックは準備中です。

概要

データ指向アプローチ(Data Oriented Approach)とは、業務で扱うデータの構造や流れに着目し、システム設計を行う手法であり、企業で扱うデータの統一的なデータベースを作り、一元化することで個々のシステム設計をシンプルにするというアプローチです。

モデリング手法

 DOAでは、まず業務で扱うデータ全体をERモデル(Entity-Relationship model)によってモデル化し、それを正規化してRDB(リレーショナルデータベース)を設計します。
個々のシステムはこのデータベースを中心に設計されます。

利点

DOAは、統一的なデータベースを中心にして各部署のシステムが設計されるため、データの整合性・一貫性が保たれ、システム間のやりとりが容易になります。
また、業務内容の変更によりシステム改変が必要になった時も、データベースの構成が定まっているため、POAよりも改変が容易になります。

欠点

DOAは、データとプログラムが切り離されているため、一度モデリングしたデータ構造を変更すると，関連するプログラムを特定するのが極めて難しいことです。
このため，システムの追加・修正の際にデータ構造を変更する必要があると，多大な手間と時間が掛かります。

概要

プロセス指向アプローチ(Process Oriented Approach,POA)は、データの「入力」、「加工」、「出力」という3つのまとまりから成る「処理」に重点を置いたアプローチです。
ただし、データを完全に無視しているわけではなく、POAでは、システムを構成する処理と処理の間をデータが通過していくと考え、データを処理の附属的な存在と捉えています。

モデリング手法

POAの代表的な表記法であるDFDは、構造化分析で有名なトム・デマルコ氏が提唱した表記法です。
DFDは「データの流れ図」という意味だが、実際にはシステムを構成する「処理」の構造に着目しています。

例えば、販売管理システムのDFDは、下記の図のように記述できます。

「顧客」というデータの発生源（源泉と呼ぶ）から生じた「注文」データが、「受注」→「在庫チェック」→「出荷」→「請求」という処理をたどって加工されながら流れていきます。
「受注」と「在庫チェック」という処理を実施するために、「顧客マスタ」と「商品マスタ」というファイル（データ）が参照されます。
ただしPOAでは、あくまでシステムの主役が「処理」であるため、これらのデータが一元管理されているわけではなく、システムごとに用意する必要があります。

利点

POAは、業務の手順や工程を図などに書き表して定義し、それに合わせてソフトウェアやシステムの挙動を決定していく。現実の手順に基いてシステムの動作を考えるため分かりやすく、設計工程を比較的容易に素早く進めることができます。

欠点

POAは、業務内容を中心に設計されるため、各部署の業務内容に応じて独立したシステムになることが多く、システム間のやりとりが複雑になるという問題点がありました
また、システムが業務内容に強く依存しているため、業務内容が変更になった時には、システムの大幅な改変が必要です。

ウォータフォールモデルは、古くから利用されているシステム開発モデルで、ほとんどの開発プロジェクトでこのモデルが使用されるほど広く普及していました。 
このモデルは、ソフトウェアの各開発工程を上流から下流まで段階的に区切りながら、流れ落ちる滝のように見立てています。

特徴

ウォータフォールモデルは、原則的に手前の工程に遡ることができないので、以下のような特徴をもっております。

• 開発工程を明確に区切って、各工程毎に厳密な確認と検証を行う
• 各工程の成果物を文書にきちんと纏めて、そのアウトプットを次の工程のインプットにする

利点

ウォータフォールモデルの利点は、管理と工数見積もりがやりやすいところです。

• 開発管理がやりやすく、特に大規模なソフトウェア開発に適している
• 工数見積もりがやりやすい、特に人月ベースの契約受注プロジェクトに適している
• 業務コンサルタント、システムエンジニア、プログラマ、テスタによる分業体制が確立しているため、 参加者が担う役割は固定的で考える事が少ない
• 要員の調達が比較的に容易に行えるため、特に労働集約型ビジネスモデルに適している

欠点

ウォータフォールモデルの欠点は、コストが高く品質管理がしにくいところです。

• ソフトウェアの実物を見られるようになるまでの時間が長い
• 設計と設計の成果物の検証とも机上レベルでしかできず、品質が担保しにくい
• 問題の早期発見が難しく、遅れるほど解決のコストが大きくなる
• 価値が少ないドキュメント作成にもやたら工数がかかる

このためウォータフォールモデルを採用するほとんどの開発プロジェクトでは、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローするように工夫しております。

モデリングするには、モデリング言語を使用します。 
モデリング言語は、ルールの一貫したセットで定義された構造によって情報、知識あるいはシステムを表現するため使われるあらゆる人工言語のことです。

モデリング言語は図式またはテキスト形式であり得ます。

• 図式モデリング言語　
  図式モデリング言語は、概念を表す名前を持つシンボルと、そのシンボルを結合しその関係を表現するライン、及び制約を表現する様々な図式表記を持つダイアグラム技術を使います。
• テキスト形式モデリング言語　
  テキスト形式モデリング言語は通常、コンピュータが解釈可能な表現にするパラメータによって達成される標準化されたキーワードを使います。

モデリングを行う手法としては、分類や分割、階層化といった方法があります。これも人間が世界を認識するための基本手法です。

• 分類 
  分類とは、事物や現象を、何らかの基準に従って区分することによって体系づけることです。
  例えばある企業の人事システムでは、従業員を職位に従って、一般社員、係長、課長、部長、社長に分類することがあります。
• 分割 
  分割とは、複雑なものをより簡単な構成要素に分けることです。
  システムを複数のサブシステムに分けたり、業務を複数の機能に分けたりします。
• 階層化 
  階層化とは、システムを互いに独立している複数の階層に分けて分析、設計及び実装のことです。

モデリングとは、業務の流れやシステムの構成、といった、論理世界にしか存在しないものを可視化するための技法です。

モデリングは、記号を使ってモデルを作成することによって、問題点の洗い出しや理解の深まり、人間同士間の認識共有を図ります。  なお、業務やシステムを視点に分けてモデリングすることによって、複雑なものを単純化にして人間に理解しやすくすることができます。

人間同士の認識共有

ソフトウェアシステム開発に関わる人間は主に、ソフトウェアシステムを利用する「ユーザ」とソフトウェアを開発する「エンジニア」に大別することができますので、人間同士間の認識共有も、ユーザとエンジニア間の認識共有とエンジニア同士間の共有に分けることができます。

• ユーザとエンジニア間の認識共有
  ソフトウェア開発では、ビジネスによる要件とシステムによる実装の間には大きな溝があります。エンジニアが直接自分が欲しいと思うソフトウェアを書く場合は、そのようなことはないかもしれません。
  しかし、ソフトウェアのことを知らないユーザからの依頼によってソフトウェアの開発を行う場合には、当然この溝は非常に大きなものになります。 
  この溝を埋めるために用いる技術が「モデル」です。モデルを仲介して要件と実装の間の溝を埋めます。
• エンジニア同士間の認識共有
  ごく小さいソフトウェアは一人で作り上げることもあるかもしれませんが、殆どの場合はチーム合同の作業になります、なかでは何百人、何千人のエンジニアが同時に開発を行うプロジェクトも少なくありません。 
  そこで分析や設計、実装、テストなどの作業を別々の人に担当してもらうのは殆どですので、モデルを通じて、エンジニア同士間の認識共有を図ります。

複雑なものを単純化

業務やシステムは複雑で，そのまま理解することは通常、人間にとっては難しいものです。  着目する視点を分けてモデリングすることによって、業務やシステムを単純化し，理解しやすくします。ただし，業務やシステム自体が単純になったわけではなく，単に着目する部分を絞っているだけです。

モデルは、図や表等でものごとを単純化して表現したものであり、以下のように様々な視点から分類することができます。

• 言語・表記法
• 対象
• 領域・局面
• 静的か動的か
• 論理か物理か

本トピックでは、各視点からのモデルの分類をそれぞれ説明します。

言語・表記法による分類

モデリング技法は、その仕様や成果物を言語・表記法としてまとめて公開されます。  以下によく使用されているモデリング言語・表記法を取り上げます。

モデリング技法は、基本的に形式化されたシステム言語を使用してモデルを記述しますが、UMLのユースケースのように自然言語で記述されるモデルもあります。

対象による分類

モデリング対象によって、モデルを以下のように分類することができます。

領域・局面による分類

モデルの種類としては、「問題領域(problem domain)」モデルと「解決領域(solution domain)」モデルの二つに大別することができます。

• 問題領域モデル　
  「何(what)」をするのかをモデル化したものです。
• 解決領域モデル 
  その「何」をどう実現するのかをモデルしたものです

問題領域モデルと解決領域モデルは、目的に応じてさらに細分化されます。

• ドメイン分析モデル 
  現実世界をモデリングしたモデルです。
• 要求分析モデル 
  やりたいことをモデリングしたモデルです。
• システム分析モデル 
  プログラミング言語や実行環境といった実現方法に依存しない、ITシステムとして本質的なレベルでの解決方法をモデリングしたモデルです。
• 設計モデル 
  プログラミング言語や実行環境を前提に具体的な実現方法をモデリングしたモデルです。
• 実装モデル 
  プログラミング言語などによる実装を指します。

静的か動的かによる分類

モデルを静的モデルと動的モデルに分類することができます。

• 静的モデル 
  静的な構造に関するモデルです。
• 動的モデル 
  動的挙動に関するモデルです。

論理か物理かによる分類

モデルを論理モデルと物理モデルに分類することができます。

• 論理モデル 
  概念上のモデルやプログラム内に存在するオブジェクトに対するモデルです。
• 物理モデル 
  ファイルやノードなど具体的に扱うことができるリソースに対するモデルです。

コンピュータを構成する回路や装置などの物理的実体をハードウェア(Hardware)と呼ぶのに対し、ソフトウェア(Software）とは、そのハードウェアの上で動作して何らかの処理を行うプログラムのことです。

ソフトウェアにはさまざまな分類方法があります。

レイヤから分類

• 基本ソフトウェア 
  ハードウェアの基本的な制御を行い、ハードウェアの資源を有効活用するとともに、多くのソフトウェアが共通して利用する基本的な機能などを実装して、システム全体を管理するソフトウェアです。
  主にOSのことを指しており、例えば、Windows、Unix、Linux、Android、iOSなどがあります。
• ミドルウェア 
  基本ソフトウェアと応用ソフトウェアの中間に位置し、OSの上に動作して応用ソフトウェアに対してOSよりも高度で具体的な機能を提供します。
  データベース管理システム(Oracle、SQLServer…)、アプリケーションサーバ(Websphere、Webogic…)などがあります。
• 応用ソフトウェア 
  ユーザの利用目的に応じて作られたソフトウェアであり、アプリケーションソフトウェアとも呼ばれます。
  Officeや会計ソフト、グループウエアなどがあります。

役割にようる分類

• 基盤ソフトウェア 
  企業などのソフトウェアシステムをサポートするために必要な共通機能を提供するものです。
  例えば、OS、データベース、メールサーバ、ネットワーク管理、セキュリティ管理などがあります。
• ユーティリティーソフトウェア 
  コンピュータ上で機能する、補助的な機能を提供するソフトウェアであり、ツールソフトウェアや単にユーティリティーとも呼ばれます。
  ファイルエディタや圧縮ツール、画像編集ツールなどがあります。
• 情報処理ソフトウェア 
  情報システムを構成するソフトウェアです。
• 組込ソフトウェア 
  産業機器や家電製品などに内蔵され、特定の機能を実現するための組み込みシステムで動作するソフトウェアです。
• ゲームソフトウェア 
  コンピュータゲームのソフトウェアのことです。
• …

ビジネス形態による分類

• 市販ソフトウェア 
  ソフトウェア開発に携わっている企業および会社が有料で販売しているソフトウェアです。一般販売しているため、OSやOfficeといった、広く利用できる汎用的なものが多い。 
  販売形態については、昔から主流だったパッケージ販売(量販店などの店頭で、記憶メディアに記録され、包装されたパッケージの状態で販売する）や、インターネットが普及してからのダウンロード販売、SaaS・クラウドが発展してからのサービス販売などがあります。
• 自社開発ソフトウェア 
  自社が使用するソフトウェアを自社で開発することです。
• オーダー生産ソフトウェア 
  自社が使用するソフトウェアの開発をベンダに委託することです。
• フリーソフトウェア 
  無料で提供されるソフトウェアであり、オンラインで配布されることが多い。
• シェアソフトウェア 
  無料な試用期間を設けて、試用期間後でも継続的な使用する場合は有償になるソフトウェアであり、フリーソフトウェアと同じ、オンラインで配布されることが多い

工学(Engineering)とは、主に数学、化学、物理をベースとする自然科学などの知識を応用して、実用的な技術発見や製品開発などを研究対象とする学問の総称です。
工学と対照的には、理学(Science)、医学(Medicine)、農学(Agriculture)などの分類があります。

工学の分類

工学には様々な分類がありますが、以下はその代表的な一部です。

• 建築工学
• 機械工学
• システム工学
• 情報工学
• 電子工学
• 鉄道工学
• コンピュータ工学

工学の共通点

工学の共通点としては、以下のような作業を共有していることです。

• モデリング 
  なにが問題で，どんなものを作るべきかを明確にするため、対象領域を分析して，モデル化する技術が重要です
• 仕様 
  工学はきちんとした仕様を明確しなければなりません
• 成果物 
  工学はなんらかの成果物を作成しています
• 設計 
  工学の核は設計技術です。
• 検証 
  成果物が仕様に満たしているかどうかを検証しなければなりません

ソフトウェア工学

ソフトウェア工学(Software Engineering)とは、ソフトウェア開発を研究対象とする工学で、ソフトウェアを効率的に設計、開発するための手法に関する学問、もしくはそのための技術のことをいいます。

情報システムとは

ソフトウェア業界の仕事は、情報システム開発が大半を占めているため、ここで情報システムのことを特別に取り上げて説明します。

情報システム(Information System)とは、情報を適切に保存・管理・流通するための仕組みやシステムのことです。言葉の意味からすれば、コンピュータを使わなければならないことはないですが、現代ではほとんどの場合、情報システムは「コンピュータ情報システム」の略として用いられています。

情報システムは、ハードウェア、ネットワーク、ソフトウェアを組み合わせて構成されたシステムであるため、ソフトウェアを含めているイメージですが、情報システム構築時は、構成要素のハードウェアは調達するものであり、開発する必要なのはソフトウェア部分のみですので、情報システムの開発=情報システムにおけるソフトウェアシステム開発として、ソフトウェア工学の最も重要な一大分野になっております。

ソフトウェアのライフサイクル  

全てのソフトウェアにはライフサイクルがあります。
ほとんどの場合、ソフトウェアは、「企画」→「開発」→「運用」→「廃棄」からなるライフサイクルをたどると考えれ、ソフトウェア工学の研究対象は主にそのなかの「開発」になります。 ソフトウェアにはリニュアルやバージョンアップがよくあるものですが、ライフサイクルからみれば、新旧バージョンを別々のソフトウェアととらえることができます。 

 ソフトウェアの品質 

1. 機能性
   必要な機能を満たしているかということです。
2. 信頼性
   指定された条件の下で正しく動くかということです。 
3. 使用性
   使いやすさを表します。 
4. 効率性
   スピードとサイズに関する性能です。 
5. 保守性
   修正のしやすさです。
6. 移植性
   実行する環境の移行のしやすさを表します。

プロジェクト管理

ソフトウェアプロジェクト管理 (Software Project Management) は、ソフトウェアプロジェクトを計画し導く技術です。 
プロジェクト管理の一分野として、ソフトウェアを開発するための組織、チーム、個人のあり方、つまり人間の問題を取り扱うため、「もの」が取り扱う対象のソフトウェア工学の分野には分類されません。