開発技術

システム開発技術

1. システム要件定義

(1) システム要件定義のタスク

要件定義（requirements definition）とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。

要件定義では、利用者がそのシステムで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」実現するかは後の工程で検討される。

(2) システム要件の定義

① システム化の目的と対象範囲

② 機能及び能力の定義

システム機能仕様

レスポンスタイム

レスポンスタイム（response time）とは、システムや装置などに要求や入力が与えてから、反応を送り返すまでにかかるの時間のこと。また、その平均。この時間が短いほど、利用者や他のシステムなど外部にとっての「待ち時間」が少ないことを意味する。

スループット

スループット（throughput）とは、機器や通信路などの性能を表す特性の一つで、単位時間あたりに処理できる量のこと。IT の分野では、コンピュータシステムが単位時間に実行できる処理の件数や、通信回線の単位時間あたりの実効伝送量などを意味することが多い。

③ 業務・組織及び利用者の要件

要求分析とは、システムやソフトウェアの開発の初期段階で、利用者がそのシステムに何を求めているのかを明確にしていく工程のこと。いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行なう作業の一つである。

データベース要件

セキュリティ要件

移行要件

テスト要件

運用要件

保守要件

障害対応

教育

訓練

費用

④ その他の要件

実行環境要件

周辺インタフェース要件

品質要件

(3) システム要件の評価及びレビュー

レビュー参加者

レビュー方式

2. システム方式設計

(1) システム方式設計のタスク

ハードウェア構成品目

ソフトウェア構成品目

手作業

(2) システムの最上位の方式確立

① システム方式設計の目的

② ハードウェア・ソフトウェア・手作業の機能分割

利用者作業範囲

③ ハードウェア方式設計

④ ソフトウェア方式設計

ソフトウェア品目に対する要件を，最上位レベルの構造を表現する方式で，かつ，ソフトウェアコンポーネントを識別する方式に変換する。

⑤ システム処理方式設計

⑥ データベース方式設計

関係データベース（relational database : RDB）

関係データベース（リレーショナルデータベース）とは、データベースの構造の一つで、一件のデータを複数の属性の値の組として表現し、組を列挙することでデータを格納していく方式。属性を列、組を行とする表（テーブル）の形で示されることが多い。最も普及している方式で、単にデータベースといった場合はリレーショナルデータベースであることが多い。

NDB（Network Database : 網型データベース）

OODB（Object Oriented Database : オブジェクト指向データベース）

XML データベース

(3) システム結合テストの設計

テスト要求事項

(4) システム方式の評価及びレビュー

レビューの手法には，次表に示す 2 つがある。

レビュー参加者

レビュー方式

3. ソフトウェア要件定義

(1) ソフトウェア要件定義のタスク

ソフトウェア構成品目

(2) ソフトウェア要件の確立

インターフェース設計

セキュリティ実現方式

業務モデリング

帳票設計

伝票設計

データモデリング

保守性

(3) ソフトウェア要件の評価及びレビュー

レビュー参加者

レビュー方式

(4) 業務分析や要件定義に用いられる手法

① ヒアリング

ヒアリング計画

ヒアリング議事録

② ユースケース

ユースケース（use case）とは、利用者があるシステムを用いて特定の目的を達するまでの、双方の間のやり取りを明確に定義したもの。利用者は機器を操作する人間以外にも外部の他のシステムなどを想定する場合もある。

アクタ

③ モックアップ及びプロトタイプ

モックアップ（mock-up）とは、工業製品の設計・デザイン段階で試作される、外見を実物そっくりに似せて作られた実物大の模型のこと。ソフトウェアや Web サイト、印刷物などのデザインを確認するための試作品のこともこのように呼ばれることがある。

プロトタイプ（prototype）とは、原型、試作品などの意味を持つ英単語。IT の分野では、ハードウェア開発の際の量産前の試作品や、動作や機能を検証するために最小限の規模で試作されたソフトウェアなどのことを意味する。

