软件项目管理大作业20111632郑雯

在线书店管理系统软件项目管理方案学号：20111632班级：计软111班姓名：郑雯指导教师：韦灵完成时间：2014年6月20日TOC\o"1-2"\h\u120521需求管理 页1需求管理需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性。1.1需求管理的内容1.1.1需求管理的特定实践需求管理包含5个特定实践，如图1所示。5.标识项目工作与需求的不一致性1.获得对需求的理解5.标识项目工作与需求的不一致性1.获得对需求的理解需求管理需求管理4.维护对需求的双向可追溯性3.管理需求变更2.获取对需求的承诺4.维护对需求的双向可追溯性3.管理需求变更2.获取对需求的承诺双向溯源矩阵双向溯源矩阵 图1:需求实践示意图①获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。②获取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。③管理需求变更。维护变更历史，为调整与控制提供数据。④在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。⑤标识项目工作(包括计划和产品)与需求的不一致性。若发现不一致性，即启动纠正措施。1.1.2需求管理的管理流程上述5个特定实践，可归结为以下3项活动，即需求确认、需求跟踪和需求变更。(1)需求确认包括图1中第1、2两个特定实践。由开发方和客户共同对主要需求文档“软件需求规格说明书”进行评审，双方达成共识后作出书面承诺，使需求文档具有商业合同效力。由此可见，需求确认实际上包含了两个重要工作：需求评审和需求承诺。其中需求承诺是双方对通过正式评审后的“软件需求规格说明书”作出的共同承诺。承诺书的格式如下：本“软件需求规格说明书”是建立在双方对需求的共同理解基础之上的，我们同意后续的开发工作根据该“软件需求规格说明书”进行。如果需求发生变化，我们将按照“需求变更流程”执行，即需求的变更将导致双方重新协商成本、[[资源]]和进度等。项目经理签字:[[客户]]或客户代表签字:该承诺书将附在“软件需求规格说明书”后，一同存档保存。(2)需求跟踪包括图1的第4、5两个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。为了有效地检验最终软件产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的，是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、编码以及测试案例，从而验证该软件产品是否实现了所有需求，是否对所有需求进行过测试。1.2需求变更控制需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大的风险。1.2.1需求变更的利弊随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。如果动不动就变更需求，某些项目也许永远不能按时完成。为此，需求变更必须遵守利大于弊的原则，并做到：①为避免出现失控等风险，对纳入基线以前的需求文档，可通过正常的check—in和check—out进行更改。而纳入基线以后的需求文档，更需按照预定的变更控制规程，确保快速、顺利和有序地进行变更。②遵照如图2所示的需求变更流程来处理。下文将具体介绍这一流程。开始开始需求变更申请书提交变更申请书需求变更申请书提交变更申请书需求分析说明书书面化变更需求需求分析说明书书面化变更需求<<项目估算表>>评估需要变更的影响<<项目估算表>>评估需要变更的影响<<项目计划书>><<项目进度表>>变更审批<<项目计划书>><<项目进度表>>变更审批审批通过?审批通过?F根据变更修改相关工作产品T根据变更修改相关工作产品变更验证变更验证需求评审结束需求评审结束图2:需求变更流程1.2.2需求变更的流程需求变更通常按变更申请一审批一更改一重新确认的流程进行。(1)变更申请此时的状态为“请求变更”。首先由申请人提交需求变更申请书，其内容应该包括：①变更源类型。指引起变更的原因类型，可分为需求变更、设计变更、代码优化、用户文档优化和计划变更等。②变更优先级。依据变更的重要性、紧迫性和对关键业务的影响程度和对系统安全性和稳定性的影响程度，可分为critical、high、middle和low等4级。③变更标志。分为新增、修改和删除。④变更影响分析。包括变更影响的工作产品和负责人，对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。⑤可能影响的工作产品。包括项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例以及用户文档。上述申请书应由项目经理进行评估，其内容包括：①该需求变更在技术上是否可行。②对工期、成本、质量的影响。首先评估单个模块工期的影响，即实现该需求变更需要的成本和工作量；然后评估实现该需求变更对整体工期工作量和成本的影响。(2)变更审批按照影响的大小由不同的负责人审批。①对影响小的变更，由项目经理直接审批。②对影响大的变更，提交软件变更控制委员会(SottwareChangeControlBoard，SCCB)审批。③项目SCCB仍无法决定的变更，再提交高层SCCB决定。所谓影响大的变更一般包括下列情况：①变更影响的模块数超过10个或超过50％，或者可能影响软件系统的框架。②变更会影响对客户的承诺。③变更会带来“高”或者“高中”程度的风险。如果审批请求未通过，则该变更请求结束。(3)变更修改如果需求变更已审批通过，应指定相关的责任人对产品进行修改，并指定人员对更改后的产品进行审核。还应在产品列表中记录具体修改的产品名称、修改描述和是否完成修改的状态。包括：1.应及时更新相应的需求大纲和需求分析说明。2.如果影响项目计划的内容，修改项目计划，以反映需求的变更。3.如果影响到概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例或者用户文档，它们也需要被及时更新。4.如果影响到测试，还需要进行回归测试。5.如果对文档进行修改，需在修改历史表格中注明修改人、修改时间以及修改原因。6.如果对原文件修改过大，必要时项目经理可以重新组织工作产品的评审。7.如果对代码进行修改，需要导出编译申请表，通知编译和测试。(4)变更关闭如果修改后不需要进行测试，则当所有产品全部修改完成时，由最后完成修改的人关闭该变更。如果变更修改后提交测试，则由测试人员负责该变更是否最后关闭：1.如果测试未通过，则返回修改者继续修改。2.如果所有工作产品全部修改完成，并且测试通过，关闭该变更。图3为需求变更的状态转换图，从中可看到各种需求变更状态的转换。新增变更请求新增变更请求PMPM接受变更接受变更拒绝变更拒绝变更变更变更关闭图3:需求变更状态转换图1.2.3需求变更的数据项为了确切记录需求变化，还需登记如表1所示的变更数据列表。数据项名称定义项目名称和ID变更所在项目的名称和ID变更阶段需求阶段，设计阶段，编码，测试和验收阶段。不同阶段的需求变更请求对整个项目开发的影响也不同变更优先级每个变更的相对重要性变更标志变更的状态变更原因描述简单描述提出变更的原因变更内容描述对变更的内容进行简单描述相关的变更请求是否有相关的变更请求，如果有，指定相关的变更请求变更的状态信息包括变更请求人，更变批准人，当前负责人，变更关闭人，请求日期，审批日期，期望解决日期以及关闭日期变更影响分析基于影响工作产品对变更的影响进行分析变更处理分析所影响的工作产品列表以及各工作产品对变更的处理状态表11.3需求管理工具在软件规模很小的时候，人们采用文档文件的方式来存储软件需求规格说明书和其他文档。在一些小规模的软件系统开发中，人们也还这样做。但是，随着各种计算机应用系统越来越复杂，软件规模也越来越庞大。这时传统的基于文档文件存储需求的方式越来越显露出它的局限性，主要体现在：1.手工维护大量文档文件十分困难。2.很难保持文档与现实的一致。3.通知受变更影响的设计人员是手工过程。4.不太容易做到为每一个需求保存附加的信息。5.很难在功能需求与相应的用例、设计、代码、测试和项目任务之间建立联系链。6.很难跟踪每个需求的状态。7.异地协作开发变得很困难。随着软件工程技术的发展，需求管理的任务越来越繁重，迫切需要研制需求管理工具来自动化地管理需求，提高工作效率。IBMRationalRequisitePro、TelelogicDOORSreg和BorlandCaliberRM等都是目前比较流行的需求管理工具，可以帮助开发团队有效地管理软件需求。1.4需求规格1.4.1功能需求该系统是典型的网上购物实践中最为普遍的电子商务企业对客户（B2C）模式，主要包括会员注册、订单管理、购物车、搜索、支付等基本功能。此外，本系统也将实现在线图书销售系统的后端管理，包括图书的添加、订单的处理等功能。本系统完全基于JSP技术，在系统的设计与开发过程中严格遵守软件工程的规范，运用软件设计模式，从而减少系统模块间的偶合，力求做到系统的稳定性、可重用性和可扩充性。该系统的主要功能如下：（1）前台（客户购买）部分：1.用户管理：注册会员、登录、激活、退出、修改密码；2.分类显示：显示所有1级和2级分类；3.图书显示：按分类查询图书、通过关键字搜索图书、高级搜索图书、查看某本图书的详细等；4.购物车管理：向购物车中添加图书、修改购物车中图书数量、删除购物车中图书、我的购物车；5.订单管理：通过购物车中图书生成订单、查看我的订单、查看某个订单的详细、订单支付、确认收货、取消未付款订单。（2）后台（管理员管理）部分：1.管理员：管理员登录；2.分类管理：查看所有分类、添加1级分类、添加2级分类、修改1级分类、修改2级分类、删除1级分类、删除2级分类；3.图书管理：按分类搜索图书、高级搜索图书、添加新图书、查看图书详细信息、编辑图书、删除图书；4.订单管理：按状态搜索订单、查看订单详细信息、取消订单、发货；1.4.2数据库分析系统的主要任务是通过大量数据获得管理所需要的信息，这就要求系统本身能够存储和管理大量的数据，而这一功能的实现必须借助大型数据库系统。本系统的开发选择MySQL作为后台数据库开发工具。在线书店管理系统的E-R模型如下图所示：管理图书分类购物车管理图书分类购物车1n管理属于n1管理属于用户管理员管理求购图书1n用户管理员管理求购图书1nn1生成管理订单11生成管理订单nn1.4.3系统开发平台与运行环境系统的开发是在Tomcat环境下进行的。Tomcat是一个免费的开源的Servlet容器，它是Apache基金会的Jakarta项目中的一个核心项目，由Apache，Sun和其它一些公司及个人共同开发而成。由于有了Sun的参与和支持，最新的Servlet和Jsp规范总能在Tomcat中得到体现。Tomcat被JavaWorld杂志的编辑选为2001年度最具创新的Java产品，可见其在业界的地位。Tomcat的环境主要有以下几方面技术优势：1．Tomcat中的应用程序是一个WAR（WebArchive）文件。WAR是Sun提出的一种Web应用程序格式，与JAR类似，也是许多文件的一个压缩包。2．在Tomcat中，应用程序的部署很简单，你只需将你的WAR放到Tomcat的webapp目录下，Tomcat会自动检测到这个文件，并将其解压。3．Tomcat不仅仅是一个Servlet容器，它也具有传统的Web服务器的功能：处理html页面。4．Tomcat也可以与其它一些软件集成起来实现更多的功能。运行环境：1.操作系统：Windows7以上版本。2.服务器软件：Tomcat6.0以上版本。3.相关软件：Myeclipse,MySQL。4.浏览器：IE、FireFox、GoogleChrome。2任务分解（1）任务分解的原则1.将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；2.每个任务原则上要求分解到不能再细分为止；3.日常活动要对应到人、时间和资金投入。（2）任务分解的方法1.采用树状结构进行分解；2.以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项工作。（3）任务分解的标准1.分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节；2.逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有活动全部定义清楚，要细化到人、时间和资金投入。2.1任务负责与分配按项目本身的实际情况进行自顶往下的结构化分解，形成树形任务结构，如图4所示，再把每个工作单元的工作内容，所需的工作量，预计完成的期限也规定下来。这样就可以把划分后的工作落实到人，做到负责明确，便于监督检查。在线书店管理系统在线书店管理系统加工信息收集信息打印报表加工信息收集信息打印报表统计计算统计计算图4：任务结构化解任务责任矩阵是在任务分解的基础上，把工作分配给相关人员，用一个矩阵形表格表示任务的分工和责任，例如，把图4已分解的任务分配给五位软件开发人员，表2表明了利用任务责任矩阵表达的分工情况。从表中可以看出，工作的责任和任务的层次关系都非常明确。任务责任矩阵如表2所示编号工作划分负责人柳某系统工程师王某系统工程师梁某程序员张某程序员李某1审批11.1收集信息审查设计实现1.2加工信息审查1.21.21统计设计实现1.22计算设计实现1.3打印报表审查设计实现表2：任务责任矩阵列表2.2项目范围管理(1)项目范围定义项目范围定义就是把项目的主要可交付成果分为较小的，更易管理的单元。而项目范围定义的输入输出（结果）就是工作分解结构（WBS）。(2)项目范围管理的目的1.确定应完成的工程活动内容，以便作出详细定义和计划。2.确保在预定的项目范围内有计划的完整的进行项目的实施和管理工作（便于项目实施控制）。3.确保项目各项活动满足项目范围定义的要求。4.为进一步确定项目费用、时间和资源计划作准备5.划定项目责任，方便对各项目任务承担者进行监督、考核和评价。(3)项目范围管理的内容1.项目范围的确定（项目目标、可交付成果）；2.明确范围管理组织责任（专人负责）；3.范围定义（结构分解、WBS、说明文件）；4.项目范围预期稳定性评价（预测范围变更）；5.实施中的范围控制（活动控制、任务落实、报告、现场检查）；6.范围变更管理（控制项目范围变化）；7.范围确认（审查确认成果）。(4)工程项目范围确定的依据1.项目目标的定义和批准的文件（项目建议书、可研报告、项目任务书）；2.项目产品描述文件（功能描述文件、规划文件、设计文件、相关规范、可交付成果清单）；3.环境调查资料（法律法规、设计和施工规范、现场条件、周边组织要求）；4.项目的其他限制条件和制约因素（预算、资源、时间的限制）；5.已建项目相关历史资料，同类项目经验教训。(5)工程项目范围确定的过程1.项目目标的分析。2.项目环境的调查与限制条件分析。3.项目可交付成果的范围和项目范围的确定。4.对项目进行结构分解工作。5.项目单元的定义。6.项目单元之间界面的分析，包括界限的划分与定义、逻辑关系的分析，实施顺序安排(6)范围计划编制项目范围计划（有的资料也称范围规划）是指形成正式文件，为将来的项目决策建立基础，包括怎么判断项目和项目阶段已经成功完成的基本标准。简单的说，就是编写项目范围说明书（或工作约定书）的过程。项目范围计划过程的主要输入（收集和参考的资料）包括项目章程（目标）和项目概述（包括产品描述，项目约束，项目条件假设等），而主要输出（结果）是形成书面的范围说明书，如图5所示。输入产品说明项目证书制约因素假设条件工具和技术产品分析利润/成本分析任选的鉴定方式专家评审输出范围阐述提供详情范围管理计划图5：范围计划的输入与输出图(7)确定工程项目范围的影响因素(如图6所示)总目标与限制条件总目标与限制条件最终产品和服务结构其他责任过程责任最终产品和服务结构其他责任过程责任功能和子功能结构功能和子功能结构工程系统结构工程系统结构项目范围定义项目范围定义图62.2.1WBS(1)WBS的定义

