第8章 IDP支持过程

《第8章 IDP支持过程》由会员分享，可在线阅读，更多相关《第8章 IDP支持过程（14页珍藏版）》请在装配图网上搜索。

1、IDP支持过程第8章8.1 软件配置管理和文档管理38.1.1 软件配置管理的概念38.1.2 软件代码管理的一般规则38.1.3 文档管理的一般规则48.2 软件质量管理58.2.1 软件质量管理的模型58.2.2 技术评审68.2.3 测试管理88.2.4 发布管理98.2.5 质量保证98.2.6 缺陷（问题）跟踪118.3 客户服务管理128.3.1 客户信息管理128.3.2 客户问题受理128.4 统计分析138.1 软件配置管理和文档管理8.1.1 软件配置管理的概念软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、

2、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。软件开发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item），配置项主要有两大类：软件代码（包括源代码和二进制代码）和文档。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、

3、丢失。配置项及其历史记录反映了软件的演化过程。基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（即变更控制）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。8.1.2 软件代码管理的一般规则软件代码管理的特征： 开发人员可能在一天之内多次更新代码，可能对整个目录进行checkout/checkin操作，文件数量多，对实时

4、性要求比较高。 软件代码的版本结构可能比较复杂（例如产生分支），对代码管理工具的功能要求比较高。 一般地只有开发人员可以checkout/checkin代码，非开发人员不必（也不该）访问代码库。开发人员应当采用专业配置管理工具来管理所有的软件代码，常见配置管理工具有CVS、SourceSafe、ClearCase等。软件代码管理的一般规则如下： 先请配置管理员在配置管理工具中创建对应的代码库，其目录结构与开发环境的目录结构保持一致。 配置管理员为每个项目成员分配代码库的操作权限。一般地，项目成员拥有Add, Checkin/Checkout等权限，但是不能拥有“删除”权限。具体操作视所采用的配

5、置管理工具而定。 项目成员根据自己的权限操作代码，例如Add, Checkin/Checkout 等，项目组成员要保证代码及时Checkin（建议时间间隔不能超过1天，最好能够每日Build所有代码）。 如果要修改已经发布了的代码，必须遵循 “申请审批执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许省略“变更控制报告”，但是至少要得到项目经理的口头批准，并告知受影响的相关人员。 有关责任人定期备份代码库。8.1.3 文档管理的一般规则文档管理的特征： 文档的主要用途是交流，交流越充分则文档的价值就越高。所以除了开发人员，不少相关人员（例如领导、市场人员等）都可能访问文

6、档库。 人们一般不会频繁地修改文档，文档的版本结构很简单（一般不会产生版本分支），对管理工具的功能要求不高。 人们并不局限在办公室里使用文档，可能出差在外地、也可能在家里使用文档。 一般地，企业领导和市场人员基本上不会使用CVS、SourceSafe、ClearCase查看文档（对他们而言这些工具都太复杂了），使用Web方式对他们而言最方便。尽管专业的配置管理工具既可以管理软件代码也可以管理文档，由于软件代码和文档有比较大的差异，业界倾向于将软件代码和文档分开管理： 采用专业配置管理工具（如CVS、SourceSafe、ClearCase等）来管理软件代码。 采用基于Web的文档管理工具来管理

7、文档，文档管理工具通常和本公司的网站链接。这样人们可以在任何地方通过 Web 方式访问他需要的文档（前提条件是拥有访问权限），非常方便。文档管理的一般规则如下： 配置管理员创建文档库，至少确定文档库的第一级目录。 配置管理员为每个项目成员分配文档库的操作权限。一般地，项目成员拥有Add, Checkin/Checkout等权限，但是不能拥有“删除”权限。具体操作视所采用的文档管理软件而定。 项目成员根据自己的权限操作文档，例如Add, Checkin/Checkout 等，项目组成员要保证文档及时Checkin（建议时间间隔不能超过1周）。 配置管理员用文件袋或文件柜妥善保管纸质文档（例如客户

8、提供的纸质文件）。 如果要修改已经发布了的重要文档（例如需求文档、设计文档、项目计划），必须遵循“申请审批执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许省略“变更控制报告”，但是至少要得到项目经理的口头批准，并告知受影响的相关人员。 有关责任人定期备份文档库（见配置管理计划，一般由配置管理员备份）。集成化研发管理平台RDMS提供了“基于Web的文档管理系统DocCenter”，是对软件配置管理工具的补充，满足上述文档管理的要求。8.2 软件质量管理8.2.1 软件质量管理的模型IDP的软件质量管理模型如图8-1所示，主要活动是“技术评审”、“测试管理”、“发布管理”

