ソフトウェア開発手法

要点と定義

開発手法は、何を作業の単位にするか、誰が何を担うか、成果物や進捗をどう確かめるかで捉えます。アジャイルは、迅速かつ適応的に進める軽量な開発の考え方です。短い反復で得た結果を確かめ、状況に応じて次の作業を調整する進め方ができます。

過去の出題で扱った補足として、インスペクションは作成者以外のモデレータが主導し、欠陥を公式に記録して分析するレビュー技法です。ウォークスルーでは、作成者を含む参加者が成果物を読み進め、想定される振る舞いを机上でたどって問題を探します。進行役や確認方法が両者を区別する手掛かりです。

ユースケース駆動開発では、ひとまとまりの要件であるユースケースを軸に、設計からテストまで進めます。ユースケースごとに状況を追えるため、要件単位の開発状況を把握しやすくなります。これは過去の出題で扱った補足です。

スクラムは、役割、イベント、作成物、ルールから成る開発フレームワークです。過去の出題で扱った補足として、プロダクトオーナーはプロダクトの価値を高めるためにバックログ項目を明確にして順序付けます。開発者は具体的な作り方を決め、インクリメントを作成します。スクラムマスターはスクラムの理解と実践を支援します。

ふりかえりで用いるKPTは、続けたいこと、問題、次に試すことを整理する方法です。問題が起きたという記述と、次に試す行動は別の観点です。次の作業で実行する具体策はTryに整理します。これは過去の出題で扱った補足です。

ローコード／ノーコード開発は、専門的なコーディングの知識や経験がなくても開発できる方法としてシラバスに挙げられています。過去の出題で扱った補足として、ローコードはGUIで部品やテンプレートを組み合わせ、必要な処理には一部コードを記述します。ノーコードはソースコードを記述せず、GUI上の設定や部品の組合せを中心に進めます。

マッシュアップは、複数の提供元によるAPIを組み合わせて新しいサービスを構築する手法です。これはシラバスに記載された概念であり、過去の出題でも定義が問われています。

適用条件と例

設計書に書かれた処理を複数人で読み、状態の変化を机上でたどって問題を探すなら、ウォークスルーの進め方です。モデレータがレビューを主導し、欠陥を公式に記録・分析するなら、インスペクションの特徴に当たります。目的がどちらも問題発見でも、進行と確認の条件で区別できます。これらは過去の出題で扱った補足です。

たとえば「会員が予約を変更する」というユースケースを要件のまとまりとして、設計、実装、テストの状況を追えます。把握できるのは、そのユースケースに対応する開発状況です。これは過去の出題で扱った補足です。

スクラムでは、何を優先するかと、どう作るかの責任を分けて考えます。たとえば、利用者向け機能の優先順位はプロダクトオーナーが決め、開発者は実現方法を決めてインクリメントを作ります。役割の責任は過去の出題で扱った補足です。

チームが振り返りで、次回からレビュー手順に確認担当を加えると決めた場合、その行動はTryです。起きた問題を挙げるだけならProblemに当たります。この整理は過去の出題で扱った補足です。

社内申請画面をGUIの部品で組み立て、独自の計算処理だけコードで加えるなら、ローコードの特徴に合います。部品や設定だけで処理ができるか、コードの追加が必要かが区別の手掛かりです。この区別は過去の出題で扱った補足です。

複数の提供元のAPIを組み合わせて、利用者向けの案内サービスを作る構想はマッシュアップに当たります。APIの提供元が複数あることと、新しいサービスを構築することが要点です。これはシラバスにもある定義で、過去の出題でも扱われました。