banner
cos

cos

愿热情永存,愿热爱不灭,愿生活无憾
github
tg_channel
bilibili

ソフトウェア工学期末小テスト

  • 後記、なぜ正しい答えを教えてくれなかったのかがわかりました…… 期末試験の出題された原題 - -
  • 勘誤:51 問目の要求工学の 7 つのステップは、開始、取得、詳細化、交渉、仕様書、確認、管理(変更管理)であるべきです。書籍の 74 ページ(日本語版)

太字が答えです(参考までに)、間違いがあればコメントしてください。結局、先生が正しい答えを教えてくれなかったので。 解説も書きましたが、すべて個人的な見解です0.0

一、単選択問題#

1、ソフトウェアは磨耗するのではなく退化するのはなぜですか()?#

ソフトウェアが磨耗するのではなく退化する理由は?

A ソフトウェアは敵対的な環境にさらされるから
B ソフトウェアが頻繁に使用されると欠陥が発生しやすくなるから
C 複数の変更要求がコンポーネント間のエラーを引き起こすから

正しい答え:継続的な要求の変更がコンポーネントインターフェース間にエラーを引き起こす

D ソフトウェアのスペアパーツの注文が難しくなるから

2. これらの中で、5 つの一般的なソフトウェア工学フレームワーク活動はどれですか?#

一般的なソフトウェア工学プロセスフレームワーク活動はどれですか?

A コミュニケーション、計画、モデリング、構築、展開

正しい答え:コミュニケーション - 計画 - モデリング - 構築 - 展開

  • コミュニケーション:目的は利害関係者のプロジェクト目標を理解し、ソフトウェアの特性と機能を定義するための要求を収集することです。
  • 計画:ソフトウェア工学の作業を定義し、記述し、実行する必要がある技術的タスク、潜在的なリスク、リソースの要求、作業製品、作業スケジュールを含みます。
  • モデリング:モデルを使用してソフトウェアの要求をよりよく理解し、それに合ったソフトウェア設計を完成させます。
  • 構築:コーディングとテストを含み、コーディング中に発見されたエラーを修正します。
  • 展開:ソフトウェア(全体または部分的な増分)をユーザーに提供し、ユーザーが評価しフィードバックを提供します。

B コミュニケーション、リスク管理、測定、生産、レビュー

C 分析、設計、プログラミング、デバッグ、保守

D 分析、計画、設計、プログラミング、テスト

3. 以下の項目の中で、ソフトウェア工学の層の 1 つではないものはどれですか?#

以下の中でソフトウェア工学の層の 1 つではないものはどれですか?

ソフトウェア工学は階層的な技術であり、プロセス層(process)、方法層(methods)、ツール層(tool)を含みます。

A プロセス

B 製造は含まれない

C 方法

D ツール

4. プロセスモデルがアジャイルとされる理由は?#

プロセスモデルがアジャイルとされる理由は?

A 煩雑な文書作成の必要性を排除するから

B 機動性と適応性を強調するから

C 計画活動に開発時間を無駄にしないから

D プロトタイプ作成を広範に利用するから

5. 進化的ソフトウェアプロセスモデル#

進化的ソフトウェアプロセスモデル

本質的に反復的であり、製品要求の変化に容易に適応でき、一般的に使い捨てシステムを生産しません。

