![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2021-07-15T10:25:05+00:00","","") #author("2021-07-16T04:24:58+00:00","","") [[KobeSpiral2021]] * 第5回講義(7/16) PBLイントロダクション [#d9a74840] - テキスト &attachref(PBL_introduction.pdf); ** 1限：PBLイントロダクション [#w700b48e] - PBL課題の紹介 -- P1：学生健康管理票 Webアプリケーション -- P2：現地訪問型クイズラリーアプリケーション -- P3：市民向け防災ノートのWebアプリ化 - 取り組み課題の決定 -- ファシリテーションを通してコンセンサスを得ること -- ※成果として残しておく事 どのような過程でコンセンサスを得たか コンセンサスの根拠となる意見、考え 食い違った意見、など -- 画像、テキストなど媒体は何でもいいですが、googleドライブに共有してください --- リンクはトップページにあります --- kobespiral2021/2021-07-16 第05回/グループX/ *** 補足資料１：三田市との連携協定に関するプレス発表 [#g8939b6b] - &attachref(【議会提供資料】_さんだ里山スマートシティ「連携協定」.pdf); *** 補足資料２：各PBL担当者からいただいた情報 [#f2b3ec6f] - &attachref(PBL1_神大医学部学生健康管理表.zip); - &attachref(PBL2_三田市クイズラリー.zip); - &attachref(PBL3_三田市防災ノート.zip); ** 2限：要求理解 [#jed91a6a] - 選択した課題について，何が求められているかを理解し，チームで共有する - どのように解決すべきか，アイデアをブレーンストーミングしてもよい - 似たような課題がないか，解決法がないか？ - これから開発するWebアプリで必要となりそうな技術は何か？ - チーム内で意識の共有を行い，共通のビジョンを持つ ** 3限：要件定義 [#i382cfc4] - システムとして何をどこまで作りこむかを決める - 参考：[[大規模ソフトウェア論第2週:http://www27.cs.kobe-u.ac.jp/~masa-n/lecture/tokuronI/week2/index.html]] -- User: tokuron Pass: tokuronI+ -- User: tokuronI Pass: tokuronI+ - システムに作りこむべき機能を洗い出す -- 機能要求 -- 非機能要求 - 優先順位づけ（MUST, SHOULD, MAY, WON'T） - 現段階の情報では決まらない場合は，それを整理しておく -- ヒアリング時に聞いて，すり合わせを行う - 要求仕様書の作成 -- 次回のヒアリング時の材料とする ** 4限：ユースケース分析 [#d08d154c] - システムの大まかなふるまいをスケッチする - 参考：[[大規模ソフトウェア論第3週:http://www27.cs.kobe-u.ac.jp/~masa-n/lecture/tokuronI/week3/index.html]] - 作成するもの -- UI紙芝居 -- ユースケース図 -- ユースケース記述 ** Googleドライブなど [#td95cfdc] - 各チーム，Googleドライブの第5回のフォルダに以下のファイルを作成してください。 -- 議事録(質疑の内容，本日の流れなど) -- 次回ヒアリング用の資料 -- 要件定義ドキュメント -- ユースケース関連(画像、外部リンクでもOK) * 以下，古い内容 [#u56a6fe9] ** Webアプリケーション開発実践演習1（要求獲得と定義・要件定義） [#o710f389] *** 午前：準備 [#da746f57] - 大規模ソフトウェア論の復習 - 午後からに向けた役割分担と内容整理 -- 午後から行うことを想定し，どのような役割が必要か考える --- 例）インタビュアーは何人？記録は？誰が舵をとるのか？時間管理は？ -- それぞれの役割の人が決めるべきことを考える --- 例）どのようなことを聞く必要があるのか，話し合いのルールは？ *** 午後：要求，要件定義実践 [#nd70b0c2] - ストーリーテリングにもとづく問題理解 -- ストーリー・テリング： 要望や想いを具体的な体験をもとにした物語を通して伝える．顧客の問題を共感を通して理解し，本質的なニーズやソフトウェアによる解決策を「WHY」の観点から考える - インタビューにもとづく要求獲得 -- インタビュー： 顧客にインタビューすることにより，システムに求められる顧客の要求を抽出する方法．オープン型インタビューと構造化インタビューを織り交ぜて，継続的に行われる - 要求仕様書の作成 -- システムの目的： システム導入の背景，対象とする業務，現状の課題，システム化の目的，期待される効果 -- システムの概要： 要求するシステムの概要．扱うデータ，処理．こんなことがここまで出来てほしい．簡単な概念図，説明図をつけてもよい -- 要求機能一覧： システムに実現してほしい機能．機能名とその概要・目的を書く． - 要求分析 -- UC記述・UC図 -- クラス図（分析レベル） -- UI紙芝居 - 要件定義書 -- 業務要件 -- 機能要件 -- 非機能要件 - （できれば）実装レベルのクラス図 -- ソフトウェアアーキテクチャとしてはSpringBootを利用したSpring MVC --- これまでの演習で一通りの構造理解と設計思想に触れているため，それなりに出来るはず --- 設計が出来れば，あとは実装TIME - 開発プロセス -- Github flowは最低でも守る --- 活動の可視化（評価）に必要になります． *** 注意事項 [#kbb3b99a] *** 提出物 [#td95cfdc] - 各チーム、第5回のフォルダに以下のファイルを作成してください。 -- 議事録(質疑の内容、本日の流れなど) -- 要求ドキュメント
