お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
今回は最終回のため、これまで行った分析結果を基に、対策として検討した改善案をご紹介していきます。
【なぜなぜ分析の統計】
弊社で発生した設計に関する25件の不具合を例に挙げ、未然に防ぐにはどのような対応を行えばよかったかなぜなぜ分析を実施しました。
≪障害原因の分析≫
上記より、正しい設計やPJ管理を行うことで8割の障害を回避することが可能となります。
(さらに…)お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
そこで前回同様、弊社で発生した不具合を例に挙げ、設計段階で未然に防ぐにはどのような対応を行っておけばよいか、分析結果と併せて記載します。
【事例システム詳細】
休職者支援システムにて、所属上司は所属社員の休職情報を閲覧することができる。
≪休職情報閲覧≫
【不具合内容】
2回以上休職履歴がある社員の休職情報を、所属上司が閲覧できないケースがある。
≪期待する結果≫
≪実際の結果≫
お客様へ高品質な製品をより早く提供するため、引き続き設計スキルの底上げを行っています。
そこで前回同様、弊社で発生した不具合を例に挙げ、設計段階で未然に防ぐにはどのような対応を行っておけばよいか、分析結果と併せて記載します。
【事例システム詳細】
受発注システムで受発注の変更依頼を行った場合、変更依頼されたデータはひとつ前のステータスに戻り、再確認・承認を行う順序となる。
【不具合内容】
「ステータス：3」で変更依頼を行った際、「ステータス：2」に戻らず「ステータス：3」のままとなる。
≪受発注システムのステータスの遷移順≫
≪期待する結果≫
≪実際の結果≫
Linux環境のVersionUpで他部門の方が作成した
Shellの改修を依頼されたときに気づいたことを記述させていただきます。
と言っても構文が悪いや、読みづらいといったことではありませんし、
コメント等も記述されていて比較的読みやすいものでした。
では何が気になったのか？になりますが、
依頼されたShellの改修はコマンドパスの修正でした。
この修正がどういったものかと言いますと、
例えばgrepコマンドですと
GREP_CMD=”/usr/bin/grep”
と定義し、grepコマンドを利用する際は
RESULT=`${GREP_CMD} hoge File`
というように使用する方法を取られていました。
そしてVersionUpでコマンドパスが変わったために
この定義の修正が必要となったという話になります。
この記述の方法が間違いでも、問題があるとは思いませんが、
こういったコマンドパスが変わることは
VersionUPではよくあることですので、あまりこういった定義は行いません。
ではどうするのか？ですが、環境変数を利用します。
Linuxではコマンドのパスが環境変数PATHに設定されていれば、
フルパスで記述する必要がなくなります。
そのため、
PATH=’/usr/bin:/bin’; export PATH
というように環境変数にコマンドが存在するパスを記述することで
RESULT=`grep hoge File`
と利用できるようになります。
コマンドパスが変わっても、環境変数に設定するパスにコマンドが存在する間は
改修が不要になります。
※コマンドのパスが変わることはあっても、
色々なコマンドの存在するパスは変わることは早々ありません。
今回記述したものはShellですが、Shellに限らずちょっとした対応で改修工数が不要となったり、
次の開発で拡張や改修がしやすいような状態にすることが出来たりすることがあります。
このような点についてあらかじめ軽く頭に入れておくと、
開発のちょっとした改善につながるのではないでしょうか。
