iwiz的博客

　　美国Forrester市场研究公司预言明年40％的公司计划提高网站改版的投入，增长速度超过整体IT投入比例。那么今年的节日季节中，许多公司的营销人员应该可以伴随着优异的线上营销成绩，欣慰之情安然进入温暖的梦乡了。

　　但是预算的实际分配是个复杂的问题。对于很多公司来说，过时陈旧的网站已经成为一种自身延续性的问题：如果网络渠道在过去的一年中表现不佳，那么公司又如何证明未来投入更多就是正确的决策呢？

　　在这种临界状态下，考虑投入应该是审慎的，并且能够带来“可量测性的回报”。基于这样的前提，如何才能在确定网站改版预算之前计算出未来ROI投资回报率成为越来越多的公司营销人员急切关注的问题。

　　为了分到节日季节利润的一杯羹，我们为营销人员总结出一套原则，指导帮助今年网站改版计划的实施。

　　模式一：分析数据

　　当然我们可以抱怨直到2006年到来前发生的一切，抱怨这一年中网上渠道未发挥出预期的超高水平。但是抱怨不会加快网站改版的进程。公司应该做的是了解网络的最佳优势，即能够反映出真实的数据。

　　首先从公司的整体营销预算开始，明年这部分预算很大程度上应该更多。仅这一因素就为网站带来许多迫切工作。当其他渠道投入预算增长时，网站的流量势必相应增大。原因很简单，宣传材料上提到了你的网站地址，所以如果公司以一个质量欠佳的网站欢迎这部分新的访问用户，分明就是在拿钱砸黑洞。

　　网站流量的某些基本分析数据将有助于网站主决定网站线上营销的预算。这些分析数据包括仅进入网站首页的访问流量，促使用户作出有价值行为（如实现购买，填写引导表格等等）的流量占总体流量的比例等。

　　当然，找出弱点仅完成了整体工作的一半。要计算出整体营销投资带来的增加回报，必须规划出合理的改进程度，这部分工作必须相当精确。可以有以下几种选择。一种是寻觅一家互连广告公司或数据统计方，如Forrester或Jupiter等。他们一般都有足够的数据论证分析站点的弱点，从而给出精确的有待完善的改进规划。

　　另一种就是在现有网站上运作一些一对一的测试。譬如，可以在网站的独立垂直域上放置一个交替页面，然后根据该页面的测试结果作为首要参考和指导目标，计算出网站的整体改进程度。网站改进的强有力的个案实例也可以作为业务规划的主要参考。

　　模式二：计算总数

　　调查IT规划中的下年投入可以作为一种工具，在尽可能满足每个人的最高期望的前提下，有效调整工作流。必备之一就是企业网站入口技术，使网站能够做到集中发布文档，设定雇员进入企业内部网及企业外联网的多级权限等。下一步就是内容管理软件，它们将使无技术用户也能更新网站内容。

　　因此，任何试图网站改版的公司都应该考虑增加相应的工作流工具。计算每个工具带来的ROI相对简单，它们的使用实际就意味着将替代公司以前的传统工作。如果工具的使用比人工更新增加六倍的效果，或者如果人力资源部门的雇员每年用400小时的时间寻找能够发布在企业内部网上的信息的话，那么节省下来的相关人员的总数就是组成企业个案的核心内容。

　　模式三：真实再现

　　对于吝啬鬼来说，三个幽灵的恐吓惊吓才能促使其打开钱袋；同样，对于最吝啬的公司预算负责人来说，只有8到10个实际网站访问用户才能促使其决定网站改版的预算。因此最好的办法就是让这些顽固不化的负责人亲自观看效果演示，让他们亲眼见证典型用户在网站上的全程操作，同时也让他们详细的了解到错误决定即将带来的损失。

　　从过去的经验来看，最为冷静或明智的做法是直接聆听来自用户的评论，但效果演示不仅仅是产生震动效果。如果由经验丰富的信息建筑师恰当地运作效果演示，从中得出的精确、有用的数据将说明哪些方面不能够产生效果，及如何改进这些弱点。

　　效果演示需要比模式一更多的前期投入，但是它也将产生更加深入的数据。一般而言，把网络营销预算的5％－10％用于用户测试通常会带来几倍以上的效果。

　　模式四：领航计划