9、、“质量保证”和“缺陷（问题）跟踪”。提示：集成化研发管理平台RDMS的质量管理功能，和图8-1的质量管理模型配套。质量保证测试管理缺陷和问题跟踪技术评审发布管理整个机构各个项目持续提高整个机构的技术水平和规范化水平图8-1 软件质量管理的模型8.2.2 技术评审技术评审的目的是通过同行专家对工作成果的评审讨论，尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审的主要好处有： 技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本； 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，

10、一定程度上提高了开发生产率。理论上讲，软件开发过程的所有工作成果都应当接受技术评审。现实中，为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审是临时的团体活动，机构没有专职的技术评审人员，当需要技术评审的时候临时组织人员就可以了。如果机构有独立的质量人员，他应当参与重要的技术评审会议，这样既监督了技术评审，又加深对工作成果的了解。技术评审的一般流程如图8-2所示。关键活动是：申请、评审、执行。技术评审报告的格式见表8-1。软件项目最重要的技术评审是需求评审和设计评审。技术评审会议 执行负责人执行评审申请 申请人 评审人图8-2 技术评审的流程1. 申请技术评审名称例如：软件设计评审

11、评审内容介绍附件申请人评审负责人只有1位负责人评审人评审人A，评审人B，评审会议时间评审会议地点2. 评审会议评审人评审意见评审人A评审人B评审结论 合格 合格需改进 不合格需重做指示执行人负责人3. 执行执行人执行情况表8-1 技术评审报告的格式第1步 申请在每个技术评审点，申请人（技术负责人或者项目经理）的主要工作如下：（1）填写技术评审的申请单（见表8-2）；邀请真正内行的人担任评审人。（2）整理需要评审的工作成果，发给相关人员；（3）和评审人约定技术评审会议的时间、地点；第2步 评审在技术评审会议期间，所有与会人员发表见解，提出问题并协商解决方案。每个评审人填写评审意见。评审负责人汇总

12、大家的意见，给出评审结论。评审结论有3种：（1）合格（2）合格需改进（3）不合格需重做评审负责人根据评审结论，给出相应的指示，指定执行人负责人。第3步 执行执行负责人根据评审结论和指示，执行相应的工作，填写执行情况。8.2.3 测试管理测试工程师根据模块需求说明书和设计说明书，撰写测试用例，格式见表7-8。开发工程师审阅测试用例，提出改进建议，双方达成共识。测试人员按照测试用例执行测试。如果发现缺陷，则记录在缺陷跟踪工具中，并通知项目经理或开发人员。开发人员及时消除缺陷后，更改缺陷跟踪工具中的相关信息。测试人员验证后，关闭该缺陷。提示：集成化研发管理平台RDMS的测试管理功能，可以填写测试用例

13、，记录测试结果，并关联缺陷。8.2.4 发布管理项目团队采用增量开发模式，可能每隔几天（或几周）就发布一个软件版本。发布用于内部测试的软件版本称为“Build”，发布给客户使用的软件版本称为“Release”。发布管理的目的是记录每次发布的软件版本号和相应功能说明，便于相关人员测试和使用。发布记录的格式见表8-2。项目名称发布负责人版本标记发布日期发布说明用途，功能说明和测试说明等。表8-2 发布记录的格式8.2.5 质量保证质量保证是指检查项目的“工作过程和工作成果”是否符合既定的规范。符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。例如开发人员没有

14、使用配置管理工具，开发人员没有写需求文档就开始编程等，这些问题可以在过程检查中发现。质量保证的要点是：找出明显不符合规范的工作过程和工作成果，及时督促开发人员纠正问题。质量保证员在执行检查的时候，如果发现问题，应该立即记录下来。质量保证员首先设法在项目内部解决已经发现的质量问题，与项目成员们协商，给出解决措施。在项目内难以解决的质量问题，由上级领导给出解决措施。质量保证员根据项目特征，设计“质量保证检查表”，格式见表8-3，向项目成员和上级领导汇报现阶段的质量状况。质量保证检查表项目名称质量保证员检查项（应根据项目特征调整）发现的问题，日期问题跟踪解决需求评审的检查项：1. 全体项目成员参加了

15、需求评审。2. 评审之前已经完成需求文档。3. 评审人员对需求达成了共识。需求文档的检查项：1. 按模板撰写了产品或项目需求说明书。2. 按模板撰写了主要的模块需求说明书。设计评审的检查项：1. 项目技术骨干参加了设计评审。2. 评审之前已经完成设计文档。3. 评审人员对设计达成了共识。设计文档的检查项：1. 按模板撰写了系统设计说明书。2. 按模板撰写了主要的模块设计说明书。项目管理的检查项：1.项目成员使用统一的工具来管理任务进度。2. 项目经理每周写项目周报。3. 大的变更有变更控制报告。软件配置管理的检查项：1. 定期备份配置库，确保安全。2. 软件交付给客户后，代码严格受控。3. 凡