プロトタイプ評価版

④ DFD

DFD（Data Flow Diagram，データフロー図）とは、情報システムの設計時などに作成される図の一つで、要素間のデータの流れを表した図。データがどこで発生し、どこからどこへ運ばれ、どこへ出力・保管されるのかを図示することができる。

アクティビティ

データストア

データフロー

プロセス

⑤ E-R 図

E-R 図（Entity Relationship Diagram）とは、情報システムの扱う対象を、実体（entity）、関連（relationship）、属性（attribute）の三要素でモデル化する「ER モデル」を図示したもの。データベースの設計などでよく用いられる。

具体的には，管理の対象をエンティティ及びエンティティ間のリレーションシップとして表現する。

⑥ UML

UML（Unified Modeling Language）とは、オブジェクト指向のソフトウェア開発において、データ構造や処理の流れなどソフトウェアに関連する様々な設計や仕様を図示するための記法を定めたもの。ソフトウェアのモデリング言語の標準としてとして最も広く普及している。

クラス図

システムを構成する各クラス（属性，操作を含む）とそれらの関係（関連，集約，汎化，多重度など）を表現する。

操作

属性

ロール名

ユースケース図

システムが提供する機能とそこから生じるサービスの対象範囲を表現する。

ステートチャート図

シーケンス図

オブジェクト間のメッセージ送受信の関連性を表した図であり，各クラスがどのように協調して動作をするかを表現する。

コミュニケーション図

アクティビティ図

ある振る舞いから次の振る舞いへの制御の流れを表現する。

⑦ その他の手法

決定表（デシジョンテーブル）

複数の条件とその条件によって取り得る各状況の動作を表として整理したものである。表は，上側に条件欄，下側に動作欄を記述し，条件欄に記述した状態（真の場合「Y」，偽の場合「N」）に対して実行する動作を動作欄に示す（処理の実行を「X」，処理を実行しない場合は「-」）。

4. ソフトウェア方式設計・ソフトウェア詳細設計

(1) ソフトウェア方式設計のタスク

ソフトウェア方式設計では，ソフトウェア要件設計の内容に基づいて，どのようにプログラムやシステムを実現すればよいかを具体的に定める。ソフトウェア方式設計で設計するものは，次のとおり。

1. 機能分割／階層構造化
2. 物理データ設計
3. 入出力詳細設計
4. ソフトウェア結合テスト使用の作成

ソフトウェアコンポーネント

ソフトウェアコンポーネント分割

ソフトウェアコンポーネント間インタフェース設計

ソフトウェア結合のためのテスト要件

(2) ソフトウェア詳細設計のタスク

ソフトウェア詳細設計では，ソフトウェア方式設計で決めた各プログラムをモジュールの単位に分割する。モジュール化することで，プログラム変更時の影響範囲を局所化でき，保守が容易になる。また，他のアプリケーションへの再利用が行える。分割後は，各モジュールの処理内容（アルゴリズム）を次工程のプログラミングで記述できるように文章化し，設計書として示す。ソフトウェア詳細設計で設計する者は，次のとおり。

1. モジュール分割
2. 単体テスト仕様の作成

ソフトウェアコンポーネントの単位

機能階層図

ソフトウェアユニット

ユニット分割

コンポーネント詳細設計

ソフトウェアコンポーネントインターフェース詳細設計

ソフトウェアユニット間インタフェース設計

データベース詳細設計

(3) ソフトウェア方式設計

構造化

ソフトウェアコンポーネント機能仕様決定

部品

入出力設計

部品

入出力設計

部品化

再利用

(4) ソフトウェア詳細設計

モジュール分割

モジュール仕様

プログラム設計

(5) インターフェース設計

入出力詳細設計

GUI

画面設計

帳票伝票設計

インタフェース設計基準

(6) ソフトウェアユニットのテストの設計

