需求分析的20条法则

--------------------------------------------------------------------------------

 

邢学慧（转载自IT经理世界）

　　对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

风险躲在需求的迷雾之后

　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

客户的需求观

　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达

　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s 3、 分析人员必须编写软件需求报告

　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明

　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见

　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案

　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

7、 描述产品使用特性

　　客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

8、 允许重用已有的软件组件

　　需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。

9、 要求对变更的代价提供真实可靠的评估

　　有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。

10、 获得满足客户功能和质量要求的系统

　　每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。

11、 给分析人员讲解您的业务

　　分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。

12、 抽出时间清楚地说明并完善需求

　　客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。

13、 准确而详细地说明需求

　　编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。

　　在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。

14、 及时作出决定

　　分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。

15、 尊重开发人员的需求可行性及成本评估

　　所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。

16、 划分需求的优先级

　　绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。

　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

17、 评审需求文档和原型

　　客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。

　　更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。

18、 需求变更要立即联系

　　不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。

19、 遵照开发小组处理需求变更的过程

　　为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。

20、 尊重开发人员采用的需求分析过程

　　软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。

“需求确认”意味着什么

　　在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”

　　这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”

　　同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”

　　这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。

　　对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。

　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No002.htm

探究需求管理的本质（1）

--------------------------------------------------------------------------------

 

万成编译（转载自赛迪网）

　　本文旨在探究需求管理的本质，需求管理所要涉及的任务在文中将适时提及，以阐释"需求管理之需求（requirements for requirements）"的涵义。

☆概要

　　需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。

　　需求管理能够确证：

　　我们确知客户的需求是什么（质量）；

　　满足客户需求的最佳解决办法（统一性）；

 

　　著名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。 　　对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。

☆需求管理所要完成的任务

　　可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化。需要始终保持注意的是，需求性是始终处于变化之中的。需求管理需要完成的任务包括：

　　明确需求并达成共识；

　　建立关联；

　　根据不同需求设计相应解决办法；

　　进行系统优化；

　　提出设计方案；

　　监控和解决可能出现的问题以及需要做出的改变；

　　控制不同开发任务的开展；

　　对最终产品做出评测；

　　监控可能出现的重复开发；

　　提出项目实施时间表；

　　确定最终用户界面。

　　有时侯我们所进行的需求分析只停留于分析本身，而没有进一步去思索我们为什么要进行需求分析。需求性是项目开发的源头，只有进行认真的需求分析，我们才能做到对症下药、量体裁衣，才能才设计开发中去伪存真，不断改进。"需求之需求"正是强调了贯穿始终的需求分析的重要。离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理所产生的效益或许并不明显，或许要日后才能体现，但是无序的，没有经过精心策划的需求管理是不可能产生效益的。

　　以下篇幅分别介绍需求管理在系统工程中的不同应用。

需求共识：

　　首先，用户需求通过非术语的形式进行表述，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。这里?quot;用户"泛指在实际应用环境中每一位可能使用最终产品的人。如果一个产品不能满足客户所需，那么设计方案再出色也无济于事，许多方案有很高的技术设计水准却最终不能获得成功，其原因正在于此。可以把产品功能说得天花乱坠，但却无法改变用户需求决定最终产品基本模式的事实。

　　需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求分析的语言组织应当使所有相关人员，包括用户，都能够理解，都能够进而对整个项目有一个整体把握，并明确每一个人在项目中所起的作用。因而需求管理需要解决的第一位也是最基本的任务就是明确需求，并使所有相关人员达成共识。

根据需求设计解决办法：

　　我们在进行系统设计时，应当首先建立一个需求模型，但不能是为了建模而建模，需求模型实际是最终产品的抽象化表现。需求模型的建立使我们在明确需求的基础上更进一步，使我们知道我们将要生产何种产品，该产品都具有那些功能。同时，创建需求模型的过程也使开发者明确自己的工作如何同整个项目有机地结合在一起。建立需求模型应当充分研究不同类型、不同架构建模方式的可行性，切忌主观武断。

系统优化：

　　任何设计都应以考虑用户需求为优先，用户需求的满足程度即成为衡量设计优劣的标准。在一个项目设计周期中，开发人员经常会面临选择，以提炼需求，决定开发的优先次序，并在不同的实施方案中作出选择。这些选择必须考虑到收益与付出地平衡比例，这种选择的重要性尤其在建立需求模型的后期凸现出来。基本需求在这时都已明确，而实施方案还未敲定，为了使用户的基本需求得到落实，一定程度的开销用于搭建不同构架的需求模式是合理的。假使我们已经有了一套翔实的需求分析，我们甚至不必将每一套方案都付诸实行，就可以成功地对系统设计进行优化。

 　　面对不同的可行性而需要作出选择时，我们也必须参照收益与付出的比例关系。例如，在被要求提供计划书时（Request for Proposal），我们应当尽量做到每一份计划书的提供都物有所值。

方案设计：

　　明确需求后，开发人员就可以进行方案设计。通过对用户需求和设计方案之间所存在关联性进行分析比较，我们就能够对设计方案进行评估。

必要的修改：

　　方案的设计不可能是一成不变的，经常会有方案设计同需求相悖的情况。如果我们无法准确把握用户需求同方案设计之间的关系，我们就无法在需要对方案进行必要修改时正确判断。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

 

任务划分：

　　一个大的开发项目可能涉及20-30组不同的开发队伍，人员包括技术工程师、软件工程师以及具体项目主管等等，而每一个模块都有它自己的开发工具和开发语言。

 　　主持一个大项目的开发并不是件容易的事，总体项目主管的首要任务是对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。总体项目主管可以将细化的不同模块的需求分析交给不同的开发队伍，对于开发进程的监控只需参照需求的解决情况，对于具体的开发细节则不必过问太多。 　　不同的开发队伍会使用不同的开发语言和开发工具，会使用不同的符号和标记。相反，作为总体项目主管所使用的语言、符号和标记等则必须简单易懂，以使所有的开发人员都等理解。换言之，总体项目主管应当使用自然语言，或只涉及少量的，简单的术语和专用词汇。

