運用制約
[Wikipedia|▼Menu]
.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%;font-size:90%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}html.client-js body.skin-minerva .mw-parser-output .mbox-text-span{margin-left:23px!important}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}

この記事は検証可能参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方
出典検索?: "運用制約" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL(2011年3月)

運用制約(うんようせいやく)とは、コンピュータのソフトウェアにおいて不具合が確認された場合の対応方法のひとつ。「運用でカバーする」ともいう。
概要

その不具合が、ある特定の操作を行うことによってのみ発生することが確認され、かつ不具合を修正するコストを捻出できない場合に、不具合を誘発する特定の操作を行わないよう運用に制約事項を設けることで、不具合による損失を回避するものである。

不具合を修正するコストを捻出できない場合には多くのケースがあるが、不具合の修正によってソフトウェアの他の処理の多くに影響を及ぼすことが予想される場合(影響範囲が大きい場合)が大半である。当該不具合の修正によって新たな不具合が発生しないことを、テスターと呼ばれる複数の人員が実際に操作することで確認するため、テストすべき項目が増えれば増えるほどコストは増加するのである。

近年ではテスト作業の多くをテストコードと呼ばれるソフトウェアによって自動的に行うようになっているが、画面の操作など、自動化することが難しいテストも数多くある。また、ソフトウェア開発会社からの出荷テストでは自動テストを行っても、発注者側の受け入れテスト(検品作業)においては実際の運用に即した手作業でのテストを行うため、テストにかかるコストの削減には限界がある。
問題点

ソフトウェアの運用に多数の運用制約が生じることがあり、運用担当者がすべての制約を把握しきれないために既知の不具合を発生させる場合がある。

ひとたび運用制約とした後は当該不具合を修正する責任をソフトウェア開発会社が負わず、不具合の発生を運用者の責任とされる場合が多い。


記事の検索
おまかせリスト
▼オプションを表示
ブックマーク登録
mixiチェック!
Twitterに投稿
オプション/リンク一覧
話題のニュース
列車運行情報
暇つぶしWikipedia

Size:4150 Bytes
出典: フリー百科事典『ウィキペディア(Wikipedia)
担当:undef