新人研修の本に沿ってJavaで開発してみる

全体の流れ

必要書類を作成しながらシステム開発の流れを体験することが目的なので作るものは簡単なものにします。

1. 要求定義・要件定義(別称：基本設計・要件定義企画)

2. システム提案

3. 外部設計(別称：機能設計)

4. 内部設計(別称：詳細設計)

5. 製造(別称：コーディング)＋単体テスト(別称：単体試験)

6. テスト(結合テスト・総合テスト(別称：~試験・総合運転試験))

7. 受入テスト

   要求定義・要件定義工程で必要な書類を作成

   顧客の要求(要求定義)を引出し文書にまとめる・作るものの指標

   要件定義書

   外部仕様：背景・課題・目的・方針・概要・機能・システム化の範囲(ユーザインタフェイス・システム構成)
   運用：導入・移行計画・運用保守
   共通：工程計画・体制・成果物(作業標準・品質管理)
   要求には機能要求と非機能要求があり、システムの基本機能(登録機能・検索機能など)は機能要求、処理速度や故障時の要求は非機能要求となる。

   顧客に提案と説明を行う

   システム提案書

   外部仕様：背景・課題・目的・方針・概要・機能・システム化の範囲・システム構成・ソフトウェア構成・ ハードウェア構成・ネットワーク構成・システムインターフェイス(ユーザインタフェイス)
   　運用：導入・移行計画・運用保守
   　共通：作業標準・品質管理・工程計画・体制・費用・工数・規模・成果物(開発環境)

   社内での開発の意思決定を記録する...本来なら個人開発ならこっちをやるのだけど今回はやらない

   開発計画書

   外部仕様：目的・方針・概要・機能・システム化の範囲・システム構成・ソフトウェア構成・ハードウェア構成・ネットワーク構成・システムインターフェイス(ユーザインタフェイス)
   運用：導入・移行計画・運用保守
   ※括弧内はあってもよいもの

   実践

   顧客の要求定義　入力した言葉を表示する・文字が見やすい・画面サイズは邪魔にならないくらい

   書類の第？.？版
   .の前が社内検討中は０顧客提出済みは１で大きな内容修正ごとに＋１する
   .の後は小さな修正ごとに＋１で.の前の数が＋１したら０に戻す
   .の後の数は１０になってもｘ.10となり.前に繰り上がらない

   1.要件定義書

---

テキストの入出力システム　要件定義書　第１．０版　２０２０年２月１５日　

1. 背景　システム開発の流れを汲むテストとして　
2. 課題　モノづくりでの計画性と他者目線を養うには
3. 目的・方針　計画的なモノづくり
4. 概要　テストのため開発自体に時間を割かない
5. 機能　文字を入力して入力した文字が見やすいサイズで出力できる
6. システム化の範囲　あくまでテストなのでネットワーク・スマホ画面での使用は考えないものとする
7. 　導入・移行計画・運用保守　(いつ導入するかバックアップや故障時の対応についてや運用スケジュール)テスト用のため不要
8. 　工程計画　(仕様凍結(仕様変更の期限)・設計完了・開発完了・試験完了・導入の日付)全項目：2020年2月24日
9. 　体制　(システム部門・運用部門の責任体制を定義) システム部門はシステムに対して導入まで責任を持って対応する
10. 　成果物　(この定義書をはじめ、出来上がる資料・ファイル・マニュアルなど)(1)要件定義書(2)システム設計書...以下略

---

2.システム提案書

作成時の心得：システムの理解とシステム化の意義と自社の信用を意識する
システム提案書でわかるべきこと：システム化により解決する問題・機能・構成・必要日数・必要費用...あいまいな所を明確にする
作成手順：要件定義書からシステムをイメージ　→　使用技術の洗い出しと技術について調査　→　システム構成決定　→　システム開発にかかる期間・費用を見積もる　→　提案書にまとめる　この後関係者にレビューしてもらって完成度を高める
※顧客へのプレゼンテーションにあたるので書き方は丁寧に一貫性を持った文にする

---

テキストの入出力システム　システム提案書　第１．０版　２０２０年２月１５日

