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

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

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

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

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


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

このQ&Aに関連する最新のQ&A

A 回答 (4件)

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



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

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

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

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

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


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

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

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

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


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

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

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

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

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


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


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

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

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

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


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

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

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

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

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

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

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

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



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

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

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

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


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

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


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

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

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

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

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

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


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

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

システム・アドミニストレータなどの資格取得の勉強範囲だったと思います。
    • good
    • 0
この回答へのお礼

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

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

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

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Q開発経験者が、開発以外で未経験IT関連業務に就けるか

31歳、男、プログラマをしています。
現在転職を考えています。
開発経験者が、開発以外の未経験IT関連業務
(例えばネットワーク、DB関連など)に就けるのでしょうか?
まるっきりゼロとは思えないのですが、
現状はどうなのかよく分からないので、ご存知の方が
いらしたら教えて下さい。
ちなみに自分の所有している資格は基本情報処理と
Oracle Silverです。

Aベストアンサー

 可能だと思います。ただし、未経験とはいえその業務についての正しい理解は必要だと思います。現在プログラマとのことですが、できれば上流工程のご経験をお積みになってから挑戦されれるのがいいと思います。私の経験では上流工程の仕事は業務領域は違っても共通するものも多く、ひとつの領域での経験が活かせるからです。
 具体的な可能性の程度については、業務経歴を詳しくみないとわかりませんが、プログラマとはいえ広範囲な知識と適性があれば問題ないと思います。ご自分のなりたい姿をまず考えてみることをお勧めします。
 私はシステム開発全般の経験(17年)を卒業して、情報工学全般を専門とする専門職(経営にも関与)に現在転職しようとしています。文部科学省の国家資格(情報処理技術者ではありません)ももっています。(合格率10%程度の難関なのです)
 ただし、10年くらい前からいま進んでいるコースは絵に描いておりました。まだお若いようなのでいろいろと可能性はありますよ。

QPCパーツの情勢などの知識は必要?

何か仕事でPCの追加購入が必要になると、いちいち色々聞かれて、
最終的にトップな方から「選んでよ」って丸投げされます。
はっきり言って自分の時間(仕事終わってからの)をそれに費やすなんて馬鹿馬鹿しくてやってられません。
しかもその事で休出までさせられます。
それらの知識があるのは私だけなのです。

IT業界人はPCのパーツ、性能、機能、仕組み、動向や情勢を知る必要はないのでしょうか?
お客から何か頼まれたらと考えたら必要だと思うのですが、
その考えは間違っていますか?
ただ要件を引き出せて設計が起こせてプログラミング出来ればいいんでしょうか?
必要とする場合、何故必要なのかも添えて頂けると嬉しいです。

社内でも、対お客でも、何かある毎に社員にパソコンの事を聞かれて参ってます。
個人スキルとしては特化していて良いのかもしれませんが、
別にそれでメシ食ってるわけではないので・・・。帰宅しても自分の時間ないし。
業界人として必要だと思うから自分で自主的に勉強しているだけなので・・・。
最近は収まってきましたが、たまに質問攻めに遭います。
どうにも一人で調べてくれないもので・・・。

回答で、必要だという意見が大多数を占めるのなら勉強会にでも講義内容として
掲げてみようかと思います。

何か仕事でPCの追加購入が必要になると、いちいち色々聞かれて、
最終的にトップな方から「選んでよ」って丸投げされます。
はっきり言って自分の時間(仕事終わってからの)をそれに費やすなんて馬鹿馬鹿しくてやってられません。
しかもその事で休出までさせられます。
それらの知識があるのは私だけなのです。

IT業界人はPCのパーツ、性能、機能、仕組み、動向や情勢を知る必要はないのでしょうか?
お客から何か頼まれたらと考えたら必要だと思うのですが、
その考えは間違っていますか?
ただ要件...続きを読む

Aベストアンサー

最初に多分色々細かいことを言ったことがあるんじゃないです?
変に最初に知ったかすると、周囲の人間は
「あぁこの人に聞けばいいや」と安易に判断して
ずーっと依存してくることになります。

