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

date2026-07-14document_iddoc_ec524c19bcca1707ba56c325ebfdbfdbdescription要求、設計、テスト、版管理、運用、保守の関係からソフトウェア工学の基礎を説明する。prerequisitesプログラミング基礎 / 計算機システムの基本 / データベースとSQLの基本type講義statusactive

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

Software Engineering Fundamentals

data/lecture/information/software-engineering/software-engineering-portal.lecture.n.md

1Introduction

This lecture explains how to manage software quality and changeability throughout the lifecycle from requirements to operation and maintenance.

Producing a computed result is only one aspect of software quality. A system must also be evaluated for conformance to user requirements, reliability under failure, security against attacks, and ease of change. Software engineering treats these concerns through systematic development and operational activities rather than as isolated implementation techniques.

2Requirements and Acceptance Criteria

A requirementRequirement is a capability that a system must provide or a constraint that it must satisfy.

A functional requirementFunctional requirement specifies behavior or functionality that the system must provide.
A non-functional requirementNon-functional requirement specifies quality or constraints such as performance, availability, security, and usability.

An ambiguous statement such as “the system must be fast” does not determine when implementation is complete. An acceptance criterionAcceptance criterion is an observable condition for deciding whether a requirement has been satisfied. For example, “when processing 1,000 concurrent requests, return 95 percent of responses within 200 ms” makes performance measurable.

3Design and Localization of Change

DesignDesign is the activity of defining a system's components, their responsibilities, and their relationships in order to realize requirements. Its purpose is not merely to divide code into files or classes. Responsibilities should be arranged so that one reason for change does not propagate through many components.

CohesionCohesion describes how closely the responsibilities within one component belong together. CouplingCoupling describes the strength of dependencies between components. In general, grouping related responsibilities with high cohesion and limiting coupling helps localize change. Excessive decomposition, however, increases the complexity of interfaces and communication.

An interfaceInterface is the boundary of operations and information that a component exposes. Stating input preconditions, output guarantees, and failure behavior limits the effect on clients when an internal implementation changes.

4Testing and Levels of Verification

TestingTest is the activity of configuring inputs and execution conditions and comparing observed results with expected results to detect defects. A successful test does not prove that no defect exists for unexecuted inputs or states. Test coverage must therefore be designed according to requirements and risk.

A unit testUnit test verifies a small unit such as a function or module.
An integration testIntegration test verifies interaction across boundaries such as modules, databases, or networks.
A system test verifies the integrated system against system requirements.
An acceptance testAcceptance test evaluates acceptance criteria from the perspective of a user or customer.

A change that damages existing behavior causes a regressionRegression. Running automated regression tests after each change continuously checks whether established behavior remains intact.

5Change Management, Operation, and Maintenance

Version controlVersion control records the history of source code, configuration, and documentation as identifiable versions. Continuous integrationContinuous integration is the practice of frequently integrating changes into a shared mainline and obtaining automated build and test feedback for each integration. It detects inconsistencies among changes early. Review is a complementary activity that examines the content of a change.

OperationOperation is the activity of keeping a deployed system available for use. It includes managing configuration, monitoring operational state, and responding to failures and security incidents. Monitoring results and incident records inform new requirements and maintenance priorities.

MaintenanceMaintenance is the activity of correcting software, adapting it to its environment, or improving its quality after deployment. It includes not only defect correction but also new requirements, dependency updates, performance improvement, and security strengthening.

Prioritizing a short-term deadline can leave design problems that increase the cost of future change. This future cost can be described as technical debtTechnical debt. Technical debt is a metaphor; it does not imply that every imperfection must be removed immediately. Teams evaluate impact and cost to prioritize repayment.

6Quality Attributes and Trade-offs

Quality comprises multiple attributes, including functional suitability, reliability, performance efficiency, usability, security, and maintainability. These attributes cannot all be maximized without limit. Redundancy, for example, can improve availability while making configuration and operation more complex. A design decision makes the relevant requirements, risks, and costs explicit and establishes an agreed trade-off.

7Example: A Database-Backed Course Registration System

In a course registration system, “a student can register for a course” is a functional requirement. “Do not permit registration beyond capacity” and “prevent duplicate registration” can be verified as acceptance criteria. The design separates the user interface, registration rules, and SQL-based persistence as distinct responsibilities.

Unit tests verify registration rules, integration tests verify transactions between the application and database, and acceptance tests verify the user's workflow. When a requirement change introduces a lottery, separated responsibilities and regression tests clarify the affected scope.

8Key Points

Requirements and acceptance criteria provide a shared basis for implementation and testing.
Design defines responsibilities and interfaces to localize the effects of change.
Testing detects defects but does not generally prove their absence.
Version control, review, and continuous integration track change and detect integration problems early.
Trade-offs among quality attributes are decided according to requirements, risks, and costs.

9Next Lecture

Systems spanning multiple devices or sites also require mechanisms that transmit information as signals. The next portal addresses signals, noise, modulation, and other foundations of communication.

data/lecture/information/communications/communications-engineering-portal.lecture.n.md