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

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

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

 "社会情勢を多分に盛り込みたい"と考えているシステムの場合、
"要求定義局面" を完全に締めてしまうと、それ以降の局面から運開
までの期間の情勢は「とりこぼし…」となってしまい、
(期間にもよりますが、とりこぼし対象の "発生と大きさ" が心配です)
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テールズ・オブ・ディスティニーの雑談システム?の・・・

手抜きでほとんど調べていません。   (汗;
申し訳ないのですが、「テールズ・オブ・ディスティニー」の雑談システム?ってありますよね。
しばらく何の動作もしないとこのソフトではキャラがしゃべるやつ

200ぐらいあるそうなのですが、それのデータベースみたいのって
どこかに(本でも可!!)ありますかねぇ
自分自身は結末体験はしているのですが、甥・姪と一緒にやるはめになったので、
ついその辺の情報が欲しいです。

個人的には
1.全コメント
2.(欲張りで)それぞれの発生する条件
3.その他??
が重点ポイントではないかと思っています。

発売時期が少々古いのですが、宜しく御願い致します。

Aベストアンサー

APW(アクティブ・パーティ・ウィンドウ) ですね。これはかなり厳しい質問のように思いましたが、参考のサイトで256種類(5種類はボツゼリフらしいです)全てのセリフだけなら見れます。ただ、条件とかはさすがに載っていないようですね。

ちなみに、エターニアでしたら、エンターブレインから出ているオフィシャルガイドブックにヒントスキットとキャンプスキットの条件や内容が書かれているのですが、デスティニーのオフィシャルには特別な解説もされていないようでした(見落としていたら出直してきます)。ということで、本ではちょっと苦しいかなと思います。

また、そのようなサイトが見つかれば出直して来ますね。

参考URL:http://www.hanna.cc/minamoto/tod/

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

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

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

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

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

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

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

Aベストアンサー

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

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

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

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

QPCで敵の動きを補足する軍事システム

「テイアーズ・オブ・ザ・サン」という映画を観ていると、アフリカのジャングルの中でアメリカ兵士がノートPCの画面をみて「10キロ離れた地点で30名ぐらいの集団がこちらへ向かっています」と報告する場面がありました。
 敵兵の位置がそんなに簡単にわかればいいのですが、これはどういったシステムなのでしょうか?
 画面では30ばかりの点が写っていました。

Aベストアンサー

 携帯電話か通信衛星かを使った相互連絡システムであると思われます。
 他の数多くの味方部隊の報告を受けた本部が、敵と味方の状況を知らせる地図を作成し、それを主人公の部隊に送っていると思われます。
 実際、その地図は人間が手作業で作ってるって設定だと思いますよ。

 俺はその映画は見てませんが、もしその主人公部隊が孤立無援の状態にあるのなら、敵の通信を傍受したか、あるいは丘の上にでも登って目視で確認したか、それかストーリーの都合で何の裏づけもなくそういう設定にしたか、どれかのはずです。

Qシステム設計

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

Aベストアンサー

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

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

Qシステム修復ディスクはシステムイメージ作成の都度?

CドライブにOS(Windows 7 Ultimate 64)がインストールされているのですが、システムイメージの作成をすると「システム修復ディスクの作成」をするように求められます。この「システム修復ディスクの作成」はシステムイメージの作成をした都度行わなければならないのでしょうか。それとも、1度「システム修復ディスクの作成」をしておけば、その後のいつ作成したシステムイメージであろうと、その1度作成したシステム修復ディスクを用いてシステムディスク(Cドライブ)の復元ができるのでしょうか。

例えば、次の(ア)~(エ)のようにしたとします。
(ア) 2月1日にシステムイメージの作成とシステム修復ディスクの作成をした。
(イ) 2月8日にシステムイメージの作成をした。
(ウ) 2月15日にシステムイメージの作成をした。
(エ) 2月22日にシステムイメージの作成をした。

この場合、(イ)~(エ)で作成したシステムイメージを使ってシステムディスク(Cドライブ)を復元するには、次の(a)、(b)のどちらでしょうか。

(a)
(イ)のシステムイメージを使ってシステムディスクを復元するには、(イ)のときにシステム修復ディスクを作成しておきそのシステム修復ディスクを使わなければならない。
(ウ)のシステムイメージを使ってシステムディスクを復元するには、(ウ)のときにシステム修復ディスクを作成しておきそのシステム修復ディスクを使わなければならない。
(エ)も同様。

(b)
(イ)のシステムイメージを使ってシステムディスクを復元するには、(イ)のときにシステム修復ディスクを作成する必要はなく、(ア)のときに作成したシステム修復ディスクを使えばよい。
(ウ)のシステムイメージを使ってシステムディスクを復元するには、(ウ)のときにシステム修復ディスクを作成する必要はなく、(ア)のときに作成したシステム修復ディスクを使えばよい。
(エ)も同様。

CドライブにOS(Windows 7 Ultimate 64)がインストールされているのですが、システムイメージの作成をすると「システム修復ディスクの作成」をするように求められます。この「システム修復ディスクの作成」はシステムイメージの作成をした都度行わなければならないのでしょうか。それとも、1度「システム修復ディスクの作成」をしておけば、その後のいつ作成したシステムイメージであろうと、その1度作成したシステム修復ディスクを用いてシステムディスク(Cドライブ)の復元ができるのでしょうか。

例えば、次...続きを読む

Aベストアンサー

http://windows.microsoft.com/ja-JP/windows7/Create-a-system-repair-disc
での解説の通り、システム修復ディスクの用途はパッケージ版インストールメディアが持つ機能の代替で使用するディスクにすぎませんので、一度作成すればOKです。

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

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

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

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

Aベストアンサー

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

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

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

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

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

Qシステムの復元がないのですが

ウインドウズ7で、アクセサリ→システムツール→システムの復元のはずが
システムツールの中に、システムの復元だけがありません。
仕方なく、メンテナンスから、復元を試しました。
システムツールの中にシステムの復元を作成する方法、または
システムの復元が、どうしたらシステムツールの中にあるようにできますか?
使用してるPCは、vaioのノートPCです。
出来るだけ、わかりやすい回答をお願い致します。

Aベストアンサー

7の場合のシステムの復元の場所は、

スタート → コントロールパネル(右の欄です) → システムとセキュリティ、で
一番上の欄の『アクションセンター』のコンピューターシステムを以前の状態に復元を
クリックすればありますよ。

Q開発

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

Aベストアンサー

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

そんな仕事です。

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

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

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

Q「システム」がつく理由

世の中には~システム、という言葉が沢山有りますよね。
じゃぁ、何でシステムがつくのか?と聞かれたら、うなってしまいます。
例えば金融システム。金融システムとはどういうもの、という説明はあっても、何でシステムなのか、という説明って見つからないんです。
以下の4つの事について、どなたか教えて下さい!!
・金融システム
・価格システム
・給与計算システム
・ネットワークシステム

よろしくお願いします!!

Aベストアンサー

金融システムについては参考URLを見てみて下さい。

価格システムは
http://www.asahi-net.or.jp/~GA2A-MYZK/mare/mare022.html

給与計算システム
http://www.ntis.co.jp/product/officeh/kyuyo.htm

ネットワークシステムに関しては多岐にわたって使われているので洞行った場面でのものかが分からないのでちょっと答え切れません。

色々苛部手いるときに面白いページを見つけたので紹介しておきます。

http://village.infoweb.ne.jp/~fwgf2942/SCNews/hpblock99/SCNews99.html

ここに「システムとは?」という話が載っています。

参考URL:http://www.geocities.co.jp/WallStreet-Stock/3120/sub1html/koukousei/ginnkou8.htm

Qメーカーの設計業務

今年社会人1年目の男性です。
大卒後、大手機械メーカーに勤務してます。

設計業務をしているのですが、いまいち設計という感じがしません。
設計って、もっと製品を見て、触って、考えて作る業務と考えていましたが、やらされる仕事は尽く
書類雑務ばっかりです。参考に完成図面見せてもらったりするのですが、何が何やらぜんぜんわかりません。 例えば、電気回路図のある部分は、製品のどの位置に搭載されているもので、どのような機能を果たすものなのか分からないという感じです。一応、私は電気系出身なので、知識はあるのですが、どうにも仕事の実態がわかりません。

要求仕様書通りに電気回路図を変更する業務も、流れ作業で淡々とすすめるので、頭を使って設計(?)してる実感がわかず、困っています。

そんな感じなので、いざシステムの詳しい事を聞かれると答えられません。
なにせ、システムの事なんか理解せず仕事自体が完遂できてしまうわけですから・・・・。

これって、私の業務の進め方が行けないんですか?
それとも、仕事とはこういうものだと割りきってしまうべきなのですか??

Aベストアンサー

こんにちは。元大手電機メーカーの設計職だった者です。

ご相談内容を読んでみて最初に思ったのは、こういう内容の相談ができる上司や先輩がいないのかな?という疑問でした。上司や先輩に仕事上の疑問をぶつけるのは入社年度の若い人の特権だと思います。私は成人前から酒好きだったこともあり、上司や先輩を飲みに誘って相談がてらご馳走になっていました。
あなたの業務の進め方について問題があるか否かは、上司や先輩から評価してもらうべきです。

他の会社はどうなのか?というと似たり寄ったりだと思います。
「システムの詳しい事を聞かれると答えられません」とありますが、入社2~3年で答えられる人なんていません。逆に分かったつもりになっている人の方が重大な問題を起こしがちなので、上司の立場で考えると、あなたのように問題意識のある若い人の方が将来有望に見えます。

今はつまらない仕事かもしれませんが、将来かならず理解できる日がくると思います。10年後かもっと後か・・・。理解できないことは自分で考えることも大事ですが、相談することも大事です。仕事のやり方に問題があるなら自ら対策を考え改善する。それでもこの会社とは合わないと思ったら私のように独立してしまうという選択肢もあります。独立を視野に置くと、会社というものは独立するまでの知識と経験を与えてくれる最適な場所という見方になり、ちょっと考え方が変わったりします。ご参考になれば幸いです。

こんにちは。元大手電機メーカーの設計職だった者です。

ご相談内容を読んでみて最初に思ったのは、こういう内容の相談ができる上司や先輩がいないのかな?という疑問でした。上司や先輩に仕事上の疑問をぶつけるのは入社年度の若い人の特権だと思います。私は成人前から酒好きだったこともあり、上司や先輩を飲みに誘って相談がてらご馳走になっていました。
あなたの業務の進め方について問題があるか否かは、上司や先輩から評価してもらうべきです。

他の会社はどうなのか?というと似たり寄ったりだと思いま...続きを読む


人気Q&Aランキング