质量管理：软件开发各阶段的质量管理

说到软件开发，我们脑海中总会浮现出这样的场景:开发团队的每一个成员都在努力工作，有些成员加班甚至熬夜是常事。虽然项目经理一次次修改进度计划，但实际发展情况总是令人担忧，以至于每次向领导汇报时，总觉得之前的计划没有完成好，人力资源不够用，我们时间不多。最终开发出代码时，测试进度非常令人担忧。每一个小BUG都要花很长时间去发现，一个小错误改了却造成很多错误。结果就是产品发布遥遥无期，项目组的每个成员都疲惫不堪。
怎样才能走出这个困境？为什么软件开发项目管理这么难？为什么我们总是不能按时完成计划？为什么软件开发不能像硬件开发一样可控？原因是软件开发完全依靠人的大脑思维来生产产品，每个人的大脑思维都是不一样的，所以软件开发的过程中有太多不确定和可变的因素。如何才能把握这些多变的因素？正如我们的题目所说，软件开发的质量管理结果在每个阶段，如果我们能控制软件生命周期的每个阶段的质量，我们也能控制软件开发的整个过程。
软件产品的质量是一个很大的概念，因为软件产品完全是人的大脑思维的产物，即把大脑中看不见、摸不着的思维变成看得见的、能解决实际问题的一套接口或组件。如此复杂的工艺，如何保证质量？一些人想到了ISO9000和CMM，而另一些人反对，认为应该使用敏捷开发。其实不管用什么样的开发流程，关键是要找到这些流程的真谛。有人说ISO和CMM来了中国就变味了。为什么他们改变了他们的口味？其实我们只学会了怎么做，不知道怎么做。我们为什么要这么做？大家都知道软件开发需要写需求说明书和设计文档。你为什么写它们？文档有多重要？没有开发和管理经验的人可能很难理解它的重要性。如果只是简单的形式去写这样的文档，对后期的编码和测试没有实际的指导作用，甚至起到“误导”的作用，而且还会造成大量的返工，那么这些文档除了负担就没有别的用处了。有必要知道，编写这些文档会消耗项目团队的资源(进度、成本...).
很多人又想到检测，认为我们的检测不够强，所以产品质量不过关。其实软件开发的质量保证应该从开发之初就开始，等到测试阶段再重视就晚了。软件开发过程，无论是瀑布式还是迭代式，都离不开需求、设计、编码和测试。在迭代开发中，这些阶段也会周期性地出现。如何把握好每一个阶段的质量，真的不是一件容易的事情。这个问题集中在需求、设计和编码阶段的结果质量。当然，以后还会分享一些关于工序质量的知识。
1。需要
我们知道，人与人之间的交流，总会有一些误会。同一句话，心情不好的感觉可能和心情好的感觉完全相反。正是因为人与人之间的误解，所以在描述需求的语言上，要尽量避免歧义。如果熟悉UML，可以使用UML工具进行需求分析，可以减少一些自然语言带来的歧义。但是，UML与用户交流可能会有一些障碍，因为不是所有的用户都知道各种UML图形的含义。除了工具，我们还可以从以下几个方面来保证需求描述的质量。
1。看句子段落是否短。长句子会看起来很难，所以不能理解真正的需求。另外，太长的句子和段落很容易让人忽略一些需求，所以如果一个句子不能完全描述需求，就要拆分成几个小句子。2.如果句子中有语法错误，要注意标点符号。有时候，一个标点符号错了，就完全变成了另一个意思。3.是否有模糊的需求，是否有类似的需求用可能、大概等词语表达。4.还要注意引用的术语和词汇是否一致。5.有没有一些形容词和比较级的词，比如:容易、快速、方便、有效、多、少、简单、复杂、最新、界面友好、减少、扩大、不小于等。？描述性文字需要量化，要给出具体数值或范围。否则不同的人根据不同的理解会得到不同的结果，最终可能满足用户最初的要求。
另外，保证需求质量的一个很重要的因素就是需求是否详细。如果需求不详细，很容易导致代码的返工。所以，我们的程序员即使总是加班加点，也无法按期完成任务。那么如何才能判断需求细化的程度呢？需求细化的程度真的很难把握。什么样的需求才算是相对细化，不需要细化？有哪些需求太厚？答案是需求能不能写出相应的测试用例。如果写不出来，说明需求不是很详细，需要细化。
2。设计
软件架构设计在软件产品的开发周期中起着重要的作用。从开发开始到产品发布，我们开发的软件产品涉及各种角色，比如用户、项目经理、程序员、测试人员、维护人员等等。不同的角色对架构设计有不同的要求。比如用户关心需求，那么我们的设计对需求的覆盖率是多少？对于程序员来说，模块是否清晰，类的功能是否单一等。，对于测试人员来说，系统是可测试的。对于维护人员来说，系统的扩展性和可维护性如何？一个高质量的软件架构应该限制考虑，满足不同角色的不同需求。因为这些要求，我们在设计软件的时候要综合考虑。一般来说，衡量软件设计质量的标准可以从以下几个方面来考虑:
1)功能性:包括完整性、正确性、安全性、兼容性和互操作性。性完全包括功能点覆盖、关键功能点覆盖和优先功能覆盖。包括需求的正确性和一致性。根据安全软件的不同需求，有不同的安全需求。
2)、效率:包括产品运行的时间效率和使用的硬件资源。
3)可维护性:包括架构的可修正性、可扩展性和可测试性。如果用户需求的小变化会引起架构设计的大变化，那么这种架构设计的可修正性和可扩展性就会很差。
4)、可移植性:包括硬件独立性、软件独立性、可安装性和可重用性。软件设计是否模块化，每个模块的可重用性都是要考虑的因素。
5)、可靠性:包括缺陷数量、容错性和可用性。
6)、可用性:包括可理解性、易学习惯、可操作性、易交流性。我们软件的最终目的是让用户使用它。如果可用性和可操作性不好，会影响用户对软件的接受度。所以软件的可用性也很重要。
3。编码
代码质量的一个非常重要的标准是代码的可读性和标准化。可读性不一定是简单的代码，而是容易理解的代码，因为太复杂的代码很难测试和维护，出错的概率会更高。如果一个方法内部的代码很长，使用了大量不可理解的数据集，会给代码维护带来困难，因为很少有人能有效分析，所以最容易出现缺陷和错误。类之间的耦合度会造成类之间的相关性。当一个类发生变化时，其他类也会有意想不到的变化。一般通过导入类的数量来判断类之间的耦合程度。如果导入的类很多，那么每个导入类的变化都会影响到类本身。另外，如果类的公共方法太多，类之间的高耦合度也会增加。
可能有些程序员觉得写可读性强、标准的代码会影响工作进度。诚然，单个程序员在短时间内为代码编写注释需要一定的时间，但如今，软件开发是一个漫长的多人协作的过程
。写过程序的人都知道，如果写非标准代码，随着他写的代码越来越多，当他需要修改之前写的一个模块时，他不知道自己一开始是怎么想的，而且要花很长时间去读自己的代码。而且，如果由于人员调动等其他原因，经常维护代码的程序员不是当初写代码的人，很多情况下，读一个不好的代码比重写代码要花更长的时间，严重影响工作效率(有时还会影响维护人员的心情)。另一方面，如果每个人都注意以标准和可读的方式编写代码，这对整个组织提高整体工作效率无疑是非常有用的。
代码质量的另一个非常重要的衡量标准是测试。我们可以简单的从一个方面来评价代码质量，通过统计测试代码产生的缺陷，比如严重程度的分布，缺陷曲线的变化。