产品测试：

　　需求的满足情况是决定最终产品成败的判定基础，对最终产品的测试评估必须以产品所试图解决的需求为标准。下图标示了不同的开发阶段所对应的测试需求。

 　　这里有一个需求、产品和测试系统之间的关系问题，确定需要进行的测试属于总体开发主管的工作范畴，虽然具体工作并非都要由开发主管来亲自完成。

重复开发：

　　对于总体开发主管而言，针对方案设计的修改是一项经常性的工作（因为修改而造成的影响则应当尽可能减小）。在进行项目开发时，随着开发进程的深入，各种修改的建议和问题的报告是屡见不鲜的，每解决一个问题，就是将产品同其需求性的结合又完善了一步。存在问题正是需求性尚未满足的表现。 　　方案设计的完善和需求性的满足是同步的，因此真正的用户对于产品的评价和建议尤其具有重要意义。在那些一步到位的产品设计中，真正用户无法左右开发进程；但在一个能够进行重复设计、重复开发的产品生命期中，开发人员应当及时搜集用户对于产品的反馈信息，并将这些信息结合到下一步的开发工作中去。如下图所示，用户反馈同产品开发是统一的。 

项目管理的辅助：

　　在有些地方，需求管理被作为一个技术问题来处理，需求管理所针对的对象只是产品，而同项目管理所涉及的问题例如进程安排或资源分配等无关。实际上，项目管理涉及三方面问题：进程安排、资源分配和质量管理（同需求的统一）。 

试想以下三种情况：

　　一场高水准的音乐会，预算合理，演出时间却晚了两天。

　　质量优良的小轿车，交货及时，然而造价是市价的两倍。

　　一套系统，完全满足了用户需求，但在开发过程中使用非法劳工。

　　这三种情况虽然都满足了用户所需，然而缺乏实际意义，因此都以失败告终。

　　"我付了钱，但这不是我想要的"，没有用户愿意这么说。要避免出现这种情况，在进行项目管理和财务预算时，也必须以需求管理为基础。仅仅完成了一件设计并不意味着工作的结束，只有这件设计充分解决了需求，它才具有里程碑般的意义。同样的，一件产品只有在测试和实际操作中完全满足了需求，已经完全准备好了投入到下一阶段的运营，才意味着这件产品在本阶段工作的结束。

　　开发进程中的每一块里程碑都意味着需求的解决又前进了一步，这样的每一块里程碑也都是委托商付款的重要参照，产品开发的整个进程都可以通过需求管理进行监控。 　　里程碑构造机制的基本方法之一就是进程管理，一项需求的满足就意味着一块里程碑的确立。我们应当对用户需求、针对需求而进行的模块设计以及每个子模块的开发进程之间的关联做到心中有数。 

   如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No012.htm

软件工程之需求分析（1）

--------------------------------------------------------------------------------

 

http://51cmm.csai.cn/Requirement/No014.htm

软件工程之需求分析（3）

--------------------------------------------------------------------------------

 

赵熙朝（转载自天极网）

4. 需求验证

　　1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。

　　2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。 　　3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。

　　4）确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。

二、需求管理

　　需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。

 

　　1．确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。

　　2．建立变更控制委员会，组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。

　　3．进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出是修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。进行影响分析的能力依赖于跟踪能力数据的质量和完整性。

　　4．跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。

　　5．建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。

　　6．维护需求变更的历史记录记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。版本控制工具能自动完成这些任务。版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定。组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。这些策略适用于所有关键项目文档。

　　7．跟踪每项需求的状态建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。

8．衡量需求稳定性记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。过多的需求变更"是一个报警信号"，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。

　　9．使用需求管理工具商业化的需求管理工具能帮助你在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No016.htm

软件工程之需求分析（2）

--------------------------------------------------------------------------------

 

赵熙朝（转载自天极网）

2． 需求分析

　　1）绘制关联图：绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

　　2）创建开发原型：创建用户接口原型当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。

　　3）分析可行性：分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

　　4）确定需求优先级：确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

　　5）为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

　　6）编写数据字典：创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

　　7）应用质量功能调配：使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

3． 编写规格说明书 　　项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。

　　1）采用软件需求规格说明模版: 采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。

 

a. 引言

　　　引言提出了对软件需求规格说明的纵览，这有助于读者理解文档如何编写并且如何阅读和解释。

a . 1 目的

　　　对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。

a.2 文档约定

　　　描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。

a.3 预期的读者和阅读建议

　　　列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。 　　

a.4 产品的范围

　　　提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。

a.5 参考文献

　　　列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。

b. 综合描述

　　　这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。

b.1 产品的前景

　　　描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个新型的、自含型产品。

b.2 产品的功能

　　　概述了产品所具有的主要功能。其详细内容将在d 中描述，所以在此只需要概略地总结。很好地组织产品的功能，使每个读者都易于理解。

b.3 用户类和特征

　　　确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。

b.4 运行环境

　　　描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。

b.5 设计和实现上的限制

　　　确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。

b.6 假设和依赖

　　列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。

　　此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。

c. 外部接口需求

　　利用本节来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。 　　c.1 用户界面

　　陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。

c.2 硬件接口

　　　描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。

c.3 软件接口

　　描述该产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。

c.4 通信接口

　　描述与产品所使用的通信功能相关的需求，包括电子邮件、We b 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。

d. 系统特性

d.1 说明和优先级

　　提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用和风险，其相对优先等级可以从1（低）到9 （高）。

d.2 激励/响应序列

　　列出输入激励（用户动作、来自外部设备的信号或其它触发器）和定义这一特性行为的系统响应序列。这些序列将与使用实例相关的对话元素相对应。

d.3 功能需求

　　详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作。就像本章开头所描述的那样，你必须唯一地标识每个需求。

e. 其它非功能需求

