IT技術 副業

システム方式設計はいつ作るのがいいのか。工程を知ろう。

IT技術
おく
おく

システム方式設計書を作るのはどの工程か?
どの時点で作るのがいいのか。
意外と難しいのです。
システム方式設計の使い方を考えながら、どの工程で作成するのがよいか説明しましょう。

結論

要件定義、基本設計(外部設計)、詳細設計(内部設計)の工程にわたって作成します。
中心は基本設計になりますが、要件定義から段階的に詳細化していきます。
工程に合わせて段階的に詳細化していきます。
要件定義の工程ではクライアントと仕様を詰める中で、システム方式についての仕様を詰めていきます。
基本設計の段階では一気に仕上げていきます。
基本設計を行うための共通仕様を作っていくの、基本設計の本格着手に先駆けて作成します。
詳細設計の工程ではコーディングにかかわる部分を追記する程度になります。

まずは、システムの開発工程を理解しよう

システムの開発にはV字モデルというものが用意されています。
主にウオーターフォール開発に用いる工程の考え方です。
アジャイル開発の場合は厳密なV字モデルで開発しませんがシステム構築の会話をするときの基礎となっているので知っておいてください。
また、日本的なアジャイル開発では短期ウオーターフォールになっていることが多いので意識しておくといいでしょう。

V字モデルです。
基礎知識となるので説明をしておきます。

まず左側の下に流れていく四角について。
オーナーと仕様を詰めて、設計して、プログラムを作る流れを表現しています。
右側の上に流れていく四角は、作ったプログラムをテストする流れになっています。
図の上側の工程(要件定義やシステムテスト)を上流工程、下の工程(コーディング)を下流工程といいます。

要件定義

クライアントと作るシステムの仕様を決めます。
どんなことができるシステムにするのか、どんな画面(簡単なイメージ)を作るのか、どんな操作をできるようにするのか。
大まかな設計書を作成します。

基本設計

画面の詳細や操作の詳細を決めます。
画面に配置する1個ずつの項目について決めていきます。
ボタンを押したときの動作についても決めていきます。

詳細設計

操作をしたときの裏の動きを詳細に決めていきます。
あまり利用者には見えない内部処理を設計していきます。

コーディング

プログラムの作成をする段階です。

単体テスト

作成したプログラムをメソッド、クラス単位での動作テストをします。
詳細設計で決めた仕様に沿って、詳細設計書の単位で設計通りにできているか確認します。

結合テスト

単体のプログラムをつなげて、つなぎの部分(インターフェイス)の動作を確認します。
また、基本設計で決めた操作に沿って動作するかも確認します。

システムテスト

要件定義で決めた設計に沿って動作するかテストします。
主に、実際に使用するシナリオに沿って動作することを確認します。

リクエストがあれば各工程の説明もしたいと思います。
システム方式設計の中で説明すると長くなりすぎるので簡単な説明にとどめます。

システム方式設計を作成する工程

システム方式設計を作成する工程は要件定義から詳細設計工程です。
主な工程は要件定義と基本設計の工程です。
下流工程に向かって段階的に詳細化していきます。

例えば次のようなことです。

システム方式設計:要件定義で決める事(概要)

主にはどのような環境でシステムを動かすかを決めます。
サーバのスペックや、多重化されているのか、インターネットにつながっているのか社内セキュリティの中にあるのか、データベースはどの製品を使っているのか、どんなアプリ(ミドルウェア)が入っているのかなど。
これから作成するシステムの概要を聞いて、どんなサーバやアプリが必要なのかを決めていきます。

副業などソーシャルワークのお仕事の場合、このあたりは決まっていることが多いでしょう。
その場合、提示された条件に間違いが合ないかを確認しましょう。
もしくは、改善提案を行えると次のお仕事につながるチャンスです。

また、ここでしっかり環境周りの条件を確認しておくことでご自身の身を守ることができます。
提示された条件に誤りがあった場合、アプリ側の仕様変更を求められることもあります。
事前に誤りに気付いておけばこのようなトラブルを避けることができますね。

システム方式設計:基本設計で決める事(概要)

共通的な操作感や共通的な内部仕様を決めていきます。
この工程でシステム方式設計の大半を決めていきます。
利用者に影響する操作感から、内部処理の共通化などです。

例えば、
データを登録する画面は「登録」ボタンを押すと、確認メッセージを出して、さらに「OK」を押すと実際に登録される。
といったことです。
こっちの画面、あっちの画面で動きが違うと操作感がイマイチですからね。

内部仕様的なところでは、こういう単位でクラス(部品、モジュール)を分けるなどです。
こっちの機能は同じメソッド(クラス)にすべての処理が書かれている。
あっちの機能では細かく部品化されている。
などでは、あとからメンテナンスするときに修正がやりにくくなります。

他には、データベースにデータを登録するときの手順なども決めます。

そのほかにも大量に決めることがあります。

システム方式設計:詳細設計で決める事(概要)

この工程で新たに決める事はほとんどありません。
システム方式設計に従って一気に詳細設計を進めていく段階なので、基本的にはすべてが決まっているべきです。
しかし、基本設計の中で決めきれず先送りにしたことや、詳細設計をしていく中でシステム方式設計にしておきたいことが見つかる場合があります。
システム方式設計の修正フェーズと考えていいでしょう。

コメント

タイトルとURLをコピーしました