首页 　· 　知识　· 　供应链
项目计划与质量管理
佚名　　本站原创　　品质管理　　编辑:dezai　　图片来源:网络
在可行性分析之后项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。项目计
在可行性分析之后项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。
项目计划是要提供一份合理的进程表让所有开发人员任务明确、步调一致最终共同准时地完成项目。项目计划是要付诸实施的不象用嘴巴喊政治口号可以很夸张。软件的项目计划重在“准确”而非“快速”。
提高质量是软件工程的主要目标。但由于软件开发是一种智力创作活动很难象传统工业那样通过执行严格的操作规范来保证软件产品的质量。世上最小心翼翼、最老实巴脚的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量因素）如正确性、性能、易用性、灵活性、可复用性、可理解性等等才能在进行系统设计、程序设计时将高质量内建其中。软件的高质量并不是“管理”出来的实质上是设计出来的质量的管理只是一种预防和认证的手段而已。
3.1　项 目 计 划

做项目计划如同给一个待出生的婴儿写传记那样困难。如果允许项目结束后再写计划那就轻松多了并且可以100% 地准确。
历史教训让我们明白一个道理：如果一万年以后才会有一条阳光大道通向共产主义那么现在就不要忙着砸锅炼钢赶英超美免得在跑步奔向共产主义时把自己累死饿死。在做软件的项目计划时应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源如可调用的程序员有几个？他们的水平如何？软硬件设施如何？

3.1.1 知己知彼
首先要了解项目的规模、难度与时间限制才可以确定应该投入多少人力、物力去做这个项目。在可行性分析阶段就要考虑这个问题。但不幸的是人们在陷入项目不能自拨之前总难以准确地估计项目的规模与难度。这里经验起到了最重要的作用。
项目的时间限制有两类。第一类项目应该完成的日期写在合同中如果延期了则开发方要作出相应的赔偿。第二类是开发自己的软件产品虽然只确定了该产品大致的发行日期并允许有延误但如果拖延太久则会失去商机造成损失。
项目的资源分为三类：“人”、“可复用的软构件”和“软硬件环境”如图3.1所示。（１）人是最有价值的资源。项目计划的制定者要确定开发人员的名单要根据他们的专长进行分工。
（２）可复用的软构件是次有价值的资源。1.2.1节论述了复用软构件可提高软件的质量与生产率。软构件并非一定要用自己的可以向专业的软件供应商购买。
（３）软硬件环境虽然不是最重要的资源却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备则要事先作好准备以免用时找不到而担搁了进程。

1. 人
　　2. 可复用的软构件
　　3. 软 硬 件 环 境








图3.1 项目的资源

3.1.2 进度安排
有一位程序员忙着编写程序经理问他还需要多久才能完成。
“明天就可以完成。”程序员立即回答。
“我想这是不切实际的实话实说到底还要多少时间？”经理说。
“我还想加进一些新的功能这需要花两个星期。”程序员想了一会儿说。
“即使这样也期望过高了只要你编完程序时告诉我一声我也就满足了。”经理说。
几年以后经理要退休了。在他去退休午餐会时发现那位程序员正趴在机器旁睡觉：可怜的家伙整个晚上都在忙于编写那个程序。[James 1999]
程序员也期望每天早晨能在7:00准时起床可老是一觉醒来就到中午了。项目落后于进度表乃是家常便饭不必大惊小怪。以下一些事件经常会导致项目被延误：
（1）上级领导主管臆断制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。
（2）客户的需求发生了变化但没有对进度表作出相应的修改。
（3）低估了项目的规模与难度导致投入的人力和物力不足。
（4）并未预见到存在难以克服的技术障碍。
（5）并未预见到开发人员会发生问题如生病辞职等等。
（6）开发人员之间不能很好的交流、协作导致各阶段任务难以如期完成。
所以写进程表不能象小学生写决心书那样充满幻想。以下是一些有益的建议：
（1）制定进度表的人最好就是项目负责人他最了解项目和开发人员。进度表要经过开发小组的讨论在得到大部数人的支持后才能实施。避免出现一厢情愿的局面。
（2）进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事后做难度低的事。也就是辛苦在前轻松在后。
小时候我对一位老先生吃饭很感兴趣：他总是先把一大盒的米饭吃光了然后再幸福地品尝一小盒菜。父母告诉我这是中国的传统美德叫“先苦后甜”。从此我铭记在心按此道理去学习和工作。可如今在饭店里人们总是先把菜吃完了最后才吃点米饭。天哪生活真是太复杂了我究竟该“先吃饭” 还是“先吃菜”？
（3）开发一个大的软件项目应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。程序员极容易沉迷于技术要么乐不思蜀要么焦头烂额。里程碑就象心灵的灯塔使忙碌的人群不混乱不迷失方向。
（4）进度表中必须留有缓冲时间并将缓冲时间用到不确定的事情上。因为人们对即将要做的事情知之甚少所以要留一些时间以防不测。Microsoft公司的一些开发小组甚至制定了“50% 缓冲规则”[Cusumano 1996]。对许多项目经理而言容忍进度表中存在缓冲时间不啻为观念上的一个飞跃。
（5）如果发现项目应交付的期限非常不合理就要跟领导或跟客户据理力争请求放宽期限、调整进度。当客户的需求发生变化时就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦不修改才会产生真真的麻烦。很多人认为戒烟很困难但马克·吐温曾说：“戒烟很容易我一年就戒几十次。”

