ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第13回は、たこ焼き屋模擬店の要求仕様書から洗い出した異常系にどのような対策を行うべきかを考察する。
山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。
なお、本シリーズ第1回目を読んでいない方は、以下のリンクから一読することをオススメします。
理想的な要求仕様書は、正常時だけでなく、異常系、限界時も含めて、発注側の要求事項を漏れなくまとめ、誰にでも伝わる文書とすることです。これによって、後々発生する問題を最小限にすることができます。
過去3回は、要求仕様書のイメージをつかむことを目標として、文化祭のたこ焼き模擬店を題材とした要求仕様書を作成しています。興味がある方は、一度戻ってご確認ください。
特に、前回は、たこ焼き模擬店の異常系を階層構造で洗い出しました(図1)。
図1を見ると、模擬店とはいえさまざまな異常系が存在することが分かりますね。人間なら異常事態が発生してから対策を考えればいいのですが、コンピュータの場合、事前に異常事態を全て洗い出して対策する必要があります。銀行のシステムがクラッシュして現金を引き出せない、ロケットが爆発したなどの事故は、想定できなかった異常事態が発生した結果です。想像力の限界が品質の限界なのです。
コンピュータは、プログラムが書いてある通りでしか動作することはできません。そのため、さまざまな異常系を事前に考え、対応策を検討する必要があります。対応策を事前に検討できない場合は、どんな動きをするか予想できません。例えば、たこ焼き機が故障した場合を考えましょう。
文化祭とはいえど、学校行事をドタキャンできません。人間ならば、たこ焼き機が故障したと分かってから、柔軟に対応策を検討しますね。コンピュータは臨機応変に動作できないため、事前にいろいろなトラブルの対応策を考える必要があります。これをキチンと考えるのはものすごく大変です。「キャンパスに隕石(いんせき)が落下した」場合は、「別の安全な場所を確保してたこ焼きを続行する」ではなく、「諦める」でイイと思いますが、「小麦粉がなくなった」場合は、「近くのスーパーで買ってくる」程度の対策を考慮する必要があります。「対応する異常事態、諦める異常事態」をきっちり仕様として考えなければなりません。
今回は、前回の異常系に関する分析の続きとして、どこまで対応して、どこで諦めるかを検討します。
Copyright © ITmedia, Inc. All Rights Reserved.