1. はじめに(あいさつ文/背景)　

   プログラミングの需要が高まる今日この頃、ポートフォリオの一環として始めました。Javaプログラマーを目指して少しでもシステム開発の理解を深めるために簡単な開発ではありますがこの流れを知ることは一人での開発では決して得られない作り手目線ではなく実際に使う誰かのためのモノづくりへの第一歩と思い作成しております。開発のより大きな流れを汲むべくこの小さな開発・テキストの入出力システムを提案いたします。

   2．解決できる課題(システムにより解決できること)

   要件定義書の　２．課題　で示されていた　計画性と他者目線を養うには　を対象としています。

現在個人でのプログラミング学習における制作物は自身の作りたいものが中心となっており、人に見せられるか、役に立つかが二の次となっております。中途半端に終わっているものもありプロを目指す上で必要な自走力や問題解決力はもちろんのこと、計画性や開発上の他者目線の不足を感じております。

3．課題解決のための提案

本提案書では表記課題を解決するものとして「テキストの出入力システム」(小さなシステム開発)によりシステム開発の流れを体験することを提案いたします。

このシステムの開発によって開発者が知るべきシステム開発の大きな流れを把握し、開発の計画・必要な機能の取捨選択を開発者目線だけではなくより広い目線での開発計画を立案できるようになることが期待できます。

4．課題解決のための方法

このシステムでは以下の課題を学習します。

• システム開発の上で必要な書類を作成する
• 作成した書類に沿って実際に開発を行う
• 開発後のテストも行う
• 終了時おまけとして開発以外についてまとめる

5. 機能概要(機能)・前提条件・制約事項(システム化の範囲)

5.1　機能概要

データを入力してボタンを押すと入力したデータが表示されます。 テスト用のため余計なことはせずシンプルな仕様になります。

5.2　前提条件

本提案書では以下を前提条件とします。

• システム開発の流れを知るためのテスト開発であること
• システムそのものは容易に開発できること

また、制約事項としては、以下の点があります。

• テスト工程まで行うので最低動くものでなくてはいけないこと

(利用者のいるシステムの場合人の流れ・情報の流れを次に説明する　ないので割愛)

6.　システムインタフェース

PC一台で完結するため割愛 (利用者のいるシステムの場合想定する利用者を次に説明する　ないので割愛)

7.　システムのハードウェア構成、ソフトウェア構成

利用端末	1台

8. 導入・移行計画

   (１)２０２０年２月２４日をもって、テストとしての開発を終了します
   (２)出来上がったものはgithub及びgitpressに置きます

9. 　運用・保守

   (１)githubに置いたものは自分用メモとして置いておきます

10. 作業標準(作業上の方法・管理条件の標準でここではどこの作業標準を使用するかということ)

    システム開発に掛かる作業標準は自社のものをします。

11. 　品質管理

    システム開発に掛かる品質管理手法は自社のものを使用します。

12. 　工程計画

　　工程計画は次のとおりです。

使用凍結：２０２０年２月２３日
設計完了：２０２０年２月２３日
開発完了：２０２０年２月２３日
試験完了：２０２０年２月２３日
導入　　：２０２０年２月２４日

13.　体制

このシステムの開発は弊社システム部門のプログラマー1名により実施します。

14.システム開発に掛かる費用

本来は表を用いて端末・周辺機器・サーバ・工事費・導入経費・保守・管理費・システム開発人件費と合計を表示する。 また、利用者増加の売り上げ増加などが見込まれるものは算出根拠も一緒に提示する。

15.　このシステム提案のアピールポイント

(１)　言語の学習以外での独学としてシステム開発全体の仕事の流れを把握することができます。 (２)　学習の基本として実践することにより学習したことのの定着が期待できます。

(次に用語の定義の項目があるが割愛)

---

外部設計・内部設計工程で必要な書類を作成

要件を実現する方法を技術的に検討する　　外部ではシステム機能を定義し内部では外部を基に内部データを決め、具体的な実現方法の定義を行いサブシステムをモジュールに分解し外部仕様を満たすようにモジュールの動作を定義する

外部設計書

外部仕様：目的・方針・概要・機能・ユーザインタフェース・システム構成・ソフトウェア構成・ハードウェア構成・ネットワーク構成・システムインタフェース

