今日もそれを柔らかくする

ソフトウェア職人気質(2)

Fri, 27 Apr 2007 19:10:35 +0900

第３部まで読んだ。
この本は徒弟制度を導入して、ソフトウェア技術者の技術力を向上させること、ソフトウェア作成の考え方・会社の仕組みを変えること、更には多分、ソフトウェア作成者の生き方を変えることを主張している。
ところで、私がソフトウェア作成のサイトでやろうとしていることは、論文や書籍をもとにソフトを作成し、作成方法を改善し、またソフトを作成し・・・と繰り返すことで、一人前のソフトウェア作成者（この本で言うジャーニーマンのレベル）になることである。
しかし私には導いてくれる人がいないため、一人よがりのソフトウェア作成者になるリスクがある。
このリスクを軽減するためには、いい人を見つけて、弟子入りさせてもらうくらいしか思い浮かばいない。
要するに、この本の主張どおり徒弟制度の導入だ。．．．私って、影響されやすいのかなぁ。
弟子入りさせてもらうためにはそれなりに見込みがあることを示さなければならない。
そのためには、少なくとも勉強熱心であることを示さなくてはならない。
結局、今のままで行くにしても、弟子入りするにしても勉強は欠かせないわけか。頑張ろ。

ソフトウェア職人気質

Wed, 25 Apr 2007 18:35:12 +0900

手元にあるクリーンルーム手法の資料は一通り読んだので、別の本を読んでみようと思う。
で、アマゾンで評価が高い「ソフトウェア職人気質」を読むことにした。早速図書館から借りてきた。
読み終わったら、これまた評価が高い「達人プログラマー」を読んでみたいのだが、図書館にはないようだ。とりあえず、近所の本屋をあたって、置いてあったら立ち読みしてみよう。

欠陥ゼロのソフトウエア開発(3)

Wed, 25 Apr 2007 03:52:45 +0900

「欠陥ゼロのソフトウエア開発」の「構造化とオブジェクト指向を統合したボックス構造化手法」を読んだ。
本稿にはボックス構造化手法の実施手順が説明されていて役に立つ。
しかし、ボックス構造化手法で抽出したボックスとか状態データの中の何をオブジェクトにするかが本稿中のどこにも記述されていない。
そのため、構造化とオブジェクト指向がどのように統合されたかがわからず、とても読みづらかった。
本稿の最後の方にある「在庫管理システムの例題」から、ブラックボックスをオブジェクトとすると推測した。大事なことなので、本稿の最初の方で明記してほしかった。
なお、オブジェクトの内部仕様は、そのブラックボックスを詳細化したホワイトボックスである。

4/22の資料見つかる

Mon, 23 Apr 2007 22:35:55 +0900

4/22のBlogに「探そう」と書いた資料が近所の図書館にあることを、その図書館のサイトで検索して見つけた。
その図書館とは名古屋工業大学、略して名工大の図書館である。ここは学外のものにも貸してくれるので助かる。
見つけた資料は「欠陥が事実上ゼロの品質を達成、生産性も格段に向上」の参考文献である。
よって、全て英語である。日本語でなくて残念だ。

時間を見つけて論文コピー、書籍借りに行こう。

欠陥ゼロのソフトウエア開発(2)

Sun, 22 Apr 2007 03:38:30 +0900

「欠陥ゼロのソフトウエア開発」の「欠陥が事実上ゼロの品質を達成、生産性も格段に向上」を読んだ。
本稿はクリーンルーム手法の説明とHP社での適用事例紹介である。
クリーンルーム手法の説明には「厳格な工学的手順で欠陥を予防、導入は３段階アプローチで」と異なるところがある。
クリーンルーム手法の主な技法として「厳格な・・・」と本稿にそれぞれ以下が記述されていて、前2つが異なる。
　　「厳格な・・・」：増分開発、ボックス構造化手法による仕様定義と設計、正しさの検証、統計的な品質保証
　　本稿：仕様構造化、データ構造化、機能検証、統計的テスト
異なる理由は不明である。クリーンルーム手法をプロジェクトに適用した時期が異なっていて、その間にクリーンルーム手法が発展したのだろうか？
ともかく、本稿に記述されている仕様構造化、データ構造化は面白そうなので、別途資料を探すことにする。
また、「厳格な・・・」に余り記述されていなかった機能検証について、本稿ではより詳しく記述されている。ただし、私にとってはまだ抽象度が高い部分がある。別の資料を探そう。
更に、統計的テストについて数学的モデルが記述されていないので概要レベルしかわからない。これも別の資料を探そう。

結局、別の資料を探さないといけないのか。日本語の資料が見つかるといいな。

4/20のボックス構造化情報システムがわからないことについて

Sat, 21 Apr 2007 15:19:42 +0900

4/20のBlogに書いたように「ボックス構造化」がわからなかったので、別の資料を探した。
「ソフトウェアエンジニアリング論文集 80's」という本に載っている論文「ボックス構造化情報システム」というのを見つけた。この論文の引用参考文献に「Box-Structured」の文字が見つからないので、ボックス構造化についての最初の論文と思われる。 [07/4/22 論文ではないが、書籍「Principles of Information Systems Analysis and Design(Acdemic Press)」方が古い。]
ボックス構造化方法は要は次のようなときにモジュールを仕様漏れや重複なく分割する。

