Comments
Description
Transcript
（J07） - BOK - に対する産業界コメントへの対応
資料６－２ 情報専門学科におけるカリキュラム標準（J07） - BOK に対する産業界コメントへの対応 情報処理学会情報処理教育委員会 J07プロジェクト連絡委員会 CS J０７（中間報告）-BOKに対するコメントおよびその対応 コンピュータ科学 (CS: computer science) DS 情報の基礎となる数学など DS1 関数，関係，集合 DS2 論理 DS3 グラフ DS4 証明技法 DS5 数え上げと離散確率の基礎 DS6 オートマトンと正規表現 DS7 計算論概論 DS8 計算論 PF PF1 PF2 PF3 PF4 PF5 AL AR OS NC PL HC プログラミングの基礎 プログラミングの基本的構成要素 アルゴリズムと問題解決 基本データ構造 再帰 イベント駆動プログラミング アルゴリズムの基礎 アーキテクチャと構成 オペレーティングシステム OS1 オペレーティングシステムの概要 OS2 オペレーティングシステムの原理 OS3 プロセスの構造とスケジューリング OS4 並行性 OS5 メモリ管理 OS6 デバイス管理と入出力 OS7 ファイルシステム OS8 認証とアクセス制御 OS9 セキュリティと高信頼化 OS10 リアルタイムシステムと組込みシステム OS11 並列・分散処理のためのオペレーティングシステムの機 OS12 オペレーティングシステム構成法 OS13 システム性能評価 ネットワークコンピューティング プログラミング言語 ヒューマンコンピュータインタラクション コア 変更 C委員 変更 41 数学系は、全領域共通基礎知 6 識として、別分類としたほうが 6 良いのでは。 4 初等解析や線形代数は、理系共通基礎の数学と 8 して、共通の内容を想定していますが、離散構造 7 DS は CS 領域で学習すべき専門のエリアとして います。他の領域で DS をエリアとして含んでいる 6 場合も、それに含まれる各ユニットの内容やコア 4 の範囲は異なっていて、領域間で共通にすること - F委員 変更 H委員 は難しいと思われます。 38 9 6 14 5 4 18 33 15 1 2 2 4 4 1 1 -＋ - このカリキュラムでは具体的 な教え方までは論じません。 また、コア時間の合計をあまり 増やすわけにはいかないとい う制約があります。 アルゴリズムは、プログラム全 般の基礎になるものと思われ る。アルゴリズムの設計手法・ 設計例を学ぶものとなってい るが、アルゴリズムで必要とさ れるものは、トレースだと思 う。トレースを中心に＋10単位 ほど必要なのではないか。 組込みシステムへの適用は、 日本として推進すべきではな いか。 カリキュラム設計の際に、取 り上げる可能性のあるテー マとして真剣に議論しました が、まだコアとするレベルに は達していないと判断しまし た。今後の検討課題の一つ だと考えます。 14 19 8 1/20 CS コンピュータ科学 (CS: computer science) MR マルチメディア表現 MR1 情報理論 MR2 文字コード MR3 標本化・量子化と圧縮 MR4 マルチメディア機器 MR5 オーサリング MR6 メディア・インタラクション GV IS IM IM1 IM2 IM3 IM4 IM5 IM6 IM7 IM8 IM9 IM10 IM11 IM12 IM13 IM14 グラフィックスとビジュアル・コンピューティング インテリジェントシステム 情報管理 情報モデルとシステム データベースシステム データモデリング 関係データベース データベース問合わせ言語 関係データベース設計 トランザクション処理 分散データベース データベースの物理設計 データマイニング 情報格納と検索 ハイパーテキストとハイパーメディア マルチメディア情報とシステム 電子図書館 3 3 14 2 2 4 3 3 2 1 - SE1 SE2 SE3 SE4 SE5 SE6 SE7 SE8 SE9 SE10 SE11 SE12 社会的視点と情報倫理 ソフトウェア工学 ソフトウェア設計 APIの使用 ソフトウェアツールおよび環境 ソフトウェアプロセス ソフトウェア要求および仕様 ソフトウェア妥当性検査 ソフトウェアの進化 ソフトウェアプロジェクト管理 コンポーネントベース開発 形式手法 ソフトウェアの信頼性 専用システムの開発 11 20 5 2 3 2 5 3 -＋ - SP SE CN コア 変更 C委員 3 情報理論として習得させた 2 ＋ い。 MR 全体を情報理論の観点か 1 ら習得させることは教え方の -＋ 問題で、ここでは扱いません が興味深いと思われます。最 終報告では MR3 に情報理論 が入っています。 計算科学と数値計算 変更 F委員 変更 H委員 検討課題とします。 中間報告書を出した後で SE のコア時間に大きな見 直しが加えられました。中 間報告書時点のコア時間 は 20 時間だったのです が、現在の案では 32 時間 です。プロジェクト管理もコ アとして入っています。要求 分析という作業は顧客から 言われた要求を受け入れる という作業ではなく、さまざ まな関係者、文書、既存シ ステム、法令などから、ある べき要求を決定してくプロセ スで、その中には当然業務 分析も含まれます。 CSと言えども、学生を受け入 れる立場としては、プロジェク ト管理を外してほしくない。 中間報告書を出した後で SE のコア時間に大きな見直しが 加えられました。中間報告書時 点のコア時間は 20 時間だった のですが、現在の案では 32 時間です。プロジェクト管理もコ アとして入っています。要求分 析という作業は顧客から言わ れた要求を受け入れるという作 業ではなく、さまざまな関係 者、文書、既存システム、法令 などから、あるべき要求を決定 してくプロセスで、その中には 当然業務分析も含まれます。 + + + ・システム開発スキル向上の ためのカリキュラムを追加す べきと考える。 中間報告書を出した後で SE の コア時間に大きな見直しが加えら れました。中間報告書時点のコア 時間は 20 時間だったのですが、 現在の案では 32 時間です。プロ ジェクト管理もコアとして入ってい ます。要求分析という作業は顧客 から言われた要求を受け入れる という作業ではなく、さまざまな関 係者、文書、既存システム、法令 などから、あるべき要求を決定し てくプロセスで、その中には当然 業務分析も含まれます。 業務系アプリケーションでは、 データベースのスキーマ構造 を理解することから始まり、シ ステムの拡張性やパフォーマ ンスを考慮した設計をすること が重要になる。その意味で、 「IM6：関係データベース設計」 で教える内容は、コアの位置 づけで扱うべきものと考える。 また、「IM7：トランザクション処 理」についても、業務系アプリ ケーションでは必須となる事 項なので、概念と必要性だけ でも、コアの中で多少の時間 を割いて説明しておいててい ただきたいと思う。 「SE5：ソフトウェア要求及び仕 様」については、要求分析の 前に、現状の業務分析を行な うことを盛り込んだほうが良い と思う。お客様から言われた 要求を受け入れることも重要 だが、新システム導入のタイミ ングで、BPRができることはさ らにシステムの価値を生む。 「SE6：ソフトウエア妥当性検 査」がコア科目に含まれてい ることは高く評価する。開発能 力が高くても、ソフトウェアの 品質に対する意識が低いと、 ソフトウェアに対する信頼性を 損ねる恐れが大きいからであ 2/20 IS J０７（中間報告）-BOKに対するコメントおよびその対応 ＜対応について＞ ISでは、個々のBOKを取り上げて教えるのではなく、教育目的と学習レベルを明確に示した ラーニングユニットを設計し、そこに関連するBOKを紐づけるという方法を採用しています。 そのため、BOKは複数のラーニングユニットに組み込まれています。 科目はラーニングユニットを組み合わせて編成し、したがって、カリキュラムもラーニング が基になります。 この思想は最終報告書に反映されています。 コメントをいただいた中間報告書は，まだBOKだけしか提示できていませんでした。ご指摘 いただいた教育内容については、ラーニングユニットの構成の中でできる限り反映できるよう 努めました。 インフォメーションシステム (IS: information systems) IS1 IS1.1 IS1.1.1 IS1.1.2 IS1.1.3 IS1.1.4 IS1.1.5 IS1.1.6 IS1.2 IS1.3 IS1.3.1 IS1.3.2 IS1.3.3 IS1.3.4 IS1.3.5 IS1.3.6 IS1.3.7 情報技術 コンピュータアーキテクチャ 基本的なデータの表現 ディジタル化された情報の物理的な 表現 CPUの構成 コンピュータシステムの構成要素 マルチプロセッサアーキテクチャ ディジタル論理とシステム アルゴリズムとデータ構造 プログラミング言語 基本的なプログラミング言語の構造 機械語とアセンブリレベルの言語 手続き型言語 非手続き型言語 第４世代言語 言語のオブジェクト指向への拡張 プログラミング言語、設計、実装と 比較 最低 レベ ル 変更 1 2 1 1 1 1 1 2 2 2 0 2 0 0 1+ A委員 B委員 C委員 F委員 H委員 これらの基礎的な内容は、 CSなどの別セクションとの 重複が見受けられるため、 各セクションの共通事項と してまとめるほうが学習者 にはわかりやすいと思われ ます。 IS1.1と同様 オブジェクト指向言語の基 IS1.1と同様 礎知識は必要。オブジェク ト指向言語を使って手続き 型プログラムを書いている 例があとを絶たないため。 コンポーネント指向の方が 適すると考える。 0 3/20 IS インフォメーションシステム (IS: information systems) IS1.4 IS1.5 IS1.5.1 IS1.5.2 IS1.5.3 IS1.5.4 IS1.5.5 IS1.5.6 IS1.5.7 IS1.5.8 IS1.5.9 IS1.5.10 IS1.5.11 IS1.5.12 IS1.5.13 IS1.5.14 IS1.6 IS1.6.1 IS1.6.2 IS1.6.3 IS1.6.4 IS1.6.5 IS1.6.6 IS1.6.7 IS1.6.8 IS1.6.9 IS1.6.10 IS1.6.11 IS1.6.12 IS1.6.13 IS1.7 最低 レベ ル 変更 オペレーティングシステム（OS） 通信 国際通信標準、モデル、傾向 データの伝送 回線構成 ローカルエリアネットワーク 広域ネットワーク ネットワークアーキテクチャとプロ トコル インターネット接続 ネットワーク設定、性能解析および 監視 ネットワークのセキュリティ 高速ネットワーク ネットワーク技術の最新の話題 通信アプリケーション オープンシステムのプロトコル 情報分散 2 3+ 1 1 1 2 1 データベース DBMS データモデル トランザクション 整合性 データ定義言語 アプリケーションインタフェース 知識問合せプロセッサと問合せ機 構、OLAPツール 分散型データベース、リポジトリと データウエアハウス DBMS製品：データベースシステムの 最新状況 データベースマシンとサービス データとデータベースの管理 データ辞書、事典、リポジトリ 情報検索 4 1 4 2 4 4 4 人工知能 1 2 A委員 B委員 C委員 F委員 H委員 IS1.1と同様 通信については、データ IS1.1と同様 ベースに準じて重要度が高 まっている。連携が高ま り、個々の情報システムが 単独では機能しなくなって 来ているため。（小項目へ の配分はお任せします。） 2 2 2 2 2 2 1 1 IS1.1と同様 レベル４の内容に、時代が 古すぎて不適切なものがあ る。再度検討していただき たい。 →1.6.6.7 DAO 1 1 1 1 2 2 4 IS1.1と同様 4/20 IS インフォメーションシステム (IS: information systems) IS2 IS2.1 IS2.1.1 IS2.1.2 IS2.1.3 IS2.1.4 IS2.1.5 IS2.1.6 IS2.1.7 IS2.2 IS2.2.1 IS2.2.2 IS2.2.3 IS2.2.4 IS2.2.5 IS2.2.6 IS2.2.7 IS2.2.8 IS2.2.9 IS2.2.10 IS2.2.11 IS2.2.12 IS2.2.13 IS2.2.14 IS2.2.15 IS2.2.16 IS2.2.17 IS2.3 IS2.3.1 IS2.3.2 IS2.3.3 IS2.3.4 IS2.3.5 組織と管理概念 組織理論一般 組織の階層とフローモデル 組織上の作業グループ 組織のスパン(単一ユーザ、作業グ ループ、チーム、企業、グローバ ル） 企業内でのISの役割 組織構造におけるISの影響 組織の構造（集権型、分権型、マト リクス型） 組織でのソフトウェア使用に関する 組織的問題 最低 レベ ル 変更 3 ++ 3 ++ 3 ++ 3 ++ 3 ++ 3 ++ 3 ++ 3 ++ 情報システム管理 IS計画 IS機能のコントロール スタッフ配置と人的資源管理 ISの機能構造（企業内対アウトソー シング） IS組織の目的と目標の決定 ビジネスとしてのIS管理 CIOとスタッフの機能 サービス機能としてのIS ISの財政管理 ISの戦略的な使用 知的作業、エンドユーザコンピュー ティング ISの方針、運用手順の公式化および コミュニケーション バックアップ、災害対策、および復 旧の計画 新しい技術の管理 サブ機能の管理 セキュリティと管理、ウィルスとシ ステムの安全性 コンピュータ運用の管理 5 5 3 3 意思決定理論 計測とモデル化 確実性、不確実性およびリスクの下 での意思決定 情報のコスト/価値、ISの競争可能な 価値 意思決定モデルとIS（最適化、満足 化） グループの意思決定プロセス 3 3 2 A委員 B委員 C委員 F委員 H委員 情報システムへの変更要求 内部統制に関するカリキュ は、組織変更によるものが ラムを明確にしたほうがよ 多い。情報システムを設計 いのではないでしょうか。 する際、これを活用する組 織の現状だけではなく組織 の構造と経営の要求に基づ く変更の可能性を見抜いた 構造化を行っておくこと で、後の変更要求への対応 の可能性が高まる。また、 組織のミッションを理解す ることにより、情報要求の 理解が高まり、実装形態に 左右され難い有用な情報が 設計できる。（小項目はど れも重要と認識します。） この中項目を「５」として ISの位置づけを説明する部 いる点に共感します。 分、と捉えれば適切な内容 と思われます。ただ内容に よってはIS3以降のカリキュ ラムと重複することが懸念 されます。 3 3 1 3 2 2 また、セキュリティに関す る項目が複数に分かれてい ますが、情報セキュリティ としてまとめではいかがで しょうか。 3 3 2 1 1 2 2 3 3 3 情報システムの専門化が ユーザ組織（経営層から末 端の担当者を含む）を相手 に意思決定の支援を行うこ とは必須です。プロとして サービスできるレベルの訓 練を充実させるべきと考え ます。 経営的な視点からの内容で あるならば、その視点を明 確にした内容にすること で、学習者は立場の相違に よる見方の違いを理解しや すいかと思われます。 4+ 5/20 IS インフォメーションシステム (IS: information systems) IS2.4.5 IS2.4.6 IS2.4.7 IS2.4.8 組織行動 ジョブ設計理論 文化の多様性 グループダイナミクス チームワーク、リーダシップおよび 権限委譲 影響力、権限、政策の行使 認知スタイル 交渉と交渉スタイル 合意の形成 IS2.6.1 IS2.6.2 IS2.6.3 スケジューリングの理論と概念 スケジューリングの目的 スケジューリングの方法 TOC（制約理論） IS2.4 IS2.4.1 IS2.4.2 IS2.4.3 IS2.4.4 IS2.6 IS2.7 IS2.7.1 IS2.7.2 IS2.7.3 IS2.7.4 IS2.7.5 IS2.7.6 IS2.7.7 IS2.7.8 IS2.7.9 IS2.7.10 IS2.8 IS2.8.1 IS2.8.2 IS2.8.3 IS2.8.4 IS2.8.5 IS2.8.6 IS2.8.7 IS2.8.8 IS2.8.9 最低 レベ ル 変更 3 1 3 1 A委員 B委員 C委員 F委員 H委員 IS2.4で３がついている小項 IS2.3と同様 目をIS2.3.5と併せて学習す るとよいと考えます。 IS2.6は、プロジェクト管理 の基礎になりますので、情 1 報システムを提供するプロ 1 セスを理解する上で非常に 1 重要と考えます。業務設計 を行う上でのスケジューリ 3 ングであったとしても、業 3 ++ 務システムとしての情報シ IS2.3と同様 3 ++ ステム設計のためには「時 4 +++ 間」の概念は非常に重要で 3 ++ す。 3 変革プロセスの管理 変革に抵抗する理由 変革を動機づける戦略 変革の計画づくり 変革の管理 モデル化プロセスとシステム データ取得手段の実験 プロセスや関係するソフトウェアの 改良でのリーダシップ 対処方略 グループおよびチーム学習 変革者の特性 2 1 1 1 1 1 1 ISの法的、倫理的側面 ソフトウェアの販売・使用許諾およ び取次ぎ 契約の基礎 プライバシ法 取次ぎと規制集団 知的財産権の保護と倫理 倫理と法律、倫理モデル、倫理的社 会的分析 計算機アプリケーションのリスク、 損失および責任 保証 コンピュータ犯罪 2 この中項目も非常に重要と IS2.3と同様 考えますが、配分を高める のは難しいでしょうか。 1 1 2 1 1 2 2 1 2 2 個人情報保護や情報セキュ リティに関するカリキュラ ムを明確にしたほうがよい のではないでしょうか。 契約の基礎で、準委任型の 契約と請負型の契約の特徴 をきちんと教えるととも に、情報システム開発にお ける「モデル取引・契約」 の概要を教えるべきである （可能であれば、どのよう なトラブルがあるのかを紹 介する） 2 2 2 6/20 IS インフォメーションシステム (IS: information systems) IS2.9 IS2.9.1 IS2.9.2 IS2.9.3 IS2.9.4 IS2.9.6 IS2.9.7 IS2.10 IS2.10.1 IS2.10.2 IS2.10.3 IS2.10.4 IS2.10.5 IS2.10.6 IS2.10.7 IS2.10.8 IS2.10.9 IS2.10.10 IS2.10.11 IS2.10.12 IS2.10.14 IS2.10.15 最低 レベ ル プロフェッショナリズム 現行の定期的、専門的、学術的刊行 物 証明書の発行 専門組織（学協会など） 専門家会議 IS産業 コンピューティングの歴史的社会的 な文脈 2 対人関係の能力 コミュニケーション能力 インタビュー、質問、傾聴 プレゼンテーションの技能 コンサルティングの能力 執筆能力 積極的な態度と取組み 個人の目標の設定、意思決定、時間 管理 原則を中心としたリーダシップ 交渉の原則 創造性と機会発見力 批判思考 データの測定と分析 個人の問題解決 発想法 3 3 1 1 1 1 1 変更 A委員 B委員 C委員 F委員 H委員 学術的な側面だけでなく、 業界標準があるものに関し てはそれらについても触れ ておくのはいかがでしょう か。 1 1 1 1 2 1 - 11 1 1 1 1 1 3 - IS2.10の重要性は痛いほど わかります。しかしこの領 域は、頭でわかって口で説 明できても何の役にも立ち ません。教室での知識提供 が中心となる大学教育にお いて、この領域をきちんと 理解させるには時間が足り ないのではないでしょう か。できればレベル４を目 指すべきですが、教室で は、諦めて1に留めることに なるでしょう。この領域の 教室での講義や学習は１に 留めておき、他の項目の演 習や教授・講師の態度を通 じて、４年間かけて伝えて いくということではいかが でしょうか。そういう意味 では、１年生の早い時期に 知識として与え、日々の学 習 この分野は机上の知識等で は習得できない内容が多い ものです。ここでは基本的 な手法や理論を紹介した上 で、別カリキュラムでケー ススタディやロールプレイ なども実施すると、社会で の活躍が早く期待できるの ではないでしょうか。米国 のMBAでも専門知識に加えて このような実務擬似体験を 重視していると聞きます。 7/20 IS インフォメーションシステム (IS: information systems) IS2.11.6 IS2.11.7 IS2.11.8 IS2.11.9 IS2.11.10 IS2.11.11 IS2.11.12 IS2.11.13 IS2.11.14 IS2.11.15 基本的な組織の機能 支払い ビジネスの関係（例：CtoB、BtoB、 BtoGなど） ビジネスのモデル、伝統的/電子的商 取引 バリューチェーン（VC）の概念 サプライチェーンマネジメント （SCM）の概念 アテンション マーケティングと広告 小売り 製造業と製品 人的資源管理とコンプライアンス 在庫管理 発送（船積み） 調達 注文票と顧客サービス 会計監査と管理 IS3.1.1 IS3.1.2 IS3.1.3 IS3.1.4 IS3.1.5 IS3.1.6 システムの理論と開発 システムと情報の概念 一般システム理論 システム概念 開放系と閉鎖系 システムの構成要素と関係 システム管理 情報システムの特性 IS3.2.1 IS3.2.2 IS3.2.3 IS3.2.4 IS3.2.5 システム開発のアプローチ システム開発モデル パッケージの取得と実装 ソフトウェア構成要素の統合 エンドユーザ開発のシステム システム開発アプローチの選択 IS2.11 IS2.11.1 IS2.11.2 IS2.11.3 IS2.11.4 IS2.11.5 IS3 IS3.1 IS3.2 最低 レベ ル 変更 4 ++ 2+ 2+ 2+ 2+ 2+ 2 2 2 2 2 2 2 2 2 2 + + + + + + + + + + 2 2 2 1 2 1 2 5 5 3 1 1 2+ A委員 B委員 基礎的なビジネスモデルの 理解は、ビジネスアプリ ケーションを提案・設計す るシステムエンジニアには 必須の基礎知識であると考 えます。社会人経験のない 学生に企業のビジネスモデ ルを理解させることは至難 のわざと思われますが、努 力を放棄してしまってはい けない領域だと考えます。 よろしくお願いします。 要件定義に関するカリキュ ラムとしてのまとめがある とわかりやすいと考えられ ます。 業務システム（＝業務の仕 組み）（例：金融システ ム）、電子化された信号だ けを扱うコンピュータシス テム、更にその一部である アプリケーションプログラ ムといったものが入れ子構 造に組みあがった仕組みの 全体像と、その中で流通す る「情報」（≠画面・帳 票）に関する正しい理解 は、IS学士の必須学習項目 と考えます。レベル２で あっても、深い理解を促す 講義をお願いします。 他のセクション等との重複 感があるので、いずれかで まとめて示すことがよいの ではないでしょうか。 巷には、何とかアプローチ というのが溢れています。 学生が「新しい（提唱・実 用化が遅かった）もの＝良 いもの」という誤謬に陥る 前に、正しい知識を与えて おく事は非常に重要と考え ます。作り上げる構造体の 利用目的と規模によって適 切なアプローチを選ぶとい う考え方を理解することは 必須です。 この中に含めないとして も、具体的な事例教材があ ると実感としてわかりやす いかと思われます。 C委員 F委員 H委員 ・ ビジネスモデルを用いた この中項目の内容は、モデ 講義時間を確保しているこ ルとした米国版の影響を受 け過ぎていると思われる。 とに賛成である。 → 発送（Shipping）を船積 みと訳したところなど。も う少し一般的な業務形態と フローをとりいれ、作り直 す必要がある。 なぜ、システム開発モデル で「プロトタイピング」だ けが取り上げられているの か。（欠陥のあるモデルで あるものの）日本で最も利 用されている「ウォーター フォール・モデル」や「ス パイラル」、最近注目され ている「アジャイル」など を教えるべきである。 8/20 IS インフォメーションシステム (IS: information systems) 最低 レベ ル 変更 システム開発の概念と方法論 組織のモデル化及びソフトウェアプ ロセスのモデル化 データモデリング データ指向方法論 プロセス指向方法論 行動指向方法論 オブジェクト指向方法論 ソフトウェア工学のプロセスとプロ ダクト 5 システム開発ツールと技術 CASE グループベースの方式 ソフトウェア実装の概念とツール リポジトリの概念と活用 5 1 1 4 4+ 5 1 2+ 4 IS3.5.6 アプリケーション計画 インフラストラクチャ計画 ISアーキテクチャの計画 運用のための計画 システム規模、ファンクションポイ ント、複雑さ管理のメトリクス ISセキュリティ、プライバシおよび 管理のための計画 発注管理 IS3.6.1 IS3.6.2 IS3.6.3 リスク管理 実現可能性の評価 リスク管理の原則 不測事態対応計画 2 1 1 2 IS3.3 IS3.3.1 IS3.3.2 IS3.3.3 IS3.3.4 IS3.3.5 IS3.3.6 IS3.3.7 IS3.4 IS3.4.1 IS3.4.2 IS3.4.3 IS3.5 IS3.5.1 IS3.5.2 IS3.5.3 IS3.5.4 IS3.5.5 IS3.6 1 4 1 1 1 2+ 4 1 1 1 A委員 B委員 ビジネスアプリケーション 全体に対してオブジェクト 指向技術がどう位置づけら れるものであったとして も、目指すものや良さ、限 界などを理解しておくこと は必須と考えます。アプ ローチに関しても、何が違 うのか、メリットとデメ リットは何かなどは重要な 知識と考えます。 システム開発システム、シ ステム管理システムとして の「リポジトリシステム」 に支援されたシステム設 計・開発・維持環境とその 運用に関する知識は必須と 考えます。「IS3.4.1： CASE」を拡張しても良いで しょう。 CMMI(Capability Maturity Model Integration)や SLCP(Software Life Cycle Process)の考え方を紹介す るとしたら、この章でしょ うか。 ハードウェアやネットワー クはISの守備範囲ではない と考えますが、アプリケー ションシステムの体系やそ の中長期的な拡張計画を練 るという観点での理解は必 須と考えます。 ITでは短期的な見方あるい は個別アプリケーションを 短期に実用化することが主 眼になると考えられますの で、IS＝中長期、IT＝短期 といった棲み分けとすれ ば、必須の項目になると考 えます。 システム化計画はIS2章、プ ロジェクト計画はこのIS3章 で示すという想定かと思わ れます。初めて学習する場 合、それらの相違を前もっ て理解しておかないと混乱 が生じます。 他のセクション等との重複 感があるので、いずれかで まとめて示すことがよいの ではないでしょうか。 C委員 F委員 H委員 レベル４の内容に、時代が 古すぎて不適切なものがあ る。再度検討していただき たい。 →3.4.3.2 Boehm, 1984 プロジェクト推進上のリス クであるならば、その側面 であることがわかるように しておきたいところです。 9/20 IS インフォメーションシステム (IS: information systems) 最低 レベ ル 3 IS3.7.3 IS3.7.4 IS3.7.5 IS3.7.6 IS3.7.7 IS3.7.8 IS3.7.9 IS3.7.10 IS3.7.11 IS3.7.12 IS3.7.13 IS3.7.14 IS3.7.15 プロジェクト管理 プロジェクト計画と適切なプロセス モデルの選択 プロジェクトの組織、管理、原則、 概念、問題 作業構造（WBS）とスケジュール プロジェクトスタッフの考え方 プロジェクトの管理 複数プロジェクトの管理 管理上の概念、ストレスと時間管理 システム文書の作成 ユーザ文書の作成 システムのメトリクス スコープとスコープ管理 構成管理 システム開発の品質保証 プロジェクトの追跡 プロジェクトの完了 IS3.8.1 IS3.8.2 IS3.8.3 情報とビジネスの分析 問題点と機会の認識 企業モデル 要求定義と仕様化 5 4 1 4 情報システム設計 設計（論理、物理） 設計方法論 設計目標 創造的な設計プロセスを促進する技 術 情報表現の代替案、認知スタイル 人間とコンピュータの相互作用 ソフトウェア開発 ソフトウェアアーキテクチャ 5 4 5 5 IS3.7 IS3.7.1 IS3.7.2 IS3.8 IS3.9 IS3.9.1 IS3.9.2 IS3.9.3 IS3.9.4 IS3.9.5 IS3.9.6 IS3.9.7 IS3.9.8 変更 3 3 3 1 2 2 1 1 1 1 1 1 1 1 1 1 4 3+ 1 2 A委員 B委員 IS3.7.1は、IS3.2.5のアプ ローチ選択に続いて、その プロジェクト固有の制約や 事情を加味してプロジェク トプロセスそのものを作り 上げていく段階として切り 分けないと、学生には、 IS3.7.1とIS3.2.5の違いが 分からないでしょう。小項 目名も、例えば、「プロ ジェクト計画と適切なプロ セスの組み立て」などにす ると誤解が少ないと考えま す。 更に、IS3.7.3との棲み分け もあると思いますので、 3.7.2を3.7.1に、3.7.3を 3.7.2にして、3.7.1を名称 変更した上で3.7.3に持って くると良いか IS2.10と同様に、プロジェ クト管理の基本的な考え方 や方法を示した上で、実践 を想定した演習が別途実施 できれば、実務的には有効 と思われます。 この領域をレベル５とした 点に共感します。 用語：「要求定義」であ り、「要求開発」ではない ですね。 単純なマンマシンインター フェースという意味ではな く、経済面を加味した人と コンピュータの適切な分担 の提案ができるという意味 での理解が必要と考えま す。 順序として、現状分析と要 件定義はIS3章のもう少し前 に置くほうがわかりやすい かと思われます。 C委員 F委員 H委員 工数の見積もり手法はどこ で教えるのか？ システム監査に関するカリ キュラムも別途設けること が望ましいかと思われま す。 また、品質管理に関するカ リキュラムは、プロジェク ト管理の一環としての「シ ステム開発の品質保証」だ けではなく、独立して全 フェーズを網羅するように 位置づけるとよいのではな いでしょうか。 IS3.8と同様に、システム設 計についてもIS3章のもう少 し前に置くほうがわかりや すいかと思われます。 10/20 IS インフォメーションシステム (IS: information systems) IS3.10 IS3.10.1 IS3.10.2 IS3.10.3 IS3.10.4 IS3.10.5 IS3.10.6 IS3.10.7 IS3.10.8 IS3.10.9 IS3.11 IS3.11.1 IS3.11.2 IS3.11.3 IS3.11.4 IS3.11.5 IS3.12 変更 A委員 B委員 システムの実装とテスト戦略 システムの構築 ソフトウェアシステムの構築 ソフトウェアの統合 システム移行 システム統合とシステムテスト 訓練 ソフトウェアプロジェクトの管理 システムのインストール 実装後のレビュー 1 1 1 1 1 1 1 1 1 1 IS3.10.8はソフトウェアの インストールでしょうか。 ※システムとソフトウェア の違い（業務システムと情 報システムとコンピュータ システムの違い、ソフト ウェアとプログラムの違 い）をはっきりさせて共有 しないため、混乱の元に なっています。（SLCP98と 2007では定義が変わってし まいました。）どれをどう ということは三輪が決める 立場にはありませんが、広 く共有された解釈がないこ とは問題です。よろしくお 願いします。 処理方式や方式設計、移行 に関するカリキュラムも実 務上は重要かと思われま す。 システムの運用と保守 サービス要請と変更管理 リバースエンジニアリングとリエン ジニアリング 調整と均衡化 システムとソフトウェア保守の概念 情報システムの評価 1 1 経営者が投資する対象とし ての情報システムの価値を 量るという概念だけは、理 解させておく必要があると 考えます。 企業等が利用する実際の情 報システムでは、この分野 に必要な経営資源はかなり 多いので、それがわかるよ うにするのはいかがでしょ うか。 さまざまな情報システムの開発 トランザクション処理システム 経営情報システム グループ支援システム 意思決定支援システム/エキスパート IS3.12.4 システム IS3.12.5 エグゼクティブ情報システム IS3.12.6 オフィスシステム IS3.12.7 協調作業システム IS3.12.8 画像およびワークフローシステム IS3.12.9 機能的な支援システム IS3.12.10 企業間連携システム IS3.12.11 生産管理システム IS3.12.1 IS3.12.2 IS3.12.3 IS3.13 IS3.14 IS3.15 IS3.16 最低 レベ ル IS教育と環境 IS人材の育成 教育方法論 その他の参照学問 1 1 1 2+ 3 -1 1 1 1 1 1 1 1 1 1 1 C委員 F委員 H委員 IS2.11の方が重要と考えま さまざまな適用例として、 す。あるいは、IS2.11の講 ISの冒頭でも概略を紹介す 義の中でIS3.12のような分 るのはいかがでしょうか。 類軸があることを添えて、 IS2.11の各要素の属性とし て、先の分類を補足すれば 済むようにも思えます。い かがでしょうか。 3 2 2 1 11/20 SE J０７（中間報告）-BOKに対するコメントおよびその対応 ソフトウェアエンジニアリング (SE: software engineering) 確率・統計 FND 数理基礎・工学基礎 FND.mf 数理基礎 FND.mf.6 離散確率 FND.mf.9 数値誤差と精度 FND.ef ソフトウェアのための工学基礎 FND.ef.2 統計解析（検定と推定、回帰分析、相関など） 離散数学 論理と推論・計算理論 コンピュータとソフトウェア工学の基礎 CMP コンピュータ基礎 CMP.cf コンピュータ科学基礎 CMP.cf.5 コンピュータの構造 CMP.cf.6 システムの基礎 *** ***.** ***.**.* ソフトウェア工学の基礎 オペレーティングシステム基礎・データベース基礎 CMP コンピュータ基礎 CMP.cf コンピュータ科学基礎 CMP.cf.10 オペレーティングシステムの基礎 CMP.cf.11 データベースの基礎 ネットワーク基礎 一般工学基礎 CMP CMP.cf FND FND.ef PRF PRF.pr 時間数 C委員 0 数学系は、全領域共通基礎知 識として、別分類としたほうが 良いのでは。 F委員 G委員 その分野の基礎は全領域共 通であっても各分野で再掲す ることとしています。 その分野の基礎は全領域共 通であっても各分野で再掲す ることとしています。 数学系は、全領域共通基礎知 識として、別分類としたほうが 22.5 良いのでは。 数学系は、全領域共通基礎知 識として、別分類としたほうが 22.5 良いのでは。 22.5 22.5 H委員 必要ならば、教養基礎科目に 回すのではなく、コアとしての 時間を設定すべきである。 その分野の基礎は全領域共 通であっても各分野で再掲 することとしています。 その分野の基礎は全領域共 通であっても各分野で再掲 することとしています。 ソフトウェア工学の基礎も、き ちんとBOKとして大中小の項 目ＩＤを付与すべきである。 異なる2つの意見があるよう に、SE委員会の中でも意見 が分れました。ある分野の特 徴を出したい学科はSAS科目 の中で、その部分を強化でき るということで、このようになり ました。 OS・DB・NW基礎の目標が「開 発に必要な程度の知識を得 る」であることを考慮すると、 他項目と比較して若干時間を 割きすぎな感がある。 データベース関係の科目がこ れだけしかないというのは、産 業界では受け入れがたいこと である。トランザクション処理 なども業務用ソフトウェアでは 必須であり、何らかの項目とし て取り上げる必要がある。 22.5 SE以外の領域でも共通として 22.5 必要ではないか。 コンピュータ基礎 コンピュータ科学基礎 数理基礎・工学基礎 ソフトウェアのための工学基礎 プロフェッショナルプラクティス プロフェッショナリズム J07委員会の方で検 討を依頼します。 12/20 SE ソフトウェアエンジニアリング (SE: software engineering) データ構造とアルゴリズム・プログラミング言語基礎 CMP コンピュータ基礎 CMP.cf コンピュータ科学基礎 CMP.cf.1 プログラミング基礎（制御とデータ、型付け、再帰） CMP.cf.2 アルゴリズムとデータ構造、データ表現（静的・動的）、 複雑性 CMP.cf.4 抽象化（カプセル化や階層化など） CMP.cf.13 プログラミング言語の意味論 CMP.ct 構築技術 CMP.ct.2 コードの再利用とライブラリ CMP.ct.4 パラメータ化と汎化 CMP.ct.5 アサーション、契約による設計(DbC)、防御的プログラミ ング CMP.ct.6 エラーハンドリング、例外処理、フォールトトレラント CMP.tl 構築のためのツール CMP.tl.1 開発環境 CMP.tl.2 GUI構築ツール CMP.tl.3 単体テストツール CMP.tl.4 アプリケーション指向言語（スクリプト言語、ビジュアル 言語、ドメイン特化言語、マークアップ言語、マクロな CMP.tl.5 プロファイリング・パフォーマンス分析・スライシングの ツール ソフトウェア構築 CMP コンピュータ基礎 CMP.cf コンピュータ科学基礎 CMP.ct 構築技術 CMP.tl 構築のためのツール DES ソフトウェア設計 DES.con 設計に用いられる概念 DES.dd 詳細設計 ソフトウェアモデリングと要求開発 MAA ソフトウェアのモデリングと分析 MAA.md モデリングの基礎 MAA.tm モデルの種類 MAA.rv 要求の評価 時間数 22.5 C委員 F委員 G委員 H委員 プログラマにとっては、プログ ラミング言語の文法を理解す ることが手始めにはなるが、 応用していくためには、構造を 見抜いて分解する能力や、パ ターン化できる能力が必要に なると考える。 離散数学など、上記のFNDの 項目を基礎として、構造を把 握する能力を身に付けさせる ことで、プログラミング能力も 向上するものと考える。 論点別分類（SE領域）の 方でお答えしました。 22.5 ビジネスモデルを用いた講義 時間も確保すべきと考える。 論点別分類（SE領域）の 方でお答えしました。 22.5 非機能要件についても扱って ほしい。 論点別分類（SE領域） の方でお答えしました。 モデリングという用語はソフトウェア開発の重要な概念であり、 この用語を冠した授業名を置くべきという議論でした。 「形式手法」は設計以前だけの工程の用語ではないため、ここ は「ソフトウェアモデリングと要求開発」としたいと思います。 「要求開発」という用語については更に検討の必要があると考 えています。 この内容は「形式手法」とまと めて一つの講義とすべきであ る。 13/20 SE ソフトウェアエンジニアリング ソフトウェアアーキテクチャ DES DES.con DES.con.1 DES.con.2 DES.con.3 DES.con.4 DES.con.5 DES.con.6 DES.con.7 DES.con.8 DES.str DES.str.1 DES.str.2 DES.str.3 DES.str.4 DES.ar DES.ar.1 DES.ar.2 DES.ar.3 DES.ar.4 DES.ar.5 DES.ar.6 DES.ste DES.ste.1 DES.ste.2 DES.ste.3 DES.ste.4 ソフトウェア設計 ソフトウェアV&V (SE: software engineering) 時間数 22.5 ソフトウェア設計 設計に用いられる概念 設計という概念の定義 基本的な設計の考慮事項（データの永続性、ストレー ジマネジメント、例外など） 複数のソフトウェア開発ライフサイクルにおける設計の 関係 設計の原則（情報隠蔽、凝集度と結合度） 設計と要求との競合 品質特性の設計（信頼性、ユーザビリティ、性能、テス ト容易性、フォールトトレラント性） 設計におけるトレードオフ アーキテクチャのスタイル、パターン、再利用 設計のパラダイム 機能指向による設計 オブジェクト指向による設計 データ構造を中心とした設計 アスペクト指向による設計 アーキテクチャ設計 アーキテクチャスタイル（パイプアンドフィルタ、レイヤー ド、トランザクション中心、ピアツーピア、 publish/subscribe、イベント駆動、クライアントサーバな アーキテクチャで考慮すべき様々な特性間のトレードオ ソフトウェアアーキテクチャで考慮すべきハードウェア アーキテクチャにおける要求のトレーサビリティ ドメイン特化アーキテクチャおよびプロダクトライン開発 アーキテクチャのための記法（アーキテクチャ上の ビューポイントと表現、コンポーネント図など） 設計の支援ツールと評価 設計支援ツール（アーキテクチャ、静的解析、動的評価 など） 設計上の特性の測定（結合度、凝集度、情報隠蔽、関 心事の分離など） 設計のメトリックス（アーキテクチャ上の要因、変換、一 般的な使い方におけるメトリクス） フォーマルメソッドによる設計の分析 C委員 F委員 G委員 H委員 ソフトウェア（モジュール、コン ポーネントetc）の再利用に関 する教育が必要、できれば Webサービスについても。 DES.con.6品質特性の設計の 中に、セキュリティを含めるべ きである。（FND.ef.4や VAV.tst.9には含まれている） ソフトウェア構築 CMP.ct.11,DES.dd.3などでコ ンポーネントが触れられま す。この中で再利用性などに ついて言及されるようにした いと思います。Software Engineering の一部の教科書 ではComponent-based developmentはこれまでの開 発方法と違う形で明記される など、その重要性は高まって いると考えますので、今後そ の扱いをWebサービスを含め て検討します。 セキュリティの重要性の高ま りを受けて、カリキュラムモデ ルではSAS科目（選択科目） の一例として、セキュリティの 扱いに特化した科目「高セ キュリティ情報システム」を挙 げています。しかしながらご指 摘のように、コア科目群中の 品質関連科目において共通 にセキュリティについても言及 すべきことが望ましく、今後、 科目「ソフトウェアアーキテク チャ」内における時間的な実 現可能性も含めて言及を検 討します 22.5 22.5 14/20 SE ソフトウェアエンジニアリング 形式手法 CMP MAA MAA.md 開発プロセスと保守 FND FND.ec PRF EVO PRO PRO.con PRO.imp QUA QUA.cc QUA.std QUA.pro QUA.pca QUA.pda ヒューマンファクター ソフトウェア開発マネジメント FND PRF MAA MGT MGT.con MGT.pp MGT.per MGT.ctl MGT.cm (SE: software engineering) 時間数 22.5 C委員 F委員 形式手法は重要であり、また 要求分析、定義工程だけに限 られるものではないので、この ような形としました。 コンピュータ基礎 ソフトウェアのモデリングと分析 モデリングの基礎 22.5 数理基礎・工学基礎 ソフトウェアのためのエンジニアリングエコノミクス プロフェッショナルプラクティス ソフトウェアの進化や保守 ソフトウェア開発プロセス プロセスの基礎 プロセスの実装 ソフトウェア品質 ソフトウェア品質の概念と文化 ソフトウェア品質に関する標準 ソフトウェア開発プロセスの改善 プロセスの保証 プロダクトの保証 G委員 「ソフトウェア品質関連科目を 減らさざるを得なかった」との ことだが、その分野はむしろ企 業側で補完できるので、問題 はない。 H委員 この内容は「ソフトウェアモデ リングと要求開発」とまとめて 一つの講義とすべきである。 ありがとうございます。 22.5 22.5 数理基礎・工学基礎 プロフェッショナルプラクティス ソフトウェアのモデリングと分析 ソフトウェア開発のマネジメント マネジメントの基礎 プロジェクトの計画 プロジェクトのメンバと組織 プロジェクトのコントロール ソフトウェア構成管理 ソフトウェア開発の契約に関 する教育は必要ないか？ SE領域はソフトウェア開発ライフサイクルを網羅 するカリキュラムモデルとし、各工程の理解、品 質・生産性・コストといった要因の理解、また、グ ループ作業作業、マネジメント、コミュニケーショ ン、チームダイナミクスなどを学び実践するカを 持たすこととしております。「契約」に関すること は明確に出ていませんが、PRF.psy.4 ステーク ホルダーとの対話や、MGT.con.5 調達マネジメ ントで触れられることになります。「契約」につい ての扱いの重要性等については再度検討いた します。 15/20 CE J０７（中間報告）-BOKに対するコメントおよびその対応 コンピュータエンジニアリング (CE: computer engineerning) CE-ALG アルゴリズム CE-ALG0 歴史と概要 CE-ALG1 基本アルゴリズムの分析 CE-ALG2 アルゴリズム戦略 CE-ALG3 アルゴリズムの複雑性 CE-ALG4 アルゴリズムと問題解決 CE-ALG5 データ構造 CE-ALG6 再帰 CE-ALG7 基本的計算可能性理論 CE-ALG8 コンピューティングアルゴリズム CE-ALG9 分散アルゴリズム CE-CAO CE-CSG CE-DBS CE-DIG CE-DSP CE-ESY CE-ESY0 CE-ESY1 CE-ESY2 CE-ESY3 CE-ESY4 CE-ESY5 CE-ESY6 CE-ESY7 CE-ESY8 CE-ESY9 CE-ESY10 CE-ESY11 CE-ESY12 CE-ESY13 CE-ESY14 CE-ESY15 CE-ESY16 CE-ESY17 CE-ESY18 CE-ESY19 CE-ESY20 CE-ESY21 CE-ESY22 CE-ESY23 CE-ESY24 コンピュータのアーキテクチャと構成 回路および信号 データベースシステム ディジタル論理 ディジタル信号処理 組込みシステム 歴史と概要 低電力コンピューティング 高信頼性システムの設計 組込み用アーキテクチャ 開発環境 ライフサイクル 要件分析 仕様定義 構造設計 テスト プロジェクト管理 並列設計（ハードウェア、ソフトウェア） 実装 リアルタイムシステム設計 組込みマイクロコントローラ 組込みプログラム 設計手法 ツールによるサポート ネットワーク型組込みシステム インタフェースシステムと混合信号システム センサ技術 デバイスドライバ メンテナンス 専門システム 信頼性とフォールトトレランス コア 変更 C委員 変更 F委員 G委員 25 CE-PRF「プログラミング」と 1 セットとした方がよいのでは。 BOK（知識項目の整理）としては，別項目としてい 2 アルゴリズムは、設計等、他 ますが，具体的な科目を構成するときはご指摘の 8 の工程でも活用する知識なの ように同じ科目の中に組み込む，同時期に平行し 2 で独立しているかもしれない た科目として設置するなどの工夫をするのがよい と考えています。 4 が、活用場面との関連性を持 6 たせた方が理解が深まると考 2 える。また、プログラミングこ そ、アルゴリズムを注意深く検 討すべきであると考える。 38 18 5 29 17 30 1 2 2 6 2 1 1 1 1 1 1 1 2 8 - 組込みならではの設計、実装 に力を入れてほしい。コンパイ ラの原理についても触れてほ しい。 BOKコアは，CEを対象とするす べて学科で与えるべき最低限 を示すものです。設計・実装に どれだけの力を注ぐかは，それ ぞれの学科が判断し決定する ことになります。 コンパイラの原理を含め，ご指 摘のCE-ESY14〜CE-ESY17 は，最終報告書でコアとして時 間割当を行いました。 ＋ ＋ ＋ ＋ 16/20 CE コンピュータエンジニアリング (CE: computer engineerning) CE-HCI ヒューマンコンピュータインタラクション CE-NWK テレコミュニケーション CE-OPS オペレーティングシステム CE-OPS0 歴史と概要 CE-OPS1 並行性 CE-OPS2 スケジューリングとディスパッチ CE-OPS3 メモリ管理 CE-OPS4 セキュリティと保護 CE-OPS5 ファイル管理 CE-OPS6 リアルタイムＯＳ CE-OPS7 ＯＳの概要 CE-OPS8 設計の原則 CE-OPS9 デバイス管理 CE-OPS10 システム性能評価 CE-PRF コア 変更 C委員 変更 F委員 G委員 7 22 22 RTOSを作れる人をイメージす 1 ると、時間が短いのでは。ま CEを対象とするすべての学科で最低限教えるべきもの 6 た、RTOSを活用する人とする を定めたのがコアです。コアの上に，学科が目指すもの 3 と、設計の原則はコアとした に応じて，内容を深めたり，演習・実習をしたりしてカリ 3 い。いずれを目指すのか？ キュラムを構成することになります。 コアの割当は継続して見直していきますが，すべの学科 2 共通という性格から大幅な時間増はできません。J07を 2 ベースとした具体的なカリキュラムの提示等で特色を出 3 したカリキュラム構成例を示す努力をしていく予定です。 2 - CE-PRF0 CE-PRF1 CE-PRF2 CE-PRF3 CE-PRF4 CE-PRF5 CE-PRF6 CE-PRF7 CE-PRF8 プログラミング 14 歴史と概要 1 プログラミングの構成 7 オブジェクト指向プログラミング 1 OSのシステムコールの使用 4 機器制御プログラミング 1 プログラミングのパラダイム イベント駆動プログラミングとコンカレントプログラミン APIの使用 コーディング作法 -＋ CE-SPR0 CE-SPR1 CE-SPR2 CE-SPR3 CE-SPR4 CE-SPR5 CE-SPR6 CE-SPR7 CE-SPR8 CE-SPR9 CE-SPR10 CE-SPR11 CE-SPR12 CE-SPR13 CE-SPR14 CE-SPR15 社会的な観点と職業専門人としての問題 歴史と概要 公的ポリシー 分析の方法およびツール 社会的な観点と職業専門人としての問題 リスクと責任 知的財産権 プライバシーと市民的自由 コンピュータ犯罪 コンピュータにおける経済問題 哲学的枠組み 個人情報保護 内部統制 人材育成 環境問題 ハイテク製品の輸出入規制 各国のハイテク関連法規 CE-SPR 16 1 2 2 2 2 2 2 1 2 - コーディング作法の中身には 触れなくとも、コーディング作 法の必要性だけはコアとした い。 項目を整理し直し，コーディ ング作法もコアに含めた形と しました。その結果は最終報 告書に示してあります。 「技術者倫理」の項目が取り 上げられている点は大変意義 深いと思う。学生にとっては、 その目的や真意をただちに理 解することは難しいかもしれな いが、その後の企業活動の中 で必ず生きてくる内容だと思 う。 賛同いただきありがとうござま す。JABEEなど専門教育認定 でも技術者倫理は必須の項目 となっています。 17/20 CE コンピュータエンジニアリング (CE: computer engineerning) CE-SWE ソフトウェア工学 CE-SWE0 歴史と概要 CE-SWE1 ソフトウェアプロセス CE-SWE2 ソフトウェアの要求と仕様 CE-SWE3 ソフトウェアの設計 CE-SWE4 ソフトウェアのテストと検証 CE-SWE5 ソフトウェアの保守 CE-SWE6 ソフトウェア開発・保守ツールと環境 CE-SWE7 ソフトウェアプロジェクト管理 CE-SWE8 言語翻訳 CE-SWE9 ソフトウェアのフォールトトレランス CE-SWE10 ソフトウェアの構成管理 CE-SWE11 ソフトウェアの標準化 コア 変更 16 1 2 2 2 2 2 2 3 - C委員 変更 F委員 ・ システム開発スキル向上の ためのカリキュラムに従来より も多くの時間を割り当てるべき と考える。 G委員 スキル向上には，実習・演 習が重要です。BOKの上 に，具体的な教育手段・教 育方法を組み合わせること が必要となります。J07普及 活動の中で取り組んでいく べき課題だと認識しておりま す。 + CE-VLS CE-DSC CE-DSC0 CE-DSC1 CE-DSC2 CE-DSC3 CE-DSC4 CE-DSC5 CE-DSC6 VLSIの設計および製造 離散数学 歴史と概要 関数、関係、集合 数え上げの基礎 グラフとツリー 帰納法 推論 ファジー集合 8 23 1 6 4 4 2 6 - CE-PRS0 CE-PRS1 CE-PRS2 CE-PRS3 CE-PRS4 CE-PRS5 CE-PRS6 CE-PRS7 CE-PRS8 CE-PRS9 CE-PRS10 CE-PRS11 確率・統計 歴史と概要 離散確率 連続確率 期待値 標本分布 推定 確率過程 仮説検定 相関関係と回帰 待ち行列理論 状態遷移モデルとマルコフチェーン モンテカルロ法 15 1 4 4 2 2 2 - CE-PRS 数学系は、全領域共通基礎知 識として、別分類としたほうが 良いのでは。 その分野の基礎は全領域共 通であっても各分野で再掲す ることとしています。 数学系は、全領域共通基礎知 識として、別分類としたほうが 良いのでは。 その分野の基礎は全領域共 通であっても各分野で再掲す ることとしています。 18/20 IT J０７（中間報告）-BOKに対するコメントおよびその対応 インフォメーションテクノロジ (IT: information technology) ITF IT基礎 ITF1 ITの一般的なテーマ ITF2 組織の問題 ITF3 ITの歴史 ITF4 IT分野（学科)とそれに関係ある分野(学科) ITF5 応用領域 ITF6 IT分野における数学と統計学の活用 HCI IAS IM IPT NET * ＋：項目・コアの増大（追加） −：項目・コアの削減（削除) コア コア 変更* 変更* 変更* A委員 C委員 F委員 H委員 33 28 -5 ITは、先端的な情報技術を応 ・ 実践的なスキル向上に 時間数の増減については，モデル 17 17 用した即実現可能なビジネス ウェートを置くことは大いに賛 コアカリキュラムとしては基礎 カリキュラムで必要と思われる授業 6 6 モデルの提案を行うことを目 成だが、それと共に高等教育 やアーキテクチャは最小限に 時間数を増やしています。IT基礎に とどめています。 3 3 指す。卒業後も毎年開発され 機関ならではの基礎理論領 ついてはモチベーションや社会にお 3 3 る新技術を吸収し提案し続け 域、ハードウェアアーキテク ける情報の役割などを説明する必 2 2 ることを目的として、在学中 チャ領域等のカリキュラムも必 要から，時間数を考えています。 2 2 は、過去のITを広く基礎から 要ではないか。 + 理解する力を養うべきと考え 20 15 -5 る。 23 23 ※エリア毎のバランスのみ考 34 28 -6 慮し、増やすべきエリア、減ら 24 28 +4 すべきエリアに関する意見を 20 24 +4 数値で表記した。 IT技術者には、ネットワーク管 3 3 理の知識も必須であると考え 現在の情報システムでは人 8 8 る。 間中心設計やユーザインタ ネットワーク管理については， 6 6 フェース、ユーザビリティテス 情報保証(IAS)とセキュリティ， 2 2 トなどが重要をなってきてい およびシステム管理とメンテナ 1 1 ることから，時間数を検討し ンス(SA)に含まれています。 ＋ ています。 NET1 NET2 NET3 NET4 NET5 NET6 ヒューマンコンピュータインタラクション 情報保証と情報セキュリティ 情報管理 技術を統合するためのプログラミング ネットワーク ネットワークの基礎 ルーティングとスイッチング 物理層 セキュリティ アプリケーション分野 ネットワーク管理 PF1 PF2 PF3 PF4 PF5 PF6 プログラミング基礎 基本データ構造 プログラミングの基本的構成要素 オブジェクト指向プログラミング アルゴリズムと問題解決 イベント駆動プログラミング 再帰 38 10 9 9 6 3 1 38 10 9 9 6 3 1 プラットフォーム技術 オペレーティングシステム アーキテクチャと機構 コンピュータインフラストラクチャ デプロイメントソフトウェア ファームウェア ハードウェア 14 10 3 1 20 10 3 1 6 PT1 PT2 PT3 PT4 PT5 PT6 システム管理とメンテナンス オペレーティングシステムの導入と運用 アプリケーションの導入と運用 管理作業 管理分野 15 4 3 2 2 4 SA1 SA2 SA3 SA4 PF PT SA - モデルカリキュラムでは総合 演習として時間数を確保して います。 モデルカリキュラムでは総 合演習として時間数を確保 しています。 11 4 3 2 2 オペレーティングシステムに － ついては，情報分野の基礎 の一つとして学んでおく必要 があると考えています。また， 仕組みをある程度理解してお かないと十分なシステム設計 や管理が行えないと考えてい ます。逆にコアとして大幅に 増やすよりは管理と運用に時 間を割いた方がよいと考えて います。 コンポーネント指向プログラミ ングの方が適していると考え る。 コンポーネント指向プログラ ミングはIPTで扱います。ここ では情報系学科としての基 礎のプログラミングと考えて います。 ここでは情報家学科として基 礎のプログラミングと考えて います。プログラム作成を実 務で実際に行わないとして も，この程度の知識は学習し ておく必要があると考えてい ます。 ゴールとなる資格・職種を考え ると、プログラミングの基礎に こんなに時間をかける必要は ない。むしろ、情報システム全 体の設計に役立つ教育をす べきである。つまり、個々のソ フトウェアの設計ではなく、情 報システム全体の設計こそが ITBOKにとって重要なのでは ないか。 オペレーティングシステムは、 「SA１：オペレーティングシステ ムの導入と運用 」を理解でき る程度で良いと考える。 運用マニュアル等の作成が求 められるため、ドキュメンテー ション技術を入れたい（入れる 場所はここでないかもしれな いが） ご指摘のとおりドキュメンテー ションは重要であると考えてい ます。カリキュラムの総合演習 科目で設計書などのドキュメン ト作成を行わせる内容が盛り 込まれています。 19/20 IT * ＋：項目・コアの増大（追加） −：項目・コアの削減（削除) インフォメーションテクノロジ (IT: information technology) SIA システムインテグレーションとアーキテクチャ SIA1 要求仕様 SIA2 調達／手配 SIA3 インテグレーション SIA4 プロジェクト管理 SIA5 テストと品質保証（QA） SIA6 組織の特性 SIA7 アーキテクチャ コア コア 変更* 21 20 -1 6 6 4 4 3 3 3 3 3 3 1 1 1 1 A委員 変更* ＋ 変更* C委員 F委員 IT技術者には、特に段取り力 ・ ビジネスモデルを用いた講 が求められる。リスク管理を含 義時間も確保すべきと考え め、プロジェクト管理に力を入 る。 れたい。 プロジェクト管理やビジネスモ デルなどは重要と考えていま す。BOKには含めておりません が，モデルカリキュラムでは総 合演習で扱うようにしていま す。 + ビジネスモデルの授業・演習 は重要と考えていますが， BOKのコア(必修)に含めるの ではなく，各学科が独自に取 り入れることが推奨されるも のだと考えています。 H委員 アーキテクチャに割り当てられ ている時間が少なくないか？ （1時間でCRM、 ERPの主要な 機能を教え、さらにEAを教え るのは無理） BOKコアはあくまで最低限履修 すべきものとして作られていま すので，CRMやERPなどは学 科独自で取り入れることが望ま しいと考えております。このた め，システムインテグレーショ ンなどの授業科目や発展学習 に含めてあります。 20/20