内部設計書

外部仕様(あってもよい)：機能・ユーザインタフェース・システム構成・ソフトウェア構成・ハードウェア構成・ネットワーク構成・システムインタフェース 内部仕様：プログラム構造・データ構造・ネットワーク構造・処理ロジック・メッセージ

外部設計書の作成手順

個別設計書の作成し、外部設計としてまとめるが個別設計書の種類はシステムの種類で違うので今回は業務システムの手順で行う

個別設計書の作成:業務フローの作成 → サブシステムへの分割 → 画面レイアウト/帳簿レイアウトの作成 → コード設計 → 論理データ設計(ER図、CRUD図作成) → システムインタフェース設計 → 外部設計書としてまとめる

業務フローをDFDで作成

サブシステムへの分割...システムを分割して機能を定義して各設計書を作成する

小さいシステムではサブシステムがプログラムモジュールにあたるが大きなシステムではサブシステム内に複数の機能を含む場合がある

画面レイアウトや帳票レイアウトの作成

帳票はプリントアウトする用紙の構成で帳票デザイン・各項目の表示内容・表示桁数・表示するデータのタイプ・項目の必須/任意の記述
画面はディスプレイ表示の画面構成で情報表示と入力受付・入力を表示に反映させる・複数画面への遷移を適切に表すための部品配置入出力値タイプ・表示条件・初期値などの入出力項目・画面遷移順を示す画面遷移図・画面遷移や情報更新のイベント発生タイミングなど細かく記述する

コード設計

書き表し方・入力者により表記のバラツキがあるデータは外部の段階でコード化しておく
性別・都道府県などに番号や英数記号のコードを割り当てておく
→コード定義書

論理データ設計

保持データや関連データベース構造の定義をする
データ構造・関係をER図やCRUD図で表し、処理に適したデータの構造を作りデータベースのテーブルの種類や構造の一覧表もここで作る
→テーブル定義書
ER図：Entity Relationship/エンティティ(実体)に複数の属性(アトリビュート)を持たせて相互関係のリレーションシップ(関連)を表す図
CRUD図：操作実行時ER図のエンティティにどうアクセスが行われるかを表で表し、アクセスとしてC(Create/生成)・R(Refer/参照)・U(Update/更新)・D(Delete/削除)の4種で表す

システムインタフェース設計

システムインタフェースは外部とデータをやり取りする場合設計する
ファイル仕様書（外部とやり取りするファイルの仕様):文字コード・改行コード・フィールド構成・値タイプ・空データ可否・最大レコード数など
データ交換仕様書（やり取りするデータの内容）:使用ネットワーク媒体の種類・トランスポートプロトコル・アプリケーションプロトコル・交換データの形式など

3.外部設計書

個別設計書を外部設計書の構成に当てはめる 画面レイアウト　→　ユーザインタフェース、コード定義書/ＤＢ一覧表/ＥＲ図/ＣＲＵＤ図　→　ソフトウェア構成、ファイル仕様書/データ交換仕様書　→　システムインタフェース

---

テキストの入出力システム　外部設計書　第１．０版　２０２０年２月１７日

1.　目的
　ポートフォリオの一環として、テキストの入出力システムのシステム外部から見た設計条件を規定する。

2.　システム概要
　本システムは入力データを１クリックで出力するテスト用の簡易な構成とする。

(１) 利用者が入力し「表示する」のボタンを押すと出力画面に入力文字が表示される
(２) 入力データは記録されず表示のみされ、もう一度ボタンを押すと消える

3.　機能
　 入出力画面　出力欄への情報入力機能

4.　ユーザインタフェース 　 (1)入力端末のユーザインタフェース
　アプリをダブルクリックすると起動し入出力画面を表示する
↓
入力のテキストに任意の文字を入力し、「表示する」のボタンを押下すると出力欄に文字を出力する
　　　　　　　　↓
ボタンをもう一度押すと文字が消える

5. システム構成

規模が小さすぎて図にしようがない．．．できそうなら更新する

6. システムインタフェース

規模が小さすぎて図にしようがない．．．できそうなら更新する

---

内部設計書の作成手順

