⑥ 開発技術

Question 1

システムは何と何でできている？

Answer 1

ハードウェア＆ソフトウェア

★ソフトウェアはシステムの一部

Question 2

システム開発とは？

Answer 2

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

Question 3

ソフトウェアライフサイクルプロセス（SLCP）の５つのステップ？
（システム開発のステップ？）

Answer 3

企画
　↓
要件定義
　↓
開発
　↓
運用
　↓
保守

Question 4

開発プロセスステップの中のステップ？５つ

これは何の開発モデルに当てはまる？

Answer 4

モデル：ウォーターフォールモデル

①システム要件定義
　：システムで実現したいことを決める
　
②システム設計
　:　システム要件定義で決めたことを実現するために、ハードウェアトソフトウェアの動作を決める

③プログラミング
　：　実際にソースコードを書く工程

④テスト
　:　システムが仕様通りに動くか確認する

⑤ソフトウェア受け入れ
　：　完成したソフトウェアをお客さんに納品する

Question 5

システム要件定義とは？

Answer 5

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

Question 6

システム要件とは？

Answer 6

システムで現実する要件
（条件？）

★システムに必要な「機能」と「性能」
eg: 応答時間、運用時間

Question 7

システム要件は２つに分類される？

Answer 7

①機能要件
：ユーザーとのヒヤリングで明らかになったシステムに必要な「機能」

②非機能要件
：ヒヤリングで出てこないが、システムに必要な「性能」

Question 8

要件定義が「共有フレーム」本で３つに分類されている？

Answer 8

①要件定義プロセス
　＞業務要件を決める
　＞共有フレームの５つのステップの中の一つ

　②システム要件定義
　＞５つのプロセスの中の「開発プロセス」のうちの一つ

③ソフトウェア要件定義
　＞開発プロセスのうちの一つ
＞ソフトウェア要件を決める

Question 9

品質特性？

品質特性は６つに分けている。それは？

Answer 9

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

●機能性
●信頼性
●使用性
●効率性
●保守性
●移植性

Question 10

システム要件定義書とは？

共同レビュー？

Answer 10

システム要件定義のプロセスで作成する文書
★これが完成したら発注者と開発側両方も誤りがないかチェックする

共同レビュー：このシステム要件定義書に誤りがないかチェックする作業

Question 11

システム設計とは？

Answer 11

システム要件定義で決めたことをもとにして、システムの設計図を書くこと

Question 12

システム設計のプロセスの中に４つのステップ？

Answer 12

①システム方式設計　　　　
②ソフトウェア要件定義　
③ソフトウェア方式の設計
④ソフトウェア詳細設計

①と②　→　外部
③と④　→　内部

Question 13

システム方式設計？

目的？

Answer 13

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

目的：システムに「何が」「いくつ」必要かどうか明確にできる

例：P211

Question 14

ソフトウェア要件定義

Answer 14

ソフトウェアの要件「性能と機能」などを決める工程

システム方式設計で振り分けたシステム要件をここでより具体化する

Question 15

代表的なソフトウェア要件２つ？

Answer 15

●インターフェースの要件
　：画面、帳票、ファイル

●データの要件
　：データの種類、データベースの要件

Question 16

ソフトウェア方式設計？

Answer 16

ソフトウェア要件定義で決めたソフトウェア要件「性能と機能」をプログラムの単位まで分割する工程

Question 17

ソフトウェア詳細設計？

この工程で分割されたプログラムをなんと呼ぶ？

Answer 17

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

★具体的にフローチャートにして表す

呼び方：ソフトウェアユニット

Question 18

外部設計？

外部設計の２つの工程？

Answer 18

ユーザーから見える箇所の設計
（ユーザーの立場から見た業務機能を中心に設計する）

２つの工程：
①システム要件定義
②システム設計の「システム方式設計」

Question 19

内部設計？

内部設計の２つの工程？

Answer 19

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

２つの工程：
①システム設計の「ソフトウェア要件定義」
②システム設計の「ソフトウェア方式設計」

P213

Question 20

プログラミングとは？

Answer 20

プログラミング言語の文法に従って処理手順を書く工程
担当者は：プログラマ

Question 21

コンピューターの０と１使った言語はなんと呼ぶ？

Answer 21

機械語
★これは人間が書くことができない

Question 22

人間は機械語を使えないからプログラミングで使う２つの段階？

Answer 22

１．人間が読みやすいプログラム言語でプログラムを書く

２．それを機械語に変換してコンピューターに処理させる

Question 23

人間が書いたプログラムを機械語に変換する作業はなんと言う？

その処理を行う機能？

Answer 23

