【IPシラバス6.3】(1) システム開発のプロセス – 1

正解
2　ユーザー認証機能の提供

解説
機能要件はシステムが提供すべき具体的な機能を定義するものです。

ユーザー認証機能の提供はシステムの機能に関する要求です。選択肢1と3はシステムのパフォーマンスや安定性を指し、これは非機能要件に含まれるため不正解です。

正解
1　ユーザーがレポートを出力できる機能

解説
ユーザーがレポートを出力できる機能はシステムが持つべき具体的な機能です。

選択肢1は処理時間に関する非機能要件であり、選択肢3も障害に関連する非機能要件です。

正解
3　データのバックアップ処理の方法

解説
バックアップ処理の方法はデータの保護やシステムの復元に関する非機能要件です。

選択肢1と3は機能要件に含まれるため正しい選択肢です。

正解
2　システムのレスポンス時間の短縮

解説
非機能要件にはシステムの性能や品質に関する要件が含まれます。

レスポンス時間はその例であり、ユーザー認証やデータ集計機能は機能要件に含まれるため不適切です。

正解
3　商品検索機能

解説
商品検索機能はユーザーに提供する機能に該当し、機能要件です。

稼働率やUIのデザインはシステムの使用感や安定性に関する非機能要件です。

正解
3　業務プロセスの自動化機能

解説
業務プロセスの自動化は具体的な機能の提供に関わるため機能要件です。

非機能要件は拡張性や権限設定など、システムの品質や環境に関する要件を指します。

正解
2　設計やコードの問題を早期に発見し改善する

解説
共同レビューの目的は設計やコードの不具合を早期に発見し、開発品質を向上させることです。

稼働率や処理速度はシステムの性能に関わるもので、レビューの目的とは異なります。

正解
1　チーム内での知識共有と品質向上が図れる

解説
共同レビューはチーム内での知識共有を促進し、ソフトウェアの品質向上につながる活動です。

進捗管理や納期短縮は直接的な目的ではないため不適切です。

正解
3　バグ修正の進捗確認

解説
バグ修正の進捗確認は管理業務の一環であり、共同レビューの目的とは異なります。

設計やコード、ドキュメントの確認がレビュー対象として適しています。

正解
2　システムの効率性

解説
品質特性にはシステムの効率性が含まれます。

開発コストやテスト回数は品質特性ではなく、開発におけるリソースの項目です。

正解
2　システムの継続稼働が重要な場合

解説
信頼性はシステムの継続的な稼働や故障の少なさを示す品質特性です。

選択肢1は保守性に関連し、選択肢3は効率性の観点です。

正解
1　操作が簡単でユーザーにとって分かりやすい

解説
使用性は、ユーザーがシステムを使いやすいかどうかを示す品質特性です。

高速な処理やエラー頻度は他の品質特性に関わります。

正解
2　ユーザーが使用する具体的な機能の詳細化

解説
機能設計ではユーザーが使用する機能や操作の流れを具体的に決めていきます。

処理速度は性能に関わる非機能要件、バグ修正はプログラム作成後の工程に含まれるため、適切ではありません。

正解
1　画面遷移やデータの流れの設計

解説
機能設計では、ユーザーインターフェースやデータの流れなど、システムの機能的な設計が重要です。

ハードウェア仕様や進捗管理は他の段階や管理項目に関する内容であるため不正解です。

正解
3　サーバーの負荷テスト実施

解説
サーバーの負荷テストはシステムが適切に動作するかを確認するテスト段階で行います。

機能設計ではデータのやり取り方法や画面設計など、ユーザー機能に関連する部分を設計する作業が含まれます。

正解
1　各機能を実現するためのモジュール構成やデータベース設計

解説
詳細設計では機能実現のためのモジュール構成やデータベース設計が行われます。

機能リストの作成は要件定義段階で、フィードバック収集は設計の内容ではありません。

正解
2　各モジュールやデータベースの具体的な構成の決定

解説
詳細設計の段階ではシステムの構成要素であるモジュールやデータベースについて具体的に決定します。

画面デザインや全体の要件はそれ以前の段階で決める内容です。

正解
3　デバッグを行い不具合を修正する

解説
デバッグはコーディング後に行われる作業で、詳細設計には含まれません。

詳細設計では画面やモジュール構成など、プログラムの実装を意識した具体的な内容を決定します。

正解
2　詳細設計をもとにした正確な実装

解説
コーディングでは詳細設計に従って正確にプログラムを実装することが重要です。

動作速度やデザインは他の工程で考慮されるものであり、コーディング段階では正確な実装が優先されます。

正解
2　プログラムが正常に機能するように設計内容をコードにする

解説
コーディングの主な目的は、設計内容に基づいてプログラムを実装することです。

エラー解消はテスト工程での主な目的です。ユーザーインターフェースの構築も、設計段階で決められた内容に従いコーディングされます。

正解
1　プログラムの実行速度の確認

解説
コーディングはプログラムを設計通りに実装する工程であり、実行速度の確認は主にテスト段階で行います。

命名や実装はコーディング中に行う作業です。

正解
3　プログラムの内部処理やロジックの誤りを発見する

解説
ホワイトボックステストではプログラムの内部構造に基づきロジックの誤りを検出します。

システムの動作確認はブラックボックステスト、UIの評価は別のテスト工程で行われます。

正解
2　各分岐やループが正しく動作するかの確認

解説
ホワイトボックステストではプログラム内部の分岐やループの動作を詳細に確認します。

外部仕様に基づく機能確認や使用感の確認はブラックボックステストで行われるため不正解です。

正解
1　外部からの動作結果のみを確認する

解説
ホワイトボックステストはプログラム内部の構造を詳細に確認するテストであり、外部からの動作確認はブラックボックステストに分類されます。ロジックエラーの検出に適している点も特徴です。

正解
3　プログラムの不具合を発見し修正する

解説
デバッグの主な目的はプログラムの不具合を発見して修正し、ソフトウェアが正常に動作するようにすることです。

機能追加や性能測定はデバッグの範囲外です。

正解
2　エラー発生の原因を特定し、適切な修正を加える

解説
デバッグではエラーの原因を特定し、その原因に対して適切な修正を行うことが重要です。

コード全体の書き直しは時間がかかり、デバッグの範囲を超えます。レビューも有効ですがテストを行わないのは不適切です。

正解
3　開発する機能を要件定義に基づいて再確認する

解説
要件定義の再確認はデバッグの範囲ではなく、要件定義や設計段階の作業にあたります。

デバッグではエラーの特定や修正後の動作確認が主な作業です。

正解
2　コードの品質と可読性を高める

解説
コードレビューの主な目的はコードの品質や可読性を高め、エラーの早期発見につなげることです。

動作速度やユーザーインターフェースの確認は、レビューの範囲外です。

正解
3　システム全体の設計を決定する

解説
コードレビューは書かれたコードの内容を確認するプロセスであり、設計の決定は行いません。

他のメンバーの意見を取り入れることやエラーの早期発見がコードレビューの主な目的です。

正解
1　コードの可読性や適切な命名規則を確認する

解説
コードレビューではコードの可読性や命名規則の適切さなどが確認されます。

動作速度の調整やインフラ設定は、別の工程で行われるため不適切です。