シラバス詳細

区分

環境情報科目

ディプロマ・ポリシーとの関係

環境データ処理ソリューション開発・エシカルテクノロジー
サステナブル・エンジニアリング

カリキュラム・ポリシーとの関係

教養応用力実践力
科目間連携

カリキュラム全体の中でのこの科目の位置づけ

環境情報学科のカリキュラムにおいては、プログラミング、Web技術、データベース、ソフトウェア工学が４本の柱となっている。この中のソフトウェア工学については、サステナブル・ソフトウェア概論（本講義）、サステナブル・ソフトウェアⅠ（ソフトウェア品質）（２年前期）、サステナブル・ソフトウェアⅡ（オブジェクト指向設計）（２年後期）、サステナブル・ソフトウェアⅢ（アーキテクチャパターン）（３年前期）、サステナブル・ソフトウェアⅣ（開発プロセス方法論）（３年後期）の５科目において、教育を行うこととなる。本講義は、この講義に続く４科目に続くように、ソフトウェア工学全体を概観する。

科目の目的

本学科では、我が国におけるいわゆるIT系の学部／学科の中で、最もソフトウェア工学に関する教育を重視している。これは、１年後期から３年後期まで、５学期連続で続く、サステナブル・ソフトウェアではじまる講義として実現されており、総単位数１８単位となっている。本講義は、これらの中の最初の講義であり、サステナブル・ソフトウェアという名称で表されているソフトウェア工学科目全体の概観を与えるとともに、ソフトウェア工学全体の概観を与えることを目的とする。

到達目標

ソフトウェア工学を含めたソフトウェア関連の講義においては、単に講義の理論的な内容を理解するだけでなく、それらを実際のソフトウェア開発に活かすことができなければならない。本講義でも、概要についての説明を行うが、それだけでなく、概要内の各項目に対して、小さな例となってしまうことが多いものの演習を行うようにする。従って、本講義の到達目標は、ソフトウェア工学に関する一通りの知識を得るだけでなく、その内容を例題に適用して、どのような成果が得られるのかについて体感することの双方を到達目標とする。

科目の概要

本科目は、以下の構成となっている。
（１）１コマ目～４コマ目：ソフトウェア工学全体において、重要な内容についての解説を行う。具体的には、ソフトウェア工学の基礎、ソフトウェアの品質とその測定法、ソフトウェア開発プロセス、ソフトウェア開発の二大潮流からなる。
（２）５コマ目～１３コマ目：ウォーターフォール型のソフトウェア開発プロセス（３コマ目で解説）に沿って、その各工程について、順を追って解説していく。その内容は、企画とドメイン分析、要求分析、設計、実装、テスト、保守から構成されている。
（３）１４コマ目～１５コマ目：本講義のまとめとして、プロジェクト管理およびこの講義に続く４科目の内容について概説する。

科目のキーワード

サステナブル・ソフトウェア、ソフトウェア工学、ソフトウェア開発・保守ライフサイクル、ソフトウェアの品質特性、ソフトウェア・メトリクス、ウォーターフォール型、プロトタイピング型、アジャイル型、スパイラル型、イテレーション型、ソフトウェア開発企画、As-IsとTo-Do、ドメイン分析、要求獲得、要求分析、要求仕様、アーキテクチャ設計、デザインパターン、クリーンコード、バージョン管理、単体テスト、結合テスト、システムテスト、ホワイトボックステスト、ブラックボックステスト、テスト駆動、自動テスト、修正保守、完全化保守、リファクタリング、チーム開発

授業の展開方法

本科目では週に1回、2コマの授業として実施される。1コマ90分の中で解説と演習を交互に織り交ぜながら、ソフトウェア工学に関する概念的な理解と具体的なソフトウェア開発技法を学び、自ら手を動かすことにより、ソフトウェア工学の基本的な理解を目指す。自らが手を動かして作業をすることが非常に重要であるため、学生各自にノートパソコンの持参をしてもらった上での参加を求める。
毎回、授業冒頭でその日の講義内容に関して必要な知識などの解説を掲載したテキストを配布し、そのテキストに沿って説明を行い、その結果を学生各自が実機で演習するという思考錯誤を行ってもらう。なお、授業１コマの基本構成は、授業の最初に復習を5～7分行い、その後、各コマ主題細目について15～20分の講義を約1時間行う。その後、10～15分の小テストを行い、最後に予復習の説明を5分程度行って授業を終わる。
授業終了後は、次回授業までに復習を行っておくことが求められる。授業後演習課題を実施すること、演習内容や小テストの解答解説の見直しを行うことだけでなく、ChatGPTを活用し、テキストの内容を読みこませて20問程度の練習問題を作成し、自分で解いて理解を深める。さらに、その解答・解説を確認することで、より確実に知識を定着させる。

オフィス・アワー

深澤良彰：【前期】月曜4限、火曜4限、水曜4限、木曜2限
【後期】
サスティナブルソフトウェア概論
サステナブル・ソフトウェア論Ⅱ（オブジェクト指向設計）
環境プログラミングⅡ
全科目：月曜4限、火曜4限、水曜4限、木曜4限
山浦恒央：【前期】
サステナブル・ソフトウェア論Ⅰ（ソフトウェア品質）木曜5限
環境プログラミングⅢ（標準API）月曜4限、水曜4限
【後期】木曜5限

科目コード

UC2040

学年・期

1年・後期

科目名

サステナブル・ソフトウェア概論

単位数

授業形態

演習

必修・選択

必修

学習時間

【授業】90分×15　【予習】90分以上×15　【復習】90分以上×15

前提とする科目

展開科目

関連資格

担当教員名

深澤良彰・山浦恒央