　　有时候我们的新年解决方案其实涉及的目标过度长远，就像是下定决心要跑一场马拉松似的。实际上最好的方法应该是为网站制定一个较为近期的并且比较现实的目标。首先为网站做部分改版然后基于效果制定未来的全面改版个案，这一原则已经成为网络开发的一种趋势。

　　对于大多数企业网站，很大程度上应该能够遵守这一原则，而无须进行用户测试中断了改版进程。通常拥有一种旗舰产品的企业网站需要全部改版，或者为某个营销活动专门开发一个“微型站点”用于输出流量。对于后者，可以把微型站点的转换率效果与原始站点的相互比较，然后计算出改版带来的潜在收益。

　　因此，2005年或许是定相改版之年。网络作为营销中介正在逐渐成熟起来，这对于那些窥觑网络，以期使其成为业务营销主要阵地的公司来说这是个最好不过的消息了。那么最后祝愿所有的公司能够度过一个愉快的节日季节，并且拥有一个丰收的新年。（By Jennifer DeVoe，编译Lela）

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

　　作者Jennifer DeVoe是White Horse主要负责人，这是一家国内知名的网络战略专业服务提供商。White Horse的主要客户包括Nautilus， Cisco Systems，微软公司级Celestial Seasonings。DeVoe是互动营销方面的专家也是一位优秀的演讲人。

软件项目管理的实质就是软件项目计划的编制和软件项目计划的跟踪控制，这里计划是项目成功实施的指南和跟踪控制的依据，而跟踪控制又保证项目计划的成功执行。本文以实例具体分析在软件开发过程中如何进行这两项

工作。

在软件项目中有两条非常重要的线索，一条是软件项目开发过程，另外一条是软件项目管理过程。通常，人们容易注意软件项目开发过程，而忽略软件项目管理过程的线索。事实上，后者很重要，有时其重要性甚至超过项目开发过程。项目管理可以让一个项目获得高额的盈利也可以让一个项目损失惨重，而编码的影响力则相对小一些。现实中由于出色的项目管理，将已经亏损很严重的项目又重新扭亏为盈的例子并不少见。

项目管理在生活中的例子很多。例如进行一次商品采购，你会在一张纸上记录所有需要购买的东西（即采购清单），这个采购清单帮助你不要遗漏采购项，你可以采用“完成一个采购项，在采购清单上打一个勾”的方法协助你完成采购。与此类似，软件项目管理也是如何管理好软件项目的内容、花费的时间（进度）以及花费的代价（规模成本）。为此需要制定一个好的项目计划，然后控制好这个计划。编制软件项目计划、跟踪控制软件项目计划这就是软件项目管理的实质。其中，计划是项目成功实施的指南和跟踪控制的依据，而跟踪控制是项目计划成功执行的保证。

确定软件项目开发的策略

项目经理的首要任务是编制项目计划。项目计划有三大核心目标: 确定项目范围、项目预算、项目进度，即明确项目做什么、花多少钱、需要多长时间。为了制定一个合理有效的计划，项目经理需要从项目需求开始确定项目范围，然后将项目的需求进行分解，以便于估算、安排资源和合理的进度等。这样就形成了三个核心计划: 范围计划、成本计划和进度计划。此外，作为完整的项目计划，质量计划、风险计划、沟通计划等同样也必不可少。没有质量管理的项目是失败的项目，没有风险管理的项目会时时处于风险之中，没有沟通的项目是很难完成的。项目规划从合同阶段就开始了，其实任何一个合同的主要内容也是确定项目的范围、时间和成本。

软件项目最终的结果是根据用户的需求提交一个用户满意的产品，这是一个从无到有的过程。因此计划首先应该确定项目开发的策略，即项目的生存期模型。瀑布、Ｖ、原型、螺旋、渐进式阶段提交等模型是几种常见的生存期模型，渐进式阶段提交模型体现了软件项目渐进性的特点，同时，分阶段提交项目结果，也有利于软件项目开发。RUP（Rational的统一过程）提及的软件项目生存期模型就是一种渐进式阶段提交模型。图1的模型是笔者曾经参与的一个银行业务系统的生存期模型，它是渐进阶段提交的模型。

图1 某银行业务系统渐进式阶段提交模型