ホワイトボックステストにおけるテストケースの設計方法には，命令網羅，判定条件網羅（分岐網羅），条件網羅，判定条件／条件網羅，複数条件網羅がある。

テスト要件

チェックリスト

ホワイトボックステスト

ホワイトボックステストとは、システム内部の構造を理解した上でそれら一つ一つが意図した通りに動作しているかを確認する、プログラムのテスト方法。

図の構造をもつプログラムに対して，ホワイトボックステストのテストケースを設計するとき，少なくとも実施しなければならないテストケース数が最大になるテスト技法はどれか。

1. 条件網羅
2. 判定条件網羅
3. 複数条件網羅
4. 命令網羅

（出典）平成27年度 春季 基本情報技術者試験 午前問題 問50

---

正解は，3. である。条件網羅のテストケース数は 2 回，判定条件網羅のテストケース数は 3 回，複数条件網羅のテストケース数は 4 回，命令網羅のテストケース数は 1 回である。

(7) ソフトウェア結合テストの設計

ブラックボックステストにおけるテストケースの設計方法には，同値分割，限界値分析，因果グラフがある。

テスト要件

チェックリスト

ブラックボックステスト

モジュール内部の構造を隠し，モジュールの仕様（機能）に基づいたテストを実施する。具体的には，モジュールへの入力に対して，正しい出力が得られるかをチェックする。ブラックボックステストでは，被テストプログラムに冗長なコードがあっても検出できない。

(8) ソフトウェア設計の品質及びレビュー

レビュー参加者

レビュー方式

(9) ソフトウェア品質

JIS X 25010 : 2013「システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル」"Systems and software engineering-Systems and software Quality Requirements and Evaluation (SQuaRE)-System and software quality models"。

JIS X 25010（ISO/IEC 25010）

ISO 9000

① 利用時の品質モデル

有効性

効率性

満足性

リスク回避性

利用状況網羅性

② 製品品質モデル

機能適合性

性能効率性

互換性

使用性

信頼性

セキュリティ

保守性

移植性

(10) ソフトウェア設計手法

① プロセス中心設計

② データ中心設計

E-R 図

実体

関連

正規化

一事実一箇所

③ 構造化設計

(a) 機能分割と構造化

階層

階層化詳細

(b) 構造化設計の手法

順次

選択

繰返し

NS（Nassi-Shneiderman : ナッシシュナイダマン）図

HIPO（Hierarchy plus Input Process Output）

ジャクソン法

プログラム全体を複数の部品（モジュール）に分割するための設計指針の一つで、入出力データの構造からプログラムの構造を決定していく方式をジャクソン法という。マイケル・ジャクソン（Michael A. Jackson）氏が 1975 年に発表した。

ワーニエ法

プログラム全体を複数の部品（モジュール）に分割するための設計指針の一つで、入力データの構造を分析してプログラムの構造を決定していく方式をワーニエ法という。1970 年代にフランスの情報科学者ジャン・ドミニク・ワーニエ（Jean-Dominique Warnier）氏によって考案された。

(c) プログラムの構造化設計

品質特性

モジュール分割

④ オブジェクト指向設計

クラス

クラス（class）とは、級、階級、等級、格、類、分類、種類、学級、科目、授業などの意味を持つ英単語。IT の分野では、オブジェクト指向プログラミングにおけるオブジェクトの雛形の意味や、何らかの階級や分類を表す名称の一部としてよく用いられる。

インスタンス

インスタンス（instance）とは、事実、事例、例、場合などの意味を持つ英単語。ソフトウェアの分野では、あらかじめ定義されたコンピュータプログラムやデータ構造などを、メインメモリ上に展開して処理・実行できる状態にしたものを指す。この意味では「実体」と訳されることもある。

属性

属性（プロパティ，property）とは、財産、資産、物件、所有物、特性、属性、性質、効能などの意味を持つ英単語。ITの分野では、ソフトウェアが取り扱う対象（オブジェクト）の持つ設定や状態、属性などの情報をプロパティということが多い。

