日本のITプロフェッショナルで、ソフトウェア開発プロセスを体系的に理解している人はほとんどいません。それどころか、彼らはホットなコンセプトを追求することに情熱を燃やしています。
ソフトウェア開発が始まった当初は、プロジェクト開発の指針となるような良い経験やアイデアがありませんでした。R&Dに使われるさまざまな用語からもわかるように、ソフトウェア業界は建設業界から多くを借用しています。
建設業界では、設計者、開発者、品質検査官など、さまざまなプレーヤーが協力し合っています。
ソフトウェア・エンジニアリング 類似職種：プロダクト・マネージャー、研究開発、テスト、QA
建設業界のプロセス：エンド・ツー・エンドのプロジェクトは各フェーズに分けられ、各フェーズを担当する役割も異なります。
各フェーズに役割を割り当てることで、コストのかかる人的資源の活用が容易になります。の借用に基づいて、最初の標準的なソフトウェア開発プロセスが作成されました。
実際、力学の3つの法則が物理学の基礎を築いたように、ウォーターフォールモデルもソフトウェア業界で揺るぎない地位を築いています。しかし、歴史の歯車が進むにつれて、ソフトウェア開発方法論の研究の焦点は、ウォーターフォールモデルの「プロセス」から、デリバリーのスピードと成功を目的としたアジャイル開発、継続的インテグレーション、継続的デリバリー、継続的デプロイメントへと移行しています。しかし、研究開発プロセスの核となるステップは決して変わっていません。
デザインよりも開発に重点を置き、分析とは何かを知りません。アーキテクチャは経験と感覚に基づくもので、根無し草の水のように、たとえ美しくても、ビジネスの変化や反復の浸食に耐えられず、最終的には腐ってしまいます。最後に、リファクタリングという最終兵器をお見せしましょう。
分析と設計を行う必要があることを認識することと、分析と設計を行う方法を知ることの間には、大きな隔たりがあります。ソフトウェア開発は形而上学ではなく、体系的な方法論があり、ツールの完璧な表現があります。要求分析はビジネスから始まり、実装に至るまでレイヤーを剥がしていきます。ソフトウェアを建物と考えると、様々な図は特定の視点からソフトウェアを表現する設計図であり、RUP C4+1はこの意味を表現するためにViewモデルと呼ばれています。ソフトウェアを明確に表現するために適切なダイアグラムを選択することは、エンジニアのソフトウェア設計能力を反映することにもなります。
あらゆるレベルの分析対象
分析の各段階で表現に使用される図
- Microsoft:
- IBM.Rational Software Architect によるアプリケーション・アーキテクチャの定義 後編.
RUPのようなソフトウェア開発プロセスは、マイクロソフトやIBMのような大企業が何十年にもわたって反復的に磨き上げてきた結果、事実上の標準となりました。その代わりに、DDDを見てください：
- ひとつは新しいボトルに入った古いワイン；
- 第二に、ランディングツールと詳細が不足していること；
- 第三に、時の試練に欠けていること；
- 第四に、大規模ソフトウェア開発の成功経験が不足していること；
- 第五に、常に磨きをかける大企業が不足していること。
センターステージと同じように、DDDがどこまでやれるかは、もっと長い時間をかけて検証する必要があります。ホットスポットを追い求めるのではなく、静かに基礎を固めた方がいい」。
なかなか書けないので、よかったら3連発で応援してください！