3.2　零缺陷质量管理的观念

“零缺陷”质量管理的观念来源于一些国际上著名的硬件生产厂商。尽管软件的开发与硬件生产有极大的差别但我们仍可以从“零缺陷”质量管理中得到启迪。“零缺陷”质量管理至少有两个核心内容：一是高目标二是可执行的规范。

3.2.1 高目标
人在做一件事情时由于存在很多不确定的因素一般不可能100% 地达到目标。假设平常人做事能完成目标的80%。如果某个人的目标是100分那么他最终成绩可达80分。如果某个人的目标只是60分那么他最终成绩只有48分。我们在考场上身经百战很清楚那些只想混及格的学生通常都不会及格那些想得高分的学生也常为自己的失误而捶胸顿足。
做一个项目通常需要多个人的协作。假设项目的总质量（最高为1）是十个开发人员的工作质量之积。如果每个人的质量目标是0.95那么十个人的累积质量不会超过0.19。如果每个人的质量目标是0.9分那么十个人的累积质量不会超过0.03。只有每个人都做到1项目总质量才会是1。
如果没有高目标人的堕落就很快。如果没有“零缺陷”的质量目标也许缺陷就会成堆。

3.2.2 可执行的规范
实现100分显然比实现80分要付出更多的努力。“零缺陷”质量目标不是随心所欲提出来的做得到才有意义。实现高目标需要一套可执行的规范来保证。
50年代末全国掀起了“浮夸风”。为了实现亩产数万斤推广各种方法害得全国闹饥荒。想不到有数千年种粮经验的几亿中国农民就这么整齐地栽倒了。
好规范必须是本企业有能力执行的。一个普通企业照搬一流企业的规范未必行得通。软件工程的规范很容易从书籍中找到但有了这些规范并不表明就能把软件做好。国内很多软件公司根本没有条件去执行业界推荐的软件工程规范。社会主义初级阶段的“草”与发达资本主义国家的“苗”的确有不同的培育方式。

软件是如此的灵活如果没有规范来制约就容易因无序的喜好而导致混沌；但规范如果太严密了就会扼杀程序员生机勃勃的创造力。制定软件规范是进退两难的事。程序员必须深入了解软件多方面的质量因素把那些能提高软件质量因素的各种规范植入脑中才能在各个实践环节自然而然地把高质量设计到软件中。

3.3　软件的质量因素

“运行正确”的程序就是高质量的程序吗？
不贪污的官就是好官吗？
时下老百姓对一些腐败的地方政府深痛恶绝对“官”不再有质量期望。只要当官的不贪污哪怕毫无政绩也算是“好官”。也有一些精明的老百姓打出旗号：宁要贪污犯不要大笨蛋。相比之下程序员是够幸福的了。因为我们能通过努力由自己来把握软件的命运。那么就不要轻易放弃提高软件质量的权利了。
“运行正确”的程序不见得就是高质量的程序。这个程序也许运行速度很低并且浪费内存；也许代码写得一塌糊涂除了开发者本人谁也看不懂也不会使用。正确性只是反映软件质量的一个因素而已。
软件的质量因素很多如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）。这些质量因素之间“你中有我我中有他”非常缠绵。如果程序员每天要面对那么多质量因素咬文嚼字不久就会迂腐得象孔乙已并且有找不到女朋友的危险。
为了便于理解可以参照武侠小说中的武学分类将质量因素粗略地分成几大派。你想那武学源源流长相互渗透谁能数得清有多少江湖派别。但想在道上混总得知道六大门派：“少林派”、“武当派”、“峨嵋派”、“华山派”、“昆仑派”和“崆峒派”。软件质量因素的分类如图3.2所示。其中“正确性与精确性”排在首位地位如同“少林派”与“武当派”；而“性能与效率”“易用性”“可理解性与简洁性”和“可复用性与可扩充性”亦是举足轻重的质量因素地位仿佛“峨嵋派”“华山派”“昆仑派”和“崆峒派”。其它的质量因素总可以在图3.2中找到合适的亲缘关系本节不再一一细表。