内部設計書はプログラム製造時のミスを防ぎ早い段階での品質を担保する/品質が均一なプログラムを製造する/複数の開発会社で製造する場合の結合を容易にする/プログラムの部品化を容易にする...という目的で作成される

設計手法として一般的に使われるものが製造で使用するプログラミング言語の特性に合わせた設計手法、よく使われるものとして構造化設計がある
構造化設計　機能を小さな機能の集まりで作られると考える
　　　　　　メリット：プログラムの全体像と詳細を把握しやすく目的に応じてシステムを展望できる
　　　　　　デメリット：機能に重きを置いた設計のためデータがおろそかになり重複/不整合を招く恐れがある

オブジェクト指向設計　データと機能をオブジェクトにカプセル化して構築する

※どちらがいいかではなく考えて設計することが大事

個別設計書の作成：画面の詳細設計→帳票の詳細設計→外部インタフェースの詳細設計→ビジネスルールの詳細設計→リクエスト処理の詳細設計→メッセージの詳細設計→物理データ設計→内部設計書としてまとめる

画面の詳細設計

...追加すべき項目がみつからないのでこのまま

帳票の詳細設計

外部設計書作成時に帳票レイアウトがある場合は出力タイミング・出力プリンタ・出力頻度・出力項目の説明・帳票定義で専用ツールがある場合は定義データなどテスト/運用マニュアル作成ができるよう細分化
ないので割愛

外部インタフェースの詳細設計

外部設計書をもとにデータ送信者/受信者・使用媒体・データの形式・1回の送信最大件数・インタフェースの使用周期など製造に必要な情報を追加で記述
内部で完結するため割愛

ビジネスルールの詳細設計

