【ITパスポート】マネジメント系 > システム開発技術

開発技術の出題内容は「システム開発技術」と「ソフトウェア開発管理技術」の2つに分類され、それぞれに関する知識が問われます。
マネジメント系分野の概要についてはこちらをご確認ください。

IT

ここでは、マネジメント系のシステム開発技術の詳細について、重要なワードと解説について記載しています。

システム開発技術

・開発プロセス

システム要件定義(要件定義) システム化する業務や対象範囲を明確にして、システムに必要な機能や性能などを決定する
システム化方式設計(外部設計) システム要件定義書を基にして、すべてのシステム要件をハードウェアで実現するもの(ハードウェア構成)やソフトウェアで実現するもの(ソフトウェア構成)、手作業で行うものに振り分け、システム構成を決定する
ソフトウェア要件定義(外部設計) システム方式設計書を基に、利用者の視点から、システムを構成するソフトウェアに求められる機能や能力、インターフェース(ファイル、画面、帳票などの形式)などを決定する
ソフトウェア方式設計(内部設計) ソフトウェア要件定義書を基に、開発者の視点から、すでに決定しているソフトウェア要件を、どのように実現させるかを決定する
ソフトウェア詳細設計(プログラム設計) ソフトウェア方針設計書を基に、プログラムを作成できるレベルまで詳細化して、プログラムの仕様(アルゴリズム)を定義する
ソフトウェアコード構築(プログラミング) ソフトウェア詳細設計書を基に、プログラムの仕様やコーディング規約に従ってプログラムを作成する
コーディング規約 変数の命名規則やコメントの書き方など、プログラムの標準的な記述を定めておくこと
仕様変更 ソフトウェア開発の途中で、仕様変更が発生する場合がある。仕様変更の要求を受け付け、仕様変更の必要性、影響度、優先順位などを評価する。最終的に、決定権を持つ会議や責任者によって仕様変更の承認が得られれば、関係者に指示し反映する

・ソフトウェアの6つの品質特性

機能性 仕様目的や要件に従って正しく動作すること
使用性 利用者にとって理解、習得、操作しやすいこと
信頼性 必要な時に使用でき、故障時には速やかに回復できること
効率性 応答時間や処理時間など求められる性能が備わっていること
保守性 修正のしやすいこと
移植性 ある環境から他の環境に移しやすいこと

・テストと運用・保守    

テスト 開発中のプログラムやシステムが正しく動作するかを検証するために、様々な手法を使ってテストを行う。テストの目的は、バグ(プログラムに潜んでいる誤りや欠陥)を発見すること。
テストケース 作成したプログラムを検証するために、入力データを想定して、それに対する出力結果がどうあるべきかを記述したもの
信頼度成長曲線 テスト開発段階では多くのバグが潜んでいるが、テストを消化するにつれてバグが減少し、高品質のプログラムやシステムになっていく状態をグラフに表したもの
テスト工程 ソフトウェア詳細設計で、プログラムはモジュールというレベルまで細分化され、モジュール単位でプログラムを作成していく。モジュールには、部品という意味があり、ある独立した機能を持った構成単位で、ソフトウェアユニットとも呼ばれる。テストでは1つのモジュールから徐々に積み上げていく方法がとられる
ソフトウェアユニットテスト(単体テスト) ソフトウェアが、ソフトウェア詳細設計書通りに正しく動作するかを検証する
ソフトウェア結合テスト(結合テスト) ソフトウェアが、ソフトウェア方式設計書通りに正しく動作するかを検証する
ソフトウェア適格性確認 ソフトウェアが、ソフトウェア要件定義書通りに正しく動作するかを検証する
システム結合テスト システムが、システム方式設計書通りに正しく動作するかを検証する
システム適格性確認テスト(システムテスト) システムが、システム要件定義書通りに正しく動作するかを検証する
ソフトウェアユニットテスト(単体テスト) プログラムの部品であるモジュールを単体でテストする(代表的な手法:ホワイトボックステスト)
ホワイトボックステスト プログラムの内部構造に注目してテストする。例えば「モジュール内の全分岐を1回以上通るデータ」や「モジュール内の全命令が1回以上実行されるデータ」などのテストデータを使う
ブラックボックステスト プログラムの内部構造を考慮せず、入力データと出力結果の関係に注目してテストデータを作成し、仕様書通りに機能するかどうかをテストする。プログラム設計者が意図した機能を実現しているかどうか確認するテストであり、様々なテスト工程で、主に開発者以外の第三者が実地する
ソフトウェア結合テスト(結合テスト) ソフトウケアユニットテストが完了したモジュールを結合してテストする。モジュール間でやりとりする命令やデータの受け渡しがうまくいくかというインターフェースを検証する。開発者が実地する。
システム適格性確認テスト(システムテスト) 実際に業務で使うデータや業務上例外として処理されるデータを使って、以下のテストを行う。開発者が主体となり、利用者も協力して実施する。
機能テスト システム要件に定められている機能が、全て含まれているかどうかを検証する
性能テスト 要求される処理能力や応答時を満たしているかどうかを検証する
例外処理テスト 間違ったデータを入力した時にエラーとして認識されるかどうかを検証する
負荷テスト 量的な負荷をかけてシステムが業務に耐えられるかどうかを検証する
操作性テスト 操作性の良さや表示されるメッセージの分かりやすさを検証する
ソフトウケアの導入 ソフトウェアが完成すると、開発環境から本番環境へ導入する。ソフトウェアの導入に先立ち、以下の項目を記載したシステム導入計画書を作成する。
・新システムへの移行方法
・新システムの移行による業務への影響範囲
・新システムに切り替えるためのスケジュールや体制
運用テスト 実際に本番環境下で運用して、問題点を発見するシステム。運用マニュアルが適切であり、決められた業務手順通りに、システムが稼働するかどうかを検証する。利用者が主体となって、開発者と協力して実施する
ソフトウェア受入れ ソフトウェアが仕様通りに完成していることを、開発者の支援を受けつつ利用者が確認し(受入れテスト)、ソフトウェアを受け入れる。受入れテストは、運用テストによって行われることもある。開発者は利用者に対して、利用者マニュアルの整備、教育訓練などを行い支援する。
ソフトウェア保守 稼働中のソフトウェアに対して、障害を起こす可能性のあるプログラムが外部環境の変化に対応するための修正、機能追加や変更に対応するための修正を行う。習性後は、マニュアルやドキュメントの改訂も必ず行う。
レグレションテスト(退行テスト) ソフトウェアの保守にあたり、修正や変更が他の正常箇所に影響していないことを確認するテスト

