ソフトウェア工学が扱う対象の基本的な構成要素は，プロダクト (product) とプロセス (process) です。
プロダク トとはエンジニアリングの過程で生成される中間製品や文書を含めたすべての生産物を指し、プロセスはプロダ クトを生み出す工程です。

これらの作業をスムーズに行えるようにするための各種の方法・手順・手段を纏めて、なんらかの原理や観点に基づいて統合した知的体系として定義されるのは、ソフトウェア開発方法論のことです。

開発技法

ソフトウェア開発技法は、ソフトウェアを開発する技術方法やテクニックのことです。 
以下の表でソフトウェア開発の局面別の技法を示します。

局面技法要求要求定義技法分析分析技法設計ソフトウェア設計技法実装プログラミング技法検証ソフトウェア検証技法 プロセスモデル

ソフトウェア開発プロセスは、ソフトウェアをどのように作り上げるかについて，手順や工程、成果物、進め方に関する基本的な考え方を定義したものです。ウォーターフォール型、反複型などが挙げられます。 
ソフトウェア開発プロセスは、ソフトウェア開発モデルと呼ばれることもあります。

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

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

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

工学の分類

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

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

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

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

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

情報システムとは

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

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

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

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

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

 ソフトウェアの品質  ソフトウェアの品質特性は大きく６つに分類され、それぞれの英語の頭文字をとってFRUEMP特性とも呼ばれています。
機能性
必要な機能を満たしているかということです。信頼性
指定された条件の下で正しく動くかということです。 使用性
使いやすさを表します。 効率性
スピードとサイズに関する性能です。 保守性
修正のしやすさです。移植性
実行する環境の移行のしやすさを表します。 プロジェクト管理

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

コンポーネントベース開発(Component-Based Development,CBD)とは、ソフトウェアを機能又はその他何かの単位で部品に分割し、得られたソフトウェア部品を組み合わせることによって開発を進めるソフトウェア開発方法です。

クラスライブラリやフレームワークに代表されるオブジェクト指向(OOA)が効果的な再利用を実現できなかったことから、 それらの研究を継承・発展させる形で登場してきたコンポーネント指向ソフトウェア開発は、以下のような効果をもたらすと期待されています。

開発効率性
既存のコンポーネントを再利用することで、 目的とするソフトウェアの開発期間を短縮し、 開発コストを削減することができます。適応性 
構成する個々のコンポーネントの置換・修正作業によって、ソフトウェア全体の要求仕様や運用環境の変化に対応することができます。信頼性 
信頼性の高いコンポーネントを組み合わせることで、 ソフトウェア全体について一定以上の信頼性が得られます。位置透過性 
インタフェースと実装の分離に基づき、コンポーネントを分散オブジェクトとすることで、 ネットワーク上におけるコンポーネント群の配備状況を意識する必要が減少されます。

本トピックは、まずコンポーネントの定義を明確にして、それからコンポーネント指向開発の説明を展開します。 

コンポーネントとは

コンポーネントというのは、部品、成分、構成要素などの意味をもつ英単語(Component)です。その意味で様々な分野で使われていますので、ITの分野では、システム・コンポーネントや、ハードウェア・コンポーネント、ソフトウェア・コンポーネン、ネットワーク・コンポーネントトといった場面があります。  ほかに意味の似た単語に「モジュール」(module)がありますが、違いとしては、「モジュールには、他の部品への接合部の仕様が標準化され、容易に追加や交換ができるような構成要素といった意味合いが込められることが多いのに対し、コンポーネントは単純に要素や部品一般のことを指すことが多い」とされています。。

ソフトウェア分野のコンポーネントとは、ある機能を実現するために部品化されたソフトウェア又はその構成要素のことで、ソフトウェア・コンポーネント(Software Component)の略です。

ソフトウェア分野で「モジュール」もよく使われますが、両者の違いとしては以下の見解が一般的です。

コンポーネント：それだけで完結した部品モジュール：粒度が少し高い部品を構成するための内部要素

規模の大きさではなく枠組みとしては「コンポーネント＞モジュール」の感じです。

コンポーネントの見方

コンポーネントには、実装部品とサービス部品の二つの見方があります、  前者は、GUI部品やEJBなどのプログラムに組み合わせて使うものを指し、後者は、業務機能やWebサービスなど必ずしも実装の実体とは限らないロジックプロセスの処理単位を指します。  下記の表にて各視点からふたつの見方の違いを説明します。

視点1:配置/ランタイム視点2:静的に/動的に視点3:物理/論理実装部品配置モデルのシステム構成要素静的なアーキテクチャモデルのシステム構成要素物理構成要素サービス部品ランタイムモデルのシステム構成要素動的なアーキテクチャモデルのシステム構成要素論理構成要素 コンポーネントの技術

コンポーネントの実装技術はいかのようなものがあげられます、カッコ内にあるのはそのコンポーネント技術を開発した会社又は組織の名称です。

OSGI组件模型J2EE组件模型(Sun Microsystems社、現在はOracle社)COM组件模型(Microsoft社)NWDI组件模型(SAP社)VCL(CLX)组件模型(Borland社、現在はMicro Focus社)

概要

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

モデリング手法

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

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

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

利点

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

欠点

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