メソッド

オブジェクト指向開発において，オブジェクトのもつ振る舞いを記述したもの。

カプセル化

データとそれを操作する手続を一つのオブジェクトにして，データと手続の詳細をオブジェクトの外部から隠ぺいすること

サブクラス

サブクラス（subclass）とは、オブジェクト指向プログラミングにおいて、あるクラスの仕様を継承して作られた新しいクラス。元になるクラスのことは「スーパークラス」（superclass）、「基底クラス」（base class）、「親クラス」（parent class）などと呼ぶ。

継承（インヘリタンス）

継承（inheritance）とは、オブジェクト指向プログラミングにおいて、あるクラスが既存の別のクラスの性質を受け継いでいること。あるクラスを元に別のクラスを作成することをサブクラス化という。

部品化

再利用

クラス図

多相性

パッケージ

関連

汎化

オブジェクト指向プログラミングの分野では、様々なクラスやオブジェクトに共通する性質をまとめ、それらの共通の親クラス（スーパークラス）として定義することを汎化（generalization）という。例えば，「スポーツカー」を汎化すれば，「自動車」となる。

特化

分解

集約

(11) コンポーネントの設計

① コンポーネント分割の考え方

ファイルの統合

ファイルの分割

レコード処理

処理の周期

② プログラム分割基準

分かりやすさ

安全性

開発の生産性

運用性

処理能力

保守性

再利用性

(12) モジュールの設計

① 分割手法

STS（Source Transformation Sink）分割

プログラム全体を複数の部品（モジュール）に分割するための設計指針の一つで、データの入力（Source：源泉）、変換（Transformation）、出力（Sink：吸収）の3つに分割する手法を STS 分割という。

TR（Transaction : トランザクション）分割

プログラム全体を複数の部品（モジュール）に分割するための設計指針の一つで、データの種類とその処理内容に応じて分割する方式を TR 分割（トランザクション分割）という。

共通機能分割

プログラム全体を複数の部品（モジュール）に分割するための設計指針の一つで、プログラム中の様々な箇所で共通して行われる処理をモジュールとして切り出す方式を共通機能分割という。

サブルーチン

サブルーチン（subroutine）とは、コンピュータプログラムの中で特定の機能や処理をひとまとまりの集合として定義し、他の箇所から呼び出して実行できるようにしたもの。

② 分割基準

モジュールの制御領域

モジュールの影響領域

分割量

モジュール再分割

従属モジュール

③ モジュール仕様の作成

流れ図

流れ図（フローチャート，flowchart）とは、工程や手順の流れを図示する手法の一つで、個々の段階を箱で表し、それらを順序や論理の推移に従って矢印や線分で結んだもの。

決定表（デシジョンテーブル）

デシジョンテーブル（decision table）とは、複数の判断条件の正否の組み合わせを列挙し、それぞれの場合についてどのような判断を下すかを一覧にまとめた表。

NS（Nassi-Shneiderman : ナッシシュナイダマン）図

ジャクソン図

ワーニエ法

(13) 部品化と再利用

コンポーネントウェア

(14) アーキテクチャパターン

MVC モデル

MVC（Model-View-Controller）とは、ソフトウェアの設計モデルの一つで、機能を「Model」（モデル）、「View」（ビュー）、「Controller」（コントローラ）の三つの役割に分離して実装し、それらが連携して処理を進める方式。

(15) デザインパターン

デザインパターンとは、ソフトウェアの設計時に直面しがちな問題とその典型的な解決策を整理し、様々な場面で応用・再利用できる形にまとめたもの。

