システムを利用するユーザに向け書かれたシステムの操作方法や障害時対応が掲載されている説明書り

必要なハードウェアを調達し、必要な機能を持ったソフトウェアを新たに作ること。

開発担当者と運用担当者が連携してシステムを開発する手法。

システム要件が仕様道理に動作するかを検証する

アジャイル開発の1つ。開発チームが一致団結するにはどうしたら良いかに着目したソフトウェア開発手法。

ソフトウェアの要件(機能や性能)を決める工程システム方式で割り振られたものを具現化する。インターフェースの要件(画面、帳票等)データの要件(データの種類、要件等)

システムに修正や追加機能をしたために、別の所で新しいバグがでてないかを確認するテスト

既存のプログラムを解析して、プログラムの仕様や設計の情報を取り出す技術。

システムを利用する部門(エンドユーザー)が主体的にシステム開発や運用に携わること

入力と出力だけに着目し、ある入力に対して、仕様書どうりの出力が得られるかどうか確認するテスト。結果さえ良ければ気にしない。

ハードウェアとソフトウエアから構成される。ソフトウェアは1部。

システムで実現したいことを決める工程。

あるものとあるものを繋ぐ部分のこと。ハードウェアインターフェースが代表例としてパソコンと周辺機器を繋ぐ部分をハードウェアインターフェースという

システムが提供する機能に点数をつけて、開発費用を見積る方法。

ソフトウェア開発プロセスを上流工程から下流工程へ向かって一直線に順番に進める手法。計画がたてやすく、修正作業が大変

ユーザへのヒアリングでは出てこないが、システムに必要な性能※応答時間やセキュリティせいなど

アジャイル開発の手法の1つ。19のプラクティス(実践)が定義された開発手法。

人間が書いたプログラムを機械語に変換すること。処理を行う機能をコンパイラという。

ソフトウェアを部品化することで再利用しやすくし、開発を効率化する手法

入力したデータが意図的に、処理されているかを、プログラムの内部構造を分析して確認するテスト手法。プログラムに記述されている全ての処理を実行し、動作を確認する。

実際にソースコードを書く工程

オブジェクト志向開発において設計とプログハミングを何度か行き来しトライアンドエラーで改良していく手法

2人のプログラマが1つのパソコンを使ってソフトウェアを開発する手法

プログラム言語の文法に従って処理手順を書く工程*プログラミング担当者をプログラマという。ソフトウェア詳細設計の後に行う

ユーザへのヒアリングで明らかになった、システムに必要な機能。※レーンにのせた寿司がお客さんの所へ届くこと

ソフトウェア要件定義で決めたソフトウェア要件をプログラム単位まで分割する工程。

プログラムの処理手順を順次、選択、繰り返しの3つで表す手法。

発注側の本番環境にソフトウエアをインストールする工程。現システムを新システムに切り替えることを移行という。

システムの早い段階から、試作品を作って利用者に確認しながら開発を進める手法

システムが仕様どうりに動くか確認する工程

本番環境と同じ条件下でシステムを運用し、動作することを検証する。

完成したシステムを本番環境で動かす工程。

ソースコードをレビューすること

システム要件定義で決められたことをもとにして、システムの設計図をかきおこすこと。

プログラム上の誤りや不具合を修正する作業。

システムに必要な条件(システム要件)を決める工程

システム要件定義のプロセスに洗い出したシステム要件をハードウェアと手作業いずれかに振り分けるプロセス

単体テストが完了したプログラム同士を組み合わせ、データ受け渡しや連携が上手くいくか検証する。ブラックボックステストのテスト手法。

人間が書いたコンピュータが読むことができる機械語に変換する機能。

通常はプログラムを書いた後に行う単体テストを順序を逆にして先に行い、このテストを通るようにプログラムを書く開発手法。

コンピュータが0と1で書いたもの。

短期間にソフトウェア開発とリリースを繰り返し、ビジネス環境の変化やユーザーニーズに柔軟に対応する開発モデル

発注者がソフトウェア受け入れテストを行い発注者がその手助けすること。

プログラムに誤りがないことを検証する。ホワイトボックステストと呼ばれるテスト手法

開発プロセスを繰り返し利用者の要求に応じながら改良する手法

プログラムの機能仕様は変えず、内部構造を変えること。プログラムの内部のソースコードだけかえること

開発者が発注者にシステムを引渡す際に行われるテスト。発注者がテストを行う。＊検収

要件定義→システム設計→プログラミング→テストの流れで行うシステム開発のこと。

ソフトウェア方式でプログラム単位まで分割された要件をさらにコーディングできるまで分割する工程。具体的にはフロートチャート(流れ図)にして表わす。

ユーザーから見える箇所の設計。ユーザかの立場からみた業務機能。システム要件定義とシステム方式設計

プログラムが計画書どうり、実装されているかを確かめること

開発者が作成したソフトウェアを発注者に納品する工程

完成したソフトウェアをお客さんに納品する工程

業務要件のうちシステムで実現する要件。システムに必要な機能や性能。

システム要件定義書を開発側と発注側の両者で内容を確認して、謝りや相違点がないかチェックする作業

ソフトウェア詳細設計で分割されたプログラムのこと

プログラミング工程のうち、流れ図に沿ってソースコードを記述すること

ソフトウェアの品質を評価する基準。機能性、信頼性、使用性、効率性、保守性、移植性の6つがある

システム要件定義で決めたことを実現するためにハードウェアとソフトウエアの仕様や動作を決める工程。

少数の人数でプロトタイピングを繰り返し短い期間で開発するモデル

人間が読みやすいプログラム言語で書かれたプログラム。コンパイラが機械語に翻訳される前のプログラムのこと。

稼働中に見つかったバグを修正したり、ソフトウェアに新機能を追加したりする工程。