Loading...

社内システム開発日記:その25

前書き

お疲れ様です!
小手投げです。

大分涼しくなってきて、風呂上りに暖房がほしくなります。

今回は打ち合わせの様子です。

打ち合わせ

担:細部のスケジューリングをするために課題を洗い出したところ
部:リスケジューリング中だから予実はいいや

部:開発前にデータ移行の設計をした方がいい。移行したDBで開発するために
  設計より、移行作業そのものでもいい気がする

部:開発段階で画面が出来しだいExcelに貼ってほしい。レビューをしよう

部:結合テスト・総合テストは分離して、結合テストを自分たちで、総合テストは社外に出ている社員に外から使ってもらおう
  総合テストとリファクタリングをまとめてタスクとする
  結合テストで担保するのは、落ちない、データが最低限CRUDできるところまで

部:課題は
担:細かいタスクに難易度を4段階で振っているが、日数にするには1~2画面作ってみないとイメージがつかめない
  そうした場合、スケジューリングが開発初期まで完了しないことになるがどうしたらよいか

小:難易度の下からそれぞれ1、1.5、2、3日と振って仮の日数を出してみるのはどうか
部:それは意味がない。実際に作ってみるしかない
担:開発の一部を前出しにするということか
部:そうだ

小:情報戦略研究所の改修のタスクが入ったが、CASTとの時間配分はどれくらいか
部:気持ち半々くらい

担:タスクの難易度を判別しがたい部分をどう決めるべきか。例えばファイル出力のあたり
部:ファイル出力はデータストリームとサーバにデータを書き出してリンクで渡す方法の2種類ある
  後者の方が簡単だがディスクを食う
  他にもファイルの生存期間や二重ログインについて考える必要がある
  セッションが追い出し系ならセッションコントロールを自前でやる必要があるかもしれない
  PDFはGoでやらなくてもいいかもしれない。システムコール系かな

部:これで行けそうだというフィジビリティが立たないとスケジューリングできない

部:口頭で説明できるならドキュメンテーションしなくてもいいが、残した方が後々役に立つ

部:各フェーズの頭でそれぞれの実装方式を決めた方がいいかも

後書き

スケジュールは本当に難しいです。
担々麺さんの役に立ってるのか疑問ですが

CASTと情報戦略研究所にさく時間のバランスに悩みます。

ではまた次回。

情報戦略テクノロジー