如果项目周期不是很长，可以不分阶段提交结果，而只是分阶段开发，这样渐进式阶段提交模型就演化为增量模型。例如笔者曾完成的一个《校务通管理平台信息系统》项目，它是对学校教务和教学活动进行综合管理的平台系统。尽管分阶段实施项目是比较理想的项目管理模型，但是由于这个项目不大，没有必要分阶段提交一个执行系统，所以采用增量的模型。

生存期模型中可以定义软件开发中采用的过程、程序，如果过程定义得很明确，或者过程定义的操作性很强，那么作为工厂化的软件开发就会很顺利，项目管理的过程也会很顺利，所以在软件项目中的这两条线索也是相辅相成的。

制定项目核心计划

项目的核心计划是范围、时间、成本的确定，这三方面并不是截然分开的，而在项目计划的制定过程中相互交织。

确定项目范围要从需求入手，将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。目的是为了提高估算（成本、时间和资源）的准确性，使工作变得更易操作，责任分工更加明确。任务分解的结果是WBS (Work Breakdown Structure)。只有在WBS中的工作才属于该项目的工作范围。

任务分解之后，可以根据分解的结果，估算任务的规模、成本，同时可以根据分解的结果进一步分解详细的项目活动，以便安排任务之间的关联关系，估算每个任务的工期，然后进一步估算项目总的工期。

项目的规模和进度估算有一定的关系。进度估算是从时间的角度对项目进行规划，而成本估算则是从费用的角度对项目进行规划。类比估算法、参数模型估算法、自下而上估算法等都是规模成本估算的方法，而经验导出模型、工程评价技术（PERT，Program Evaluation and Review Technique）、关键路径法（CPM，Critical Path Method）等都是进度估算的方法。在项目的进行过程中，可能要不断重复进行估算，以减少估算的误差。在项目的不同阶段可以采用不同的估算方法，开始可能很粗糙，随着项目的进展会逐步精确。

在安排项目进度的时候，可以根据WBS的分解情况，继续分解相应的活动（任务），分析确定各个活动之间的顺序关系，画出任务的网络图(例如PDM网络图或者ADM网络图)。图中的每一项任务必须有一个前驱和后继，除了项目中的第一项和最后一项任务。确定关键路径在哪里、哪些任务还有变化，然后结合资源、成本等情况，再不断进行资源调整优化以及工期、活动关系的调整等。计划调整的过程虽然很费时费力，但也是一个关键的过程，要经过多次调整、修改、评审讨论等，最后才能确定一个计划，将此计划存为基准计划。这个基准计划可以存入项目管理系统中，例如MS Project。

通过这个基准计划可以确定项目的范围即项目所有的任务，还可以确定项目的时间进度表，这个计划也确定了各个任务的资源（人力资源、物力资源等），当然项目的成本就可以确定下来。

仍以《校务通管理平台信息系统》为例，根据项目WBS的分解情况，继续分解相应的活动（任务），然后确定各个活动之间的关系，系统的功能采用增量方式实现，实施阶段分6个增量，对各个任务（活动）分配相应的资源，经过多次的活动调整以缩短工期，多次的资源调配以解决资源冲突和减少成本，最终形成了基准计划，如图2所示。

图2 《校务通管理平台信息系统》基准计划(点击小图看大图)

制定辅助计划

1. 质量保证计划

质量保证的主要活动包括过程评审和产品审计。过程评审和产品审计的目的是为了确保在项目进展过程的各个阶段和各个方面采取各项措施来保证和提高产品质量。

产品审计 产品审计由质量保证人员来进行，检查项目产品是否达到质量目标。质量保证人员对项目生存期中创建的工作产品可以有选择性地进行审计，以验证是否符合适当的标准，是否进行了质量检查。

过程评审 过程评审是检查项目是否严格按照组织定义的软件过程进行开发，过程评审的具体依据可以参照企业的过程规范，以保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确地决策并形成评审记录。评审可采取文件传阅、评审会等形式。

这里质量保证人员负责对项目过程进行监督，发现的问题和解决情况在每周的例会上通报，对没有解决的问题进行讨论，对不能解决的问题提交高级管理者处理。

要注意的事，项目的质量活动包括质量保证和质量控制，质量保证是一种管理职能、质量控制是一种检查职能，质量保证是确定项目完成的是否正确，质量控制是确定项目是否正确地在进行。有时将质量控制归类到开发活动中，质量控制活动更多由开发人员完成。

