ソフト設計プロセスの改善ポイントは設計の手順と設計項目と記述様式と完了判断

2022年1月19日2022年5月19日プロセス品質

ページの概要

1. 設計プロセスは設計手順と設計項目と記述様式と完了方法の観点から改善する
2. ソフトの設計手順は具体的に決まっていて漏れは無いか
3. 設計書に書いておくべき設計項目は決まっているか
4. 設計書の記述様式はきまっているか
5. 設計の完了の判断方法や判断規準は決まっているか
6. 設計プロセスの次ぎは設計レビュープロセスです

設計プロセスは設計手順と設計項目と記述様式と完了方法の観点から改善する

ソフト設計はソフト開発の上流にある重要なプロセスで、ソフトのプロダクト品質に大きく影響します。ですので、ソフト設計プロセスのプロセス品質を良くする事は、ソフトのプロダクト品質の改善にとっても大切です。では、どうすればソフト設計プロセスの品質を良くする事ができるのでしょうか。

設計プロセスの改善の方法には色々あるのですが、この記事ではグータラ親父がソフト設計プロセスの改善のために重視していた、設計手順、設計項目、記述様式、完了方法の４つのポイントについて紹介していきます。これらの４つのポイントを意識して、現状のソフト設計プロセスの不足箇所を見つけ出し改善していく事で、ソフトの設計プロセスの品質を良くしていく事ができます。

ソフトの設計手順は具体的に決まっていて漏れは無いか

まずはソフト設計の手順が具体的に決まっている事が大切です。ソフト設計はソフトエンジニアが頭の中で考える作業が主体なのでその実態は見えにくいのですが、どんな作業が必要なのかは開発チームの中で統一されている必要があります。

ソフトの設計とは、ソフトのエンジニアが設計作業を順番に行ってその結果を成果物として記録していく事ですが、この作業の項目や順番が具体的に決まっていて、全てのソフトエンジニアが作業項目や順番を守っている事が大切です。作業項目や順番は開発組織によって変わってきますが、例えば、一般的なウォーターフォールモデルでのソフトの設計ならば、以下のような設計作業の項目とその実施の手順が決まっている事が必要です。

要求仕様や開発要件の確認：要求仕様書や要件定義書などの内容について、それを作成した部門や担当者と内容のレビューを行い、要求仕様や要件定義についての意識合わせをする。要求仕様や要件定義の１項目毎に、誰がどんな使い方をするのか、どんな機能や性能が求められるのか、世の中に競合となる製品はあるのか、などについて出来るだけ具体的に開発要件についてすり合わせる事が大切です。
開発ベースラインの確認：開発ベースラインには、①要求仕様書や設計書等の設計ドキュメントのベースライン、②ソースコードのベースライン、③開発環境のベースライン　の３種類があります。どれも重要なのですが、ソフト設計の観点から一番重要なのは、②のソースコードのベースラインです。今回のソフト開発において、「開発せずに他から持ってくるソースコード」がソースコードのベースラインです。採用するOSや流用する既存製品のソフトや利用するOSSなど具体的なバージョンをまで明確にして、開発チーム内で共有する必要があります。
ソフトエンジニアによる設計：ここは、ソフトエンジニアによる設計作業そのものですので、設計プロセスとしては特に注意する必要はありません。個々のエンジニアが自分なりのやり方で、要求仕様や要件定義を実現するために、開発ベースラインの上にどんなプログラム構成やデータ構成やオブジェクト構成でソフトを作るのか、ソフトを設計していきます。
設計書初版の作成：ソフトエンジニアが頭の中で設計した内容を、開発プロジェクトで決められた記述様式に従って、ソフトの設計書として書き出していきます。最初はメモ書きの集合から初めて、設計内容が出来上がってくるに従って設計書としての体裁が整ってきて、何度かのセルフレビューによる改定を経て、初版の設計書が作られます。
レビューによる設計書の査読と修正：ソフトエンジニアが書き出した初版の設計書は、あくまでのそのエンジニアが一人で考えて設計した内容です。人間が考えるた事なので、どうしても誤解や見落とし等の設計ミスが混入していまし。この設計ミスは、設計者本人にはなかなら見つけられないので、他の設計者やより熟練した設計者によるレビューを受けて、設計ミスを洗い出し修正していきます。設計レビューの方法には色々とあるので、開発プロジェクトではどの方法でレビューを行うのか、レビュー参加者やレビュー結果の記録・トレースの方法も含めて、明確になっている事が大切です。
設計完了の判断：何度かのレビューと修正を経て設計書の設計ミスが十分に取り除かれたら、設計が完了したと判断して次の作業段階に移行します。この、設計が完了したかどうかを判断する手続きをどうするのか、会議で判断するのか設計チームのリーダが判断するのか、具体的な方法について決めておく必要があります。

設計書に書いておくべき設計項目は決まっているか