変換すること：コンパイル
　　　compile(編集する）

機能：コンパイラ

Question 24

プログラミングは開発のどのタイミングでやる工程？

Answer 24

ソフトウェア詳細設計の後にやる工程

Question 25

ソースコード？

Answer 25

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

★コンパイラが機械語に翻訳する前のプログラム

Question 26

テスト？

Answer 26

作ったシステムが仕様通りに動くか確認する工程

＋さらに、要件定義で明確にした「業務要件」がきちんと実現されているか確認する

Question 27

単体テスト？

他の呼び方？

Answer 27

プログラミングに誤りがないかを検証する

ホワイトボックステスト

Question 28

結合テスト？

他の呼び方？

Answer 28

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

ブラックボックステスト

Question 29

システムテスト？

Answer 29

システム要件が仕様通りに動くかどうかを検証する

Question 30

運用テスト？

Answer 30

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

★このテストだけユーザーがやる！

Question 31

インターフェースとは？

例？

Answer 31

あるモノとあるモノをつなぐ部分（接続）

例：ハードウェアとハードウェアのインターフェース
　＞PCを周辺のプリンターにつなげる

ユーザーインターフェース
　＞人間をコンピューターにつなげる部分　‐　操作画面

ソフトウェアインターフェース
＞プログラムをプログラムにつなぐ

Question 32

ホワイトボックステスト？

誰が行う？

Answer 32

プログラムの内部構造を分析して確認するテスト

★プログラムに記述されているすべての処理を実行し、動作を確認する

担当者：開発者（プログラマ）

Question 33

ブラックボックステスト？

誰が行う？

Answer 33

入力ト出力だけに着目して、ある入力に対して仕様書どおりの出力が得られるかどうか確認する

★システムがどのようにそれを処理しているのか関係なく、結果が正しければOK

担当者：開発者＋ユーザー

Question 34

ブラックボックスとホワイトボックステストのメリット＆デメリット？

Answer 34

●ホワイトボックス

メリット：すべての処理を検証できる

デメリット：プログラムの誤解による不具合は見つけられない

●ブラックボックス

メリット：仕様通りの動作をするか検証できる

デメリット：すべての処理をテストしないので、発生頻度が低い不具合が残る可能性がある

Question 35

ソフトウェア受入れ？

Answer 35

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

Question 36

ソフトウェア導入？

Answer 36

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

★古いシステムを新しいシステムに切り替えることを「移行」という

Question 37

ソフトウェア受入れ支援？

Answer 37

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

Question 38

ソフトウェア受入れテスト？

Answer 38

開発者が発注者にシステムを引き渡す際に行われるテスト
★システムが契約内容どおり完成しているかテストする
（発注者がやる）

Question 39

利用者マニュアル？

Answer 39

Users manual
市捨てmを利用するユーザー向けに描かれたシステムの操作方法や障害時対応が書かれている説明書

Question 40

運用プロセス？

Answer 40

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

Question 41

保守プロセスとは？

Answer 41

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

Question 42

ファンクションポイント法？

Answer 42

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

Question 43

waterfall モデル？

メリットとデメリット？

Answer 43

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

メリット：計画が立てやすい

デメリット：修正作業が大変
不具合があった工程まで戻ってやり直さなきゃいけない

Question 44

アジャイル開発とは？

Agile　（素早い）

Answer 44

waterfallモデルのデメリットを解決するために誕生したモノ

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

Question 45

アジャイル開発の特徴？

Answer 45

事前に計画を立てずに、品質はたかくなくとも、製品をリリースする

Question 46

waterfall modelとagileの違い？

Answer 46

●waterfall model
１．事前に計画を立てる
２．大きなプロジェクト
３．システムの変化に弱い

●アジャイル
　１．計画の変化が前提
　２．小さなプロジェクト
　３．システムの変化に強い

Question 47

DevOps？

Answer 47

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

Question 48

XP？

Answer 48

eXtreme Programming
アジャイル開発の手法の一つで、19のプラクティスが定義された開発手法

Question 49

XPの19のプラクティスの中のもっとも重要な3つ？

Answer 49

①テスト駆動開発
　test driven development
②ペアプログラミング
③リファクタリング
　refactoring

Question 50

テスト駆動開発？

メリット？

Answer 50

XPの一つ
★通常プログラムを書いた後に行う単体テストを先に行い、このテストを通るようにプログラムを書くこと

メリット：プログラムが書き終わった段階で、既に単体テストを合格しているので不具合の少ない状態になる

Question 51

ペアプログラミング？

メリット：

Answer 51

XPの一つ
★二人のプログラマが一つのPCを使ってソフトウェアを開発すること
：1人が書いているとき、もう1人がそれをチェックする

メリット：１．一人がやsンでいるときにもう１人が作業を進めること
２．OJTができる