コンピュータ利用のシステム構築なんたら…

　コンピュータ利用のシステム構築なんたら…
という内容の本を立ち読みしてたのですが、
開発達成には、各局面を(時期的に)完全垂直分離すべき…

(こんな感じです)
| 要求定義 | 外部設計 | 内部設計 | 作り込み | テスト| 移行 | 運用開始

と結論付けているように理解(勝手な私見)しました。

　"社会情勢を多分に盛り込みたい"と考えているシステムの場合、
"要求定義局面" を完全に締めてしまうと、それ以降の局面から運開
までの期間の情勢は「とりこぼし…」となってしまい、
（期間にもよりますが、とりこぼし対象の "発生と大きさ" が心配です）
cut over後、「 もう古いよ…つかえねぇ～ 」
なんてお褒めのことばが(作る前から)聞こえてきそうです。
（かといって、いつまでもだらだら開発してるというのも…）

　仕上がり時点(時期固定)で最新の情勢を反映しているような
おいしい作り方ってなにかありませんでしょうか…？


こんな(つまらん?)ことで思い悩んだことのあるかた、
なにか見解（努力経験のある方のおはなしnaoうれしいっ）
ありましたらおはなしください。
（脳あるタカのツメの先の垢の匂いをちょっぴりかがせてほしい
nao_2ともうします。よろしくお願いします）

No.1 回答者： MtBook 回答日時： 2001/04/09 11:33

あなたの見解は、的を得ています。

結論から言うと、その立ち読みした本自体が、あなたの指摘している、すでに最新の情報を反映していない物です。

コンピュータのシステム構築等の計画には、いくつかの方法が時代に沿って、次々と出てきています。

システム・アドミニストレータなどの資格取得の勉強範囲だったと思います。

この回答へのお礼

回答ありがとうございます
（別件忙殺モード突入によりお礼が大変おくれてスミマセン。
　回答したこともお忘れでしょう。5/11）

システム・アドミ…またなんか耳慣れないコトバがでてきました。
資格の一種のようですが、得るときっといいことありますよね。

お礼日時：2001/05/12 00:39

No.2 回答者： a-kuma 回答日時： 2001/04/09 12:55

> 開発達成には、各局面を(時期的に)完全垂直分離すべき…

という考え方自体古臭いですね。
解決のためのアプローチは大きくふたつ。

ひとつは、ウォーターフローモデルで言われる

| 要求定義 | 外部設計 | 内部設計 | 作り込み | テスト| 移行 | 運用開始

の内部設計～テストをなるべく早く済ませちゃおう、という考え方。
いわゆる RAD というやつです。


もうひとつは、プロトタイプモデルと言われるやり方で、要求定義の
前にプロトタイプシステム（やプログラム）を作り、それをベースに
して要求定義を行なうというもの。

これは、いわゆる陳腐化を防ぐための効力はありませんが、要求定義
のときに具体的なやりとりができるので、実装後の手戻りを少なくし
結果的に開発完了までの速度を上げるという効果があります。


とまあ、教科書的な説明ですが、いわゆるコンピュータシステムが
（値段的にも、感覚的としても）身近になってきたので、それなりに
作り方を模索している人もいっぱいいますし、また、万能な解決策が
わかっているわけでもない、というのが今の状況です。

この回答へのお礼

回答ありがとうございます
（別件忙殺モード突入によりお礼が大変おくれてスミマセン。
　回答したこともお忘れでしょう。5/11）

　プロトタイプですか…ためしてみてどうでした？

私は、際限のない［個別変更と見積と進捗管理］で
えらい目にあったりして、”締め”の必要性は痛感しました…
（質問中の ”かといって、いつまでもだらだら…”
　あたりがその辺に該当したりします…）

お礼日時：2001/05/12 00:42

No.3 回答者： takash 回答日時： 2001/05/10 03:28

「社会情勢」というのが、「IT技術の進歩」のことなのか、「アプリケーションの機能の追加／変更等」のことなのかによって回答も変わってくるのかも知れませんが、、