回	主題	コマシラバス項目	内容
1	ソフトウェア工学の基礎	科目の中での位置付け	本学科では、「サステナブル・ソフトウェア」で始まる科目が、５科目置かれている。これらの科目群の位置づけについて、まず述べる。続いて、これらの科目群の中で、本サステナブル・ソフトウェア概論の概要について述べることにより、サステナブル・ソフトウェア（ソフトウェア工学）についての導入を行う。
		コマ主題細目	① ソフトウェア開発の現状 ② サステナブル・ソフトウェアとは／ソフトウェア工学とは何か ③ ソフトウェア・エンジニアリング知識体系SWEBOK
		細目レベル	① 環境プログラミングⅠにおいては、数十行～20０行程度の行数のプログラムを作成してきた。しかし、世の中では、このような行数のプログラムが要求されることはない。また、環境プログラミングⅠでは、各人でプログラミングを行った。しかし、IT業界に就職すると、一人でプログラムを開発することはない。数十人から、場合によっては、数百人で一つのソフトウェアを開発することも珍しいことではない。本講義を始めるにあたって、まず、ソフトウェア開発の現状について述べる。基本的なデータは、日本情報システム・ユーザー協会（JUAS）が毎年実施している「企業IT動向調査報告書」に基づいて行う。
			② 本学科におけるソフトウェア工学関係科目は、サステナブル・ソフトウェアとして扱われている。サステナブルとは何を意味するのか、具体的には、サステナブルにソフトウェアを開発するのか、サステナブルなソフトウェアを開発するのかなど、サステナビリティに関する理解ができるようにする。それに続いて、本講義では、ソフトウェア工学について述べることを説明した後に、ソフトウェア工学とは何かについて述べる。ソフトウェア工学の定義には、さまざまなものが提案されている。IEEEの IEEE Std 610-1990 によると、ソフトウェア工学とは、ソフトウェアの開発、運用、保守に対する、系統的で統制され、定量化可能な方法論を適用すること、およびその研究を指し、品質の高いソフトウェアを効率的かつ期限内に開発し、保守するために不可欠な学問分野となっている。本講義では、幅広く「信頼性が高い大規模なソフトウェアを容易に開発するための方法論およびツール」という定義をする。この定義で使用されている「信頼性」には、第２回目の講義で、ソフトウェアの品質の一種であることの理解へと進む。次に、ソフトウェア工学が対象とする「大規模なソフトウェア」の定義を行い、環境プログラミングの授業で学んでいる内容との差分を明らかにする。また、「ソフトウェア」と「プログラム」との使い分けについても定義する。
			③ 業務の生産性を上げるためには、『標準化』を進めることが重要です。SWEBOK（Software Engineering Body of Knowledge、ソフトウェア・エンジニアリング知識体系）は、その名の通りソフトウェア・エンジニアリングの標準的な知識の集積です。現時点での最新版は、2024年10月15日に正式リリースされたSWEBOK 4.0版（［＊１］参照）です。SWEBOK プロジェクトは、1998年にプロジェクトが開始し、SWEBOK 4.0版は約10年ぶりの改訂でした。以下は、その概要です。すべてを覚える必要はありません。ソフトウェア工学の全体像の広がりと、この授業で触れる内容について、概観していただければ十分です。 SWEBOKは、第１部開発プロセスの核となる知識領域（第1章〜第7章）、第２部システム管理とプロセスの知識領域（第8章〜第12章）、第３部セキュリティとプロフェッショナリズム（第13章〜第15章）、基礎知識領域（第16章〜第18章）の４部、1８章から構成されています。第１部開発プロセスの核となる知識領域第1章：ソフトウェア要求（Software Requirements）【講義第５、６回】第2章：ソフトウェアアーキテクチャ（ＳｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅ）【講義第７回】第3章：ソフトウェア設計（Software Design）【講義第８回】第4章：ソフトウェア構築（Software Construction）【講義第９回】第5章：ソフトウェアテスティング（Software Testing）【講義第10、11、12回】第6章：ソフトウェア・エンジニアリング運用（Software Engineering Operations）第7章：ソフトウェア保守（Software Maintenance）【講義第１３回】、　第２部システム管理とプロセスの知識領域（第8章〜第12章）第8章：ソフトウェア構成管理（Software Configuration Management）第9章：ソフトウェア・エンジニアリング管理（Software Engineering Management）【講義第14回】第10章：ソフトウェア・エンジニアリングプロセス（Software Engineering Process）【講義第３回】第11章：ソフトウェア・エンジニアリングモデルと手法（Software Engineering Models and Methods）【講義第４回】第12章：ソフトウェア品質（Software Quality）【講義第２回】第３部セキュリティとプロフェッショナリズム（第13章〜第15章）第13章：ソフトウェアセキュリティ（Software Security）第14章：ソフトウェア・エンジニアリング専門職実践（Software Engineering Professional Practice）第15章：ソフトウェア・エンジニアリング経済学（Software Engineering Economics）　　第４部基礎知識領域（第16章〜第18章）第16章：計算基礎（Computing Foundations）第17章：数学基礎（Mathematical Foundations）第18章：エンジニアリング基礎（Engineering Foundations）
		キーワード	① ソフトウェア工学 ② 品質特性 ③ 大規模ソフトウェア ④ 方法論 ⑤ SWEBOK
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習今回の授業は、サステナブル・ソフトウェア概論と名付けられた概論科目の中の更なる概論です。サステナブル・ソフトウェアではじまる科目群、ならびに、このサステナブル・ソフトウェア概論双方について、広い視野を持ち、学んでいくものを、その視野の中にきちんと位置付けるようにしましょう。 ◆次回授業の予習今回の授業では、「高品質な」ソフトウェアを開発することがソフトウェア工学の目的であることについて述べました。これまで、環境プログラミングⅠでプログラミングについて学んできましたが、その中で、プログラムの品質を向上させるための手法がいくつかありました。どんなものがあったか復習してみましょう。
2	ソフトウェアの品質とその測定法	科目の中での位置付け	ソフトウェアは、そのソフトウェアがどのような分野で使用されるのかによって必要とされる品質が異なる。同じ航空機でも戦闘機と旅客機では必要とされる品質が異なるのと同じである。あるソフトウェアが、どのような性質をもつのかをソフトウェアの品質特性と呼ぶ。さまざまな品質特定が提案／実用化されているが、本講義では、国際標準化機構（International Organization for Standardization：ISO）／日本産業規格（Japanese Industrial Standards：JIS）で定義されている品質特性について述べるので、その内容について理解する。続いて、その品質特性をについて、何を計測すべきかについて述べる。この計測するものをメトリクス（Metrics）と呼ぶ、距離を測るメーターと同じ起源をもつ用語である。もっとも簡単なメトリクスは、ソフトウェアの行数である。どのようなメトリクスが提案されており、どのような長所／短所があるのかを理解する。
		コマ主題細目	① ソフトウェアの品質特性の構成要素 ② ソフトウェア・メトリクス
		細目レベル	① ソフトウェア品質特性とは何であり、そのための規格としてどんなものがあるのかについて、まず理解する、そして、これらから、ソフトウェア品質特性を活用する二つのメリット（ソフトウェア品質を可視化できる、テスト設計の漏れを減らせる）に繋がることを実感する。講義の中では、ソフトウェア品質特性・品質副特性の一例としてISO/IEC 25010（日本語版：JIS X 25010）について述べる。この標準は、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の８種類の品質特性から構成されている。これらを意識することによって、ソフトウェアの品質を向上させよう。
		細目レベル	② ソフトウェア・メトリクス（software metrics）とは、ソフトウェアの品質を数値として可視化し、定量的な評価を可能にする尺度や、その測定方法のことである。metricsは「尺度」や「評価基準」といった意味合いで使われる。たとえば「バグ密度（欠陥密度）」は、メトリクスの代表的な例であり、「バグ数÷規模」という計算式によって算出され、「ソフトウェアの規模に対するバグの混入量」を表す。この数値により、ソフトウェアの大小を問わず、定量的にバグの量を評価できる。　　メトリクスは、特定の時点のデータではなく一定時間内に収集された測定値の集合体である。平均値や最大値などさまざまな集計操作を用いて分析可能なため、大規模データや長期のデータから有用な情報を抽出できる。また、メトリクスは一つ以上の属性を含むので、これらの属性に基づいた多角的な分析ができることも特徴の一つである。　　ソフトウェアの開発・運用で活用されるメトリクスには、大きく分けて「リソース状況を表すもの」と「サービスの提供状況を表すもの」の2種類がある。リソース状況を表すメトリクスとは、システムやアプリケーションを構成するリソースの使用状況や健全性を定量的に示す数値データのことである。具体的には、CPU使用率やメモリ使用率、ストレージ使用率などが挙げられる。適切に監視することで、リソース不足や過剰利用などの問題を早期に発見し、システムの安定運用と効率的なリソース管理が可能になる。従来のシステム監視では、CPUやメモリの使用率が一定のしきい値を超えた場合にアラートを出し、エンジニアが対応するのが一般的であった。しかし、最近ではクラウド環境の普及により、システムが複雑化しているため、単純なインフラ中心のリソース監視だけでは適切な対応が難しくなっている。システムのリソース使用率が高まってもサービスの品質が許容範囲内であれば、対応不要なケースも少なくない。そのため、リソース状況を表すメトリクスを活用する際には、サービス全体のパフォーマンスへの影響も併せて確認することが重要である。一方、サービスの提供状況を表すメトリクスは、サービスの品質や信頼性を定量的に評価するために使用される。代表的なメトリクスは、レイテンシー（応答時間）、トランザクション量、エラー発生率などがある。これらのメトリクスは、ユーザーの使用感に直結する数値である。機能としていかに優れたサービスであっても、反応が遅かったり、頻繁にエラーを起こしたりすれば、ユーザー体験（ＵｓｅｒＥｘｐｅｒｉｅｎｃｅｓ：ＵＸ）に悪影響を及ぼし、ユーザー離れにつながりかねません。そのため、これらのメトリクスを常に監視し、適切な水準を維持するための対策を講じる必要がある。システムのボトルネックを特定したり、パフォーマンスを最適化したりすることで、ユーザーが求めるレスポンスと安全性を実現することが重要である。　　しかし、システム開発・運用において、メトリクス単体での分析や監視には限界がある。たとえば、メトリクスは、トラブル発生の兆候を検知することはできても、トラブルの根本原因を詳細に分析し、具体的な対応策を導き出すことには限界がある。従来のモノリシックなシステムでは、メトリクスをもとにエンジニアの経験と知見を活用してトラブル対応を行うことが可能であった。しかし、ある大きなアプリケーションを機能ごとに複数の小さな独立したサービスに分割して構築するマイクロサービスや外部APIとの連携が一般的となった現代のソフトウェア環境では、CPU使用率が正常でもパフォーマンスが低下するケースや、CPU使用率が高くても適切な負荷分散により問題が発生しないケースもあり、従来の単純な指標だけでは判断が難しい状況が増えている。このような複雑化したシステム環境下では、メトリクス単体での分析には限界があり、他のツールやデータと組み合わせた総合的なアプローチが必要不可欠となってくる。講義の中では、どのようなメトリクスが提案されており、何を計測するのに役立つのかについて述べる。
		キーワード	① ソフトウェア品質特性 ② ISO/IEC 25010 ③ 機能適合性 ④ ソフトウェア・メトリクス ⑤ バグ密度
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習前回の講義において、ソフトウェア工学を「信頼性が高い大規模なソフトウェアを容易に開発するための方法論およびツール」と定義した。この定義は、感覚的には分かりやすいと思いますが、よく考えてみると、いろいろな知識が必要です。この知識を理解してください。 ◆次回授業の予習次回の授業では、ソフトウェア開発プロセスについて扱います。最も広く使われている開発プロセスは、ウォーターフォール型の開発・保守ライフサイクルモデルです、このモデルの詳細に触れるとともに、別なモデルも紹介します。ですので、予習として、まずは、ウォーターフォール型の開発・保守ライフサイクルモデルについて勉強しておきましょう。
3	ソフトウェア開発プロセス	科目の中での位置付け	顧客のニーズや要望に沿ってシステムやアプリケーションを開発し、提供する一連の工程のことをソフトウェア開発プロセスと呼ぶ。これらのなかには従来長く用いられてきた手法もあれば、近年に登場し急速に導入事例を増やしているものもある。そこで、今回の講義では、ソフトウェア開発の現場で用いられている開発プロセスの種類をいくつか挙げ、それらの特徴とメリット・デメリットについて述べる。
		コマ主題細目	① ソフトウェア開発プロセスとは何か ② ウォーターフォール型開発プロセス ③ プロトタイプ型開発プロセス ④ その他の開発プロセス
		細目レベル	① 開発プロセスを定め、プロセスに沿ってソフトウェア開発を行うことには、メンバー間の認識のずれを防ぐ、システム開発の効率化を図る、開発者とユーザーの認識をすり合わせるなどいくつかの目的がある。ソフトウェア開発プロセスは、顧客の要求分析から、設計、開発、テスト、納品、そしてその後の運用・保守に至るまでの一連の工程を体系的に管理する手法と言える。ウォーターフォール（型）モデルのように「要件定義→設計→開発→テスト→納品→保守」と段階的に進める伝統的な手法や、アジャイル開発のように短期間で「計画→設計→実装→テスト」を繰り返す手法などさまざまなものがあります。この講義では、どのような開発プロセスがどのようなソフトウェアの開発に使われているのかについて理解する。
			② さまざまなソフトウェア開発プロセスの中で、現在最も広く利用されているのが、ウォーターフォール型開発である。各工程を順序通り確実に完了させていくため、上流から下流へと水が流れ落ちていくようなイメージでウォーターフォール型開発と名付けられ、古くからある開発プロセスである。ウォーターフォール型開発のメリットは、スケジュールが立てやすく管理もしやすいことである。システムの目的や要件を初期段階に明確にすることで、工程毎の工数を正確に見積もることができる。そこで、稼働開始日の期限や予算が優先される案件に適している。その一方で、開発工程のなかで不具合や問題点が生じた際に、次の工程に進めないというデメリットもある。わずかな手戻りが発生しただけでも、予算や納期に影響を及ぼす可能性があるためである。
			③ アジャイル型の開発プロセスとは、ソフトウェアを小さな機能単位に分解し、「計画→設計→実装→テスト」のサイクル（イテレーション）を短い期間で繰り返し、動くソフトウェアを顧客や関係者に提供しながら開発を進める反復型の開発手法を意味します。近年、特に、先進的なソフトウェア開発企業で、広く使われるようになってきている手法である。
			④ 細目レベル②および③以外にも、スパイラル型（要件定義・設計・開発・テスト・評価を繰り返しプロトタイプ型開発とは、従来のウォーターフォール型開発のデメリットを克服するために、開発中に試作を行ってユーザーに確認を取りながら工程を進めていく開発手法である。開発の早い段階で試作品が完成することと、試作とその承認を何度か経ることで、テストや運用段階での手戻りが発生しにくくなるというメリットがある。その反面、試作を開発するだけでも大きな手間やコストを要する大規模なプロジェクトに不向きである点はデメリットとなる。）やスパイラル型（要件定義・設計・開発・テスト・評価を繰り返し、プロトタイプを段階的に改良しながらシステムを完成させるソフトウェア開発手法）、イテレーション（反復型）開発（ソフトウェアを小さな単位（イテレーション）に分け、その単位ごとに計画、設計、開発、テストといった開発工程を短期間で繰り返し実行するソフトウェア開発プロセス）などがある。しかし、プロセスの詳細によりある開発手法がどのタイプに属するかについては、微妙なことも多い。各々長所・短所があり、向いている・向いていないアプリケーションの種類もあるので、各々について、比較した基準をもってほしい。
		キーワード	① ソフトウェア開発プロセス ② ウォーターフォール型開発プロセス ③ プロトタイプ型開発プロセス ④ アジャイル型開発プロセス ⑤ スパイラル型開発プロセス
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習各開発プロセスモデルの概要について理解し、その利点・欠点を整理しておきましょう。 ◆次回授業の予習今後の授業はウォーターフォール型開発プロセスに従って、説明をしていきます。ですので、ウォーターフォール型の詳細については、予習をしておくと良いと思います。
4	ソフトウェア開発方法論の二大潮流	科目の中での位置付け	大規模ソフトウェアを開発していくためのキーポイントは、その大規模ソフトウェアをいかに小さな要素に分割していくかにある。つまり、うまく分割さえできれば、分割された小さな要素について考えれば良いからである。この考え方を分割統治法と呼ぶ。さらに、うまく分割を行い、モノや概念に抽象化によって名前を与えてやると、明確になっていない事についても語ることができるようになる。この抽象化も、分割統治によるモジュール化と同じように重要である。　　現在使用されているソフトウェア開発技法は、「処理（機能）」の分割に焦点を当てる構造的手法、および、「データ（情報）と振る舞い」を一体化した「オブジェクト」の分割に焦点を当てるオブジェクト指向的手法び大別される。つまり、構造化技法がシステム全体の機能を細かく分割していく、という考え方だったのに対して、システム全体の機能を、オブジェクト間の相互作用で表現する、すなわち「オブジェクトに分割していく」という考え方が、オブジェクト指向と言える。この講義では、この２種類について述べ、その違いについての理解を進めていく。
		コマ主題細目	① モジュール化 ② 抽象化 ③ 構造的手法 ④ オブジェクト指向的手法
		細目レベル	① モジュールとは関数/クラス/サービスなどの何等かの機能のまとまりを指し、大規模なものをモジュールに分けることをモジュール化と呼ぶ。良いモジュール化を行うことにより、複雑性を隠蔽することができる。ソフトウェア（プログラムを含むソフトウェア開発の工程で作成されるさまざまな文書）において、最も重要なことは、読みやすく、拡張しやすいことである。ですよね？　ソフトウェアは、最初は開発されるが、その後は圧倒的に読みものなので、どう読みやすく、つまり理解しやすい状態にしておくかは重要なこととなる。大きなものは切り分け、対象を小さくすることで認知的負荷を下げることができ、これによって理解しやすくなる。
			② ソフトウェア開発においては「明確に決めないままにしておく」、「決めないことで様々なものに適用できる」ということが大切になる場合がある。たとえば、ゲームやスポーツなどでは、さまざまな『作戦』がある。たとえば、野球における「満塁策」とか、サッカーにおける「オフサイドトラップ」とか、将棋における「矢倉囲い」とか、インベーダーゲームにおける「名古屋撃ち」などがその例である。モノや概念に抽象化によって名前を与えてやると、明確になっていないことについても語ることができるようになる。名前をつけることで抽象度を一段階上げ、不要な詳細をそぎ落とした議論が可能になる。しかし、よく言われるように名前を付けるのは計算機科学で最も難しいことの一つである。
			③ 構造的手法とは、物事を論理的・体系的に整理し、全体像を明確にしたり、複雑な問題を解決したりするためのアプローチ全般を指す。構造的とは、「stuructured」の日本語訳であるが、我が国では、誤って、「構造化」（＝構造化されていないものを構造化すること）と呼ばれている。具体的には、ユーザーの要求を機能に分けながら詳細化している構造化要求分析、システム設計で段階的に進める構造化設計、プログラムを整理する構造化プログラミング（structured programming）などが有名である。このような手法の本質を理解することが重要である。
			④ オブジェクト指向的手法とは、データとそのデータを操作する処理をオブジェクトという部品にまとめ、オブジェクト同士のやり取りでシステム全体を構築する開発手法である。現実世界の物事を模倣したクラスを元にオブジェクトを生成し、そのカプセル化、継承、ポリモーフィズム（多態性）といった概念を活用することで、ソフトウェアの再利用性、保守性、拡張性などを向上させることができる。この仕掛けについての理解が重要である。
		キーワード	① 分割統治法 ② モジュール化 ③ 抽象化 ④ 構造的手法 ⑤ オブジェクト指向的手法
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習この授業では、オブジェクト指向的手法を中心に、構造化手法についても触れていくの、両者の違いについて、きちんと復習をしてほしい。 ◆次回授業の予習次回からの授業では、ウォーターフォール型のソフトウェア開発プロセスについて扱います。みなさんは、環境プログラミングⅡで、オブジェクト指向プログラミングを学んでいきますが、どのように考えれば、オブジェクト指向のプログラムが思いつくのかに注意を払いながら勉強をすすめてください。
5	企画とドメイン分析	科目の中での位置付け	ソフトウェア開発の目的は様々であるが、ビジネス上発生していた業務の自動化、効率化、コスト削減、ビジネス上の課題解決、属人化の防止などを目的とすることが一般的である。ソフトウェア企画とは、事業やサービスを提供するために、どのようなソフトウェアが必要か、どのようなソフトウェアがビジネス上の目的を達成し、ニーズを満たすのかを検討し、ソフトウェア開発開始からリリースまでの計画を立てることである。この工程をソフトウェア開発企画と呼ぶ。具体的には、開発するソフトウェアへの要望をまとめ、開発予算から開発期間、開発プロジェクトの体制、費用対効果などを行う工程が含まれる。ソフトウェア企画の結果、開発にGoサインが出されると、ソフトウェア開発の主導権は、開発を担当するベンダー側に移行する。ここで問題となることはユーザー側（発注側）は、開発対象のソフトウェアに関する業務領域（ドメイン）について詳しいものの、ベンダー側（開発側）は、その業務領域についての知識が十分ではないことが多いことである。そこで、このギャップを埋めるために、ドメイン分析という工程が必要となる。
		コマ主題細目	① ソフトウェア開発企画 ② ドメイン分析
		細目レベル	① ソフトウェア企画の段階では、ソフトウェア開発の発注者である事業者がすべてのソフトウェア企画工程を行うことが多い傾向があるが、専門的な知識やアイディア、ノウハウが必要になることがことが多いため、開発を請け負う側であるベンダーがこの段階からメンバーとして入り、ソフトウェア企画への助言、サポートを行うこともある。
		細目レベル	② ソフトウェア開発におけるドメイン分析とは、特定の業務領域（ドメイン）で使われる知識、プロセス、ルール、データを収集・整理し、ソフトウェアのモデルとして抽象化する活動を意味する。　ドメイン分析においては、ドメイン専門家との密な連携が不可欠であり、業務を深く理解することでビジネス要件に適合したソフトウェアを設計し、開発チームとドメイン専門家との共通言語を確立することを目指す。ドメイン分析の目的は、以下のようにまとめることができる。・知識の共有と標準化:業務の専門家が持つ知識を収集し、ソフトウェア開発チームと共有する。共通の概念や用語を定義し、誤解を減らすことで、正確なソフトウェア設計につなげていく。・ビジネス要件の明確化:開発対象となるドメインの業務内容、発生するイベント、関連するデータなどを詳細に分析し、ソフトウェアが解決すべき問題とその範囲を明確にします。ドメインモデルの作成:ビジネスドメインを抽象化し、ドメインモデルを作成する。これは、開発するシステム全体の骨子となるものである。　このために、以下のようなプロセスの実施が必要である。 1. ドメインの調査と理解:開発対象となるビジネス領域の専門家（ドメインエキスパート）と協力し、ヒアリングやワークショップなどを通じてドメインに関する理解を深める。 2. 分析とモデリング:収集した知識やデータを基に、ドメインの共通データ領域と制約条件を抽出・標準化し、モデルを作成する。 3. サブドメインの特定:ビジネスのコア機能と補助的な機能、そしてそれらの機能間の依存関係をマッピングし、サブドメインを識別する。 4. 共通言語（ユビキタス言語）の確立:ドメイン専門家と開発チームが共通の言葉でコミュニケーションがとれるように、分析結果から共通言語を確立する。　このようなドメイン分析を行うことにより、以下のような利点が得られる。・ビジネス要件を正確に反映した高品質なソフトウェアが開発できる。・開発チームとビジネス側との認識のずれを減らし、プロジェクトの成功率を高める。・将来的な機能拡張などの保守が容易になる。
		キーワード	① ユーザー ② ベンダー ③ ソフトウェア開発企画 ④ 発注 ⑤ ドメイン分析
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習ソフトウェアの開発においては、一般的に、発注側（ユーザー）と開発側（ベンダー）が存在する。この両者の立場、知識などの相違点についてきちんと整理しておくことが望ましい。 ◆次回授業の予習次回の授業では、ウォーターフォール型の開発プロセスにおいて、ソフトウェア開発企画、ドメイン分析に続いて行われる要求分析工程について述べる。自分が、あるソフトウェア（それがゲームでももちろん良い）の開発を発注する立場となったときに、どのようなことを考えるかについて考えてみよう。
6	要求分析	科目の中での位置付け	要求分析とは、ソフトウェア開発などのプロジェクト初期に行われる工程で、関係者から引き出した「要求」（ユーザーがソフトウェアに望むこと、例えば「〜したい」「〜が欲しい」という非技術的な願望）を、ソフトウェアとして具体的に実現するための「要件」（「〜ができる」「〜が必要」という機能や性能の条件）へと明確化・整理するプロセスである。この分析を通じて、プロジェクトの方向性を明確にし、関係者間の共通理解を形成することで、手戻りを減らしプロジェクトの成功確率を高める目的があります。　この工程において、「要求分析」と「要件定義」という二つに分割して議論されることもある。この場合には、・要求分析：ユーザーの抽象的な願望やニーズを明確化する工程。・要件定義：要求分析で明確化された要求を、技術的に実現可能な「要件」に具体化し、合意する工程。この要件定義で定義される内容（要求仕様）が、後のシステム設計・実装の基盤となる。　「要求」は「requirement」の和訳であり、「要件」などと訳されることもあるが、同じものを意味する。
		コマ主題細目	① 要求分析の目的 ② 要求分析のプロセス ③ 要求仕様書の記載内容
		細目レベル	① 要求分析の主な目的は、以下のようにまとめることができる。・ステークホルダーのニーズ理解：ユーザーのビジネスニーズ、期待、要望を深く理解する。・共通理解の形成：プロジェクトの初期段階で、ビジネスリーダーからエンジニアまで関係者全員が同じ認識を持つことで、認識のズレや仕様変更のリスクを減らす。・プロジェクトの明確化:開発するソフトウェアの方向性を明確にし、システム開発の基盤を構築する。・リスクの軽減：潜在的なリスクや課題を早期に特定し、コストやスケジュールの影響を最小限に抑える。
			② 要求分析の詳細なプロセスとしては、以下が挙げられる。 1. 要求の収集：関係者（特に、ユーザ側）へのヒアリングや調査を通じて、システムに求められる機能や性能などの要求を洗い出す。 2. 要求の分類・整理：収集した要求を、機能要件、非機能要件などに分類し、構造化する。 3. 分析と明確化：曖昧な要求を具体的な「要件」に落とし込み、矛盾や欠落を解消する。 4. 優先順位付け：要求の実現可能性、必要性、効果などに基づいて、各要求の優先順位を決定する。 5. 合意形成：分析結果をステークホルダーと共有し、合意を得る
			③ 要求仕様書は、ソフトウェア開発などにおいて、クライアント（依頼者、ユーザー）が開発する製品やサービスに求める機能、特性、特徴などを具体的にまとめた文書を意味する。目的は、依頼者と開発者間の認識のずれを防ぎ、プロジェクトの目標達成をサポートすることである。要求仕様書には、一般的に、以下の要素が記述されます。・背景・目的：なぜソフトウェアを開発するのか、ソフトウェア導入によって何を実現したいのかを明確にする。・機能要求：システムが持つべき具体的な機能（例：検索機能、データ入出力機能など）をリストアップする。・非機能要求：システムの性能、セキュリティ、使いやすさなどの特性に関する要求を記述する。・制約条件：予算、納期、開発する環境などの制約について記述する。・予算とスケジュール：プロジェクトの予算と、目標とするリリース時期などを記載します。要求仕様書を作成することにより、・関係者間の認識を明確にする。・開発チームの目標を明確にし、プロジェクトの指針とする。・後工程の設計や開発を適切に進めるための材料となるなどという目的が実現される。
		キーワード	① 要求分析 ② 要求定義 ③ 要求仕様書 ④ 機能的要件 ⑤ 非機能的要件
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習ソフトウェア開発が、利用者側（ユーザー、発注者側）と開発側（ベンダー）に分かれて出発することが多い。この時に、重要なのは、利用者側と開発者側との合意の形成である。そのために、最も重要なのがこの要求分析／定義である。この科目を履修している学生諸君が、卒業して、利用者側になるのか、開発者側になるのかは分からないが、どちらの立場の企業に就職しても、やっていかなければならない。あるソフトウェアを開発することを前提にして、どちらの立場に立ったら、何を主張すべきかについてまとめてほしい。 ◆次回授業の予習今回の授業で述べた要求分析に続く工程は、設計である。要求分析が「どんなソフトウェアを開発するのか（what）」であるのに対して、設計は「どのような構造をもったソフトウェアを開発するのか（how to）」である。家を建てることを例にあげて、設計とは、どんなものであるのかについて考えてみよう。
7	設計（１）	科目の中での位置付け	ソフトウェア設計とは、ユーザーのニーズを満たすソフトウェアを具体的にどのように作るかを決定する工程である。具体的には、要件定義で決まった内容を基に、ソフトウェアの内部構造、外部のユーザーインターフェース、処理の流れなどを具体的に設計し、開発チーム全体で共通認識を持てるように設計書を作成する。この工程により、開発の不確実性を減らし、高品質なソフトウェアを正確に、かつ一貫性を持って開発することが可能になる。
		コマ主題細目	① ソフトウェア設計の主な目的とメリット ② 基本設計と詳細設計
		細目レベル	① ソフトウェア設計の主な目的とメリットは、以下のようにまとめることができる。・不確実性の管理と回避：事前に戦略を立てることで、予期せぬ問題に対応し、開発のブレを少なくできる。・正確な実装の確保:開発手順を具体的に定義することで、正確な実装を促す。・開発プロセス全体の指針：ソフトウェアの構造や機能の詳細を明確にすることで、開発の方向性を定め、一貫性を保つ。・品質の向上：要件を満たすための具体的な計画が明確になるため、完成するソフトウェアの品質を高める。
		細目レベル	② ソフトウェア設計は、大きく以下の2段階で進められる。 1.基本設計（外部設計、概要設計）：ユーザーや外部システムから見える部分（ユーザーインターフェース、業務フローなど）を設計する。要求定義の内容をすべて網羅し、ユーザーがどのような操作をすれば、どのような結果が得られるかを具体的に決める。 2. 詳細設計（内部設計）：基本設計で決定した内容を、プログラミングで実現できるように内部構造を詳細に設計する。データ処理の流れや、具体的なアルゴリズム、画面表示や帳票の処理項目などを具体的に定義する。（詳細設計については、次回の講義で述べる）　設計工程の成果物は、ソフトウェア設計書である。そこには、ソフトウェアの全体的な構造、機能、処理フローなどがまとめられる。この設計書は、開発の指針となり、チームメンバー全員が仕様を理解し、一貫した開発を行うための重要なツールとなる。
		キーワード	① ソフトウェア設計 ② ソフトウェア設計書 ③ 基本設計 ④ 詳細設計 ⑤ アーキテクチャ設計
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習これまでに環境プログラミングⅠにおいて、多くのプログラムを作ってきました。逆に考えて、そのようなプログラムを作成するのなら、どのような基本設計が必要なのかを考えてみてください。 ◆次回授業の予習次回の授業では、ソフトウェア設計の中でも詳細設計と呼ばれる工程を扱います。ソフトウェア設計全体の構成について勉強しておきましょう。
8	設計（２）	科目の中での位置付け	ソフトウェア設計とは、ユーザーのニーズを満たすソフトウェアを具体的にどのように作るかを決定する工程である。具体的には、要件定義で決まった内容を基に、ソフトウェアの内部構造、外部のユーザーインターフェース、処理の流れなどを具体的に設計し、開発チーム全体で共通認識を持てるように設計書を作成する。この工程により、開発の不確実性を減らし、高品質なソフトウェアを正確に、かつ一貫性を持って開発することが可能になる。
		コマ主題細目	① ソフトウェア設計の主な目的とメリット ② 基本設計と詳細設計
		細目レベル	① ソフトウェア設計の主な目的とメリットは、以下のようにまとめることができる。・不確実性の管理と回避：事前に戦略を立てることで、予期せぬ問題に対応し、開発のブレを少なくできる。・正確な実装の確保:開発手順を具体的に定義することで、正確な実装を促す。・開発プロセス全体の指針：ソフトウェアの構造や機能の詳細を明確にすることで、開発の方向性を定め、一貫性を保つ。・品質の向上：要件を満たすための具体的な計画が明確になるため、完成するソフトウェアの品質を高める。
		細目レベル	② ソフトウェア設計は、大きく以下の2段階で進められます。 1.基本設計（外部設計、概要設計）：ユーザーや外部システムから見える部分（ユーザーインターフェース、業務フローなど）を設計する。要求定義の内容をすべて網羅し、ユーザーがどのような操作をすれば、どのような結果が得られるかを具体的に決める。（基本設計については、前回の講義で述べた） 2. 詳細設計（内部設計）：基本設計で決定した内容を、プログラミングで実現できるように内部構造を詳細に設計する。データ処理の流れや、具体的なアルゴリズム、画面表示や帳票の処理項目などを具体的に定義する。　　設計工程の成果物は、ソフトウェア設計書である。そこには、ソフトウェアの全体的な構造、機能、処理フローなどがまとめられる。この設計書は、開発の指針となり、チームメンバー全員が仕様を理解し、一貫した開発を行うための重要なツールとなる。
		キーワード	① ソフトウェア設計 ② ソフトウェア設計書 ③ 基本設計 ④ 詳細設計 ⑤ デザインパターン
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習これまでに環境プログラミングⅠにおいて、多くのプログラムを作ってきました。逆に考えて、そのようなプログラムを作成するのなら、どのような詳細設計が必要なのかを考えてみてください。 ◆次回授業の予習次回の授業では、ソフトウェア設計に続く実装工程を扱います。実装とはプログラミングによりプログラムを作成することであり、環境プログラミングⅠおよびⅡの内容について予習をしておきましょう。
9	実装	科目の中での位置付け	ソフトウェア実装工程は、設計仕様書に基づいてプログラムコードを作成し、ソフトウェアを具体的に構築する段階であり、プログラミングと考えて良い。この工程は、要求定義や設計を経て行われ、詳細設計書などの仕様書を基に開発者がコーディングを行い、設計どおりに機能するかを確認しながら進められる。最近では、生成AIを用いた実装も頻繁に用いられるようになってきている。実装の品質を高めるため、コードのレビューやバグ修正が繰り返し行われる。
		コマ主題細目	① ソフトウェア実装工程の概要 ② コードレビュー ③ コーディングルール
		細目レベル	① ソフトウェア実装工程の概要は、以下のようにまとめることができる。目的：要求定義や設計で定められた仕様を実現するために、実際にプログラムコードを記述する。進め方：詳細設計書や外部設計書を「設計図」として、プログラマまたは生成AIが具体的なコードを記述する。成果物：プログラムコード（ソースコード）
			② コードレビューとは、プログラムのソースコードを開発者以外の第三者がチェックし、潜在的なバグ、セキュリティ上の脆弱性、コードの可読性、保守性の問題点などを発見・修正することで、コードの品質を向上させるプロセスである。チーム開発において、コーディングスタイルの統一、知識共有、スキルアップにも貢献する重要な工程である。コードレビューの目的には、以下がある。・品質向上：早期にバグや脆弱性、設計上の誤りを発見し修正することで、ソフトウェアの品質を担保する。・可読性・保守性の向上：他の開発者が理解しやすい、効率的なコードに修正することで、将来的な保守作業を容易にする。・チーム全体のスキルアップ：レビュアーとレビュイー（コードの作成者）が互いのコードを学び、新しい知識やスキルを共有する。・知識・ノウハウの共有：プロジェクト全体でコーディングスタイルを統一し、知識を共有することで、チーム全体の連携を強固にする。　　効率的なレビューを行うためには、以下の視点を忘れず、幅広い観点からコードを検証する。・仕様・設計要求の充足度：コードが求められている仕様や設計要求を正しく満たしているかを確認する。セキュリティ：コードに潜在的なセキュリティ上の脆弱性がないかをチェックする。可読性・保守性：変数名や関数名が分かりやすいか、コードの記述が論理的で保守しやすいかなどを評価する。・コーディングルールへの準拠：チームで定められたコーディングルールや標準ガイドラインに沿った記述になっているかを確認する。・最適性・効率性：コードが最適化されており、処理が効率的であるかを確認する。レビューを実施する際の手順例には、以下がある。 1. レビュー依頼：コード作成者（レビュイー）が、他の開発者（レビュアー）にコードのチェックを依頼する。 2. コードの確認：レビュアーが、コードの差分を確認し、上記のような観点から検証を行う。 3. フィードバック：問題点や改善点をリストアップし、建設的なフィードバックをテキストや口頭でレビュイーに伝える。 4. 修正・再レビュー：レビュイーがフィードバックに基づいてコードを修正し、再度レビューを依頼する。 5. 承認：問題が解消されたと判断されたら、コードの統合（マージ）や承認を行う。
			③ コーディングルール（コーディング規約）を作成する目的は、プログラムの品質を一定に保ち、プロジェクト全体の生産性と保守性を向上させることである。コードの書き方にルールを設けることで、属人化を防ぎ、担当するプログラマが変わっても一貫した品質を保つことができます。ルールといっても、実際の内容は、タスクやプロジェクトを行うチームによって異なる。代表的なコーディングルールには、命名規則、コーディングスタイルなどがある。
		キーワード	① コードレビュー ② レビュイー ③ レビュアー ④ コーディングルール ⑤ コーディングスタイル
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習環境プログラミングⅠ、Ⅱでは、さまざまなプログラムを書いてきた。こうして作成したプログラムのコーディングルールに関して、再考してみましょう。 ◆次回授業の予習次回からの授業では、オブジェクト指向ソフトウェア開発プロセスについて扱います。みなさんは、環境プログラミングⅡで、オブジェクト指向プログラミングを学んでいきますので、２つの授業の内容がバラバラにならないように予習をしていきましょう。
10	テスト（１）	科目の中での位置付け	新規ソフトウェア開発は、要求定義、基本設計、詳細設計、実装と進んできた。この各工程に対して、各々対応するテストが必要となる。具体的には、実装に対する単体テスト、詳細設計に対する結合テスト、基本設計に対するシステムテスト、要求分析に対する運用テストとなる。本講義では、この４種類のテストの詳細について理解する。
		コマ主題細目	① 単体テスト ② 結合テスト ③ システムテスト（総合テスト） ④ 受入れテスト（運用テスト、ユーザーテスト）
		細目レベル	① 単体テストの役割は、システム開発の初期段階で個々のコンポーネントやモジュールが正しく機能しているかを確認することである。このテストによって、コードに存在するエラーやバグを早期に特定し、修正まで対応できる。また、単体テストによって各コンポーネントが予定通りの動作をすることが保証され、後続の結合テストやシステムテストをスムーズに進められる。また、単体テストは開発プロセス全体の効率性や品質を向上させる重要な役割を果たす。例えば、単体テストが適切に実施されると、後続のテスト段階で発生する問題の数が減少する。これにより、開発サイクル全体のコストや時間を削減できる。他にも、単体テストは開発者が自分のコードの品質を向上させるための良い機会である。何かしらの不具合が見つかると、横並びで問題をチェックできるため、全体としての品質向上に繋がる。
			② 結合テストは、システム開発の中間段階で実施されるテストで、異なるコンポーネントやモジュールが正しく連携して動作するかを確認する。単体テストで確認された各コンポーネントが、相互にデータを受け渡しや機能を連携して動作するかどうか評価しなければならない。結合テストによって、コンポーネント間のインターフェースやデータの流れに関する問題を発見可能となる。また、結合テストは、異なる開発者が作成したコンポーネントが互換性を持っていることを証明する工程でもある。その結果、全体としてシステムが問題なく動作すると保証できる。これにより、システム全体の品質が向上し、システムテストや受入れテストなどの実務に即したテストにも対応しやすくなる。
			③ システムテスト（総合テスト）は、システム全体が要件を満たし、正常に動作することを確認するためのテストである。この段階では、単体テストや結合テストで検証されたコンポーネントやモジュールが、システムとして問題なく動作するかを評価する。また、システムテストは、機能性だけでなく、性能、セキュリティ、互換性、および利用可能性など、システムの様々な側面から評価することが特徴となる。加えて、システムテストでは、エンドユーザーの視点からシステムが適切に動作するかどうかを検証しなければならない。例えば、ユーザーが遭遇する可能性のある問題やシステムの制約を事前に特定するシナリオが、これに該当する。異常系のテストを中心に、システムにトラブルが発生した際の動きを適切に評価しておく必要がある。
			④ 受入れテスト（運用テスト、ユーザーテスト）は、システム開発プロセスの最終段階で実施されるテストである。エンドユーザーの視点から、システムが実際の業務環境で適切に機能するかを検証する。また、受入れテストを通じて、エンドユーザーはシステムの操作方法や機能を理解し、システムを効果的に活用するためのトレーニングを受けることが可能となる。　一般的に受入れテストは、クライアントやエンドユーザーと開発チームが共同で実施する。実際の業務プロセスやシナリオを模倣してシステムが正確に動作するかを確認するため、クライアントやエンドユーザーの協力なしには実施できない。　なお、問題が見つかった場合、開発チームが修正や改善を行う。ただ、この場合はすぐに受入れテストを実施するのではなく、それまでのテストを再度実施することが一般的である。確実に問題が解決されていることを確認してから、改めて受入れテストを実施する。
		キーワード	① 単体テスト ② 結合テスト ③ システムテスト ④ 受入れテスト ⑤ ユーザーテスト
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	自らが、環境プログラミングⅠおよびⅡで作成したプログラムをテストするのなら、どのようにしたらよいのかを考えましょう。 ◆次回授業の予習今回の授業では、ソフトウェア開発のライフサイクルに沿ったテストの概要でした。次回の講義もテストについて扱いますが、より細かい技法について学ぶことになる。環境プログラミングⅠの中で出てきたテスト手法について思い出しましょう。同値分割とか、境界値分析とかについて学んだはずです。
11	テスト（２）	科目の中での位置付け	テスト手法には大きく分けてブラックボックステストとホワイトボックステストの２種類がある。ブラックボックステストとは、要求仕様や外部仕様を基にテストを設計し、ユーザ視点で、外部からの入力に対して出力結果が意図したものであるか検証するテストで、単体テストより大きな対象でのテストで実施されることがほとんどである。メリットとしてはテスト設計が比較的容易である一方で、複数の条件を組み合わせて行うテストについては組み合わせ方に工夫を入れないとテストするデータ量(テストケースなど)が非常に多くなるといった問題が起きる。一方、ホワイトボックステストでは、内部パス、構造や設計情報を基にテストを設計し、プログラムの内部情報を理解した上で一つ一つの動作が意図したものであるかを検証するテストである。テストする対象が小さい場合は効果が高くなる一方で、テスト対象が大きすぎると、把握すべき情報量が多すぎて扱いきれなくなる。そのため、基本的には単体テストで採用されるテスト手法である。このように、ブラックボックステストは結合テスト以上の大きな対象に対して、ホワイトボックステストは単体テストで使うことが多いため、テスト工程では対象の大きさに応じてこれら手法を使い分けてテストすることが必要となる。
		コマ主題細目	① ブラックボックステスト ② ホワイトボックステスト
		細目レベル	① 代表的なブラックボックステスト技法について、以下にまとめる。・同値分割テスト（同値クラステスト）：同値クラス毎に代表的なテストケースを一つ作成する技法である。ここで、同値クラスとは同じ動作をする値の集合のことを意味する。たとえば、数値型変数xの値域が1 ≦ x ≦ 5のときを真、それ以外を偽が出力されるとした場合、1 ≦ x ≦ 5の領域の集合が同値クラスであり、また、x ≧ 6 or x ≦ 0の領域の集合も同値クラスとなる。同値分割テストでテストケースを作成する場合は代表値となる値を使用する。代表値としては、中間値、デフォルトの設定値や入力される頻度の高い値が採用するケースが多い。たとえば、1 ≦ x ≦ 5の領域の集合が同値クラスの時、代表値として中間値のx = 3をテストデータとして使用するなどが該当する。プログラムへの入力として正しい値の集合を有効同値クラス、エラーとなる値の集合を無効同値クラスと呼ぶ。・境界値テスト：入力項目が連続する領域を持つ場合、同値クラスごとに分類したうえで、各同値クラスの最大値または最小値を境界値とし、境界値毎に境界値と境界値の一つ上及び境界値の一つ下の値の３つを用いてテストケースを作成する技法である。たとえば、数値型[整数]の変数xの値が1≦xのときを有効同値クラスとした場合、境界値テストで使用するxの値は0、1、2の3つとなる。この手法は、境界値付近ではエラーや不具合が発生しやすいためである。使用する値のうち、境界値の一つ上の値と一つ下の値について、同値クラスの境界値と同じ出力結果が出るものについては省略可能である。先程の1 ≦ xの例でいうと、x = 2については境界値x = 1と同じ同値クラスに含まれるため省略可能となる。境界値の一つ上の値、一つ下の値については仕様書から入力値の最小単位を確認して設定するがあります。たとえば、x = 10を境界値かつ最小単位を0.1とした時、境界値テストで使用するxの値は9.9 、10、10.1(省略可)の3つとなる。・デシジョンテーブル（決定表）テストとは、全ての入力条件とそれらの組み合わせ及び全ての出力をリストアップして整理した表(デシジョンテーブル)を作成し、それを基にテストケースを作成する技法である。この技法を使用することで、複雑な条件と結果の関係を視覚化し、仕様についての理解が容易になる。また、不要なテストケースの整理をしつつ、条件や結果の組み合わせについて網羅的にカバーすることができるため、テスト効率や品質を向上させることできる。
		細目レベル	② ホワイトボックステストには、命令網羅、判定条件網羅、条件網羅、複数条件網羅と呼ばれる網羅基準が存在する。以下にその詳細について述べる。ホワイトボックステストについては、次回に述べる。・命令網羅：命令網羅とは、全ての処理(命令)を最低1回は通すようにするテストのこと・判定条件網羅：判定条件網羅とは、全ての分岐を最低1回は通すようにするテストのこと・条件網羅：条件網羅とは、個々の条件を最低1回は満たすようにするテストのこと・複数条件網羅：複数条件網羅とは、想定される条件の組み合わせをすべて網羅するテストのこと
		キーワード	① ブラックボックステスト ② 同値分割 ③ 境界値分析 ④ ホワイトボックステスト ⑤ 命令網羅
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	自らが、環境プログラミングⅠおよびⅡで作成したプログラムをテストするのなら、どのようにしたらよいのかを考えましょう。 ◆次回授業の予習テストが終われば、開発は終了し、実際にそのソフトウェアを使用する運用の段階となる。ソフトウェアを使用している時に、どのようなことが起きるのか、考えてみましょう。
12	テスト（３）	科目の中での位置付け	テスト手法には大きく分けてブラックボックステストとホワイトボックステストの２種類がある。ブラックボックステストとは、要求仕様や外部仕様を基にテストを設計し、ユーザ視点で、外部からの入力に対して出力結果が意図したものであるか検証するテストで、単体テストより大きな対象でのテストで実施されることがほとんどである。メリットとしてはテスト設計が比較的容易である一方で、複数の条件を組み合わせて行うテストについては組み合わせ方に工夫を入れないとテストするデータ量(テストケースなど)が非常に多くなるといった問題が起きる。一方、ホワイトボックステストでは、内部パス、構造や設計情報を基にテストを設計し、プログラムの内部情報を理解した上で一つ一つの動作が意図したものであるかを検証するテストである。テストする対象が小さい場合は効果が高くなる一方で、テスト対象が大きすぎると、把握すべき情報量が多すぎて扱いきれなくなる。そのため、基本的には単体テストで採用されるテスト手法である。このように、ブラックボックステストは結合テスト以上の大きな対象に対して、ホワイトボックステストは単体テストで使うことが多いため、テスト工程では対象の大きさに応じてこれら手法を使い分けてテストすることが必要となる。
		コマ主題細目	① ブラックボックステスト ② ホワイトボックステスト ③ テスト駆動開発
		細目レベル	① 代表的なブラックボックステスト技法について、以下にまとめる。・同値分割テスト（同値クラステスト）：同値クラス毎に代表的なテストケースを一つ作成する技法である。ここで、同値クラスとは同じ動作をする値の集合のことを意味する。たとえば、数値型変数xの値域が1 ≦ x ≦ 5のときを真、それ以外を偽が出力されるとした場合、1 ≦ x ≦ 5の領域の集合が同値クラスであり、また、x ≧ 6 or x ≦ 0の領域の集合も同値クラスとなる。同値分割テストでテストケースを作成する場合は代表値となる値を使用する。代表値としては、中間値、デフォルトの設定値や入力される頻度の高い値が採用するケースが多い。たとえば、1 ≦ x ≦ 5の領域の集合が同値クラスの時、代表値として中間値のx = 3をテストデータとして使用するなどが該当する。プログラムへの入力として正しい値の集合を有効同値クラス、エラーとなる値の集合を無効同値クラスと呼ぶ。・境界値テスト：入力項目が連続する領域を持つ場合、同値クラスごとに分類したうえで、各同値クラスの最大値または最小値を境界値とし、境界値毎に境界値と境界値の一つ上及び境界値の一つ下の値の３つを用いてテストケースを作成する技法である。たとえば、数値型[整数]の変数xの値が1≦xのときを有効同値クラスとした場合、境界値テストで使用するxの値は0、1、2の3つとなる。この手法は、境界値付近ではエラーや不具合が発生しやすいためである。使用する値のうち、境界値の一つ上の値と一つ下の値について、同値クラスの境界値と同じ出力結果が出るものについては省略可能である。先程の1 ≦ xの例でいうと、x = 2については境界値x = 1と同じ同値クラスに含まれるため省略可能となる。境界値の一つ上の値、一つ下の値については仕様書から入力値の最小単位を確認して設定するがあります。たとえば、x = 10を境界値かつ最小単位を0.1とした時、境界値テストで使用するxの値は9.9 、10、10.1(省略可)の3つとなる。・デシジョンテーブル（決定表）テストとは、全ての入力条件とそれらの組み合わせ及び全ての出力をリストアップして整理した表(デシジョンテーブル)を作成し、それを基にテストケースを作成する技法である。この技法を使用することで、複雑な条件と結果の関係を視覚化し、仕様についての理解が容易になる。また、不要なテストケースの整理をしつつ、条件や結果の組み合わせについて網羅的にカバーすることができるため、テスト効率や品質を向上させることできる。ブラックボックステストについては、前回の講義で述べた。
			② ホワイトボックステストには、命令網羅、判定条件網羅、条件網羅、複数条件網羅と呼ばれる網羅基準が存在する。以下にその詳細について述べる。・命令網羅：命令網羅とは、全ての処理(命令)を最低1回は通すようにするテストのこと・判定条件網羅：判定条件網羅とは、全ての分岐を最低1回は通すようにするテストのこと・条件網羅：条件網羅とは、個々の条件を最低1回は満たすようにするテストのこと・複数条件網羅：複数条件網羅とは、想定される条件の組み合わせをすべて網羅するテストのこと
			③ テスト駆動開発（TDD）とは、最初にテストコードを書き、そのテストを通過するコードを実装し、コードを整理（リファクタリング）するという「テスト→実装→リファクタリング」の短いサイクルを繰り返すソフトウェア開発手法である。この手法により、バグを早期に発見して品質の高いソフトウェアを効率的に開発することを目指し、特にアジャイル開発において推奨されている。テスト駆動開発のサイクル（レッド・グリーン・リファクター）の手順は以下のようになる。１）テストコード（レッド）を書く：次に実装したい機能のテストコードを作成する。この時点では、まだコードが存在しないためテストは失敗する。２）実装する（グリーン）：失敗したテストを通過させるために、必要最低限のコードを実装する。３）リファクタリング（リファクター）：テストがパスしたら、コードの品質を維持・向上させるためにコードを整理・改善する。これらのステップを繰り返しながら、徐々に機能を追加・蓄積していく。
		キーワード	① ブラックボックステスト ② ホワイトボックステスト ③ 命令網羅 ④ テスト駆動開発 ⑤ リファクタリング
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習自らが、環境プログラミングⅠおよびⅡで作成したプログラムをテスト駆動開発で作り直してみましょう。 ◆次回授業の予習テストが終われば、開発は終了し、実際にそのソフトウェアを使用する運用の段階となる。ソフトウェアを使用している時に、どのようなことが起きるのか、考えてみましょう。
13	保守	科目の中での位置付け	ソフトウェア保守とは、既存のソフトウェアに対してバグ修正、機能改善、環境変化への対応などを行い、ソフトウェアの品質や信頼性を維持・向上させる作業全般のことを指す。製品の引き渡し後から利用終了まで継続的に実施されるもので、利用環境の変化に適応させたり、機能を追加・変更して使い勝手を高めたりすることも含まれる。
		コマ主題細目	① 保守の種類 ② ソフトウェア保守の重要性 ③ 保守のタイミング
		細目レベル	① 保守の種類は、その目的によって、以下のように分類できる。・是正保守（修正保守）：バグや不具合を発見し、それを修正してプログラムの動作を正常に戻す。・適応保守：OSのバージョンアップや周辺機器の変更など、利用環境の変化に対応してソフトウェアを修正・更新する。・改善保守（完全化保守）：ユーザーの要求に応え、機能を追加したり、既存の機能を改善して最適化を図る。・予防保守：ソフトウェアに潜在する問題が顕在化する前に、その原因を特定し、将来の障害を未然に防ぐ。
			② ソフトウェア保守は、以下の諸点から重要である。・ソフトウェアの利用期間延長：継続的な保守により、ソフトウェアを長く安全に使い続けることができる。・ユーザー満足度の向上：機能の改善や不具合の解消により、ユーザーが求める品質と使いやすさを提供し続けられる。・技術進歩への対応：新しい技術や環境の変化にも追随できるよう、ソフトウェアを最新の状態に保つことができる。
			③ 保守のタイミングは、以下のようにさまざまである。・障害発生時（事後保守）：発生した不具合や障害に対応する。・計画的に実施（予防保守・定期保守）：システムを停止させて行う定期的なチェックや、潜在的な問題への対応を計画的に行う。・環境変化時（適応保守）：OSやハードウェアの更新、法律や税制の改正など、外部環境の変化に対応する必要がある場合に行う。
		キーワード	① 修正保守 ② 適応保守 ③ 改善保守 ④ 完全化保守 ⑤ 予防保守
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習ソフトウェア保守は、ソフトウェアの開発・保守ライフサイクルの中で最も難しいと言われている。この理由について、考えてみよう。 ◆次回授業の予習一人でやるとうまくいくものの、同じことを複数人でやるとうまくいかないことが世の中にはある。その例を考えて、なぜそうなるのかについての理由を考察してみましょう。
14	プロジェクト管理	科目の中での位置付け	プロジェクト管理とは、特定の目標を達成するために、ヒト・モノ・カネ・時間・情報といった限られた資源（リソース）を計画的に管理・制御し、プロジェクトを成功に導く活動のことを指す。プロジェクトの「QCD」（品質、コスト、納期）を守りながら、効率的かつ効果的にプロジェクトを進めるための活動全般を指す。
		コマ主題細目	① プロジェクト管理の目的 ② プロジェクト管理の対象 ③ PMBOK（Project Management Body Of Knowledge）
		細目レベル	① プロジェクト管理の目的は、以下を指す。・目標の達成：プロジェクトの目的やゴールを明確にし、それを達成する。・QCDの達成：品質、コスト、納期を適切に管理し、成果物を完成させる。・効率化とリスク軽減：限られたリソースを効果的に配分し、プロジェクトの進行をスムーズにし、潜在的なリスクを管理する。
			② プロジェクト管理の主な要素には、以下がある。・スケジュール：プロジェクト全体の工程を計画し、進捗を管理する。・コスト（予算）：プロジェクトにかかる費用を管理し、予算内に収まるようにする。・品質：成果物が定められた品質基準を満たすように管理する。・リソース：プロジェクトに必要な人員、資材、予算などの資源を適切に配分・管理する。・リスク：プロジェクトの進行を妨げる可能性のあるリスクを特定し、対応策を講じる。・ステークホルダー：プロジェクトの関係者（利害関係者）との調整やコミュニケーションを行う。
			③ PMBOK（Project Management Body of Knowledge）とは、プロジェクト管理のベストプラクティスや知識体系をまとめたガイドラインである。このガイドラインには、プロジェクトの計画、実行、監視、制御、完了といった一連のプロセスの目的や概要、インプット、アウトプット、使用するツールや技法が体系的に整理されている。PMBOKはプロジェクトマネジメント協会 (PMI) によって策定されており、プロジェクト管理の原則に基づき、柔軟性と適応性が重視されている。そのため、さまざまな環境に対応可能であるが、具体的な手法やツールは示されておらず、実践には各自の判断が求められる。IT分野では、ソフトウェア開発やITプロジェクトの管理に広く活用されている。PMBOKを利用することで、各プロセスの効率化やリスク管理が強化され、プロジェクトの成功の可能性が高まる。また、PMBOKガイドに基づいたPMP (Project Management Professional) は、プロジェクトマネジメントに関する国際資格で、PMIによる認定試験が行われている。
		キーワード	① プロジェクト管理 ② QCD ③ ステークホルダー ④ PMBOK ⑤ PMP
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習プロジェクト管理は、ソフトウェア開発を成功するキーアイテムです。これまで経験してきたさまざまな団体行動において、プロジェクト管理における管理対象がどのように管理されてきたかを思い出してみましょう。 ◆次回授業の予習今回の授業実質的な内容は終了するので、特に予習を必要とすることはないものの、ここまで１４回の授業を振り返っておきましょう。
15	今後に向けて	科目の中での位置付け	本講義は、サステナブル・ソフトウェア概論であり、今後、サステナブル・ソフトウェアⅠ（ソフトウェア品質）（２年前期）、サステナブル・ソフトウェアⅡ（オブジェクト指向設計）（２年後期）、サステナブル・ソフトウェアⅢ（アーキテクチャパターン）（３年前期）、サステナブル・ソフトウェアⅣ（開発プロセス方法論）（３年後期）へと続く。本講義では、これらの科目への導入をすでに行ってきたが、今回の授業では、これらの科目との関係性についての知識を深める。
		コマ主題細目	① ソフトウェア品質 ② オブジェクト指向設計 ③ アーキテクチャパターン ④ 開発プロセス方法論
		細目レベル	① サステナブル・ソフトウェアⅠでは、ソフトウェアの品質について扱う。ソフトウェアの品質については、本講義の２回目で扱った。そこで学んだ内容と深めていく。
			② サステナブル・ソフトウェアⅡでは、オブジェクト指向設計を主たるテーマとする。本講義では、第４回目の講義において、構造的開発手法とともに扱った。ただし、実際には、オブジェクト設計だけに閉じず、オブジェクト指向要求分析、オブジェクト指向設計、オブジェクト指向プログラミングとライフサイクルにそって解説を行う予定である。
			③ サステナブル・ソフトウェアⅢでは、アーキテクチャパターンについて扱う。パターンとは、過去のソフトウェア開発において得られたノウハウを再利用しようとするもので、さまざまなパターンが提案されている。この講義では、アーキテクチャパターンを中心にさまざまなパターンについて述べる。
			④ サステナブル・ソフトウェアⅣでは、開発プロセス方法論について扱う。開発プロセスについては、本講義の３回目で扱った。この内容をさらに深める。
		キーワード	① ソフトウェア工学 ② ソフトウェア品質 ③ オブジェクト指向設計 ④ アーキテクチャパターン ⑤ 開発プロセス方法論
		コマの展開方法	社会人講師 AL ICT PowerPoint・Keynote 教科書コマ用オリジナル配布資料コマ用プリント配布資料その他該当なし
		小テスト	「小テスト」については、毎回の授業時間内に、LMS上において当該コマの小テスト（難易度表示付き）を実施する。
		復習・予習課題	◆今回授業の復習今回の講義は、本サステナブル・ソフトウェア概論の最終回である。すべての授業回についての復習をしてほしい。 ◆次回授業の予習最終回ですので、予習はありません

