マネジメント系開発技術202～234
ハードウェアとソフトウエアから構成される。ソフトウェアは1部。システム
必要なハードウェアを調達し、必要な機能を持ったソフトウェアを新たに作ること。システム開発
システムで実現したいことを決める工程。システム要件定義
システム要件定義で決めたことを実現するためにハードウェアとソフトウエアの仕様や動作を決める工程。システム設計
完成したソフトウェアをお客さんに納品する工程ソフトウェア受け入れ
システムに必要な条件(システム要件)を決める工程システム要件定義
業務要件のうちシステムで実現する要件。システムに必要な機能や性能。システム要件
ユーザへのヒアリングで明らかになった、システムに必要な機能。※レーンにのせた寿司がお客さんの所へ届くこと機能要件
ユーザへのヒアリングでは出てこないが、システムに必要な性能※応答時間やセキュリティせいなど非機能要件
ソフトウェアの品質を評価する基準。機能性、信頼性、使用性、効率性、保守性、移植性の6つがある品質特性
システム要件定義書を開発側と発注側の両者で内容を確認して、謝りや相違点がないかチェックする作業共同レビュー
システム要件定義で決められたことをもとにして、システムの設計図をかきおこすこと。システム設計
システム要件定義のプロセスに洗い出したシステム要件をハードウェアと手作業いずれかに振り分けるプロセスシステム方式設計
ソフトウェアの要件(機能や性能)を決める工程システム方式で割り振られたものを具現化する。インターフェースの要件(画面、帳票等)データの要件(データの種類、要件等)ソフトウェア要件定義
ソフトウェア要件定義で決めたソフトウェア要件をプログラム単位まで分割する工程。ソフトウェア方式設計
ソフトウェア方式でプログラム単位まで分割された要件をさらにコーディングできるまで分割する工程。具体的にはフロートチャート(流れ図)にして表わす。ソフトウェア詳細設計
ソフトウェア詳細設計で分割されたプログラムのことソフトウェアユニット
ユーザーから見える箇所の設計。ユーザかの立場からみた業務機能。システム要件定義とシステム方式設計外部設計
プログラム言語の文法に従って処理手順を書く工程*プログラミング担当者をプログラマという。ソフトウェア詳細設計の後に行うプログラミング
プログラミング工程のうち、流れ図に沿ってソースコードを記述することコーディング
人間が書いたプログラムを機械語に変換すること。処理を行う機能をコンパイラという。コンパイル
人間が読みやすいプログラム言語で書かれたプログラム。コンパイラが機械語に翻訳される前のプログラムのこと。ソースコード
人間が書いたコンピュータが読むことができる機械語に変換する機能。コンパイラ
プログラムに誤りがないことを検証する。ホワイトボックステストと呼ばれるテスト手法単体テスト
単体テストが完了したプログラム同士を組み合わせ、データ受け渡しや連携が上手くいくか検証する。ブラックボックステストのテスト手法。結合テスト
システム要件が仕様道理に動作するかを検証するシステムテスト
本番環境と同じ条件下でシステムを運用し、動作することを検証する。運用テスト
あるものとあるものを繋ぐ部分のこと。ハードウェアインターフェースが代表例としてパソコンと周辺機器を繋ぐ部分をハードウェアインターフェースというインターフェース
入力したデータが意図的に、処理されているかを、プログラムの内部構造を分析して確認するテスト手法。プログラムに記述されている全ての処理を実行し、動作を確認する。ホワイトボックステスト
入力と出力だけに着目し、ある入力に対して、仕様書どうりの出力が得られるかどうか確認するテスト。結果さえ良ければ気にしない。ブラックボックステスト
プログラム上の誤りや不具合を修正する作業。デバック
システムに修正や追加機能をしたために、別の所で新しいバグがでてないかを確認するテスト回帰テスト
開発者が作成したソフトウェアを発注者に納品する工程ソフトウェア受け入れ
発注側の本番環境にソフトウエアをインストールする工程。現システムを新システムに切り替えることを移行という。ソフトウェア導入
発注者がソフトウェア受け入れテストを行い発注者がその手助けすること。ソフトウェア受け入れ支援
開発者が発注者にシステムを引渡す際に行われるテスト。発注者がテストを行う。＊検収ソフトウェア受け入れテスト
システムを利用するユーザに向け書かれたシステムの操作方法や障害時対応が掲載されている説明書り利用者マニュアル
完成したシステムを本番環境で動かす工程。運用プロセス
稼働中に見つかったバグを修正したり、ソフトウェアに新機能を追加したりする工程。保守プロセス
システムが提供する機能に点数をつけて、開発費用を見積る方法。ファンクションポイント法
ソフトウェア開発プロセスを上流工程から下流工程へ向かって一直線に順番に進める手法。計画がたてやすく、修正作業が大変ウォータフォールモデル
短期間にソフトウェア開発とリリースを繰り返し、ビジネス環境の変化やユーザーニーズに柔軟に対応する開発モデルアジャイル開発
開発担当者と運用担当者が連携してシステムを開発する手法。DevOps
アジャイル開発の手法の1つ。19のプラクティス(実践)が定義された開発手法。XP
通常はプログラムを書いた後に行う単体テストを順序を逆にして先に行い、このテストを通るようにプログラムを書く開発手法。テスト駆動開発
2人のプログラマが1つのパソコンを使ってソフトウェアを開発する手法ペアプログラミング
プログラムの機能仕様は変えず、内部構造を変えること。プログラムの内部のソースコードだけかえることリファタリング
ソフトウェアを部品化することで再利用しやすくし、開発を効率化する手法オブジェクト志向
システムを利用する部門(エンドユーザー)が主体的にシステム開発や運用に携わることEUC
少数の人数でプロトタイピングを繰り返し短い期間で開発するモデルRAD
既存のプログラムを解析して、プログラムの仕様や設計の情報を取り出す技術。リバースエンジニアリング
要件定義→システム設計→プログラミング→テストの流れで行うシステム開発のこと。フォワードエンジニアリング
アジャイル開発の1つ。開発チームが一致団結するにはどうしたら良いかに着目したソフトウェア開発手法。スクラム
プログラムが計画書どうり、実装されているかを確かめることコードインスペクション
オブジェクト志向開発において設計とプログハミングを何度か行き来しトライアンドエラーで改良していく手法ラウンドトリップモデル
開発プロセスを繰り返し利用者の要求に応じながら改良する手法サブシステムモデル
プログラムの処理手順を順次、選択、繰り返しの3つで表す手法。構造化
システムの早い段階から、試作品を作って利用者に確認しながら開発を進める手法プロトタイピング
ハードウェアとソフトウエアから構成される。ソフトウェアは1部。システム
必要なハードウェアを調達し、必要な機能を持ったソフトウェアを新たに作ること。システム開発
システムで実現したいことを決める工程。システム要件定義
システム要件定義で決めたことを実現するためにハードウェアとソフトウエアの仕様や動作を決める工程。システム設計
完成したソフトウェアをお客さんに納品する工程ソフトウェア受け入れ
システムに必要な条件(システム要件)を決める工程システム要件定義
業務要件のうちシステムで実現する要件。システムに必要な機能や性能。システム要件
ユーザへのヒアリングで明らかになった、システムに必要な機能。※レーンにのせた寿司がお客さんの所へ届くこと機能要件
ユーザへのヒアリングでは出てこないが、システムに必要な性能※応答時間やセキュリティせいなど非機能要件
ソフトウェアの品質を評価する基準。機能性、信頼性、使用性、効率性、保守性、移植性の6つがある品質特性
システム要件定義書を開発側と発注側の両者で内容を確認して、謝りや相違点がないかチェックする作業共同レビュー
システム要件定義で決められたことをもとにして、システムの設計図をかきおこすこと。システム設計
システム要件定義のプロセスに洗い出したシステム要件をハードウェアと手作業いずれかに振り分けるプロセスシステム方式設計
ソフトウェアの要件(機能や性能)を決める工程システム方式で割り振られたものを具現化する。インターフェースの要件(画面、帳票等)データの要件(データの種類、要件等)ソフトウェア要件定義
ソフトウェア要件定義で決めたソフトウェア要件をプログラム単位まで分割する工程。ソフトウェア方式設計
ソフトウェア方式でプログラム単位まで分割された要件をさらにコーディングできるまで分割する工程。具体的にはフロートチャート(流れ図)にして表わす。ソフトウェア詳細設計
ソフトウェア詳細設計で分割されたプログラムのことソフトウェアユニット
ユーザーから見える箇所の設計。ユーザかの立場からみた業務機能。システム要件定義とシステム方式設計外部設計
プログラム言語の文法に従って処理手順を書く工程*プログラミング担当者をプログラマという。ソフトウェア詳細設計の後に行うプログラミング
プログラミング工程のうち、流れ図に沿ってソースコードを記述することコーディング
人間が書いたプログラムを機械語に変換すること。処理を行う機能をコンパイラという。コンパイル
人間が読みやすいプログラム言語で書かれたプログラム。コンパイラが機械語に翻訳される前のプログラムのこと。ソースコード
人間が書いたコンピュータが読むことができる機械語に変換する機能。コンパイラ
プログラムに誤りがないことを検証する。ホワイトボックステストと呼ばれるテスト手法単体テスト
単体テストが完了したプログラム同士を組み合わせ、データ受け渡しや連携が上手くいくか検証する。ブラックボックステストのテスト手法。結合テスト
システム要件が仕様道理に動作するかを検証するシステムテスト
本番環境と同じ条件下でシステムを運用し、動作することを検証する。運用テスト
あるものとあるものを繋ぐ部分のこと。ハードウェアインターフェースが代表例としてパソコンと周辺機器を繋ぐ部分をハードウェアインターフェースというインターフェース
入力したデータが意図的に、処理されているかを、プログラムの内部構造を分析して確認するテスト手法。プログラムに記述されている全ての処理を実行し、動作を確認する。ホワイトボックステスト
入力と出力だけに着目し、ある入力に対して、仕様書どうりの出力が得られるかどうか確認するテスト。結果さえ良ければ気にしない。ブラックボックステスト
プログラム上の誤りや不具合を修正する作業。デバック
システムに修正や追加機能をしたために、別の所で新しいバグがでてないかを確認するテスト回帰テスト
開発者が作成したソフトウェアを発注者に納品する工程ソフトウェア受け入れ
発注側の本番環境にソフトウエアをインストールする工程。現システムを新システムに切り替えることを移行という。ソフトウェア導入
発注者がソフトウェア受け入れテストを行い発注者がその手助けすること。ソフトウェア受け入れ支援
開発者が発注者にシステムを引渡す際に行われるテスト。発注者がテストを行う。＊検収ソフトウェア受け入れテスト
システムを利用するユーザに向け書かれたシステムの操作方法や障害時対応が掲載されている説明書り利用者マニュアル
完成したシステムを本番環境で動かす工程。運用プロセス
稼働中に見つかったバグを修正したり、ソフトウェアに新機能を追加したりする工程。保守プロセス
システムが提供する機能に点数をつけて、開発費用を見積る方法。ファンクションポイント法
ソフトウェア開発プロセスを上流工程から下流工程へ向かって一直線に順番に進める手法。計画がたてやすく、修正作業が大変ウォータフォールモデル
短期間にソフトウェア開発とリリースを繰り返し、ビジネス環境の変化やユーザーニーズに柔軟に対応する開発モデルアジャイル開発
開発担当者と運用担当者が連携してシステムを開発する手法。DevOps
アジャイル開発の手法の1つ。19のプラクティス(実践)が定義された開発手法。XP
通常はプログラムを書いた後に行う単体テストを順序を逆にして先に行い、このテストを通るようにプログラムを書く開発手法。テスト駆動開発
2人のプログラマが1つのパソコンを使ってソフトウェアを開発する手法ペアプログラミング
プログラムの機能仕様は変えず、内部構造を変えること。プログラムの内部のソースコードだけかえることリファタリング
ソフトウェアを部品化することで再利用しやすくし、開発を効率化する手法オブジェクト志向
システムを利用する部門(エンドユーザー)が主体的にシステム開発や運用に携わることEUC
少数の人数でプロトタイピングを繰り返し短い期間で開発するモデルRAD
既存のプログラムを解析して、プログラムの仕様や設計の情報を取り出す技術。リバースエンジニアリング
要件定義→システム設計→プログラミング→テストの流れで行うシステム開発のこと。フォワードエンジニアリング
アジャイル開発の1つ。開発チームが一致団結するにはどうしたら良いかに着目したソフトウェア開発手法。スクラム
プログラムが計画書どうり、実装されているかを確かめることコードインスペクション
オブジェクト志向開発において設計とプログハミングを何度か行き来しトライアンドエラーで改良していく手法ラウンドトリップモデル
開発プロセスを繰り返し利用者の要求に応じながら改良する手法サブシステムモデル
プログラムの処理手順を順次、選択、繰り返しの3つで表す手法。構造化
システムの早い段階から、試作品を作って利用者に確認しながら開発を進める手法プロトタイピング