　　这部分列举出了所有非功能需求，如产品的易用程度如何，执行速度如何，可靠性如何，当发生异常情况时，系统如何处理，而不是外部接口需求和限制。

e.1 性能需求

　　阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。你还可以在这里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。

e.2 安全设施需求

　　详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。

e.3 安全性需求

　　详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。

e.4 软件质量属性

　　详尽陈述与客户或开发人员至关重要的其它产品质量特性。这些特性必须是确定、定量的并在可能时是可验证的。至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。

e.5 业务规则

　　列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。

e.6 用户文档

　　列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。

f. 其它需求

　　定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。 　　附

录A ：词汇表

　　定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。

附录B ：分析模型

　　这个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。

附录C ：待确定问题的列表

　　编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。

　　2）指明需求来源：指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。

　　3）为每项需求注上标号：为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。需求标识方法有序列号;层次化编码;使用"待确定"（to be determined, TBD ）符号等。

　　4）记录业务规范：是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求；当然这些需求也应能追溯相应业务规范。

　　5）创建需求跟踪能力矩阵：建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。

　　这里我们还要介绍需求规格说明书中设计阶段，用到的图形模型--数据字典、数据流图、数据流图、状态转换图、对话图和类图。

　　数据字典：一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。数据字典的维护独立于软件需求规格说明，并且在产品的开发和维护的任何阶段，各个风险承担者都可以访问数据字典。它定义了原数据元素、组成结构体的复杂数据元素、重复的数据项、一个数据项的枚举值以及可选的数据项。

　　数据流图：是结构化系统分析的基本工具。一个数据流图确定了系统的转化过程、系统所操纵的数据或物质的收集（存储），还有过程、存储、外部世界之间的数据流或物质流。数据流模型把层次分解方法运用到系统分析上，这种方法很适用于事务处理系统和其它功能密集型应用程序。

　　数据流图：描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。相反，当你在系统设计阶段建立实体联系图时，通常要定义系统数据库的物理结构。

　　状态转换图：实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入激励。这样的系统是有限状态机的例子。大多数软件系统需要一些状态建模或分析，就像大多数系统涉及到转换过程、数据实体和业务对象。

　　对话图：在许多应用程序中，用户界面可以看作是一个有限状态机。在任何情况下仅有一个对话元素（例如一个菜单，工作区，行提示符或对话框）对用户输入是可用的。在激活的输入区中，用户根据他所采取的活动，可以导航到有限个其它对话元素。因此，许多用户界面可以用状态转换图中的一种称为对话图来建模。对话图描绘了系统中的对话元素和它们之间的导航连接，但它没有揭示具体的屏幕设计。

　　类图：面向对象的软件开发优于结构化分析和设计，并且它运用于许多项目的设计中，从而产生了面向对象分析、设计和编程的域。类图是用图形方式叙述面向对象分析所确定的类以及它们之间的关系

如果想了解更多相关内容请访问:

 

http://51cmm.csai.cn/SoftQuality/No016.htm

 

也谈系统分析员论文试题的应试方法

--------------------------------------------------------------------------------

 

来源：希赛网 作者：田俊国

论文试题考什么？

　　关于系统分析员论文试题的应试方法，有一篇经典的文章--《系统分析员级下午试题II(论文)解答方法》（下称《方法》）,笔者当年备考试时曾研习多遍，受益良多。文中提到论文考试的目的有三：

　　(1)检查应试者是否具有参加软件项目工作的实践经验；

　　(2)检查应试者分析问题与解决问题的能力，特别是应试者的独立工作能力；

　　(3)检查应试者的表达能力。

　　笔者认为，系统分析员考试的下午两卷试题，主要是对应试者软件项目经验的考察。实践经验是捏造不来的，分析问题和解决问题的能力也需要在实践中提升,不是单靠读书就能奏效的，，缺乏实践经验，即便表达能力再强，也只怕腹中空空，乏善可陈。所以，没有几个大的项目实践经验，想通过系统分析员考试几乎是不可能的事情。

　　论文试题从形式来看，无论哪一方面的论题，都要求应试者在论文中阐述清楚大致雷同的三个问题：

　　［问题1］简述你参与开发的软件概要和你所担任的工作。

　　［问题2］具体叙述你在参与开发的软件项目中是如何进行XXX的，采用了哪些主要技术？遇到过哪些实际问题？你还采取过哪些改进措施？

　　［问题3］简述你所采用XXX的效果。你有哪些主要体会和进一步的设想。

　　对这三个问题，只要你真正经历了项目的研发过程，是不难回答的。首先，问题一是不需要过多为难就能够回答的；问题二要求阐述你所参与项目中某一角度或某一层面的实际问题的解决办法，要写亲身经历，列举事实；问题三要你描述所采用措施的效果以及进一步改进的想法，实际上是总结和展望。

　　写论文是你展示系统分析员水平的最佳时机，如果你通过对上述三个问题的阐述，能让人相信你有项目实践经验，有较强的分析问题、解决问题的能力，那么，你的论文就很有说服力。下面是笔者总结的几条应试法则，希望对读者有所帮助。

论文应试法则

法则一：多总结，要全面，以不变应万变

　　《方法》指出，论文试题的考核内容都是软件开发和维护工作中的具有共性的问题，即通用性问题，与具体的软件应用领域无关的问题。所谓共性的问题，概括起来无非三个方面：新技术的应用、软件性能设计和项目管理方法与技术应用。下表是近五年论文试题的分类情况：

 

