中国 IT 从业人员中对软件研发过程有系统认识的少之又少，甚至在工作中遇到的科班出身的研发同学同样不例外。相反，大家对于追求热点概念（例如：DDD，领域驱动设计）倒是不遗余力，满怀热情。
软件开发刚开始的时候，并没有很好的经验或思想来指导项目研发。从研发的各种名词中可以看出来，软件行业从建筑行业借鉴了许多经验。
建筑行业涉及到不同角色协作：设计师、开发商（工人、电工和水暖工）、质量监理、等等。
软件工程类似的角色：产品经理、研发（后端、前端、客户端）、测试、QA
建筑行业遵循的流程：把端到端的项目分成不同的阶段，每个流程阶段由不同角色负责
每个阶段赋予角色的做法，有利于充分利用成本高昂的人力资源。在借鉴的基础的产生了第一个标准的软件开发流程
事实上，如同力学三大定律为物理学奠基一样，瀑布模型在软件行业的地位同样不可动摇。虽然随着历史的车轮滚滚向前，软件研发方法论的研究重点从瀑布模型的 “流程”，过渡到以交付速度和成功率为目标的敏捷开发、持续集成、持续交付、持续部署。但研发过程的核心步骤从未改变：分析、设计、开发
然而，不幸的是，因为追求交付速度、成功率，国内研发不仅丢掉了瀑布模型，也丢掉了核心过程。太多的研发以敏捷为理论核武，把设计完全抛掉，更遑论分析。如果系统确实太过复杂，抑或领导要求，那就装模作样加入一个设计阶段，设计一个看起来能够跑的通的架构。一旦软件进入实现阶段，所有的设计文档就被雪藏起来吃灰。
重视开发多于设计，不知分析为何物。架构凭经验和感觉，就像无根之水，即使再美也经不起业务变化和迭代的侵蚀，最终走向腐朽。最后不得不亮出终极武器：重构（其实，是“重做”）。
意识到需要做分析、设计，到知道如何做分析设计，中间有着不小的鸿沟。软件开发不是玄学，有着系统的方法论，以及完善的表达工具。需求分析从业务开始，层层剥开，直至实现。如果把软件想象成建筑，那么各种图就是从某一个特定的视角（viewpoint）表达软件的设计图纸，因此RUP C4+1 称之为 View model 也大抵表达该含义吧。选择合适的图表述，把软件表述清楚也能体现出工程人员的软件设计能力。
各个层级的分析对象
各分析阶段用于表达的图
具体使用细节，不再使用例子详细描述，可以参考：
- Microsoft: Analyze and model your architecture
- IBM:利用Rational Software Architect 定义应用程序架构 第一部分、利用Rational Software Architect 定义应用程序架构 第二部分
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/07-22-2020/software-development-methodology.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！