現在、要件定義フェイズなのですが、Microsoft Wordの操作性の悪さに辟易しています＞＜ 特に箇条書きにするところ。 次のインデント場所が読めないとか、ないわー＞＜ で思ったのですが、お客様の要件をまとめる上での定型的なフォーマットとか、文書作成ソ…

このテーマで書いたエントリの２つともで、書き忘れていた事があったので追記的なエントリを起こします。あのエントリで僕が本当に言いたかった事は、以下の２つ。 下流工程だ、下請だって理由で腐るな 下流工程でも下請でも、自分のやるべき事をきっちりや…

今更ですが、このエントリの中での「偉い」の定義が曖昧だったんですよね、お陰で変なエントリになってしまいました＞＜そんなKusoってるエントリに対してid:kompiroさま、id:Horiuchi_Hさま、id:loveatさま、id:AWAWAさま、コメントありがとうございます。…

上流工程を担当する＝偉い と思っている方が身近にまだいましたので、ちょっとこんな話題について考えてみました。 開発プロセスの最初の方を上流と呼ぶ場合、最下流は「検収を頂く」とか「お客様より評価を頂く」事な筈です。これってどう考えても、「下流…

本当は「Teeda＆WTP＠Eclipse 3.3 Europa」の続報を書きたいのですが、情けないことに帰宅時間が遅いせいで進捗ゼロという深刻な状況もあって、再び話は開発プロセスに。

方式設計について、色々考えた事を書いてきましたが、そろそろまとめます。

前回、方式設計のミッションと思われる（ちょっと自身ない）を列挙してみました。こうすると、方式設計とはプロジェクトそのものをデザインする工程だと思ったです。ソフトウェア・デザインと同様、この設計が後の工程に与える影響は少なくないです。無駄な…

一瞬わき道に反れてしまいましたが、設計というプロセスについてです。まずは方式設計。 対象のシステムの実装の仕方を設計します。その為、まずは実装方針の指標ともなるシステム・アーキテクチャ設計が必要となります。そのアーキテクチャに沿ったハードウ…

システムのデザインの最適化を考えるのと同じくらい、プロジェクトの置かれた状況を意識しないと、本当に設計と言える設計は出来ない、という前回からの続きです。

前回[id:itengineer:20070602]、少し書き残した事がありましたので、補足します。自分が設計フェイズを担当した際、まず気にするのは開発要員の技能レベルです。一時はこれを無視して自分なりに最も最適化された、効率化された設計をしようとしていましたが…

自分の周辺の人の中で「上流工程やりたい」って人が多いんですが、「じゃ具体的に上流（と呼ばれるフェイズ）に何をしたいんだ？」と聞くと真っ先に出てくるのが「要件定義」。次に「設計」です。更に「要件定義」「設計」で君は何が出来るのさ？と聞くと、…