PC購入に関してあなたの判断で最終決定がされるなんて
素晴らしい会社じゃないですか!
好きなメーカーでハイエンドモデルを選んでおけば、
エライ人たちも納得するんじゃないですか?

機能やら性能はウダウダ説明したって、どうせ理解しません。
「私が選ぶものが信用出来ないのなら、もう聞かないでくれ!」
と一喝してやれば終わる話です。

まぁ真面目にビジネス仕様のPCを購入ということなら、
各メーカーの営業担当に来てもらえばいいでしょう。
彼らにあなたの会社のエライ人達を相手に
一生懸命説明させればいいと思いますよ。

Qシステム設計

システム設計とは具体的にどういうものなのか知りたいのですが…
回答願います。
色々なサイトを検索してみたのですがどうも僕が求めている情報が載っているサイトが見付かりません。
どこからどこまでがシステム設計なのか(どこから開発になるのか)等、本当に基本的な事で構わないので教えていただけないでしょうか。
また、システム設計について書いてあるサイト等知っている方がいましたら教えていただければありがたいです。
宜しくお願いします。

Aベストアンサー

まず、システム開発とは一般的にシステム設計~製造までの一連の作業を指して言うことが多いです。
基本的にはシステム開発とは(1)要件定義(システムで何を実現したいかを定義)、(2)外部設計(ユーザーが使用する画面や帳票類の設計)、(3)内部設計((1)(2)で決定した要件を実現する為のシステム設計)を経てプログラム製造~テスト工程へと進んで行きます。
一般的にシステム設計と言えば、(2)と(3)を指します。

システム開発は、よく建築に例えられます。
まず、家を新築したいクライアントがいたとします。
どんな家を建てたいのかを聞き出すのが(1)。
(1)を元に、外壁やキッチンなど目に見えるところの設計をするのが(2)。
(2)を実現するために、内部構造の設計をするのが(3)です。

Qシステム設計を学ぶ良書を教えてください

こんにちは、私はSIに13年勤務しているものです。
入社してから5年は、Java+DB2+WebSphereで開発を行っていましたが、ウェブサイト構築の仕事をするようになり、8年間開発現場からは離れておりました。
今回、システム開発案件で上流を担当することとなり、忘れていた勘所を戻そうと勉強をしたいと考えていますが、オススメな良書はありませんでしょうか?
自分自身が開発する立場では無いとはいえ、設計や開発、DBチューニングやLinuxの知識など、幅広くもとめられますので、書籍の分野は幅広いですが、システム設計の知識を中心に、業務分析から設計に落とし込むあたりの本を中心にご紹介いただけると、ありがたいと考えております。

あえて言語や技術、環境をしぼるとすると、
Java+Oracle+Linux
という感じでしょうか。

私自身の知識レベルは、浅いので新卒の学生に紹介する本のレベルでもかまいません。
皆様何卒、お知恵をお借りできたらと思います。よろしくお願い致します。

Aベストアンサー

私も同じような境遇で一時期オープン系の開発を離れていた時期がありました。
その時に過去の勘を取り戻すためにいくつか書籍を読んだ経験があります。

オススメとしては、エンジニア道場出版の『はじめての設計をやり抜くための本』が
一番勉強になったように思います。

「はじめての」と銘打っているだけあって全体を広く浅く理解するのに最適です。

※もし、ひっかかる部分があれば別の専門書で深く掘り下げることとで
 より実務よりの知識を補完する事ができるかと思います。

個人の一例ですが、ご参考になれば幸いです。

Q開発

こんばんわ
就職した友達らが仕切りに開発…開発と仕事について言っています。
彼らはプログラマー?SE?の仕事をしていると思いますが、"開発"とは、どのような仕事をしているのでしょうか

Aベストアンサー

キャンパスに絵を描くような
粘土で器を作るような
原稿用紙に小説を書くような

そんな仕事です。

間違いやすいのは
プラモデルを組み立てるのとは違います。
ジグソーパズルを組み立てるのとは違います。
誰かの作ったレシピで料理を作るのとは違います。

大雑把に言えば無から有を作る事。

なんとなくでも伝わればと思います。


人気Q&Aランキング

おすすめ情報