WBS（工作分解结构）是WorkBreakdownStructure的英文缩写，是项目管理重要的专业术语之一。WBS的基本定义：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。(2)WBS字典

管理的规范化、标准化一直是众多公司追求的目标，WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS元素的规范，即WBS元素必须完成的工作以及对工作的详细描述；工作成果的描述和相应规范标准；元素上下级关系以及元素成果输入输出关系等。同时WBS字典对于清晰的定义项目范围也有着巨大的规范作用，它使得WBS易于理解和被组织以外的参与者（如承包商）接受。在建筑业，工程量清单规范就是典型的工作包级别的WBS字典。(3)WBS的分层分解层次分解分层层次分解分层整个项目整个项目第一层可交付的成果可交付的成果可交付的成果可交付的成果可交付的成果可交付的成果第二层...可交付的子成果可交付的子成果可交付的子成果可交付的子成果可交付的子成果可交付的子成果第三层...底层可交付的子成果底层可交付的子成果底层可交付的子成果底层可交付的子成果底层可交付的子成果第四层...工作包工作包工作包工作包工作包工作包第五层...图7：WBS的分层分解(4)系统的WBS前台：用户购书功能WBS图如图8所示在线书店管理系统（前台）在线书店管理系统（前台）购物车管理订单管理图书查询分类管理用户管理购物车管理订单管理图书查询分类管理用户管理修改密码查看一级分类订单支付取消未支付订单生成订单我的订单确认收货查看订单详情我的购物车修改数量删除图书添加图书按分类查看图书查看图书详情高级查询图书查看二级分类退出激活登陆注册修改密码查看一级分类订单支付取消未支付订单生成订单我的订单确认收货查看订单详情我的购物车修改数量删除图书添加图书按分类查看图书查看图书详情高级查询图书查看二级分类退出激活登陆注册图8：用户购书功能WBS图后台管理员功能WBS图如图9所示在线书店管理系统（后台管理员管理）在线书店管理系统（后台管理员管理）订单管理图书查询分类显示订单管理图书查询分类显示按状态搜索订单删除新图书修改新图书添加新图书查看图书详情高级查询图书按分类查看图书查看一级分类取消订单查看订单详情订单发货所以订单修改一级分类修改二级分类删除二级分类删除一级分类添加二级分类查看二级分类添加一级分类按状态搜索订单删除新图书修改新图书添加新图书查看图书详情高级查询图书按分类查看图书查看一级分类取消订单查看订单详情订单发货所以订单修改一级分类修改二级分类删除二级分类删除一级分类添加二级分类查看二级分类添加一级分类图9：后台管理员功能WBS图3规模估算3.1成本估算3.1.1直接成本估算项目开发工作量估算表单位：人天编号任务名称估计值小计前台设计：531用户管理模块82分类显示模块103图书查询模块104购物车管理模块105订单管理模块15后台管理：526分类显示模块107图书查询模块248订单管理模块18表3从上图得知项目工作量是105/人天，假设开发人员开发成本参数=500/人天，则内部开发成本=500*105=52500元。管理和质量成本可以根据以往的经验，管理和质量成本约为开发成本的30%，即：52500*30%=15750元。则直接开发成本=开发成本+管理和质量成本=68250元。3.1.2间接成本估算项目名称在线书店管理系统项目经理梁某估算小组成员张三，李四，王五估算阶段与日期2014.6.10工作分解结构项目规模系统模块新代发模块的规模（代码行、类、文档页数）复用或自动生成的组件（代码行、类、文档页数）规模模块11025模块22030模块32520模块41515模块总和7090工作量估计项目研发工作量估计项目研发的工作量=100新开发组件的规模难度系数人均生产率10058需求开发工作量25系统设计工作量15编程工作量30测试工作量25研发总工作量95项目管理工作量 估计项目管理的工作量=75比例系数0.75项目规划工作量16项目监控工作量22需求管理工作量21管理工作量14项目支撑工作量估计项目支撑的工作量=30比例系数0.25配置管理工作量5质量保证工作量5外包与采购工作量4培训管理工作量6支撑总工作量20成本估计类别细分、说明金额人力资源成本2000050000表43.1.3估算的误差任务编号里程碑计划工作预算成本已完成工作预算成本实际成本变量（%）计划成本1已完成100100100002已完成5050550-103已完成5050400204未开工7000-100--5已完成90901400-55.56未开工7000-100--7已完成4050250508未开工5000总计450340360-24.4-5.9表5EAC=（360/340）*579000=613059（元）超支=613059-579000=34059（元）4项目进度项目进度管理是指在\o"项目"项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的\o"管理"管理。是在规定的时间内，拟定出合理且\o"经济"经济的进度计划（包括多级管理的子计划），在执行该\o"计划"计划的过程中，经常要检查实际进度是否按计划要求进行，若出现\o"偏差"偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。4.1定义活动定义活动是一过程，它涉及确认和描述一些特定的活动，完成了这些活动意味着完成了WBS结构中的项目细目和子细目。通过定义活动体现项目工作内容的完成，定义活动的输入输出图如图10所示工具和方法分解参考样板输入工作分层结构范围的叙述历史资料约束因素假设输出活动目录细节说明WBS的修改图10：定义活动的输入输出4.2活动排序活动排序过程包括确认且编制活动间的相关性。实际上，这是一个开发网络图的过程。网络图是一种示意图，描绘项目中各项活动以及它们的时序关系。活动必须被正确地加以排序以便今后制定实现的可行的进度计划，可用手工进行排序，大型项目也可以用专门的软件。排序还因为存在的特定的约束，包括：1.技术需求和规范2.安全性与效率3.企业政策与偏好4.资源可用性活动排序过程包括编制活动间的三种相关性:1.内在的相关性（强制依赖关系）2.指定性的相关性（资源依赖关系）3.与外部相关性（外部依赖关系）活动间有四种相关依赖的关系：结束—>开始：某活动必须结束，然后另一个活动才能开始。结束—>结束：某活动结束前，另一活动必须结束。开始—>开始：某活动必须在另一活动开始时开始。开始—>结束：某活动结束前另一活动必须开始。活动排序的结果（输出）是项目网络图。项目网络图是项目所有活动以及它们之间逻辑关系（相关性）的一个图解表示，如图11所示B开始A C D F E图11：项目网络图解4.3PERTChart(PERT图)PERT(ProgramEvaluationReviewTechnique)图是项目中包含的各项活动的关系视图.是以图形方式辅助表示活动表中列出的活动及其关系.在使用PERT图表示活动关系以前,应做以下工作:(假定我们以改造在线书店系统为例)1.对项目按模块划分,对每个小块分别作出计划(比如持续时间,使用人力,使用机时,占用终端等等).必要时可列出模块的层次结构图。2.做出活动表，如表6活动说明前面的活动持续时间（周）A需求分析A1B重新设计现存部分A6C设计新增部分C3D接口设计C1E增补新代码C6F开发整体衷十划B,D2G修改现存代码E,G5H完成单元测试E,G1J更新文档F2K准备整体测试H,J,K1L执行整体测试L1M完成验收测试1表6上述活动是针对一个已存在的在线书店管理系统,由于情况变化,不满足用户需求而进行改造所提出的步骤.对于从人工系统转化为在线书店管理系统来说,B和C应分别对应于“概要设计”和“详细设计”;E将不存在;F改为“编码”;J改为“整理文档”.在持续时间方面，也要作适当调整.之所以选择本系统的例子,是因为对改造本系统来说,可并行工作的部分比较多,更体现按关键路径进行项目进度管理的有效性。一个PERT图是有方向的其边表示活动,其结点表示事件。在图中标出活动的持续时间。对应上述活动表的PERT图见图l25510983FKLM10983C21H1131D6F121764ABGJ217641652图12：对应项目的PERT图在PERT图中的各项活动以A到M做标记,圆圈表示的事件以l到10做标记,从7到8的虚线是一个虚活动。在每个事件旁标出活动的开始和结束时间各个事件是具有下述意义的项目里程碑事件说明1项目开始2需求分析完成3新增部分设计完成4现有部分重新设计及接口设计完成5整体计划完成6新增部分编码及现有部分修改完成7更新文档完成8完成单元测试，准备整体测试9整体测试完成10验收测试完成11项目结束联结关键事件(最早开始时间和最晚开始时间相等的事件)的PERT图中的路径叫关键路径.每个PERT图至少有一条关键路径.对应于我们实例中的关键路径如图13的红线所示.其中各结点的方框中标出了最早开始时间和最晚开始时间5（4,6）（6,13）5983FKLM98310C21H111031D6F1（14,14）（15,15）（1616）21764ABGJ217641652（14,14）(0,0)(1,1)（7,7）（12,12）图13：具有关键路径的PERT图非关键路径上的活动有比较灵活的开始时间.一个活动的总松弛时间是一个时间范围,在这个时间范围内任一时间开始都不会影响整个项目的完成时间。所以一个活动的松弛时间是:最晚开始时间(LST)减去最早开始时间(EST)对应图13的最早和最晚开始时间如表7所示。活动持续时间最早最晚开始结束开始结束A10101B31436C61717D14567F2461113E6410612G5712712K1671314J212141214H112131314L114151415M115161516表7管理人员重点要掌握关键路径上的事件,按时和提前完成关键路径上的事件对整个项目的完成时间长短有重要意义4.4活动时间估计活动时间估计指预计完成各活动所需时间长短，在项目团队中熟悉该活动特性的个人和小组可对活动所需时间做出估计。活动时间估计的输入包括活动目录，结束和假设，还有：1.资源需求2.资源数量活动所需时间估计的工具和方法：1.专家判断2.类推估计4.5项目进度安排工作集子工作完成时间负责人最终交付物描述项目计划确定负责人以及组长第二周陈玉玺负责人以及组长名单完成在线书店管理系统开发团队的工作分配确定小组第三周王国斌小组成员名单成立系统开发团队小组搭建环境第三周各组组长开发环境运行说明文档确定项目开发的工具及语言制定项目管理计划书第四周熊宝《项目管理计划书初稿》制定软件开发过程管理计划初步完成需求规格说明书采集用户需求第五周陈玉玺熊宝需求规格说明书通过与用户沟通以及查阅相关资料了解和采集用户的需求。对需求进行汇总，制定需求规格说明初稿分析用户需求及制定需求规格说明原型第五周需求规格说明的进一步完善与修改第六周需求规格说明的最后确认第七周系统设计系统总体设计第八周张三软件设计报告初稿制定系统总体的设计方案，并根据需求说明联系实际进行相应的修改系统详细设计第九周系统模型及架构最后确定第十周开发系统源代码及源码测试系统源码开发第十一周李天交付源代码掌握开发工具的使用系统源码测试第十二周王五测试文档根据测试要求严格测试系统源码复查第十三周吴倩无对代码进行复查，尽量减少bug进行整个在线书店滚轮系统的集成进行整个网上教学系统的集成第十四周梁冰无与其他小组长无间协作完成整个系统的集成对整个集成后的系统进行测试检查运行情况第十四周张国体无配置好IIS服务，搭建整个系统的运行平台测试整个系统的发布情况系统交付系统交付第十五周张斌系统能够运行以及以及把相关技术文归类存档各组之间可以交流各自的开发经验和心得体会表84.5工具使用MicrosoftProject是国际上最为盛行与通用的项目管理软件，适用于新产品研发、IT、房地产、工程、大型活动等多种项目类型。经过微软多年研发，Project包含了经典的项目管理思想和技术以及全球众多企业的项目管理实践。在企业内部使用和推广Project，在提升项目管理人员能力的同时也实现了项目管理专业化与规范化的过程。5质量计划项目质量计划是指为确定项目应该达到的质量标准和如何达到这些项目质量标准而做的项目质量的计划与安排。项目质量计划是质量策划的结果之一。它规定与项目相关的质量标准，如何满足这些标准，由谁及何时应使用哪些程序和相关资源。项目质量计划工作的成果：项目质量计划、项目质量工作说明、质量核检清单、可用于其它管理的信息。5.1质量计划编制编制项目的质量计划，首先必须确定项目的范围、中间产品和最终产品，然后明确关于中间产品和最终产品的有关规定、标准，确定可能影响产品质量的技术要点，并找出能够确保高效满足相关规定、标准的过程方法。编制质量计划通常采用流程图、因果分析图等方法对项目进行分析，确定需要监控的关键元素，设置合理的见证点（W点）、停工待检点（H点），并制定质量标准：

