项目管理三角形中定义了项目的范围，质量，进度和成本之间的关系。对于软件开发项目而言，在整个项目过程中，监控项目的质量是一个比较重要的环节。尤其对于项目经理的每周项目报告中，除了对项目进度进行更新之外，还需要对项目质量做一定的阐述。
项目质量监控大致可以从两方面入手。
第一，在开发过程中，交付测试前的开发质量监控
当前项目正处于开发阶段。每天开发人员会提交自己当天改动的代码到服务器上。此阶段可以依靠第三方工具，制定脚本，在半夜逐行扫描代码。具体可以根据如下指标进行判定。（当然每个项目有自己的特殊性，莫斯在这里只是抛砖迎玉，也欢迎大家留言补充。）
1. Coding Rule
无论用什么语言写的代码，只要是代码，必然后他自己的coding rule。开发成员是否都遵循了Coding Rule？那些代码违反了Coding Rule？如果每天都扫描所有代码，必然可以在最短的时间内找出不符合Coding Rule的代码行，第二天进行改正。
这点对于刚毕业的学生尤为重要，因为从大学到工作，最本质的变化是原本代码一个人写，现在代码一个团队写。如何提高代码的可读性是通过Coding Rule来实现的。而这点在刚毕业的大学生身上比较欠缺。在大学期间没有遇到别人读自己代码的情况，所以好习惯最好从一开始就养成。今后就会自然而然的规范起来。
而站在项目角度，很多时候项目中的代码会有很多人在不同时间去读，只有写的符合规范的代码才能够使得其他成员不花力气也能理解。
2. UT 覆盖率
UT 又叫单元测试，对于一个方法，一个函数，根据不同的输入，得到预期的输出的一种测试方式。一般情况是有开发人员自行撰写UT用力。现在一些成熟的IDE都可以提供自己生成部分UT。这是对于开发人员代码质量的自我检测。
通俗地讲，一个方法，一个函数写出来都是有用途的。对于不同的输入，输出也是可以预期的。只有开发人员在撰写之初就想清楚了，写明白了，才不至于应用的时候出现差错。
另一方面来讲，UT测试的好处在于在开发阶段就进行了局部范围内的边界测试。从而可以提高代码的强壮程度。
UT的覆盖率即综合所有代码中的函数而言，有百分之多少是通过UT测试代码的一个指标。UT覆盖率高，代表着通过计算机运行的结果和预期设定的符合的比率高。
3. 代码复杂度
代码复杂度是指一个函数中使用if/else,switch等条件语句嵌套的次数。如果嵌套的越多，说明代码越复杂。
而对于一个函数而言，原则上是一个函数只做一件事情。代码复杂度越高的函数说明函数越复杂。而越复杂的函数根据面向对象的设计原理，是建议拆分成多个简单的函数的。
4. 其他指标
比如网页响应时间，耐压程度，能同时响应多少个用户同时访问等等。这对于一个网站，尤其是电商而言也是至关重要的。试想一下，淘宝双十一的时候，是不是那几秒总是很卡？那是因为整个服务器在那几秒里承受了几亿用户同时的点击。所以不是他们做的不好，实在是太多人同时操作了。
所以这类的指标是规定了网站同时访问的上限。
第二，在交付测试后的缺陷修正和更新质量监控。
这个阶段是在开发完成之后，通过了冒烟测试，达到了测试阶段的开始要求。又测试团队开始接受测试后的质量监控。主要分为两个方面：
1. 返工率
指测试进行测试后，发现缺陷后，由开发重新修正的次数。
有一句话叫做缺陷往往存在于曾经发生缺陷的地方。
意思是当某个地方发生缺陷时，说明有些方面开发没有考虑到。而开发在修正缺陷的时候，有很大可能没有完整的考虑问题，从而导致修正过缺陷的地方再次找到缺陷。
2. 针对单一功能的缺陷率。
之前我们有一个文件叫做RQM。主要是需求功能，和对应设计的一个矩阵。实际上RQM后面还有其他的列项，这里主要讲两个：
a. 根据需求撰写的测试用例。
如果说需求功能和设计是一对一的关系，那么这一列需求对应的测试用例就是一对多的关系，一个功能会有多个测试用例用于验证这个功能。
从中可以得知，每一个功能都有一个或者多个用例用于验证功能的正确性。
b. 每一轮测试的测试结果。
对于每一轮测试，每一个测试用例都会有一个结果，即通过或失败。合在一起对于每一个功能都可以有一个测试通过率。
如果通过率是100%那么证明该功能没有问题。
如果一个功能有5个测试用例用于验证，而只通过了2个，则通过率为40%。那么说明该功能还远没有达到交付上线的要求。还需要修复缺陷再次测试。
事实证明，只有对于软件类项目的质量监控不是仅仅增加测试环节。是需要从开发过程中就严格监控的。原因在于如果开发的代码质量就很差，那么最终交付测试的成品也好不到哪里去。这就和造房子打地基一个道理，地基不打打牢，房子是不会稳得。稍有风吹草动就轰然倒塌。
只有在开发过程中，每天严格按照要求保证每一行代码都是符合要求的高质量代码。最后在配上测试双保险，才能够杜绝豆腐渣工程，保证项目质量从一而终的达到要求。