2. 配置管理计划

软件配置管理贯穿于软件生存期的全过程，目的是用于建立和维护软件产品的完整性和可追朔性。软件配置管理是一组追踪和控制活动，软件配置管理可以管理好项目进行的中间产品以及它们之间的关系。配置管理计划中包括很多的内容，例如配置管理工具、配置项计划、基线计划、配置管理规程等。

3. 沟通计划

为了保证项目开发过程的顺利进行和信息的有效沟通，从而使一些重要的项目信息实时、最新、及时获取，做到实时同步，就必须有一个灵活而且容易使用的沟通方法和沟通计划。

4. 风险管理计划

任何项目都有一定的不确定性，如果没有很好的风险管理，项目就可能遇到麻烦。所以，软件项目管理过程中，风险计划同样必不可少。风险管理中常用的工具是TOP10风险清单，它是通过一系列的风险识别、风险评估、风险规划得到的。表2是《校务通管理平台信息系统》项目的TOP 10风险列表。

项目计划的跟踪控制

如同采购时，你通过采购单（在其上打勾）保证采购的顺利进行; 在聚会演出时，你通过节目清单（你的计划）来控制节目的顺利进行等。同样，软件项目管理也需要跟踪控制，跟踪控制就是为了保证项目能够按照预先制定的计划进行，使项目不要偏离预定的发展进程。

跟踪控制的对象就是项目计划。在项目进展过程中，项目经理根据项目计划来及时跟踪项目实际的执行情况，关注项目的范围、成本、进度、质量、风险等情况，记录实际的进展情况，对照计划与实际的情况，发现问题并及时解决。进行项目跟踪控制的基本步骤如下:

（1） 建立标准，即建立项目正确完成应该达到的目标;

（2） 建立项目监控和报告体系，确定控制项目必要的数据;

（3） 测量和分析结果，将项目的实际结果与计划进行比较;

（4） 采取必要措施，如果实际的结果同计划有误差时，采取必要的纠正措施，必要时修改项目计划;

（5） 控制反馈，如果修正计划，应该通知有关人员和部门。

软件项目经理要确定如何获取项目的时间、成本、范围的进展信息等（例如计划中可以规定跟踪频率和步骤，设置专门人员负责收集项目数据或者项目人员按照规定的度量标准统计上报项目数据）。然后将项目的实际结果与计划进行比较，采用一定的方法分析项目的进展情况，如偏差分析和挣值分析等。

表1 校务通平台软件生存期中各阶段的定义(点击小图看大图)

项目跟踪分析应该根据计划的要求实时进行，要随时了解项目的进展情况，以便做出正确的决定。另外，还要跟踪其他计划的执行情况，特别要关注风险管理计划，项目经理应该定期回顾和维护风险计划，及时更新风险清单，对风险进行重新排序，并更新风险的解决情况，这些活动应该包含在项目计划中，以防遗忘。只有这样才能使项目经理们经常思考这些风险，居安思危，对风险的严重程度保持警惕。

项目管理一个非常重要的手段是进行项目评审。项目评审的主要目的是根据项目计划对项目的执行活动进行检查，及时进行沟通，发现问题，研究解决对策，纠正偏差，保证项目的顺利实施。评审可以针对产品的评审，例如设计评审，或者针对质量的评审，例如质量过程评审，但更多的是针对管理的评审，例如定期的周例会等，以及针对突发事情的评审等。

项目的最后一项是进行项目总结，这是一项必要的工作。就如同我们聚会活动结束之后，要核算或者说总结，节目单的活动执行的如何？费用如何？时间如何？同样，作为项目管理的最后一件事情也是总结，即最后评审，总结经验教训，编写项目总结报告等，为以后的项目提供参考。

链接一:软件项目管理的相关研究成果

美国专门从事跟踪IT项目成功或失败的权威机构Standish Group在它每年的CHAOS Report报告中给出了IT项目相关调查数据结果。根据1999年Standish Group对当年美国项目的统计数字表明，只有26%的项目是真正成功的， 28%的项目是彻底失败的（即中途夭折的项目），介于两者之间是完成了的、但“受到质疑的”项目占46%，这些项目被定义为存在费用超支、超出工期的项目。这些存在问题的或是失败的项目带来的直接损失是970亿美元，占了美国当年全部的IT投资（2550亿美元，17.5万个项目左右）的近40%，而由于这些项目所带来的间接损失是无法估量的。