** 進化モデル(Evolutionary Model)には、一般的に使用される 2 つのタイプがあります:**迅速なプロトタイプ(Rapid Prototype)開発と螺旋モデル

  • 迅速なプロトタイプ開発は、コミュニケーションから始まり、ソフトウェア開発者が他の利害関係者とコミュニケーションを取り、ソフトウェアの全体的な目標を定義し、既知の要求を明確にし、今後さらに定義するものを大まかに描きます。その後、迅速にプロトタイプ開発の反復を計画し、モデリング(迅速な設計)を行います。迅速な設計は、最終ユーザーが見ることができる側面に主に焦点を当て、プロトタイプを生成し、プロトタイプを展開した後、利害関係者によって評価され、利害関係者のフィードバックに基づいてソフトウェアの要求をさらに洗練させます。
  • 螺旋モデルは、迅速なプロトタイプモデルを進化的な開発方法に中心に据え、各プロジェクト段階でウォーターフォールモデル法を使用します。このモデルの各サイクルには、要求定義、リスク分析、エンジニアリング実現、レビューの 4 つの段階が含まれ、これらの 4 つの段階で反復されます。ソフトウェア開発プロセスが 1 回反復されるごとに、ソフトウェア開発は 1 つのレベルを進めます。螺旋モデルはリスク分析を強調し、開発者とユーザーが各進化層で発生するリスクを理解し、適切な反応をすることを可能にするため、大規模で複雑かつ高リスクのシステムに適しています。

6. ソフトウェア開発の線形順序モデルは#

ソフトウェア開発の線形順序モデルは

ウォーターフォールモデルです。明確に要求を定義する際にウォーターフォールモデルで開発するのが最適です。

A 要求が明確に定義されている場合の合理的なアプローチ

B 作業プログラムが迅速に必要な場合の良いアプローチ。

C 大規模な開発チーム向けの最良のアプローチ。

D 現代の文脈で使用できない古いモデル。

7. ソフトウェア開発の増分モデルは#

ソフトウェア開発の増分モデルは

増分モデルは、ウォーターフォールモデルの順序特性と迅速なプロトタイプ法の反復特性を組み合わせ、ソフトウェアを相互に関連する一連の増分として見なします。開発プロセスの各反復で、1 つの増分を完成させることで、短期間でユーザーに完成した部分的な製品を提出できます。

A 要求が明確に定義されている場合の合理的なアプローチ

B 作業コア製品が迅速に必要な場合の良いアプローチ

C 大規模な開発チーム向けの最良のアプローチ

D 商業製品に使用されない革命的なモデル

8. ソフトウェア開発のプロトタイプモデルは#

ソフトウェア開発のプロトタイプモデルは

上記のように、プロトタイプ開発は初期の要求が明確になった後、迅速にプロトタイプ開発の反復を計画し、モデリング(迅速な設計)を行い、その後、要求を徐々に補充して反復するため、要求が不明確な顧客に適しています。

A 要求が明確に定義されている場合の合理的なアプローチ

B 顧客が要求を明確に定義できない場合の有用なアプローチ

C 大規模な開発チーム向けの最良のアプローチ

D 意味のある製品をほとんど生産しないリスクの高いモデル

9. 以下の特性は、アジャイルソフトウェアチームのメンバー間に存在する必要がありますか?#

以下の特性は、アジャイルソフトウェアチームのメンバー間に存在する必要がありますか?

A 能力

B 意思決定能力

C 相互信頼と尊重

D すべての上記

10. 極限プログラミング(XP)プロセスモデルで見られる 4 つのフレームワーク活動は何ですか?#

極限プログラミング(XP)プロセスモデルで見られる 4 つのフレームワーク活動は何ですか?

極限プログラミング(XP)は、アジャイルモデルの中で最も重要なソフトウェア開発フレームワークの 1 つです。計画、設計、コーディング、テストの 4 つのフレームワーク活動のルールと実践を含みます。

  • 計画:要求分析ですが、ユーザーの要求だけでなく、開発中に遭遇するすべての要求を含むべきです。
  • 設計:コーディングの前に、何をするか、構造がどうなるかなどを伝える計画があります。必ずこれに従ってください。そうしないと、混乱する可能性があります。
  • コーディング:コーディングを開始する前に、各ストーリーのために一連の単体テストを開発することをお勧めします。これらの単体テストに基づいてプログラミングを行います。同時に、効率を高めるためにペアプログラミングを奨励します。
  • テスト:毎日単体テストを実行して、問題を早期に発見します。

A 分析、設計、コーディング、テスト

B 計画、分析、設計、コーディング

C 計画、分析、コーディング、テスト

D 計画、設計、コーディング、テスト

