ソフト開発監査チェックリスト（２１）内作ソフト設計/実装技術(後半)
ソフト開発監査のチェックリストの開発技術・設計と実装の項目を紹介しています
ソフト開発監査は、ソフトの開発委託先の能力を判定するためにグータラ親父が勝手に命名した監査の方法です。ソフト開発監査の概要や監査時の事前の準備や監査当日の作業内容については、他の記事で紹介しています。また、ソフト開発監査で使う監査チェクリストの使用時のポイントについても、別の記事で紹介していますので、そちらをご覧ください。
この前後の記事では、前の記事に続いて開発技術のチェクリストの中の設計と実装について、内作ソフトに関するチェック項目の残りを紹介します。
【項目番号：IS-06】
タイマーやカウンタはインクリメントやデクリメントされて使われる事が殆どです。インクリメントやデクリメントの操作の結果、タイマやカウンタが保持できる最大値や最小値に達してさらにインクリメントやデクリメントをすると、タイマやカウンタの値がゼロになるロールアップ現象が起きます。
タイマーやカウンタは何等かの値と大小の比較をする事が多いのですが、ロールアップによりゼロになった時にでも大小比較が本来の意味を保てるようなコードの作成をしておかないと、その時点でプログラムの動作がおかしくなってしまいます。ですので、このようなロールアップ時の処理を適切に設計・実装するようなソフト開発の仕組みができているかという点に注意して確認をします。
【項目番号：IS-07】
タイマーやカウンタのロールアップ処理は、設計・実装での確認と合わせて、テストによる確認も重要です。実際にタイマーやカウンタを構成する変数の値をロールアップ直前の値に設定してプログラムを実行し、ロールアップ処理が正しく実行される事の確認がソフト開発の仕組みに組み込まれているか、という点に注意して確認しましす。
【項目番号：IS-08】
タイマーやカウンタの次に時限爆弾バグのリスクが高いのが、メモリリークです。起動時は問題なく動作していたのが少しずつメモリリークが進んでいき、起動から10か月たった時点で空きメモリが無くなってシステムがハングする、なんていう事が起こるのがメモリリークバグの怖いところです。
社内のテストでは、メモリリーク状態を意識して作り出さない限り、潜在するバグを見つけるのは困難です。このメモリリークを引き起こすのは、動的に獲得と解放を行う事のできる動的メモリと呼ばれる種類のメモリですのが、まずはそのような動的メモリを注意が必要な物として管理しているかどうかという点を確認します。
【項目番号：IS-09】
動的メモリを使っている場合には、メモリリークが起きない事が一番良いのですが、残念ながら全てのメモリリークを事前に見つけるのはなかなか難しいのが現実です。例えば、何等かのエラー処理が実行された時にだけ実行されるコードでメモリリークがあったりすると、エラー処理を加速した状態でリークの有無を確認するテストをしないと、その問題を再現する事さえできません。
このように全てのメモリリークを見つけるのが難しいので、最低限の対策として万が一メモリリークが発生した時にその事を検出する処理を組み込むのも一つの対策方法です。そのような事を考えて設計・実装がされているかという点に注意して確認していきます。
【項目番号：IS-10】
動的メモリでメモリリークが発生しいる事を検出した場合にはいくつかの対策方法があります。プログラムの動きを縮退動作モードにしてオペレータ介入を待つとか、システムを再起動してメモリリーク状態を解決するとかですが、どの場合でもそのソフトが本来提供している機能を一時的に中断する事になるので影響は大きいです。それでも、メモリリークによりシステムがハングして何も応答しなくなるよりは幾らかはましですので、そのような設計・実装がなされているかという点に注意して確認をしていきます。
【項目番号：IS-11】
メモリのリークはソフトウエアの世界では割と有名な問題ですので、設計・実装の担当者でも気を付けている人が多くなってきました。ところでリークをするのはメモリだけでしょうか？ 実は動的に獲得と開発をする資源であれば、その資源の解放処理が抜けてしまうと、そこで資源のリークが起きます。
具体的には、ＯＳが提供するソケットやアプリケーションソフトが提供する登録;/削除が可能なテーブルのエントリは動的資源なのでリークが発生し得ます。このような、メモリ以外の動的な資源についてもリークのリスクがあるので動的メモリと同じように、注意が必要な物として管理しているかどうかという点を確認します。
【項目番号：IS-12】
メモリ以外の動的資源についても、メモリと同じように資源がリークした時にこれを検出する仕組みが対策として有効です。このような対策が設計・実装で検討されているか、とう点に注意して確認します。
【項目番号：IS-13】
メモリ以外の動的資源についても、メモリと同じくリークして枯渇してしまった時には可能ならその回復処理を実施して動作を続けるほうが、何もせずにハングしてしまうよりも良い場合が多いです。そのような設計・実装がなされているか、とう点に注意して確認をしていきます。
【項目番号：IS-14】
他の装置や他のソフト機能と連携しながら動作をするソフトの場合には、その連携処理が一定の時間以内に終わらなかった場合に相手からの応答待ちから抜けるためのタイムアウト処理を組み込むのが普通です。このタイムアウト処理では、タイムアウトの時間を設定する時にどれだけの余裕時間を織り込むかが結構大切です。
余裕時間が長すぎるとタイムアウトの検出が遅れてしまいますし、短すぎるとちょっとした処理時間の揺れでタイムアウト処理が走ってしまいます。どのような考え方や計算の仕方でタイムアウトの余裕時間を決めるのか、ある程度定型化した方法が決めてあると、誰が設計しても同じようなレベルのタイムアウト処理が作れます。そのような事が開発のプロセスの中に作りこんであるか、という点に注意して確認をしていきます。
【項目番号：IS-15】
タイムアウト処理が実行されるまでのタイムアウト時間は、連携する機能の応答時間と自分自身の処理時間と連携のための通信時間に左右されます。このうち、自分自身の処理時間は、機能の追加や不具合修正等のソフトウエアの変更によって変わる場合があります。そのような時には、処理時間の変化に合わせてタイムアウト時間の設定値も変える必要があるのですが、そのような確認の仕組みが開発プロセスの中に作りこんであるかという点に注意して確認をしていきます。
【項目番号：IS-16】
組み込み系のソフトでは、状態遷移の設計をわりとよく使います。状態遷移の設計は制御の条件が複雑な問題をできるだけ簡単に設計するための設計手法なので、状態遷移の設計をするという事は制御が難しい問題だという意味です。
ではどんな場合なら状態設計が必要になるのでしょうか？ どの程度の難しさがあったら状態遷移の設計を使うほうが良いのか、何等かの判定の基準があれば誰でも迷わずに状態遷移の設計を行えます。そのような確認の仕組みが開発プロセスの中に作りこんであるかという点に注意して確認をしていきます。
【項目番号：IS-17】
状態遷移の設計では、状態遷移図や状態遷移表をつかって設計を進めるのですが、慣れていないとなかなかうまく設計が進みません。また、設計者が考えた状態遷移の設計内容は、他の設計者や開発リーダが設計レビューをして間違いがないかどうかの確認をします。その様な時に、状態遷移の設計の方法が統一されていないと設計の漏れが出たり、その漏れや間違いをレビューで見落としたりします
その様な事が起こらないようにするためには、状態遷移の設計やレビューの方法がある程度決めておくと効果があります。そのような事が開発プロセスの中に作りこんであるか、という点に注意して確認をしていきます。
【項目番号：IS-18】
状態遷移の設計はそのレビューも大切です。通常の設計レビューに加えて、状態設計に特徴的な設計内容をレビューしていく必要があります。状態設計のレビューの時にどんな点に注意してレビューをしていけば良いのかか、そのような事が開発プロセスの中に作りこんであるか、という点に注意して確認をしていきます。
チェックシートの内容にはダブりもありますが、まあ気にせずに・・・
ここまでの記事で、ソフト開発監査で使う４つのチェックリスト ①開発プロセスのチェックリスト ②開発技術の要求仕様のチェックリスト ③開発技術のテストのチェックリスト ④開発技術の設計・実装のチェックリストについて順番に紹介してきあしたが、いかがでしたでしょうか。
ソフト開発監査というものが、グータラ親父が勝手にな名前を付けた作業なので、なんかよく判らないところもあると思いますが、まあそんな物だと思って下さい。 あくまでも、監査先の組織のソフト開発能力の良し悪しを大雑把に把握して、改善点があればそれを洗い出して改善をお願いする、という作業を１日から３日という限られた時間の中で効率的に進めるためのワークシートがチェックリストだと思ってもらえば大丈夫です。
とはいえ、なかりの項目数があるので、一度見ただけでは判りにくいところも多いと思いますが、それでも気にする必要はありません。自分が判り易いようにどんどん変更していけばそれで良いと思います。 この記事が少しでも皆さんのお役に立てばグータラ親父としても頑張って書いた甲斐があります。