Standish Group 2003年公布的调查数据中，在被调查的1.35万个项目中，绝对成功的项目比例大大低于50%，仅为34%。彻底失败的项目为15%。受到质疑的项目占所有IT项目的51%。通过对Standish Group自1994年以来发布的一系列项目调查数据进行了汇总，可以看到三个现象:

1. 项目的成功率在提高、失败率在下降。这显示出随着时间的推移，被调查企业项目管理能力在上升。例如从1994年和2004年的数据看，取消项目的比例从31%下降到23%; 超期项目从189%下降到45%; 超预算项目从222%下降到63%。

2. 从总体上看，目前项目的成功率仍低至34%。

3.有疑问项目的比例保持基本不变，而且占据了被调查项目总数的一半左右。

另外，从历年的Standish Group报告分析看，导致项目失败的最重要原因与需求有关。Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目的变更。

链接二:软件项目计划与实际进展的比较方法

一般来讲主要有两种方法: 一个是偏差分析，相当于简单的减法。在项目的某一点，计划值与实际值相减，这个计划值和实际值包括范围、时间、成本等，判断其中的差值是否超出可以接受的范围; 另一个是挣值分析，相当于加权的减法。在项目的某一点，计划值与实际值不是简单的相减，而是进一步分析实际完成的任务与成本和时间的关系，以判断项目进展如何。

偏差分析是将实际费用和计划费用简单相减，在下图中就是当前日期的实际费用（ACWP）和计划费用（BCWS）相减。而挣值分析是进一步分析实际完成工作的情况，如下图，尽管当前的实际费用（ACWP）比计划费用（BCWS）花费得多，但是当前实际完成工作量比计划多，这时就引入一个挣值的概念，即实际完成工作量的价值（BCWP，已完成工作的预算成本，又称已获取价值）。挣值分析的输入如下:

项目计划与项目实际进展的比较

BCWS (Budgeted Cost of Work Scheduled)计划完成工作的预算成本: 是到目前为止的总预算成本。它表示“到目前为止原来计划成本是多少”或者说“到该日期为止本应该完成的工作是多少”，它是根据项目计划计算出来的。

ACWP (Actual Cost of Work Performed)已完成工作的实际成本: 是到目前为止所完成工作的实际成本，它说明了“到该日期为止实际花了多少钱”，可以由项目组统计。

BCWP (Budgeted Cost of Work Performed)已完成工作的预算成本，又称已获取价值，是到目前为止已经完成的工作的原来预算成本，它表示了“到该日期为止完成了多少工作？”

BAC（Budgeted At Completion）工作完成的预算成本: 是项目计划中的成本估算结果。是项目完成的预计总成本。

理想状态下BCWP、BCWS、ACWP三条曲线可以重合。

挣值分析过程如下:

1. 进度差异:SV(Schedule Variance)=BCWP-BCWS。若此值为零，表示按照进度进行; 如果为负值，表示项目进度落后; 如果为正值，表示进度超前。

2.费用差异:CV(Cost Variance)=BCWP-ACWP。若此值为零，表示按照预算进行; 如果为负值，表示项目超出预算; 如果为正值，表示低于预算。

3.进度效能指标: SPI(Schedule Performance Index)=BCWP/BCWS。表示完成任务的百分比。若此值为1，表示按照进度进行，如果小于1，表示项目进度落后，如果大于1，表示超进度进行。

4.成本效能指标: CPI(Cost Performance Index)=BCWP/ACWP。表示花钱的速度。若此值为1，表示按照预算进行; 如果小于1，表示项目超出预算; 如果大于1，表示低于预算。研究表明: 项目进展到20%左右，CPI应该趋于稳定的，如果这时CPI值不理想的话，应该采取措施，否则这个值会一直持续下去的。

5.项目完成的预测成本: EAC（Estimate At Completion ）=BAC/CPI。

6.项目完成的成本差异VAC（Variance At Completion）=BAC-EAC。

7.项目完成的预测时间: SAC(Schedule At Completion )=完成时的进度计划/SPI。

