﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>C++博客-It is just c plus plus.-随笔分类-Software Engineering</title><link>http://www.cppblog.com/zmllegtui/category/13473.html</link><description>Nothing in my mind.</description><language>zh-cn</language><lastBuildDate>Fri, 09 Apr 2010 10:28:09 GMT</lastBuildDate><pubDate>Fri, 09 Apr 2010 10:28:09 GMT</pubDate><ttl>60</ttl><item><title>编写软件项目需求文档</title><link>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112087.html</link><dc:creator>zml_cnnk</dc:creator><author>zml_cnnk</author><pubDate>Fri, 09 Apr 2010 09:31:00 GMT</pubDate><guid>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112087.html</guid><wfw:comment>http://www.cppblog.com/zmllegtui/comments/112087.html</wfw:comment><comments>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112087.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/zmllegtui/comments/commentRss/112087.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/zmllegtui/services/trackbacks/112087.html</trackback:ping><description><![CDATA[<font><font size="3"><font face="Verdana">&#8226; 保持语句和段落的简短。<br>&#8226; 采用主动语态的表达方式。<br>&#8226; 编写具有正确的语法、拼写和标点的完整句子。<br>&#8226; 使用的术语与词汇表中所定义的应该一致。<br>&#8226; 需求陈述应该具有一致的样式，例如&#8220;系统必须⋯⋯&#8221;或者&#8220;用户必须⋯⋯&#8221;，并紧跟一个行为动作和可观察的结果。例如，&#8220;仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。&#8221;<br>&#8226; 为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说&#8220;用户友好&#8221;或者&#8220;快&#8221;或者&#8220;健壮&#8221;时，你应该明确它们的真正含义并且在需求中阐明用户的意图。<br>&#8226;
避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该&#8220;
处理&#8221;、&#8220;支持&#8221;或&#8220;管理&#8221;某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。由于需求的编写是层次化的，因此，可以把顶层不明
确的需求向低层详细分解，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的
需求影响了设计。如果你能用不同的方法来满足需求且这种方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客
户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。<br></font></font></font><font><font size="3"><font face="Verdana">&#8226;
编写可测试需求文档</font></font></font><font><font size="3"><font face="Verdana">。</font></font></font><font><font size="3"><font face="Verdana">需求文档的编写人员总是力求寻找到恰如其分的需求详细
程度。一个有益的原则就是编写单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求能够正确地实现，那么就达到了合理的详细程度。如果你
预想的测试很多并且很分散，那么可能就要将一些集合在一起的需求分离开。已经建议将可测试的需求作为衡量软件产品规模大小的尺度（Wilson
1995）。<br></font></font></font><font><font size="3"><font face="Verdana">&#8226;
</font></font></font><font><font size="3"><font face="Verdana">文档的编写人员必须以相同的详细程度编写每个需求文档。我曾见过在同一份软件需求规格说明中，对需求的说明五花八门。例
如，&#8220;组合键C o n t r o l - S代表保存文件&#8221;和&#8220;组合键C o n t r o l -
P代表打印文件&#8221;被当成两个独立的需求。然而，&#8220;产品必须响应以语音方式输入的编辑指令&#8221;则被作为一个子系统，而并不作为一个简单的功能需求。文档的编写
人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如&#8220;和&#8221;，&#8220;或&#8221;之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用
&#8220;和/或&#8221;，&#8220;等等&#8221;之类的连词。文档的编写人员在编写软件需求规格说明时不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这
也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，</font><font face="Verdana">在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。<br><br>================可有可无的分割线================<br><br></font></font></font>首先，应重视需求分析的目的（意义），编写目的明确，写的详细，能确保文档的质量有所提高。<br>下面是一段需求分析意义的范例，希望对大家有所帮助。<br><span class="Title">1.6进行需求分析的意义</span><br><font color="#ff6600">1.&nbsp;本说明书将对用户生产信息管理的业务、对系统要实现的主要功能、性能等需求进行全面地阐述，以便帮助用户判断所要开发的软件是否符合他们的要求。该说明书将在软件开发目标和需求方面为用户和开发者之间创建一个共同的基础和共识。<br>2.&nbsp;由
于需求说明书要有用户的审核、修改完善、认定的过程，在这个过程中可以使用户在软件设计之前广泛地征求各业务部门的意见、提出有关系统建设的建议、对自己
的需求和要求进行周密地思考，并要把这些意见和建议反映到用户需求说明书中。这样就能减少事后重新设计、重新编码和重新测试的返工行为。<br>3.&nbsp;用户需求的调查分析过程也是用户对自己的业务和管理进行总结和规范的过程，通过用户需求说明书把用户更加规范的管理反映到了软件开发中，从而使用户的管理更加完善和规范。<br>4.&nbsp;需求说明书是开发者进行软件设计的依据，软件设计要依据本说明书将进行系统分析、数据库设计、模块设计、接口设计、输入输出格式设计等。<br>5.&nbsp;需求说明书使开发者在软件进行设计和开发之前，能够充分了解和熟悉用户的要求，并判断这些要求是否有不能解决的技术问题，若有应提出一个用户认可的代替解决方案。以免出现设计出的一个目标不能在开发过程中实现的问题<br>6.&nbsp;在需求调查和分析期间可以搜集有关系统开发的有关原始数据和代码，以便在系统开发中建立开发环境时应用<br>7.&nbsp;在软件开发方面为用户和开发者提供一个标准，为系统开发结束进行确认和验收提供一个双方认可的依据。<br>8.&nbsp;便于软件的维护和提高，为软件维护和为今后对所开发的软件进行完善扩充提供进一步分析的基础。<br>总之，用户需求说明书的编写是软件工程中的非常关键的一个环节，用户说明书也是软件工程中的非常重要的一个文档。一个好的用户需求说明书不但能够提高软件开发的效率、保障软件开发的质量，而且有利于系统的验收和以后软件的维护及扩充。</font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 下面正式谈一下我对需求文档的一些写作思路：&nbsp;&nbsp;&nbsp; </p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
首先要对用户机构机构有清晰的了解，写出各机构所涉及的业务，画出相应业务的用例图；之后提取出相应的业务流程，画出相应的流程图。通过业务流程，即可抽
象出系统需实现的功能。再将各业务（功能）涉及到对象（如人员，物品等）信息描述出来，根据提取出的信息将功能以IPO表（即输入、处理、输出表）的形式
进行描述，逐项定量和定性地叙述对软件所提出的功能要求，详细的说明输入什么量、经怎样的处理、得到什么输出，并说明待开发软件应支持的终端数和应支持的
并行操作的用户数。需求文档的主要部分就这样完成了。</p>
<p>====================完全没有必要的分割线=====================</p>
<p>引用topic:<br></p>
http://www.javaeye.com/topic/178200<br> <img src ="http://www.cppblog.com/zmllegtui/aggbug/112087.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/zmllegtui/" target="_blank">zml_cnnk</a> 2010-04-09 17:31 <a href="http://www.cppblog.com/zmllegtui/archive/2010/04/09/112087.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>软件项目可行性分析的要素</title><link>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112058.html</link><dc:creator>zml_cnnk</dc:creator><author>zml_cnnk</author><pubDate>Fri, 09 Apr 2010 05:32:00 GMT</pubDate><guid>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112058.html</guid><wfw:comment>http://www.cppblog.com/zmllegtui/comments/112058.html</wfw:comment><comments>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112058.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/zmllegtui/comments/commentRss/112058.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/zmllegtui/services/trackbacks/112058.html</trackback:ping><description><![CDATA[<font size="3">
<p><font face="Verdana">做可行性分析不能以偏盖全，也不可以什么鸡毛蒜皮的细节都加以权衡。可行性分析必须为决策提供有价值的证据。<br><br>联想集团领导人柳传志曾说：&#8220;没钱赚的事我们不干；有钱赚但投不起钱的事不干；有钱赚也投得起钱但没有可靠的人选，这样的事也不干。&#8221;柳传志为决策立了上述准则，同时也为可以行性分析指明了重点。<br><br>一般地，软件领域的可行性分析主要考虑四个要素：经济、技术、社会环境和人。本节只是泛泛地解释这四个要素，旨在建立全局分析的观念。4.2节将结合案例围绕上述要素进行重点分析与评注。</font></p>
<p><font face="Verdana"><strong>经济</strong><br><br>经济可行性分析主要包括：&#8220;成本——收益&#8221;分析和&#8220;短期——长远利益&#8221;分析。</font></p>
<p><font face="Verdana">一、成本——收益分析<br>成本——收益分析最容易理解，如果成本高于收益则表明亏损了，如果成本大大高于收益那就亏大了。商人都不喜欢做吃亏的事情。有些商店成天贴着&#8220;最后一天跳楼大拍卖&#8221;的标语，意思是：我准备吃大亏让你占便宜，同志，你快上钩吧。<br>如果是为客户做软件项目，那么收益就写在合同中。如果是做自己的软件产品，那么收益就是销售额。<br>人们在预估产品销售额时常常过分乐观而犯下大错。那些对你的产品说恭维话的人并不见得就是要买货的人，俗话说&#8220;嫌货才是买货人&#8221;。当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时，就要做好会破产的心理准备。<br>如果做的是小本生意，那可得对成本进行细算。软件的成本不是指存放软件的那张光盘的成本，而是指开发成本。要考虑的成本有：<br>（1）办公室房租。<br>（2）办公用品，如桌、椅、书柜、照明电器、空调等。<br>（3）计算机、打印机、网络等硬件设备。<br>（4）电话、传真等通讯设备以及通讯费用。<br>（5）资料费。<br>（6）办公消耗，如水电费、打印复印费等。<br>（7）软件开发人员与行政人员的工资。<br>（8）购买系统软件的费用，如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件，却按市场价算成本，可从美国佬那里赚一笔。<br>（9）做市场调查、可行性分析、需求分析的交际费用。<br>（10）公司人员培训费用。<br>（11）产品宣传费用。如果用Internet作宣传，则要考虑建设Web站点的费用。<br>（12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿的费用。<br>（13）如果公司的风水不好，会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。</font></p>
<p><font face="Verdana">二、短期——长远利益分析<br>人们喜欢吃着碗里的、看着锅里的，还想着别人家里的。短期利益和长远利益兼得是人们梦寐以求的事。在商业上，这等好事可不会轻易降临。<br>短期利益容易把握，风险较低。国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。每当我们沉迷于短期利益不思进取时，应该好好回忆童年时代那些伟大的抱负，给自己一些激励。<br>长
远利益难以把握，风险较大。能为了长远利益不惜短期亏损的人，要么是雄心勃勃的将帅之才，要么是&#8220;纸上谈兵&#8221;、&#8220;眼高手底&#8221;的那一类庸人。国内目前有不少
Internet企业，只投入不产出。为了成就将来的霸业，甘愿现在拼财力、比耐性。最后存活下来的几个公司将瓜分市场。<br>那些为长远利益奋斗的人们，你们可得把长征的路途走完啊，千万别让事业中途夭折。</font></p>
<p><font face="Verdana"><strong>技术</strong><br><br>技术可行性分析至少要考虑以下几方面因素：<br>（1）在给定的时间内能否实现需求说明中的功能。如果在项目开发过程中遇到难以克服的技术问题，麻烦就大了。轻则拖延进度，重则断送项目。<br>（2）软件的质量如何？有些应用对实时性要求很高，如果软件运行慢如蜗牛，即便功能具备也毫无实用价值。有些高风险的应用对软件的正确性与精确性要求极高，如果软件出了差错而造成客户利益损失，那么软件开发方可要赔惨了。<br>（3）
软件的生产率如何？如果生产率低下，能赚到的钱就少，并且会逐渐丧失竞争力。在统计软件总的开发时间时，不能漏掉用于维护的时间。软件维护是非常拖后腿的
事，它能把前期拿到的利润慢慢地消耗光。如果软件的质量不好，将会导致维护的代价很高，企图通过偷工减料而提高生产率，是得不偿失的事。<br>技术可行性分析可以简单地表述为：做得了吗？做得好吗？做得快吗？</font></p>
<p><font face="Verdana"><strong>社会环境</strong><br><br>社会环境的可行性至少包括两种因素：市场与政策。<br>市场又分为未成熟的市场、成熟的市场和将要消亡的市场。<br>涉足未成熟的市场要冒很大的风险，要尽可能准确地估计潜在的市场有多大？自己能占多少份额？多长时间能实现？<br><br>挤进成熟的市场，虽然风险不高，但油水也不多。如果供大于求，即软件开发公司多，项目少，那么在竞标时可能会出现恶性杀价的情形。国内第一批卖计算机的、做系统集成的公司发了财，别人眼红了也挤进来，这个行业的平均利润也就下降了。<br><br>将要消亡的市场就别进去了。尽管很多程序员怀念DOS时代编程的那种淋漓尽致，可现在没人要DOS应用软件了。学校教学尚可用用DOS软件，商业软件公司则不可再去开发DOS软件。<br>政策对软件公司的生存与发展影响非常大。整个90年代，中国电信的收费相当高，仅此一招就把国内互联网企业打得奄奄一息。某些软件行业的利润很高，但可能存在地方保护政策，使竞争不公平。政策不当将阻碍软件公司的健康发展，可最怕的还是政府干预企业的正当行为。例如：<br>现在家电行业竞争非常激烈，其中有一个著名企业的总裁十分了得，把对手打得节节败退。于是中央领导人就来视察该企业并作讲话：&#8220;你们的业绩辉煌，得到了中央的高度重视，&#8230;&#8230;但我们是社会主义国家，不是资本主义国家，你们总得给兄弟企业的同志们留口饭吃吧!&#8221;<br><br>有一次我拜访了北京大学一位研究经济学的朋友。这个年青人，还是个党员，竞然这么说：&#8220;我最近在研究国内明星企业的兴衰问题，我发现了一个规律，明星企业一旦被政府领导人视察过，它就忘了自己是谁，就会做些走向死亡的蠢事。&#8221;<br><br>我
实在不明白企业中为什么还要有&#8220;书记&#8221;职位。我以为&#8220;书记&#8221;乃是天下第一号可笑的官衔，&#8220;书记&#8221;本是&#8220;秘书&#8221;（secretary）的同义词，是个可有可
无的行政人员的称呼，在中国竟然成了最大的官衔。每次看到新闻联播把国家主席错叫成总书记我都十分气愤：因为总书记的称喟只对几千万的党员适用，国家的新
闻机构难道不面向十多亿普通老百姓？如果我将来的工作单位还靠&#8220;书记&#8221;来管事，我每天准忙着生气，那里还有精力去编程。</font></p>
<p><font face="Verdana"><strong>人</strong><br><br>有句名言：&#8220;人分四类——人物，人才，人手，人渣。&#8221;<br>如果一个软件公司里上述四类人齐全了，那么最好的分工是让&#8220;人物&#8221;当领导，&#8220;人才&#8221;做第一线的开发人员，&#8220;人手&#8221;做行政人员，&#8220;人渣&#8221;负责行贿。<br><br>这里只谈公司的领导与开发人员&#8220;行还是不行&#8221;。&#8220;人物&#8221;毕竟是少数，&#8220;人才&#8221;可是济济的。举重若轻的那类&#8220;人才&#8221;可以做领导，举轻若重的那类人才适合做软件开发人员。假如一群持有学士、硕士和博士文凭的毕业生到软件公司应聘，该如何录用呢？我的建议如下：<br>先选择本科毕业生，因为他们正当青春、干劲十足、不摆架子、不耻下问、要求不高、奉献甚多。<br>其次选择硕士毕业生，如果该生没象范进中举时那么老，并且在读硕士时没有天天去造文章而丢弃了编程工作，那么让有经验的学士程序员带他们煅练几个月就可以用了。<br><br>如
果学士、硕士被其它公司取光了，那只好捡几个博士充数。博士到了软件公司有什么用呢？我想不出有什么用，只知道他们挺值得可怜的：从硕士读到博士出头，这
六七年时间，真本事没学多少，倒学会&#8220;眼高手低&#8221;甚至&#8220;弄虚作假&#8221;；毕业时蓦然回首，发觉青春已被虚度，心灵已呈老态，唯有长叹短嘘，强把自负作自信。我
也将博士毕业，就要论为三手贷贱卖了。真羡慕那些比我年轻的学士、硕士们，他们可以远走高飞，唉！</font></p>
</font><img src ="http://www.cppblog.com/zmllegtui/aggbug/112058.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/zmllegtui/" target="_blank">zml_cnnk</a> 2010-04-09 13:32 <a href="http://www.cppblog.com/zmllegtui/archive/2010/04/09/112058.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>软件项目需求分析为什么困难</title><link>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112059.html</link><dc:creator>zml_cnnk</dc:creator><author>zml_cnnk</author><pubDate>Fri, 09 Apr 2010 05:32:00 GMT</pubDate><guid>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112059.html</guid><wfw:comment>http://www.cppblog.com/zmllegtui/comments/112059.html</wfw:comment><comments>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112059.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/zmllegtui/comments/commentRss/112059.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/zmllegtui/services/trackbacks/112059.html</trackback:ping><description><![CDATA[<p><font face="Verdana">有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。</font></p>
<p><font face="Verdana"><strong>1 客户说不清楚需求</strong><br><br>有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全国各地的很多政府机构在搞网络建设，这些单位的领导和办公人员大多不清楚计算机网络有什么用，反而要软件系统分析人员替他们设想需求。这类工程的需求是如此的主观，以致产生很多贪污腐败现象。<br><br>有
些客户心里非常清楚想要什么，但却说不明白。读者可能很不以为然。就举日常生活的事例吧，比如说买鞋子。我们非常了解自已的脚，但没法说清楚脚的大小和形
状。只能拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼客户的手，就知道应该穿什么样的鞋）。<br><br>如果客户本身就
懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。如果客户全不懂软件，但信任软件开发方，这事也好办。分析人员可以引导客户，先阐
述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。最怕的就是&#8220;不懂装懂&#8221;或者&#8220;半懂充内行&#8221;的客户，他们会提出不切实际的需求。如果这些客
户甚至觉得自己是上帝的爸爸，那么沟通和协商都会很困难。</font></p>
<p><font face="Verdana"><strong>2 需求自身经常变动</strong><br><br>唐僧曾说：&#8220;妖要是有了仁慈之心，就不再是妖，是人妖。&#8221;（《大话西游之大圣娶亲》）<br>连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也因此变得多姿多彩。<br>软件的需求会变化吗？<br><br>答：据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的。[Cline 1995]<br>让我们先接受&#8220;需求会变动&#8221;这个事实吧，免得在需求变动时惊慌失措。明白&#8220;需求会变动&#8221;这个道理后，在进行需求分析时就要留点神：<br>（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。<br>（2）在合同中一定要说清楚&#8220;做什么&#8221;和&#8220;不做什么&#8221;。如果合同含含糊糊，日后扯皮的事情就多。要防止象韩复渠那样，在别人请他喝酒吃饭时他什么都点头（人家就更加献殷勤），吃完了他就宣布刚才答应的事都不算数，便扬长而去。</font></p>
<p><font face="Verdana"><strong>3 分析人员或客户理解有误</strong><br><br>有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：&#8220;主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。&#8230;&#8230;有趣的是，车里住着一种叫作&#8216;人&#8217;的寄生虫，这些寄生虫完全控制了车。&#8221;<br><br>软
件系统分析人员不可能都是全才。客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错了，可能会导致开发人员白干活，吃力不讨好。我读中
学时候最怕写作文逃题，如果逃题了，不管作文写得多长，总是零分。所以分析人员写好需求说明书后，要请客户方的各个代表验证。如果问题很复杂，双方都不太
明白，就有必要请开发人员快速构造软件的原型，双方再次论证需求说明书是否正确。<br><br>由于客户大多不懂软件，他们可能觉得软件是万能的，会提出一些无法实现的需求。有时客户还会把软件系统分析人员的建议或答复给想歪了。<br><br>有一个软件人员滔滔不绝地向客户讲解在&#8220;信息高速公路上做广告&#8221;的种种好处，客户听得津津有味。最后，心动的客户对软件人员说：&#8220;好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。&#8221;<br><br>为什么软件系统分析员的工资要比普通程序员高？就是因为需求分析困难嘛。</font></p><img src ="http://www.cppblog.com/zmllegtui/aggbug/112059.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/zmllegtui/" target="_blank">zml_cnnk</a> 2010-04-09 13:32 <a href="http://www.cppblog.com/zmllegtui/archive/2010/04/09/112059.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>软件项目的质量控制要素</title><link>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112057.html</link><dc:creator>zml_cnnk</dc:creator><author>zml_cnnk</author><pubDate>Fri, 09 Apr 2010 05:31:00 GMT</pubDate><guid>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112057.html</guid><wfw:comment>http://www.cppblog.com/zmllegtui/comments/112057.html</wfw:comment><comments>http://www.cppblog.com/zmllegtui/archive/2010/04/09/112057.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.cppblog.com/zmllegtui/comments/commentRss/112057.html</wfw:commentRss><trackback:ping>http://www.cppblog.com/zmllegtui/services/trackbacks/112057.html</trackback:ping><description><![CDATA[<p><font face="Verdana">&#8220;运行正确&#8221;的程序就是高质量的程序吗？不贪污的官就是好官吗？时下老
百姓对一些腐败的地方政府深痛恶绝，对&#8220;官&#8221;不再有质量期望。只要当官的不贪污，哪怕毫无政绩，也算是&#8220;好官&#8221;。也有一些精明的老百姓打出旗号：宁要贪污
犯，不要大笨蛋。相比之下，程序员是够幸福的了。因为我们能通过努力，由自己来把握软件的命运。那么就不要轻易放弃提高软件质量的权利了。<br><br>&#8220;运行正确&#8221;的程序不见得就是高质量的程序。这个程序也许运行速度很低并且浪费内存；也许代码写得一塌糊涂，除了开发者本人谁也看不懂也不会使用。正确性只是反映软件质量的一个因素而已。<br><br>软
件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）。这
些质量因素之间&#8220;你中有我，我中有他&#8221;，非常缠绵。如果程序员每天要面对那么多质量因素咬文嚼字，不久就会迂腐得象孔乙已，并且有找不到女朋友的危险。</font></p>
<p><font face="Verdana"><strong>1 正确性与精确性</strong></font></p>
<p><font face="Verdana">正确性与精确性之所以排在质量因素的第一位，是因为如果软件运行不正确或者不精确，就会给用户造成不便
甚至造成损失。机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的。即使一个软件能100%
地按需求规格执行，但是如果需求分析错了，那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求，但是如果软件没有100%
地按需求规格执行，那么这个软件也存在错误。开发一个大的软件项目，程序员要为&#8220;正确&#8221;、&#8220;精确&#8221;四个字竭尽精力。<br>与正确性、精确性相关的质量因素是容错性和可靠性。<br><br>容错性首先承认软件系统存在不正确与不精确的因素，为了防止潜在的不正确与不精确因素引发灾难，系统为此设计了安全措施。在一些高风险的软件系统，如航空航天、武器、金融等系统中，容错性设计非常重要。<br><br>可
靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备，一开始工作很正常，但由于工作中器件的
物理性质会发生变化（如发热），慢慢地系统就会失常。所以一个设计完全正确的硬件系统，在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化，人
们常以为如果软件的某个功能是正确的，那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试，无法根除软件中潜在的错误。平时软件运行得好好的，说
不准哪一天就不正常了，如&#8220;2000年&#8221;问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软件可靠性的著作，此书充满了数学公式。我发现以我
目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧，我把此书给&#8220;供&#8221;起来，没敢用笔画一处记号。</font></p>
<p><font face="Verdana"><strong>2 性能与效率</strong></font></p>
<p><font face="Verdana">用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）。旧社会地主就是这么对待长工
的：干活要快点，吃得要少点。程序员可以通过优化算法、数据结构和代码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率的&#8220;瓶颈&#8221;，
不要在无关痛痒的地方瞎忙乎。如果你想职称升得快，光靠增加课时能顶屁用；你就该一年写它几十篇文章，争取破格升教授。</font></p>
<p><font face="Verdana"><strong>3 易用性</strong></font></p>
<p><font face="Verdana">易用性是指用户感觉使用软件的难易程度。用户可能是操作软件的最终用户，也可能是那些要使用源代码的程序员。现代人的生活节奏快，干啥事都想图个方便。所以把易用性作为重要的质量因素无可非议。<br><br>导
致软件易用性差的根本原因是开发人员犯了&#8220;错位&#8221;的毛病：他以为只要自己用起来方便，用户也一定会满意。俗话说&#8220;王婆卖瓜，自卖自夸&#8221;。当程序员向用户展
示软件时，常会得意地讲：&#8220;这个软件非常好用，我操作给你看，&#8230;&#8230;是很好用吧！&#8221;软件的易用性要让用户来评价。当用户真的感到软件很好用时，一股温暖的感
觉油然而生，于是就用&#8220;友好&#8221;来评价易用性。</font></p>
<font face="Verdana">
</font>
<p><font face="Verdana"><br><strong>4 可理解性与简洁性</strong></font></p>
<p><font face="Verdana">可理解性表达了人们一种质朴的愿望：我化钱买了它，总得让我明白它是什么东西。我小时候的一个伙伴在读中学时，就因无法理解电荷之分正负，觉得很烦恼，便早早地缀学当工人。<br>可
理解性也是对用户而言的。开发人员只有在自己思路清晰时才可能写出让别人能理解的程序。编程时还要注意不可滥用技巧，应该用自然的方式编程。我们的确不知
道自己的得意之举究竟是锦上添花，还是画蛇添足。就象蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。</font></p>
<p><font face="Verdana">简洁是一种美，不管是自己还是用户都会有同感。在生活中，与简洁对立的是&#8220;罗里罗嗦&#8221;。中国小说中最&#8220;
婆婆妈妈&#8221;的男人是唐僧。有一项民意调查：如果世上只有唐僧、孙悟空、猪八戒和沙僧这四类男人，你要嫁给哪一类？请列出优先级。调查结果表明，现代女性毫
不例外地把唐僧摆在老末。一个原始的应用问题可能很复杂，但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪，它迟早会出问题。简洁是人们
对工作&#8220;精益求精&#8221;的结果。</font></p>
<p><font face="Verdana">废话大师有句名言：&#8220;如果我令你过于轻松地明白了，那你一定是误解了我说的话。&#8221;我最近有一种奇怪的体
会：如果把学术文章写得很简洁，让人很容易理解，它往往中不了；只有加上一些玄乎的东西，把本来简单的弄成复杂的，才会增加投稿的命中率。事实上，我可以
在5分钟之内说清楚三年来读博所做的工作，根本用不着写100多页的博士论文。我是在临近毕业时，才发觉自己完全不适合读博士学位。将来工作后，我一定要
好好编程，重新做人。</font></p>
<p><font face="Verdana"><br><strong>5 可复用性与可扩充性</strong></font></p>
<p><font face="Verdana">复用的一种方式是原封不动地使用现成的软构件，另一种方式是对现成的软构件进行必要的扩充后再使用。可复用性好的程序一般也具有良好的可扩充性。</font></p><img src ="http://www.cppblog.com/zmllegtui/aggbug/112057.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.cppblog.com/zmllegtui/" target="_blank">zml_cnnk</a> 2010-04-09 13:31 <a href="http://www.cppblog.com/zmllegtui/archive/2010/04/09/112057.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>