開発理論は多々あるとは思いますが、通常良く行っているのがフェイズわけです。
CutOVER時に「１２０％必須の機能」「今後長期に利用可能と判断したインフラ」「後に変更してもアプリケーションに多大な影響を与えないような簡便なインフラ」はフェイズ１に盛り込み、CutOverの時期を死守した上で、「その後の想定される機能追加／変更」「本格的なインフラ構築」等を適切なCutOver時期を設定した上でフェイズ２に盛り込みます。もちろんフェイズわけは２段階と決まっているわけではなく、数段階が輪唱のように並行するようなイメージです。
これを効果的に行うことができるようにするために、「開発のレイヤー分け（ユーザインターフェイス／アプリケーションロジック／データベース）」とか、「アプリケーションロジックのコンポーネント化」等のキーワードが世間に広まっているのでしょう。
これだけがベストな方式とはいえないのですが、御参考まで。

この回答へのお礼

回答ありがとうございます。

　敬いたくなるようなかたは何か共通の匂いがするので、
すぐにそれとわかります。
（個人的な好みですが、この匂いはケッコー好きです…失礼しました）

回答いただける方に混乱を生じさせてしまうような表現については、反省してます。
（もっと具体詳細をいろいろ書けばいいのですが、
　　・匿名性担保
　　・カンタン手短かに
　という主催がわの配慮を尊重するので、アバウトな表現に
　なったりしてしまいます。
　ちなみにご回答冒頭で悩まれた(?)部分でいえば、”後者”です。
　もちろん前者にも興味あります。）

　ご提示いただいた”層で輪唱”をキーワードにまた何かしら
あたってみます。
（ "ＩＳＯでＯＳＩ" なる回文講座みたいな表紙の本を
　みてたときになにやら似たようなコトバがいっぱい
　でてきてたような…）

この分野もなにやら "オーケストラ"　な感があるようですね…
（オーケストラ・アドミニストレータなる資格はないんでしょうか…）

お礼日時：2001/05/12 00:45

No.4 回答者： a-kuma 回答日時： 2001/05/12 01:33

> プロトタイプですか…ためしてみてどうでした？

いくつかコツはあるのですが、気をつけてやれば、それなりに
効果はあります。

いわゆる「ウォーターフォールモデルは旧い」と書きましたが、使えない
ということではなく、そのモデルに縛られることが「古臭い」ということ
です。

プロトタイプも万能ではなく、あくまでも、考え方のひとつでしかありません。

プロトタイプをあまりにも一生懸命作ってしまうと、いつしか
本物を作っているような錯覚に陥ってしまうので、お試しのものがいつしか
製品になってしまい、基本的な構造の問題をいつまでも引きずってしまったり
性能上の問題をいつまでも抱え込む羽目に陥る弊害もあります。

ただ、早い段階でシステムのイメージをエンドユーザと共有できるので、
気をつけて使えば、それなりに有効です。


私の経験では、システムの機能はあまり変わらないが、プラットフォームが
大きく変わる、例えば、汎用機で運用されていたシステムを Windows系の
OS で運用するような場合なんかに、作る側と使う側のイメージのギャップを
早いうちに気づかせてくれる、という意味で有効だと感じています。

もちろん、そのギャップを早いうちに埋める手段をうてて *初めて*
有効だった、ということになるわけです。

この回答へのお礼

＜なかなか一筋なわではいかない…＞
＜"万全" ではないけど "できるだけ有効" な手段を講ずべく努力されている…＞
というところは、他のかたのアドバイスからも共通してよくわかりました。

　いろいろな方法論を身にまとい(実戦もわすれずに)、状況に応じて最適な方法を
見誤ることなく選択し使い分ける…
ムリヤリまとめるとこんなんでしょうか？
（気が遠くなってきました…いずれ一人じゃムリでしょう…）


じつは、
私自身この問題については、現時点で100％の解を必須としているわけではありません（失礼）…
（といいつつ、"バッチリ解決" にこしたことはないのですが…）

最近の分野傾向における "お祭りモード(収束中?)" のなか、

・"どの辺りが革命なんだろ…?”
　　（恩恵を受けておきながらそれを意識させないのが技術のイイとこだったりするので…）
・"最新の方法論だとこのテの問題はあっちゅうまに解決されてしまってるんだろうか…?"

という疑問や期待感…それともひとつ、

　"模索努力奮闘中(or済)" なるかたのお話をいただいて、
自身の励みにもさせてもらいたい…などという身勝手な発想から、


このようなところに　"ひっそりと (か？)"　書いてみたりしてます…


何度もありがとうございました。

”うてばソッコ―響く心地よさ”…こんな匂いも大好きです。
（もちろん自分の反射速度は、たなにあげてます…）

お礼日時：2001/05/13 20:44