凪瀬 Blog
Programming SHOT BAR

目次

Blog 利用状況
  • 投稿数 - 235
  • 記事 - 0
  • コメント - 1350
  • トラックバック - 171
ニュース
広告
  • Java開発者募集中
  • 経歴不問
  • 腕に自信のある方
  • 富山市内
  • (株)凪瀬アーキテクツ
アクセサリ
あわせて読みたい
凪瀬悠輝(なぎせ ゆうき)
  • Java技術者
  • お茶好き。カクテル好き。
  • 所属は(株)凪瀬アーキテクツ
  • Twitter:@nagise

書庫

日記カテゴリ

 

ソフトウェアの品質と一口に言っても複数の属性が存在することは 先のエントリ でも触れましたが、この中の保守性に今回は焦点を当ててみたいと思います。

保守性が活きるかどうかは不確定

保守性というのは端的に言えば修正のしやすさを意味します。 仕様変更や追加の際の工数が小さい、その作業過程でのバグの出現数が少ない、といったところです。

さて、この保守性の高さというのは、いざ変更を行おうとする段にならないと効力を発揮しません。
例えば初期のデータ移行のためのバッチとか、そういった「使い捨て」のプログラムでは重要視されません。

つまり、将来発生するかもしれない変更に対して、工数が少なくなるように保守性を高めるということは、 アップサイドリスクである、つまり、発生するかどうかが不確かな利益であると言えましょう。

このアップサイドリスクは仕様変更があって初めて効力を発揮するものです。 そしてその価値は、

修正の発生確率 × 省略できる工数 = 保守性の高さの価値

という式で与えられるでしょう。

近年普及したリファクタリングの概念(動きを変えずに保守性を高める手法)は、 一般には手を加えることによるバグ発生のダウンサイドリスクばかりが注目されます。
しかし、リファクタリングによって得られるアップサイドリスクと比較して検討されるべきであり、 保守性というアップサイドリスクの価値をもっと関心を持って計測する必要があるのではないでしょうか。

投稿日時 : 2007年11月6日 12:58
コメント
  • # re: ソフトウェアの保守性はアップサイドリスクである
    裏口
    Posted @ 2007/11/06 13:14
    >保守性というアップサイドリスクの価値をもっと関心を持って計測する必要があるのではないでしょうか。

    計測まではあまりやってないと思います。

    但し、開発予算・期間等の関係で二次開発送りとか将来変更される部分が見えるケースでは十分に考慮した構造にしておくことは良くやります。
    # 設計書に明記&検収時にチェック
    # これができないとSE失格だと思います。
  • # re: ソフトウェアの保守性はアップサイドリスクである
    Ognac
    Posted @ 2007/11/06 13:39
    都市伝説的に言われる項目「将来使うかもしれない機能に対応する....使われたことがない.」が示すように、切り分けは難しいと思うのです。
    会計と連動しない販売管理システムの仕事であっても、会計を意識しないで販売管理を設計するのは拡張性に欠けると思うのです。
    労務管理にカレンダー機能は不可欠ですし、売掛回収はnヶ月手形を前提にするのが筋と思うのです。(3ヶ月,1ヶ月手形等の特定期日Onlyのシステムがあったりします)、回収して消しこみをする機能も考えられます。
    業務要件で不要となっても、口だけで作って隠して置くこともありました。(このあたりは意見が分かれるかと思います。)
     変更は業務ルールの追加/変更はパターン化して、ハードコーディングしないことである程度達成できそうですが、ルールの仕組み自体の変化は予測がつき難いのでリビルドになると思うのです。
    予測の付く範囲で口を設計しておくのがベターだと考えているのですが.....開発コストと引き合うか...難しいですが...
  • # re: ソフトウェアの保守性はアップサイドリスクである
    凪瀬
    Posted @ 2007/11/06 13:46
    二次開発送りなんてのは、拡張計画の具体案がはっきりしているので
    ブレが少ないのでいいのですが。
    そしてその拡張ができないような作りにしてたら確かにSE失格だと思いますね…。
  • # re: ソフトウェアの保守性はアップサイドリスクである
    凪瀬
    Posted @ 2007/11/06 13:49
    保守性が高い状態だからこそ提案できることというのもありますしね。

    システムの保守性が十分に高ければ、顧客に対して「こういう修正をしたら業務要件と合うのではないか?」と言える。
    しかし、保守性が引くければそもそも大変なことになる提案なんてしないだろう、と。

    つまり、保守性が高いと、修正の発生確率が高まるという鶏と卵のような話にもなる。
  • # re: ソフトウェアの品質を向上させるためには
    Out of Memory
    Posted @ 2008/03/27 16:40
    re: ソフトウェアの品質を向上させるためには
タイトル  
名前  
Url
コメント