作为一个软件工程师，我们天天生产着代码。看着满天飞的软件技术。突然回过头来看看，感觉到迷茫的走了很多路，缺少了思考。
- ISO9126软件质量模型
ISO9126软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成，在工作中需要从这些特性和子特性去设计和实现一个软件。这个模型也是软件质量标准的核心，对于大部分的软件，都可以考虑从这几个方面着手进行测评。
- 软件质量铁三角
流程：从计划到策略的实现，流程就是按照这种思维方式指导软件开发的，并且流程来源于成功的经验，可以指导项目少走弯路，从而提高软件质量，不仅如此，流程还对项目的成本和进度控制有很大的帮助
技术：包括了分析技术、设计技术、编码技术、测试技术，需求是项目的灵魂，良好的需求分析便是项目成功的关键所在，若是需求分析做不好不可避免的要出现返工；设计，软件的质量是设计出来的，良好的设计基本上决定了软件产品的最终质量；编码技术产生正确高效的代码；测试是保证软件的一道防线。所以各种技术对质量来说都是很重要的
组织：好的组织可以有效的促进流程的实施，同时提供员工的发展通道以吸引更多的人（技术的载体）
- 软件质量的思考
质量是设计出来的还是测试出来的？针对这个问题有这样一组讨论：
A同学：我认为质量是设计出来的，在设计上考虑的各种功能和非功能质量数据，都会落地到代码中。设计的优化会不断的驱动系统质量的优化。
B同学：我认为质量是测试出来的，设计的东西可以避免已知的问题，但在实际测试的过程中，还是会发现其他未考虑到的问题，例如与软硬件兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动质量提升。
C同学：听完B同学的发言，我更坚信了质量是设计出来的。在不断的BUG驱动下，我们打补丁式做出来的系统，质量会更好吗？打补丁解一时之急，而后续系统性的设计、重构、升级，才是提升质量的关键点。
D同学：如果站到产品层面，我们会怎样去定义产品好不好？在我们定义产品好坏的质量模型里，很可能会包含软件研发相关的非功能质量属性(ISO9126)，可能会包括产品舆情、竞品对比中挖掘出的东西。例如，我们去定义一款内容推荐产品的好坏，除了“内容不重复”、“多样性”等维度外，“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准，新功能上线、满足需求，用户就会认为产品好。我们的认知会不断升级，“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈，让质量不断变好。
针对以上看法，其实是给出了针对软件质量的集中观点：
谋而后动的观点：无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析，都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。
探索式测试的观点：无论是保证在设计变成代码的过程中是否100%的完成翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是希望所见即所得，想人之未想。B同学说得也对。
技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的升级，还是对基建能力进行优化，都是希望能够打好底盘，走的更远，走得更稳。C同学靠谱。
持续改进的观点：无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情，都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。
- 项目生命周期中的质量
需求阶段：检验质量的主要标准只有一个：满足使用者的实际需要。需要挖掘客户真实需求以及应用场景，做到用户常用爱用的功能或者功能点准确易用好用
设计阶段：在设计上正确理解客户的功能性需求，考虑的各种非功能需求以及异常场景的处理
开发阶段：选取合适的软件架构，做好代码审查，编写单元测试代码，进行单元测试、集成测试
测试阶段：依赖覆盖面充分的测试用例，注重系统测试、用户验收测试
运维阶段：及时收集、处理版本发布后客户反馈的市场缺陷，更新补丁，确保问题闭环，遵循PDCA循环持续改进
其实质量既是设计出来的，也是测试出来的，还是被逼出来的！
参考文章：https://zhuanlan.zhihu.com/p/40138584
欢迎关注【技术型项目经理】公众号。可获取软件行业动态、技术积累和项目管理理念文章分享。可在菜单中选择获取「PMP」、「高项」（信息系统项目管理师）、「CISSP」、「Python」、「GoLang」、「C++」学习资料。
有疑问加站长微信联系（非本文作者）
