開発技術　(説明)

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

ユーザーも把握しいるシステムに必要な機能

ユーザーが把握しきれていない、システムに必要な性能

ソフトウェアの品質を評価する基準

・システムで実現したいことを決める工程 ・システムに必要な「機能」や「性能」を決める工程

業務要件のうち、システムで実現する役割のこと

システム要件定義のプロセスで作成する文書

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

ソフトウェアの要件(機能や性能)を決める工程

ソフトウェア要件定義で決めたソフトウェア要件(機能や性能)をプログラムの単位まで分割する工程 (ソフトウェア要件をどこまで実現するか決める)

ソフトウェア方式設計で分割したものをさらに「コーディングができる単位」まで分割する工程

ユーザーが見える箇所の設計

ユーザーから見えない箇所の設計

・システム要件定義で決めたことを実現するために、ハードウェアとソフトウェアの仕事や動作を決める工程 ・システム要件定義で決めたことを元にして、設計図を書き起こす

・実際にソースコードを書く工程 ・プログラム言語の文法に従って処理手順を書く工程

プログラミングの担当者

プログラミングなどを用いてソースコードを書くこと

人間が書いたプログラムを機械語に変換すること

人間が書いたプログラムを機械語に変換する機能

人間が読みやすいプログラム言語で書かれたプログラム

コンピュータが読むことが可能な、０と１で表される言語

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

プラグラムに誤りがないことを検証するテスト

単体テストが完了したプログラミング同士を組み合わせて、データの受け渡しや、連携がうまくいくかを検証するテスト

システム要件が仕様どおりに動作するかを検証するテスト

本番環境と同じ条件下でシステムを運用し、業務要件どおりにシステムが動くかを検証するテスト

あるモノとあるモノをつなぐ部分のこと

入力したデータが、意図どおりに処理されているかを、プログラムの内部構造を分析して確認するテスト手法

入力と出力だけに着目し、ある入力に対して仕様書どおりの出力が得られるかを確認するテスト手法 (システムが実際にどのような処理を行っているかは問題ではなく、入力と出力の結果が正しければ良しとする)

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

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

リグレッションテスト ・システムに修正や機能を追加をしたために、別のところで新しいバグが出ていないかを確認するテスト

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

発注者側の本番環境にソフトウェアをインストールする工程

発注者が「ソフトウェア受入れテスト」を行い、開発者がそのテストの手助けをする工程

開発者が発注者にシステムを引き渡す際に行われるテストであり、システムの契約内容どおり完成しているかを確認する

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

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

本番稼働中のソフトウェアを修正・改善すること

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

ソフトウェアの開発プロセスや開発方法をモデル化したもの

ソフトウェアの開発プロセスを上流工程から下流工程経へ向かって一直線に順番を進める手法

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

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

アジャイル開発の手法の１つで、１９のプラクティス(実践)が定義された開発手法

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

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

プログラミングの仕様機能を変えずに、内部構造を変えること

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

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

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

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

リバースエンジニアリングデで取り出した情報を元にして、従来のように開発プロセスの流れで行うシステム開発