凪瀬 Blog
Programming SHOT BAR

目次

Blog 利用状況
  • 投稿数 - 260
  • 記事 - 0
  • コメント - 48909
  • トラックバック - 192
ニュース
広告
  • Java開発者募集中
  • 経歴不問
  • 腕に自信のある方
  • 富山市内
  • (株)凪瀬アーキテクツ
アクセサリ
  • あわせて読みたい
凪瀬悠輝(なぎせ ゆうき)
  • Java技術者
  • お茶好き。カクテル好き。
  • 所属は(株)凪瀬アーキテクツ
  • Twitter:@nagise

書庫

日記カテゴリ

 

前回の続きです。

前回は、管理対象となるモノの差分からタスクは生まれ来るのではないかという話でした。
ざっくりとしたクラス図を描いてみたのでご覧ください。

管理対象であることをインターフェースで表現しています。
仕様やコードといったものはその実装という位置づけになっています。インシデントもそうですね。

仕様・テストケース・テストコード・ソースコードは別々に管理されますが、 互いに関連づいた表裏一体のモノというイメージです。
こういった関連した管理対象の同期を行うメカニズムが必要ですね。これは宿題としておきます。

タスクは管理対象に依存する形にしてあります。 実際には管理対象から生成するなどの形態をとるのではないかと思っています。 このあたりは設計をもっとブレイクダウンしていかないと決まらないでしょう。

タスクのほかに休暇などもスケジューリングして管理したいと思います。しかしこれはタスクではないので スケジューリング可能であるというインターフェースを括りだして、その実装としました。

前回出てきた電話応対などの割り込み作業はここでは表現できていません。 スケジューリング不可能だけども実績はとっておきたいという扱いなのでしょうか。 位置づけが決まりませんね。

といったところで次回に続きます。

投稿日時 : 2007年9月7日 10:49
コメント
  • # re: タスク管理システムを考える その3
    シャノン
    Posted @ 2007/09/07 11:15
    設計書の一部の修正、ソースコードの一部の修正、その一部に対する再テストなど、複数のファイルの中の一部分を関連付けることが必要だと思っています。
    ファイルの先頭からの文字数とか行数で管理するとズレるので、XMLみたいなのがいいのかなぁと。
    ただ、ソースコードやExcel、Word、PDF等で作られた設計書をXMLに手動で書き直すなんてやってられないので、何らかの自動変換の仕組みが必要になります。
    また、ソースコードに関しては、言語が変われば構文要素の意味が変わるので、それをいかにして統一的で抽象的なXMLにマップするかという課題もあります。
  • # re: タスク管理システムを考える その3
    凪瀬
    Posted @ 2007/09/07 11:50
    そもそもの前提として、設計書の書式をExcelなどの外部ツールから、DB管理に落としたいというのがあります。
    Excelで仕様を書くのでは限界がある、もっと先駆的な仕様管理ツールが必要だ!というわけです。

    もっとも、Excel方式でもDB管理方式でも管理対象インターフェースの実装方式の違いとしてクッションできるべきだと思っていますが。

    仕様・テストケース・テストコード・ソースコードは互いに姿を写す合わせ鏡のようなものだと思いますので、ギャップを検出して、自動的にタスクを起こすような仕掛けが要るのではないでしょうか。
  • # re: タスク管理システムを考える その3
    シャノン
    Posted @ 2007/09/07 11:55
    設計書作成ツールを作るのはいいですが、それで、Officeで作られた設計書を根絶できるかというと、難しい気がするのです。Office文書をインポートする機能は絶対に要望されると思いますよ。
  • # re: タスク管理システムを考える その3
    凪瀬
    Posted @ 2007/09/07 12:58
    んー。
    とりあえず、そのへんはプラグイン可能な「管理対象インターフェースの実装のひとつ」程度に考えています。
    私はExcelでの管理なんて興味がないし、過去の遺物を引きずる前提での使用を推奨する気はないので、必要ならそういうプラグインを作れば?という立場。

    メインの方針としては、新しい仕様管理ツールではExcelでの管理ではできない細やかな連携を可能として、移行を促すつもりです。

    Excelの仕様書のまま使うのではなく、データ変換して移行する、というツールはそれはそれで需要はあるかもしれませんね。

    仕様書をExcelで提出せよ、というのであれば、XMLデータ書き出すからXSLTで好きなフォーマットに変換してよ、という方向性で。
  • # re: タスク管理システムを考える その3
    シャノン
    Posted @ 2007/09/07 13:24
    プラグインにしても、本体に標準添付して配布すべきだと思います。
    新規に仕様書を起こす場合には新しい形式でやるにしても、既存の仕様書も取り込めないといけませんし、移行を促すのはいいですが、移行期間中にもドキュメントは書かれますから。
    それに、このツールがない場所で行われたミーティング議事録なんかも取り込めないと困りますしね。
    インポート/エクスポート手段はあるべきです。

    # 俺だって Excel / Word で仕様書書くのは嫌いですよ。

    プラグインアーキテクチャを取った場合、それはそれで興味深い問題が発生します。
    本体にそれなりの機能を持たせ、プラグインで補うのか、ほとんどの機能はプラグイン化して、本体はプラグインの連携を取るだけに専念するのか、とか。
  • # re: タスク管理システムを考える その3
    凪瀬
    Posted @ 2007/09/07 14:08
    最終的なプロダクトとしては含めるべきでしょう。
    しかし1stのリリースに必要かといわれるとそうは思わないですね。
    まずは形にしたいので最小限の機能に抑えたい。

    その後の拡張でカバーしていきたいと思っていますが、オープンソース形式でやりたいので私一人ではなくいろんな人が手を出せるように配慮しておきたいですね。
    それがプラグイン形式にする理由です。

    プラグイン形式の場合、とりあえず抽象部分から先、具象部分は好きに作ってよいよ、ということになりますが、
    抽象部分から上のコアは手を出せないことになります。

    コアの部分でどこまで考慮するのかは設計上の重要事項ですが、ここを高度に抽象化して汎用化すると難しすぎるので、
    今の私の設計能力ではこのクラス図程度の抽象度が限界となっています。
    今の私にはEclipseを設計する能力はありません :-(
タイトル
名前
Url
コメント