# a1-group4 議事録 27.Oct.2023
参加者 : 葛原、津田、平川、山川、平山(記)
講師 : 菊地先生(後半)
演習時刻 : 18:20-21:30

## 次回までのアクション

1. 平山さんが名刺抽出でドメイン分析を進めてくださったので、それを確認する。
1. イベントストーミングに付箋を追加する(内容に対する疑問、イベントの追加 or 削除、変更点の可能性などのメモ)
1. もしも追加で作業する必要があれば、作業可能な日の候補を11月中から3日程度、列挙する(slack上でやりとりし、日程を1つ以上確保)

## 次回予定

- 日程 : 11/2(木) 18:20~21:30
- 議題 :
-
-
-

## 議題

### 1. イベントストーミング予習

### 2. 変更容易性向上の工夫･手法の検討
#### 向上の工夫の検討
- ◯ドメイン分析
- ◯再利用演習のVariation point,Variantを活用
- Variation pointを作っておいて、variantで色々なパターンに対応する
- 仕様変更されそうなところを、Variation pointにしておく
- マイクロサービスアーキテクチャと相性良さそう
- Variation pointをMSAのコンテナに対応づける
- ◯ADD
- ユーティリティツリーで変更容易性のところに、仕様変更が想定されるものを挙げておき、評価する
- △ デザインパターンを使う
- ☓ モデル駆動開発(MDD)
- ☓ モデル検査(形式仕様)
-

#### 評価手法の検討
- 過去のポスターを確認し、SQuaREというのがあった
- https://www.topse.jp/images/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E5%AE%9F%E8%B7%B5%E6%BC%94%E7%BF%92%E3%83%9D%E3%82%B9%E3%82%BF%E3%83%BC_2019A1.pdf
- アーキテクチャ評価、再利用演習からキーワード拾う
- ATAM
- 変更容易性にいくつか挙げておいて、設計後に何個対応できたかを評価指標にする
- MSAだからできた、など述べられればOK
- 変更容易性を品質特性にして、MSAで工夫した点を書いて評価する
- 過去で一番評価できていたのは、実装したグループ(先生より)
- 実施にシステム壊して、動いている
- 品質特性の観点(Webで検索すれば見つかる)(先生より)
- システムぶっ壊したときに、全部壊れるのか、一部でとどまるのか(可用性)
- MSAは変更容易性が高いと言われている(先生より)
- 実際に導入してみて、メリット・デメリットがある
- コストがかかるとか
- MSAに不適なサービス(リリース後一切変えないシステムなど)に導入したら、コストだけかかった
- まずは分析･設計してみる(先生より)
- 今後、仕様変更が入る
- 仕様変更に備えて、前もって設計を工夫してもよい
- それで実際どうだったか、もし簡単に変更できたのなら、なぜうまくいったのか議論してほしい
- プロセス評価の一般的手法について質問
- MSAはアジャイルと親和性が高い
- ウォータフォールは、要件定義しっかりしないと後で見落としがあると、膨大な工数が発生する
- MSAは、変更箇所、影響範囲が少ない
- MSAのメリット･デメリット

### 3. ドメイン分析
- イベントストーミングか、一般的な分析手法か
- イベントストーミングは、ドメイン分析知らない人でも導入しやすそう
- イメージしやすそう
- 新しいものにチャレンジしてみたい!
- イベントストーミング実践
- Webのテンプレート活用
- クラス図のパラメータに相当する部分は、どのタイミングで入れる?
- シーケンス図を作ってみて、そのドメイン分割で動く?などは確認してほしい
- 外部システムとの連携が必要な箇所は書き出しておく
- あまり外部システムがどう動くかとか、深みにはまらないようにする
- 迷ったときは顧客役が決める(平山)
- イベントストーミングは、Step2まで終わった

### 4. 今後
ちょっと遅れ気味･別日で追加開催を検討する
Todo
来週木曜までに、11月中に希望する日をSlackに書いておく
平山がやった名詞抽出･境界わけをmiroに貼ったので確認してみる
変更点や疑問点があれば、miro上にPink付箋で貼っておく
困ったこと･解決するためにどう工夫したのかをメモしておく(発表時に助かる)

### 5.

