[敬请读者注意] 本人保留本文的全部著作权利。如果哪位读者使用本文所描述内容，请务必如实引用并明白注明本文出处。如果本人发现任何人擅自使用本文任何部分内容而不明白注明出处，恕本人在网上广泛公布侵权者姓名。敬请各位读者注意，谢谢！

指导软件工程过程及实践的16条核心原则

程京德 

    “软件工程”是为了保证大规模软件系统的高可靠性，研究以系统化的、规范化的、可量化的、过程化的工程方法去定义、设计、开发和维护大规模软件系统，以及如何将这些方法应用到工程实践的工程专业学科。

    美国软件工程专家 Roger S. Pressman 在其名著 “Software Engineering: A Practitioner’s Approach”[1] 中归纳列举了指导软件工程过程及实践的16条核心原则。

    本文以下部分为笔者对上述 Pressman 书中16条核心原则的编译（省略了不重要的细节），是笔者历年给国内大学讲授“软件工程”课程的教学材料之一，现提供给有兴趣的读者参考。

指导软件工程过程的8条核心原则

原则1 敏捷 

    无论你选择的过程模型是规定性的还是敏捷的，敏捷开发的基本原则应该支配你的方法。你所做的工作的每一个方面都应该强调动作的经济性 — 尽可能保持你的技术方法简单，尽可能保持你的工作产品简洁，并且尽可能在局部做出决定。

原则2 关注每一步的质量 

    每一个过程活动、动作和任务的出口条件都应该关注已经生产之工作产品的质量。

原则3 准备好适应 

    过程不是宗教体验，教条在其中没有位置。必要时，使你的方法适应问题、人员和项目本身所施加的约束。 

原则4 建立一个有效的团队 

    软件工程过程和实践很重要，但底线是人。建立一个相互信任和尊重的自组织团队。

原则5 建立沟通和协调机制 

    项目失败是因为重要信息被遗漏或者利益相关者未能协调他们的努力来创建成功的最终产品。这些是管理问题，必须解决。 

原则6 管理变更 

    方法可以是正式的也可以是非正式的，但是必须建立机制来管理变更的请求、评估、批准和实施方式。

原则7 评估风险 

    随着软件的开发，很多事情都可能出错。你必须建立应急计划。其中一些应急计划将构成安全工程任务的基础。

原则8 创造为他人提供价值的工作产品 

    仅创建那些为其他流程活动、动作或任务提供价值的工作产品。作为软件工程实践的一部分而产生的每一个工作产品都将被传递给其他人。需求功能和特性的列表将传递给做设计的人，设计将传递给编码的人，等等。要确保工作产品给出了必要的信息，没有歧义或遗漏。

指导软件工程实践的8条核心原则

原则1 分步解决 

    用更专业的方式来说，分析和设计应该总是强调关注点分离。如果一个大问题被细分为一系列元素(或关注点)，那么它就更容易解决。理想情况下，每个关注点都匹配了可以独立于其他关注点开发的不同功能，在某些情况下还可以进行确认。

原则2 理解抽象的使用 

    从其本质上来说，抽象是对系统中一些复杂元素的简化，用一个短语来表达其交流含义。在软件工程实践中，你会使用许多不同层次的抽象，每一个层次都传递或暗示着必须交流的含义。在分析和设计工作中，软件团队通常从表达高层次抽象的模型开始，并慢慢地将这些模型细化到较低层次的抽象。抽象的目的是消除交流细节的需要。但有时，这些细节引发的问题效应会“泄露”出来。不了解细节，就不容易诊断出问题的原因。

原则3 争取一致性 

    无论是创建一个需求分析模型，开发一个软件设计，生成源代码，还是创建测试用例，一致性原则表明一个熟悉的上下文将会使软件更容易使用。 

原则4 关注数据/信息的传输 

    软件是关于数据/信息的传输。在每种情况下，数据/信息都通过一个接口流动，因此，有可能出现错误、遗漏或歧义。这个原则的含义是，你必须特别注意接口的分析、设计、构造和测试。

原则5 构建展示有效模块化的软件 

    关注点分离(原则1)为软件建立了一个哲学。而模块化为实现这一哲学提供了一种机制。任何复杂的系统都可以分成模块(组件)，但是良好的软件工程实践要求的更多。模块化必须是有效的。也就是说，每个模块应该专门关注系统的一个约束良好的方面 — 它应该在功能上具有内聚性或者在它所表达的内容上受到约束。此外，模块应以相对简单的方式互连 — 每个模块应表现出与其他模块、数据源和其他环境方面的低耦合性。

原则6 寻找模式 

    Brad Appleton建议: “模式在软件界的目标是创建一个可参照（模式）集来帮助软件开发人员解决在整个软件开发中遇到的重复出现的问题。模式有助于创建一种共享语言，用于交流关于这些问题及其解决方案的见解和经验。”通过允许复杂系统中的组件独立发展，设计模式的使用可以应用于更广泛的系统工程和系统集成问题。

原则7 如果可能的话，从多个不同的角度描述问题及其解决方案 

    当从多个不同的角度审视一个问题及其解决方案时，更有可能获得更大的洞察力，并发现错误和遗漏。 

原则8 记住有人会维护软件 

    从长远来看，软件将随着缺陷的发现而被修正，随着环境的变化而被调整，随着涉众要求更多的功能而被增强。如果在整个软件过程中应用可靠的软件工程实践，这些维护活动将会得到促进。

参考文献

[1] R. S. Pressman and B. R. Maxim, “Software Engineering: A Practitioner’s Approach,” McGraw-Hill, 2014(8th Edition).  

微信公众号“数理逻辑与哲学逻辑”