ソフトウェア工学をつつく7ープロセスモデル。ちゃんと作業を区切ろう。

ソフトウェア工学がもたらした成果の中で、一番重要かもしれない概念が プロセスモデルピヨ♪今回はそのプロセスモデルをつつくピヨ♪
プロセスモデルを簡単に言うと、システム開発とシステム運用の工程を細かく区切って定義したものピヨ。これは工学でお馴染みの考えピヨね♪みんな、工場見学もしくはTVとかで工場内の様子を見たこと事ある？見たことがあるのならば、箱だけを作る工程、箱に入れるものだけを作る工程・・・などが明確に区切られて、機械で大量生産されているのを知っていると思う。このように、明確に作業を定義する事により作業の自動化や生産性の向上を期待できるんだ。そのソフトウェアバージョンがプロセスモデルと思えばいいピヨ♪
その中で一番古く単純なのがウォーターフォールモデルピヨ♪これはソフトウェア開発を6個の工程で区切るプロセスモデルなんだ。その工程を列挙するから見てね♪


【ウォーターフォールモデルの手順】

• 基本計画・・・既存のシステムがある場合、その問題点を調査し、システム分析を行い、システム用件、問題点の解決法を考えるピヨ。そして新規の場合も再構築の場合も、システムのユーザーの要求、システム導入会社の要求等を正しくまとめて要求定義書にするピヨ♪
• 外部設計・・・要求定義書に基づいて、ユーザインタフェース（画面、印刷物のレイアウト等）、コード設計などをおこうなうピヨ。この工程で定めた事は、外部設計書に書くんだ。
• 内部設計・・・外部設計書に基づき、オブジェクトのデザインやモジュールの設計をするピヨ。この工程で定めた事は内部設計書にするんだ。
• プログラム設計・・・内部設計書に基づきコーディングをするピヨォ♪
• テスト・・・出来上がったプログラムをテストするピヨ。
• 運用・・・ここまで来たらソフトウェアシステムは完成だから実際に運用して、今後の為に問題点などを書いておくピヨ。

上記の一覧を見たら分かると思うけど、ウォーターフォールモデルの特徴は、 各工程を滝が流れるように順番に進めていく所にあるピヨ♪ ってこれぐらいならば、どの教科書にも書いてあるからつついているとは言わないよね。皆も現実を知りたいだろうから、中の人（このブログの作者）の実体験を踏まえながらもっと詳しくつついていくピヨ♪じゃあ行くぞ！鳥やー
※先に断っておくけど、これは中の人の体験に基づくものだから、情報産業全体のことではないピヨ。


バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ



【基本計画の現実】
中の人の仕事はフリーな何でも屋エンジニアだから全工程を担当することが多いんだ。だかも勿論この工程も経験済み♪その時の事を踏まえて基本計画をつつくいていくピヨ♪
教科書では大層な事を書いているけど、現実はそんなにたいしたものではないピヨね。日本では良くある事で、契約書での壮絶な心理合戦、責任範囲の不毛な擦り付け合い、美麗字句の言い合い、名刺交換、無意味な会議・・・などで費やされるピヨ♪とてもじゃなけど、巷で考えられているような華麗な工程ではないピヨね。実際は、泥臭い人間模様としか言いようがないそうだよ。勿論、情報産業は広いからもっと優雅な所もあるんだろうけど、残念ながら中の人は体験した事が無いピヨね。
先ほど書いたように、この工程は今後の全てを定める重要な工程なんだけど、実際は後の工程に押し付けられる事が多いピヨ。だってぇ、ココの工程で出てくる人の大半は情報処理技術を知らない人だもんね。そんな人達が、ソフトウェア工学に基づいてシステムを定める事を期待できるでしょうか（笑） その結果生まれるのが意味のない要求仕様書ピヨね・・・


【外部設計】
本来はしっかりとした完璧な要求定義書が必要なんだけど、現実はえてして意味のない要求定義書しかないからこの工程では、システムを使う顧客の要望を推理する事から始まるピヨ♪中の人の場合は仕方が無いから、無意味な会議中に勇気を振り絞って、情報の断片を聞き出して、この工程で推理をするそうだッピヨ。でも当然のことながら開発者はエスパーじゃないから、ウォーターフォールモデルでは禁止されている後戻りが何度も発生するピヨ。それでも完全な要望を顧客から聞きだすのは不可能に近い事ピヨ。だって、お客様も要望が定まっていない場合が多いからね。それは無理もない事だよ。お客様にしたら異文化以外の何ものでもないし、本来一番詳しくあるべきプロジェクトの責任者が情報処理技術を知らないもんだから上手くいくはずがないピヨ。 こんな調子だからやはり、ここで仕上がる外部設計書は不完全なものピヨ・・・もうだめぇ