システムを開発する手方は色々あり、主なものとしては、ウォータフォールモデル、プロトタイピングモデル、スパイラルモデルなどがあります。

ウォータフォールモデル ウォータフォール(water fall)には、「滝」という意味があり、開発工程を「要求定義」、「システム設計」、「プログラミング」、「テスト」の順に、滝が上から下に流れるように各工程を順番に進めていく技法
プロトタイピングモデル プロトタイプ(prptptype)には、「試作品」という意味があり、システム開発の早い段階から試作品を作成して、利用者の確認を得ながら開発を進めていく開発技法
スパイラルモデル スパイラル(spiral)には、「渦巻き」という意味があり、大規模なアプリケーションを開発する時、独立性の高いサブシステムごとに、分析、設計、プログラミング、テスト、評価の開発工程を反復しながら完成度を高めていく開発技表
RAD(Rapid Application Development) 利用者の参画、少人数による開発、開発ツールの活用によって、短期間にシステムを開発する手法
アジャイル 従来のウォータフォールモデルでは、開発期間が長く、利用者が完成品を見られるまでに時間がかかる、仕様変更に柔軟に対応できないなどの欠点があるため、アジャイルでは、システムを迅速に開発するための軽量なソフトウェア開発手法の総称
リバースエンジニアリング 既存のプログラムを解析して仕様書を作成する開発手法
EUC(End User Computing) 利用者がシステム環境の構築や運用管理を行ったり、情報機器を使用して自ら業務処理を行う
ソフトウェアパッケージ DVDや USBメモリなどの記憶媒体に記録して、箱に詰められて販売されているソフトウェア

・ユーザインタフェース

ユーザインタフェース(UI) 利用者とコンピュータの接する境界部分
CUI(Character User Interface)方式 コンピュータはキーボードからコマンド(命令)を入力して操作する方式
GUI(Graphical User Interface)方式 画面に表示されたアイコンユアボタンをマウスなどのポインティングデバイスで視覚的に選ぶ方式

・GUIの部品

プルダウンメニュー 垂れ下がって表示されるメニュー
ポップアップメニュー 画面上に飛び出すように表示されるメニュー
ラジオボタン いくつかの項目から一つだけを選択するメニュー
チェックボックス いくつかの項目について、それぞれに項目を選択するかどうかを指定するメニュー

・画面設計

(例)ふりがなと氏名 関連する入力項目は隣接するようにする
作業効率 作業効率向上のために、ある項目の入力が終了したら、カーソルが自動的に次の項目に移動するようにする。基本的に画面左から右へ、上から下へと移動させ入力項目以外の項目には移動させない
罫線、強調 罫線や強調表示はあくまでも入力補助であるので、適時使用する
色、点滅 色や点滅などによる視覚的注意は、誤操作を防止する効果があるので、適時使用する
エラーメッセージ エラーメッセージは、利用者が何をすべきかを簡明化つ正確に表示する
ガイド情報 不慣れな利用者が想定される場合は、入力項目ごとにガイド情報を表示する
ヘルプ機能 画面上に説明が多いと繁雑に感じるので、説明が必要な入力項目についてはヘルプ機能を用意し、画面は簡素にする
使用頻度 使用頻度の高い操作に対しては、マウスとキーボードの両方のインタゲースを用意する
デフォルト値 入力画面で、画面が表示された時点で、ある値がすでに選択された状態になるように設定する、この値のこと

・帳票設計

システムで出力する印刷物のフォームを決める

考慮1 帳票に統一性をもたせるために、タイトルの位置、出力項目などに関する設計上のルールを決めておく
考慮2 余分な情報は除いて必要最低限の情報を盛り込む
考慮3 関連する項目は隣接するようにする
ユニバーサルデザイン 障害、年齢、性別、国籍などに関わらず、誰もが使える設計
アクセシビリティ 障害者や高齢者がサービスを支障なく操作または利用できる度合い
ユーザビリティ どれだけ利用者がストレスを感じずに、目標とする要求が達成できる度合い
UX(User experience) 使いやすさや機能にとどまらず、使うことで利用者が楽しく快適な体験ができるかどうかまで含む
コード設計 システム構築時に使用するデータにコードを割り当てて扱う(代表的なもの:学生を割り当てた学籍番号、商品を割り当てた商品コード、顧客を割り当てた顧客コード)
チェックディジット コードの入力誤りや読み取り誤りを検出するために付加された数字(バーコードでも利用されている)


あわせて読みたい

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です