　・あるモジュールをモジュール1、2、・・nに分割したい。
　・モジュール１、２、・・ｎにそれぞれどんな機能を持たせて分割したいか決まっている。
複合設計や段階的詳細化を厳密に行う方法といいますか。
確かに、これができれば設計に欠陥はほとんど入らないでしょう。
ただし、仕様が厳密に定義されている必要がありますが...。
実際には要求仕様、もしくは外部仕様の一部に曖昧な点があったとしても、ソフトウェア作成に適用すべき方法でしょう。

欠陥ゼロのソフトウエア開発

Fri, 20 Apr 2007 04:37:54 +0900

「欠陥ゼロのソフトウエア開発」の「厳格な工学的手順で欠陥を予防、導入は３段階アプローチで」を読んだ。
クリーンルーム手法の概要、および導入アプローチの説明なので、ふーん、という感じだった(^^;
説明されている導入アプローチは「初期導入」、「本格導入」、「高度導入」である。
ＣＭＭレベル１、２の組織なら「初期導入」が、レベル２、３の組織なら「本格導入」が、ＣＭＭレベル４、５の組織なら「高度導入」が適しているそうである。
私のソフトウェア作成は確実にＣＭＭレベル１なので、初期導入から実施しよう。

なお、「ボックス構造化」の説明は全くわからなかったので、別の資料をあたることにする。

4/14の情報的強度の疑問について

Wed, 18 Apr 2007 18:20:18 +0900

2007/4/14のBlogに以下のように記した。

例えば、情報的強度はモジュール内に複数の機能を持ち、機能間でデータを共有するので、情報的強度のモジュール内部の機能群は共有結合相当の結合度になってしまう。共有結合は結合度として実質一番よくないので、この点は問題ではないだろうか？

上記について考えたので、記述する。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
以下のようにすることで、情報的強度のモジュール内のある機能の都合でデータを変更したとき、同モジュールの別機能に影響をできるだけ及ぼさないようにする。

情報的強度のモジュールに機能１、２および構造化されたデータＡが内包されているとする。
このとき、機能１の都合でデータＡを変更すると、機能２にも影響がでる。
そこで、以下の機能を当該モジュールに追加する。
　　機能１ｒ：データＡから機能１が読むフィールドを抽出し、出力する。
　　機能１ｗ：データＡのフィールドに機能１が書き込む値をパラメータに取り、フィールドに書き込む
　　機能２ｒ：データＡから機能２が読むフィールドを抽出し、出力する。
　　機能２ｗ：データＡのフィールドに機能２が書き込む値をパラメータに取り、フィールドに書き込む。

データの流れは以下のようにする。
　　機能1がデータＡのフィールドを読み込むとき：機能１←機能１ｒ←データＡ
　　機能1がデータＡのフィールドに書き込むとき：機能１→機能１ｗ→データＡ
　　機能２も同様。

これにより、機能1の都合でデータＡを変更したとき、影響を受けるのは機能１、１ｒ、１ｗ、２ｒ、２ｗである。機能２には影響しない。
もっとも、データＡが大変更になった場合は、機能２ｒ、２ｗでは影響を受け止めきれず、機能２にも変更が必要になる。これは避けようがない。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
どうだろうか。
データの読み書き用の機能を常に追加する必要はないかもしれないが、影響範囲を小さくする手段としてありだと思う。

Cによるらくらく構造化設計

Wed, 18 Apr 2007 18:15:59 +0900

「Cによるらくらく構造化設計」を読んだ。
「ソフトウェアの複合/構造化設計」、「高信頼性ソフトウェア-複合設計」を読んでいたためか、非常に読みやすかった。
第５章までの内容は「ソフトウェアの複合/構造化設計」と被っている。
第６章以降は構造化設計の練習、および「ソフトウェアの複合/構造化設計」にはない内容である。
第６章以降をコピーしておこう。
＃「Cによるらくらく構造化設計」は図書館で借りたのです。

高信頼性ソフトウェア-複合設計

Tue, 17 Apr 2007 22:15:48 +0900

「ソフトウェアの複合/構造化設計」を読み終わったので、「高信頼性ソフトウェア-複合設計」の内容と比較してみた。
「高信頼性ソフトウェア-複合設計」の第９、１０章以外は基本的に「ソフトウェアの複合/構造化設計」に記述されている。
記述は「ソフトウェアの複合/構造化設計」の方がわかりやすい。
「高信頼性ソフトウェア-複合設計」の「第９章モジュラリティーと仮想記憶装置」の内容は設計を仮想記憶装置に合わせて最適化する方法なので、よほど性能を求められない限り特に考慮しなくてよいと思われる。
「第１０章プログラムの安定性モデル」の内容はモジュール間の安定性の計算の仕方である。「ソフトウェアの複合/構造化設計」に記述されていないということは、計算した安定性と実際のソフトウェアの安定性があっていなかったのだろうか。
DaRTで検証してみよう。

以上から、「高信頼性ソフトウェア-複合設計」は第10章のみ手元においておくことにしよう。
「高信頼性ソフトウェア-複合設計」は第10章だけコピーして、図書館に返却する。
また、「ソフトウェアの複合/構造化設計」は全て手元においておきたいので、今もっているのは図書館に返却し、購入しよう。
＃「ソフトウェアの複合/構造化設計」、「高信頼性ソフトウェア-複合設計」は図書館で借りたのです。

クリーンルーム手法のリファレンスモデル

Tue, 17 Apr 2007 03:51:17 +0900

「ソフトウェアエンジニアのためのホームページ」にてSEIのサイトが勧められていた。
覗いてみたところ、SEIのレポートのページにこんなものが。
　　Cleanroom Software Engineering Reference Model
　　Cleanroom Software Engineering Implementation of the Capability Maturity Model (CMM) for Software
クリーンルーム手法がCMMと対応しているのなら、とりあえずCMMレベル2相当のプロセスだけ実施するか？

しかし、こんなの読んでたら、いつまで経ってもソフトの作成にとりかかれない。見なかったことにしよう(^^;
冗談だけどさ。いや、冗談にならないかも。(^^;;;

ところで、クリーンルーム手法って最近使われているのかなぁ。というのも、探して見つけた資料が90年代のものばかりだからだ。最近の状況がわかる資料はないかしらん。

ソフトウェアの複合/構造化設計(2)

Mon, 16 Apr 2007 06:29:24 +0900

「ソフトウェアの複合/構造化設計」を「１１．データ構造分割」まで読んだ。
「欠陥ゼロのソフトウエア開発」を早く読みたいからか、集中できず、８章辺りから読むペースが落ちてきた。
でも、「欠陥ゼロのソフトウエア開発」を読む前に、ソフトウェア開発の基本中の基本である構造化設計をそれなりに理解しておきたい。
クリーンルーム手法や６Σはソフトウェアの開発全体にわたるものだから、基本をある程度おさえていないと読みこなせない、ような気がする。
構造化設計をおさえるために、「ソフトウェアの複合/構造化設計」と「Cによるらくらく構造化設計」を読んで、「高信頼性ソフトウェア-複合設計」と内容比較しよう。その後、「欠陥ゼロのソフトウエア開発」を読もう。

欠陥ゼロのソフトウエア開発、構造化分析とシステム仕様

Sun, 15 Apr 2007 12:45:07 +0900

amazonで注文した「欠陥ゼロのソフトウエア開発」、「構造化分析とシステム仕様」が昨日届いた。いずれもユーズドで購入。
「欠陥ゼロのソフトウエア開発」は「ソフトウェアエンジニアのためのホームページ」にクリーンルーム手法と６Σの参考文献として載っていたので購入してみた。
中身をざっと見たところ、上級者向け...(^^;
でも、欠陥ゼロは非常に魅力的。しっかり読んで、DaRTの作成に適用したい。
「構造化分析とシステム仕様」は要求仕様に関する本として、色々なサイトで薦められていた。購入したのは現在販売されているソフトカバーではなく、旧版というか、ハードカバーの方。
目次をざっと見たところ、図書館から借りてきたソフトカバーと同じなので、内容も同じと思われる（違ってたらすいません）。

ソフトウェアの複合/構造化設計

Sat, 14 Apr 2007 06:20:16 +0900

「ソフトウェアの複合/構造化設計」を「５．モジュール結合度」まで読んだ。
本書は構造化設計に関する古典の名著、だそうだ。
本書には、なぜモジュール強度は強く、モジュール結合度は弱くすべきかが、設計の基本原則のようなことを基に説明されている。
また、第１章に記述されている問題は、現在でも注意して対処しないと、同じことを繰り返しまう可能性がある。
第４、５章に記述されているモジュール強度、モジュール結合度も同様で、設計時に注意していないと変更に弱く、再利用性の低い設計になる可能性がある。
だから、現在でも必読、というか確実に身に付けておき、さらに設計時にいつでも参照できるようにすべき本である。

私が過去に作ったプログラムでもきっと問題を起こしているはずである。恥ずかしいし、本を読んでなかったことを悔む。

ただ、疑問点もないわけではない。
例えば、情報的強度はモジュール内に複数の機能を持ち、機能間でデータを共有するので、情報的強度のモジュール内部の機能群は共有結合相当の結合度とみなせる。共有結合は結合度として実質一番よくないので、この点は問題ではないだろうか？
どう解決すればいいのだろうか。そういうことが書いてある本を探そう。じゃなくて、先ずいろいろ考えてみよう。

なお、本書のプログラム例はPL/Iで記述されている。私はPL/Iを知らないので、理解できない箇所があった。そういう箇所は、本書の翻訳者である国友氏の著作「Cによるらくらく構造化設計」を読んで、理解した。

ソフトウェア作成サイトの公開

Fri, 13 Apr 2007 08:44:00 +0900

ソフトウェア作成サイトから「整備中」の注釈を外した。
このブログは、三日坊主になったら恥ずかしいので、もう少し続いたら公開しよう。