【内部設計】
不完全な外部設計書と格闘しつつ、技術者が職人魂を発揮してデスマーチの下にソフトウェアの全体像を考えるピヨ。この工程はえてして、プログラム設計と同時進行されるピヨ。その様は地獄としか言いようが無いピヨね。今までツテがここに押し込まれているという事だね。本来ならば内部設計書を作るべきなんだけど、デスマーチではちゃんとしたものは作られない傾向があるピヨ。


【プログラム設計】
本来ならば内部設計書を見て行うこの肯定だけど、先述の通り内部設計と同時に行われる事が多いピヨ。もう世間の優雅なイメージとは逆で、阿鼻叫喚絵図だピヨ。ここで多くの人間ドラマが発生するピヨ。もちろん、悪い意味でね。デスマーチ中に職場恋愛なんて生まれない。生まれるのは負の感情だけさ。


【テスト】
ウォーターフォールモデル型開発では、実際は殆ど行われていないピヨ。これで本当に大丈夫ぅ？


【運用】
テストがろくにされていないものだから、当然お客様からのクレームが来るピヨ。当たり前だよね。無計画かつ、お客様の要望をろくに聞かないで成功するはずが無い。日本では責任者は責任を取らず、デスマーチの被害者である技術者達にに責任を押し付ける場合が多いんだ。それでも職人魂に燃える技術者達には「今こそ本当のシステム開発の始まりだ。お客様の声がやっと聞こえるぞー。」という強者が多いピヨね・・・・


どうかな？これで強烈にウォーターフォールモデルの弱点が分かったと思う。それはソフトウェア開発は完璧に進められないという事ピヨ。ウォーターフォールモデルでは、全工程が正しい事を前提としていけるけど、現実はそんなに甘くないピヨ。仮に要求定義を完璧にしたとしても、時が経てばシステムに対する要求が変化するからね。そんな現実を無視したプロセスモデルは通用しないピヨって事だね。だけど、このモデルは非常に重要ピヨ。このプロセスモデルを反面教師として、多くの犠牲を払いながら開発プロセスの研究がさらに進んだんだ。この先が気になると思うけど、長くなるからここで一旦おしまい。

ソフトウェア工学をつつく6ー1970年代までの成果。やったね！

【プログラミング技法】

• 構造化プログラミング
• 構造化コーディング
• トップダウンプログラミング

【テスト技法】

• モジュール集積テスト
• ブラックボックステスト
• ホワイトボックステスト
• 動的／静的テスト

【管理技法】

• 品質管理技法
• 工程管理技法

うーん凄い成果だ！次回からは個々につついていくピヨ。楽しみにしてね。

ソフトウェア工学をつつく5－構造化プログラミング誕生。GOTOは有害？

1960年代後半のソフトウェア工学の歴史は、B.W.Boehm（ベーム）氏、Dijkstara（ダイクストラ）氏達によって、大きな展望を迎える事になるピヨ。彼らが提唱したのは、

1つの入り口と1つの出口を持つようなプログラムは、「順次・反復・分岐」の3つの基本的な論理構造によって記述できる-構造化定理

『Go to文は有害だと考えられる』("Go to statement considered harmful") - GOTO有害論

このころから既にスパゲッティプログラムの問題が認識されていた事がわかるよね。でも理屈だけじゃわかりにくいのでプログラムを書いてみた。

#include 

int main(void) 
{
    char i = 0, x = 0;
    char str[6];
    str[0] = 'H', str[1] = 'e', str[2] = 'l', str[3] = 'l',
         str[4] = 'o', str[5] = '\n';
HELLO:
    goto CHAROUT;
HELLOSUB:
    x += 1;
    if ( x < 6 ) goto HELLO;
    goto NUMBEROUT;
COUNT:
    goto NUMBEROUT;
COUNTSUB:
    i += 1;
    if ( i < 10 ) goto COUNT;
    printf("good-by \n");
    goto END;
CHAROUT:
    printf("%c", str[x]);
    goto HELLOSUB;
NUMBEROUT:	
    printf("%d \t", i);
    goto COUNTSUB;
END:
    return 0;
}