11. 毎日のスクラムミーティングで各チームメンバーが答えるべき重要な質問の 1 つではないのはどれですか?#

毎日のスクラムミーティングで各チームメンバーが答えるべき重要な質問の 1 つではないのはどれですか?

アジャイル開発プロセスのスクラム

開発チームは自己組織化されており、毎日のスクラムミーティングでスプリントの目標を達成できるかどうかを確認します。
各開発チームメンバーは以下の 3 点を提供する必要があります:

  • 昨日何を完了しましたか;
  • 今日何を完了する予定ですか;
  • 進捗を妨げているものは何ですか。

毎日のスクラムは通常 15 分を超えません。
毎日のスクラムでは簡単な質問の明確化と回答があるかもしれませんが、トピックの議論は行われるべきではありません。
毎日のスクラムは管理層への報告でも、プロダクトオーナーやスクラムマスターへの報告でもありません。それは開発チーム内部のコミュニケーション会議であり、彼らが現状を一致して理解することを保証します。

A 前回の会議から何をしましたか?

B どのような障害に直面していますか?

C あなたが直面している問題の原因は何ですか?(×、毎日のスクラムの質問ではありません)

D 次のチームミーティングで何を達成する予定ですか?

12. 以下の中で、ソフトウェアプロセスにアジャイル性を適用するために必要ないのはどれですか?#

以下の中で、ソフトウェアプロセスにアジャイル性を適用するために必要ないのはどれですか?

A プロジェクト計画とテストの使用を排除すること(Duck は必要ありません)

B 必要な作業製品のみを生産する

C プロセスはチームがタスクを合理化できるようにする

D 増分製品配信戦略を使用する

13. どのようにして予測不可能性を管理するためのアジャイルプロセスを作成しますか?#

予測不可能性を管理するためのアジャイルプロセスをどのように作成しますか?

A 計画が行われる前にリスク分析を実施する必要があります

B ソフトウェアの増分は短期間で配信されなければなりません

C ソフトウェアプロセスは段階的に変更に適応しなければなりません

D B と C の両方

14. 以下の中で、良いコーディングの原則の 1 つではないのはどれですか?#

以下の中で、良いコーディングの原則の 1 つではないのはどれですか?

A コーディングを開始する前に単体テストを作成する

B 理解を助ける視覚的レイアウトを作成する

C 変数名を短く保ち、コードをコンパクトにする(間違いです!変数名は意味がわかるようにするべきです)

D 自己文書化コードを書く、プログラム文書ではなく(つまり、可読性の高いコードは自明であり、外部文書に依存する必要はありません)

15. 以下の中で、フッカーのソフトウェア工学実践の核心原則の 1 つではないのはどれですか?#

以下の中で、フッカーのソフトウェア工学実践の核心原則の 1 つではないのはどれですか?

A すべての設計は可能な限りシンプルであるべきですが、よりシンプルではない

B ソフトウェアシステムはユーザーに価値を提供するためだけに存在する

C パレートの法則(製品の 20%が 80%の努力を必要とする)

D あなたが生産することを他の人が消費することを忘れないでください

16. ソフトウェアエンジニアは顧客と協力して以下のどれを定義しますか?#

ソフトウェアエンジニアは顧客と協力して以下のどれを定義しますか?

A 顧客が目に見える使用シナリオ

B 重要なソフトウェア機能

C システムの入力と出力

D すべての上記

17. ユーザーストーリーはアジャイル計画でどのような役割を果たしますか?#

ユーザーストーリーはアジャイル計画でどのような役割を果たしますか?

ユーザーストーリーは、ビジネス担当者と技術者の両方が要求を理解するのを助けることを目的としています。アジャイル開発におけるユーザーストーリーの詳細化は、開発に実行可能な基準を提供します。

A 最終ユーザーに提供される有用なソフトウェア機能と機能を定義する

B 活動の詳細なスケジューリングを実行する代替手段を提供する

C 現在の増分を構築するために必要な作業量を見積もるために使用される

D A と C の両方

18. システム要求仕様は以下を説明します。#