正确性与精确性
易用性
可理解性与简洁性
性能与效率
可复用性
与
可扩充性
少林派、武当派
华山派
昆仑派
峨嵋派
崆峒派












图3.2　软件质量因素分类和武学分类

3.3.1 正确性与精确性
正确性与精确性之所以排在质量因素的第一位是因为如果软件运行不正确或者不精确就会给用户造成不便甚至造成损失。机器不会主动欺骗人软件运行不正确或者不精确一般都是人造成的。即使一个软件能100% 地按需求规格执行但是如果需求分析错了那么对客户而言这个软件也存在错误。即使需求分析完全符合客户的要求但是如果软件没有100% 地按需求规格执行那么这个软件也存在错误。开发一个大的软件项目程序员要为“正确”、“精确”四个字竭尽精力。
与正确性、精确性相关的质量因素是容错性和可靠性。
容错性首先承认软件系统存在不正确与不精确的因素为了防止潜在的不正确与不精确因素引发灾难系统为此设计了安全措施。在一些高风险的软件系统如航空航天、武器、金融等系统中容错性设计非常重要。
可靠性是指在一定的环境下在给定的时间内系统不发生故障的概率。可靠性本来是硬件领域的术语。比如某个电子设备一开始工作很正常但由于工作中器件的物理性质会发生变化（如发热）慢慢地系统就会失常。所以一个设计完全正确的硬件系统在工作中未必就是可靠的。软件在运行时不会发生物理性质的变化人们常以为如果软件的某个功能是正确的那么它一辈子都是正确的。可是我们无法对软件进行彻底地测试无法根除软件中潜在的错误。平时软件运行得好好的说不准哪一天就不正常了如“2000年”问题。因此把可靠性引入软件领域是有意义的。我曾买了一本关于软件可靠性的著作此书充满了数学公式。我发现以我目前的学历实在难以看懂书上讲了些什么。请宽恕我的愚昧我把此书给“供”起来没敢用笔画一处记号。

3.3.2 性能与效率
用户都希望软件的运行速度高些（高性能）并且占用资源少些（高效率）。旧社会地主就是这么对待长工的：干活要快点吃得要少点。程序员可以通过优化算法、数据结构和代码组织来提高软件系统的性能与效率。优化的关键工作是找出限制性能与效率的“瓶颈”不要在无关痛痒的地方瞎忙乎。如果你想职称升得快光靠增加课时能顶屁用；你就该一年写它几十篇文章争取破格升教授。

3.3.3 易用性
易用性是指用户感觉使用软件的难易程度。用户可能是操作软件的最终用户也可能是那些要使用源代码的程序员。现代人的生活节奏快干啥事都想图个方便。所以把易用性作为重要的质量因素无可非议。
导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便用户也一定会满意。俗话说“王婆卖瓜自卖自夸”。当程序员向用户展示软件时常会得意地讲：“这个软件非常好用我操作给你看……是很好用吧！”软件的易用性要让用户来评价。当用户真的感到软件很好用时一股温暖的感觉油然而生于是就用“友好”来评价易用性。

3.3.4 可理解性与简洁性
可理解性表达了人们一种质朴的愿望：我化钱买了它总得让我明白它是什么东西。我小时候的一个伙伴在读中学时就因无法理解电荷之分正负觉得很烦恼便早早地缀学当工人。
可理解性也是对用户而言的。开发人员只有在自己思路清晰时才可能写出让别人能理解的程序。编程时还要注意不可滥用技巧应该用自然的方式编程。我们的确不知道自己的得意之举究竟是锦上添花还是画蛇添足。就象蒸出一笼馒头在上面插一朵鲜花本想弄点诗情画意却让人误以为那是一堆热气腾腾的牛粪。
简洁是一种美不管是自己还是用户都会有同感。在生活中与简洁对立的是“罗里罗嗦”。中国小说中最“婆婆妈妈”的男人是唐僧。有一项民意调查：如果世上只有唐僧、孙悟空、猪八戒和沙僧这四类男人你要嫁给哪一类？请列出优先级。调查结果表明现代女性毫不例外地把唐僧摆在老末。
一个原始的应用问题可能很复杂但高水平的人就能够把软件系统设计得很简洁。如果软件系统臃肿不堪它迟早会出问题。简洁是人们对工作“精益求精”的结果。
废话大师有句名言：“如果我令你过于轻松地明白了那你一定是误解了我说的话。”我最近有一种奇怪的体会：如果把学术文章写得很简洁让人很容易理解它往往中不了；只有加上一些玄乎的东西把本来简单的弄成复杂的才会增加投稿的命中率。事实上我可以在5分钟之内说清楚三年来读博所做的工作根本用不着写100多页的博士论文。我是在临近毕业时才发觉自己完全不适合读博士学位。将来工作后我一定要好好编程重新做人。

