開発プロセスについて

はじめに

引き続き研修のアウトプットをしていきます！
今回は「開発プロセスについて」です。

学んだこと

実際に開発していくときどういう流れでおこなわれて、どういう成果物が作られるのか。

開発のプロセス

要件定義

「なにをつくるか」を決める。

目的

• 要件（顧客のもつふんわりとした要望を満たす条件）を定義して一貫性のある形へ整える。
• 顧客と開発者の認識をすりあわせる。
• コミュニケーションによる信頼関係の構築
• 顧客要望の背景理解

成果物
要件定義書

設計

「どのようにしてつくるか」を決める

目的

• 要件から実現可能なふるまいへソフトウェアの仕様を定める
• どのようなものが作成されるか全体のイメージを共有

成果物
機能仕様書、基本設計書、詳細設計書、DB設計図、UI設計図、UML図など

基本設計と詳細設計

基本設計とは：ソフトウェアのふるまい（エンドユーザーから見た画面の動き）を設計。外側から見てどのような動きをするのか確認する

詳細設計とは：ソフトウェアの中身（アルゴリズム部分）を設計。プログラムに落とし込めるかどうかを確認する

DB図とは？

データベース設計で使われる図。テーブルの定義や、ER図などがある。

UI図とは？

ウェブページ上の画面構成。誰に何をどうしてほしいかをもとに「どう伝えるか」を設計する。

UML図とは？

人や言語の違いによる表現の方法を統一した手法。システムの全体像を図形を使って表現する。
UML図にも種類があり、表現内容や用途によって使用するUML図が異なる。

参考：https://cacoo.com/ja/blog/what-is-uml/

製造

実際に「つくる」
開発でいう実装にあたる

成果物
ソースコード

テスト

つくったものを「確かめる」

目的
品質に不備がないと自身をもっていえるよう、機能要件を満たしているかを確認する

成果物
テスト結果報告書

納品

「使える」ようにする

運用

「使い続けられるように」保つ。
例）OSのアップデートに対応できるようにする　など

プロセスモデル

ウォーターフォールモデル

• 上流から下流に向かって順番に開発を進める
• 後戻りがしにくい。下流フェーズで上流フェーズの不具合が見つかった場合には、修正が困難。
• 段階を踏んで開発していくため、スケジュール・資源の管理がしやすい
• 大規模システム開発 に向いている

プロトタイプモデル

• 試作品（プロトタイプ）を作成して顧客と確認しながら開発する
• 要件定義　→　プロトタイプ作成　⇔　プロトタイプ確認　→　設計という流れ
• 早い段階でイメージの共有ができることで認識のズレを回避し、手戻りを減らせる
• プロトタイプの作成、確認、修正の工程を繰り返すため、開発への負担が大きい
• 小規模開発に向いている

スパイラルモデル

• 全体の機能を分割して機能ごとに開発していく
• 完成した機能から順番に顧客に引き渡す

例）機能１を設計→製造→テスト。完了したら機能１は引き渡し、機能２を作成。これを繰り返す。

• 工程を小さく回せるので柔軟
• 柔軟であるがゆえに仕様が肥大化したり、コストや人員がかかることがある
• 品質を高めたいシステムに向いている

アジャイル開発

• アジャイル＝素早い
• 要件定義からリリースまでを小さなサイクルで繰り返す
• スパイラルモデルとの違いは、１つの機能の開発が完了し、品質が保証された段階で、その都度リリースするところ
• アジャイルソフトウェア開発宣言に則っている
• 開発期間を短縮したいときに向いている

まとめ

ウォーターフォールやアジャイル開発は聞いたことがありましたが、プロトタイプモデルなどはじめて聞く開発モデルがあり、勉強になりました。
開発工程についても、個人で勉強していたときは製造の部分しか考えていなかったので、今後は全体の流れも意識しながら開発に携わっていきたいと思いました。