markdown
ソフトウェア工学の基本md 2ebcef9
lecture/information/software-engineering/software-engineering-basics.lecture.n.md
Download PDF

ソフトウェア工学こうがくの基本きほん

date2026-07-14document_iddoc_ec524c19bcca1707ba56c325ebfdbfdbdescription要求、設計、テスト、版管理、運用、保守の関係からソフトウェア工学の基礎を説明する。prerequisitesプログラミング基礎 / 計算機システムの基本 / データベースとSQLの基本type講義statusactiverelateddata/lecture/information/software-engineering/software-engineering-portal.lecture.n.md / data/lecture/information/database/sql-basics.lecture.n.md / data/lecture/information/communications/communications-engineering-portal.lecture.n.md
informationsoftware-engineeringundergraduatelecture
data/lecture/information/software-engineering/software-engineering-portal.lecture.n.md

1導入どうにゅう

この講義こうぎでは、要求ようきゅうから運用うんようと保守ほしゅまでのライフサイクルを通つうじて、ソフトウェアの品質ひんしつと変更可能性へんこうかのうせいを管理かんりする方法ほうほうを説明せつめいする。

プログラムが計算結果けいさんけっかを返かえすことは、ソフトウェアの品質ひんしつの一部いちぶにすぎない。利用者りようしゃの要求ようきゅうとの一致いっち、障害時しょうがいじの信頼性しんらいせい、攻撃こうげきに対たいするセキュリティ、変更へんこうのしやすさなども評価ひょうかする必要ひつようがある。ソフトウェア工学こうがくは、これらを個別こべつの工夫くふうではなく、体系的たいけいてきな開発かいはつ・運用活動うんようかつどうとして扱あつかう。

2要求ようきゅうと受入条件うけいれじょうけん

要求ようきゅうRequirement は、システムが提供ていきょうすべき機能きのうまたは満みたすべき制約せいやくである。

  • 機能要求きのうようきゅうFunctional requirement は、システムが実行じっこうすべき処理しょりや提供ていきょうすべき機能きのうを規定きていする。
  • 非機能要求ひきのうようきゅうNon-functional requirement は、性能せいのう、可用性かようせい、セキュリティ、使用性しようせいなど、機能きのうの品質ひんしつや制約せいやくを規定きていする。

要求ようきゅうを「高速こうそくである」のような曖昧あいまいな表現ひょうげんだけで記述きじゅつすると、実装じっそうの完了かんりょうを判定はんていできない。受入条件うけいれじょうけんAcceptance criterion は、要求ようきゅうが満みたされたと判断はんだんするための観測可能かんそくかのうな条件じょうけんである。たとえば「同時どうじに1000件けんの要求ようきゅうを処理しょりしたとき、95%の応答おうとうを200 ms以内いないに返かえす」と記述きじゅつすれば、性能せいのうを測定そくていできる。

3設計せっけいと変更へんこうの局所化きょくしょか

設計せっけいDesign は、要求ようきゅうを実現じつげんするために、システムの構成要素こうせいようそ、責務せきむ、および構成要素間こうせいようそかんの関係かんけいを定さだめる活動かつどうである。設計せっけいの目的もくてきは、単たんにファイルやクラスを分割ぶんかつすることではない。一ひとつの変更理由へんこうりゆうが多数たすうの構成要素こうせいようそへ波及はきゅうしないように、責務せきむを配置はいちする。

凝集度ぎょうしゅうどCohesion は、一ひとつの構成要素こうせいようそに属ぞくする責務せきむがどの程度ていどまとまっているかを表あらわす。結合度けつごうどCoupling は、構成要素間こうせいようそかんの依存いぞんの強つよさを表あらわす。一般いっぱんに、関連かんれんする責務せきむを高たかい凝集度ぎょうしゅうどでまとめ、構成要素間こうせいようそかんの結合度けつごうどを必要最小限ひつようさいしょうげんにすると、変更へんこうの影響えいきょうを局所化きょくしょかしやすい。ただし、分割ぶんかつを過度かどに進すすめると、インターフェースと通信つうしんの複雑性ふくざつせいが増加ぞうかする。

