软件Software开发为何不能像硬件开发那样可控？软件Software质量的旅将带给我们些启示

　　提到软件Software产品开发我们脑海里总是浮现出这样情景:开发组每位成员都在辛苦地工作加班加点甚至通宵达旦虽然项目经理(project manager)次又次地修改了进度计划而实际开发情况却总是令人担忧以至于每次向领导汇报工作时候总是觉得以前制定计划没有很好完成总是觉得人力资源不够总是觉得没有太多时间等到代码终于开发完成了测试进度同样非常令人担忧每个小BUG都要花很长时间去查找改了某个小却又引起了很多新结果产品发布遥遥无期而项目组里每位成员已经筋疲力尽

　　怎样摆脱这样困境？为何软件Software开发项目管理(project management)这么困难？为何我们做计划总是不能按时完成？为何软件Software开发不能像硬件开发那样可以控制？

　　软件Software开发是完全依靠人大脑思维产生出产品而每个人大脑思维是不样因此在软件Software开发过程中有太多不确定、可变化原因那么我们怎样把握住这些变化原因呢？

　　软件Software项目管理(project management)——质量先行如果我们能够控制软件Software生命周期每个阶段质量就能很好地控制了软件Software开发整个过程

　　软件Software产品质量是个很大概念软件Software产品完全是人们大脑思维产物是将大脑里无形思维变成可以解决实际问题组界面或者组件在这样个复杂过程中应该如何保证质量呢？有人想到了ISO9000、CMM也有人提出反对意见认为应该用敏捷开发其实不管用什么样开发过程关键是找到这些过程本质

　　有人说ISO和CMM到中国来如何就变了味了？其实我们只学到了怎样去做但是不知道为什么要这样做大家都知道在产品立项的前要写市场分析报告但不了解为什么要写市场分析报告重要性有多高？不是资深开发人员很难理解其重要性如果是简单地去写篇形式上文档那么除了负担的外就没有其它用途了

　　有些人又想到了测试觉得是我们测试力度不够所以产品质量不过关

　　其实软件Software开发质量保证从最初就应该开始了如果到了测试阶段才重视就已经晚了软件Software产品开发过程不管采用瀑布式模型还是迭代式模型都离不开需求、设计、编码、测试这几个阶段在迭代式开发中这几个阶段也是周期性出现

　　怎样把握好每个阶段质量确实不是件容易事对于软件Software产品测试不管是单元测试还是集成、系统测试这方面介绍已经很多了因此笔者重点介绍下需求、设计和编码阶段质量保证

　　让我们开始次质量的旅吧第站就是需求分析

　　在需求分析过程中如何进行质量保证呢？我们平时可能更多地关注需求本身却忽视了个很重要原因那就是市场我们开发出来产品是直接面向市场如果费了很多人力物力开发出来个没有市场前景缺乏竞争力产品那么所有努力都是白费如何充分考虑市场原因具体可以从以下几个方面进行

　　首先判断需求是否符合愿景目标所谓愿景目标就是我们开发出来产品能够给我们用户带来什么样好处？如果有些需求没有被包含在愿景目标里那么这样需求其实就背离了我们开发产品初衷其次判断产品需求能够给企业带来多大利润如果某个需求只是代表个别用户需求并不能给企业带来较大利润但又花费甚高就可以考虑删除最后和竞争对手相比核心竞争力有哪些？如果核心竞争力不够就应该考虑重新进行需求分析如果没有核心竞争力开发出来产品就没有市场

　　在排除了市场原因产生风险的后我们应该保证需求描述质量人和人交流总会存在些误会同样句话心情不好和心情好时候听起来可能会截然相反正是人们的间存在着理解上偏差在描述需求语言上就应该注意尽量避免歧义产生如果对UML比较熟悉话需求分析可以利用UML工具进行这样可以减少些自然语言引起歧义但是并不是所有用户都了解UML各种图形意思和用户沟通起来存在障碍除了工具的外我们可以从以下几个方面来保证需求描述质量