对软件开发的各个阶段进行管理，增强对软件开发的控制能力，提高软件开发质量，这是软件项目管理的根本目的。

软件的质量高低取决于其是否符合包括功能性、可靠性、易用性、效率、可维护性、可移植性等

在内的六个方面的要求。而要达到这六个方面质量要求，就必须对软件开发过程中各个环节进行全过程的项目管理，从需求分析、设计、编码、测试到上线验收进行控制。根据软件工程的生命周期，软件项目可分为项目立项、启动、需求分析、系统设计、系统开发、系统测试、系统上线、项目验收和上线后评估等9个阶段进行。加强软件项目管理，就是以软件工程的各个环节为管理主线，将动态项目管理贯穿其中，通过对软件开发的项目范围、项目进度、项目质量、项目沟通、人力资源、项目成本六大核心要素的集成管理，实现软件开发管理效能的最大化，从而大大提高软件的开发质量。

准确把握软件需求

软件开发项目的提出，应由迫切的业务需求来驱动。很多不成功的软件项目，往往是由信息技术部门提出，按照技术人员的思路主导开发，并理所当然地被认为能够在业务部门取得良好的应用效果。这样的项目由于得不到业务部门的理解和支持，脱离业务需求，多数面临失败或半途而废的命运。因此软件项目业务需求的迫切性、技术实现的成熟性、经济效益的可行性等方面的因素，都是考虑的要素，将对项目的成败产生直接影响。

正确的做法应该是，由软件的需求单位根据自身业务需要，向信息技术管理部门提出软件项目的立项建议，对立项的目的、业务需求范围、技术经济指标、开发周期要求等方面做简要概述，再由信息技术管理部门组织业务专家和信息技术专家组成联合专家组，进行项目立项的可行性论证。通过专家组论证审核后，项目提出单位需要进行开题设计，进一步明确软件开发范围、技术路线、进度安排、经费预算、研究人员组成、合作队伍，并以此为基础编制完成开题设计书。信息技术管理部门组织专家组对开题设计进行论证，只有业务需求合理、技术路线可行、开发队伍落实的项目，才能通过专家组审核，进入项目启动阶段。

软件开发过程的监督和管理

软件开发项目具有建设范围难界定、技术含量高、人员流动快、协作性强、开发成功率低等特点。目前国内对软件项目的监理制度尚不规范，对软件开发仍然缺乏有效控制。因此由企业的信息技术管理部门设立软件监督岗位，加强对软件项目的开发过程管理，就显得非常必要。

软件监督的主要职责是在项目的进行过程中，协调业务需求部门和软件开发方的关系，监控软件开发任务的执行情况，给开发人员和管理层提供反映软件过程质量的信息和数据，提高项目透明度，从而保证项目按照计划实施，实现预期目标。软件监督应具备以下三方面的基本素质:

● 具有较强的工作责任感和良好的沟通能力;

● 熟悉业务管理流程，掌握软件开发流程、开发规范以及相关标准;

● 具有软件开发项目的建设和管理经验，掌握项目管理知识;

软件监督的工作任务主要有:

● 确保软件按照业务需求方确认的范围进行开发。

● 保证软件开发进度符合双方确认的计划指标。

● 保证软件开发过程中存在的不符合要求的问题能够及时得到沟通和处理，必要时需要将问题反映给管理层。

● 确保项目组中软件开发人员队伍相对稳定。

● 保证软件开发过程和开发出来的软件符合相应标准和规范。

● 收集软件开发过程中的成功经验，为企业提供软件开发过程的有效控制方法和规范。

1.监督管理的范围

《需求分析说明书》是对软件开发范围的书面表达依据。由于《需求分析说明书》往往是采用软件设计的术语编写，因此常常令计算机背景知识较少的业务需求方难以理解，也就很难发现需求报告中与实际需求不符之处，更难提出建设性的意见。

软件监督要对软件开发范围进行管理，首先要确定双方都能认可的《需求分析说明书》。如要求软件开发方对《需求分析说明书》做出进一步更详细的解释，编制业务模型，以便用户方准确地理解《需求分析说明书》的内容，能及早地发现需求与实际的偏差。这也是对需求分析工作的总结与确认。

在项目需求分析阶段，双方必须全面地、尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。

