開発プロセスとは?

システム開発は「家づくり」に似ている。

ここまでで経営ニーズ・利用者ニーズ(業務プロセスの洗い出し)などから、どんなシステムが必要か決まっているはずです。システム開発部門として、形作っていきます。開発フローが家づくりに例えられることが多く、一つずつプロセスを完了させながら進めていきます。

 

4つプロセス
  1. システム設計
  2. プログラミング
  3. テスト
  4. ソフトウェア受入れ

システム設計

システム要件定義をもとにシステム設計図を作成します。

  1. システム方式設計
    システム要件を「ハードウェア」「ソフトウェア」「手作業」のどれかに振り分ける。

    • ハードウェア:サーバ、プリンタなど
    • ソフトウェア:ソフトウェア名、バージョンなど
    • 手作業:電話受付、在庫確認、データ入力など
  2. ソフトウェア要件定義
    ソフトウェアの機能や性能を決める。

    • UI(ユーザー画面、印刷結果、ファイル出力など)
    • データ(扱うデータ、データベース設計『論理モデル』など)
  3. ソフトウェア方式設計
    ソフトウェア要件をプログラム単位まで分割する。
  4. ソフトウェア詳細設計
    プログラム単位を「コーディングできる」まで分割する。具体的には、フローチャート(流れ図)などにして表す。
    また、データベース設計『物理モデル』まで行う。
    分割されたプログラムを「ソフトウェアユニット(ソフトウェア単体)」といいます。

プログラミング

ここまできて、やっとシステム開発として「プログラミング」となります。プログラミングとは、「プログラマー」がプログラム言語を使用し「処理手順」を記述します。

プログラミングを早く行いたいと気持ちは焦りますが、「システム設計(ソフトウェア詳細設計)の後」となります。

 

プログラミング重要用語
  • ソースコード
    人間が認識できるようにプログラム言語で記述されたプログラム
  • コンパイラ
    ソースコードをコンピュータが認識できるように機械語に変換する機能
  • 機械語
    コンピュータが認識できる「0」と「1」で記述された言語

テスト

システムが仕様通りに動作するかを確認します。また、業務要件も満たしているかどうかも併せて確認します。不具合があった場合には、修正します。

重要用語
  • バグ(プログラム不具合)
  • デバッグ(不具合を修正する作業)
  • レグレッションテスト(回帰テスト)
    システム修正や機能追加したことで別のバグが発生していないかを検証

 


 

V字モデル
  • 単体テスト
    「開発者」がプログラミングに誤りが無いかを検証する。(※ホワイトボックステスト
  • 結合テスト
    「開発者」が単体テストで問題なかったプログラムを結合し、データや連携が動作するかを検証する。(※ブラックボックステスト
  • システムテスト
    「開発者」がシステム要件に沿ったものになっているかどうかを検証する。
  • 運用テスト
    「ユーザ」が本番環境と同じテスト環境で動作検証する。

 


 

ホワイトボックスとブラックボックス
  • ホワイトボックステストとは?
    プログラムの構造を追いかけながら分析確認するテストです。そのため、プログラムで記述されているすべての処理(分岐したもの含む)を動作検証する。但し、プログラマの誤解によるバグは見つけられない。
  • ブラックボックステストとは?
    プログラムでどのように記述されているのかは気にせず、「入力データ」を正しく加工し、「出力」されているかどうかの「結果」をみて検証する。

ソフトウェア受入れ

開発者が開発したソフトウェアを発注者に納品します。その際の「ソフトウェア導入」と「ソフトウェア受入れ支援」を行います。

また、納品物としてソフトウェアだけでなく、「利用者マニュアル」などを作成し、導入後の運用を円滑行えるように支援します。

  • ソフトウェア導入
    本番環境にソフトウェアを導入(インストール)します。新規導入のこともあれば、既存システムから「移行(切り替える)」こともあります。
  • ソフトウェア受入れ支援
    発注者が行う「ソフトウェア受入れテスト」に対して、開発者が支援します。発注者は、システムが契約内容通りに完成しているかどうかを確認するテストを「検収」とすることが多いです。ここで問題が無ければ「納品」完了となります。