ソフトウェア保守とは何か?②


前回はバグ改修と仕様追加のみをソフトウェア保守している場合の問題点を私自身の経験から挙げていきました。

今回はどうすれば、安全に、楽しく、誇りを持って、本当に顧客の為に保守作業ができるか?を考えてみたいと思います。

私がポイントだと思ったのが、前回も紹介したWikipediaでの保守の定義です。下記再掲したいと思います。

ソフトウェア保守はその動機により細分できる。JIS X 0161:2008には、次の区分が定義されている。

適応保守(adaptive maintenance)
変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の引渡し後の修正。
是正保守(corrective maintenance)
発見された問題を訂正するために行うソフトウェア製品の引渡し後の受身の修正。いわゆるバグ修正。
緊急保守(emergency maintenance)
是正保守実施までシステム運用を確保するための、計画外で行われる一時的な修正。
完全化保守(perfective maintenance)
潜在的な欠陥が故障として現れる前に検出し訂正するために行う、引渡し後のソフトウェア製品の修正。
予防保守(preventive maintenance)
引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し、是正を行うための修正。

このなかの『適応保守』『是正保守』『緊急保守』は私も実行している内容です。

ポイントは他の『完全化保守』『予防保守』です。それぞれの説明で気になるのが「故障として現れる前に」「運用障害になる前に発見し」という言葉です。

つまり、常にソースコードをチェックし、テストし潜在的なバグがないかをチェックしていなければならないという事です。

これこそが、保守作業の重要な仕事であり、作業者にとってプレッシャーもなく、楽しく、誇りを持って、真に顧客の為になる作業ではないでしょうか?

そこで問題となるのが『どのようにソースコードを常にチェックし、テストをして行くか?』という事です。

開発時から単体テストから結合テストまで自動化されたテストコードがある場合はやりやすいと思います。

しかし、そんなものがないケースの方が多いのではないでしょうか?

参考にしたいのはこの書籍。。。

テストコードがないのなら、テストを書いていくのです。その作業こそが保守作業となるわけです。

テストコードがないソフトウェアって大体、結合度が高く、凝集度が低く、テストしずらいコードである可能性が高いと思います。

私の保守しているコードもUI部にほぼ全てのロジックが書かれている。しかも、UIクラスそのものを他クラスに引数として渡してしまうなんていう最悪のコードも抱えています。しかもユーザーコントロールを見境なく沢山作ってしまい、どのロジックがどこにあるかも分からない部分もあります。

それをいかにテストを書きながら、疎結合に、しかも凝集度を高くしていくか?それをこの本を参考に紐解いていくといいと思います。

具体的には結合度が高いコードは先にその上位のテストを書く、UIクラスに強く結びついてしまっている場合はUIテストを先に書く。

WindowsアプリならUIオートメーション、WebアプリならSeleniumやFitやCanoo WebTestなどが使えるかと思います。

UIの動作を保障しながら、単体レベルのテストを書いていく、リファクタリングしながらコードを修正していきます。そうしていくとバグが検出された場合も、仕様を追加する場合も、再テストする場合もこのテストが役に立って行き、プレッシャーなく変更ができるようになっていくはずです。

これこそが保守作業者のするべき仕事かと思います。

で、問題はこれを現場でどう理解してもらうか?なんですよね。。。

2件のコメント

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です