システム要求仕様は以下を説明します。

A コンピュータベースのシステムの機能、性能、および制約

B 各割り当てられたシステムの実装

C 要素ソフトウェアアーキテクチャ

D システムシミュレーションに必要な時間

19. プロジェクト開始時のタスクの意図は以下を決定することです。#

プロジェクト開始時のタスクの意図は以下を決定することです。

A 基本的な問題の理解

B 必要な解決策の性質

C 解決策を求める人々

D すべての上記

20. 以下の中で、品質機能展開(QFD)で使用される要求分類の 1 つではないのはどれですか?#

以下の中で、品質機能展開(QFD)で使用される要求分類の 1 つではないのはどれですか?

品質機能展開(QFD)は、顧客の要求をソフトウェア技術的要求に変換する技術であり、顧客がソフトウェア工学から最大限に満足できるようにするために、正常要求、期待要求、意外要求の 3 つの要求を確認します。

A 意外要求

B 期待要求

C 強制的な要求

D 正常要求

21. 以下の中で、プロジェクト開始時に使用される文脈に依存しない質問ではないのはどれですか?#

以下の中で、プロジェクト開始時に使用される文脈に依存しない質問ではないのはどれですか?

A 良い解決策から得られる経済的利益は何ですか?

B 誰がこのプロジェクトに反対していますか?

C 誰が作業の費用を負担しますか?

D 誰が解決策を使用しますか?

22. 協力的な要求収集において、ファシリテーターは#

協力的な要求収集において、ファシリテーターは

A ソフトウェアチームのメンバーであってはならない

B 顧客であってはならない

C プロセスを制御し、促進する

D 外部者でなければならない

23. 以下の中で、システム分析モデルを作成するために使用される UML 図ではないのはどれですか?#

以下の中で、システム分析モデルを作成するために使用される UML 図ではないのはどれですか?

A アクティビティ図

B クラス図

C データフローダイアグラム

D 状態図

24.UML アクティビティ図は、どの分析モデル要素を表現するのに役立ちますか?#

UML アクティビティ図は、どの分析モデル要素を表現するのに役立ちますか?

A 行動要素

B クラスベースの要素

C フローベースの要素

D シナリオベースの要素

25. 以下の中で、分析モデルを構築する目的ではないのはどれですか?#

以下の中で、分析モデルを構築する目的ではないのはどれですか?

分析モデルが達成しなければならない 3 つの主要な目的:顧客が何を必要としているかを説明する;ソフトウェア設計の基礎を築く;ソフトウェアが完成した後に確認できる要求のセットを定義する。

A 確認できるソフトウェア要求のセットを定義する

B 顧客の要求を説明する

C 問題の簡略化された解決策を開発する

D ソフトウェア設計の基礎を築く

26. 以下の中で、CRC カードに表示されない項目はどれですか?#

以下の中で、CRC カードに表示されない項目はどれですか?

CRC カードは標準的なインデックスカードのセットであり、各カードは 1 つのクラスを表します。クラス名は上部にあり、クラスの責任は左側に、クラスの協力関係は右側に記載されています。

A クラスの協力者

B クラス名

C クラスの信頼性

D クラスの責任

二、判断問題#

27. 大多数のソフトウェア開発プロジェクトは、いくつかのビジネスニーズを満たすために開始されます。#

大多数のソフトウェア開発プロジェクトは、いくつかのビジネスニーズを満たすために開始されます。

はい

28. 変更はほとんどのソフトウェアシステムにおいて容易に適応できません。システムが変更を考慮して設計されていない限り。#

ほとんどのソフトウェアシステムにおいて、変更は容易に適応できません。システムが変更を考慮して設計されていない限り。

はい

29 は 28 と同じ

30. ソフトウェアは製品であり、他の工学的成果物と同じ技術を使用して製造できます。#

ソフトウェアは製品であり、他の工学的成果物と同じ技術を使用して製造できます。

はい

31. ソフトウェアプロセスは、既存のソフトウェアパターンから構築され、ソフトウェアプロジェクトのニーズを最もよく満たすことができます。#

