机械制造业经过上百年的发展，已经是一个非常成熟的产业了，她的每一个步骤、每一道工序都有非常明细和严格的标准，软件业相比机械制造业还是一个处于发展行业，尤其是在中国。软件工程的出现就是为了将软件开发工程化，并确保软件过程正确执行。规范软件过程的目的就是提高产品的质量，降低个体的不确定因素对软件质量的影响，将软件开发至于受控状态下。
很多人认为“软件开发是一项智力密集、创造性成分较高的劳动”，因此会产生许多非受控的因素，造成软件开发标准规范的贯彻执行在实际中都会碰到困难。我认为软件开发和其他行业一样，对质量的保证都是一个管理问题，从这一角度讲，需要遵循的基本原则和面向的对象没有什么不同，过分强调软件开发的特殊性其实是软件行业尚不成熟的表现。
我们可以借鉴制造行业的质量管理体系，反思一下软件开发过程的问题。制造业拥有长久的历史，形成了一套行之有效的管理模式、规范以及质量管理体系，更重要的是这种观念和意识深植于制造业从业人员心中----不论是大型的企业还是只有一二百人的小厂，都会有自己详细的流程、制度，并良好运转且大家习以为常----正是因为这种现象的存在，才使我有了剥析一下软件开发过程的想法。
当一个机械制造企业需要开发一个新产品时－这个产品可能是一种新型步枪，也可能是新一代的运载火箭，大致可以分为这样几个步骤：
1、首先，是对新产品的功能、技术性能（指标）等的定义；
2、其次进行产品的总体设计、分系统或模块的划分，设计各接口之间的关系或依赖条件等等，还包括部分的尺寸、重量等等具体的技术指标，完成总体蓝图以及设计计算说明书；
3、然后进行的是分系统的设计－产生分系统的蓝图、设计计算说明书，为简短起见，我把具体的零件图完成也加在这部分；
4、组织加工。这个阶段完成零件工艺线路、工卡量夹具的设计，零件的加工，产品的装配；
5、系统的联调。
6、产品的定型或提交；
整个的阶段过程大致如此，我们可以看一下，与软件开发的步骤非常相似，完全可以将1、2、3、4、5、6分别对应到需求分析、概要设计、详细设计、编码与实现、测试、发布。在一个机械产品开发过程中，同样有与软件开发过程相对应的职责与角色，如果有必要，可以进一步讨论。我个人认为，两者最大的区别可能在于机械产品开发过程中“工艺线路、工卡量夹具的设计”可能没有相应的步骤可以对应，这也是造成机械产品开发过程中4步骤所占周期远大于编码与实现阶段的原因，不过我想这不是一个问题的主要层面，不会对问题的讨论产生影响（其实“工艺线路、工卡量夹具的设计”也是一个小的产品开发过程）。
制造业不是一个“智力密集、创造性成分较高的劳动”吗？如果我们了解了一个产品的开发过程，恐怕会说"Yes"，只不过我们经常在流水线的轰鸣声中忘记了一个背后的事实----任何产品，包括生产线本身，都是人类创造性的结果。其实不止是制造业，电子行业、建筑行业等等，都属于这种情况。
这里说了这么多，只是想说明对于质量的管理、控制，不是哪一个行业或哪一些人面临的孤立问题，而且万变不离其中，任何成功的模式同样适用于我们自己。还是让我们来看一看制造业如何进行过程的控制吧。
上面的6个步骤，只是一个开发的流程，对于质量的保证是随处可见的，我也仅仅举几个例子而已。
一、规范的制订和执行
规范在制造业称为标准，按不同等级有国标、部标甚至企业自己的标准。
1、规范的产生
制造业的规范和标准由来以久，现在已经是整个行业的标准，这也是一个行业成熟的标志，标准约束的不仅仅是内容的表示方法，而且包括表示的格式，在一张设计图中中绝对不会出现别人看不懂的符号，而且这些符号的写法、位置甚至字体都是相同的（这一点任何学过机械制图的人都应有所体会，程序员的code 格式不也是这样吗，很多公司制订了自己的标准，不过离行业标准还有一定距离）。
2、规范的执行
没有那一个机械工程师会认为这个规范没有必要，每个人都会认真的执行----感谢我们的老师在教学中的严格要求。在国内的软件行业规范执行的并不严格，是不是和教师的认识和身体力行有关。
3、检查
规范的执行仅仅有执行的自觉自愿是不够的，严格的复查必须存在。在制造企业通常有标准化检查的部门（小一点的企业也有专人负责），检查的内容无非是设计图纸、计算说明书中的标准执行情况，看看你的设计是否符合国标、部标、企业标准，和软件公司中QA的角色类似，不过QA还有一些对过程执行情况的检查，而标准化检查仅仅关注于标准化的执行。标准化检查拥有一票否决权，他可以让你修改、返工----想一想在自己的软件开发过程中，如果QA指出你的code大括号的位置不对，你是否不屑一顾，甚至你的公司中有没有人检查你的编码格式等等。
二、设计的复查
上面我说了，制造行业中4、组织加工 这一步骤可能耗费大量的人力、物力，因此对设计的复查十分重要。复查可能包括：重新校核、计算你的设计说明书，检查你的设计图纸等等（机械的术语我就不多说了），总之一个目的，尽可能减少进入加工阶段的设计缺陷。因此在所有设计图纸和计算说明书上，都可以看到设计者、校核者、批准者的签名，仅仅签名一项就是很麻烦的事，由此可见在这方面投入的精力----想一想在自己的企业中是否对概要设计、详细设计进行了细致到function的设计复查，其实大量的缺陷在这一过程中被发现、纠正，也许是因为软件的code阶段对资源的要求比较小，才养成了很多人的不良习惯，先code再说。
三、测试的问题
这个标题并不准确，因为制造业没有明确的测试提法，我是套用软件行业的术语表示问题。不过这没有关系。
其实在4、组织加工 5、系统的联调的阶段都有测试的内容。加工中可能出现零件的设计不合理，部件无法装配等等错误，即使有了复查这些错误也无法全部避免。系统联调可以发现产品的某些技术指标不能达到要求。系统联调的测试很多都有标准可循，可以说有很多标准的测试用例，不过更多的测试方法和手段的实现是在系统设计过程中并发进行----想一想你的企业中是否还是由程序员自我测试，至多是交叉测试，有没有在概要设计的同时设计测试用例和测试方法，测试用例的选取是否与需求紧密结合能够覆盖需求。
四、图纸档案的管理
还是叫配置管理吧，大家比较习惯。
设计工作结束后，设计图纸和计算说明书都必须归档，因为设计图纸必须晒图才能长期保存，可能这使归档的工作更容易完成了。设计的复核都是针对晒过的图纸，也就是归档后的图纸，如果发生错误，对不起，小的错误可以在图纸上改过，但是每一处修改都必须注明修改的位置、内容、修改时间、修改人，而且还要有人复核、批准，如果没有这些，图纸档案的管理人员就不会同意，你无法归档，不要说奖金，饭碗想一想再说。要是大的错误，只好重画、重写设计说明书了。在加工过程中难免发生错误，修改的过程大致一样，由于有了专职的图纸档案管理人员和严格的制度，自然有效解决了版本控制的问题，没有哪个制造企业找不出几年前某个产品的设计图纸，甚至当时的设计者作了什么，有那些错误等等都一清二除。这样不仅仅控制了版本，而且为设计复用提供了保证。
其实改图纸和设计说明书是很痛苦的事，在手工绘图的时代，需要做大量的重复性劳动，另外很多人要对无数张图纸重新审查、签字认可。即使现在CAD的应用，可能还需要到各处去修改发出的图纸，能跑细你的腿。相比之下，软件开发中的管理可以借助很多工具，已经简单了很多，看来关键是制度的建立、实施和检查----想一想是否有人告诉你，应该从谁那里拿到设计文档，修改了已经版本化的code后我应做哪些工作，这很多东东我以为应该是新员工培训的一部分。
五、需求的管理
制造行业中大多产品的需求是以规格、功能、性能指标的形式出现，客户和厂家对此都非常重视，所以一般比较明确。对这一点我的理解不深，希望大家发表看法，不过窃以为，正是甲乙双方对需求的不重视，才会出现需求的频繁变更和难以控制。
六、设计的重用
在机械设计中，经常可以看到，借用某零件图、某部件图的现象，正是因为良好的设计文档（对产品的良好描述）以及配置管理，才能作到这一点----想一想你是否希望copy别人的代码，但是看了半天code，最后还是决定自己去写。不过设计的重用一个比较难以解决的问题是对产品的描述。
软件开发的质量管理实际上可以分为工程人员工程素质的提高和制度体系建设两部分。对于小企业前者是关键，由于人力物力有限不可能有完备的质量管理体系，更多依赖开发人员自身的素质保证，因此在团队建设的初期应该加大工程素质的灌输力度，通过代码复查等手段严格要求；对于大一些的企业，在提高开发人员工程素质的基础上，应着重于制度建设，从上直下的建立起一套固定的制度、流程，并与管理人员、开发人员、保证人员紧密结合，使之成为自觉。
在制度建设中不应过度的强调人文精神，因为体系、制度、规范的建设，其目的是：将个人的创造性集中在设计、开发本身，最大程度的减少在流程、表现形式等方面的个人发挥（或随意性）。简而言之，将个人的创造性发挥在需要的地方。
文章来源于领测软件测试网 https://www.ltesting.net/