ビジネスルールは顧客が取り決めた業務の進め方・このルールでプログラムの機能仕様を決める
ビジネスルール：業務の流れ(誰がどの順序で作業するか）・ステータス(各種チェックのロジックや画面遷移条件、システム状態の遷移)・データ範囲と値・業務処理の条件(割引プランの設定条件など)やアルゴリズム(株式売買の約定アルゴリズムなど)
→フローチャート・ＨＣＰチャートなどで記述

リクエスト処理の詳細設計

本来は外部設計で決めるところもあるがビジネスルールを決めた後に定義することなので今回は内部設計とする
Ｗｅｂベースのクライアントサーバシステムの場合サーバプログラムの起動方式（CGI,Java...etc）、ＵＲＬに含めるパラメータ数、機能、形式、省略時の動作などを決定する
ないので割愛

メッセージの詳細設計

メッセージの種類を分類し、表示項目を定義する

分類：エラー、情報提供、警告、ログ
項目定義：エラーダイアログのサイズ・構成、エラー種類とダイアログ内に表示するアイコンの対応、メッセージ番号

物理データ設計

データベースのテーブル名・フィールとの型や桁数・主キー・外部キー・インデックス名・関連テーブル名の定義・データベース全体の設計項目として、テーブルのアクセス順序・想定レコード件数・データベースのライフサイクルなどを定義する
データベース使用しないので割愛

4.内部設計書

個別設計書を内部設計書の構成に当てはめる ユーザインタフェース　→　プログラム構造　→　データ構造　→　処理ロジック　→　メッセージ　→　システムインタフェース　→　ネットワーク構造...必要に応じて機能・システム構成・ソフトウェア構成・ハードウェア構成・ネットワーク構成

---

テキストの入出力システム　内部設計書　第１．０版　２０２０年２月２３日

1. 開発環境 　　テキストの入出力システムを開発するにあたり、次の開発環境を利用する。

   • プログラム言語　Java
   • 設計書作成・管理ツール Github,Gitpress,draw.io

2. 動作環境 　　テキストの入出力システムの動作環境は、次のとおりである。

   • OS Windows
   • CPU Core i7
   • メモリ　...割愛

3. モジュール仕様

3.1モジュール構成

　　・入出力表示モジュール (モジュール構成図...割愛)

3.2モジュール仕様

　　(1)入出力表示モジュール 　　　入出力画面の表示を行う。入力欄で入力された文字を出力欄に出力する。入力されたデータは保存されず、出力後ボタンを押すと消える。

3.3モジュールの処理フロー

右を参照 図１　入出力表示モジュールの処理フロー

3.4モジュールインタフェース

　　(1)入出力表示モジュール

  - メソッド名　input_screen  
  - 引数        なし  
  - 戻り値      なし  

4. メッセージ

　　テキストの入出力システムの表示メッセージは次のとおりである。

5.　システムインタフェース・ネットワーク構造...割愛

---

製造工程と単体テスト

コーディング規約

使うプログラミング言語の標準的な書き方・作法を基に定める

• プログラムの冒頭につけるコメントの記述

• 変数名の付け方や宣言方法

• プログラムロジックの記述

• 変数の型
  システム全体で統一されたルールに従ってプログラムを書くことが大切
  今回はＪａｖａコーディングの基本規約

  • 見やすさを重視せよ
  • ネーミングはわかりやすく
  • サンプルを鵜呑みにしない
  • 同じコードを二度書かない
  • 役割は一つに

5.製造とテスト

反省：gitpodで作ってみたくなってしまってやってみたものの慣れるのに時間がかかりそうで一旦保留にした・当初の予定のEclipseで作った。 先にこちらをやるべきだった。

Eclipseで作った成果物
アラートメッセージの実装、忘れてた。
アラート実装したIntelliJで作った成果物

テスト

予定変更...Javafxをこれから使うならeclipseよりIntelliJのほうが良い
ecliseからIntellIjにIDEを変更

• 単体テスト...ホワイトボックステスト ~~EclipseのJunit4で行う
  IntelliJでJunit5で行う

  単体テスト対象プログラムフローチャート

  

  単体テスト項目欄

  

  レイアウト図で文字数10文字指定してるの忘れてたので訂正

  メッセージ定義書

  

  単体テスト対象プログラムフローチャート

  

  単体テスト項目

  

6.テスト(結合テスト・総合テスト)

結合テストの目的

• プログラム間のインタフェースのチェック
• 必要な機能の実現チェック

  結合テストの項目

• 項目数の目安として対象プログラムステップ数(プログラムの文の数)の20分の1
• 外部設計書の機能の実現をチェックする
• ブラックボックスでテストする

7.受入テスト

受入テストの目的

• 発注者側で行われる発注内容・希望内容との確認
• 開発会社側で出荷検査が適切に行われていればテストの重複となるため網羅性より必要なテストを短期間で効率よく行うことが求められる

受入テストの項目

• 2つの作成方法がある
  • 開発会社の作成したテスト項目を採用
  • 独自のテスト項目を作成する方法
    ...テスト重複するだけなので割愛

自分用メモ...作成にあたり他サイトを巡回して気になったこと

設計書はソースコードとは違う視点で書く

• 同じものを２つ作っても意味はない
• 多面的・多角的に検証するために作る

  二重化(同資料を別場所で書く、管理する)

• 更新・同期が困難になると情報の混乱を招く
• ファイルが見づらいものはコンバート(転換)のためのスタイルシートを用意して情報そのものは１か所を厳守する

  必要な資料の表と図

• 基本設計：外から見た動き(ＷＨＡＴ)
  • 機能設計書として
    • 外部設計書
    • 業務フロー
    • 機能一覧表
    • ネットワーク構成図
    • 画面レイアウト
    • 帳票レイアウト
    • コード定義書
    • ＣＲＵＤ図
    • ファイル仕様書
  • データベースの物理設計書として
    • テーブル定義・ＥＲ図
• 詳細設計：基本設計の実現(ＨＯＷ)
  • 内部設計書
  • 画面詳細設計書
  • 帳票詳細設計書
  • リクエスト処理設計書
  • 物理データ設計書
  • ビジネスルール設計書
  • メッセージ詳細設計書(プログラム機能仕様書)
  • 外部インタフェース設計書
• ドキュメントとしての分類
  • 開発に必要なドキュメント
  • 利用者用ドキュメント
  • 契約上必要なドキュメント
  • 運用保守に必要なドキュメント

設計には世界基準が存在しない

• 属人化(担当者以外わからないやり方)⇔標準化
• 標準化するために組織でルールを作成する
• ＩＰＡのソフトウェア開発技法実践的演習教育コンテンツがある