ソフトウェアプロセスは、既存のソフトウェアパターンから構築され、ソフトウェアプロジェクトのニーズを最もよく満たすことができます。

はい(先人の肩に立つということです)

32. 弱いソフトウェアプロセスを持っていて、高品質な最終製品を作成することはできないということは一般的に受け入れられています。#

弱いソフトウェアプロセスを持っていて、高品質な最終製品を作成することはできないということは一般的に受け入れられています。

はい

33. ソフトウェア工学の普遍的活動は、ソフトウェア開発プロジェクトの初期段階でのみ適用されます。#

ソフトウェア工学の普遍的活動は、ソフトウェア開発プロジェクトの初期段階でのみ適用されます。

いいえ、普遍的活動はソフトウェアプロセス全体に適用されます。

34. プロセステクノロジーツールは、重要でない活動をスキップすることによって、ソフトウェア組織がスケジュールを圧縮できるようにします。#

プロセステクノロジーツールは、重要でない活動をスキップすることによって、ソフトウェア組織がスケジュールを圧縮できるようにします。

はい

35. 顧客のニーズを満たし、明日拡張できる品質特性を示すソフトウェアを構築することは不可能です。#

顧客のニーズを満たし、明日拡張できる品質特性を示すソフトウェアを構築することは不可能です。

はい

36. アジャイルソフトウェアプロセスでは、最も優先されるのは、早期かつ継続的に価値あるソフトウェアを顧客に提供することです。#

アジャイルソフトウェアプロセスでは、最も優先されるのは、早期かつ継続的に価値あるソフトウェアを顧客に提供することです。

はい

37. アジャイル性は、プロジェクトチームが変化に迅速に対応する能力に他なりません。#

アジャイル性は、プロジェクトチームが変化に迅速に対応する能力に他なりません。

いいえ、それだけではありません。

38?

39. アジャイルソフトウェアプラクティスを使用するチームは、決してモデルを作成しません。#

アジャイルソフトウェアプラクティスを使用するチームは、決してモデルを作成しません。

いいえ、アジャイル開発はプロトタイプを設計しないことを意味しません。

40. 分析パターンは、一般的な問題に対する信頼できる解決策を提案することによって、分析モデルを設計モデルに変換するのを助けます。#

分析パターンは、一般的な問題に対する信頼できる解決策を提案することによって、分析モデルを設計モデルに変換するのを助けます。

はい

41. 開発者と顧客は、異なるクラスの最終ユーザーが機能をどのように使用するかを理解するのを助けるためにユースケースを作成します。#

開発者と顧客は、異なるクラスの最終ユーザーが機能をどのように使用するかを理解するのを助けるためにユースケースを作成します。

はい

42. 利害関係者とは、開発中の完成したソフトウェアシステムを購入する人のことです。#

利害関係者とは、開発中の完成したソフトウェアシステムを購入する人のことです。

いいえ、利害関係者はソフトウェアプロジェクトに利害関係を持つ人々であり、システムの影響を受けるか、システム開発に影響を与える人々です。

43. ユースケースのアクターは常に人間であり、決してシステムデバイスではありません。#

ユースケースのアクターは常に人間であり、決してシステムデバイスではありません。

いいえ、システムや時間なども含まれます。

44. 多くの場合、使用シナリオのグラフィカルな表現を作成する必要はありません。#

多くの場合、使用シナリオのグラフィカルな表現を作成する必要はありません。

はい

45. 異なる顧客が相互に矛盾する要求を提案することは比較的一般的であり、各顧客は自分のバージョンが正しいと主張します。#

異なる顧客が相互に矛盾する要求を提案することは比較的一般的であり、各顧客は自分のバージョンが正しいと主張します。

はい

46. 情報隠蔽は、プログラムの未影響部分からデータと手続きを隠すことによって、プログラムの保守を容易にします。#

情報隠蔽は、プログラムの未影響部分からデータと手続きを隠すことによって、プログラムの保守を容易にします。

はい

三、短答問題#

