システム方式設計は膨大な設計が必要です。
これをすべて設計するのは目が回りそうですね。
実はすべてを選択る必要はないのです。
システム方式設計書はひな形からテーラリングして使うものです。
今回はテーラリングについてお話したいと思います。
テーラリングとは何か
テーラリングという言葉を聞いて一般的には洋服の仕立てを思い浮かべるでしょう。
ITの世界でテーラリングというのは標準化されたプロセスや設計書を仕立て直すことを言います。
わかりやすい言葉でいうと、汎用的に作られたプロセスや設計書のひな形をカスタマイズして使うことです。
少し違うのは、不要な部分を切り落として使うお言う意味でつかわれることが多いですね。
システム方式設計書はテーラリングしよう
システム方式設計の項目については膨大なボリュームが示されています。
当サイトでも以前、概要を紹介しました。
これをすべて設計するのは現実的ではありませんし、必要ない項目もあります。
例えばバッチ処理のないシステムではバッチ方式を考える必要はないです。
このように、構築するシステムで必要のない項目は設計をしません。
標準的に示されたものをすべて使うのではなく、必要なものを選んで使うようにしましょう。
当サイトでもフルスペックのシステム方式設計を紹介していきますのでテーラリングして利用してください。
テーラリングでやってはいけないこと
テーラリングをするにあたり気を付けることがあります。
「設計するほどでもないから省略しよう」というのはNGです。
「機能がないから省略しよう」はOKです。
つまりは、実装・利用する機能があるなら必ず設計をしてください。
その理由はシステム方式設計を行う3つのポイントに関係します。
そのポイントは
・クライアントとの仕様のすり合わせ
・仕様の説明
・実現方法の具体化
の3つです。
クライアントとの仕様のすり合わせ
一つ目の目的はクライアントとの仕様のすり合わせの目的があるためです。
あなたは常識もしくは標準だと思っている方式でもクライアントも同じ考えだとは限りません。
念のため方式を確認しておくという気持ちでもよいので作成しましょう。
仕様の説明
仕様の説明はクライアントやほかの開発者と仕様を共有するために使います。
人によって考えている仕組みが微妙に違うことがあります。
しっかり認識を合わせるために、設計を行っておくことは重要です。
もう一つは自分の気付きのために作成します。
設計をしてみるといろいろな気づきがあります。
考慮が足りていないことが見つかったり、他の方式と整合が取れないことに気づくかもしれません。
例えば、「システム構成」でWebサーバの多重化をする設計をしたとします。
「オンライン方式」でセッション管理について設計したとします。
この方式は整合を取っておかないと操作をするたびに「セッションタイムアウト」なんてエラーが出ることになってしまいます。
システム方式設計をしているとこのような問題に気づきやすくなります。
実現方法の具体化
同じ方式を採用したとしても開発者間でソースコードの書き方が違うというを防ぎます。
一人で開発する場合も機能間でソースコードの書き方が違うなんてことを防ぐことができます。
保守・メンテナンス性を高めるために必要なことですね。
コメント