ソフト開発監査の監査当日（１０）設計と実装技術のチェックのポイント
設計と実装の技術はソフトエンジニアの力量に注意して監査をします
この記事では前の記事に続いてソフト開発監査の４つのチェックリストのうち最後の、設計と実装のチェックリストについて、チェックリストを使って監査を行う時のポイントを紹介します。組織の持つ設計と実装の技術力とはソフトエンジニアの技術力そのものなので、ソフト監査で行うのはソフトエンジニアの技術力の良し悪しの判断です。
設計と実装のチェックリストも開発プロセスのチェックリストと同じように、各々のチェック項目については実務・チェックリスト（開発技術・設計と実装）の記事で紹介していますので、具体的な項目に興味のある方は先にそちらの記事をご覧ください。
以下にチェックリストの例を載せてありますので、こちらも見ながら記事をご覧ください。
設計と実装チェックリスト
設計と実装の能力は具体的な問題点への対応の状況から判断します
このチェックリストの目的は、相手先の組織のソフトの設計や実装の力量の善し悪しの把握です。そのために、ソフトに関わる技術項目についての質問をして、相手がそれらの項目をどの様に認識しているのかを確認する事で、ソフト開発の技量を推測します。
しかし一言でソフト開発の技量といっても対象とする技術領域が広いので、技量の善し悪しを簡単に確認する方法はなかなか見当たりません。要求仕様の明確化や、システム設計の経験や、ソフト構造の設計や、データ構造の設計、或いはコード実装の技術、などソフトを作るための技量もあれば、社外から導入したソフトを製品のソフトと統合するための技量もあります。さらにアプリケーションソフトの領域まで考えると、ソフトを開発するために必要な技量の種類は際限なく広がってしまい、技量の善し悪しを判断する事なんてできなくなります。
とはいえ、短い時間で相手先組織のソフト開発の技量を判定しなければソフト会開発監査の目的が達成できません。そこでグータラ親父は、自分が過去に経験した具体的なソフトの問題点について相手の組織では対策をどうしているのかをヒアリングする事にしました。要するに、自分が遭遇した問題点について相手の組織がその内容や重要度を即座に理解できるか、既に対策を実施しているか、対策が未実施なら重要性を認識してなんらかのアクションを考えてくれるか、というような観点から相手先のソフト開発に関する技量を判断していました。
設計と実装の技術のチェックの注意点
開発技術のチェックリストはグータラ親父が経験した項目を抜き出したものなので、世間一般でいう所のソフト開発の技量とはズレがあるかもしれません。ここは、各々の組織で過去に問題を起こした事例等を持ってきて、確認項目とされた方が良いと思います。
とはいえ、その様な項目が揃うまでの繋ぎとしてグータラ親父のチェック項目を使われる方もおられるかと思いますので、このチェック項目を使う時の注意点を簡単に紹介しておきます。
まず最初に、購入ソフトとOSSと Free Soft の品質確認の手順についての項目が並んでいます。購入ソフトはオブジェクトやソースの形式でライセンス費を支払った購入してきたソフトです、これは昔から存在しますね。OSS はオープンソースです、最近は Linux や Android やその上で動くソフアスタックを製品用のソフトに採用する事が増えてきました。 最後の Free Soft はチップベンダ等がそのチップを使うために無償で提供しているドライバ等のインターフェース用ソフトです。多くの場合は、サンプルコードとして提供されるのでチップベンダによる保証は無く使う側の責任で品質を担保する必要があります。これを Free Soft と呼んでいます。
購入ソフト/ OSS / Free Soft のいずれの場合にも、選定方法や品質確認の方法や出荷後の保守の体制について明確なルールやプロセスを持っているかを確認します。明確なルールやプロセスを持っているという事は、これらの社外から導入したソフトも含めた全体としてのソフトに対して責任を持つ組織で有る事が判ります。要するに、「自分達の作ったソフトでは無い他社から導入したソフトなので保障できません」という様な考え方を持つ組織には、当社のソフトの開発を委託したく無いので、その確認です。
次にFROM関連の確認項目があります。 Flush ROM は昔からアクセスの速度が遅い事や特殊な手順による Erase 処理が必要な事から、RAMによるキャッシュを挟んだりアクセスの排他制御を掛けたりと、扱いが少し面倒な素子なので、それに応じてバグがよく潜在しています。最近では大容量化が進み素子の寿命が極端に短い物のあります。要するに、扱いに注意が必要な素子なので、その扱いに関する技術ノウハウをどれだけ意識しているか、でその組織の組み込みソフトに関する技量を判断していました。
その次に来るのが、タイマ/カウンタ問題とメモリリークや資源リークの確認です。これらはグータラ親父が時限爆弾バグと呼ぶバグに関する確認です。どれも、装置が稼働した直後は問題無いのですが、一定の時間を経過すると全ての製品で問題を引き起こす原因となるバグです。通常のバグ（というと定義があやふやですが）に比べて、問題が発生する範囲が極端に広く、場合によっては全製品で問題を引き起こすリスクが高いので、特に注意すべきバグです。そのような時限爆弾バグについて、リスクが高い事を認識しているかどうかを確認する事で、ソフ開発の技量を判断しています。
最後が状態遷移です。これも市場で問題を発生させると原因が見つけ難いバグです。何かの特殊な条件が揃った時に、内部の状態遷移がデッドロックを起こしてしまい、特例の状態から抜け出せずにその機能が停止する、という事を引き起こします。発生条件が特殊な場合が多いので、テストでこの手のバグを見つけ出すのは難しく、設計段階でのレビューで見つけるような仕組みが無いと対応が難しいです。なので、そのような対策がとれているかどうかを確認する事で、ソフトウエア開発の技量を判断しています。
チェックリストによる確認が終わったら監査報告書の作成です
ここまでで、チェックリストを使ったソフトウエア開発監査の進め方について紹介してきました。チェックリストを使った確認が終われば、次は監査報告書を作って監査結果を相手の組織に説明するという最後の作業です。監査報告書の作成で注意する点については、次の記事で紹介します。