1995 年にオブジェクト指向プログラミングの分野で有名な「GoF」（Gang of Four：四人組）の通称で知られる研究者グループ、エーリヒ・ガンマ（Erich Gamma）氏、リチャード・ヘルム（Richard Helm）氏、ラルフ・ジョンソン（Ralph E. Johnson）氏、ジョン・ブリシディーズ（John M. Vlissides）氏による共著「オブジェクト指向における再利用のためのデザインパターン」（原題 “Design Patterns: Elements of Reusable Object-Oriented Software”）の中で 23 のパターンが紹介されたことを契機に広まった。

(16) レビュー

レビュー（review）とは、再検討（する）、再考（する）、復習（する）、論評（する）、講評（する）、検査（する）、精査（する）、点検（する）、査察（する）、審査（する）、回顧（する）などの意味を持つ英単語。

デザインレビュー

インスペクション

ソフトウェア開発におけるレビュー手法の一種で、仕様書やソースコードなどの成果物を人の目で見て不具合や問題点が無いか検証する作業をインスペクション（inspection）という。

モデレータ

情報システム開発の分野で、成果物レビューの手法の一つであるインスペクション（inspection）において会合を主催し、参加者の選出や役割の依頼、スケジュールや会場の調整、会議の司会・進行などを行う役割のことをモデレータ（moderator）という。

文書化手法

レビュー参加者

ウォークスルー

システム開発の分野では、開発プロジェクトのメンバーが一同に会し、仕様や構成の問題点を探したり解決策を討論したりする作業のことをウォークスルー（walk-through）という。

コードレビュー

共同レビュー

5. ソフトウェア構築

(1) ソフトウェア構築のタスク

コーディング

プログラム言語

(2) ソフトウェアユニットの作成

アルゴリズム

データ処理

構造化プログラミング

(3) ソフトウェアコード及びテスト結果の評価基準

追跡可能性

外部一貫性

内部一貫性

テスト網羅性

コーディング方法及び作業標準の適切性

ソフトウェア結合及びテストの実現可能性

運用及び保守の実現可能性

(4) コーディング標準

インデンテーション

ネスト

命令規則

使用禁止命令

(5) コーディング支援手法

コード補完

コードオーディタ

シンタックスハイライト

(6) コードレビュー

メトリクス計測

コードインスペクション

ピアコードレビュー

(7) デバッグ

デバック環境

静的解析

動的テスト

アサーション

デバッカ

(8) ソフトウェアユニットのテスト

① テストの目的

障害

欠陥

障害分析

② テストの手順

テスト方法論

テスト範囲

テスト準備（テスト環境，テストデータなど）

テスト実施者

③ テストの実施と評価

ドライバ

最下位モジュールから上位モジュールへと結合しながらテストする場合，上位モジュールの働きをするダミーモジュール。

スタブ

階層構造のモジュール群から成るソフトウェアの結合テストを，上位のモジュールから行う場合に使用する，下位のモジュールの代替となるテスト用のモジュール。トップダウン方式で結合テストを行うとき，特に必要となるものである。

テストデータジェネレータ

テスト設計と管理手法

バグ曲線

横軸にテスト項目消化件数，縦軸に発見した累積バグ件数を取り，テスト結果をプロットして描かれる曲線

エラー除去

バグ管理図

実際のバグ曲線からテスト状況や品質を読み取る図のこと

実験計画法

効率よくテストするために，直交表を用いてテストケースを作成する。検証する項目の組合せによるテストケース数が膨大になる場合に有効になる。

④ テストの手法

メトリクス計測

テストケース

命令網羅

全命令を最低 1 回は実行するようにテストケースを作る。

条件網羅

分岐の判定文が複数の条件からなる場合に採用される。判定文において，それぞれの条件が真と偽の場合を組み合わせテストケースを設計する。

判定条件網羅（decision coverage）

分岐の判定において，真と偽の分岐を少なくとも 1 回は実行するようにテストケースを設計する。

複数条件網羅（multiple condition coverage）

判定文の条件において，取り得るすべてのパターンを網羅するようにテストケースを設計する。

限界値分析法