//元のプログラム
#include 
int main(void) {
    char i;
    char str[6];
    str[0] = 'H', str[1] = 'e', str[2] = 'l', str[3] = 'l', 
        str[4] = '0', str[5] = '\n';
    for ( i = 0; i < 6; i++ ) printf( "%c", str[i] );
    for ( i = 0; i < 10; i++ ) printf( "%d ", i );
    printf( "\n" );
    printf( "good-by\n" );
}

┐(´ー｀)┌ﾔﾚﾔﾚ
うーん。こりゃすごい。この調子で何万行も書くんだから彼らの言い分がわかるよね。 確かにGTOTの多用は有害以外のなにものでもないし、根源は機械語だから全てのプログラムは「順次・反復・分岐」でかけるピヨ。生産性が悪いけどね。
しかしダイクストラは、アセンブラな人達から「GOTOは必要だ！」と猛抗議を受けたんだ。まぁ、確かにOSとか作る時は必要性を感じるピヨ。ダイクストラも言い方が悪かったのかもしれないね。 この議論の結果、今日当たり前となったbreak、continue、continue、switch・・・などの限定版GOTOが登場したんだ。これらはアセンブラレベルではGOTOそのものピヨ。だけど、人間にとってはGOTOは読みにくいよね。だからGOTOに意味を持たせたこれらの文が考案されたんだ。猛抗議の中主張し続けた勇者ダイクストラに感謝しよう！

ソフトウェア工学をつつく4－アンバンドリング。これって抱き合わせ商法？

ソフトウェア系技術者のボクとしては不快な事に、1960年代ソフトウェアはハードウェアのおまけだったんだ。もちろん、カスタムメイドのソフトを望むお客も居たけど、当時はハードウェア屋に追加注文して作らせるのが普通だったんだ。当時のソフトウェアは移植性がかなり低く、ユーザーは販売業者のハードウェア屋さんに頼むしか手段が無かったんだ。 このように、ハードウェアとソフトウェアが一緒に売られる事を英語でバンドリングというんだ。
その時一番成功しているのが今もなお存在するIBMピヨ。でも運が悪い事に、あまりにも勝ち過ぎて、米政府から独占禁止法の疑いで訴えられたんだ。多分、今でいうところの抱き合わせ商法のような事を考えられたんだろうね。でも訴えられたまま黙っているIBMではない。IBMは新しい手段を思いついたんだ。それがアンバンドリングという方法ピヨ。
アンバンドリングとは、先ほど言ったバンドリングと逆の方法で、ハードウェアとソフトウェアを別々に有料で売る販売方法の事なんだ。 この方法はかなり好評でソフトウェア産業の発展を促したのでソフトウェア革命と呼ばれているピヨ。この革命のお陰でFreeBSD、MS-DOSなどの基本ソフトウェアも発達したとも考えられているピヨ。今日ボク達ソフトウェア系の技術者が居られるのもIBMのお陰かもね。
あれ？でもこれって、商売方法であってソフトウェア工学と呼べるのかな・・・かなり疑問だけど、そう言われているから一応そうしておくピヨ。
今回は短いけどこれでおしまい。

ソフトウェア工学をつつく3ー1960年代後半の成果。古いけど今でも重要！

前回はソフトウェア工学が誕生した背景をつついたから、今回はその成果をつつくピヨォッ！1960年代後半に早速成果が出たピヨ。結構速いよね。まずはその成果と概要を列挙するピヨ。


【1960年代後半の成果】

• アンバンドリング（unbundiing）方式
  IBM社が考えた方式で、ハードウェアとソフトウェアの 価格を分離した。
• プログラム構造理論
  べーム（B.W.Boehm）氏達が、どのようなプログラムでも基本的な制御構造の組み合わせだけを使って実現可能だという事を証明したんだよね。それは1966年の事だった。
• GO TO命令有害論
  当時のプログラマはGOTO文を多用して、スパゲッティプログラムを量産したらしい。この年代の人達は、もともとアセンブラ使いだったから仕方がない部分もあったけど、こんなスパゲッティ誰も食べれないよね。