3.3.5 可复用性与可扩充性
复用的一种方式是原封不动地使用现成的软构件另一种方式是对现成的软构件进行必要的扩充后再使用。可复用性好的程序一般也具有良好的可扩充性。本书第六章将论述如何设计可复用、可扩充的C++程序。

3.4　质 量 检 查

检查是人们不信任自己和别人的一种行为。当某些事情涉及到利益分配时更需要有检查活动来保证公平。估计即使进入了共产主义社会也少不了检查。
质量检查并不是要等到项目结束时才执行唯一的一次应该在每个实践环节都要执行。对应于进度表在每个里程碑到达时执行质量检查比较合理。质量检查的内容有二：一是作出评审是合格还是不合格？能打多少分？二是作出建议对质量为什么好为什么差进行分析以便“改差为好”、“好上加好”。
以下是人们经常采用的软件质量检查措施[Pressman 1999]：
（1）事先把检查的主要内容制成一张表使检查活动集中在主要问题上。
（2）只评审工作不评审开发者。评审的气氛应该是融洽的。存在的错误应该被有礼貌地指出来任何人的意见都不应被阻挠或小看。
（3）建立一个议事日程并遵循它。检查过程不能放任自由必须排照既定的方向和日程进行。
（4）不要化太多的时间争论和辩驳。
（5）说清楚问题所在但不要企图当场解决所有问题。
（6）对检查人员进行适当的培训。
……
做好检查工作并不是件容易的事。自古以来“上有政策下有对策”。 虚假的质量检查还不如不检查下面讲两个故事作为解释。

故事一
不久前我回到西北那所读了六年多的大学惊奇地发现校园里房前屋后长满了待收割的小麦！这所大学是从事电子科技的种小麦干啥呀？朱总理曾讲过：“目前国家粮食充足再来三年自然灾害也不怕。”现在国泰民安似乎用不着“深挖洞广积粮”。我素知学校提创勤俭节约、自力更生但与其种小麦还不如种蔬菜呢。老同学告诉我种小麦是为了应付“211”工程（为21世纪选拔100所重点大学）的检查团因为“211”工程有较高的绿化指标。偏偏检查赶在冬天那时的西北极难长草。我那所大学本来就人多地少地上一长草马上就会被谈恋爱的学生给折磨死。一到冬天整个校园就光秃秃一片。用小麦绿化校园可谓千古绝笔检查团的那些权贵人士早已五谷不分岂知所见的“草坪”乃是麦田。
检查工作要预防被检查者弄虚作假。

故事二
我上高中时班里举行一次入团评审。侯选人中有几位是好学生有几位是坏学生。我心想“伸张正义”的机会到了绝不能让坏蛋混进纯洁的团里。可天知道团支部书记是聪明绝顶还是蠢笨之极。他竟说：“班里还有一些同学没有入团现在他们申请入团有不同意的请举手。”我们都不知道该怎么办了。书记接着说：“既然没有人举手反对就表示全部同意请大家鼓掌欢迎。”这次入团评审不到一分钟就结束了从此后我再也没想过争取入党。
检查工作要有科学的评审方式。

3.5　小　结
　　
不知为什么国内很多大的企业都喊着要进世界500强。如果真的实现了世界500强还不全被中国霸占了。软件的项目计划和质量管理都不是用来喊叫的口号。做项目计划时切忌“冒进”不要指望在项目陷入困境后靠增加人手来解救。软件的高质量主要是设计出来的不是“管”出来的更不能依赖质量检查。为此程序员要充分了解软件的质量因素只有提高设计水平才能开发出高质量的软件。 本文作者:佚名 来源:本站原创
CIO之家 www.ciozj.com 微信公众号:imciow
　　　　>>频道首页　　>>网站首页 　　纠错　　>>投诉
版权声明:CIO之家尊重行业规范，每篇文章都注明有明确的作者和来源；CIO之家的原创文章，请转载时务必注明文章作者和来源；
延伸阅读
也许感兴趣的
我们推荐的
主题最新
看看其它的
上一篇
怎样进行质量改进工作
下一篇
项目计划与质量管理
作者其它的文章
收藏至微信