对一款OA系统来说，除了从源头入手，做好模块化架构外，还可以通过哪些层面确保OA系统的高质量，给用户打造良好的体验呢？本文将针对这一问题做仔细展开，希望对你有帮助。

大家在提到质量的时候大多会想到一些形容词，如：好、坏、一般，用这些词来指定某个产品是否好用、是否耐久、是否有缺陷。所以大多数人一提到质量，总难免想到产品缺陷，因此，缺陷少就自然而然地成为了高质量的代名词，软件产品也不例外。那么软件缺陷少就能代表软件产品质量好吗？

“这是肯定的”。也许在10年前甚至更早的时候用户会这样回答。

但是随着信息化建设不断推进，用户的信息化水平也有了很大的提高，在和用户沟通的过程中，出现最多的反而是“XX功能真不好用”、“首页加载这么慢”、“这个界面真不好看”、“这个功能不是我们要的”……这类偏用户体验的反馈。

美国著名质量管理专家J.M.Juran博士从客户的角度出发，提出了产品质量就是产品的适用性，即产品在使用时能成功地满足用户需要的程度。由此可见，软件缺陷少不再能够代表软件的质量高，而是仅仅成为了衡量软件质量的其中一项指标。

“好看、好用、bug少、能解决实际问题”是用户对软件高质量的最直接反馈。但是如何才能保证软件的高质量呢？

从开发的角度来看，软件需要达到高内聚、低耦合、代码简洁易懂。称之为软件的设计质量，具有外部不可见性，“高内聚低耦合”满足软件易于扩展、易于复用的要求，“代码简洁易懂”满足软件易于维护的要求。易于扩展和复用能够保证快速响应用户新需求，易于维护能够保证快速响应用户需求的变更。

协同办公系统（本文简称OA）基于公司通用开发平台、采用模块化架构思想建设而成。模块化架构思想从根本上保证了OA系统达到“高内聚低耦合”的建设目标，通用开发平台从基础层面确保了软件的产品质量。除此之外，项目组还重点从以下几个方面保证OA系统的高质量。

一、需求分析阶段

有这样一句话：“风险躲在需求的迷雾之后”。充分体现了需求分析的重要性，需求分析工作做得到位，就能为开发出优秀的产品奠定良好的基础，反之则有可能导致出现潜在的质量问题和业务价值的丧失。为了拨开“需求迷雾”，项目组在需求分析阶段做了大量的工作。

要求需求分析人员在与客户沟通的过程中避免使用计算机专业术语，要结合OA系统特性总结行业术语并在和客户的沟通交流中逐步学习客户“语言”。这样可以更大程度打破与客户之间的沟通障碍，为客户需求的收集和理解提供便利。

除却常用的通知公告、新闻、工作流、人力资源等通用模块，OA系统还具有强大的包容性，可以更大限度的容纳客户个性化需求，因此要求需求分析人员能更好地理解客户的业务，必要时采用驻场等方式观察客户实际工作流程。如系统开发过程中为满足客户对督查督办业务的需求，项目组派专人负责直接与客户督查室工作人员保持密切的联系，及时收集分析用户需求并反馈给开发人员。

即使是通用模块，在面对大量客户的时候也难免会遇到个性化的要求，对此项目组在保证系统稳定的前提下积极响应并尽量满足用户。极力把OA系统打造成一款适用于客户、让客户满意的产品。

二、实现阶段

软件实现阶段的主要活动包含：详细设计、编码、测试，是软件项目过程中工作量更大、历时最长、细节最多的阶段。如果保证实现阶段各项工作的开展，是确保产品高质量的重中之重。在实现阶段，项目组主要采用以下原则做到质量保证。

对于简单需求，关注重点集中在编码和测试，尽量弱化详细设计，避免耗费大量时间做无用功。

需要做的详细设计也把侧重点放在领域模型设计、业务流程设计、数据库设计、核心算法设计，并在需求变更的时候优先调整详细设计避免设计与实现脱节。

代码规范基于阿里巴巴java编码规范结合具体情况进行调整，使之更符合项目组的要求，比如：要求类、 *** 、变量等的命名严格使用能代表实际意义的英文或缩写；简化对代码注释的要求，只有复杂的算法逻辑才要求必须添加注释。

进行不定期code review，代码走查人员不局限于固定的项目成员，而是采用互查的方式进行，通过这种方式可以让项目组成员学会阅读代码，发现好的编码思想和算法逻辑，也能发现别人代码中的不足以给自己警示，最终达到全员开发能力的提升。

要求开发人员对自己负责的功能做到单元测试，并根据业务的变化及时调整测试用例，也为代码重构工作的开展提供保障。