履修判定指標

履修指標	履修指標の水準	キーワード	配点	関連回
ソフトウェア工学の基礎	【★やさしい】・ソフトウェア工学が目指すものを理解している。・ソフトウェア工学の対象について理解している。・ソフトウェアの品質特性について理解している。・ソフトウェア・メトリクスを理解している。・ソフトウェア開発プロセスについて理解している。・ウォーターフォール型、プロトタイプ型、アジャイル型などの開発プロセスについて理解している。・構造的ソフトウェア開発手法について理解している・オブジェクト指向ソフトウェア開発手法について理解している【★★普通】・与えられたソフトウェアに対して、その品質特性、メトリクス値などについて言及できる。・さまざまなソフトウェア開発プロセスの利点・決定について理解している。・構造的ソフトウェア開発手法とオブジェクト指向ソフトウェア開発手法との違いが言える【★★★難しい】・どのような品質特性を計測するのに、どのようなメトリクスが適しているのかについて理解している。・開発対象のソフトウェアの種類を与えた時に、どのような開発プロセスが適しているのかについて言及できる。・構造的ソフトウェア開発手法とオブジェクト指向ソフトウェア開発手法と使い分けることができる。 ※いずれも選択肢のなかから正しいものを選択できること。	サステナブル・ソフトウェア、ソフトウェア工学、ソフトウェア開発・保守ライフサイクル、ソフトウェアの品質特性、ソフトウェア・メトリクス、ウォーターフォール型、プロトタイピング型、アジャイル型、スパイラル型、イテレーション型、構造的ソフトウェア開発手法、オブジェクト指向ソフトウェア開発手法	20	1,2,3,4
ソフトウェア開発の上流工程	【★やさしい】・ソフトウェア開発企画について理解している。・ドメイン分析について理解している。・要求獲得、要求分析、要求仕様について理解している。【★★普通】・与えられたソフトウェアに対して、要求獲得をし、要求分析をし、要求仕様としてまとめることができる。・与えられた要求分析結果がどのようなものであるのかを評価できること。 ※いずれも選択肢のなかから正しいものを選択できること。	ソフトウェア開発企画、As-IsとTo-Do、ドメイン分析、要求獲得、要求分析、要求仕様	20	5,6
設計と実装	【★やさしい】・ソフトウェア設計の主な目的とメリットについて理解している。・基本設計と詳細設計の内容について理解している。・コードレビューの方法について理解している。・コーディングルールについての知識がある。【★★普通】・与えられたソフトウェアに対して、良い設計ができる。・与えられたソフトウェアに対して、良い実装ができる。・実際にコードのレビューができる。【★★★難しい】・与えられた設計結果、実装結果がどのようなものであるのかを評価できること。 ※いずれも選択肢のなかから正しいものを選択できること。	ソフトウェア設計、ソフトウェア設計書、基本設計、外部設計、概要設計、詳細設計、内部設計、デザインパターン、コードレビュー、レビュイー、レビュアー、コーディングルール	20	7,8,9
テスト	【★やさしい】・単体テスト、結合テスト、システムテスト、受入れテストについて理解している。・同値分割、境界値分析、デシジョンテーブル法などのブラックボックステストの手法について理解している。・命令網羅、判定条件網羅、条件網羅、複数条件網羅など各種の網羅度を用いたホワイトボックステストについて理解している。・テスト駆動について理解している。【★★普通】・与えられたソフトウェアに対して、さまざまなテストができる。・さまざまなテスト手法の利点／欠点について述べることができる。【★★★難しい】・与えられたテスト結果がどのようなものであるのかを評価できること。 ※いずれも選択肢のなかから正しいものを選択できること。	単体テスト、結合テスト、システムテスト、総合テスト、受入れテスト、運用テスト、ユーザーテスト、ブラックボックステスト、同値分割、境界値分析、ホワイトボックステスト、命令網羅、判定条件網羅、条件網羅、複数条件網羅	20	10,11,12
保守	【★やさしい】・保守の重要性について理解している・是正保守、修正保守、適応保守、改善保守、完全化保守、予防保守というさまざまな保守の内容について理解している。・事後保守、予防保守・定期保守、適応保守という保守のタイミングについて理解している。【★★普通】・いつ、どのような保守を行うべきかについて理解している。【★★★難しい】・実際のソフトウェアに対して、保守を行うことができる。 ※いずれも選択肢のなかから正しいものを選択できること。	是正保守、修正保守、適応保守、改善保守、完全化保守、予防保守、事後保守、予防保守・定期保守、適応保守	10	13
プロジェクト管理	【★やさしい】・プロジェクト管理の目的について理解している・プロジェクト管理の対象について理解している・PMBOK（Project Management Body Of Knowledge）の概要について理解している。【★★普通】・プロジェクト管理チームに参加した時に、どのように振る舞うべきかについて理解している。・PMBOK（Project Management Body Of Knowledge）の詳細について理解している。【★★★難しい】・実際のソフトウェア開発に対して、プロジェクト管理を行うことができる。 ※いずれも選択肢のなかから正しいものを選択できること。	プロジェクト管理、QCD、PMBOK	10	14

評価方法

評価基準	評語
学習目標をほぼ完全に達成している・・・・・・・・・・・・・	S (100～90点)
学習目標を相応に達成している・・・・・・・・・・・・・・・	A (89～80点)
学習目標を相応に達成しているが不十分な点がある・・・・・・	B (79～70点)
学習目標の最低限は満たしている・・・・・・・・・・・・・・	C (69～60点)
学習目標の最低限を満たしていない・・・・・・・・・・・・・	D (60点未満)

教科書

参考文献

実験・実習・教材費