　　首先看句子和段落是否简短长句子看起来会非常困难很难弄懂真正需求:另外过长句子和段落容易让人忽视些需求所以如果个句子不能完全描述清楚需求应该将其拆分成多个小句子

　　其次句子是否有语法还要注意标点符号有时标点符号点错了就完全成了另外个意思再次是否存在模糊不清需求出现“可能大概或者”等词汇表述

　　最后注意是否存在形容词及比较性词语比如:容易、快速、方便、有效、许多、很少、简单、复杂、最新、界面友好、减少、扩大不小于等等需要将描述性词语进行量化并且给出具体值或者范围

　　另外保证需求质量个很重要原因就是需求是否细化如果需求不细化就很容易造成代码返工出现员尽管加班加点却总是不能如期完成任务情景怎样才能判断需求细化程度呢？需求细化程度确实很难把握什么样需求可以算是比较细了不用再进行细化了呢？

　　答案是:是否可以将需求写出相应测试用例如果写不出来就介绍说明需求还不是很细还需要进步进行细化

　　把握住了需求分析这关下站我们就可以进行设计了

　　软件Software架构设计在软件Software产品开发周期中占有很重要位置我们开发出来软件Software产品在开发伊始到产品发布会涉及到方方面面角色

　　例如:用户、项目管理(project management)人员、员、测试员、维护人员等等区别角色对架构设计要求也不相同对于员来说更关注模块是否清晰类功能是否单等等对于测试人员来说关注是系统可测试性对于维护人员来讲系统扩展性、可维护性如何？

　　个高质量软件Software架构应该最大限度考虑并满足区别角色区别要求因此我们在进行软件Software设计时候应该进行全面考虑般用来衡量软件Software设计质量标准可以从以下几个方面来考虑:

　　◆功能性

　　包括完全性、正确性、安全性、兼容性、互用性

　　◆效率

　　产品运行时间效率和利用硬件资源两方面

　　◆维护性

　　包括架构可改正性可扩充性以及可测试性如果用户个很小需求变更会引起架构设计很大变化那么这样架构设计可改正性和可扩充性就比较差

　　◆可移植性

　　包括硬件独立性、软件Software独立性、可安装性、可重用性软件Software设计是否模块化、可复用性都是应该考虑原因

　　◆可靠性

　　包括无缺陷性、容错性、可用性

　　◆使用性

　　包括可理解性、易学习性、可操作性、易沟通性我们软件Software最终目是让用户来使用如果易用性不好可操作性不好都会影响用户对软件Software接纳程度因此软件Software可用性也是非常重要

　　完成了设计的后接下来就要进行编码了在编码阶段应该怎样保证我们编码质量呢？两个比较有效思路方法就是代码走查和单元测试

　　代码走查可以以组为单位进行代码走查可以发现代码是否符合代码规范标准是否存在拼写是否具有可读性类和思路方法是否过于冗长类的间是否存在高耦合性

　　代码质量个很重要标准就是代码可读性可读性不定是简单代码而是容易理解代码过于复杂代码难以测试和维护同时出错几率也会更高

　　如果个思路方法内部代码很长而且使用了很多令人难以理解数据集就会带来代码维护困难很少有人能够有效地分析它们因此也就最容易出现缺陷和类的间耦合度会造成类和类的间相互关联当个类发生改变时会使其他类发生意想不到变化般从导入类个数判断类的间耦合度如果导入类个数很多或者该类public思路方法太多都会导致类的间高耦合性增加



　　编码阶段另个非常重要手段就是单元测试单元测试是个模块功能及常规测试单元测试是由员进行般单元测试能够捕获80%bug因此单元测试对保证代码质量方面占有很重要地位由于这方面内容比较多我们这里就不做具体阐述了

　　好了经过了这样次质量旅行我们对软件Software开发是否增加了很多信心呢？当然软件Software项目管理(project management)还有很多其他原因但是如果每个阶段都能够很好控制质量就会在产品开发初期减少很多风险从而使我们软件Software开发在个可以控制范围内进行这样我们才能够避免过多没有必要人力物力浪费从而使我们产品更快更好投入市场