ひとまず列挙してみたけどまだ数は少ないよね。でもそこには、今でも通用する重要なテーマがあるピヨ。それは、ソフトウェアの価格問題、 プログラムの本質は単純である事、 プログラムの可読性の三つピヨ。 これは今でも形を変えて言われているよね。ボクが産まれるより前の事が今でも解決していないなんてうんざりするピヨ。人間が起こす問題の本質は変わらないんだね。
それぞれ重要な事だからこれから個別につついていくピヨ。

ソフトウェア工学をつつく2ーソフトウェア工学の定義。結局何なのさ！

ソフトウェアについてある程度しったからいよいよソフトウェア工学をつつくピヨォッ。ソフトウェア工学の定義を調べたところこんな文章が見つかった・・・

ソフトウェアの開発から保守に至るまでの全行程で、工学的な方法論や技巧を体系化し、それを適用しすることによって、正しいソフトウェアを計画的に作成し、ソフトウェアの生産性と品質の向上を図るための理論と実践的な技術と学問領域。

・・・・・・日本語でおk。何ことやらさっぱりだ。学者は自分を賢そうに見せるために、やたら難しい言葉や言い回しをしたがるんだよねー。本当の賢さは難しい事をいかに簡単に話すかってことなのにねぇ。でも裏を返せば、それって「印象で金を出す馬鹿が多い」という事だよね。惑わされずに本質を見極めよう。学者がこんな講釈をたれ始めたら歴史を振り返るのが一番ピヨ。でも、普通に書いたら面白くないからボクの空想ストーリーで話すよ。最近絵本作家に向いているって言われたしねｗ


【オープニング】
時は1960年半ば。その頃は汎用コンピュータが普及し、ソフトウェアも大量に作られる事になり、IT業界の人々に未曾有の危機が迫ってきた。それを人々はこう言った「ソフトウェア危機」と・・・誰が言い始めたのかはわからないが、危機なのは誰の目にも明らかであった。これは、情報産業に従事する者達の汗と涙と感動の物語なのかもしれない。

【ニューヨークの片隅で】
ニューヨークのIT会社、JJ（ジョン・ジュニア）エンジニアリングは商売は繁盛していた。しかし、誰の顔にも陰りが見えていた。
トム（リーダー）「おい、みんな、新しい任務だ。今度の任務はかなりハードだぜぇ。１０州にまたがってクモの巣を張り巡らし（ネットワークの事）、メール、電話、ピザ、ハック、書類、なんでも飛ばしてみんなハッピーってわけさ！さあ、戦争をおっぱじめようぜ！勇気がない奴はとっととこの場を去れ。この場は命知らずの野郎どもの聖域だ。」
ケン「（あいかわらずテンション高いな。こっちは徹夜続きなんだぜ。）確かにハードな仕事だなボス。そんな規模のネットワーク構築聞いたことがないぞ。こりゃ本当に死ぬかもな。」
マリー「オー・マイ・ゴット！そんなのクレイジーよ。ここ最近、お客の要望がエスカレートしてソフトウェア規模が増大 しているけど、こっちはもう限界！ヘトヘトよ！ちょっとは分別ってものを叩き込むべきよ！」
トム「おいおい、もうそれぐらいにしてくれよ。確かに色々な意味でソフトウェアコストが増大しているが、こっちはそれで飯を食っているんだぜぇ。」
メンバー「なにはともあれ、やるしかないな・・・」
三ヶ月後・・・
トム「おい、お前ら。要求仕様がまた追加されたぞ！」
マリー「なんですって！ これじゃあ、バックログ（開発の積み残し）が増大するばかりよ。 とても正気とは思えないわ！クレージーよ！デートもできなくて彼にも振られるし、 お肌は荒れるし、ビザとケンタッキーと不規則で太るし、もうストレスでどうにかなりそうよ！ 精神科医を常備して！」
スペンサー「まぁ落ちつけよ。お前も技術者ならば」
マリー「うるさい！もうこんなクレイジーな職場沢山よ。今日限りで辞めるわ。」
アニー「じゃあ、私も。」
山田「あちきも辞めさしてもらうわん」
トム「おい待ってくれ。そんなことされたらソフトウェア技術者は不足し、その結果ソフトウェアの生産性と品質が低下するぞ！おいもどれったら。畜生！神よわれを救い給え」

不幸な事にこれはこの会社だけの現象ではなかった・・・