　　把握了上述规律，我们就有以不变应万变的办法。所谓不变，就是你所参与的软件项目不变，应试者应该在考前总结一下最近所参与的最有代表性的的项目，来回答三个问题中的第一题。不管论文的题目为何，项目的概要情况和你所承担的角色是不必改变的，如果你觉得有好几个项目可以选，那么就应该检查所选项目的规模是否能证明你的实力或项目是否已年代久远。要应付万变，就要靠平时的全面总结和积累。系统分析员应该是善于对项目分析和总结的，不总结永远没有提高。对过去完成的项目，我们要三省其身：项目中采用了哪些新的方法和技术？系统的各种性能是怎么设计的？采用了哪些项目管理手段和技术？从多个侧面对过去的项目进行回顾，把其中的经验和教训归纳成条，自然就形成"土香气"的、令人信服的东西。临场时，把你以前总结的和论题相关的经验描述出来就回答了问题二。问题三要求指出你所采取措施的效果，最好有一些数据或实例来说明问题。最主要的，你的进一步设想，必须以发展的眼光看你所采取措施的局限与不足，原则上，任何方法技术都有两面性，所以要清楚认识到你所采取措施的优缺点。最后，将与论题相关的业界最新发展情况加以展望也是必要的。

法则二：平时多积累，临场自不急

　　系统分析员考试不同与其他考试的突出特点是靠临场突击收效甚微。功夫全在平时，仅靠对一个项目多角度的总结仍然达不到系统分析员的水准。项目经验丰富的应试者还应该对以前做过的项目进行一次盘点，对每个项目中采用的方法与技术、性能与特性设计、工程管理手段等进行总结。这样，临场时可以将不同项目中和论题相关的经验和教训糅合在一个项目中表述取来，笔下可写的东西就多了。举个例子，如论述数据库的安全性上，你可以先将A项目的安全性设计作为你的最初方案，然后分析该方案的缺点（采用该方案遇到的问题），然后将B项目中安全性设计发案作为改进方案，最后谈谈改进方案收到的效果。这样，你就成功地将A项目积累地经验（教训）嫁接到B项目中了。

　　还有，自己做过的项目毕竟是很有限的，要大量参考其他项目的经验或多和同行交流。多读报刊、网络上介绍大型项目的文章，从上述几个角度去审视这些项目的做法，从中汲取经验，也很有好处；和同行交流，互通有无，一方面对自己做过的项目进行了回顾，另一方面，也学学别人的长处，往往能收到事半功倍的效果。

　　总之，经验越多，可写的素材就越丰富，胜算越大；平时归纳总结了，临场搬到试卷上就驾轻就熟了。

法则三：条理清晰，开门见山

　　前面两个法则的着眼点放在论文的素材积累上，做好这两点可有效抑制泛泛而谈，言之无物的毛病。然而，光有内容，组织不好也会影响考分，论文的组织一定要条理清晰。题目选定后，迅速整理一下你所掌握的素材，列出提纲，即你打算谈几个方面，每个方面你是怎么做的，收效如何等等，简明扼要地写在草稿纸上。切忌一点，千万不要试图覆盖论文题目的全部内涵而不懂装懂，以专家的姿态高谈阔论，而将侧重点放在汇报你自己在项目中所做的与论题相关的工作，所以提纲不要求全面，关键要列出你所做过的工作。

　　下来的事情就是一段一段往出写了。要知道，评卷的专家不可能把你的论文一字一句地精读，要让他短时间内了解你的论文内容并认可你的能力，必需把握好主次关系。一般说来，第一部分的项目概述评卷专家会较认真看，所以，你要学会用精练的语句说明项目的背景、意义、规模、开发过程以及你的角色等，让评卷人对你所做的项目产生兴趣，这里面可以适当吹捧。第二部分要回答问题二，最好分条陈述，每自然段的第一句就开门见山指出你所采取的措施，然后指出你为什么这样做，这样做有何优点，克服了以前做法的哪些缺点等等。最好对你所采取的措施分一下主次，先陈述你认为重要的措施。第三部分和第二部分往往是密不可分的，你所采取的每一措施都应该有效果，所以索性把措施收到的效果写到第二部分也行。第三部分的开始，又是评卷人的一个重要看点，他要搞清你还有什么设想和改进。这一块要充分发挥你在书刊或和同行交流中得到的启示，指出你的项目和国内、国际先进水平间的差距，大胆设想如果再给你一次机会，你应该怎样在现在的基础上提高设计水平。

　　最后，把各段的提纲串连起来就是一个摘要，大功告成。再罗索一句，最好不要先写摘要，先写摘要浪费时间，还可能限制正文的发挥，正文写完了，归纳出摘要是水到渠成的事情。

法则四：图文并茂，能收奇效

　　论文的紧要地方，如果能画个草图表示，往往能收到奇效。因为图形比文字更能吸引人的注意力，通过的图形方式表达你所要表达的东西，评卷专家可能会更直接一些了解你所做的工作，对你的论文产生兴趣，多看上几眼，你便有更多被认可的可能。再说，图形方式展示你的成果也是你表达能力的重要体现。

　　比如说项目概述一段，你可以对你的软件构件以草图说明，把各个部分的关系在图上标出；系统安全性问题，你可以把你所采用的几级安全防护措施用图表示出来。

法则五：标新立异，要有主见

　　设想一下，如果评卷专家看了你的论文有一种深受启发，耳目一新的感觉，结果会怎么样？你想不通过都难！所以，论文中虽然不要刻意追求新奇，但也不要拘泥于教科书或常规的思维，一定要动脑筋写一些个人的见识和体会。这方面，见仁见智，在此不予赘述。

结语

　　参加系统分析员的论文考试的确是一次实力的对话。笔者当年考试的感觉是：上场十五分钟左右的思考，就开始埋头苦写（酷似过去的科举考试），两个小时下来，手腕都酸了，尚有意犹未尽的感觉。因时间原因，笔者不得不放弃还没写完的正文转而写了个摘要草草交卷，但对论文部分的发挥感觉特别良好。因为，笔者写的东西基本能体现了自己的水平，要向评卷专家表达的思想基本都说清了，如果不能通过也没什么抱怨的。结果还是涉险通过了（48分）。

一般来说，论文考试比简单的问卷考试及面试都要难，如果应试者能通过一个适当的话题，全面地、系统地展现个人的软件研发工作经验以及分析问题解决问题的能力，那么，得到评卷专家的认可也不是很困难的事情。

作者简介：

　　田俊国，系统分析员，西安山脉科技发展有限公司项目管理部。Email 

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/SATutorship/No034.htm

 