1.流程图：

显示系统的各种成分是如何相互关系的，帮助我们预测在何处可能发生何种质量问题，并由此帮助开发处理他们的办法。

2.因果分析图（也称鱼刺图）如图14所示：人员人员参考资料设备参考资料设备质量问题质量问题环境方法环境方法原因结果图14对于本项目，编制质量计划时采用因果分析图，描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。其次，质量计划中还必须确定有效的质量管理体系，明确质量监理人员对项目质量负责和各级质量管理人员的权限。戴明环（又名PDCA循环法）作为有效的管理工具在质量管理中得到广泛的应用，它采用计划——执行——检查——措施的质量环，质量计划中必须将质量环上各环节明确落实到各责任单位，才能保证质量计划的有效实施。5.2质量保证活动质量保证的只要活动包括过程评审和产品审计，过程评审和产品审计的目的是确保在项目进展过程中的各个阶段和各个方面采取各项措施来保证和提高提交给用户的产品质量。每一次过程评审和产品审计都应填写相应的报告或活动记录。如下表9为质量计划标准项目具体描述计划实际需求检查52系统总体设计检查21缺陷排除率（缺陷数/KLOC）详细设计复核3227详细设计检查107代码复核6156代码检查2018编译2115单元测试1514系统集成54系统测试55表95.3产品审计产品审计由质量保证人员来进行，检查项目产品是否达到质量目标。质量保证人员可以有选择性地审计项目生存期中创建工作产品，以验证是否符合适当的标准，是否进行了质量检查，质量审计一览表见表10所示项审计对象审计阶段参照的标准1软件项目计划计划结束企业质量体系2软件配置管理计划计划结束企业质量体系3软件质量保证计划计划结束企业质量体系和项目规划4总体设计文档设计结束企业质量体系和项目规划5详细设计文档计划结束企业质量体系和项目规划6数据库表和编码规范计划结束企业质量体系和项目规划7产品代码每个阶段实施结束企业质量体系和项目规划8测试报告测试结束企业质量体系和项目规划9系统计划设计结束企业质量体系和项目规划10用户文档测试结束企业质量体系和项目规划表105.4过程评审项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。5.5测试计划1.建立每个测试阶段的目标。2.确定没项测试活动的进度和职责。3.确定工具、设备和测试库的可用性。4.建立用于计划和进行测试以及报告测试结果的规程和标准。5.制定衡量测试成功与完成的准则。6配置计划项目质量计划是指为确定项目应该达到的质量标准和如何达到这些项目质量标准而做的项目质量的计划与安排。项目质量计划是质量策划的结果之一。它规定与项目相关的质量标准，如何满足这些标准，由谁及何时应使用哪些程序和相关资源。项目质量计划工作的成果：项目质量计划、项目质量工作说明、质量核检清单、可用于其它管理的信息。6.1配置管理人员组成根据本项目计划的角色分配，可以确定配置管理人员，配置管理人员的角色和职责见表11：角色人员职责、工作范围配置管理者张三1.制定《配置管理计划》2.创建和维护配置库项目经理李四1.审批《配置管理计划》2.审批重大的变更项目组成员项目经理：张晓质量保证人员：王五配置管理者：吴天审批某些配置项或基线的变更表116.2配置控制配置控制活动请求、评估、认可或拒绝、实现对基线CI的配置变更。变更包括错误的改正和可靠性增强。为变更过程所需的必须手续的复杂程度依靠在配置结构中变更对基线的影响。计划必须描述在基线CI的变更控制影响。计划必须定义下列的详细步骤：1.变更所需的标识和文档；2.变更需求的分析和评估；3.需求的认可或否决；4.变更的确认、执行和发布；计划必须标识用来追踪和记录每个变更的执行序列的记录。在处理原始需求的变更的每个不同必须被明确的记录下来。6.3配置审核和审计配置审核决定事实上CI影响的所需的物理和功能的广度。配置审阅时建立基线的管理工具。计划必须为项目标识配置审核和审计。至少，一个配置审核必须在CI发布前审核。对每个计划的配置审核和审计，计划必须定义以下方面：1.它的目标；2.处于审核和评审CI；3.审核和评审任务的时间表；4.实施审核和评审的过程；5.工作标题的参与者；6.为回顾或支持审核和评审需要用到的文件；7.记录不足和报告纠正行动的过程；8.对认可之外的认可标准和特定行动。7风险计划项目风险管理是指通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法技术和手段，对项目的风险实行有效的控制，妥善的处理风险事件造成的不利后果，以最少的成本保证项目总体目标实现的管理工作。7.1风险识别,评估与风险规划（1）风险识别风险识别是理解某特定项目有哪些可能令人满意的结果的过程。就是采用系统化的方法，识别某特定项目已知的和可预测的风险。（2）风险评估风险评估（RiskAssessment）是指，在风险事件发生之前或之后（但还没有结束），该事件给人们的生活、生命、财产等各个方面造成的影响和损失的可能性进行量化评估的工作。即，风险评估就是量化测评某一事件或事物带来的影响或损失的可能程度。（3）风险规划针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件。通常采取的措施有回避风险。转移风险。3.损失控制。4.自留风险。7.2风险分析表根据风险识别，风险评估，风险规划可以制定了如下风险分析表排序输入风险事件可能性影响风险值风险应对措施1最终用户抵制该系统投资方可能会由于某个细节的问题对整个系统产生反感。80%70%40%1.尽力满足用户提出的需求。2.界面尽可能的美观，方便。3.需求分析阶段派出专门的系统分析员去了解用户的性格，爱好，工作习惯。2项目期间，投资方举棋不定网上购物系统众多，投资方浏览后可能会经常要求更改需求60%70%40%1.软件详细设计阶段注意增加软件的可重用性。提高复用水平。2.沟通和协调。3客户的需求规格说明需求不明确，增加需求，导致需求蔓延，由于本软件是不太了解计算机的用户使用，变更需求可能性很大。70%50%35%1.采取加班的方法。2.修改计划去掉一些任务。3.与客户商量延长一些时间。4.当出现影响重大的变更需求时与客户协调，这个版本的不做改动，在下一个版本中进行功能的提升。4合同带来的限制进度要求紧，合同金额有限。

