前に、
ソフトウェア工学におけるアカデミックと現場の違い その２：ソフトウェア工学（１）
http://blog.goo.ne.jp/xmldtp/e/f2921a124e6d1cfaa829f27d149c6e78
を書いてから、ずいぶん時間が経ってしまったけど、その続き。
■実務では、プロセス指向が中心、データ中心が続く。
前のエントリーでは、
大学ではそこで、
構造化設計のDFDとER図を教えるところと
オブジェクト指向のUMLを教えるところが
ある。両方教えているところも有る。
と書いた。しかし、実務的には、オブジェクト指向で分析するより、
業務プロセスを中心に、分析する場合が多い。
●UMLの場合、
プロセスを扱うのはアクティビティ図になるが、
そのアクティビティ図を俯瞰するために、ユースケース図が使われる。
この２つが中心で、各アクティビティの入出力を定義するために
データ構造を定義する図（クラス図、オブジェクト図、UMLでないけどER図）
または表(Excelで書かれたDB仕様書）が必要となる。
●UMLでなく、DFDを使う場合
DFDでは、処理の順番を指定できない。
そのため、処理順番が違ったら、どうのこうのするということを指定できない
（例：営業担当が注文票を持ってくる場合と、
注文票が届いていて営業担当を割り当てる場合
の処理の差を指定できない）
そのため、処理の順番までを記述できるWFD(ワークフローダイアグラム；業務流れ図）
を記述するのが、基本となる。
WFDの入出力を記述する為に、データ構造を定義するER図が必要になってくる。
●ER図が中心になることも有る
業務フローが動きやすいので、データ中心でデータ構造を考える場合も
あるけど、その場合でも、プログラミング前に業務プロセスは明らかになる。
→つまり、業務プロセスを業務フローチャートで明らかにし、その業務プロセスの
入出力を実現するアプリケーションを作成するという形をとる。
業務フローチャートは、内部監査の三点セットでも必要なように、
ソフトウェア開発以外でもポピュラーなものになっている。
■大学の授業は、言葉の紹介で終わってしまう。
でも、業務フローは、あまり大学では教えられない。
なので、業務フローを元に、入出力項目を出し、その入出力項目から
正規化して、ER図を作成、DBを構築していくという手法は教えられない
はずである。はじまりの業務フローを教えていないので・・・
その結果、学校では、ER図、DFD、UMLという言葉や書き方、
お膳立てされた問題を元に図を書くという、言葉の紹介で終わってしまい、
・・・単位認定試験が終わったら、さっぱり忘れてしまう。
■なので、実務と大学の授業が結びつかない。
前のエントリ内の「フトウェア工学だけでは、システム開発をカバーできない（１）」
でも書いたが、大学の授業は、そもそも、ビジネスモデル構築から、どうやって、
システム化していくかのところは、説明していない。
・・・できないはずである。
ビジネスモデルというのは、ビジネスプロセスを構築することで、
ビジネスプロセスは業務フロー図であらわせるが、
それを教えていないのだから・・・
ビジネスモデルまでは、
（１）マーケティング戦略から、ターゲット顧客と、進出するドメインが決まる
（２）そこでターゲット顧客のペルソナを作成し
（３）そのターゲット顧客がドメイン内でどういう行動をとるか
カスタマージャーニーマップないしシナリオを作成し、
（４）その顧客の課題と、自社で解決できる課題を抽出
（５）課題解決のソリューションを決定する
（６）ソリューションは、どういう外部からのインプットと
外部へのアウトプットがあるかを確認し
→DFDのトップ、コンテキストダイアグラムができる
（７）そのインプット、アウトプットを実現するための
サービスの機能を絵にする
→これがビジネスモデルであり、
絵としては、DFDのコンテキストダイアグラムの第一詳細化
や、UMLのユースケース図で表せる。
とここまでの作業をしてから、業務フロー図に落とし込む
（んだけど、ここがむずかしい）
でも、これを教えたり、実習することは学校では、まずない。
だから、教えてもらったUMLやDFDの使い方はわからない
（インターンに来た人に使い方を見せると
「おお、こういうもんなんだ」と感心される）
それから、下流工程、「プログラミング」についても
違いがあるんだけど、これは別のときに書こう。
ソフトウェア工学におけるアカデミックと現場の違い その２：ソフトウェア工学（１）
http://blog.goo.ne.jp/xmldtp/e/f2921a124e6d1cfaa829f27d149c6e78
を書いてから、ずいぶん時間が経ってしまったけど、その続き。
■実務では、プロセス指向が中心、データ中心が続く。
前のエントリーでは、
大学ではそこで、
構造化設計のDFDとER図を教えるところと
オブジェクト指向のUMLを教えるところが
ある。両方教えているところも有る。
と書いた。しかし、実務的には、オブジェクト指向で分析するより、
業務プロセスを中心に、分析する場合が多い。
●UMLの場合、
プロセスを扱うのはアクティビティ図になるが、
そのアクティビティ図を俯瞰するために、ユースケース図が使われる。
この２つが中心で、各アクティビティの入出力を定義するために
データ構造を定義する図（クラス図、オブジェクト図、UMLでないけどER図）
または表(Excelで書かれたDB仕様書）が必要となる。
●UMLでなく、DFDを使う場合
DFDでは、処理の順番を指定できない。
そのため、処理順番が違ったら、どうのこうのするということを指定できない
（例：営業担当が注文票を持ってくる場合と、
注文票が届いていて営業担当を割り当てる場合
の処理の差を指定できない）
そのため、処理の順番までを記述できるWFD(ワークフローダイアグラム；業務流れ図）
を記述するのが、基本となる。
WFDの入出力を記述する為に、データ構造を定義するER図が必要になってくる。
●ER図が中心になることも有る
業務フローが動きやすいので、データ中心でデータ構造を考える場合も
あるけど、その場合でも、プログラミング前に業務プロセスは明らかになる。
→つまり、業務プロセスを業務フローチャートで明らかにし、その業務プロセスの
入出力を実現するアプリケーションを作成するという形をとる。
業務フローチャートは、内部監査の三点セットでも必要なように、
ソフトウェア開発以外でもポピュラーなものになっている。
■大学の授業は、言葉の紹介で終わってしまう。
でも、業務フローは、あまり大学では教えられない。
なので、業務フローを元に、入出力項目を出し、その入出力項目から
正規化して、ER図を作成、DBを構築していくという手法は教えられない
はずである。はじまりの業務フローを教えていないので・・・
その結果、学校では、ER図、DFD、UMLという言葉や書き方、
お膳立てされた問題を元に図を書くという、言葉の紹介で終わってしまい、
・・・単位認定試験が終わったら、さっぱり忘れてしまう。
■なので、実務と大学の授業が結びつかない。
前のエントリ内の「フトウェア工学だけでは、システム開発をカバーできない（１）」
でも書いたが、大学の授業は、そもそも、ビジネスモデル構築から、どうやって、
システム化していくかのところは、説明していない。
・・・できないはずである。
ビジネスモデルというのは、ビジネスプロセスを構築することで、
ビジネスプロセスは業務フロー図であらわせるが、
それを教えていないのだから・・・
ビジネスモデルまでは、
（１）マーケティング戦略から、ターゲット顧客と、進出するドメインが決まる
（２）そこでターゲット顧客のペルソナを作成し
（３）そのターゲット顧客がドメイン内でどういう行動をとるか
カスタマージャーニーマップないしシナリオを作成し、
（４）その顧客の課題と、自社で解決できる課題を抽出
（５）課題解決のソリューションを決定する
（６）ソリューションは、どういう外部からのインプットと
外部へのアウトプットがあるかを確認し
→DFDのトップ、コンテキストダイアグラムができる
（７）そのインプット、アウトプットを実現するための
サービスの機能を絵にする
→これがビジネスモデルであり、
絵としては、DFDのコンテキストダイアグラムの第一詳細化
や、UMLのユースケース図で表せる。
とここまでの作業をしてから、業務フロー図に落とし込む
（んだけど、ここがむずかしい）
でも、これを教えたり、実習することは学校では、まずない。
だから、教えてもらったUMLやDFDの使い方はわからない
（インターンに来た人に使い方を見せると
「おお、こういうもんなんだ」と感心される）
それから、下流工程、「プログラミング」についても
違いがあるんだけど、これは別のときに書こう。
アクセス
トータル
ランキング
