1. 在传统财务概念下，软件公司或者商业公司IT部门的员工，是公司的成本中心。对于一个定额合同项目，员工工资成为项目中唯一的可变成本。
2. 因此，尽可能的缩短工期，减少人员投入就成为缩减成本的基本方式。
3. 软件的分工模式，以及传统的waterfall——流水线的工作方式，决定了问题发现的越早，修正的成本越低。
4. 有两种手段来减少工期，工程上采用迭代，并让迭代周期尽可能短，以及从技术上对于问题域进行分解，建立有效的边界。
5. 迭代周期减少的目的是减少分工环节中尤其是第一个环节的不确定性带来的问题，而对问题域的技术分解是解决开发环节的质量问题。因为通常维护成本是开发成本的3倍，提高质量可以减少项目后期对前期开发代码的维护成本。
6. 同时，分解的好坏将决定了是否可以在开发环节中引入测试环节的工作，从而提供质量;并减少修正缺陷以及测试的工作量。
7. 质量是难以衡量的，通常以能否工作为准。而通常意义上的高质量代码是可以较容易调整以及适应变化，但是不容易识别。
为保障质量，通常的手段是代码审查，但在工程中完全代码审查承保高昂，同时工作量大，并难以评估(评估结果有时因人而异)。而各种各样的代码规范检查工具只能保障最低要求。
8. 在进度落后于计划时，管理人员通常会下达行政指令——要求项目成员全力以赴赶上计划。在此情况下，工程人员通常牺牲质量换取开发进度，同时把质量问题推后发生。
9. 软件开发是脑力劳动 而非体力劳动;因此工程人员有很大的权利，他们有选择质量和进度的能力，工程人员的工作状况严重影响产出和进度。而上述情况的发生是人在利益环境下的自然选择，对于工程人员的指责无济于事。
10. 正确的工作方式是，为工程人员创造合适的条件以便工程人员做正确的事。
软件架构师的工作
软件工程的三要素：工具，方法和过程。然这所有的一切是规范人的分工和行为，提高人的生产效率，降低成本。
架构师的工作围绕这个三个要素进行。
1. 工具评估(包括开发平台，开发语言，开发工具以及辅助工具)。
A. 用好的工具提高生产效率，使人关注于有效工作内容，从而减少不必要工作量，减少成本。
特别对于分工下的团队开发尤为重要。典型的分工是流水线，一步接一步。减少上一个环节的工作量，如开发环节，不仅提前下一个环节——测试的时间。
B. 用好的工具保证质量——另一种生产效率。
保证质量有利于减少工作上的反复，尤其影响到测试工作量，从而减少成本。
提高生产效率的同时有利于保证士气。
2. 方法论选择
解决问题的办法就是分治。要被分解问题域是：数据(模型)，计算和流程;而如何分解问题便是架构师的取舍啦，流行的有OOD和AOSD两种。
在大比例结构中必需考虑的是：抽象分层，技术分层以及模块切分。抽象分层(包括模型，计算以及流程抽象)以及模块切分是基于业务的纵向以及横向分解。而技术分层则是对于业务逻辑的技术分类，分类本身还可能涉及到平台技术限制。所有分解都涉及到上下文的边界建立——不仅仅是业务逻辑同时也是技术边界。
分解问题必需考虑人的因素，降低分解后的知识学习阻力，保持知识的内聚以及有效组织是保证分解成功的关键。这些工作将有效保证开发人员不做出破坏系统分解边界的行为。
考核分解的有效性：保证开发的效率。分解的目的是降低解决问题的难度，从而提高生产效率，如果分解方案增加了系统适应变化的能力，那么分解方案可能是错误的。
除了开发方法还有开发方式，已知的三种开发方式：编程式，声明式以及产生式。
开发方式的选择和技术分层有相当的联系，一般认为除了Service以及Model，其它的技术分层代码尽量使用声明式以及产生式开发方式来完成，减少建立以及维护成本，提高效率。
对于Domain Model还要分析model的生命周期，明确设计主题。
3. 过程选择
选择的过程，最重要的是让问题及早暴露(降低成本)，尽早让用户使用(创造价值).
敏捷方法就是要让问题更快的暴露，让功能更快的实现。
文档，文档是过程的一个重要产物。文档也是保证知识传递的。
在问题分解情况下的开发角色分为三种：开发者，使用者以及维护者。开发者写的文档给后两者看，最最关键是写给使用者的文档。
所有的决定都是基于利益和成本考虑的。
文章来源于领测软件测试网 https://www.ltesting.net/