イチから全部作ってみよう(24)設計フェーズの入り口「画面設計書」は紙芝居!?:山浦恒央の“くみこみ”な話(193)(2/3 ページ)
ソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」。第24回からは設計フェーズに入る。基本設計書と詳細設計書の例を示した後、ECサイトを事例にして設計フェーズの入り口に当たる「画面設計書」を作成する手順を紹介する。
3.画面設計書から考えよう
設計フェーズの進め方にはいろいろな手順がありますが、今回のECサイトやATM(現金自動預払機)のように画面が主体となるソフトでは、画面設計書を入り口にすると視覚的に分かりやすいでしょう。また、処理も各画面対応に書けばよいので、システム全体としては複雑でも画面単位では複雑さを小さくできます。
3.1 画面設計書とは
画面設計書とは、画面遷移や表示レイアウトを定義した文書です。画面設計書に似た身近な文書の例には「紙芝居」があります。
紙芝居では、話し手が聞き手に絵を見せながら物語を読み進めます。同様に、画面設計書でも、画面を紙芝居のように順番に記述することで、必要な処理、画面レイアウトやデータ項目が明確になります。
3.2 お題
ここで、画面設計に関する「お題」を出しましょう。図3に示す業務フローから必要な画面を洗い出してください。なお、厳密な答えがあるわけではないため、図3の内容に捉われず身近に使用しているECサイトを参考にしてもいいでしょう。
3.3 解答例
画面設計の解答例は、業務フローの四角で示した処理から、以下のようになります(画面と処理番号を示します)。
- サイトのトップページ:(1)
- カート画面:(2)
- 顧客情報&支払情報入力画面:(3)
- 購入確認画面:(4)〜(7)
- 購入完了画面:(8)
なお、どの画面をどのように設計するかは発注側と協議して決定します。例えば、顧客情報入力画面と支払情報入力画面を分けた方がいいという場合もあるでしょう。画面遷移や画面の詳細設計は、ソフトウェア開発に詳しくない発注側が理解できる唯一の設計ドキュメントなので、ボタンの色、形、配置など、いろいろな要望が大量に出てきます。この段階で、発注側と開発側できちんとすり合わせておくことは非常に重要です。
ただし、発注側が「夢のような機能」に興味を持った場合、実装するには時間もコストもかかるので、開発規模が大きくなる要望は、全力で阻止しなければなりません。
Copyright © ITmedia, Inc. All Rights Reserved.