インターフェースInterface は、構成要素こうせいようそが外部がいぶへ公開こうかいする操作そうさと情報じょうほうの境界きょうかいである。入力にゅうりょくの前提条件ぜんていじょうけん、出力しゅつりょくの保証ほしょう、失敗時しっぱいじの応答おうとうを明示めいじすると、内部実装ないぶじっそうを変更へんこうしても利用側りようがわへの影響えいきょうを抑制よくせいできる。

4テストと検証けんしょうの水準すいじゅん

テストTest は、入力にゅうりょくと実行条件じっこうじょうけんを設定せっていし、観測結果かんそくけっかを期待結果きたいけっかと比較ひかくして欠陥けっかんを検出けんしゅつする活動かつどうである。テストが成功せいこうしても、未実行みじっこうの入力にゅうりょくや状態じょうたいに欠陥けっかんがないことまでは証明しょうめいできない。このため、要求ようきゅうとリスクに応おうじて試験範囲しけんはんいを設計せっけいする。

  • 単体たんたいテストUnit test は、関数かんすうやモジュールなどの小ちいさな単位たんいを検証けんしょうする。
  • 結合けつごうテストIntegration test は、データベース、ネットワーク、モジュールなどの境界きょうかいを介かいした連携れんけいを検証けんしょうする。
  • システムテストは、統合とうごうされたシステムがシステム要求ようきゅうを満みたすかを検証けんしょうする。
  • 受入うけいれテストAcceptance test は、利用者りようしゃや発注者はっちゅうしゃの観点かんてんから受入条件うけいれじょうけんを評価ひょうかする。

修正しゅうせいによって既存機能きそんきのうが損そこなわれることを回帰かいきRegressionという。自動化じどうかされた回帰かいきテストを変更へんこうごとに実行じっこうすると、既知きちの振ふる舞まいが維持いじされているかを継続的けいぞくてきに確認かくにんできる。

5変更管理へんこうかんり・運用うんよう・保守ほしゅ

版管理はんかんりVersion control は、ソースコード、設定せってい、ドキュメントなどの変更履歴へんこうりれきを識別可能しきべつかのうな版はんとして記録きろくする。継続的けいぞくてきインテグレーションContinuous integrationは、開発者かいはつしゃが変更へんこうを共有きょうゆうされた主系列しゅけいれつへ頻繁ひんぱんに統合とうごうし、そのたびに自動じどうビルドとテストの結果けっかを得える実践じっせんである。これにより、複数ふくすうの変更へんこうの不整合ふせいごうを早期そうきに検出けんしゅつできる。レビューは変更内容へんこうないようを検討けんとうする補完的ほかんてきな活動かつどうである。

運用うんようOperation は、配備はいびしたシステムを利用可能りようかのうな状態じょうたいに維持いじする活動かつどうである。構成こうせいを管理かんりし、稼働状態かどうじょうたいを監視かんしし、障害しょうがいやセキュリティインシデントへ対応たいおうする。監視結果かんしけっかとインシデントの記録きろくは、新あらたな要求ようきゅうや保守ほしゅの優先順位ゆうせんじゅんいへ反映はんえいする。

保守ほしゅMaintenance は、運用開始後うんようかいしごにソフトウェアを修正しゅうせいし、環境かんきょうへ適応てきおうさせ、または品質ひんしつを改善かいぜんする活動かつどうである。障害しょうがいの修正しゅうせいだけでなく、新あたらしい要求ようきゅう、依存技術いぞんぎじゅつの更新こうしん、性能改善せいのうかいぜん、セキュリティの強化きょうかも含ふくむ。