同値分割において，各クラスの境界線をテストデータとして取り出し，テストケースとする。

同値分析法

入力データを，正常に処理される値を持つ有効同値クラスとエラー処理される値を持つ無効同値クラスに分割し，各クラスから 1 つずつ取り出してテストケースとする。

原因結果グラフ法

入力データが明確にクラス分けできない場合に有効な方法で，入力（原因）と出力（結果）の因果関係をグラフで表し，その後，デシジョンテーブルを作成してテストケースを洗い出す。

エラー埋込法

6. ソフトウェア結合・ソフトウェア適確性確認テスト

(1) ソフトウェア結合のタスク

テスト要件

テスト手順

テストデータ

(2) ソフトウェア適合性確認テストのタスク

ソフトウェア要件

監査

(3) ソフトウェア結合テスト

ソフトウェア結合テストのテスト手法には，代表的な方法として，結合するモジュールを徐々に増やしながらテストを行う増加テスト（ボトムアップテスト，トップダウンテスト，折衷テスト）と，すべてのモジュールを結合し，一度にテストを行う非増加テスト（ビッグバンテスト）がある。

増加テストは，大規模なシステムに適したテスト方法，一方，非増加テストは，小規模なシステムに適したテスト方法である。

テスト計画

テスト準備（テスト環境，テストデータなど）

ソフトウェア結合テスト報告書

トップダウンテスト

最上位モジュールから下位モジュールへと結合しながらテストする方法。スタブを使用し，トップダウンでプログラムのテストを行うとき，作成したモジュールをテストするために，仮の下位モジュールを用意して動作を確認する。

ボトムアップテスト

最下位モジュールから上位モジュールへと結合しながらテストする方法。

ドライバ

ボトムアップテストで必要となる上位モジュールの働きをするダミーモジュール。ドライバは，引数を渡してテスト対象モジュールを呼び出す。

スタブ

トップダウンテストで必要となる下位のモジュールの代替となるテスト用のモジュール。

(4) ソフトウェア適合性確認

機能テスト

非機能要件テスト

性能テスト

負荷テスト

セキュリティテスト

回帰テスト（リグレッションテスト）

ソフトウェアのテストの種類のうち，ソフトウェア保守のために行った変更によって，影響を受けないはずの箇所に影響を及ぼしていないかどうかを確認する目的で行うもの。

(5) テスト結果の評価

7. システム結合・システム適確性確認テスト

(1) システム結合のタスク

ハードウェア構成品目

ソフトウェア構成品目

手作業

(2) システム適格性確認テストのタスク

システム要件

(3) システム結合テスト

システム結合テストでは，システムとして要求された機能や操作性，性能などに問題がないかを確認する。システム結合テストの種類を下表に示す。

テスト計画

テスト準備（テスト環境，テストデータなど）

(4) システム適格性確認テスト

機能テスト

非機能要件テスト

性能テスト

負荷テスト

システムに要求されている処理能力の限界状態における動作を確認する。

セキュリティテスト

回帰テスト（リグレッションテスト）

(5) テスト結果の評価

8. 導入

(1) システム又はソフトウェアの導入のタスク

(2) システム又はソフトウェアの導入計画の作成

導入要件

移行要件

導入可否判断条件

インストール計画の作成

導入作業

(3) システム又はソフトウェア導入の実施

導入手順

導入体制

利用部門

システム運用部門

(4) 利用者支援

9. 受入れ支援

(1) システム又はソフトウェアの受入れ支援のタスク

納品

(2) システム又はソフトウェアの受入れレビューと受入れテスト

受入れ手順

受入れ基準

受入れテスト

検収

検収基準

(3) システム又はソフトウェアの納入と受入れ

受入れ体制

(4) 教育訓練

(5) 利用者マニュアル

運用規程

利用者マニュアル

システム利用文書

ソフトウェア利用文書

チュートリアル

10. 保守・廃棄

(1) 保守のタスク

