ソフト開発監査チェックリスト（２０）内作ソフト設計/実装技術(前半)
設計と実装のチェックリストの最後は内作ソフトについての確認です
この前後の記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしています。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では④設計と実装の中の内作ソフト個々の項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリストその１７：開発技術・設計と実装（概要）の記事に載っていますので、そちらをご覧下さい）
内作ソフトの品質に関するチェックは具体的なバグを元にして開発能力を測る
これまで見てきた３つの社外から持ち込むソフトに対して、社内で開発するソフトについてもいろいろと確認する項目があります。社内で開発するソフトについては、設計・実装・テストを自社で実施しますので、これらの作業を品質良く実施するための良い開発プロセス（手順やルール）の確認が中心になります。
そして、この開発プロセスについては、別の記事にも書いてありますように開発プロセスについてのチェックリストを使って確認しています。ですので、この設計・実装のチェックリストではもう少し具体的な組み込みソフトでよく起きるバグについての対策状況を確認する事でソフト開発能力の良し悪しを見ていきます。
ソフト開発の現場では同じようなバグが繰り返される
もちろん種々多様なバグの全てを網羅する事などできません。でも、何年も組み込みソフトの業界で仕事をしていると同じような傾向のバグが周期的に発生するような状況がよく起こります。ある技術に関するバグが起きると、類似のバグを起こさないように対策や教育が実施され数年間はその手のバグは起きません。ところがその時にバグを経験した人達が管理職になったりしてソフト開発の現場、要するにコーディングやデバッグの現場から離れると、、、新しい人たちがまた同じようなバグを引き起こしています。昔も今も組み込みソフトでバグが多く潜んでいる、言い換えれば設計・実装が難しい箇所はあまり変わっていません。
そのような箇所について、開発チームがどれだけ認識していてそのようなバグを発生させないための注意を開発作業の中に織り込んでいるのか、という事を確認していくことで、ソフト開発組織の開発能力の良し悪しを測る事ができます。
開発現場にビギナーが多いかベテランが多いか そこが大切
実際にどの国でも、若いソフト技術者の多い所ではここに書いてあるような注意点が十分に認識されていない場合が多いです。逆に10年以上のベテラン技術者が多い所ではここに書いてある事は、そーなんだよなー、ここって危ないよなー、だからうちではこうやってチェックしてるよー、と回答が出てきます。
設計・実装・テストの全てが技術者の頭脳に依存するソフト開発では、この差はとても大きいのです。ですので、このようなソフトの設計・実装についての技術力をどの程度持っているのかを測るために、いくつかの具体的な問題点についての質問をしていくのがこのチェック項目です。では、順番に見ていきましょう。
【項目番号：IS-01】
トップバッターはFROMです。すみません、Flush ROM を FROM と勝手に省略していますが、要するにフラッシュメモリの事です。最近では SSD とか SDカードとか言ったほうが良いかもしれませんね。この Flush ROM はD-RAM (Dynamic RAM) に比べて書き込み処理に時間が掛かります。そのためにアクセスの排他制御が必要な箇所で排他制御をし忘れていると、すぐにデータの書き壊しや不定データの読み出しを起こしてしまいます。Flush ROM のデータについて、プログラムの動作に従って書き換えが発生する場合には、排他制御の必要性がちゃんと設計されて実装されているか、排他制御の要否をどうやって確認しているかとう点に注意して確認をしていきます。
【項目番号：IS-02】
Flush ROM に対するアクセスは特に書き込みに時間が掛かりますが、その時間も場合によってさらに長くなる事があります。物理的な Flush ROM チップへのアクセスまでにどんな中間処理が実行されるかにもよりますが、Flush ROM への書き込みはブロック消去と新しい値の書きみで実現されるので、このブロック消去の有無の要否で必要な時間が変わってきます。さらにファイルシステムの層が間に入っていると、時々ガベッジコレクション処理が動いて、とても長時間待たされる事もあります。 そんな場面も含めて、Flush ROM のアクセスに必要な最大の待ち時間をちゃんと推測して、ソフトウエアの設計・実装をしていないと、不要な所で何等かのタイムアウトが発生して正常な処理がエラー終了してしまう事もあります。このような Flush ROM のアクセス時間についての設計・実装上の注意がちゃんとできているか、という点に注意して確認していきます。
【項目番号：IS-03】
Flush ROM へのアクセスは、実は起動処理の時に一番多くなる傾向があります。Flush ROM からプログラムや各種設定情報を読み出したり、起動時の様々なログ情報を Flush ROM に書き込んだりと、通常の処理以外にも Flush ROM へのアクセスが多く発生します。ここでも、Flush ROM のアクセスの最大時間をちゃんと見積もっておかないと、思いもよらない箇所で処理のタイムアウトが起きてしまいます。起動時の Flush ROM へのアクセスの量とタイミングが設計・実装でちゃんと認識されていて問題が起きないようになっているか、という点に注意して確認してきます。
【項目番号：IS-04】
プログラム内でタイマーやカウンタは様々な用途で多用されますが、注意して扱わないと、時限爆弾バグを仕込んでしまい大きな問題を引き起こしてしまうリスクがあります。時限爆弾バグとは、グータラ親父が勝手につけた名前ですが、時間が経過すると必ず発生するようなバグの事をこう呼んでいます。市場で稼働している製品でこのバグによる問題が起きる時には、全ての製品で問題が発生するので、とても大きな問題になる場合が多いです。そのため、時限爆弾バグには十分な注意が必要です。そして、タイマーやカウンタはこの時限爆弾バグを引き起こすリスクがあるので十分な注意が必要です。ですので、まずはタイマやカウンタを構成している変数をリストアップして、設計/実装上の重要な項目として意識できているか、という点を確認します。
【項目番号：IS-05】
タイマやカウンタを構成する変数で一番最初に注意が必要なのが、データ型とサイズです。データ型とサイズが決まれば、そのタイマやカウンタが扱える最大値が決まります。この最大値を意識した設計/実装になっているかどうかを判断するため、まずはデータ型とサイズの決め方を確認します。当然の事ですが、そのタイマやカウンタで利用する最大値を保持できるデータ型をサイズでないといけません。特に符号付整数を使う場合には、符号なし整数の半分の値までしか保持できないので、注意が必要です。その様な観点に注意して確認をします。