短期的たんきてきな納期のうきを優先ゆうせんして設計上せっけいじょうの問題もんだいを残のこすと、将来しょうらいの変更費用へんこうひようが増加ぞうかすることがある。この将来費用しょうらいひようを技術的負債ぎじゅつてきふさいTechnical debtとして捉とらえる。技術的負債ぎじゅつてきふさいは比喩ひゆであり、すべての未改善箇所みかいぜんかしょを直ただちに解消かいしょうすべきことを意味いみしない。影響えいきょうと費用ひようを評価ひょうかして返済へんさいの優先順位ゆうせんじゅんいを定さだめる。

6品質特性ひんしつとくせいとトレードオフ

品質ひんしつには、機能適合性きのうてきごうせい、信頼性しんらいせい、性能効率性せいのうこうりつせい、使用性しようせい、セキュリティ、保守性ほしゅせいなどの複数ふくすうの特性とくせいがある。すべての特性とくせいを無制限むせいげんに最大化さいだいかすることはできない。たとえば、冗長化じょうちょうかは可用性かようせいを高たかめる一方いっぽうで、構成こうせいと運用うんようを複雑ふくざつにする。要求ようきゅう、リスク、費用ひようを明示めいじし、トレードオフを合意ごういすることが設計判断せっけいはんだんとなる。

7具体例ぐたいれい:データベースを利用りようする履修登録りしゅうとうろくシステム

履修登録りしゅうとうろくシステムでは、「学生がくせいが科目かもくを登録とうろくできる」が機能要求きのうようきゅうとなる。「定員ていいんを超こえる登録とうろくを許可きょかしない」「二重登録にじゅうとうろくを防止ぼうしする」は、受入条件うけいれじょうけんとして検証けんしょうできる。設計せっけいでは、画面がめん、登録規則とうろくきそく、SQL による永続化えいぞくかを異ことなる責務せきむとして分離ぶんりする。

単体たんたいテストは登録規則とうろくきそくを、結合けつごうテストはアプリケーションとデータベースのトランザクションを、受入うけいれテストは利用者りようしゃの操作手順そうさてじゅんを検証けんしょうする。要件変更ようけんへんこうによって抽選方式ちゅうせんほうしきを導入どうにゅうするとき、責務せきむの分離ぶんりと回帰かいきテストが変更へんこうの影響範囲えいきょうはんいを明確めいかくにする。

8要点ようてん

  • 要求ようきゅうと受入条件うけいれじょうけんは、実装じっそうとテストの共通基準きょうつうきじゅんとなる。
  • 設計せっけいは責務せきむとインターフェースを定さだめ、変更へんこうの影響えいきょうを局所化きょくしょかする。
  • テストは欠陥けっかんを検出けんしゅつするが、欠陥けっかんが存在そんざいしないことの一般的いっぱんてきな証明しょうめいではない。
  • 版管理はんかんり、レビュー、継続的けいぞくてきインテグレーションは、変更へんこうを追跡ついせきし、統合時とうごうじの問題もんだいを早期そうきに検出けんしゅつする。
  • 品質特性間ひんしつとくせいかんのトレードオフは、要求ようきゅう、リスク、費用ひように基もとづいて判断はんだんする。

9次つぎに進すすむ講義こうぎ

ソフトウェアを複数ふくすうの機器ききや拠点きょてんにまたがるシステムとして構成こうせいするには、情報じょうほうを信号しんごうとして伝送でんそうする仕組しくみも必要ひつようとなる。次つぎのポータルでは、通信つうしんを支ささえる信号しんごう、雑音ざつおん、変調へんちょうなどを扱あつかう。

data/lecture/information/communications/communications-engineering-portal.lecture.n.md
raw .n.md をコピー
loc をコピー (filepath:line ~ line)
copy share link
copy encoded share link
path をコピー
copy share link
copy encoded share link
copy share link
copy encoded share link
タブを全て閉じる