保守手順

保守体制

保守の実現可能性

保守テスト

回帰テスト（レグレッションテスト）

リバースエンジニアリング

(2) 廃棄のタスク

組織の運用の完整性（integrity）

(3) 保守のタイプ及び形態

保守契約

保守要件の定義

ハードウェア保守

日常点検

是正保守

予防保守

適応保守

完全化保守

オンサイト保守

遠隔保守

ライフサイクルの評価

(4) 保守の手順

① 保守プロセス開始の準備

開発プロセスから保守に必要な成果物の引継ぎ

計画及び手続きの作成

問題管理手続きの確立

保守のための文書作成

② 問題把握及び修正の分析

問題報告又は修正依頼の分析

問題の再現又は検証

修正実施の選択肢の用意

③ 修正の実施

修正するシステム又はソフトウェアや関連文書の決定

機能追加

性能改良

問題の是正

④ 保守レビュー及び／又は受入れ

⑤ 再発防止策の実施

⑥ 移行

移行計画の文書化と検証

関係者全員への移行計画などの通知

新旧環境の並行運用と旧環境の停止

関係者全員への移行の通知

移行結果の検証

移行評価

旧環境関連データの保持と安全性確保

(5) 廃棄

廃棄計画の立案

廃棄計画などの利用者への通知

新旧環境の並行運用と利用者の教育訓練

関係者全員への廃棄の通知

廃棄関連データの保持とアクセス可能性の確保

ソフトウェア開発管理技術

1. 開発プロセス・手法

(1) ソフトウェア開発手法

① ソフトウェア開発モデル

ウォータフォールモデル

最初に全体の機能設計・計画を決定し、この計画に従って開発・実装していく手法である。

プロトタイピングモデル

アジャイル

アジャイル（Agile）とは，直訳すると「素早い」「機敏な」「頭の回転が速い」という意味である。アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法のひとつで、大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進めていく。従来の開発手法に比べて開発期間が短縮されるため、アジャイル（素早い）と呼ばれている。

ソフトウェアプロダクトライン

段階的モデル（Incremental Model）

進展的モデル（Evolutionary Model）

② アジャイル

アジャイル開発（agile software development）とは、ソフトウェアを迅速に、また、状況の変化に柔軟に対応できるように開発する手法の総称。「アジャイル」（agile）とは、俊敏な、しなやかな、素早い、などの意味で、短いプロセスを何度も反復して次第に全体を組み立てていくアプローチの手法が多い。

エクストリームプログラミング（XP : eXtreme Programming）とは、迅速で柔軟性の高いソフトウェア開発手法の一つ。いわゆるアジャイル開発手法と総称される軽量で柔軟な手法の先駆けとなったもので、1999年に米著名プログラマのケント・ベック（Kent Beck）氏らが提唱した。

スクラム（Scrum）とは、ソフトウェア開発手法の一つで、チームが一丸となって仕事に取り組むための方法論を中心にまとめられた方式。少人数で迅速に開発を進める、いわゆるアジャイルソフトウェア開発手法の一つ。

アジャイルソフトウェア開発宣言

「アジャイルソフトウェア開発宣言」参照

アジャイルソフトウェアの 12 の原則

「アジャイル宣言の背後にある原則」参照

XP（エクストリームプログラミング）

事前に立てた計画よりも途中変更などの柔軟性を重視する手法である。

スクラム

スクラム開発は、アジャイル開発の中でも有名な手法で、開発を進めるためのフレームワークを指す。スクラムとはラグビーで肩を組んでチーム一丸となってぶつかり合うフォーメーションのことで、その名の通り、チーム間のコミュニケーションを重視している点が特徴である。

ユーザストーリ

テスト駆動環境

リファクタリング

ソフトウェアの保守性を高めるために，外部仕様を変更することなく，プログラムの内部構造を変更する。

継続的インテグレーション（CI）

ふりかえり（レトロスペクティブ）

