Recommended
More Related Content
What's hot
What's hot (20)
Similar to ソフトウェア工学2023 02 上流工程
Similar to ソフトウェア工学2023 02 上流工程 (20)
More from Toru Tamaki
More from Toru Tamaki (20)
Recently uploaded
Recently uploaded (11)
ソフトウェア工学2023 02 上流工程
- 2. ライフサイクル：上流工程
- 3. システム開発のライフサイクル nライフサイクル＝始まりから終わりまで • 要求分析，要件定義 • 顧客の望むこと（要求）を仕様（要件）に落とし込む • 外部設計 • システムの使い方と構成を仕様にする • 内部設計 • 実装の方針を決定する • プログラミング • 実際の開発を行う • テスト • 品質を保証するための確認を行う • 運用・保守 • 納品後のメンテナンスを続ける 上流工程 下流工程
- 4. ウォーターフォールモデル nライフサイクルを滝に見立て た開発モデル • 最初の方が上流工程 • 後のほうが下流工程 n一つの工程での成果物を次の 工程へ引き継ぐ • 例：外部設計は，要件定義書を 引き継いでから開始 要件定義 外部設計 内部設計 実装 テスト 運用・保 守 要件定義書 外部設計書 内部設計書 プログラム 上 流 工 程 下 流 工 程 成果物 システム
- 5. ウォーターフォールモデル nメリット • 順番が明確 • 進捗管理が容易 • 分担も明確 • 長年利用されている nデメリット • 実際にはやり直しもある • 遅れが生じると下流にしわ寄せ がいく • システムが納品されるまでクラ イアントはシステムを観ること ができない 要件定義 外部設計 内部設計 実装 テスト 運用・保 守 要件定義書 外部設計書 内部設計書 プログラム 上 流 工 程 下 流 工 程 システム
- 6. 要件定義
- 7. 要件定義 n要件定義の工程 • 要求の導出と獲得（要求獲得） • 要求の分析と記述（要求分析） • 要求の仕様化（要件定義） • 要求（要件）の妥当性の検証と評価 • 要求（要件）の計画と管理 n用語 • 要求と要件の違いは曖昧 • ここでは • 要求：ユーザーが持つ要望や理想など • 要件：定義され仕様化された要求項目 https://pixabay.com/ja/vectors/チェックリスト-チェック-考える-1266989/ Pixabay License
- 8. 要求分析 n要求分析とは • 顧客の要求を分析・獲得し，仕様化すること • 顧客の業務内容や業界知識を理解しなけれ ばならない • 顧客との意思疎通のための打ち合わせが必須 n要求分析の重要性 • 思っていたのと違う，と完成してからクライ アントに言われても困る • クライアントに検収してもらえない＝料金 が支払われない • ベンダーから納品されても使えない＝業務 に支障が出る https://pixabay.com/ja/illustrations/怒り-実業家-対立-苦情-3233158/ Pixabay License
- 9. 要求分析の体系 nREBOK • 要求工学知識体系（Requirements Engineering Body Of Knowledge） • 参考 • 要求工学知識体系 第1版,一般社団法人情 報サービス産業協会 REBOK企画WG, 2011 • 要求工学知識体系(REBOK)概説, IPA, 2012 • ユーザのための要件定義ガイド第2版 要 件定義を成功に導く128の勘どころ, IPA, 2019
- 10. 要求分析の基本要素 n問題 • 発生している事実 nニーズ • 顧客や市場が持つ希望や要望 n課題 • 解決するべきテーマ n目的 • 達成するべき事柄 n手段 • 目的を達成するための方法 ユーザのための要件定義ガイド第2版 要件定義 を成功に導く128の勘どころ, IPA, 2019
- 11. 要求の分類 nビジネス的な要求 • 経営者としてそのシステム導入に どのようなビジネス的なメリット を期待するのか nシステムに対する要求 • システム導入によってどのように 業務が改善されるのか nソフトウェアの使い勝手に対す る要求 • そのシステムの利用者が効率的に 使えるのか 要求工学知識体系(REBOK)概説, IPA, 2012
- 12. 要求の異なるレベル nビジネス的な要求 • 経営者としてそのシステム導入に どのようなビジネス的なメリット を期待するのか nシステムに対する要求 • システム導入によってどのように 業務が改善されるのか nソフトウェアの使い勝手に対す る要求 • そのシステムの利用者が効率的に 使えるのか ユーザのための要件定義ガイド第2版 要件定義 を成功に導く128の勘どころ, IPA, 2019
- 13. マーケティングにおける要求獲得の困難さ n“If I had asked people what they wanted, they would have said faster horses.” Henry Ford • 「もし顧客に何が欲しいのかを訪ねていたら，彼らはもっ と速い馬が欲しいと答えただろう」ヘンリー・フォード • 自動車の発明以前に自動車を欲しがる人はいない n“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do.” Steve Jobs • 「顧客が望むものを与えよ」と言う人がいるが，私のアプ ローチは違う．我々の仕事は，顧客が何が欲しくなるのか を，顧客が欲しくなるよりも前に見つけ出すことだ」ス ティーブ・ジョブズ • iPhone以前にiPhoneを欲しがる人はいない https://commons.wikimedia.org/wiki/Fi le:Steve_Jobs_Headshot_2010.JPG CC BY-SA 3.0 https://commons.wikimedia.org/wiki/File:Ford_1921.jpg CC0
- 14. マーケティングにおける要求獲得の困難さ Why Does Apple Create S Model For IPhone? by Elizabeth Kartini, September 5, 2015 https://www.technobezz.com/why-does-apple-create-s-model-for-iphone/
- 15. 要求獲得の困難さ n複雑なステークホルダー（関係者，利害関与者） • エンドユーザー，システム担当者，導入する顧客，取引先など • バラバラの要求．誰の要求を取り入れるべきか n相互理解 • それぞれのドメイン（専門分野）の知識と専門用語で説明 • 対象となる業務やその分野の理解が必須．背景知識や関連知識も必要 n環境の変化 • ビジネス的要素（他社の動向），経済状況（好景気，不況），政治的要素（社 長の交代）など
- 19. 要求分析の重要性 n要求が原因でプロジェクトは失敗する • (1) 要求が確定しないまま設計を開始し途中で頓挫 • (2) システム完成するも要求齟齬によりユーザが訴訟 • (3) ユーザのトップ交代で、要求変更により開発中断 • (4) ユーザの納得する要件定義が完成せず頓挫 • (5) 要求齟齬によりベンダは再開発で大赤字 要求アナリストの確立と育成~要求工学知識体系(REBOK)に基づく要求工学を主 導する人材像とその育成~, 平成 24 年度 技術委員会 ソフトウェアエンジニアリ ング部会 REBOK WG レポート, 2013
- 21. 要求獲得の技法 nインタビューによる聞き取り調査 • 構造化インタビュー • 事前に決めた質問項目を聞き取る • 非構造化インタビュー • テーマだけを設定してフリートーク • 半構造化インタビュー • 上記の組み合わせ https://pixabay.com/ja/photos/営業会議-会議-ビジネス-5395567/ Pixabay License
- 22. 要求獲得の技法 nステークホルダーの整理 • どの立場の人間の要求なのか • 現場を知らない上の人間の要求か • 経営を知らない現場の要求か nドメイン制約の明確化 • その業界や企業ならではの制約事項 • 銀行は9時開店，15時閉店，オンライン振り込みは24時間 • 不動産業界は水曜定休，歯医者は木曜定休，床屋は月火定休 要求工学知識体系(REBOK)概説, IPA, 2012
- 23. 要求獲得の技法 nシナリオの利用 • 実際の業務の運用状況を想定する＝シナ リオ • 具体的なストーリーに限定する • ユースケース図を用いる • シナリオを可視化・図解するモデリン グ技法（UML） • 5W1Hを明確にしたユーザーの言葉で表現 する
- 24. 要求獲得の技法 nリッチピクチャ • 要求を整理・可視化した もの • 各ステークホルダー の課題や要求 • ステークホルダー間 の対立関係 • 要求間の関係 ユーザのための要件定義ガイド第2版 要件定 義を成功に導く128の勘どころ, IPA, 2019 例：お見合いパーティ運営システム
- 25. 要求獲得の技法 n現場視察・実地調査 • ベンダがクライアントの業務現場に出向いて調査する • ドメイン知識を習得し，業務の理解と問題点の抽出を行う • 方法 • 業務フロー追跡型：業務に沿って観察 • 定点観測型：ある設定した時刻に観察 • 短期体験型：実際に業務を行う 要求工学知識体系(REBOK)概説, IPA, 2012
- 26. 要求獲得・分析 n要求獲得 • 現状の把握 • 問題の抽出 • ゴールの抽出 • 手段の抽出 • ステークホルダーの特定 n要求分析 • 要求の整理 • 要求の具体化 • 要求の優先順位付け n要件定義 • 要求の文書化＝要件 n要件検証 • クライアントの確認と評価 n要件管理 • 要件へのID割り振り • 追加・変更される要件のトレーサ ビリティの確立
- 27. 要件定義書 n獲得した要求を，仕様（要件）としてまとめる • この内容を満たすシステムが顧客に納品される n要件定義書が満たすべき特性 • 妥当，曖昧でない，完全，一貫している，重要度と安定性がランク付けされて いる，検証可能，変更可能，追跡可能 • ユーザの課題を解決するかどうか確認 • モレやダブリがないかどうか確認 • 要件にIDを付与して変更や修正を管理 • 参考 • ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どこ ろ,独立行政法人情報処理推進機構（IPA）社会基盤センター, 2019 • IEEE 380-1998 IEEE Recommended Practice for Software Requirements Specifications
- 28. 要件の種別：機能と非機能 n機能要件：対象業務についてシ ステムが持つべき機能や挙動 n非機能要件：機能面以外の品質 や性能 • ガイドライン • ISO9126：ソフトウェア品質の 評価に関する規格 • 非機能要求仕様定義ガイドライ ン, 社団法人 日本情報システ ム・ユーザー協会, 2008 • 非機能要求グレード2018, IPA, 2018 IPA 社会基盤センター, IoT製品／ITシステムの安全性・信頼性の確保, システム構築の上流工程強化（非 機能要求グレード）, 2019
- 29. 要件の種別：機能と非機能 n機能要件：対象業務についてシステムが持つべき機能や挙動 • 「このシステムは＊＊＊ができる」などの顧客が望む機能 • 要求獲得・分析の工程で抽出されるもの • しかし，それだけでは「できるけどとてつもなく遅い」ということになりかね ない n非機能要件：機能面以外の品質や性能 • システムを運用するために必要な性能 • クライアントの要求には含まれない，もしくはクライアントは気づかない • 速度，メモリ使用量，セキュリテイ，拡張性，保守性など • 「＊＊＊を1分以内で」「仕様メモリは1GB以下」など • 分類：可用性，性能・拡張性，保守・運用性，移植性，セキュリティ，使 用性，効率性，保守性，移植性など
- 31. 要件定義書の実物 n自治体が入札のために公開 • 総務省, 別添1 パッケージソフトに対する 要求仕様書(サンプル), 自治体クラウ ド開発実証事業 調査研究報告書, 2011 • 札幌市, 文書管理システム再構築に係る設計・開発業務 要件定義書, 2019 • 農林水産省 動物検疫所, 動物検疫支援システム オンライン連携機能構築 シス テム要件定義書, 第1.1版, 2016 • 神戸市, ネットモニターシステム 開発業務委託事業者の公募, 2019 • 経済産業省, 令和2年度補正経済産業省デジタルプラットフォーム構築事業（補 助金申請システムの機能開発等事業）」に係る委託先の公募について, 2020
- 33. 要件定義は終わらない n要求を集める作業をユーザーが妨げる可能性 • ユーザーは自らが何を欲しているか理解していないことがある。 • ユーザーは要求仕様書に関わりたがらないことがある。 • ユーザーは既にスケジュールと費用が確定した状態で新たな要求を出してくる。 • ユーザーとの対話には時間がかかる。 • ユーザーはレビューに参加したがらないか、参加できないことがある。 • ユーザーは技術に疎い。 • ユーザーは開発工程を理解しない。 n要求仕様は開発が開始されてからも変更され続ける Wikipedia, 要求分析「関係者の問題点」
- 34. サイクルを伴う開発モデル nプロトタイプを用意 • 作成して見せてフィードバック • 水平プロトタイプ：多くの機能を実現（ただしすべてダミー） • 垂直プロトタイプ：少数の機能を実現（しかし動作する） nプロトタイピングモデル • 各工程でプロトタイプを作成 • 顧客にフィードバックし，要求を満たしているのかチェック • ユーザーインターフェースの確認に適している nスパイラルモデル • 4つのフェーズを繰り返す • 目的と対策の決定，対策とリスクの評価，開発と検証，次フェーズの計画 • プロトタイピングモデルを体系的にウォーターフォールモデルに組み合わせる
- 35. DX（デジタルトランスフォーメーション） nいろいろな定義がある • デジタルテクノロジーを使用して、 ビジネスプロセス・文化・顧客体 験を新たに創造（あるいは既存の それを改良）して、変わり続ける ビジネスや市場の要求を満たすプ ロセス (wikipedia) nつまり「ITシステムで継続的に 変えていく」 • トランスフォーメーションとは、 その組織の文化が変わることあり、 ビジネスの在り方を含めた経営の 問題であり、デジタルはその経営 変革の重要なリソースでしかない。 （DX白書2023, IPA, 2023） nIT & 改革 • どうやって変えるか（how） • 情報系・ITの知識が必要 • 何を変えるか（what） • 要求獲得のスキルが必要 DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
- 36. 様々な業種で今後DXが必要になる DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html 今は不要と言っていても．．． 確実にDXに動いている
- 37. 様々な業種で今後DXが必要になる，はず nDX人材は大幅不足 • どの業界でも引っ張りだこ nただし • DX人材育成の予算はない • DX人材を適切に評価できない • そもそも役員がITをわかってない DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
- 38. 外部設計
- 39. 設計 n設計：外部設計，内部設計 • 定義された要件からプログラム仕様を作り出す工程 n外部設計（基本設計） • 各要件をどのようなシステムとして実現するかを設計 • システム外部とのインタフェースを定義 • 画面，操作，出力などユーザーインターフェース，セキュリティ，運用， スケジュール，コスト，保守，使い方教育など • システムの全体構成を決定 • クラサバかスタンドアローンか • SaaSかPaaSかIaaSか • オンプレミスか，クラウドか • スクラッチ開発かSIか • 外部設計書，システム仕様書を成果物として作成
- 40. 現代社会：ほぼシステム外部 nやり取りにはAPI を利用 nクラウドにはWeb API • 楽天API • Yahoo API • Amazon API • Google Cloud API • 【2023年最新】作りたいアプリ 別API一覧を全紹介〜随時更新〜 n開発にはSDKを利 用 社内サーバ 社内DB 本社システム 入退室 システム クラウド 他社 システム 工場システム 社内PC 開発する システム エンドユーザー API API API API API SDK SDK SDK SDK
- 41. 大学における各種システム Moodle logo Moodle.org GPL https://apps.apple.com/jp/app /nitechピロリン /id1449703640 Nitechピロリン https://apps.apple.com/jp/app /nitechbb-学生掲示板アプリ /id1525858812 NitechBB-学生掲示板アプリ wholo Youngsnipper234 - Own work CC BY-SA 4.0 Eduroam Géant - Géant CC BY-SA 4.0 掲示板 システム 出席管理 システム 授業支援 システム メール・オフィス クラウドシステム 学外者 ネットワーク 接続システム 経費管理 システム 給与支払 システム 図書館管理 システム
- 42. ユーザーが関わる部分 nUI設計 • UI：ユーザーインターフェース （User Interaction） • ユーザー操作による入力，ユーザー への出力 • アプリ画面のデザイン，表示方 法の設計，など nUX設計 • UX：ユーザーエクスペリエンス （User Experience） • UIによってユーザーが得る体験 • 楽に操作できる，覚えやすい， 見やすい，など主観的な評価 https://pixabay.com/photos/ux-design-webdesign-app-mobile-787980/ Pixabay License
- 43. MVC nMVC (Model, View, Controller) • システムをモデル，ビュー，コントロー ラの3要素に分割する • モデル • ユーザー入力に基づき内部を更新 • ビュー • モデルに基づきユーザーへ表示 • コントローラ • ユーザー入力をモデルへ伝達 • メリット： • 内部設計で分業しやすくなる • 保守の分離が明確になる MVC Diagram (Model-View-Controller). Used the following other documents: CPT-FSM- abcd.svg, Human-ooo-base.svg, Emblem-person-blue.svgXinfe, initial work by Deltacen - https://commons.wikimedia.org/wiki/File:ModeleMVC.png CC BY-SA 3.0
- 44. スタンドアローンかクラサバか nクライアントサーバ • 呼称：クラサバ，C/S • 多数のクライアントマシン • ユーザ固有の処理 • 複数のサーバマシン • 特定の処理 • 明確に機能が分けられたサ ブシステム nスタンドアローン • 一つのPC内で完結 メールサーバ クライアント クライアント クライアント PC ファイルサーバ プリントサーバ サーバサイド フロントエンド
- 45. nファイルを読み込み，処理し，保存 するだけ • ネットワークに依存しない例 • Officeソフト • 画像処理ソフト nただし現在は多くがクラウド • MS Office365 • 保存先がクラウド • ブラウザベース • Adobe Creative Cloud • 保存先がクラウド スタンドアローン OnlyOffice editing suite - online spreadsheet editor (screenshot) Softwaregenius - Own work CC BY-SA 4.0 I logged into hello GNOME under Arch Linux and took a screenshot of the latest version of GIMP, editing the GIMP splash screen Saikobee CC BY-SA 3.0
- 46. サーバと物理サーバ nサーバが物理サーバとは限らない • 「サーバ」は「サーバプロセス」の意味 • Unixではデーモン，Windowsではサービス とも呼ばれる メールサーバ ファイルサーバ プリントサーバ メールサーバ ファイルサーバ プリントサーバ メールサーバ ファイルサーバ プリントサーバ すべてが物理サーバ 物理サーバは1つ そこにサーバプロセスが走る すべてがクラウドの 仮想マシン上のサーバ
- 48. シンクライアント nクライアント側では最低限の処理しかしない • Thin（薄い）Client（端末），略してシンクラ • サーバが集中的に • 処理を行い，端末側に表示する • ストレージを管理し，端末側には保存しない • ゼロクライアント • 一切処理せず表示機能しかないシンクラ nメリット • 大量の端末で同一環境を提供できる • 大企業，官庁，大学など • 端末でデータを保存しない • セキュリティが保てる • どの端末でも同一環境 https://pixabay.com/photos/classroom-computers-education-class-1167524/ Pixabay License
- 49. オンプレかクラウドか nオンプレミス型（on-premise，自社運用） • 自社の施設内で物理サーバを運用 • セキュリティは高い • 初期導入費用が高額 • 故障に備えて冗長化も必要 • ランニングコストもそこそこ • 電気代，消耗品（ファンやケーブル交換） • 導入後のメンテナンスが自前 • 故障，停電，消耗など • 簡単にはスケールアップできない • 最大負荷に耐えられるように最初から高ス ペックで導入 • 通常はリソースが余ってしまう https://pixabay.com/ja/photos/データ-センター-サーバー-286386/ Pixabay License
- 50. オンプレかクラウドか nクラウドサービス型 • 通常はパブリッククラウドを導入 • 専用に構築したもの：プライベートクラウ ド • 融合型：ハイブリッドクラウド • 初期導入費用は低額 • ランニングコストはやや高め • メンテナンスフリー • サービスの可用性，稼働率に依存 • スケーラビリティが高い • アクセスが集中するイベント時にサーバを 増やして負荷を分散する • イベントが終了したらサーバを減らす • 従量制なら使った分だけ料金を支払う https://pixabay.com/ja/illustrations/クラウド-コンピュータ-3406627/ Pixabay License 参考：総務省, クラウド環境構築ガイドブック(案) , 平成 26 年度クラウド等の最先端情報通信技術を活 用した学習・教育システムに関する実証別冊, 2015
- 51. 可用性，稼働率 n稼働率＝使用できる時間 / 総時間 • クラウドの稼働率は99.9%程度 • Amazon • AWS は、毎月の請求期間において、少なくとも 99.9% の月間稼働率で Amazon ECR を利用可能とするように商業上合理的な努力を払います Amazon ECR で 99.9% のサービスレベルアグリーメント (SLA) を発表, 2019/1/16 • Google • Gmail をはじめとするサービスは計画的ダウンタイムを持つことなく、 99.978% の可用性をもって何億ものユーザーに提供されているのです。 Google Cloudヘルプ：信頼性 • オンプレの稼働率はもっと低い • 可用性（サーバやストレージの冗長化）と保守コストに依存する • 1日停電するだけで稼働率は (1 - 1/365) * 100 = 99.72%
- 54. 各種クラウドサービス：XaaS nXaaS (X as a Service), EaaS (Everything as a Service) • インターネットを通じて提供されるサービスの総称 • SaaS (Software as a Service) • PaaS (Platform as a Service) • IaaS (Infrastructure as a Service) データ アプリケーション ミドルウェア/仮想化 OS/ハードウェア データ アプリケーション ミドルウェア/仮想化 データ アプリケーション データ OS/ハードウェア ミドルウェア/仮想化 OS/ハードウェア アプリケーション ミドルウェア / OS OS/ハードウェア オンプレミス IaaS PaaS SaaS ユーザ クラウド 「◯aaS」に何があるか知っていますか？「◯aaS」11種まとめ https://career.levtech.jp/guide/knowhow/article/389/
- 55. SaaS nSaaS (Software as a Service) • Gmail，Google Workspace， Microsoft365など • 一般人が「クラウド」と言ったらこれ • アプリをオンラインで提供．データは自前（ユーザが準備） • 料金体系 • 無料，または • 複数段階のサブスクリプション（定額制） データ アプリケーション ミドルウェア / OS OS/ハードウェア SaaS
- 57. PaaS nPaaS (Platform as a Service) • Heroku，render，MS Azure，Google App Engineなど • 実行環境（ミドルウェア）を提供 • アプリは自前（アプリの実行環境はPaaS依存） • 一般人が「webアプリ」と言ったらだいたいこれ • 料金体系 • 従量制がほとんど データ アプリケーション ミドルウェア/仮想化 OS/ハードウェア PaaS
- 58. PaaS AWS E2C https://aws.amazon.com/jp/ec2/features/ Heroku https://jp.heroku.com Google App Engine https://cloud.google.com/appengine/docs Microsoft Azure https://portal.azure.com/
- 59. IaaS nIaaS (Infrastructure as a Service) • Amazon EC2やGoogle Compute Engine，さくらサー バなど • マシンとOSをオンラインで提供．コンテナやミドル ウェアは自前 • 仮想マシン（Virtual Machine, VM）とも呼ばれる • 専用サーバ：物理サーバ1台を1つのVMに割当 • 共用サーバ，仮想専用サーバ（Virtual Private Server, VPS）：物理サーバ1台を複数のVMで共有 • 料金体系 • 従量制と定額制がある データ アプリケーション ミドルウェア/仮想化 OS/ハードウェア IaaS
- 60. IaaS, VPS AWS E2C https://aws.amazon.com/jp/ec2/features/ Microsoft Azure Virtual Machines https://azure.microsoft.com/ja-jp/free/ Google Compute Engine https://cloud.google.com/compute さくらインターネット https://www.sakura.ad.jp
- 63. 日本企業でクラウド利用はまだまだ nクラウド開発は日本 はまだまだ遅れている nSaaSだけは比較的利 用されている • メールやワードなど • 全社でも事業部でも DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx- 2023.html
- 64. 開発の種類 n スクラッチ開発 • フルスクラッチとも呼ばれる • 対象業務を実現するシステムを，パッケージを利用せずに新たに開発 • 自由度が高く，応えられる要求の範囲は広い • 費用と時間がかかる n カスタマイズ開発 • 既存のパッケージソフトを組み合わせて（カスタマイズして）利用 • コストは削減，開発期間は短縮される • 自由度は低く要求に応えられる範囲は狭まる n パッケージソフトの利用 • 既存のパッケージソフトをそのまま利用 • システム化対象に合致していれば低コストで実現可能
- 65. スクラッチ開発が大半 nスクラッチ開発が9割 で首位 n次点は再開発 • 既存システムの機能を そのままリプレース nパッケージ利用はかな り少数派 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html スクラッチ開発
- 66. 開発かインテグレーションか nシステムインテグレーション（SI） • 既存製品を組み合わせて利用してシステムを構築 • SI専門事業者：SIer（えすあいやー ，SI屋） • 分類 • メーカー系：PCメーカーなどから独立 • ユーザー系：自社開発部門が独立 • 独立系：SI専門として開始 • 方式 • シングルベンダ方式：系列企業が自社グループ製品を利用 • マルチベンダ方式：様々な製品を利用
- 67. スクラッチ開発とSIの企業数 SIer スクラッチ開発 DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html
- 71. 課題 n要件が曖昧だったために失敗した身近な例と，その改善策を説明せよ • 店で買ってきた家具が家のサイズに合わず入らなかった • ネットで注文した服を着てみたらイメージと違っていた • 注文住宅を立てたら自分の生活スタイルに合っていないために住みづらい n実社会におけるシステムについて，どのような外部設計になっている のかを推測して説明せよ n自分が普段使っているクラウドサービスをしらべて，SaaSかPaaSか IaaSかを理由をつけて述べよ nまだ使ったことのない（無料の）XaaSを探し，実際に使ってみて， その使い方をまとめよ
- 72. 想定試験問題 • 上流工程に含まれる工程を述べよ • ウォーターフォールモデルとは何か， そのメリットデメリットも述べよ • 要件定義とは何かを述べよ • 要求分析の基本要素を述べよ • 要求獲得が困難である理由を，具体 例を用いて述べよ • ステークホルダーとは何かを述べよ • 要求獲得の技法を2つ以上説明せよ • 機能要件と非機能要件の違いを具体 例を用いて説明せよ • 外部設計とは何かを述べよ • MVCとは何かを述べよ • スタンドアローンとクラサバの違い を述べよ • オンプレとクラウドの利点欠点をそ れぞれ述べよ • XaaSについて説明せよ • システム開発におけるSIとは何かを 述べよ