系统分析员水平考试堪忧

--------------------------------------------------------------------------------

 

作者：刘兴

　　编者按：这是一篇老文章，原刊登于《计算机世界》报1996年12月23日第197版。但等我们读完后，并不感觉到文章老旧，相反，获益匪浅。刘兴先生早在5年以前就提出要成立系统分析员协会，为中国系统分析员呐喊，但因各方面的原因，未能如愿。

　　我国计算机软件人员水平考试于1984年从上海开始，以后由部分省市自治区联考发展到全国统一考试。国家根据全国信息化建设发展的需要，1989年又在软件水平考试中增设了系统分析员级考试。

　　回顾1989年以来系统分析员水平考试的7年历程，可以容易得出结论：系统分析员水平考试堪忧！

（一）

　　截止到1995年，在7年时间里，全国共有多少人报名参加系统分析员考试，由于查不到资料而无法知道，合格人数从《计算机世界》报上一篇文章中得知是270人。7年270人，7年只有270人！平均每年只有39人！我国除台湾省外共有30个省、自治区、直辖市，一个省还平均不到2人！我国是一个有十二亿人口的大国，是一个在大搞信息化建设发展中的大国，平均每年只有39人，实在是少得可怜！

　　再让我们看看国外的情况，由于当前国内所有报刊杂志很少登载有关系统分析员的文章，因而资料十分匮乏。根据我手头仅有的一份资料，日本从1969年开始举行软件人员水平考试，于1971年开设特级软件人员（相当于我国系统分析员）水平考试。截止1988年共18年，报考特级水平考试人数为156878人，共合格8821人，合格率为5.6%，平均每年合格490人。与我国相比，日本每年合格的特级人数将近是我国7年总和的2倍。这是多么令人吃惊的数字！

　　这里还想讲一个令人吃惊的系统分析员考试被零落的情况。

　　中国软件行业协会出于对发展中国家软件事业的责任感，于1992年年初开始，连续在一些计算机专业报刊上刊登广告，发布将在北京举办程序员、高级程序员和系统分析员三个级别考前辅导班的消息。可从冬到春，从春到夏，从夏到秋，终因报名寥寥该系统分析员辅导班未能办成。到了1993年，中国软件行业协会做了半年多的广告，发出了无数封信，同时联合了北京大学、清华大学、中科院等单位好不容易在暑假期间办起了系统分析员考前辅导班，可学员总共才有9人，而这9人来自三省二市。学员竟没有突破一位数！学员如此之少，是否因辅导班教学质量差？恰恰相反，笔者有幸参加了此次辅导班，深感该辅导班是笔者参加所有辅导班中教学质量最高的。讲课的老师都是各个领域的专家，有的还是国内著名学者。他们讲课深入浅出，一丝不苟，使笔者获益匪浅。

　　自此以后，全国再也没有哪个单位举办过系统分析员辅导班。

（二）

　　既然系统分析员水平考试如此被冷落，那么是否说明我国当前没有对系统分析员的需求呢？答案正好相反，我国当前不但对系统分析员有需求，而且有强烈的需求。

　　当前，一场席卷全球的信息化建设热潮正方兴未艾。我国政府也正在抓住一切有利时机，加快我国信息化建设步伐。1994年，国务院正式成立了国家经济信息化联席会议，统筹规划全国经济信息化建设。在这一进程中，中央以实施"三金工程"（金桥、金关、金卡）为突破口，为全国起到示范和推动作用。全国各级政府部门和大中型企业也都积极行动起来，大力推广计算机应用，提高办公自动化水平，加强通讯设施建设，有条件的单位开始着手建设本部门、本企业的MIS 。

　　建设大型MIS是一项极其复杂的系统工程，它既需要有大量的物质、资金和人力的投入，又存在诸多的技术问题需要攻克，更有许多诸如组织、行政、管理、人际关系等社会问题需要解决。因而建设MIS，需要有一支训练有素的技术和开发队伍，而在这支队伍中，扮演最重要角色的就是系统分析员。

　　对系统分析员素质要求是很高的。系统分析员首先是计算机方面的专家，他们应该是既对计算机、通讯等专业有较深入的、全面的理论知识，又有较长时间软硬件开发的实践经验；同时，他们还应该是企业管理方面的专家，他们不但应该熟悉并掌握企业管理的理论和方法，而且应该有深入扎实的企业管理的实践。另外，系统分析员还应该是一个优秀的领导者，他们应该具有组织和管理才能，会妥善处理各种人际关系，能够团结各方面人员一道工作。

　　由于系统分析员本身具有较高的素质，因而他们理所当然地应成为信息系统的设计者，又应是系统实施的组织者和领导者。系统分析员应该是企业管理层特别是高层决策者与系统开发人员间的联络员和信息沟通者。

　　这里需要指出，当前这种完全靠企业自己培养建设开发队伍来开发本企业MIS的情况已经不适应形势发展的需要。普华资深顾问贝奕指出，"目前，西方国家自己开发管理系统的企业已经很少，因为他们都明白，建立信息系统并不是企业的核心任务，专门培养一支信息技术开发队伍费用很高，即使这支队伍建立起来了，他们从掌握最新技术的能力到开发经验都不如专业公司，开发出来的产品投资不会少，而软件健壮程度都低于商品化软件。"我国也有越来越多的企业把开发MIS的任务委托给专门公司。在这种情况下，企业拥有自己合格的系统分析员尤为重要，因为这时，企业要与专业公司打交道，不但有企业内外信息的沟通，而且要协调企业与专业公司的关系，有时甚至可能在经济利益上与专业公司发生冲突。这时，系统分析员应该是企业利益的代表者。由于他们具有专业上的优势，因而由他们来与专业公司打交道，会显得得心应手，从而可以更好地维护企业利益，大大地提高信息系统开发的成功率，增强信息系统的健壮性和适用性。

　　至于专业公司，需要合格的系统分析员更不待言了。

　　从以上分析可知，我国社会正急需一批合格的高水平的系统分析员。