ペアプログラミング

スプリント

③ ソフトウェア再利用

モジュールの独立性

標準化

カスタマイズ

④ リバースエンジニアリング

リバースエンジニアリング（reverse engineering）とは、出荷された製品を入手して分解や解析などを行い、その動作原理や製造方法、設計や構造、仕様の詳細、構成要素などを明らかにすること。

互換性

コールグラフ

⑤ マッシュアップ

マッシュアップ（mashup）とは、音楽において複数の曲を重ねて再生し一つの楽曲に仕立てる制作手法。転じて、IT の分野では複数のWebサービスやソフトウェア、データベースなどを組み合わせて新しいシステムを作り出す手法を指す。

⑥ モバイルアプリケーションソフトウェア開発

モバイル用 Web アプリケーションソフトウェア

ネイティブアプリケーションソフトウェア

ハイブリッドアプリケーションソフトウェア

User-Agent

パーミッション要求

アプリケーションソフトウェア審査

アプリケーションソフトウェア配布

(2) 構造化手法

階層構造化

段階的詳細化

構造化チャート

状態遷移図

要求の分析・設計時において，時間の経過や制御信号の変化などの，状態を変化させるきっかけと，変化に伴って実行する動作を記述するために使用される。

HIPO（Hierarchy plus Input Process Output）

DFD

ソフトウェア構造

(3) 形式手法

VDMTools

(4) 開発プロセス

① ソフトウェアライフサイクルプロセス

SLCP-JCF（共通フレーム）

JIS X 0160

② プロセス成熟度

初期

管理された

定義された

定量的に管理された

最適化している

2. 知的財産適用管理

(1) 著作権管理

プログラムの著作権

職務著作

(2) 特許管理

特許権

専用実施権

通常実施権

(3) ライセンス管理

ライセンサ

ライセンシ

(4) 技術的保護

コピーガード

DRM

DRM（Digital Rights Management）とは、デジタルデータとして表現されたコンテンツの著作権を保護し、その利用や複製を制御・制限する技術の総称。デジタル著作権管理。音声・映像ファイルにかけられる複製の制限技術などが有名だが、広義には画像ファイルの電子透かしなども DRM に含まれる。

アクティベーション

CPRM

CPRM（Content Protection for Recordable Media）とは、DVD などに採用されている、記録メディア向けの著作権保護技術の一つ。利用者側で内容を書き込み可能なメディア（recordable media）向けの方式で、コンテンツのデジタルコピーをメディアに記録する際の一度だけ許容し、メディアから他の機器やメディアへのコピー（ダビング）を禁じる「コピーワンス」を実現する。

3. 開発環境管理

(1) 開発環境管理

構成品目

ソフトウェアライセンス

ライセンス（license）とは、免許（証）、許可（証）、認可、許諾などの意味を持つ英単語。ソフトウェアの分野では、開発者がそのソフトウェアの使用、改変、再配布、販売などの可否や条件を定めたもの、また、それを文書にまとめたものをライセンスという。

(2) 管理対称

① 開発環境稼働状況管理

資源管理

運用管理

② 設計データ管理

更新履歴管理

アクセス権管理

検索

③ ツール管理

構成品目

バージョン管理

④ ライセンス管理

不正コピー

バージョン管理

棚卸

4. 構成管理・変更管理

(1) 構成管理

ソフトウェア構成管理

ソフトウェア構成品目

SLCP（Software Life Cycle Process : ソフトウェアライフサイクルプロセス）

SLCP とは、ソフトウェアの構想・設計から開発、導入、運用、保守、破棄に到るまでの工程全体のこと。また、それらの工程について個々の作業内容、用語の意味などを標準化した枠組み。

構成管理計画

(2) 変更管理

① 構成状況の管理

② ソフトウェア構成品目の完全性保証

一貫性

正確性

③ リリース管理及び出荷

バージョン管理

保管管理