設計の手順とともに大切なのは、どんな項目についてソフトの設計をするのかという具体的な設計項目です。要求仕様や開発要件を満たすソフトを設計するのは当然ですが、要求仕様や要件定義書に明確には書かれてはいないくてもソフトを作るために必要な設計項目もあります。これらも含めて、設計が必要な項目が漏れなく洗い出されている事が大切です。例えば、以下のような項目が設計すべき項目として決まっていると、設計の漏れ・抜けが防げます。

機能の実現方法：どんなアルゴリズムに従って機能を実現するのかというソフト設計の根幹の部分です。入力されるデータに対してどんな処理を行い出力のデータを作り出すのか、基本的なアルゴリズムを設計する項目です。
必要なデータ構造：入力データや出力データの構造に加えて、ソフトの内部で制御や途中結果の保持のために中間データを使う事も良くあります。各々のデータ構成メンバやデータに対するアクセス方法、データの記憶場所も含めて、必要なデータ構造を設計する項目です。
インターフェース方法：ソフトは何等かの手段で外部に機能を提供しますが、その機能提供の出入り口がインターフェースです。どんなインターフェースを使って機能を提供するのか、同じCPU内の他のソフトに対するインターフェース、ネットに繋がった他のコンピュータのソフトに対するインターフェース、ソフトを使う人間のオペレータに対するインターフェース、などさまざまなレベルでのインターフェースがありますが、それらを具体化する設計の項目です。
性能の実現方法：ソフトが提供する機能は十分な性能を持っていないと使い物になりません。性能の測り方は色々ですが、機能を提供する時の応答性や単位時間あたりに処理できる件数、同時に複数の処理を実施できる最大数など、性能に関する目標を実現するためにどんな構造のソフトとするのかを設計する項目です。
安定性の実現方法：組み込み系のソフトは24時間365日稼働し続ける事が求められます。稼働している最中には、通信エラーやオペレータの誤操作、装置のハード故障等が発生する事もありますが、その様な時にも適切に対応する必要があります。故障からの回復機能、長時間の連続稼働を維持する機能、高負荷の状態でも動作を続ける機能など、安定性を実現するために内部に組み込む機能を設計します。
保守機能：通常の機能・性能の設計とは別に、装置やソフトに問題が起きた時の対応の機能も設計が必要です。故障が起きた時に故障からの自動による回復やオペレータからの指示による回復を行う機能や、故障の原因を調査するのためのデータの収集を行なう機能や、バグ修正版のソフトと入れ替える機能など保守機能について設計する項目です。
セキュリティ対応：コンピュータが社会生活の殆ど全ての場面で使われるようになるとともに、サイバー戦争も激化してきました。多くの機器がインターネットに接続されて動作する現状では、組み込みソフトにおいてもセキュリティ対応が必須です。に外部からのサイバー攻撃に対応するための設計や既存の脆弱性の回避のための対応などを設計しておく必要があります。

設計書の記述様式はきまっているか

ソフト設計の結果は設計書として書き出しますが、どんな様式を使って設計書を書くのかは開発プロジェクトとして決めておく事が大切です。設計書の記述様式が統一されていないと、設計レビューによる設計ミスの発見の効率も低下しますし、なによりもソフトの保守性も大幅に低下します。保守開発では、既存のソフトの内容を理解するために設計書を読む事から始まりますが、設計書の記述様式がバラバラだと、読む気も起きません。

ソフトの設計書に使う様式には、昔からあるフローチャート、シーケンス図、状態遷移図や状態遷移表、タスク構成図、IPO図　など色々な表現方法がありますし、オブジェクト指向の設計の場合にはUMLでのクラス設計図　なども必要になります。どの様式を使って設計書を書くのかはプロジェクトの初期の段階で明確にしておきましょう。

複数のソフトエンジニアが共同して開発を進める場合には、特にインターフェースの記述方法はしっかりと決めておきましょう。機能の利用の仕方、正常な応答とエラー時の応答、処理に掛かる時間や処理の順番の制御の有無などについて、ソフトエンジニアの間で正確に伝わる事が大切です。

設計の完了の判断方法や判断規準は決まっているか

ソフト設計の完了の判断はとても難しいです。設計内容に潜在的なミスが無く、機能・性能・安定性などの要求仕様を十分に満たす設計になっている事が確認できれば設計完了とすれば良いのですが、、、確認する手段がありません。ソフトは設計しだけではまだ設計書に書かれた「構想」に過ぎず、実際に動作する実態が何もありません。そのために、実際に動作させて機能や性能が正しいかどうかを判断するというテストの手段が使えないので、設計の良し悪しが判断し難いのです。

設計完了の良い判断方法や判断規準は無いのですが、良く使う設計完了の判断方法としては、設計レビューを繰り返して行って、新たな指摘事項が見つからなくなった事をもって設計完了と判断する、という物でしょうか。　設計レビューの参加者や設計内容の複雑さにも影響されるので、少々あやふやな判断規準なのですが、何等かの判断方法や判断の基準は決めておかないと、設計完了の判断が難しくなります。