（三）

　　那么，人们不禁要问，为什么系统分析员水平考试竟遭如此冷落呢？

　　笔者认为，其中的主要原因有：

1、缺少舆论宣传

　　由于我国计算机应用起步比较晚，因而普及程度比较低。近几年，由于不断地宣传，更由于一些企业成功的开发实践，逐步使MIS的概念被政府部门和企事业的管理人员所了解和认识。至于系统分析员，时至今日，仍无有任何报刊杂志，任何会议作过介绍和宣传。

2、考试目的模糊

　　关于考试目的应该包括两个方面，一方面是个人参加考试的目的，另一方面是国家举行考试的目的。

　　这里首先谈谈有关个人参加考试的目的问题。

　　我国现行软件考试是将专业技术资格考试与水平考试合并进行，其中除系统分析员级无资格考试外，其他级别（初级程序员、程序员、高级程序员）都有资格考试。有资格考试，一个人参加考试的目的是显然的，就是要取得相应级别的任职资格。这当然具有一定吸引力，但是，系统分析员考试就无此吸引力了。"暂行规定"中明确规定，"系统分析员水平考试合格可以做为评聘高级工程师的条件之一"。然而，这里的"可以"和"条件之一"无疑包含可以评，也可以不评之意，而 "条件之一"更是很虚的内容，根本无法用来去 "评聘高级工程师。

　　再说国家举行考试的目的。按着"暂行规定"所说，是"跟踪国际水平"。《对<中国计算机软件专业技术资格和水平考试暂行规定>的几点说明》中说，"水平考试是一种业务、学术水平的测定考试，其主要目的是为了追踪'国际水平'，便于国际间的人才交流与技术合作。"笔者不明白是出题水平"跟踪国际水平"呢，还是合格人员在专业上"跟踪国际水平"？如果是前者，是做到了；如果是后者，则远没有达到。可以说，从上到下在这方面所做工作甚少。

3、缺少配套政策

　　我国软件水平考试如同一个孤岛，与其他社会和企业活动都缺少联系，特别是系统分析员更是这样。因而无法形成一个有利于合格人员发展提高的氛围。总起来可以概括成一句话：缺少配套政策。当前我国除了"暂行规定"和"考试大纲"外，没有别的政策文件涉及水平考试。

　　我于1993年获得了系统分析员水平证书。3年多时间已经证明，此证书根本没用，只好藏之箱底。目前，我国一个机关工作人员要经常填表，评职称填表、提职填表、调动工作也要填表，但所有这些表都没有填系统分析员的地方，因它不是学历、不是荣誉、不是科技成果、也不是职称。在讲文凭不讲水平的今天，哪会有填水平证书的地方呢？

而在日本，就是另一种情形。计算机软件人员考试已成为日本国家考试中规模最大的考试。1988年参考人员竟多达43万。日本社会非常重视一年一度的这个考试。各个软件公司也相互炫耀各自各级的人数，以显示本公司的技术实力和企业教育水平。因此在考前争相采取措施，如组织模拟考试和辅导等。考后对合格者给予适当的鼓励和奖励。

4、国家考试中心的作用发挥不够

　　1990年成立了在中国计算机软件专业资格和水平考试委员会领导下的中国计算机软件专业资格和水平考试中心。应该说，为了提高软件考试的知名度，扩大其影响，每年考试中心应该把各级别当年和累计的报考人数、合格人数等数据在有关报刊上公布，对于系统分析员由于合格人数较少，应该公布名单。做为专职机构的考试中心，做到这点应该是不算难事，但却没有做到。

　　至于考试中心 "对考试合格人员再培训，提高软件专业水平，促进国际间人才交流"更是缺乏。

（四）

　　为了改变系统分析员考试被冷落的局面，笔者建议：

1、做好宣传舆论工作

　　利用各种传媒，特别是利用专业报刊杂志大力宣传软件水平考试，不断提高水平考试的知名度，扩大考试的影响，鼓励有志的业务人员积极报考，鼓励和奖励考试合格者，造成人人立志成才的社会氛围。

2、 修改"暂行规定"

　　把现行"暂行规定"中的"系统分析员水平考试合格可以做为评聘高级工程师的条件之一"修改为"系统分析员水平考试合格者即具有高级工程师任职资格"。

3、 给考试合格者以进修提高的机会

　　水平考试合格只说明一个人业挀瑡潩?潮搬爀捥??????瑡獵渽?务、学术水平达到了一定的标准，但由于信息产业发展十分迅速，对任何一个人来说每天都有大量的新知识需要掌握，因而国家应制定相应政策，给应试合格者以进修提高的机会，给他们以参加国内培训和出国培训的机会，丰富他们的知识，提高他们的水平，充分发挥他们的作用。特别是系统分析员，由于他们在信息化建设中扮演重要角色，因而更应优先地给他们参加国内培训和出国培训的机会，多渠道开展国内和国际间的学术交流活动，促进我国系统分析员队伍健康成长。

4、 建立系统分析员注册制度

　　为了使信息化建设健康有序发展，国家应制定政策，建立系统分析员注册制度，规定凡是系统分析员水平考试合格者都可以经过个人申请，单位推荐，上报有关主管部门给予注册，纳入统一管理，真正实现"暂行规定"中的开展"国际间人才交流与技术合作"的目标。

5、 在大中型企业中设立系统分析员职位

　　本文前面在论述系统分析员作用时指出，"系统分析员"应该是企业管理层特别是企业高层决策者与系统开发人员间的联络人员和信息沟通者"。如果系统分析员在企业中一点地位也没有，要他们发挥重要作用是根本不可能的。为了保证企业决策层对企业信息化建设实施正确的、强有力的领导，在大中型企业领导班子设立系统分析员的职位是非常必要的。

6、 建立系统分析员学会

　　为了适应信息产业日新月异的发展，当前非常有必要建立一个突出学术特点，有系统分析员水平考试合格人员参加的全国系统分析员学会。国家有关部门可以通过学会指导全国信息化建设，组织国内和对外学术交流活动。

 

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/SATutorship/No024.htm

 

 

