计算机科学基础知识Word文件下载.docx
《计算机科学基础知识Word文件下载.docx》由会员分享，可在线阅读，更多相关《计算机科学基础知识Word文件下载.docx（20页珍藏版）》请在冰点文库上搜索。
例如对于一个电子政务项目而言，前期可能只会给出该项目的定位，例如“通过将现有手工业务转变为软件支撑的电子流工作方式，提升工作效率，并对现有的业务模式进行合理优化”。
可是如何对这样笼统的项目要求进行细化，并将其转变为相应的软件需求规格，软件开发团队还面临着各种挑战。
首先是获取单一部门内的业务流程，现有的业务流程可能本身就存在不合理或者冲突的情形，需要需求分析人员与业务人员进一步讨论才能确定。
如果涉及到部门之间的业务流程，其困难程度还会进一步加大，因为不同部门的人员都倾向于站在自己的立场来考虑问题，所以部门之间的业务流程确定往往还需要领导的强力参与。
伴随着组织业务流程的调整，通常意味着部门和人员的重新定位，有时甚至影响相关人员的切身利益，此时的需求分析将会面临更大的阻力。
除了来自业务部门本身的挑战外，业务人员与技术人员的沟通也存在明显的障碍，即客户与技术开发方对业务需求的理解不一致。
客户方的业务人员通常认为自己对业务需求的表述清楚无误，而开发方却觉得业务人员语焉不详，并没有将业务的来龙去脉交待清楚。
不少项目在各方对于需求的理解还未达成一致的情况下就开始项目，结果项目是边做边改，等到项目临近结束时，需求已“面目全非”，与双方前期确定的需求相差甚远。
试想，一栋大楼或一座大桥在还未确定功能或结构的前提下就开始动工，然后在施工的过程中再根据用户的要求不断变更，将会出现什么样的结果？
结果很可怕，所以没人做这样的尝试。
但软件项目不然，环顾我们身边的软件项目，有多少项目真正能够做到“谋定而后动”呢？
正是软件需求的脆弱性和易变性导致了软件项目的失控。
（2）项目目标失控，明显超出客户心理预期。
所有的软件项目在初期都会设置相应的管理目标，包括项目所要实现的功能、项目工期、项目预算以及项目的质量目标等。
可是在项目开发的过程中却发现这些目标无异于“海市蜃楼”，可望而不可及。
大部分软件项目或多或少地表现出下列特征：
要么是“种瓜得豆”，要求的功能大幅缩水；
要么是项目工期严重滞后，影响客户业务的正常运行；
或者项目严重超支，软件开发商虽然投入了额外的人力物力，但客户并不领情；
更有甚者，虽然软件系统勉强按时上线，但后续的质量问题却层出不穷，“摁下葫芦浮起瓢”，永远有解决不完的问题。
既然上述问题是目前软件项目所面临的共性问题，那么单一地将其归属为软件开发商的责任似乎有失公允。
设想这样的场景：
如果对一个小学班级进行数学测验，孩子们最后的平均成绩为30分（考试采用百分制）。
30分的平均成绩说明什么呢？
首先孩子们的数学知识学得不够好，怎么才考30分呢？
其次，数学测验题目有问题，为孩子们设置了过高的目标要求（学生家长往往更倾向于这种结论）。
对软件项目而言，也存在类似的现象。
所以在抱怨软件开发商工作绩效的同时，客户似乎也应该进行自我反省，客户要求的目标合理吗？
我国现在大部分的软件项目均采用招投标的方式来选择供应商，再加上在国内的软件行业中普遍存在“买方市场”的特点，许多软件开发商都存在“先拿到合同再说”这样的心理，故而往往对于客户所提的各种要求都满口应承，即使认为客户设置的项目目标不合理，也往往忍气吞声、委曲求全。
也有一些软件开发组织与客户签署合同之前，对于客户单方面设定的目标会提出不同的建议，例如更为合理的工期、成本与质量目标等，但这些建议对于客户往往缺乏足够的说服力。
因为大多数软件开发组织并没有一个明确的、量化的过程可以向客户表明自己所建议目标的客观性、合理性，代之以“根据我们的经验”、“参照我们以前的项目”等说法，因而缺乏说服力，最终只能接受客户方设置的项目目标。
但软件项目最终的结果却让客户追悔莫及，油然而生“早知如今，何必当初”的感叹。
所以如何为客户设定合理的项目目标至关重要。
（3）软件项目的成功过度依赖个人，缺乏来自组织的过程保证。
成熟与不成熟的软件开发组织相比较，其最大差异在于两者的可预期性。
不成熟的软件开发组织往往倾向于过度承诺，而实际开发过程中却经常面临捉襟见肘的困境：
要么是工期严重滞后，要么是成本超支，工期若能勉强得到保证，通常即意味着质量风险。
而高成熟度组织所做出的承诺通常可以得到真实的兑现。
在不成熟的软件开发组织内，更多地采用“游击队”、“个人英雄主义”的开发模式，在项目中甚至没有采用相应的软件配置管理平台，更没有进行软件项目计划与跟踪、软件项目质量评价等相应的管理措施。
这种“作坊式”的开发模式导致软件开发的最终结果主要取决于个人因素，而组织对软件项目的管理与控制则力不从心，只能寄希望于员工在工作中一直表现出认真、负责、任劳任怨的态度。
如果出现项目经理或项目组成员离职等情形，对软件开发的影响通常是致命的，新加入的人员不得不从头再将前任的工作完成一遍。
软件开发是一项群体的智力活动，软件开发过程是否高效、开发团队工作是否工作在同一基础之上、个人的工作成果能否完全融合到项目中等因素对于成功的软件开发至关重要，而要保证软件团队工作的有效性，来自软件开发组织的过程管理则必不可少。
适用于软件开发的典型过程管理模型包括ISO9000模型、CMMI模型和RUP模型等，而在这些模型中无一例外地强调了过程度量的重要性。
正是通过过程度量，我们才能评价当前工作的好与坏、正常还是异常、是否需要采取纠正措施或补救措施等。
“人贵有自知之明”被许多人奉为人生的圭臬，可是许多软件开发组织却缺乏“自知之明”，项目组的产出如何？
组织的开发绩效如何？
对开发过程中生成的需求或技术文档质量状况是否满意？
对类似的问题许多组织往往会采用“还行”、“不错”、“我们有信心”等模棱两可的说法来搪塞，因为组织根本就没有数据。
基于以上分析，目前软件项目管理所面临的困境可以归结为三个“说不清”：
需求说不清；
目标说不清；
过程说不清。
要做什么不清楚，做到什么程度不清楚，中间过程也说不清，这样的项目做出的软件可想而知会是什么结果。
说不清首先和软件本身的特点相关，从客观角度分析可能包含两方面的原因：
首先，软件不同于其他的有形产品，很多时候难以去想象最终的产品究竟是什么样子；
其次，软件的开发过程主要表现为人们的智力活动，表现为建立模型、编写文档和代码调试等可见性较低的活动形式。
所以上述两类原因导致人们对软件不容易“说清楚”。
除了客观方面的原因外，可能也有来自人员本身的主观原因。
现在各行各业都在倡导“定量化”的管理模式，对于软件行业也应该引入定量管理的理念，可为什么在国内的软件开发组织中真正采用定量管理模式的组织却少之又少呢？
第一，可能是由于思维惯性。
“我们一直都是这么跟着感觉走，也没出啥大问题嘛”，不愿意主动提升和优化现有的软件开发过程。
第二，和我们的传统文化有关。
如果采用定量管理的办法使得大家的工作都透明化，是否组织中的每个人都喜欢看到这样的结果？
中国的传统文化强调中庸，强调“水至清则无鱼”，你把账算那么清楚，犯得着吗？
所以我们看到在各个国家审计部门都不是一个受欢迎的部门，他们总是拿着数据报告要别人解释自己的行为或结果。
在软件项目中采用定量评价的方式虽不至于产生类似经济领域的“审计风暴”，但迫使人们在事后要关注自己的行为，有时甚至还需要为自己的行为进行解释。
在潜意识里，人们希望自己在工作中的束缚和来自外部的检查尽可能的少。
因而在软件开发组织中引入定量管理评价机制通常是不受欢迎的，甚至会遭到抵制。
因为存在这样那样的原因，所以我们国家的软件开发现状在最近5年、甚至最近10年并没有发生明显的变化。
虽然我们的软件行业表现得朝气蓬勃，但我们的沉淀和积累仍然不足。
如果我们对现状不满，那就必须做出改变。
如何改变？
在软件开发过程中引入定量管理评价方法则是必不可少的一个主要步骤，而定量评价方法的基础则是软件项目规模的评价。
如果能够在软件项目管理过程中引入基于功能点度量方法的规模评估，则有助于我们做到“需求说清楚”、“目标说清楚”和“过程说清楚”。
1.2软件规模评价方法
为什么说软件规模评价是软件量化管理的基础？
在实际的软件开发项目中我们好像更关注工期、成本和质量。
软件规模、工期、成本以及质量之间存在什么样的关系以及如何对这些关系进行定量表述是软件项目量化管理的主要内容。
在介绍这些依赖关系之前，有必要首先建立“和谐项目管理”理念。
对一个软件项目而言，在项目中会设置4个最主要的目标，即项目范围、项目时间、项目成本以及项目质量。
它们4者之间相互影响、相互依赖，如图1.1所示。
图1.1软件项目管理三角形
也许有些读者还记得若干年前我们国家的一句政治口号：
“多快好省地建设社会主义”，这种提法的出发点是好的，但忽视了经济建设的内在规律，最终导致了“大跃进”的局面，对中国经济的健康发展造成很大的伤害。
即使在我们大力倡导科学发展观的今天，仍然有不少客户和领导希望软件项目完成的功能越多越好、工期越快越好、成本越低越好、质量越高越好，岂不是“多快好省”模式在软件行业的完全翻版？
我们应该从错误的做法中汲取经验和教训，而不是重蹈覆辙。
我们现在的社会和经济发展强调“和谐”理念，对于软件项目管理也要遵循“和谐”的管理模式。
概言之，即要完成的软件功能有多少，就应该设置多长的工期，就应该设定多少预算，就应该设置相应的质量目标，而不是一味求快贪多，置客观事务的内在联系于不顾。
正如其他传统行业的定量评价机制一样，项目的工期、成本和质量目标的设置主要取决于项目所要完成的工作内容。
例如修建铁路的成本与工期主要取决于道路的长度；
办公大楼的建设费用与工期则主要取决于建筑面积。
所以要在软件项目管理过程中引入量化评价机制，对于软件规模本身的评价则是首要任务。
只有确定了软件规模，才能得到其他的项目管理目标；
只有预先设定了项目目标，定量管理才有执行的依据。
根据软件行业的实践，目前评价软件规模的方法可以区分为两种评价方法：
非标准评价方法和标准评价法。
非标准评价方法具有操作简单、容易实施等特点，但不容易在项目干系人之间达成一致，往往会引起较多的分歧；
标准评价法则较好地克服了非标准评价方法的不足，但因为其操作相对繁琐，很多情形下甚至需要外部咨询机构的辅导，因而在实际应用中也受到一定程度的限制。
1.2.1非标准评价方法
与软件规模标准评价方法相比，非标准评价方法更多采用约定俗成的方式，评价方法有较强的主观性，因而难以保证评估结果的一致性。
但因为这些评价方式简便易行，因而在我国软件行业中仍然占据主导地位。
典型的非标准评价方法包括软件源代码行评价法、对象点评价法、需求数量评价法、用例数评价法以及文档页码评价法等。
1．软件源代码行评价法
在所有的软件项目规模评价方法中，软件源代码行方法在我国的软件行业中仍然占据统治地位。
顾名思义，软件源代码行法就是以完成的软件源代码的数量表示软件项目所完成的功能的多少。
源代码行方法最大的特点即是简单，直接数出代码行的数量即可。
不同的项目源代码行数量不同，小项目可能只有几千行代码，而那些规模巨大的项目动辄会超过百万行。
但应用代码行作为评价软件项目规模的方法，其缺点也是显而易见的。
首先，代码行从技术而非业务角度度量软件规模。
对于没有足够技术背景的客户或其他项目外部干系人来说，代码行不具备说服力，他们总是倾向猜测技术人员使用了过多的代码来实现软件功能。
其次，代码行度量不及时。
度量软件项目规模的主要目的往往要在前期确定项目的工期、费用等关键指标，但在项目前期只有笼统的业务需求，只有当项目完成后才能得到真正的代码行数量。
项目前期或项目执行过程中估算出的代码行数量没有足够的说服力，不同人员估算得到的代码行数量也许会有50%的偏差。
第三，缺乏代码行度量标准。
一行代码是多长？
注释语句算不算？
跨行的语句算一行还是多行？
在行业中并没有一致的规定。
即使IEEE和SEI尝试过颁布了一些代码行度量标准，但并没有得到广泛的接受。
最后，不同语言编写的代码行可比较性差。
如何比较汇编语言、C语言或者Java语言编写的语句呢？
如果使用多语言开发的程序，又该如何度量代码行的数量呢？
虽然软件代码行方法目前在我国的软件行业中仍然是一种普遍的规模估算方法，但因为其一致性不容易得到保证，越来越多的软件开发组织倾向于采用标准评价方法（功能点标准）来衡量软件项目的规模。
2．对象点评价法
对象点（ObjectPoint）评价法属于BarryBohem所提出的COCOMOII模型的组成部分，主要适用于基于组件或可视化开发环境的项目，同时也适用于原型项目。
对象点评价法基于加权的概念将软件项目的工作内容转换为相应的对象点数量，它包含最基本的三个对象点类型：
屏幕、报表和组件。
屏幕对应的复杂度加权表如表1.1所示。
表1.1对象点评价法的屏幕计算表
屏幕计算表
包含的视图个数
引用数据表的个数
总数<
4
（<
2Server;
<
3Client）
8
（2～3Server;
3～5Client）
总数>
（>
3Server;
>
5Client）
3
简单
平均
3～7
困难
>
如果一个屏幕包含了5个视图，且访问了5个数据表，其中两个是Server端的数据表，而另外三个是客户端的数据表，则该屏幕对应的复杂度为平均。
报表对应的复杂度加权表如表1.2所示。
表1.2报表的复杂度加权表
报表计算表
报表的节数
2Server;
<
0,1
2,3
4+
如果一个报表包含三个节，访问一个服务器端的数据表，对应的复杂度为简单。
对象点评价法中并没有对组件设置相应的复杂度加权表，所有的组件默认其复杂度为平均。
确定了屏幕、报表以及组件的复杂度，然后再根据对象点权重表将其转换为统一的对象点，如表1.3所示。
表1.3对象点权重转换表
对象点权重表
对象类型
复杂度权重
屏幕
1
2
报表
5
三代语言组件
10
如果一个软件开发项目要完成10个平均复杂度的屏幕、8个平均程度和3个困难程度的报表以及2个三代语言组件，则该项目的对象点规模即为（10×
2+8×
5+3×
8+2×
10）=104。
基于对象点的生产率对应表（如表1.4所示），即可推算完成该项目所需要的工作量。
假定项目组的生产率为平均水平，则对应的工作量为8人月（103/13=8）。
表1.4基于对象点的生产率对应表
OP对应的生产率
开发人员的能力及开发环境的效率
生产率（NOP/人月）
很低
低
7
13
高
25
很高
50
对象点评价法的评价方法一致，但其对对象点类型的划分并无详细的规定，所以在操作中容易引起歧义，例如不同人员对视图的理解可能就存在歧义。
3．其他非标准评价法
除了上面的两种方法外，实际工作中还会使用到需求数量评价法、用例数评价法以及文档页码评价法等方法。
需求数量以项目需要完成的需求数量作为规模衡量的方法，但对于需求的粒度却从来就没有统一的规定，包括经常所提的模块数量、功能模块数量也属于需求数量衡量的范畴，它们共同的缺陷都在于缺乏统一的标准，甚至不如代码行方法的一致性。
用例（UseCase）是基于UML方法的一种定义软件需求的方式。
用例是软件工程或系统工程中对系统如何反映外界请求的描述，每个用例提供了一个或多个场景，该场景说明了系统如何同最终用户或其他系统交互，从而获得一个明确的业务目标。
通过用例描述的方式可以将软件系统所实现的功能进行抽象和总结，软件系统要实现的功能则表现为一组用例，所以可通过用例数量来描述软件项目的规模。
相对笼统的“需求”、“功能”等说法，用例具有较好的一致性。
UML语言对用例规范建立了用例模板，例如典型的用例应该包含如下内容：
用例名、迭代、综述、前置条件、触发器、基本事件流、备选路径、后置条件、业务规则、说明、作者和日期等。
如果能采用用例作为软件规模的衡量手段也不失为一种可取的方式。
但用例也存在粒度不一致的缺点，不同的用例可能相差很大。
对一个银行应用软件来说，描述用户管理的用例和住房贷款的用例可能会有很大的差别，从而缺乏横向比对的意义。
除此之外，用例对于客户往往缺乏说服力，尽管UML的倡导者声称用例是客户和技术人员沟通需求的最佳方式，但客户对用例描述的需求多数还是采用敬而远之的态度。
采用文档页码评价法的优点和不足也是显而易见的，页码最容易统计，但人们的书写习惯、逻辑表达能力、图形与文字的比例、甚至纸张的大小等因素都使得页码评价法很难成为合适的软件规模评价方法。
非标准评价法以其方便理解、易于操作的特点在实际工作中得到广泛应用，尽管存在不同程度的不一致缺陷，但聊胜于无。
无论如何，非标准评价法对于软件规模给出了一个明确的、用数字表示的数值，从而使得在此基础上讨论项目的工期、费用和质量目标等量化管理目标成为可能。
如果要尽可能减少项目干系人对于软件规模评价结果理解的歧义，则需要采用软件规模的标准评价方法——功能点方法。
1.2.2标准评价方法
上述各种非标准评价方法虽然在实际工作中也有着普遍的应用，但更多地局限于软件开发团队内部。
如果要在业务部门与开发部门、甲方与乙方等外部组织约定软件开发的工期或费用等关键项目目标，则首先需要对软件项目规模进行标准、一致的评价与估算。
目前的软件规模标准评价方法都同属一类方法，即功能点方法。
用功能点衡量软件项目规模类似于用平方米衡量房间的面积，或者用千克衡量体重，所以如果使用功能点方法衡量软件项目规模，则不同的人员对同一项目的软件功能可以得到一致的结果，从而克服软件规模非标准评价方法的不足。
从美国人Allan
J.
Albrecht在20世纪70年代末提出功能点方法以来，功能点在软件行业的应用与实践已超过30年，在Albrecht的功能点模型基础之上，经过进一步应用与发展，功能点标准演进为一个总标准（ISO14143）与5个子标准（MarkII标准、COSMIC标准、NESMA标准、FISMA标准以及IFPUG标准）。
1.3功能点标准
作为评价软件规模的标准方法，功能点度量方法（FunctionPointAnalysis）已经被纳入ISO14143标准系列。
就功能点方法的发展历程分析，目前被纳入ISO14143的5种实际操作方法都源自于Allan
Albrecht所提出的功能点分析思想。
当然，各种标准之间又存在一定的差异和共性。
为了保证这些功能点操作方法的一致性和客观性，ISO组织委托ISO/IECJTC1（信息技术）的SC7（软件与系统工程）委员会制定了ISO14143标准。
ISO14143标准本身又包含了6个子标准，各子标准的作用如下：
∙ISO14143-1：
概念定义（DefinitionofConcepts），对标准中所采用的术语给出解释。
∙ISO14143-2：
一致性评价（ConformityEvaluation），给出如何检验功能点操作标准是否符合ISO14143标准的评价过程。
∙ISO14143-3：
验证（Verification），在需要时对功能点操作标准进行验证。
∙ISO14143-4：
参考模型（ReferenceModel），给出功能度量方法模型以及需要度量的内容。
∙ISO14143-5：
应用领域确定（DeterminationofFunctionalDomains），确定功能点操作标准适用的应用领域。
∙ISO14143-6：
使用指南（GuidelineforUse），对功能点标准的应用提出建议和指导。
ISO14143给出了度量功能模型的标准，但在度量具体的软件功能时，使用者还应该考虑所度量的软件应用领域，从而选取合适的功能点度量方法。
所以从这个角度分析，ISO14143是关于功能点度量标准的标准。
在实际的软件规模度量实践中，目前符合ISO14143标准的功能点操作方法有5种，依次是MarkII标准、COSMIC标准、NESMA标准、FISMA标准以及IFPUG标准。
下面各节对这些操作标准的主要特点和操作方法进行简要说明。
1.4MarkII功能点标准
1991年，英国人CharlesSymons在自己的《SoftwareSizingandEstimating:
MkIIFunctionPointAnalysis》一书中介绍了MarkII功能点的操作方法。
Symnos先生在为毕马威咨询公司工作期间提出了MarkII功能点操作方法，在该操作方法的基础之上形成了MarkII功能点标准，该标准提出后被英国政府所采纳，目前该标准由英国软件行业协会维护。
MarkII功能点标准目前主要在英国应用，此外在印度等国家也有一定的应用。
正如Symons先生自己所言，该功能点标准受到Albreht先生的功能点操作方法启发，不过采用了不同的加权方式来定义功能点标准。
除了功能点的操作方法外，该标准还包含了功能点的应用建议，例如如何基于Mar
升级会员 