47. コンピュータソフトウェアが時間とともに進化する必要がないという考え方の何が間違っているか説明してください。#

コンピュータソフトウェアが時間とともに進化する必要がないという考え方の何が間違っているか説明してください。

時間が経つにつれて、新しいエラーを発見し修正するためにソフトウェアを更新する必要があります。計算環境の変化に適応するためにも、顧客が既存の製品に新機能を追加したり、ビジネス環境の変更に適応するように要求することがあります。時には、古いシステムを再設計して、現代の環境でユーザーに利益を提供する必要があります。進化しないソフトウェアは最終的に使用できなくなります。

48. なぜ増分プロセスモデルが現代の文脈でソフトウェア開発の最良のアプローチと見なされるのか?#

なぜ増分プロセスモデルが現代の文脈でソフトウェア開発の最良のアプローチと見なされるのか?

増分モデルは、ソフトウェア開発プロセスにおいて、主要機能モジュールを先に開発し、次に副次的な機能モジュールを開発し、段階的に完成させて、最終的に要求に合ったソフトウェア製品を開発することを指します。現代のソフトウェアは小さくて全体的であり、開発プロセス中にユーザーの要求がより複雑になるため、増分的な進化を提供する方法が必要であり、このプロセスはより多くの不確実性を受け入れます。

49. ソフトウェア開発のプロトタイプモデルの各段階を説明してください。#

ソフトウェア開発のプロトタイプモデルの各段階を説明してください。

画像の説明を追加してください

まず、顧客と開発者の会議で彼らの要求と目標を特定するためにコミュニケーションを取る必要があります。次に、迅速な設計段階に進み、より代表的な機能に焦点を当て、顧客に有形の設計プロトタイプを提供します。プロトタイプが現れた後、顧客と開発者が反復的に改善し、完全な新システムを構築します。

50. 螺旋モデルなどの進化的プロセスモデルにおけるリスク分析の役割を説明してください。#

螺旋モデルなどの進化的プロセスモデルにおけるリスク分析の役割を説明してください。

螺旋モデルはリスク分析を強調しており、多くの不確実性が存在するため、ソフトウェア開発の失敗リスクは客観的に存在します。各反復時にリスク分析を実施し、技術的および管理的に評価して、必要な機能と時間、コストが受け入れ可能かどうかを確認します。

51. 要求工学の 7 つのステップは何ですか?#

要求工学の 7 つのステップは何ですか?

勘誤:要求工学の 7 つのステップは以下の通りです。

①開始:解決すべき問題の範囲と性質を定義する

②取得:利害関係者が何を必要としているかを定義するのを助ける

③詳細化:基本的な要求を正確に定義し、修正する

④交渉:対立を調整し、優先順位をどのように定義するかを交渉する。何が必要か?いつ必要か?

⑤仕様書:書かれた文書 / 一連のグラフィカルモデル / 形式的な数学モデルなどである可能性があります。

⑥確認:要求工学の作業製品の品質を評価し、すべてのシステムを完全かつ明確に説明していることを確認します。

⑦管理:要求の変更を管理し、各提案された変更を評価します。

52. 要求工学プロセスの一部としてのユースケースの欠点を説明してください。#

要求工学プロセスの一部としてのユースケースの欠点を説明してください。

①オブジェクト指向ではなく、能動的な適用の役割がない

②2 つのユースケース間の関係が厳密に定義されていない

③システム内の流れや依存関係を示さず、操作の順序を表示しない

53. 白箱テストと黒箱テストの技術を説明してください。#

白箱テストと黒箱テストの技術を説明してください。

白箱テストは、製品内部の作業プロセスを知っているテストであり、システム内部のプロセスと論理構造が正常に実行されているかを検査し、プログラムの実際の動作状態が期待される状態と一致しているかを確認します。

黒箱テストは、製品内部の作業プロセスを知らないものであり、プログラムの機能がその機能説明に合致しているかを検査します。

読み込み中...
文章は、創作者によって署名され、ブロックチェーンに安全に保存されています。