系统分析员论文样例

--------------------------------------------------------------------------------

 

中石化金卡工程江苏省联合办公室 尤一浩

（江苏省南京市中山南路242号 邮编：210005 电话：4209423）

江苏省石油集团公司信息技术管理处 司文全

（江苏省南京市中山南路242号 邮编：210005 电话：4209423）

 

论建立企业内部网INTRANET的策略

　　近年来，英特网internet以其丰富的应用在社会的迅速得以普及，internet技术的先进性，引起的企业的广泛关注。于是利用internet技术的思想，在企业局域网（LAN）上加以应用，组建企业内部网Intranet（在互联网上，相对于英特网现在有人称为内特网）成为时尚。

　　作为一名单位内信息中心的技术骨干，我有幸独立完成了整体方案设计、组织参与了本单位的Intranet的建设并承担了部分软件的开发工作。该方案实施后，集成了原有的业务应用系统，建立了企业内部信息发布系统和FTP文件传输系统，并与下属单位实现了网络互连，实现了相互间信息共享，并利用VPN技术利用INTERNET网能访问总公司的Intranet。 现将实施这一工程的一些方法和策略以及我们采用的一些措施介绍如下，希望能对组建中小企业Intranet网有所启发：

　　基本情况：1、应用单位情况：某外运集团在某口岸外贸运输企业，是一家经贸部属企业，是集团的分布各地的一个分支机构，承担进出口货物的运输代理，以进出口货物的单据流转为主配合物流为客户服务作为主业务。

　　2、计算机应用情况：现企业有一局城网，NT 4.0平台，运行的核心应用软件为集装箱运输代理业务系统，为VISUAL　FOXPRO 5.0开发的网络多用户系统。还有其它一些人事、财务、统计软件、办公软件（OFFICE）在使用。有专门的计算机应用机构4人。

　　本单位Intranet网的实施主要是针对系统内信息流转不畅的需求而得以进行的。在实施方案的过程中我们主要进行了如下的策略选择：

　　1、网络建设方案：单位原有一局城网，25个信息息点。但随着信息化建设的高要求，已远远不能满足需要。单位有6层办公楼，要求人手一机，同时要求与三个基层单位（车队、外运仓库）和一个集装箱站相连。领导层、中层干部等都要求有相应数据和各种查询。对于本单位情况，首先在办公楼进行了综合布线工程，由于办公楼不大，集用了集中走线的方案，采用5类线，100M带宽，125个信息点。交换机采用12口3COM 3C5092A 10/100M自适应设备，共享HUB采用数个3COM 16口HUB。并选用CISCO 3600作为路由器，4个广域网口连接4 个远程基层单位和箱站，采用拨号方式.并将来打算用帧中继FR与北京总部相连（因为经费，暂时没有申请）。由于单位多为PC机，有庞大的WINDOWS用户群，故网络平台也采用WINDOWS NT4.0.采用Intranet的基础协议TCP/IP作为网络协议。

　　另外对于办公楼较大的可采用采用结构化布线，大对数电缆做主干，设主工作间、每层设水平工作间的方案进行。若有好几个楼群如校园网，可采用光纤做主干网（FDDI），再在每个楼实行P&S布线。

　　2、 软件平台的选择：当前流行的Intranet平台，有A、基于UNIX，B、基于LINUX（开放源代码的OS） C、基于微软平台WINDOWS NT。考虑到中小企业的特点、可供选择的第三方软件比较多、支持微软平台的软件厂商多以及方便用户简便易操作、GUI界面等因素，我们选择了windows nt4.0作为网络操作系统,用自身配备的IIS4.0作为WEB平台,IE4.0作为客户Intranet网上浏览平台. 相比于SYBASE、ORCALE、INFORMIX、DB2等大型数据库由于SQL SERVER是与NT平台具与极佳的配合性能的小大型数据库,对中小型企业较为合适,自然就选择SQL SERVER6.0作为数据库平台. 另外，用LINUX平台技术当前也十分红火，从技术上讲也是完全可以胜任的，只是考虑到学习上的要一断时间，以及用户的接受能力故未采用。

　　3.由于我们自已的技术力量较强,并且面对外运行业的商品化软件较少.我们打算自已开发INTRANET上一些WEB应用软件.开发平台用VISUAL BASIC/FRONT PAGE/Html editor,由于还要开发一些交互式WEB应用程序，还要采集原应用系统的数据。需要掌握相应用交互式开发技术和与数据库相连的技术，如CGI（公共网关接口）、API（应用程序编程接口）、ASP（活动服务器页）、ODBC（开放数据库互连）、RDO/ADO（ACTIVEX DATA OBJECT活动数据对象）。在上述技术中，考虑到响应速度和效率，我建议采用ASP加ADO的技术进行开发。并且这是当前和将来的INTERNET/Intranet网主流开发技术。

　　4、内网与外网的互通以及安全考虑：由于属中小企业，单位上英特网的并发用户数一般不会超过15人，我们采用了较为低廉的ISDN一线通方式，专用一台PC用安装了代理服务器软件（PROXY），可实现按需拨号、HTTP代理、FTP代理、TELNET代理、SMTP/POP

　　邮件代理、用户管理等，可设快速缓冲。当然，用DDN方式，申请合法的IP地址再设代理的方式也可行，只是由于经费的原因，没有选择。由于内外网的互通，如果没有一定的安全机制，将使公司的内部数据、机器、应用系统受病毒或黑客的攻击或非授权访问等。

　　内外网间的安全技术有包过滤、防火墙、安全代理服务等，由于我们选择的代理服务器软件已有部分安全方面的机制并且内部数据的安全措施、管理制度、备份机制做的还可以。故没有在这方面投入更多的资金。在内部局域网上，我们选择了NET　VRV（50用户）网络版防病毒软件，在服务器端和客户端都各自安装相应的版本，保证了内网的安全可靠性。当前，做网络安全的公司很多，如王江民的KV系列、瑞星公司等都可选择。

