shimashimaの日記: ソフトウェアの保守性 6
日記 by
shimashima
ソフトウェアの品質基準については、JIS規格の中のJIS X 0129で「機能性」、「信頼性」、「使用性」、「効率性」、「保守性」、「移植性」に分類され既定されている。
JIS規格の本文を読んだことはないが、それぞれの項目について数値化する妥当な方法はあるのだろうか。「保守性」を数値化することができれば、現状のひどさをアピールできるのだが…
ソフトウェアの品質基準については、JIS規格の中のJIS X 0129で「機能性」、「信頼性」、「使用性」、「効率性」、「保守性」、「移植性」に分類され既定されている。
JIS規格の本文を読んだことはないが、それぞれの項目について数値化する妥当な方法はあるのだろうか。「保守性」を数値化することができれば、現状のひどさをアピールできるのだが…
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
こんなんみっけた (スコア:1)
つか、軽くぐぐってみただけなんだけど、カテナ [catena.co.jp]とかいう会社が評価指標 (PDF) [catena.co.jp]なるものを公開していて、保守性を評価する指標として、
を挙げています。
指標としては分かりやすいのですが、具体的な目安となる数値が欲しいところですよね。各社が同様の指標で数値を表示することを義務付けた上で、ある程度実績が積まれたところで改めて JIS として基準値を設けるとかすれば、ソフトウェア開発も化学製品の製造ぐらいには品質の底上げが。。。ってさすがにそこまでは無理か? (^_^;
むらちより/あい/をこめて。
てゆか (スコア:1)
書いてて思ったんだけど、「時間」ってのが多いんだけど、本当は時間以外の何かで数値を表現できるならば、それに越したことは無いんですけどね。時間だとどうしても、メンテナンスを行なう人間の手腕にも左右されちゃうところがあるし、「平均」って部分にどうしても不公平が生じてしまう。メンテナに優秀な人材をつぎ込め! という方向に動いてしまうんでは本末転倒だし。
むらちより/あい/をこめて。
半世紀以上も (スコア:1)
と,私は考えていますがどうでしょうか。
Re:半世紀以上も (スコア:1)
ソフトウェアという特殊論で組み立てられたものを、数値化という一般論の世界へ引きずりおろすのは至難の業です。元々理学・工学は特殊論と思われていることから一般論を導き出す学問なので、目標としては当然存在しているだろうし研究している人もいるでしょう。ですが、どの程度一般化できるかは微妙かなぁと。
むらちさんのコメントに、カテナの事例として主に時間を指標とするとありましたが、一つの解答ではあるものの適用範囲が極めて限られてしまいます。
ある一つのソフトウェアに限っても、同じ状況で同じ修正を行うことは普通ありえないからです。修正内容を数値することができるのであれば時間の指標は使えそうですが、これはこれで数値化が難しそうです。
そもそも、いまあるソフトウェアに対する修正についての相対的な指標を得るものでって、いまあるソフトウェアの設計・実装がどの程度の保守性を持っているかどうかという絶対評価には使えないのです。
いま私が抱えている問題を解決する方法はソフトウェアの保守性についての絶対評価を行うしかなく、その手段が現在の所ないようだということはわかりました。
ですが、保守性の絶対評価指標の確立が無理かというと、できそうな気もしなくもないのです。普通のプログラマがソースを見れば、それが修正しやすいか否か、ある程度把握できます。この把握する手順については各自の頭の中、というか「センス」で行われていることですが、これを手順を追って解析できればある程度はいけるのかもしれません。
簡単なところでは、ソースチェッカレベルの解析とオブジェクト同士の依存関係の複雑さであらわせるでしょう。動的な解析は…ちょっと難しいかな。
他の産業ではどうやっているんだろうね。 (スコア:1)
よく誤解されがちなのですが、ソフトウェア開発に対する保守性と、他の製造業における保守性とでは、評価対象となるプロセスが異なっているんではないかと思うのです。
ハードウェア部品の製造にせよ、薬品や素材の製造にせよ、評価対象は製造工程を流れる output そのものです。だから、形状の正確さや物質の純度などといった、数値化しやすい指標が利用できます。これは、そもそもこれらの製造業においては、量産そのものに不具合が発生する可能性から敷かれている体制であって、そもそもの製造工程には間違いが無いことが前提とされています。
ソフトウェアは設置方法が複雑なものでなければ、よほど特殊な状況で無い限りコピーは確実かつ瞬時に行なわれるため、量産における不具合を気にする必要はありません。つまり、数値化すべき指標が設定できないのではなくて、そもそも数値化すべき指標を設定する必要が無いのがソフトウェア工学である、といえるのかもしれません。
ソフトウェアの保守性として問題になる部分は、ハードウェアについて言えば結局のところ設計という部分に相当します。実際、ハードウェアの世界においても、設計不良の為にロット単位で回収ということは日常茶飯事として行われていることです。PSP みたいな事例はあんまりにも特殊すぎますが (-_-; 。
さて、ハードウェアの製造において、設計上の不良が見つかった場合、製造工程を解析し、不具合の原因を見つけ出し、それを修正して、ラインに反映させるといった、保守作業の能率性を、時間以外の何らかの指標で示すことは可能なのでしょうか? 実は、この部分に関して言えば、他の業種においても明確な数値化なんてことは実現できていないんじゃないかと思うのです。もしもそれが、既に実現されていることであるならば、それはほぼそのまま、ソフトウェア工学においても応用が可能であり、そして今すぐにでもそれは必要なことであると思うのです。どこかの企業はそんなノウハウを、既に手に入れていたりするんでしょうかね。。。?
むらちより/あい/をこめて。
補足 (スコア:1)
数値化に拘らないのであれば、絶対的・普遍的な評価は難しいにしても、危機感を促す程度のアピールは出来ないわけではありません。いくつかやれることはあると思いますが、例えばドキュメントの減点法による評価、すなわち「不明点の洗い出し」なんかがその一つになると思います。
設計 (文書) と実装 (プログラム) の整合性が取れていない箇所について、機能単位などに項目分けし、チェックを入れていきます。具体的に、どのような問題があるのかもメモとして残して行くと良いかもしれません (指定されている名称はすでに使われていない、もしくは XXX に変更されている、そもそも実装上のどのモジュールを指しているのかが不明瞭、実際には A だけでなく B も保持している、等々)。症状に応じてランク分けし、点数をつけ、その点数が多いほど、品質は悪いものとして扱います。
文書が多岐に渡る場合には、文書間の矛盾点の洗い出しも必要になります。内部仕様が外部仕様を満足していないケースなんかも当然マイナス評価の対象となります。
この手の評価手法は、とりあえずメンテナンスが行き届いていないプロジェクトを最低限の品質にまで引き上げるのには役に立ちますが、より効率の良い体制に転換するには向かないかもしれません。しかしあまりにも成績の悪い保守体制であることが強調できれば、「作り直し」という天の声に期待をつなぐことは可能かもしれません。。。(何とも浅はかな -_-;)
設計そのものに対する評価の場合は、やはり影響範囲チェックということになるでしょうか。モジュールごとに、そのモジュールの機能に沿った変更を加えるケースを項目立て、その変更を達成するのに必要な修正のステップ数を、自モジュールと他モジュールとに分けてカウントします。特に、他モジュールに加えなければならない変更が多いほど、「酷い設計である」ということが言えることになります。
この辺は、実作業による実績からも得られる指標である為、常にその指標をチェックできる体制と環境を整えることが必要になると思います。 cvs に commit するときに追加するコメントに規則を設けて、後でツールで集計、といった形で実現できるかもしれません。どのモジュール部分に改良の余地があるかを割り出すことが出来るので、かなり前向きなチェック体制であるといえると思います。
以上、テキトーな思いつき発言でした。
むらちより/あい/をこめて。