《需求分析说明书》完成后，软件监督应组织项目组与业务需求方共同讨论，听取业务需求方的意见和建议，并进行相应的修改完善。各方确认《需求分析说明书》内容后，需在说明书上签字确认。

在软件开发过程中，双方应严格按照签字确认的《需求分析说明书》中规定的业务范围进行开发。有些需求可能在项目初期很难确定，在开发过程中需要不断地加以修正，项目软件监督要及时与用户充分沟通，建立可以直接联系的渠道，共同进行需求确认，保证项目范围可控。

2.进度管理

为确保项目按时、按量、保质完成，必须控制任务和跟踪里程碑。按照软件项目的开发规律，将软件开发过程分为几个重要阶段，对这几个阶段的关键事件设立里程碑进行跟踪管理。项目进度管理可以通过以下方式完成:

● 制定项目里程碑管理运行表（里程碑管理表的主要内容见表1）。

表 项目里程碑管理运行表(点击小图看大图)

● 定期举行项目状态会议，由软件开发方报告进度和问题，用户方提出意见。

● 比较各项任务的实际开始日期与计划开始日期是否吻合。

● 确定正式的项目里程碑是否在预期完成。

从软件项目实施的过程来看，很少有一个项目是完全按照实施计划来进行的，因为再好的计划也不能完全预见所有的问题，并事先制订出对策。计划可以调整，但是调整必须合理，并得到业务需求方和管理层的批准。当有问题发生时，其直接的表现就是实施结果偏离了原来的计划和目标，在这种情况下，软件监督就要及时发现这种偏离，并分析这种原因，如果是因为原来的计划和目标制订的不合理，或者发生了预料之外的情况而又无法克服，这样就必须调整计划和目标。

3.沟通管理

信息系统本身就是沟通的产物。软件开发过程实际上就是将手工作业转化成计算机程序的过程。软件开发的原料和产品就是信息，中间过程传递的也是信息，而信息的产生、收集、传播、保存正是沟通管理的内容。可见沟通不仅仅是软件项目管理的必要手段，更重要的，沟通是软件生产的手段和生产过程中必不可少的工序。

软件开发的柔性标准需要沟通来弥补。软件开发不像加工螺钉、螺母，有具体的标准和检验方法。软件的标准柔性很大，比如在用户的心里好用是软件成功的标准，而这个标准在软件开发前很难确切地、完整地表达出来。因此，开发过程项目组和用户的沟通互动是解决这一现实问题的惟一办法。

软件监督要有效地安排开发方软件人员与需求方使用人员的交流，保证有畅通的交流渠道。制定完善的项目汇报制度，明确沟通时间、频率和渠道。按照项目汇报制度定期组织项目组向业务需求方和管理层汇报，包括项目进度计划、已完成工作、与计划的比较、存在的问题、措施和建议以及下一步工作计划等。

4.软件版本管理

目前的软件开发是团队开发的时代，软件开发技术更新迅速，开发人员流动频繁，因此对软件版本的管理就显得尤其重要。在软件开发的过程中，在多人共同开发一个软件时，会出现多人同时修改软件的情况，这是不可避免的，由于部分功能模块版本可能要进行不断地升级完善，而老的软件版本又没有即使更新，随着时间的推移，开发人员对自己机器上的不同版本间的差异就会模糊不清。另外由于软件开发工期的压力，开发人员只将注意力集中在设计和编码上，未将文档纳入到版本控制中。为了解决这些问题，软件监督就要注意跟踪记录整个软件的开发过程，包括软件本身及其相关文档，重视代码的一致性。这一工作可以通过应用软件版本管理的工具软件实现，如Microsoft公司的Visual SourceSafe等对源代码和整个项目进行管理，从而建立正常的软件版本管理机制，

把握正确的验收方法

软件项目验收是对软件项目成果的检验和确认，也是对软件项目范围的再确认。软件验收应是一个过程的概念，包括验收前的系统测试、数据移植、系统上线和正式验收四个阶段。

1.系统测试

系统测试是对系统进行全面的测试，应在测试环境中进行，以确保系统的功能和技术设计满足企业的业务需求，并能正常运行。系统测试阶段应包括以下主要流程和工作内容:

（1）制订测试计划，包括编制测试用例，建立测试环境。