• 規模の増加
• バックログの増加
• 技術者不足
• 生産性低下
• 品質低下

この５つの問題は全米を揺るがした。そこで登場したのがスーパーマン・・・じゃないよ。 現実はきわめて地味で、博士などの知識人たちがNATO会議でソフトウェア工学ってものを作ってこの危機を解決しようとしたのさ。これがソフトウェア工学の誕生ピヨ。
結局のところ、ソフトウェア開発を効率化する方法論や技法の事なんだ。一言で言うのならば根性論じゃあ解決しないって事だね♪
このソフトウェア工学が何をもたらしたのかという事なんだけど・・・それは次回でお話しするよ。

ソフトウェア工学をつつく1ーソフトウェアってどんなの？

前回ソフトウェアについて軽くつついたから、今度はもっとつついていくピヨ。
どんなものにも性質や特性はある。ソフトウェアも勿論例外ではなくて次の特徴があるピヨ。


【ソフトウェアの特徴】

• 目に見えない・・・物理的なものじゃないからね。
• 潜在的なバグが常にある・・・バグっていうのは文法エラーだけじゃないピヨ。
• 要求仕様は常に変化している・・・常に世界は動いているからね。
• 些細な変更が大きな影響を与える・・・一つのモジュールを変更しただけで動かない事なんてざら。
• 簡単にコピーできる・・・コピーコマンド一発で窃盗される。
• 創造者の思想を含んでいる・・・ソフトウェアには実態がないから作った人の意思が出やすいよ。
• 物理的なものではない故に無限のバリエーションを持つ・・・芸術は爆発だー。

【ソフトウェアの品質特性】

• 機能性・・・要求仕様をどれだけ満たしているかだよ。顧客満足度ってことだね。
• 信頼性・・・バグに対する対処法がちゃんとあるかとか、信頼に関わる事だよ。
• 操作性・・・機能が良くっても使いづらかったら意味がないよね。わかりやすいGUIがあるかなどの尺度を操作性というピヨ。
• 効率性・・・CPUやメモリなどの資源をどれだけ有効利用しているかということピヨ。コードの行数少なさもこれに含めて言う場合もあるピヨ。
• 保守性・・・ソフトウェアの構造が理解しやすく、変更が行いやすい状態になっているかとか、ドキュメントがあるかとか（コード読めじゃだめ！）、スパゲッティコードを書いていないかとかだよ。
• 移植性・・・Windows用ソフトを、すぐinux用ソフトに作り変えられる時「移植性が高いソフト」というピヨ。どれだけ、違う環境に適用できるかということだね。ということは、ゴキブリは移植性が高いのかな・・・
  ※それは環境適用能力です。

大まかにはこんなところかな？一度に書いても読みにくいだけだから、詳しい話しはまたあとでするピヨ。おしまい。

ソフトウェア工学をつつく0ーそもそもソフトウェアって何？

情報処理技術者はやっぱりプログラミングだけしていちゃ駄目。ちゃんと情報処理技術に関して学習しなくっちゃならないんだ。プログラミングや業務に関係ないと思われている節もあるけど、 情報処理技術の知識がなければ プロとしてはお話にならないピヨ。 ちょっときつい言い方かもしれないけど良薬口に苦しだからちゃんと聞いてね。 例えば料理人を思い浮かべてみよう。 一流の料理人さん達は、食材・食文化・地理・・・など膨大な知識を持っている。 それと同じで、我々技術者が知識がなければ知らないものを作れるの？ って話しになってしまうんだ。 だからこのブログでは、ちゃんと情報処理技術についてもつついていくピヨ。 僕自身もまだまだ未熟者だからみんなも一緒にがんばろう！
まず初めにソフトウェアの定義からつつくピヨ。 そんなの常識だという人もいるけど、じゃあ何か説明してというと説明できない事が多いんだ。 この事実からもわかるけど案外難しい概念なんだ。 ソフトウェアの定義は色々あるけど、ボクが思うに ハードウェア（CPU、HDD、カメラ、建物など）以外 の全てのものピヨ。 具体的に言うと、プログラム・仕様書・操作説明書・知識・技術者のノウハウ・アイデア・アルゴリズム・・・これら全てがソフトウェアなんだ。
でもこれじゃあ曖昧模糊し過ぎているから少しずつつついていくピヨ。
今回はひとまずおしまい。