16、是交付给客户的软件包，必须从配置库提取已经通过测试的软件包。测试改错的检查项：1. 测试人员按模板撰写了测试用例，开发人员审阅了测试用例。2. 测试人员和开发人员使用缺陷跟踪工具。客户服务和维护的检查项：1. 客服人员记录客户请求，及时告知相关人员。2. 维护人员及时响应，并记录维护工作。表8-3 质量保证检查表8.2.6 缺陷（问题）跟踪人们在开展技术评审、软件测试、质量保证活动时，可能发现不少缺陷（或者其它质量问题）。如果没有缺陷跟踪工具的话，人们只好用纸张或文件去记录缺陷，不仅变更缺陷信息很麻烦，而且难以共享信息。缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的，一般都有数据库支持，可以在

17、局域网内运行。缺陷的属性如表8-4所示。缺陷跟踪工具的常见功能有：查询缺陷、新建缺陷、修改缺陷、删除、缺陷饼图、缺陷趋势图、发送消息。提示：集成化研发管理平台RDMS具备缺陷跟踪功能。缺陷属性描 述缺陷编号给每个缺陷分配唯一的ID 缺陷类型给缺陷划分一些类型，便于统计。所属模块说明该缺陷所属的模块缺陷状态常用缺陷状态有：新缺陷、缺陷再现、解决待关闭、关闭等缺陷描述用一段文字描述缺陷附件本缺陷相关的附件严重性划分缺陷的严重性，例如严重、中等、轻微等优先级划分处理缺陷的优先级，例如高、中、低报告者即报告这个缺陷的人报告日期给出这个缺陷的报告日期接受者把缺陷指派给某人处理解决方案用一段文字描述该缺陷

18、的解决方案更新日期缺陷信息的更新日期表8-4 缺陷的属性表8.3 客户服务管理8.3.1 客户信息管理本公司客服人员收集并整理客户信息，如填写客户公司信息（如表8-5所示），填写客户联系人信息（如表8-6）所示。公司名称公司地址公司网址联系方式如电话、传真等邮政编码公司简介其它表8-5 客户公司信息姓名所属公司职务联系电话固定电话、移动电话电子邮箱个人介绍其它表8-6 客户联系人信息提示：集成化研发管理平台RDMS满足此“客户信息管理”要求。8.3.2 客户问题受理客户问题受理的一般流程如图8-3所示，主要活动有：报告问题，受理问题，处理问题，关闭问题。客户报告问题负责人处理问题客服人员受理问

19、题客服人员关闭问题客户反馈信息图8-3 客户问题受理第1步 报告问题客户通过各种途径报告问题，客服人员记录该问题。第2步 受理问题客服人员对问题进行分类，指定处理问题的负责人，并填写受理意见。第3步 处理问题负责人处理问题，填写处理意见，设置问题的状态（如正在处理，解决待关闭）。第4步 关闭问题客服人员检查状态为“解决待关闭”的问题，如果确实已经解决该问题，则将状态设置为“关闭”。可能的话，客服人员获取客户的反馈意见。提示：集成化研发管理平台RDMS满足此“客户问题受理”的要求。8.4 统计分析IDP统计分析分2类：（1）以项目为中心的统计分析；（2）以人员为中心的统计分析。见表8-7。以项目

20、为中心的统计说明项目信息汇总汇总每个项目的立项信息，项目人员表，工作量统计，任务进度统计，成本统计，缺陷统计，风险统计。项目人员表统计每个项目的人员、角色、工作起至时间。项目工作量统计统计每个项目的总工作量，每个工作类型对应的工作量百分比，绘制统计图。项目任务进度统计统计每个项目的计划和实际的“工作量、进度”等信息，绘制统计图。项目成本统计统计每个项目的预算和实际开支。项目缺陷统计统计每个项目的缺陷（按状态，类型，严重性），绘制统计图。项目风险统计统计每个项目的风险的严重性、状态、风险类型等信息，绘制统计图。以人员为中心的统计说明人员项目表显示每个人员参加的所有项目，在项目中的角色和工作时间。人员工时表显示给定时间段内每个人的工时表（每天工作量）。人员进度表绘制给定时间段内每个人的任务进度表。表8-7 IDP的统计分析表提示：集成化研发管理平台RDMS中的“统计分析工具Analysis”满足IDP的统计要求。