ユースケース(ビデオ録画) (Linux-video-devel) - linux-video

橋本です。

On Mon, 27 May 2002 17:14:31 +0900
Takeshi HORIE <false****@mx1*****> さんは書きました:
>堀江です。
>　以上、昨日kenji氏とken氏と話し合った結果です。

 実は、メールの理解で悩んでしまって、何を話したか
 わからなくなってきた気がするのですが、

 1.
  橋本の提案したユースケースは「人間」と「予約DBS」をアクタとしている。
  これ以外に「予約DBS」「録画制御装置(コントローラ？)」
  「録画装置(録画コマンド)」などをアクタとしてユースケースが必要
         => ちゃんと作る
 
 2.
  橋本の提案したユースケースの「番組」および「予約」の定義がきっちり
  されていなくて不明瞭
         => もうちょっと、ユースケースを考える
 
 3.
  橋本の提案したユースケースの「予約修正」などのユースケースが
  きっちり決まっていないので、後々設計時に困る。
         => ちゃんと考える

 4.
  基本的にシステムはシンプルにして、そのシステムの緩い結合で
  システムを構築すべきではないのか？
         => それは、一般的に正しいので、そのようにすべき
 4'.
  「予約DBS」が番組スケジュールから予約を生成する事は、実は
  非常に複雑なことではないか？
  予約DBSは予約を管理するべきではないのか？
         => 予約DBSは予約を扱い、スケジュールから予約生成はUIの仕事？
             => 予約生成は、一つのフレームワークとして提供され
                UIはそれを利用する程度のコストになるべき？

だったきがします。
(まちがっていますか？)

 はんぶん、議事録的ですが、こんなことが話されました。

# 一部、身内のIRCで堀江さんやKenjiさんが話していますが、
# その話の内容を「議事録」っぽいも形でMLに流す必要があるな
# と感じてしまいました。
## 別に「話の内容を整理する必要がない」とは言わないけど
## 「報告書や仕様書」の様にしっかりしすぎているのは、半分困ります。
## MLベースだと、コミュニケーションのキャッチボールが密に行えません。
## (もちろんMLベースが悪いといっているのではなく、
## 直接会って話すよりという意味です)
## プロジェクトなども「コミュニケーションが密に取れること」＝「成功の秘訣」
## らしいので...
## それを考えると「どこが悪いのか」を読んで直わかるように記述する
## 必要があるかと。
## 分量の多いドキュメントは読んでもらえないという定説が（わら

# ちなみに、橋本は日本語も英語も語学力がないです（わら
---
 Ken-ichi HASHIMOTO
 E-Mail ken****@po*****

linux-video

[Linux-video-devel] ユースケース(ビデオ録画)