2012年11月1日木曜日

ソフトウェア・アーキテクチャ設計でやるべきことってなんだろう…。

本当はもっと纏まった文章を書くつもりだったのですが、何時まで経っても纏められそうにないし、少し荒削りでも早く出すことが大事だと思いましたので、駄文ですがご容赦ください。書き出しが唐突に始まりますが、これもご容赦ください。m(_ _)m


以下のようなアクティビティを含むソフトウェア・エンジニアリング・プロセスで、ソフトウェア・アーキテクチャ設計のアクティビティでやるべきタスクについて考察してみた。

  • ソフトウェア要求定義
  • ソフトウェア・アーキテクチャ設計
  • ソフトウェア詳細設計
  • 実装
  • 単体テスト
  • ソフトウェア結合テスト
  • ソフトウェア総合テスト

ソフトウェア・アーキテクチャ設計のタスク

設計条件の確認

ソフトウェア・アーキテクチャを設計する上で重要なソフトウェア機能要求、非機能要求および制約事項をリストアップする。このとき、リストアップする要求や制約事項に漏れがあると、後の工程でソフトウェア・アーキテクチャの大規模な見直しが必要となるリスクを高めることになるため、漏れを防止するという観点から適切にレビューを実施することが重要である。
 また、ここで策定するソフトウェア・アーキテクチャは、その後23年は大きく見直すことなく使い続けることも目標とするため、将来的に導入することが予想される要求や制約事項も可能な限りリストアップする。

ソフトウェア構成の設計

上記でリストアップした要求や制約事項とハードウェア構成などをもとに、レイヤと機能ユニットの分割方針を策定する。レイヤの分割方針では縦方向の役割分担の考え方を策定し、機能ユニットの分割方針では各レイヤにおける横方向の機能分担の考え方を策定する。また、機能ユニットの分割方針は、クラスなどの静的構成とスレッドなどの動的構成の両方について策定する。
 策定した分割方針に従って、具体的にレイヤと機能ユニットの分割を行い、各レイヤと各機能ユニットの役割を明確化する。

ソフトウェア全体の振る舞いの設計

上記で分割した機能ユニット間の処理シーケンスを策定する。全てのユースケースに対して処理シーケンスを作成する必要はないが、代表的なユースケースや特異なユースケースに対する処理シーケンスは必ず作成する。ここでも、重要なユースケースに対する処理シーケンスの検討漏れを防止するという観点から適切にレビューを実施することが重要である。

インタフェースの設計

上記で策定した機能ユニット間の処理シーケンスをもとに、各機能ユニットのインタフェース仕様を策定する。

ソフトウェア・アーキテクチャ設計書の作成

上記までの検討結果を整理・体系化して、ソフトウェア・アーキテクチャ設計書を作成する。また、リストアップした要求や制約事項と検討したソフトウェア・アーキテクチャとの間に不整合はないかという観点からレビューを実施する。


ソフトウェア詳細設計のタスク

プログラムユニット分割

ソフトウェア・アーキテクチャ設計で策定した各機能ユニットのインタフェース仕様に対して、処理内容をリストアップしていき、それぞれをプログラムユニットとする。このとき、ソフトウェア・アーキテクチャ設計では検討しなかった全てのユースケースに対して処理シーケンスを作成し、インタフェース仕様を策定しておく。リストアップした処理内容に同じものがあれば、プログラムユニットを共通化する。また、各プログラムユニットのインタフェース仕様も策定する。

プログラムユニット設計

上記で分割した各プログラムユニットの処理内容を詳細化する。プログラムユニットの処理内容は箇条書きで構わないが、処理内容が複雑で誤解を招く恐れがある場合はフローチャートを作成したほうがよい。

ソフトウェア詳細設計書の作成

上記までの検討結果を整理・体系化して、ソフトウェア詳細設計書を作成する。また、プログラムユニットの分割が最適に行われているかという観点からレビューを実施する。

実装のタスク

プログラムユニットの実装

ソフトウェア詳細設計書に従って、ソースコードを作成する。また、レビューを実施する。


  現実のソフトウェア開発では、ソフトウェア・アーキテクチャ設計書は作成していても、ソフトウェア詳細設計書は作成していなかったり、作成していても更新できていないためにソースコードと内容が乖離していることがあると思われる。こうした課題の改善策は別の機会に考察する。