（2）测试。在测试环境中，项目组根据需要，对系统依次进行单元测试、集成测试、压力测试和用户接受测试，记录测试结果并由相关测试人签字确认，编制相应的测试报告。对于未通过测试的内容，项目组应查找失败的原因，并修改相应程序或设置，重新进行测试。除了进行充分的系统功能测试，测试应包含与内部控制相关的测试内容，如系统认证和授权、交易完整性及数据真实、完整性的有关功能。

（3）提交测试报告、用户确认签字。项目组撰写测试报告，将测试报告提交给各相关用户，用户应在测试报告上签字确认。

2.数据移植

新系统上线时如需要将原始数据移植到新系统，则应完成以下主要工作内容:

（1）制订数据移植/转换计划。除了要定义数据收集的格式、范围、进度外，还要考虑系统接口的影响，并建立了数据移植完整性和准确性测试方法以及意外事件处理程序。

（2）数据收集。如果项目实施涉及到数据收集，应由数据收集小组根据数据收集格式，对数据进行收集，数据收集小组在收集数据时应培训业务部门的数据提供人员，以确保数据提供人员了解和掌握对数据收集的各项规定和要求。

（3）数据移植前的测试。在测试环境中对数据移植方法进行测试，书面记录测试结果，解决测试中发现的问题，进行问题记录并归档。

（4）数据导入并核查结果。

项目组成员将数据导入系统，并在导入后按照事先制定的数据移植完整性和准确性测试方法对系统中的数据做进一步的核查，确保导入数据的质量。如有意外，按照事先制定的意外事件处理程序处理，并留下记录。数据移植完成之后，用户应对数据移植结果签字确认。

（5） 数据移植后要进行适当时间的试运行，确认数据移植的真实性和完整性。试运行时间视具体系统的规模、影响程度而定。对影响较大的系统，至少应试运行三个完整的月结周期。

3.系统上线

系统上线阶段应包括以下的主要流程和工作内容:

（1） 上线前准备工作。在上线前，软件开发方应制定系统上线计划，包括上线检查清单、上线支持人员、退回机制等，并提交《上线申请表》。系统上线计划和《上线申请表》应经过信息技术部门和业务部门管理层的正式批准，并通知各相关部门。

（2）系统上线。所有的上线准备工作做好之后，由软件监督人员确认上线系统版本正确性后，与用户确认系统上线时间，下达上线指令。系统上线操作人员将最后版本的系统程序移植到生产环境。

刘剑 中国石油新疆油田公司科技信息处软件工程师，连续多年参与编制新疆油田公司信息化建设项目计划。

4.正式验收

正式验收前，软件开发方应向信息技术管理部门提交软件开发过程中各阶段性文档，包括需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、源程序代码、可供安装使用的系统安装程序、系统管理员手册、用户使用手册、测试计划、测试报告、用户报告、数据移植计划及报告、系统上线计划及报告、用户意见书、验收申请等。

信息技术管理部门接到验收申请后，组织专家对项目进行初审。初审通过后，组织管理层领导、业务管理人员和信息技术专家成立项目验收委员会，负责对软件项目进行正式验收。

软件监督应根据软件开发方在整个软件开发过程中的表现，向验收委员会提出全面的软件监督报告，并根据开题设计书、软件开发合同以及《需求分析说明书》，制定验收标准，提交验收委员会。信息技术管理部门组织由验收委员会、软件监督、软件开发方参加的项目验收会，软件开发方以项目汇报、现场应用演示等方式汇报项目完成情况，验收委员会根据验收标准对项目进行评审，形成最终验收意见。

链接:软件质量的六个考核要素

1. 功能性: 满足用户的要求，在预定环境下能够完成预期的功能。

2. 易用性: 用户容易理解和使用功能，操作方便，符合用户业务习惯。

3. 可靠性: 软件按照设计要求，在规定时间和条件下不出故障，具有异常捕获功能并提供异常处理与恢复功能。

4. 效率: 降低系统资源的开销，响应时间快，提高用户工作效率。

5. 可维护性: 遵从统一的标准和规范，编码具有良好的可读性。为满足用户新的要求，或当环境发生了变化，或运行中发现了新的错误时，能够对一个已投入运行的软件进行相应诊断和修改。

6. 可移植性: 一个软件（或软件的部分功能模块）能再次用于其他相关联的应用。