### 6. メンバー所感メモ

#### 葛原

#### 津田
slack上で @ChatGPT for A1 にメンションするとchat gptから応答を得られる。
1ポストごとにお金がかかるが、金額上限が設定されているため、とりあえず自由に使ってよいとのこと。
早速晩ごはんの献立を考えてもらったが、豪華すぎてつくるのが大変そうで笑顔になった(学習したデータのうちにこんな晩御飯があったのかなと想像して)。

イベントストーミングで、イベントを抽出する粒度?に悩んだ。
誰かが要求、応答するのがイベントになると考え進めたが後のコマンドを追加する段階で考えれば良いことだったように思う。

時間の使い方が上手くなく、工程遅延している。
今日のやることは見えているので、何時までに何を完了するか目標を決めて取り掛かるようにしたい。
(21:30までに進捗状況、次回までのtodo、次回の実施内容の確認までしたい。)

遅延について、今後設計でまた遅延することが考えられる。
中間発表までのコンティンジェンシーとして、実装工程を中間発表以降にずらすことを挙げる。
ずらした場合、中間発表までに設計工程を1日(2コマ分)増やすことができる。
また、ずらした実装工程は仕様変更前の設計に基づいた実装、仕様変更後の実装の2フェーズに分けて実施する。
中間発表では実装について話すことができないが、最終発表では仕様変更前後の影響について評価考察が可能である。

#### 平川

#### 平山

#### 山川

# 議事録テンプレに直したもの
<相談した項目>

変更容易性向上の工夫の検討
･ドメイン分析の実施(必須)
･再利用演習のVariation point,Variantを活用(仕様変更されそうなところを、Variation pointにしておく)→取り入れる
･ADD(ユーティリティツリーで変更容易性のところに、仕様変更が想定されるものを挙げておき、評価する)→取り入れる
･デザインパターンを使う→検討
･モデル駆動開発(MDD)→取り入れない
･モデル検査(形式仕様)→取り入れない

変更容易性の評価手法の検討
･過去のポスターを確認し、SQuaREというのがあった
https://www.topse.jp/images/ソフトウェア開発実践演習ポスター_2019A1.pdf
･アーキテクチャ評価、再利用演習からキーワード拾う
･ATAMを使う
･変更容易性にいくつか挙げておいて、設計後に何個対応できたかを評価指標にする
･変更容易性を品質特性にして、MSAで工夫した点を書いて評価する
･過去で一番評価できていたのは、実装したグループ。実施にシステム壊して確認(先生より)
･品質特性の観点(Webで検索すれば見つかる)(先生より)
･システム壊したときに、全部壊れるのか、一部でとどまるのか(可用性の観点)

ドメイン分析
･イベントストーミングか、一般的な分析手法か→イベントストーミングを使う
･イベントストーミングは、ドメイン分析知らない人でも導入しやすそう
･新しいものにチャレンジしてみたい!
･クラス図のパラメータに相当する部分は、どのタイミングで入れる?
･迷ったときは顧客役が決める(平山)
･イベントストーミングは、Step2まで終わった

<指示された事項>
･シーケンス図を作ってみて、そのドメイン分割で動く?などは確認してほしい
･仕様変更を想定して設計してもよい。それで実際どうだったか、もし簡単に変更できたのなら、なぜうまくいったのか議論してほしい
･外部システムとの連携が必要な箇所は書き出しておく
･あまり外部システムがどう動くかとか、深みにはまらないようにする
･それで実際どうだったか、もし簡単に変更できたのなら、なぜうまくいったのか議論してほしい
･議事録には、困ったこと･解決するためにどう工夫したのかをメモしておく(発表時に助かる)

<次回のミーティングまでに取り組む項目>
･平山さんが名刺抽出でドメイン分析を進めてくださったので、それを確認する。
･イベントストーミングに付箋を追加する(内容に対する疑問、イベントの追加 or 削除、変更点の可能性などのメモ)
･もしも追加で作業する必要があれば、作業可能な日の候補を11月中から3日程度、列挙する(slack上でやりとりし、日程を1つ以上確保)

<次回の打合せ予定>
日時 : 11/2(木) 18:20-21:30
場所 : Zoom
出席者 : 全員参加予定