シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
今回は「１．３ ソフトウエアプロセスとは」です。
１．３ ソフトウエアプロセスとは
前回、ソフトウエア工学とは、
顧客の要望に応じたソフトウエアを上手に作るために、コンピューターサイエンスを基礎として、コンピューターを使いこなすソフトウエアを作るための工学
とまとめました。結局、ソフトウエアを作るための工学ということです。
では、ソフトウエアを作るためには、どうしたらよいのでしょうか？
１．１章で見たとおり、人間は、活動します。そして、この活動で、入力→処理→出力となるものを、アクティビティと呼びました。
ソフトウエアを作るためにも、活動します。エディタでプログラムを記述するとか、コンパイルするとか、コンピューターを立ち上げるとか・・・
そしてこれらの活動の一つ一つは、たとえば、コンパイルが
ソースコード→コンパイル→オブジェクト
となるように、入力→処理→出力というアクティビティになっています。
つまり、ソフトウエアを作成するためには、人々は、さまざまなアクティビティを行っているということになります。このアクティビティを実施することが、ソフトウエア開発ということになります。
しかし、ソフトウエア開発には、多種多様なアクティビティがあるため、これをばらばらに扱うと、管理や計画が立てられなくなってしまいます。
そこで、アクティビティを、ある目的に基づき、一まとめにまとめます。
この
ある目的をもとに、アクティビティをまとめたまとまり
のことを、「プロセス」と呼びます。これはソフトウエア工学に限ったことでなく、一般のお仕事（運動会を行うでも、会社を乗っ取るでも）でも、アクティビティをまとめてプロセスとします。
そして、ここでは、ソフトウエア開発にかかわるプロセスを「ソフトウエアプロセス」と呼ぶことにします。
具体的には、ソフトウエア開発には、どのようなプロセスがあるのでしょう。
大きく分けると、要求分析→設計→実装→テストというプロセスがあります。
設計をさらに細かく、外部設計(基本設計）→詳細設計（内部設計）と分けたり、
テストを単体テスト→結合テスト→詳細テストと分けたりもします。
そしてソフトウエア開発は、全体的にみると、プロジェクト立ち上げプロセス（これはソフトウエア開発外のプロセス）からくる、プロジェクトの利害関係者（ステークホルダー）を入力とし、運用するソフトウエアを出力し、これを運用プロセス（これもソフトウエア開発外）に渡します。
各ソフトウエアプロセスにおける入出力と処理内容は、以下のとおりです。
＜＜要求分析＞＞
入力：プロジェクトの利害関係者（ステークホルダー）
→誰（Who）に相当
処理：
１．誰に、「どんな機能」を提供するかを決定
２．「どんな機能」について、「いつ」行うかを決定
３．機能について「何を」提供するかを事後条件として決定
出力：要求仕様書
機能（＝コンピューターが、いつ、誰に、何を提供するか）を記述
機能以外も記述
＜＜設計＞＞
入力：要求仕様書
機能（＝コンピューターが、いつ、誰に、何を提供するか）を記述
機能以外も記述
処理：機能以外のことを制約条件として、
機能（＝コンピューターが、いつ、誰に、何を提供するか）を実現する
コンピューター的な手法（どのように）を決定する
出力：設計書
コンピューターが、何を、どのように行うかを記述
＜＜実装＞＞
入力：設計書
コンピューターが、何を、どのように行うかを記述
処理：設計書に書かれている、「どのように行うか」を
コンピューターのプログラムに変換し、
実行可能プログラムを得る
出力：実行可能プログラム
＜＜テスト＞＞
入力：要求仕様書、設計書、実行可能プログラム
処理：要求仕様書、設計書で書かれていることが、
実行可能プログラムを実行することで得られるか
確認する
出力：テスト結果報告
では、これらソフトウエアプロセスを、いつ、どのように行っていったらよいでしょうか？
それについては、２章で説明します。
今回は「１．３ ソフトウエアプロセスとは」です。
１．３ ソフトウエアプロセスとは
前回、ソフトウエア工学とは、
顧客の要望に応じたソフトウエアを上手に作るために、コンピューターサイエンスを基礎として、コンピューターを使いこなすソフトウエアを作るための工学
とまとめました。結局、ソフトウエアを作るための工学ということです。
では、ソフトウエアを作るためには、どうしたらよいのでしょうか？
１．１章で見たとおり、人間は、活動します。そして、この活動で、入力→処理→出力となるものを、アクティビティと呼びました。
ソフトウエアを作るためにも、活動します。エディタでプログラムを記述するとか、コンパイルするとか、コンピューターを立ち上げるとか・・・
そしてこれらの活動の一つ一つは、たとえば、コンパイルが
ソースコード→コンパイル→オブジェクト
となるように、入力→処理→出力というアクティビティになっています。
つまり、ソフトウエアを作成するためには、人々は、さまざまなアクティビティを行っているということになります。このアクティビティを実施することが、ソフトウエア開発ということになります。
しかし、ソフトウエア開発には、多種多様なアクティビティがあるため、これをばらばらに扱うと、管理や計画が立てられなくなってしまいます。
そこで、アクティビティを、ある目的に基づき、一まとめにまとめます。
この
ある目的をもとに、アクティビティをまとめたまとまり
のことを、「プロセス」と呼びます。これはソフトウエア工学に限ったことでなく、一般のお仕事（運動会を行うでも、会社を乗っ取るでも）でも、アクティビティをまとめてプロセスとします。
そして、ここでは、ソフトウエア開発にかかわるプロセスを「ソフトウエアプロセス」と呼ぶことにします。
具体的には、ソフトウエア開発には、どのようなプロセスがあるのでしょう。
大きく分けると、要求分析→設計→実装→テストというプロセスがあります。
設計をさらに細かく、外部設計(基本設計）→詳細設計（内部設計）と分けたり、
テストを単体テスト→結合テスト→詳細テストと分けたりもします。
そしてソフトウエア開発は、全体的にみると、プロジェクト立ち上げプロセス（これはソフトウエア開発外のプロセス）からくる、プロジェクトの利害関係者（ステークホルダー）を入力とし、運用するソフトウエアを出力し、これを運用プロセス（これもソフトウエア開発外）に渡します。
各ソフトウエアプロセスにおける入出力と処理内容は、以下のとおりです。
＜＜要求分析＞＞
入力：プロジェクトの利害関係者（ステークホルダー）
→誰（Who）に相当
処理：
１．誰に、「どんな機能」を提供するかを決定
２．「どんな機能」について、「いつ」行うかを決定
３．機能について「何を」提供するかを事後条件として決定
出力：要求仕様書
機能（＝コンピューターが、いつ、誰に、何を提供するか）を記述
機能以外も記述
＜＜設計＞＞
入力：要求仕様書
機能（＝コンピューターが、いつ、誰に、何を提供するか）を記述
機能以外も記述
処理：機能以外のことを制約条件として、
機能（＝コンピューターが、いつ、誰に、何を提供するか）を実現する
コンピューター的な手法（どのように）を決定する
出力：設計書
コンピューターが、何を、どのように行うかを記述
＜＜実装＞＞
入力：設計書
コンピューターが、何を、どのように行うかを記述
処理：設計書に書かれている、「どのように行うか」を
コンピューターのプログラムに変換し、
実行可能プログラムを得る
出力：実行可能プログラム
＜＜テスト＞＞
入力：要求仕様書、設計書、実行可能プログラム
処理：要求仕様書、設計書で書かれていることが、
実行可能プログラムを実行することで得られるか
確認する
出力：テスト結果報告
では、これらソフトウエアプロセスを、いつ、どのように行っていったらよいでしょうか？
それについては、２章で説明します。
アクセス
トータル
ランキング
