包括フレームワークの開発プロセス

ソフトウェアとしてのフレームワークはいたって無難な構成になっているのでそんなに違和感がない。

「今ならこういう選択肢もあるのではないか？」と疑問にもつ人もいるとは思うが、業務系のフレームワークは最新を狙うよりも堅いライブラリを選択するのが正しい選択だと考えるので妥当なところだろう。
しかし、最終的には非機能要求が不明確なところでフレームワークの良否を判断してもしょうがない。

ここでは開発プロセスの方に着目する。

包括FWの開発プロセスの特徴は（もしかすると札幌市版は　ということかもしれないが）、工程毎に調達をかけることである。

包括フレームワークの工程は以下のように分かれている

　・企画
　・要件分析プロセス
　・基本設計プロセス
　・開発プロセス
　・保守運用プロセス

このプロセスをユースケース駆動で進める。
ユースケース駆動とはっきりうたっていないようだが、ユーザが認識出来る情報をもとに開発を駆動するので広義の意味でユースケース駆動といえる。

開発を駆動する中心となるのが業務フローとユースケース記述である。

業務フローで業務とシステムとの接点を明らかにし、ユースケースでシステムとの接点を明確にする。

そして概念モデルで言葉の定義を行い業務フロー、ユースケースの中で使われる言葉の曖昧さをなくす。
ここまではオブジェクト指向で業務系のシステムを開発した経験があればイメージをつけやすい展開である。

乱暴な言い方をすれば要件分析プロセスで業務フローを作成し、基本設計プロセスではユースケース記述を作成する。

ユーザが認識可能な情報をもってシステムの仕様とする。

そして開発プロセスに渡す。

これが上流工程の大きな流れである。

発注者側で「仕様の策定に責任をもつ」ということから考えてユーザ側で認識可能な情報をもって開発前の仕様とする。
というのは考え方としては筋が通っている。

しかし、一方で工程毎に調達をかける今回の方式では、工程の成果物が一定の基準を満たしている必要がある。
そこをどのように確保するかがもう一つの大きな課題として残っている。

下工程になればなるほどそのことが重要な意味を持ってくる。
そこがもっとも今回の難しいところなのでそこを少しづつ考えていきたい。

「要求をまとめることはしないのか」という質問がセミナー内であったが、既存システムの更新をターゲットにしているので、要求をとりまとめるようなことはしないと言っていた。
ん〜〜　これはちょっと片手落ちのような気がするが　それは後日扱う...

ここまでの話で開発になれている人であれば　「おい　おい　アーキテクチャは何処いった」

と疑問に思うだろう....

次回はアーキテクチャを取り上げる