30%50%15%可以请一些实习的学生做辅助工作,一来成本不高,二来可以加快进度。5交付期限紧缩。需方存在紧缩交付期限的可能。导致项目吃紧。20%60%10%1.加班。2.临时雇佣员工。3.调整结构。6历史项目信息。开发人员的流动。15%60%9%1.注意项目团队的沟通，及时了解开发人员的动态。2.控制好项目过程中的文档。3.从其他的项目组借调人员。4.从外部招聘有过此类开发经验员。

7人员缺乏经验。由于本项目中的一些员工是刚刚招聘来的，可能会缺乏经验。15%30%10%1.采取一帮一，让有经验的程序员带着相对经验少的程序员进行开发。2.开发之前适当的培训。8用户数量超出计划。由于该网站可能销售商品特别，导致访问激增。20%20%20%1.防患于未然，数据库上采用数据池的技术在，增加并发访问量。9技术达不到预期效果。可能有一些技术达不到预期的效果，不能使需方满意。如访问速度，一些特效等等。10%10%10%1.找懂得这种技术的人帮忙。2.向老师请教。表127.3风险应对措施（1）风险规避风险规避是改变项目计划来消除特定风险事件的威胁。通常情况下我们可以采用多种方法来规避风险。例如，对于软件项目开发过程中存在的技术风险，我们可以采用成熟的技术，团队成员熟悉的技术或迭代式的开发过程等方法来规避风险;对于项目管理风险我们可以采用成熟的项目管理方法和策略来规避不成熟的项目管理带来的风险;对于进度风险我们可以采用增量式的开发来规避项目或产品延迟上市的风险。对于软件项目需求不确定的风险我们可以采用的原型法来规避风险。（2）风险转移风险转移是转移风险的后果给第三方，通过合同的约定，由保证策略或者供应商担保。可以采用外包的形式来转移软件开发的风险，例如发包方面对一个完全陌生领域的项目可以采用外包来完成，发包方必须有明确的合同约定来保证承包方对软件的质量，进度以及维护的保证。否则风险转移很难取得成功。（3）风险减轻风险减轻是减少不利的风险事件的后果和可能性到一个可以接受的范围。通常在项目的早期采取风险减轻策略可以收到更好的效果。例如，软件开发过程中人员流失对于软件项目的影响非常严重，我们可以通过完善工件，配备后备人员等方法来减轻人员流失带来的影响。（4）风险接受准备应对风险事件，包括积极的开发应急计划，或者消极的接受风险的后果。对于不可预见的风险，例如不可抗力;或者在风险规避，风险转移或者风险减轻不可行，或者上述活动执行成本超过接受风险的情况下采用。8团队管理项目团队是软件项目项目中最重要的因素，成功的团队管理是软件项目顺利实施的保证。8.1软件团队管理概述软件项目团队管理工作结构如图15所示软件项目团队管理软件项目团队管理团队组织计划输入：组织界面人员配置要求制约方法和技术：样板人力资源惯例组织理论项目干系人分析输出：组织结构图角色和职责分配人员配备管理计划支持细节团队人员获取输入：人员配置管理计划人员库说明招募规则工具和技术：1.谈判2.预分配3.采购输出：1.已分配的项目人员2.项目团队名录团队建设输入：项目人员项目计划3.人员配置管理计划4.执行情况报告5.外部反馈措施：1.团队建设活动2.一般管理技能3.奖励和承认系统4.集中5.培训输出：1.团队效能改进2.绩效评估输入图158.2软件项目团队1.软件项目开发团队是通过将不同的个体组织在一起，形成一个具有团队精神的高效率队伍来进行软件项目的开发。2.软件项目包括所有的项目干系人。项目干系人是指参与项目和受项目活动影响的人，包括：.项目发起人.资助者.供应商.项目组成员.协助人员.客户.使用者.项目的反对人8.3沟通时间安排1.小组交流（1）每周例会每周例会时间由小组负责人自己拟定，因为要满足各成员在场，所以时间弹性比较大，但确定每周例会时必须的。（2）每天交流项目小组成员之间要每天进行交流，使用电话、QQ等进行讨论有问题及时解决。2.团队交流（1）每两周例会（时间固定）每两周四下午14：30到17：30进行整个团队的项目交流。（2）每天交流每天项目组成人员用电话或者QQ来进行讨论，了解项目的进度，交流所遇到的困难并及时解决。9项目度量软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目成功，开发高质量的软件产品。度量取向是软件开发诸多事项的横断面，包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量，等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。9.1度量指标度量指标如表13所示度量指标分析方法决策准则里程碑进度偏差1.统计项目各个里程碑进度偏差值，画出对应的控制图如果里程碑进度相对偏差超出+/-5%，则项目经理需要调查原因并采取措施。如果里程碑进度相对偏差超出+/-15%，进行正式的计划变更项目生产率1.统计项目的总工作量和产品实际规模2.计算出项目生产率若项目生产率高于或者低于公司平均生产率10%，则要求评价项目，检查项目的实际过程是否与组织的标准过程符合项目软件开发生产率1.统计各项目每周的软件开发生产率画出趋势图如果该生产率低于或高于公司平均水平10%时，需分析原因，采取相关措施调整项目按时完成率项目按时完成率的控制图对项目按时完成比率低于90%的时候，分析其原因，并制定整改措施。相对偏差低于等于10%为按时完成，反之为未按时完成。软件产品的遗留缺陷密度1.统计软件产品遗留缺陷和产品实际规模，使用柱状图表示软件产品遗留缺陷密度软件产品的遗留缺陷密度如果高于1，则必须调查其根本原因顾客满意度1.根据顾客满意度的分数，可以将产品或者服务的满意度分为：不满意、非常不满意、非常满意、较满意、满意，而后用柱形图表示满意度的情况顾客满意度低于85，则必须调查其根本原因。需求稳定度参见《度量构造指南》需求稳定度低于90%，则必须调查其根本原因任务工作量分布1.统计各类型任务工作量之和并使用饼图显示各类型任务工作量分布情况如果各类型任务工作量所占项目总工作量的比例比公司度量库中值偏差10%，则必须调查其根本原因。阶段工作量分布1.统计各阶段任务工作量之和并使用饼图显示各阶段任务工作量分布情况如果各阶段任务工作量所占项目总工作量的比例比公司度量库中值偏差10%，则必须调查其根本原因。表139.2数据收集数据的收集如表14：目标度量指标数据定义责任提高项目化产率功能点／l时项目实施过程中计算出功能点数。功能点负责人用电子表格记录数据。项目开发周期内记录工作时间量。开发人员随时记录数据。提高顶目质量缺陷功能点项目实施过程中计算出功能点数。功能点负责人用电子表格记录数据。计算用户使用三个月后的缺陷数。服务台的人员在接到用户的报告后采用缺陷跟踪系统记录数据。降低项目成本成本功能点项目实施过程中计算出功能点数。功能点负责人用电子表格记录数据。按工作量计算出劳动成本。项目经理在项目进行过程中记录并计算。项目周期内记录非芳动成本。表1410集成项目项目集成管理是为了实现项目目标，确保项目范围内的各项工作能够顺利协调地配合进行，消除项目管理中的局部性，平衡项目各个目标之间的冲突，保证项目过程各阶段的正确实施，所开展的以整体思想为指导，从全局出发，以项目总体利益最大化为目标，以统一协调各方面管理为内容进行的全面管理的过程。它具有综合性、全局性和内外兼顾性的特征。集成项目计划的完成是项目经理完成项目计划的标志。项目集成管理包括对计划的集成管理和对项目跟踪控制的集成管理，它保证项目各要素相互协调，在相互影响的项目目标和方案中做出权衡，以满足或者超出项目干系人的需求和期望。10.1项目集成计划范范成功进围计划度计计划风划险质配沟计量置通划计计计划划划项目控制度项目控制项目计划量项目计划计划图16：项目集成计划图10.1.1项目概述网上购书的优势在于选择面大、价格便宜、交易方便、节省时间和精力等。整个图书市场一片繁荣，在这种情况下，网上书店的加入无疑将使得竞争更加激烈，但从另一个方面看，只有在这种激烈的竞争下，网上书店的优势才能得以体现。在中国，网上书店有发展的必要，也有发展的基础，发展网上书店的各方面条件也日趋成熟，但是还存在一些问题，只有把问题解决好了，才能保证网上书店的蓬勃发展。网上在线书店是以当前商务的网络化、快速化实际需求为背景，实现图书购买的方便、快捷、送货上门等服务为前提综合信息服务系统的设计；实现通过Internet互联网对图书购买的相关信息进行发布及图书查询、图书介绍、图书内容浏览等功能。消费者通过网络在线进行图书的网上购物和网上支付等活动，这样即方便了消费者，又减少了企业成本。倡导“用户是伙伴，多为用户着想”的新型客户服务理念。因此，在网络在线书店系统实现显示其它用户购买情况和浏览产品情况。这些新型客户服务，具有与众不同的优势和特点，将成为和用户沟通、联系、发展的有效的方法。10.1.2项目任务范围在线书店管理项目需要完成的任务主要包括会员注册、订单管理、购物车、搜索、支付等基本功能。此外，本系统也将实现在线图书销售系统的后端管理，包括图书的添加、订单的处理等功能。本系统完全基于JSP技术，在系统的设计与开发过程中严格遵守软件工程的规范，运用软件设计模式，从而减少系统模块间的偶合，力求做到系统的稳定性、可重用性和可扩充性。。10.1.3项目目标本系统完全基于JSP技术，在系统的设计与开发过程中严格遵守软件工程的规范，运用软件设计模式，从而减少系统模块间的偶合，力求做到系统的稳定性、可重用性和可扩充性，与传统利用书店进行销售的方式相比拥有许多优势：一是降低了销售成本；二是利用网络作为交易平台，改变传统的交易方式，使得交易活动不受空间和时间的限制；三是信息的传递更迅速灵活，新书信息上传后，客户可以立即看到，交易马上可以从网上进行，从而大大提高了交易的效率。11跟踪控制11.1项目分析在线书店管理系统这个项目的负责人每天都需要审核项目的实际情况，对比项目的规模估算，项目进度，质量计划，配置计划，风险计划来判断实际项目是否得到了有效的完成。同时在上面说明的的每周五的团队沟通例会中进行进一步的审核与交流。每个基线结束后，进行阶段评审，给出阶段评审报告。该报告具对本项目的完成，和对未来项目的经验积累都有重大的意义。这个报告可以给需求方，使他们也能够了解项目的进度。11.2阶段评审报告模板本项目阶段评审报告表如表15所示项目名称政府公文审批及工作通告系统项目标识部门/组织名阶段名称总体设计主持人丁锋会议地点A401评审时间2014年10月24日评审次数2评审人张三，李四，王五评审项与结论评审要募评审结果问题和对策详细设计实施结果满足需求规格的要求开发人员与用户一起评审，用户对本阶段的提交结果很满意。计划执行通过基本按计划执行质量情况通过满足质量计划的要求配置管理通过开发人员对配置工具的使用技巧学习有待提高其他问题通过开发人员增强政府工作业务学习，以便保证开发顺利进行。同时要进一步了解操作者的习惯计划调整完成根据本阶段的计划执行情况调整下一阶段的计划提交产品项目计划计划跟踪数据源码评审报告阶段统计数字数据项目计划实际偏差工期（日）30333规模（人时）720792+72人力投入（M/D/QA/SCM）l21112l32成本（元）4300042000+5000阶段日期2013/8/3-2013/9/32013/8/3-2013/9/9正常开始，延后6天结束阶段评语本阶段的成本和进度基本在控制的范围之内，而且进度略有延后。在完成本阶段目标的基础上，开发人员更加深入地熟悉技术和业务，为确定下阶段目标打下了一定的基础。从管理上，体现在生存期的定义、项目计划的细化和确认、项目跟踪日常化等方面。可以为今后类似项目的管理提供宝贵的经验。所以，本阶段除较好地完成了规定的目标之外，还进行了许多有益的尝试，本阶段结束后，项目进展及完成情况属正常表1512系统测试12.1测试的目的与目标在此系统进行初步实现之后，开始进行对系统进行测试，找出系统中存在的Bug，通过测试，用提交的Bug报告来为以后软件的改进提供标准和参考，能够在以后的系统改进中找到依据。测试后的软件各模块基本功能可以顺利进行，尽可能的提高软件的健壮性。12.2测试方法1.从是否关心软件内部结构和具体实现的角度划分：黑盒测试和白盒测试；2.从是否执行程序的角度：静态测试和动态测试；3.从软件开发的过程按阶段划分有：单元测试、集成测试、确认测试、系统测试、验收测试、回归测试、Alpha测试、Beta测试；单元测试又称模块测试，是针对软件设计的最小单位─程序模块（这里所说的程序模块在Java中一个模块就是一个方法），进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。集成测试(组装测试、联合测试），通常在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2.一个模块的功能是否会对另一个模块的功能产生不利的影响；3.各个子功能组合起来，能否达到预期要求的父功能；4.全局数据结构是否有问题；5.单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。确认测试（ValidationTesting），确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。系统测试（SystemTesting），是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。验收测试（Acceptance