　　5、原有的应有系统与Intranet技术的集成：由于原应用系统是基于FOXPRO，数据库为文件型数据库，所选的WEB应用开发环境并不能直接操作FOXPRO数据库。对此我们有另外编制了一个软件用于每天从应用系统中将管理者与领导层要的数据导入SQL SERVER中，再以SQL SERVR为后台，编制WEB交互查询系统。

　　6、与集团总部的相连：现在WIONDOWSNT4.0支持一种新技术即VPN(虚拟专用网),对于实时性要求不高又受经费困扰的应用来说,无疑是一种较为可行的方案,由于总部的条件较好,已建设好INTRANET网,并通过路由器以DDN与INTERNET直通.分公司在目前条件下,与总公司的连接是暂通过INERNET网,并在此链路基础上,运行PPTP协议(而非PPP协议),虚拟出一个数据通道,并在此基础上,通过用户身份验证即可实现总公司Intranet与分公司LAN的连接.现在的应用有,分公司的LAN用户可直接浏览总公司的Intranet网的WEB站点.同时,全系统的业务统计软件也是改为通过WEB应用程序实现的。

　　Intranet网运行后,在公司的用户间获得好评,客户界面(IE)的单一化,简化用户培训学习的过程.同时,网络的建成,极大方便了系统内信息和单据的流转速度,文件、数据的上传、下载十分方便.原有的应用系统数据还可通过IE浏览查询.部分WEB应用程序的建立,使客户端的维护成本大大降低.同时Intranet的成功运行，也使得我们的信息部门的地位有所提高。

　　但是，由于单位性质、规模的许多局限性，诸如费用、本身的技术水平、系统分析能力等，使一些应用走了简单、实用、低廉的策略。我们仅做了一台WEB服务器、一台SQLSERVER服务器和一台主域NT服务器，由于机器较少，没有作域名分配；对于与原文件型数据库的应用系统，没有采用效率更好的方法，做了简单化处理；与总公司总部的相连，速度稍难忍受、高峰堵塞严重，一般使用都各分公司划时间段使用；另外，在说服领导花钱投入加以重视方面还有待改进；也许，采用与软件公司、ISP等专业公司合作开发会更好地把本企业Intranet网做好。

　　鉴于上述原因，我认为我们公司的Intranet网将来还要作如下方面的改进：

　　1、通信线路的改进：随着各种数据通讯网的建立和改善以及费用的逐步下降，分公司与总公司、分公司与基单位将来都应该采用DDN/FR甚至光缆等专线接入。

　　2、软件应用模式从DOS单用户、文件型数据库多用户、C/S、向B/S结构、三层结构和多层次结方向方向发展，我们单位，将来的应用升级可直接使用B/S结构、三层结构，在开发技术中要广泛使用面向对象OOP、COM/DCOM构件组件、ADO数据库连接对象、ASP技术。并且开发方式也要采取与专业技术软件公司进行合作或委托开发的形式，否则，自已开发的软件的质量、可靠性等方面都难以达到软件工程的高要求；另外，更要在开发中重需求分析、重建模（可采用UML建模技术）、加强项目管理、团队协作。

　　3、在1-2年内，用专线接入INTERNET网，建立基于INTERNET网的客户查询系统，在内外网间设立防火墙。

 

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/SATutorship/No026.htm

 

 

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/NewTech/No056.htm

 

SQA到底是什么? 

作者：河清（来源：希赛网）  http://www.csai.cn  2003年03月10日

一、 前言

本人在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教，如果要和本人联系，请发Email到：heqingemail@163.net。

二、SQA的理论探索

2.1、过程的 认识

我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。

软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是“人、过程、技术”。

首先要明确的是这三个因素中，人是第一位的。

现在许多实施CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。

“XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。

根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了“要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。

如果我们考证一下历史的沿革，应当更加容易理解CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：

质量重要

规模较大

这是CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。

上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨论SQA。

2.2、生产线的隐喻

如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。

抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含“决策、执行、反馈”三个重要方面。

QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

 

2.3、SQA和其他工作的组合

在很多企业中，将SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。

根据hjhza 的意见“中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。

下面根据本人经验对它们之间的关系进行一个说明。

2.4、QA和QC

两者基本职责

QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；

QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；

注意区别检查和审计的不同

检查：就是我们常说的找茬，是挑毛病的；

审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。

在这样的分工原则下，QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。

如果企业原来具有QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

2.5、QA和SEPG

两者基本职责

SEPG：制定过程，实施过程改进；

QA： 确保过程被正确执行

SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。

QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。

如果企业的SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进；但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。

管理过程比较成熟的企业，因为企业的文化和管理机制已经健全，SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。

另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选；这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。

这种情况在许多CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因；因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛！

2.6、QA和组织级的监督管理

有的企业为了更好的监督管理项目，建立了一个角色，我取名为“组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。

为了有效管理项目，“组织级的监督管理者”必须分析项目的数据。

他们的职责对照上图的模型，就是执行“反馈”职能。

QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。

SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。

如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理；而QA来确保这个管理过程的运行。

三、SQA的工作内容和工作方法

3.1、 计划

针对具体项目制定SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：

有重点：依据企业目标以及项目情况确定审计的重点

明确审计内容：明确审计哪些活动，那些产品

明确审计方式：确定怎样进行审计

明确审计结果报告的规则：审计的结果报告给谁

3.2、审计/证实

依据SQA计划进行SQA审计工作，按照规则发布审计结果报告。

注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。

审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

3.3、问题跟踪

对审计中发现的问题，要求项目组改进，并跟进直到解决。

四、SQA的素质

过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。

服务精神：为项目组服务，帮助项目组确保正确执行过程

了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识

了解开发：对开发工作的基本情况了解，能够理解项目的活动

沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

如果想了解更多相关内容请访问:

 

http://51cmm.csai.cn/SoftQuality/No016.htm