年老いたシステムをとらえる3つの類別と3つの軸
出来立てほやほやの時のシステムはバグだらけで危なっかしい。そして数か月でバグ収束曲線で近似されるように徐々に品質があがっていて安定して動き出す。まるで赤ちゃんから大人に成長する過程を見ているようだ。そして、普通システムってのは長年使われるものだ。そうなると、今度は年老いてくる。システムが年老いてくるということはどういうことなのか。もちろん、ハードの衰えは確実にある。しかし、より重要なことはソフトウェアの衰えだ。長年使われている間の追加開発によりシステムは「衰える」。
最近、たくさんの衰えを見てきた。基本的に衰えたシステムは「わけがわからない」状態になる。モジュール構成がどうなっているのか、どんな機能があるのか、最近バグが多いけどどうしたらいいのか、弱ってきたんで性能をあげたいけどどうしたらよいのかなどなど。しかし、「わけがわからない」と言っていても永遠にわけがわからない。わけがわからないものでも何らかの観点で整理しなくてはならない。
検討の結果、「衰えるモノの3つの類別」と「衰えの方向性の3つの軸」で整理できることがわかった。それを示そう。システムの衰えは類別されたものごとに3つの軸で衰えをとらえることができるのだ。
- 3つの類別：これはシステムの分割方式である。
- 論理的と物理的： 概念的なものと実装や作業を構成する者自身
- システムの構成物と成果物： 実装や作業を構成する物自身と、それらを作るために作った文書群
- 物そのものとと物の関係： 文書・実装・作業など自身とそれらの関係
- 3つの軸：
こう書いてしまうと当たり前に思えると思うが、「この3つの類別と3つの軸」が整理の強力なフレームワークになる。これは実際に衰えたシステムのお守りをしている人なら納得いただけるのではないであろうか。
この強力さはいずれ学会で発表する予定だからよろしくお願いします。
- 作者: Tom Mens,Serge Demeyer
- 出版社/メーカー: Springer
- 発売日: 2008/02/11
- メディア: ハードカバー
- この商品を含むブログ (1件) を見る
Software Reengineering (Ieee Computer Society Press Tutorial)
- 作者: Robert S. Arnold
- 出版社/メーカー: Ieee Computer Society
- 発売日: 1993/05
- メディア: ハードカバー
- この商品を含むブログ (1件) を見る
- 作者: Serge Demeyer,Stéphane Ducasse,Oscar Nierstrasz
- 出版社/メーカー: Morgan Kaufmann
- 発売日: 2002/07/08
- メディア: ハードカバー
- この商品を含むブログ (1件) を見る
- 作者: トムデマルコ,Tom Demarco,高梨智弘,黒田順一郎
- 出版社/メーカー: 日経BP社
- 発売日: 1994/09/20
- メディア: 単行本
- 購入: 13人 クリック: 74回
- この商品を含むブログ (40件) を見る
参考情報として"Laws of Software Evolution"を再掲しよう。
システムは進化する。前言っていたように、Lehman先生のソフトウェア進化の法則(元は1970年あたりに体系化された法則)を抜粋しておこう。
Lehman先生のE-Typeソフトウェア進化に関する肝に銘じとけの８つの法則を(日本語は解釈が混じってます)
1. Continuing Change
- An E-type program that is used must be continually adapted else it becomes progressively less satisfactory.
- 仕様が確定できないプラグラム（E-Type：環境依存のE?)は、常に環境に合わせて変化を続けなければ満足性が下がる一方なんだよ。
2. Increasing Complexity
- As a program is evolved its complexity increases unless work is done to maintain or reduce it.
- さっきも言ったけど、プログラムは変化するんだから、何か手を打たないと複雑性は増すがり。そうしたい？
3. Self Regulation
- The program evolution process is self regulating with close to normal distribution of measures of product and process attributes.
- ソフトウェアが進化をする過程は、普通のプログラム開発と同じぐらいきっちりと決めてせなだめ。特にビジネスからの要求変更管理には気をつけたほうがいい。
4. Conservation of Organisational Stability
- The average effective global activity rate on an evolving system is invariant over the product life time.
- システムの試用期間にかかわらず、ソフトウェアの進化にかける実施作業の比率は一手に確保しておけ
5. Conservation of Familiarity
- During the active life of an evolving program, the content of successive releases is statistically invariant.
- ユーザが真に実現したかったシステムは結局作って反応を見て継続的にリリースしていくアプローチしかない
6. Continuing Growth
- Functional content of a program must be continually ncreased to maintain user satisfaction over its lifetime.
- ユーザの満足が駆動減となってシステムの機能は変更を要求されプログラムはずーっと変更され続けなければならない。
7. Declining Quality
- E-type programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment.
- E-Typeのシステムはどう進化するのか、環境によってまったく読めない。しかしそれに対してちゃんとプログラムを進化させ、保守*1をきっちりやらないと、品質は目に見えて下がっていく
8. Feedback System
- E-type Programming Processes constitute Multi-loop, Multi-level Feedback systems and must be treated as such to be successfully modified or improved
- E-typeシステムの進化のプロセスは、複雑なサイクリックな開発スタイル、内容に応じて様々なレベルでの変更の混在、そして五月雨式かつ複数のステークホルダからのフィードバックなどのおかげで大変すぎる。
E-Typeつまり、問題すらはっきりしないシステムが多くなってきた*2ことで、「ソフトウェア進化」の世界は注目をあびつつあるのだ。SaaSもひとつはその流れのソリューションだと思うのだけどね。
