|
| « | Mar.2026 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | |
|
公告 |
| 暂无公告... |
| Blog信息 |
|
blog名称:Topiemie's Blog
日志总数:17
评论数量:19
留言数量:2
访问次数:102196
建立时间:2005年1月6日 |
| |
|
 [.Net学习]软件开发过程规范
文章收藏, 电脑与网络
二休 发表于 2005/1/7 22:10:09 |
|
软件开发过程规范第一部分 概述1 目的本规范的目的是使整个软件产品开发阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化，有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。2 适用范围本规范适用于公司范围内所有以正式的项目形式进行的软件产品的开发；不包括需求获取、现场调试等内容。本规范分为两个部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。3 过程模型本规范所采用的软件开发过程模型为裁剪的RUP开发过程模型。4 环境建模语言 采用UML作为建模语言建模工具 采用Rational Rose作为建模工具配置管理工具 采用SourceSafe/Cvs作为配置管理工具，由项目经理根据具体情况自行决定。变更和缺陷管理工具 采用ClearQuest作为变更和缺陷管理工具需求管理工具 采用RequisitePro作为需求管理工具单元测试工具 推荐使用Purify、Quantitify、PurifyCovervage、BoundChecker等工具，具体选择何种工具由项目经理自行决定。引用规范 《C++编码规范》指南 《需求建模指南》、《分析指南》、《设计指南》、《实现建模指南》、《数据库建模指南》5 角色划分与组织机构 软件过程的每一个活动都由具体的角色执行；本过程所涉及的角色和组织机构及其职责如下：系统分析员 管理需求 查找参与者和用例 确定性能要求 建立用例模型结构用例工程师 详细说明用例 详细说明软件需求 用例分析 用例设计需求复审员 复审需求用户界面设计员 设计用户界面原型 确定边界类 * 一般界面设计员不参与界面部分的实现构架设计师 确定需求优先级 构架分析 构架设计 构架实现 制定和组织学习编码规范设计员 类的设计 子系统设计 数据库设计员 生成数据模型设计复审员 复审设计 构架复审员 复审构架程序员 实现构件 调试 单元测试 实现测试 开发安装软件代码复审员 复审代码（该角色可以由技术监督小组成员兼任）测试员 制定测试计划 设计测试 执行测试 评估测试配置管理员 建立变更控制流程 复审变更请求 确认重复或拒绝的变更请求 管理基线流程工程师 编制开发案例 启用开发案例项目经理 制定软件开发计划 制定迭代计划 制定风险管理计划 协调项目运行项目复审与变更控制委员会 该委员会是负责监督项目和控制变更的行政管理团队；在执行复审任务时，可由该委员会主席指派专人（项目复审员）负责。建议该委员会由项目经理、构架设计师、需求提供方及有项目审批权限的3~5人组成，其中主席一职应当在需求和技术方面都有一定权威性。主席根据实际需要召开会议评估变更请求，对项目进行审批和项目计划复审。该委员会有三个基本任务：变更控制明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。由他们批准对已建立基线的配置项的所有变更。该团队的目的在于确保所有提出的变更都得到了妥善的技术分析与复审，并已记录备查。项目审批与计划复审项目审批；项目计划复审；迭代计划复审。验收复审迭代验收复审；生命周期里程碑复审；项目验收复审；
技术监督小组 与项目经理一起监控小组技术状态，建议每周由研发人员轮流执行技术小组组长职责，定期负责召开技术讨论会，审查上周进展情况及技术状态（软件模型完整性、代码规范性等内容），讨论本周工作计划、技术问题等内容并监督各规范的执行情况。6 制品该部分列出了工作流程所涉及的制品及这些制品的格式。（该部分的表格不太容易画，若有需要该部分的同志，可以向我索取ZXHSCOTT@SINA.COM）(第一部分结束)
第二部分 管理过程规范 管理规程规范分为两个部分：项目管理过程规范、配置与变更管理过程规范。7 项目管理过程规范7.1 过程概述项目管理过程如下图所示 500)this.width=500'>管理过程贯穿于软件开发过程的始终，它也随着开发过程的迭代进行自身的迭代。7.2 项目准备7.3 7.3.1 概述项目准备活动在软件开发过程中只进行一次，即在项目初始阶段的第一个迭代中，而且它是最早进行的活动。500)this.width=500'>7.3.2 确定并评估风险执行角色项目经理活动描述项目经理 确定潜在的风险，分析风险、确定风险的优先级并制定风险规避和降低策略，填写《风险列表》；制品《风险列表》（草拟）7.3.3 启动项目执行角色项目经理活动描述指派项目复审与变更控制委员会成员； 由项目复审与变更控制委员会正式任命项目经理；指派项目计划团队（项目计划团队是将要执行先启阶段工作的项目团队初始成员。计划团队由项目经理和项目复审与变更控制委员会共同确定、批准和指派。通常，项目计划团队可能会包括项目经理、构架设计师、系统分析员、开发负责人、测试负责人、配置管理员、领域专家）；已正式或非正式的形式规定技术监督小组及组长的任命规则；批准项目验收标准，对于有明确合同要求的软件项目，合同的要求可以作为验收标准；由以上内容形成《软件开发计划》的“组织结构”部分；制定用于初始阶段的第一次迭代的迭代计划，形成《迭代计划》；制品《软件开发计划》初稿；初始阶段第一次迭代的《迭代计划》。7.3.4 定义项目组织与人员配备7.3.5 执行角色项目经理活动描述项目经理决定项目组的梯次，即管理、需求、分析设计、质量保证等，并决定每个梯次所需的角色和职责。对于规模较小的项目，项目经理可以直接定义所需人员的数量、人员的技能，将该部分内容写入《软件开发计划》的“人员配备计划”部分。制品更新的《软件开发计划》；7.3.6 制定质量保证计划执行角色项目经理活动描述确保制定了项目的质量目标（项目经理部需要制订质量目标，但应确保已经由该目标存在）；确定质量保证角色与职责；确定质量保证任务与时间表，质量保证活动主要指各种复审，即计划复审和验收复审；形成《质量保证计划》；制品《质量保证计划》；7.3.7 计划阶段和迭代执行角色项目经理活动描述定义项目阶段里程碑；定义里程碑目标；定义阶段内迭代的数量、长度和目标（确定将为每个项目阶段安排多少次迭代、确定分配给各次迭代的相对工作量、确定每次迭代的目标）；改进里程碑日期和规模（根据在先启阶段结束时获得的信息来对估计加以改进）；确定项目资源需求（确定角色及数量），定义该项目所需的资源数量和类型（按阶段/迭代分配）；根据以上内容更新《软件开发计划》。
制品更新的《软件开发计划》；7.3.8 制定软件开发计划执行角色项目经理活动描述根据以上内容形成《软件开发计划》。
制品更新的《软件开发计划》；7.3.9 编制开发案例执行角色流程工程师活动描述根据项目的性质、进度要求等形成《开发案例》；制品《开发案例》7.3.10 项目计划复7.3.11 审执行角色项目复审员活动描述安排召开项目计划复审会议的时间；分发会议材料（风险列表、软件开发计划）；召开项目计划复审会议；根据复审会议的决定形成《复审记录》。制品《复审记录》7.4 计划下一次迭代7.4.1 概述对下一次迭代进行规划。500)this.width=500'>7.4.2 计划下一次迭代执行角色项目经理活动描述确定迭代的范围，即确定哪些用例需要优先实现、哪些非功能要求需要优先考虑；定义迭代活动，即根据以上确定的范围确定要执行的活动集（核心工作流中的那些部分）；确定该次迭代要产生的制品；将这些职责与人员对应；形成《迭代计划》；
制品《迭代计划》7.4.3 制定软件开发计划执行角色项目经理活动描述改进里程碑日期和规模，制定更准确的阶段计划（要考虑已确定的用例数量、已确定的用例复杂性、已确定的风险等）；制品更新的《软件开发计划》；*注：该活动并非必需的7.5 管理迭代7.5.1 概述进行迭代日常的管理。500)this.width=500'>7.5.2 人员配备7.5.3 执行角色项目经理活动描述将人员与角色对应；任命技术监督小组组长和其他组员；将对应关系写入《软件开发计划》的“人员配备”部分；制品更新的《软件开发计划》；7.5.4 启动迭代执行角色项目经理活动描述将人员分配给工作包；获取并分配非人员资源（例如工位、计算机等）；发出工作单；制品《工作单》；7.5.5 评估迭代执行角色项目经理活动描述评估迭代结果，检验是否已实现迭代目标，书写《迭代评估》；考虑外部变更，拟定《变更请求》；制品《变更请求》；7.5.6 迭代验收复7.5.7 审执行角色项目复审员活动描述安排召开项目计划复审会议的时间；分发会议材料（风险列表、软件开发计划）；召开项目计划复审会议；根据复审会议的决定形成《复审记录》。制品《复审记录》；7.6 监测与控制项目7.6.1 概述该活动主要是监控项目变更，处理变更请求；并非所有的变更都需要正式向项目复审与变更控制委员会提交并复审；一般影响较小的变更，比如轻微缺陷的修复可以由项目经理直接决定。500)this.width=500'>7.6.2 检测项目状态执行角色项目经理活动描述根据《迭代计划》和《软件开发计划》对项目的状态（包括进展、风险化解情况等）进行检测，并通过各种方式向项目复审员汇报。制品无；7.6.3 安排和分配工作执行角色项目复审员活动描述将变更请求分配到迭代（一般重要的扩展请求会被延期到下一个迭代甚至更迟的迭代中，而缺陷修复一般在本次迭代中完成）；分配职责；说明工作和预期结果；制定时间表；如果必要，修改当前迭代计划，并在软件开发计划中反映出对将来迭代的影响；发出工作单；制品《工作单》；7.7 确定并评估风险执行角色项目经理活动描述项目经理 确定潜在的风险，分析风险、确定风险的优先级并制定风险规避和降低策略，填写《风险列表》。制品《风险列表》（更新）7.8 阶段收尾7.8.1 概述该活动仅在阶段收尾时执行。 7.8.2 为阶段收尾做准备7.8.3 执行角色项目经理活动描述检查所需工件的状态；向涉众交付制品（具体制品见“附录一 项目里程碑”）；制品《软件开发计划》（交付）；《状态评估》（最近的迭代形成的，交付）；《迭代评估》（最近的迭代形成的，交付）；7.8.4 生命周期里程碑复7.8.5 审执行角色项目复审员活动描述安排生命周期里程碑复审会议日程；分发会议材料；召开生命周期里程碑会议；记录决定；制品《复审记录》；7.9 项目收尾7.9.1 概述该活动仅在项目收尾时执行。 7.9.2 为项目收尾作准备7.9.3 执行角色项目经理活动描述为活动安排时间表，此时间安排表应包含在软件开发计划中；进行项目事后检查复审；完成验收操作项；项目收尾；制品《软件开发计划》（交付）；《状态评估》（最近的迭代形成的，交付）；《迭代评估》（最近的迭代形成的，交付）；7.9.4 项目验收复7.9.5 审执行角色项目复审员活动描述安排项目验收复审会议的日程；分发会议材料；召开项目验收复审会议；记录决定；制品《复审记录》；8 配置与变更管理过程规范8.1 过程概述配置与变更管理过程如下图所示，其中前两个活动，即“计划项目配置与变更控制”和“创建项目CM环境” 主要在项目开发开始时调用，其他工作流程根据软件开发生命周期的进展情况进行调用。500)this.width=500'>8.2 计划项目配置与变更控制8.2.1 概述500)this.width=500'>8.2.2 制定CM策略执行角色配置管理员活动描述确定配置标识方法；确定建立基线方法：建立基线的里程碑、建立基线标记；确定产品目录结构；确定备份保存方法；确定配置状态报告需求：选择基于变更请求的报告、确定报告频率；制品无。8.2.3 建立变更控制流程执行角色配置管理员活动描述建立变更请求流程：（1）完成变更请求单，提交变更请求（2）分析、评估变更请求（3）分配角色解决变更请求（4）保存变更历史记录制定变更复审通知协议；制品《配置管理计划》。8.2.4 编写CM计划执行角色配置管理员活动描述编写CM计划；复审并批准CM计划；维护CM计划；制品《配置管理计划》。8.3 创建项目CM环境8.3.1 概述500)this.width=500'>8.3.2 设置CM环境执行角色配置管理员活动描述编设置硬件环境；根据配置管理计划在项目储存库上建立产品目录结构；制品项目储存库。8.3.3 创建集成工作区执行角色配置管理员活动描述在配置管理员设置好项目储存库后，创建集成工作区；制品集成工作区。8.4 交付与变更配置项8.4.1 概述500)this.width=500'>8.4.2 创建开发工作区执行角色任意角色活动描述任意角色在开始进行自己的日常工作前，应该在设置好的项目储存库上创建自己的开发工作区；制品开发工作区。8.4.3 进行日常开发执行角色任意角色活动描述根据项目经理分配的工作单在自己的开发工作区上进行日常开发与变更工作，这些工作包括：检出、检入、添加、交付、更新工作区；制品更新的开发工作区。8.4.4 交付开发执行角色任意角色活动描述完成分配工作单上工作内容后，向集成工作区交付开发（变更）内容，这些工作包括：从开发工作区检出，并检入到集成工作区、通知其他人员；制品更新的集成工作区。8.4.5 更新开发工作区执行角色任意角色活动描述根据配置管理员的通知，从集成工作区check out其他人员的工作内容更新自己的开发工作区；制品更新的开发工作区。8.4.6 建立基线执行角色配置管理员活动描述根据任意角色交付的已完成工作单，从开发工作区check in他的工作内容到集成开发工作区，并建立基线，同时通知其他人员更新自己的开发工作区；制品基线。8.4.7 晋升基线执行角色配置管理员活动描述当产品达到一定的成熟度、稳定性或质量级别，或某个里程碑，集成员与项目经理协商后可以晋升产品基线，这些工作包括：确定基线标记、在集成工作区晋升基线；制品基线。
8.5 管理基线与发布8.5.1 概述500)this.width=500'>建立基线和晋升基线同上。8.5.2 创建部署单元执行角色配置管理员活动描述配置管理员根据材料清单所列出的可交付工件从项目储存库中创建工件的拷贝；配置管理员在项目储存库中对可交付工件建立或晋升基线；制品部署单元。8.6 审核报告配置状态8.6.1 概述500)this.width=500'>8.6.2 报告配置状态执行角色配置管理员活动描述根据配置管理计划中规定阶段和时间报告统计项目储存库中配置项状态的变化，并给出量化的配置报告（可以由ClearQuest直接生成）；制品《配置状态报告》。8.6.3 执行配置审核执行角色配置管理员活动描述物理配置审核：准备一份开发案例中给出的所有工件的列表审核产品目录结构包含每一个工件报告结果功能配置审核：列出产品功能审核每项功能是否都有一个测试结果报告结果制品《配置审核结果》。8.7 管理变更请求8.7.1 概述500)this.width=500'> 变更会对项目项目产生影响，尤其是扩展性的变更以及需求的其他变更往往会对项目产生较大的影响。当这种变更出现时应当严格遵循该过程。较小的变更，尤其一些修复性的变更，项目经理可以自行组织处理。8.7.2 提交变更请求执行角色任意角色活动描述完成变更请求单提交变更请求，变更请求单状态为已提交制品《变更请求单》（已提交）。8.7.3 更新变更请求执行角色任意角色活动描述接收变更请求表单（已重复或已拒绝）更新并重新提交变更请求制品《变更请求单》（已更新）。8.7.4 复8.7.5 审变更请求执行角色项目复审与变更控制委员会活动描述准备要复审的变更需求；安排召开复审会议的时间；复审已提交的变更请求；制品《变更请求单》（已复审）。8.7.6 确认重复8.7.7 活拒绝的变更请求执行角色项目复审与变更控制委员会活动描述准备经复审怀疑认为重复或已拒绝的变更请求；指定CCB代表确认重复或拒绝的变更请求；更新变更请求状态：（1）已确认重复或拒绝的变更请求应该关闭，同时通知变更请求提交者；（2）要求提交者提供更多信息，或更新变更请求信息，说明不是重复或拒绝的理由，重新提交以备CCB复审；制品《变更请求单》（已拒绝）。
第三部分技术过程规范
本规范中将软件开发的整个技术过程分为五个顺序实施的工作流程，分别为需求、分析、设计、实现和测试。在一次迭代过程中，这五个工作流程从总体上是顺序的，但彼此之间又存在交叉和重叠。9 需求
9.1 管理需求执行角色系统分析员活动描述通过访谈、问卷、审阅合同等形式收集用户需求；通过走查等非正式形式评估需求收集结果，确保无需求重复、不一致、不清晰等问题；*对于需求的变更请求，此时的变更请求应当已经过变更控制与项目复审委员会复审，可直接作为正式的需求；在模型元素与需求之间建立可追踪性链接；建立需求属性；制品需求集；9.2 查找参与者和用例执行角色系统分析员活动描述命名并简述已发现的主角；命名并简述已发现的用例，概述事件流并收集非功能性需求（记录在《增补需求》中）；形成用例模型（描述用例间的关系并将参与者和用例打包）；制品用例模型（概要的）；《增补需求》；9.3 排列用例优先顺序执行角色构架设计师活动描述一般根据用例的重要性、风险来确定用例优先级；优先级可用数字表示，该数字表示该用例在那一次迭代中实现；优先级也可以用关键、重要、辅助等级来表示；制品用例模型（更新的）；9.4 详细说明用例执行角色用例工程师活动描述建模某用例与其他用例、用例与参与者的关系；详细说明用例事件流；制品用例（详细说明的）；《SRS》；9.5 原型化用户界面执行角色用户界面设计员活动描述用各种界面元素形成用户界面原型；制品用户界面原型；9.6 组织用例模型执行角色系统分析员活动描述描述用例间的关系（包含、扩展、泛化），优化用例模型；制品用例模型（结构化的）；9.7 复9.8 审需求执行角色需求复审员活动描述正式核实需求结果符合客户对系统的看法，建议召开复审会议，复审如下内容：影响现有需求集的变更请求；整个用例模型；对用例及其图表的复审（适合每个用例）；制品《复审记录》；10 分析
10.1 构架分析执行角色构架设计师活动描述编写构架概述，采取了使用大量图片、示意板或图标化图形的非正规形式来对构架进行概述，这部分工作通常只在项目早期进行；定义子系统的高层组织，在构架分析中通常侧重于两个高层层次，即应用程序层和业务专用层；根据该层次组织形成分析包，将一些紧密联系的用例分配给一个具体包，然后在该包中实现相应的功能，确定服务包，同一服务包中的分析类都用于相同的服务；确定明显的实体类；确定特殊需求，如分布与并发、永久性机制、安全性机制等；制品分析包（概要的）；实体类（概要的）；分析模型；10.2 用例分析执行角色用例工程师活动描述确定边界类、实体类和控制类；为每个由人或其他系统充当的参与者确定一个主要的边界类；将参与某个用例实现的分析类收集到一个类图中；描述分析类间的交互（主要用协作图实现）；确定每个用例实现的所有需求（非功能性需求）；制品分析类（概要的）；用例实现-分析；10.3 形成分析类执行角色设计员活动描述确定分析类的职责，可以用类的成员函数来表示，但仅仅是概念上的；确定分析类的属性，可以用类的成员变量来表示，但仅仅是概念上的；确定分析类间的关系；确定分析类特殊需求；制品分析类（完整的）10.4 形成分析包执行角色设计员活动描述将相关性较强的分析类打包成一个分析包；包间应遵循高内聚、低耦合的原则；制品分析包（完整的）10.5 分析复10.6 审不要求正式复审，但应当对分析过程的制品进行检查执行角色建议由构架设计师执行活动描述检查或复审分析类、分析包、用例实现-分析、分析模型；制品无11 设计
11.1 构架设计执行角色构架设计师活动描述识别节点和网络配置，将这些元素映射到实施模型；识别子系统及其接口（一般来讲一个子系统映射到一个分析包，子系统对应到一个可执行构件）；识别对构架有重要意义的类（不要设计细节，数目不要太多），识别主动类（进程和线程），考虑并发要求，将这些主动类分布到具体的节点上；制品子系统（概要的）；接口（概要的）；设计类（概要的）；实施模型（概要的）；构架描述（设计模型和实施模型视图）；11.2 用例设计执行角色用例工程师活动描述识别设计类，使用类图来表示参与某一用例的类；描述设计对象间的交互（可以用序列图来表示对相间的交互）；识别参与的子系统和接口；描述子系统间的交互作用（用序列图）；捕获实现性需求（非功能性需求）；制品子系统（概要的）；接口（概要的）；设计类（概要的）； 用例实现-设计；11.3 形成设计类执行角色设计员活动描述根据分析类或接口来勾画一个设计类：边界类à用户界面类；实体类à数据库管理类；控制类à一个或一组类；识别操作（跟踪分析类的职责、分析类的非功能性需求及接口）；识别属性；识别类之间的关系；要对方法进行描述，尤其要对复杂的方法进行详细描述，可以由自然语言或伪码进行描述，也可以用状态图进行描述；对于状态控制的设计对象，可以用状态图进行描述；制品设计类（完整的）；11.4 形成设计子系统执行角色设计员活动描述形成设计子系统；形成设计子系统的接口；制品子系统（完整的）；接口（完整的）；11.5 数据库设计执行角色数据库设计师活动描述在组件视图中创建数据库模型；在逻辑视图中创建方案，将该方案分配给数据库；在该方案中创建对象模型视图；在方案中创建表、视图等；在表中创建列；在数据模型视图中创建表之间的关系；为数据库分配存储过程、触发器等行为；制品数据模型；11.6 复11.7 审设计执行角色设计复审员活动描述复审设计模型总体，在先启阶段和精化阶段的早期，总体复审着重检测模型的整体结构，尤其重点检查分层和接口；复审每个用例实现；复审每个子系统（及其内容）或类（如果系统很小）；制品无；11.8 复11.9 审构架执行角色构架复审员活动描述进行软件构架评估的最佳时机就是在精化阶段结束的时候。该阶段主要集中在对需求进行详尽研究，并建立构架的基线。构架复审由在该阶段的里程碑的流程确定。在此情形下，可以进行大范围的构架质量检查。制品无；
12 实现 12.1 构架实现执行角色构架设计师活动描述确定在生命周期早期对构架有重要意义的构件，以启动实现工作；建立实现模型；把可执行构件映射到节点上；制品实现模型；构件（概要的，可能被映射到节点上）；构架描述（实现模型和实施模型的视图）； 12.2 制定集成构造计划执行角色任意角色活动描述计划应实施哪些子系统，以及在当前迭代中按照什么顺序集成子系统；根据一个完整的用例实现寻找要实现的构件并分配给不同的构造；制品实现模型；《集成构造计划》； 12.3 实现一个子系统执行角色程序员活动描述当前构造所需的子系统内的每个类应当由实现子系统中的构件来实现；当前构造所需的子系统的每个接口也应当由实现子系统实现；制品实现子系统（已完成设计的）； 接口； 12.4 实现一个类执行角色程序员活动描述实现成员函数；制品构件（完整的）； 12.5 单元测试略。12.6 集成系统执行角色任意角色活动描述验证工作版本并晋升基线；制品工作版本（更新的）； 12.7 复12.8 审代码执行角色代码复审员（可以由技术监督小组成员兼任）活动描述走查/审查代码是否符合《编码规范》，提出更改/返工意见；制品无；13 测试
13.1 制定测试计划执行角色测试员活动描述确定测试需求，包括功能性需求（参与测试的用例）和性能需求；确定测试优先顺序，一般分为：H - 必须测试 M - 应该测试，只有在测试完所有 H 项后才进行测试 L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试；制定测试策略；确定测试资源，包括人员、测试环境等；制定测试进度；形成《测试计划》；制品《测试计划》；13.2 设计测试执行角色测试员活动描述确定并说明测试用例，测试用例应考虑分支情况；构造用户说明如何执行测试用例的测试规程（若测试用例足够详细，测试规程可以省略）；制品测试用例；《测试规程》；13.3 实现测试执行角色程序员活动描述该部分主要用来产生测试构件以使测试自动化；该部分常用来产生测试数据、显示测试结果等；该步骤不是必需的；制品测试构件；13.4 执行集成测试执行角色测试员活动描述对当前构造的每一个用例执行测试规程，或运行测试构件自动执行测试规程；将测试结果与预期结果比较；记录并提交缺陷；制品缺陷；13.5 执行系统测试执行角色测试员活动描述与集成测试类似；制品缺陷；13.6 评估测试执行角色测试员活动描述分析测试结果并提交变更请求；评估基于需求的测试覆盖；评估基于代码的测试覆盖；确定是否达到了测试的完成标准和成功标准；生成测试评估摘要；制品《测试评估摘要》；
版权声明：CSDN是本Blog托管服务提供商。如本文牵涉版权问题，CSDN不承担相关责任，请版权拥有者直接与文章作者联系解决。
发表于 2004年10月21日 9:01 PM
-->
评论
# 回复：软件工程过程规范（裁剪的RUP）第三部分（技术过程） 2004-10-26 3:17 PM twirk
要是有详细的Pdf文档下载就好了！当然了，如果有具体的例子就更好了。
# 回复：软件工程过程规范（裁剪的RUP）第三部分（技术过程） 2004-11-02 3:03 PM dear_book
电话：010-82645151 详情参见：www.f c s o f t.com.cn 什么是eform开发平台? eform是基于浏览器的表单自定义工具,eform是页面设计工具,eform内含大量构件.不用写一行代码便能用eform开发出来常见的功能点. 使用eForm平台有如下好处: 1、用eform平台开发能降低开发人员的技术门槛,使很低水平的人就能开发一个软件项目中常见的功能.例如数据库的数据增删改查打印等等,而这部分功能往往也占居了一个软件项目的大部分.这样一个软件项目开发成员中可以有一大部分人是中专生甚至是高中生就能胜任.从而大大降低了整个软件项目的开发成本.另一方面因为低水平的开发人员很容易招聘到,这样也使软件项目更加容易完成. 2、用eform平台开发的代码一致性比较好,以后维护升级方便.因为只有个性化的功能才需要编写事件代码.所以代码量很少,大量的调用底层的代码,这样代码的集成度高.以后维护升级时修改的代码量非常少. 3、用eform平台开发能大大提高开发效率.eform平台采用对常见的功能和控件内置的方法,使得开发一些常见的功能(如数据库的增删改查,树控件,表格控件)非常容易方便.几乎不用写一行代码.直接通过控件的拖拉然后再设置属性和事件即可完成.开发程序的工作就象是打字员的工作一样.(如图所示开发效率对比示意图) 4、用eform平台开发能很好地应对软件开发项目成员的流动的问题.因为程序员的离职而造成整个项目瘫痪的事例很多.而用eform平台,因为大家都是采用同一模式开发的表单,因而一个人开发的表单很容易被另一个人看懂和使用.这样就使开发人员的流动造成的影响大大降低.企业不再受制于人. 5、用eform平台开发可以使项目不再没完没了,无法关闭.因为可以培训最终用户中的精英,让他们掌握eform平台的使用方法,这样大多需求他们便可以自己做好,而不用麻烦软件开发商了. eform的设计思路是将数据库程序开发中常用的控制或功能点在eform平台中设计好,通过简单的设置参数或属性即可调用.而遇到很个性化的功能点则可以用传统的代码方式进行开发.因为一个数据库程序开发中大量是增,删,改,查,打印,报表,图表,数据校验等常见的功能点,而这些功能点在eform平台中都做好了,只要简单地设置一下即可完成这些功能点,而且这个设置过程也是可视化的,有相应的设置界面.这样做这些常见的功能点就非常简单快速.而少量的特别的功能点又可通过写代码的方式来完成.也就是说在一张表单中可以一部分功能是直接通过简单的设置一下来完成,另一部分功能是用代码来硬写出来的.这样就达到了常见的功能可以直接调用eform底层的api来实现以提高开发效率,但一个表单又不限定只能实现这些常见功能,你也可随意地用代码来进行无限扩充.这样就达到了既提高了开发效率又能实现很复杂的功能. eform开发平台分为eform.j2ee和eform.net两个版本.eform.j2ee是用java编写的,面向j2ee应用.eform.net是用.net编写的,面向.net应用.实际上整个eform开发平台共有三部分的代码,① 一部分是htc js dhtml等前台的代码,② 一部分是java的代码,③ 一部分是.net的代码(c#语言的),其中java的代码完成的功能和.net的代码完成的功能完全相同.用①和②就组成了eform.j2ee版本,用① 和③ 就组成了eform.net.这样就得到了两个版本.由此可知,eform.j2ee和eform.net的接口和操作是完全相同的.只是运行环境和使用的编程语句不同罢了.这样做的好处是当需要从j2ee平台转到.net平台或是从.net平台转到j2ee的平台时,使用eform编写的表单和程序可以完全保留下来直接使用.可以轻松地跨越当今两大主流的开发平台. 使用eform开发平台开发出来的表单可以直接在浏览器中运行,不但如此,而且其设计工具也是在浏览器中运行的.也就是说,开发人员也是在IE中(拖拉控件)开发的.开发人员再也不用为了搭建开发环境而装一大堆软件了,这一点对于远程协作开发非常有利. eform内置了常见的大量的开发构件,如树控件,表格,图表控件,打印控件,上传控件,查询等,也内置了象单表输入,一对多表输入等常见的数据库程序的功能点.通过使用这些可以大大提高开发的速度,降低开发这些常见功能的门槛,只需知道很少的知识便可以开发.使用eform生成的表单结构和格式一致,非常便于以后的维护升级. eform开发平台开发出来的表单可以脱离eform平台单独运行,也很容易和其它程序进行集成.一个项目的程序往往是大量常用功能用eform平台开发,而少量功能用其它方式开发.然后把它们集成在一起而成的. eform开发平台是专门为软件开发商或需要开发数据库程序的人而设计的.它采用开放版权的销售方式.对于用户开放100%的源代码,也就是说将eform开发平台的源代码全部提供给用户,同时还包括相应的开发文档和典型示例都提供给用户,而且用户用eform开发平台开发出来的程序可以自由分发.用户购买了eform后,就相当于eform是自己开发出来的一样.而且北京 方 成公司还提供一年的免费服务和技术支持. eform的销售没有任何加密和license之说.是一种特别的销售方式.销售的过程实际上是完成知识和价值的转移的过程.相当于方成公司帮用户开发了一个平台然后再帮助用户把它使用起来,用户使用eform开发的软件可以自由销售,和方成公司没有任何关系,更不需要再收费用.由此可见,购买eform和自已招聘员工开发一个平台相比,无论是时间还是费用以及风险都是购买eform比较合算. |
|
|