1. ソフトウェア工学とは?
ソフトウェア工学を学ぶ皆様、こんにちは。
今日は4/1ではありませんので、安心してください(意味不明)。
... ところで、ソフトウェア工学って何でしょうか?
あまりにも広大で意味ちょびっとで、「人生を学ぶ」「愛を語る」「世界平和」と同じくらいかも知れません。それに「ハードウェア工学」とかはあまり聞きませんし。
なぜソフトウェアだけ?
ということで、ソフトウェア工学を学ぶに当たり、これを定義しておかなくてはいけません。
そうしないと、ソフトウェア工学の時間に、愛を学ぶかも知れませんから。
恐ろしいことにソフトウェア工学と題した本は多く出ています。私の手許にも著者が違う同名の本が3冊あります。(副題は違っていますが)
そして問題は同じ題名なのに内容が違うことです。この原因の一つは書かれた時期によるものです。やはりソフトウェア工学にも流行があります。ロングスカートが流行ったと思ったらミニスカートが流行り、マイクロミニ、ナノミニが流行るという感じでしょうか。
そこで今日当たりのソフトウェア工学の定義。
「ソフトウェア工学とは趣味のプログラミングから組織のソフトウェア開発へ行くためのもの」
・・・てオチはどこにあるの?
先頭へ戻る
2. 暴風雨が来る前の
章題の「暴風雨が来る前の」は現在の状況と、デスマになって襲ってくる暴風雨を指しています。・・・たぶん。って偶然?。しかしちょうどぴったりです。
1章ではソフトウェア工学の定義を行いましたが
... # ってそうだった?前提条件みたいなものだけしか言っていなかったのでは?
ごほん、ソフトウェア工学の定義は置いておいて、今回はその目的をお話します。
# って定義せずに教えると、愛を教えるようになるのではなかったの?
ソフトウェア工学の目的は、ごほん、その目的の一つには、組織によるソフトウェア開発に役立てることがあります。
# つまり、1人で作るなら、ソフトウェア工学はいらないって?
いや、そこまでは、ソフトウェア工学を棚の奥にしまっておいてもいいのでは。
この組織によるソフトウェア開発も抽象的なものですから、この山を登るには、色々な道があります。例えば、オブジェクト指向を杖代わりにして登山するというのもあります。
スニーカーで登山を勧めているような本もあります。・・・遭難したときの責任は?
ということで、今日当たりの教訓。
「山登りには、事前準備と道具の整備が大事」
次回は登山道具についてお話します。
先頭へ戻る
3. 教科書はどんなものがある?
3.1 登山の準備
前回まではソフトウェア工学の目的と登山準備について書いてきました。
・・・登山って象徴としての登山だよね。本当にピッケルとか用意しなくていいよね?
もちろんそうです。但し徹夜の準備は用意した方がいいでしょう。
・・・こんなことを書くから、6Kとか言われるんですよ
徹夜と言っても、夜通し遊ぶためのものです。
マージャンとか、トランプとか、デバッグとか、始末書書きとか・・・
・・・最後の方は違いますって。
えっと、最近の道具の流行は、「オブジェクト指向」です。
もしあなたが持っているソフトウェア工学の教科書にオブジェクト指向が載っていなければ、それは偽者であるか、古いものか、偏屈なものであるかです。
・・・ってここはオブジェクタの巣窟?危険。。。
3.2 ソフトウェア工学の教科書の分類
道具の詳細な説明をする前に、ソフトウェア工学の教科書を分類してみましょう。
あなたが読んでいた教科書がどのタイプかをチェックしてみてください。
(1) おのぼりさんツアー本
これは観光名所だけを団体バスで移動し、ぱっと見て帰るという教科書です。
この教科書の特徴として、ページ数は薄いのですが、絵(風景写真を含む)が多く入り、最近の用語(オブジェクト指向、派生開発、xxBOKなど)が多く入っています。
いわゆる「連れ回しツアー」です。その国に行った気にさせます。
もちろん、これで満足していてはいけません。
実際の教科書の名前は(検閲により省略されました)
(2) バロック本
これはクラシックなものの中でもバロックを中心にしているものです。古典で重厚長大です。
例えて言うなら、ロケットの弾道計算を国民総動員で作るような教科書です。
これを見破るのは簡単です。初版が出たときの年代を見てください。
もしあなたの生まれる前に出版されていたなら、その教科書は貴重品です。
厳重に保管して閲覧できないようにしてください。
このタイプの特徴としては、例えば、オブジェクト指向が全く記載されていないか、「もの指向」や「対象指向」のようにオブジェクトを訳そうと努力をしています。
(3) ヲタク本
ソフトウェア工学は総合芸術の雰囲気がありますが、ソフトウェア工学と題した教科書の中には、特定の1分野に多くのページを割き、その他の興味を持っていない分野にはページをわずかしか使っていません。筆者の興味のあるところだけをマニアックに語っています。
例えば、それがプロジェクト管理であったり、テスト技法であったりします。それぞれ、PMヲタク、テストヲタクと呼ばれています。
(4) パズル本
この教科書はやっかいです。「通常では起こらないような想定」のパズルの問題だけを出題しています。さらにやっかいなことに、解答が書かれていない本さえもあります。
(5) 夢物語本
このパズル本をさらに発展させたのが「夢物語本」です。例えば、「仕様変更は起こらないものとする」や「仕様はあらかじめ定義されている」という記述があります。
まさに夢の世界、別世界でのソフトウェア開発について妄想しています。
恐ろしいことに大学のソフトウェア工学のシラバスにも同じことが言えます。
一度、"ソフトウェア工学" "シラバス" でググってみてください。
驚愕の真実が分かります。
ソフトウェア工学の教科書のタイプはまだまだあります。
教科書の種類よりもタイプの方が多いくらいです。
しかしこれ以上書くと命の保証がないような気がしてきましたので、ここらd
先頭へ戻る
4. 登山道具にはどんなものがある?
4.1 道具一巡り(1)
前回は、ソフトウェア工学の教科書を眺めて分類してきました。
この分類はウケ狙い30%、皮肉10%、悪意10%で練成されています。
・・・って100%になっていないし。(ネタ元が分からない人はハガレンで検索してください。)
同様に大学などのソフトウェア工学のシラバスを眺めても、同じような感じで分類できます(推測30%入り)。
ということで、ここでは教科書やシラバスからピックアップした登山道具を眺めてみます。
えっと、登山靴にピッケル、リュック、バーナー、寝袋、・・・ってこれは、登山入門の本じゃないか。
エンジニアリングプロセス(開発工程)の順にピックアップしてみます。
(うゎ、同じことを別の言葉で表現しているのが多いなぁ。これはカテゴライズするのは面倒。)
まぁなるべくエンジニアリングプロセスの順にピックアップしてみます。
その後にプロジェクトマネジメントや開発プロセスのサポートプロセスの方で分類してみます。
これで(単体の授業としての)ソフトウェア工学の道具立てが分かります。
■エンジニアリングプロセス別
○企画戦略
・・・あれ?ない?まぁここは仕方がないかも。
○要求分析
・・・あぁ、ありますね。でも道具についてはあまり書かれていませんね。
・・・どうやって要求分析させる気?いやこれもいい経験になるでしょう。たぶん。
・・・あ、UML の授業から発掘しました。でもこれは読み書きのレベルでは?
○アーキテクチャ設計
・・・あれ?ない?
・・・いや、アーキテクチャパターンとかの古代文字が。
・・・別の授業でアーキテクチャと名前が付いた授業が案外ありますのでたぶん大丈夫・・・かな。
○システム設計(外部設計、概要設計)
・・・あります。あります。これは古典派からニューウェイブまで多種多様です。
・・・モジュール設計も DFD もクラス設計(UMLを含む)もあります。うわ、全部やるの?
・・・ジャクソン法ですか、お懐かしい!まだご存命でしたか、うわ、石を投げないで
・・・デザインパターンもあります。さすが流行!
・・・(ぼそっ)ソフトウェア工学を設計の授業と間違っていない?
・・・でもソフトウェア工学で学んでほしい「設計の維持(管理や文書化、見直し)」がない・・・
○プログラム設計(内部設計、詳細設計)
・・・これも多くあります。上記と区別されていないものもありますが、兎に角あります。
・・・懐かしい!構造化ですか?今は当たり前かも。もうじきオブジェクト指向もそうなる?
・・・ここも古典派からニューウェイブまで多種多彩です。まるで動物園のようです。
○コーディング(製造、実装、プログラミング)
・・・ここはさすがにプログラミングの直接の話はないですね。
・・・ここは設計工程と違って、ちゃんと分離されています。うんうん。非常に正しいです。
・・・あ、コーディングスタイルのようなプログラミング書法的な道具がありますね。うーん、微妙です。
・・・あ、デバッグ手法について触れているのもありますね。うーん、これは違うだろ!いや正しいのか?
○テスト(単体テストからシステムテストまでイッキに一つで。・・・て分類が面倒になった?)
・・・昔は、テスト技法と呼ばれるものがソフトウェア工学の花形だった時代もありますが・・・
・・・もちろん、テスト技法の授業でやってほしい道具が多いですた。(この行のバクが発見できるか?)
・・・ソフトウェア工学では、テスト技法で教わった道具を使って、テスト管理をしたり、それを失敗
・・・何か、失敗したようですが、テスト運用を学んでほしいのですが、それはないような内容です。
○運用・保守
・・・あれ、ない?うーん、ここの比重が大きいのに・・・
■サポートプロセス別
○開発プロセス(V字モデル、プロトタイピング、アジャイル、派生開発、SPL・・・)
○プロジェクトマネジメント(リスク、タイム、要求、スケジュール、計画・・・)
○見積手法(積み上げ、FP、ステップ、・・・)
○文書化
○コミュニケーション
えっ省略?時間切れ?
面倒になったわけでも時間切れになったわけでもありません!・・・たぶん、きっと。
次回はここから再開・・・できたら、いいね!
先頭へ戻る
facebook の調べ
Android の調べ
鉄道の調べ
ビールコレクション
Copyright © 2012 GOMI Hiroshi All Rights Reserved