こんにちは!運営者のハックです。
今回は「デイトラ中級編Day37『現場での開発の流れ(V字モデル / ウォーターフォール / アジャイル / スクラム)』」の前半部分の学習内容について記録します。
今回は解説部分ばかりで文章が長くなってしまったみたいなのにゃ。
読むのが面倒くさい場合は赤字だけ注目して見るのにゃ!
開発の流れを学習しよう
まず、開発の流れの詳細について紹介します。以下は流れの全体図です。
アプリケーションを作る際にはまず「要件(して欲しいこと)」があって、それを実現するための作り方や体制、仕組みなどを決めます(①要求分析、②要件定義)。
①要件分析と②要件定義は非常に重要であり、ここが決まっていないとすべてが崩れてしまう可能性があります。
そこから作るものが決まってきて(③基本設計)、機能の数や種類がわかった上で、それをどう作るかという具体的な部分(④詳細設計)に向かいます。これが「設計」です。
設計ができてから実装(⑤コーディング、⑥コードレビュー)です。後はでき上がったものが求めていたものになっているかをテスト(⑦単体テスト、⑧結合テスト、⑨システムテスト、⑩受入テスト)し、納品して完了になります。
「V字モデル」で開発の流れを把握しよう
システム開発の進め方で良く言われるのが「プロセスモデル」です。その中でもよく扱われるのが「V字モデル」で、システム開発プロジェクトにおける開発工程とテスト工程の対応を表したものです。
引用:ソフトウェア開発の「V字モデル」とは何か? | Remote TestKit
V字モデルはソフトウェア開発手法の一つで、開発工程を左の斜め下向きに、対応するテスト工程を右の斜め上向きに配置したV字形をしています。
開発の上流工程(要求分析からコーディング)と下流工程(コードレビューから受け入れテスト)が対になっており、この対応関係が品質の確認を容易にします。各工程の進捗に応じてテストを行うことで、問題点を早期に発見しやすく、多くのプロジェクトで効果的な開発手法として採用されています。
その流れの通りにやらなければダメということはありませんが、V字モデルに沿った開発は概ね正しい結果が得られるため、採用されるケースが多いそうです。
確かに、ぱっと見で非常にシンプルで分かりやすいですよね。
開発工程とテスト工程の用語を覚えよう
開発工程とテスト工程の各用語の詳細について説明します。
※画像はイメージです。
ねこ奈の画像でイメージしやすくしたのにゃ!
開発工程
要求分析
要求分析はソフトウェア開発において、発注者が求める機能やシステムの目的を明確にする初期段階の工程です。この分析を通じて、どのようなソフトウェアが必要か、そのシステムがビジネス上どんな役割を果たすべきかを特定します。要求分析は開発者だけでなく、システムの最終ユーザーとの議論を含むこともあります。この工程の成果は、受け入れテストでソフトウェアが要求を満たしているかどうかを評価する基準となります。
要件定義
要件定義は、要求分析で明らかになった機能を実現するための具体的な方法を決定する工程です。ここでは、開発の目的や必要な機能に加えて、セキュリティ、保守、予算、開発スケジュールなどの要素も考慮に入れます。この段階での決定がプロジェクトの成功に大きく影響し、技術的な知識と高度な計画が求められます。適切な要件定義がプロジェクトの進行をスムーズにし、目標達成へ導く鍵となります。
基本設計
基本設計では、要件定義で特定された機能をシステム上でどのように実現するかを詳細に計画します。この段階で、システムの全体構造を作り上げ、各機能の動作やデータの流れ、画面レイアウトなどを具体化します。開発者と利用者のニーズを調整し、具体的な開発プランを策定するため、コミュニケーションが重要となります。
詳細設計
詳細設計は、基本設計で決めたシステム構造を具体的なプログラムの仕様に落とし込む工程です。ここで、機能ごとの処理の流れやデータ構造、インターフェース、クラス設計など、開発者が開発を進めるための詳細な情報を定義します。システムの内部設計が重視され、効率的なコーディングと正確な機能実装のための道筋がつけられます。
コーディング
コーディングは、詳細設計の指示に基づき、プログラミング言語を使って実際のソースコードを書く段階です。
この工程で具体的な機能がプログラムとして形にされます。実際にJavaで開発を行う工程です。
テスト工程
開発工程に応じたテスト工程が存在します。
テストを行わないとシステムとしての品質を担保できないことになるので、テスト工程は非常に重要な役割を果たしています。
以前の記事「デイトラJava中級編35 テスト設計、テスト手法」でも少し学んだのにゃ。
コードレビュー
コードレビューは、他の開発者が作成したソースコードを評価し、様々な観点からフィードバックを提供するプロセスです。誤記、設計ミス、効率性の低下、セキュリティ上の脆弱性など、開発者自身が見落とす可能性のある問題を発見し改善することが可能になります。手順は現場によっても異なりますが、コードレビューを行うことによりコードの品質向上や、チーム内での技術的な知見の共有に貢献し、結果的にソフトウェアの全体的な信頼性を高めることが期待されます。
単体テスト
単体テストは、プログラムの最小単位(ユニット)が意図した通りに機能するかを確認するテストです。開発の初期段階で行われ、不具合の特定と修正が容易になるため、バグ修正コストを抑える効果があります。担当開発者が実施することで、高精度の検証が可能となり、後のテスト工程での手戻りを防ぐことにもつながります。
また、単体テストは大きくブラックボックステストとホワイトボックステストに分類できます。
この二種類のテストを併用することで、内部仕様(プログラムの仕様)と外部仕様(インターフェースやシステム全体、主要機能などの仕様)のずれを検出できます。
ブラックボックステスト
ブラックボックステストは、ソフトウェアの内部構造を見ずに、外部からの入力とそれに対する出力だけを検証するテスト方法です。このテストでは、ソフトウェアが仕様書通りに動作するかを確認します。コーディングのスキルは不要で、ソフトウェアテストのスキルを持つ人が実施できることが特徴です。
ホワイトボックステスト
ホワイトボックステストは、ソフトウェアの内部構造やソースコードを基に実施されるテスト方法です。このテストは、プログラムの内部動作やロジックを詳細に検証するために行われ、テスト実施者はプログラミングの知識を必要とします。主に単体テストの段階で利用されます。
結合テスト
結合テストは、単体テストを通過した複数のソフトウェアモジュールを一つに組み合わせて、それらが集合体として意図した通りに機能するかを検証するテストの段階です。このテストは、モジュール間の接続や相互作用に焦点を当て、全体としてのシステムが要件を満たしているかを評価します。
システムテスト
システムテストは、開発されたソフトウェアが全体として要件定義に沿った機能を満たしているかを検証する最終テスト工程です。システムテストでは、ソフトウェアの全機能とシステムの統合が正しく行われ、仕様通りに動作するか、また不具合や実装漏れがないかが確認されます。
受入テスト
受入テストは、最終的なユーザーが実際の運用環境でソフトウェアをテストし、日常業務での使用に問題がないかを検証する過程です。このテストでは、ソフトウェアがユーザーのニーズを満たし、運用可能な状態であるかを確認します。主に開発終了後、納品前に行われ、実用に基づいたシナリオで検証します。
基本設計から詳細設計でよく使われるダイアグラムを学習しよう
基本設計から詳細設計でよく使われるダイアグラム(図)について紹介します。
※画像はイメージです。
前の項目がねこ奈の写真集化してるので、この項目はシンプルな画像を使います!
あにゃっ!?
ねこ奈の写真お披露目会が…
クラス図
クラス図は、システムのクラス、その属性、メソッド、そしてクラス間の関係性を視覚的に示すUML(統一モデリング言語)の一種です。これにより、システムの静的な構造を明確に理解でき、大規模開発での概要把握や、シーケンス図作成の基礎となります。システム間の静的な関係を図式化することで、仕様書の読み解きやシステムの抜け漏れを発見しやすくなり、汎用性と保守性を高めます。
ER図
ER図(エンティティ・リレーションシップ図)は、データベースの構造を視覚化するためのツールです。エンティティ(実体)、属性、そしてこれらの間の関係性を図式化し、データモデルの設計と整理に役立ちます。開発者はデータベース内のテーブル間の関連性を明確に把握し、一貫性のあるデータベース操作と管理を支援します。ER図は、データベース設計の基本であり、システムのデータ関係の共通理解を促進する重要なドキュメントです。
シーケンス図
シーケンス図は、システム内のクラスやオブジェクト間のインタラクションを時間軸に沿って視覚的に表現するUMLの一形態です。システムの動作やプロセスの流れを具体的に理解しやすくなり、設計、開発、保守、運用の各フェーズでシステムの詳細を把握するのに役立ちます。シーケンス図は、ロジックの流れを直感的に捉えることができ、問題発生時の原因特定や修正箇所の判断にも有効です。
他にも利用者視点でシステムが要求に対してどのように振舞うかを示すユースケース図や、業務や処理のフローを表すアクティビティ図といったものがあります。
前半のまとめ
前半部分では「開発の流れ」「開発工程とテスト工程」「基本設計から詳細設計で使用されるダイアグラム」について学習しました。
学習はChatGPTや基本情報技術者試験用のテキストを補助として使用しました。
以前は基本情報技術者のテキストを読んでもイマイチ理解しづらかったのですが、プログラミング学習を進めることによって開発の流れを把握しやすくなったと感じています。
後半は「Mermaid記法でダイアグラムを表現」や「開発プロセスのフレームワーク」、「アジャイル開発の種類」についての学習記録を紹介します。
以上で今回の学習記録を終えます。
ここまでご覧いただきありがとうございました。
コメント