软件开发规范整体规范

《软件开发规范整体规范》由会员分享，可在线阅读，更多相关《软件开发规范整体规范（37页珍藏版）》请在装配图网上搜索。

1、软件开发标准Software Development SpecificationVersion: V1.0Date: 2021-06-22Prepared byDocument Revision History文档修订记录VERSION版本DATE日期DESCRIPTION内容说明INDIVIDUAL修订人2021-06-22初稿Table of Contents目录1Introduction 简介5Purpose 目标5Scope 范围6Definitions, Acronyms, and Abbreviations. 术语，缩略词6References 引用7Overview 文档组织72

2、The Overall Description 概述8Software Development Organizing 开发团队组织结构8Project Base Process 工程根本流程9CMM Base Process CMM根本过程10SCM软件配置管理10SPP 方案筹划12SPTO工程追踪15PR同行评审17SQA质量保证18SDLC 生命周期选择19Development Process 开发过程20Development Phase 开发阶段20Phase Product 阶段制品21Role Duty 角色职责22Constraints 限制233Specific Requi

3、rements 详细描述24Precondition 前提24SCM配置库24Test Environment 测试环境25Development Control Process 开发控制流程25工程启动和筹划阶段26需求分析、设计、编码阶段26提交测试阶段26生产发布、终测27发布后问题反应修改正程27TSP 团队软件过程29会议组织29沟通问题29代码走查29其它30PSP 个人软件过程30工作原那么30日常工作30DE 开发工程师31SCME 配置管理员32DBA 数据库管理员32Deployer 发布人员334Tool Specification 工具标准33通用工具33方案33需求分

4、析34设计34编码34测试345Documents 文档35工程管理文档35工程筹划35工程追踪35质量保证35工程终止35开发过程文档35软件配置管理35会议管理36方案跟踪36评审管理36质量管理36测试过程36问题解决过程36其他376Appendix 附录37易于理解的代码37Log输出371 Introduction 简介 一个成熟稳定的组织或者团队，能够减少风险，经常地成功地达成目标。成功的含义是：按时、预算内【即符合本钱要求】、符合质量要求。换言之，成熟稳定的团队，能够防止以下问题： 组织方面出现问题 对需求缺乏管理 缺乏方案和控制 估算错误同时，还要在以下几个方面做得比拟出色：

5、 人员调度与工作安排 工作量估计 预算管理 责权分配与平衡 执行与监控 沟通本文档是软件开发标准，力求使团队打下一个良好的根底，以便逐步成长为成熟稳定的团队。团队需要一个逐步标准、标准的开发过程，在这个过程中，团队得到锻炼，成员能力得到提高，风险得到控制。主要内容是： 定义软件开发的流程； 定义软件开发的文档格式； 定义涉及的角色； 定义涉及的信息； 描述开发流程；1.1 Purpose 目标本文档的目标是： 统一软件开发团队的流程、文档； 促进团队成员的沟通，减少误解； 促使程序员书写易维护的代码； 提高代码编写效率； 使每个成员成为一个高效的程序员；1.2 Scope 范围本文档，包含：

6、工程管理的流程；n 工程筹划n 工程追踪n 配置管理n 质量保证n 同行评审 涉及文档；n 工程方案mppn 需求规格说明书SRSn Delphi估算n 工程状态报告n 配置库样式n CheckListn 评审表n 变更申请表 开发工具的标准；n 数据库设计工具n 功能设计工具n IDEn 配置工具1.3 Definitions, Acronyms, and Abbreviations. 术语，缩略词 SPP工程筹划Software Project Planning SPTO工程追踪Software Project Tracking & Oversight SCM配置管理Software Co

7、nfiguration Management SQA质量保证Software Quality Assurance PR同行评审Peer Review BaseLine 基线 SCCB软件配置控制委员会Software Configuration Control Board CR变更请求Change Request SDLC软件开发生命周期Software Development Life Cycle RUP统一开发过程Rational Unified Process XP极限【敏捷方法】eXtreme Programming TDD测试驱动Test Driven Development1.4

8、References 引用 ?CMM2?CMM3?1.5 Overview 文档组织 本文档主要分为四大局部： 概述；描述了团队组织开发过程的高层视图； TSP和PSP；按照团队和个人描述流程标准； 工具标准；描述了开发工具的详细标准； 文档；涉及的文档格式；2 The Overall Description 概述 本局部是开发团队开发过程的高层描述。它描述了开发过程标准的背景，用来和所有涉及各方就根本过程达成共识。2.1 Software Development Organizing 开发团队组织结构说明： 表示公司的行政部门 表示公司的逻辑部门 实线表示参加产品实现的组织和人员不表示所属关

9、系 虚线表示工作的汇报关系，如SQAE向SQA经理汇报。2.2 Project Base Process 工程根本流程识别需求提出解决方案执行工程结束工程投入力量可行性分析报告需求建议书合同工程目标 工程定义 制定方案 方案实施 工程终止时间根本流程说明： 工程启动： 本阶段主要是进行可行性分析，定义工程，识别需求； 制定方案： 本阶段主要是方案筹划，估算工作量，制定具体的可执行的方案； 方案实施： 本阶段主要是实施方案，完成方案中的各项任务，报告方案状态； 工程终止： 方案执行完毕，总结工程；2.3 CMM Base Process CMM根本过程SCMSQAWork AreaBaseLin

10、eSPPSPTOPRChange & PR根本过程说明： SCM： 软件配置管理，所有活动的根底，一切制品必须放入配置库； SPP： 软件工程筹划，估算工作量，制定详细方案【工程的制定方案阶段】； SPTO：工程追踪，报告工程状态，评估并更新方案【工程的方案实施阶段】； PR： 同行评审，进入基线的前提条件，降低风险，提高质量的有效手段； SQA： 质量保证，预防风险的有效手段；2.3.1 SCM软件配置管理配置管理主要解决： 版本 变更确定配置项和基线确定记录和报告配置项状态策略定义配置项定义访问权限访问权限确定配置管理工具确定SCCB成员确定配置库及其目录结构工程启动确定配置管理人员Vss

11、、SVN或VSTS一般由：工程经理、技术经理、客户经理、质量保证人员、配置管理等工程的核心成员人员组成。在配置项基线生成和基线变更时配置库结构权限表基线表确定基线变更过程定义备份与病毒策略按方案执行配置管理活动SCM方案制定和评审记录和报告基线的状态在配置项基线生成和基线变更时至少在工程的每个里程碑结束时进行备份1建立配置库2对工程组指导和培训3对配置项的日常管理4参加评审会议5定期备份和病毒防护6实施发布7进行归档8配置管理方案的维护配置管理情况总结方案完成总结配置项是否完整、基线的变化情况统计、审核发现问题情况统计、改良建议等，记入工程总结报告 定义测试和发布归档方式SCM方案配置审核状态

12、报告审核报告2.3.2 SPP 方案筹划方案筹划的核心是工作量估算从历史库中识别可用的信息工程启动从公司的数据中识别工程相似的信息，如工程的总结报告和其它的数据或文挡工程需求、合同以及?软件工程任务书?等相关要求选择工程生命周期识别工程的特点了解各个生命周期的特点确定适合工程生命周期模型从对用户需求的理解是否充分；人员介入工程的方式；产品的交付方式；工程规模大小和风险上下；对工程系统架构的理解是否充分等方面考虑RUPXPRUPXP依据定义的过程，识别必须完成的任务和工作产品分解时考虑的活动事项要详尽，不要漏掉：教育或培训的需要；参与评审文档；参与工程会议；确定、记录和显示各种与质量相关和与过程

13、相关的数据；传播时间文档制品如：方案、SRS等规模估算制定工作产品的评审方案估算表估算结果评审方案识别工程需要使用的工具和设施风险评估识别与其他组之间的关系确定工程的跟踪情况确定工程的组织结构和职责识别工程需要进行的培训制定时间进度表在的停工和节假日时间不安排工作；不考虑加班时间；考虑测试及评审中发现问题的返工需要的时间；考虑客户需求的稳定情况；考虑各项活动的交接和信息的传递时间；识别出的风险对活动的影响；在安排工作时应考虑整个工程的效率因素，在正常估算的工期内增加2040的余量，分配到工程的所有活动中特别是关键路径中的活动中工具指南风险表协同工作方案工程跟踪方案组织和角色定义培训方案时间进度

14、表编写工程开发方案书及其相关方案书方案评审方案管理和控制SQA方案SCM方案SDP方案Test方案风险方案2.3.3 SPTO工程追踪软件工程开发方案日常进度跟踪定期报告工程状态周例会里程碑总结需要调整方案修改和评审方案纠正和预防当出现：规模、工作量、进度和关键计算机资源超出规定的阈值；工程总的原始方案不再可能到达；方案和实际的任务安排明显不相符，起不到指导作用；对客户的承诺不能实现时并满足以下条件时：导致方案变化的原因是知道的，并清楚方案怎么样改变；提议的工程进度方案变动是可到达的；提议的工程进度方案已经得到了必须完成他的人员的许诺在周例会上向工程组的成员传达客户方面的信息、交流工程近期进展

15、情况、未完成的工作、工作中存在的问题、好的经验以及部署下两周的工作，以使得方案和实际的开发工作相符合总结到目前为止工程开发总体状况、工程活动进展情况一般通过甘特图来表达、活动项进展应特别关注未完成活动项、本阶段好的经验和典型问题、过程改良建议、客户方面新要求，工程评审、培训执行情况、工程风险等其它方面存在的问题，分析在进度、工作量和缺陷等方面收集的数据并根据情况制定相应的措施和调整时间进度表，保持工程正常、健康开发个人工作周报时间进度表数据收集其它组跟踪周报告分析和预测里程碑报告工程总结工程总结报告2.3.4 PR同行评审评审准备制定本次评审方案评审跟踪正式评审评审人员进行预审，在指定的时间内

16、给出预审意见，反应给评审组长和作者。评审组长将缺陷或问题及工作量汇总填入?评审报告?。要评审的文档已经完成且文档符合标准模板要求，工程经理指定评审组长，发放工作产品及参考资料，必要时确定评审重点参见评审指南工作产品评审方案将报告抄送相关人员工程经理组织解决发现的缺陷或问题作者根据评审结果进行必要的改良验证人验证最终修正评审通过的产品作为基线的要得到SCCB批准评审通知表个人评审表评审报告2.3.5 SQA质量保证软件工程启动指定SQAE制定质量保证方案并评审通过进行审核发现不符合项方案完成？NoYes制定质量审核方案详细的审核时间安排至少在正式审核前2天发给工程经理或技术经理、SQA经理审核、

17、得到工程或技术经理认可询问相关人员，对工程组的过程执行情况进行审核检查文档和其他一切相关的证据，验证工程组的活动总结审核情况将报告初稿与工程经理及有关人员进行讨论，落实问题负责人；形成正式报告后发送给高级管理者、SQA经理、工程经理、工程成员等相关人员工程质量保证情况总结SQA方案SQA审核方案CheckListSQA审核报告SQA差异报告2.4 SDLC 生命周期选择当前比拟成熟稳定的SDLC是： WaterFall RUP XP其中：RUP和XP是迭代式开发过程，风险是可控的。 RUP的优点是过程清晰、文档齐全，但是过于庞杂，比拟适合大规模的团队； XP的优点是过程简洁、推崇简单，但是不注

18、重文档，难于交接，适合小规模团队。对于中等规模的团队来说，应该基于RUP和XP，进行裁剪，找到适合的SDLC： SDLC的核心是：迭代式和TDD 从全局看：n Use-Case Driven用例驱动n 基于Architecturen 迭代和递增的 从微观看：n TDD测试驱动n ReFactor重构n Pair结对编程2.5 Development Process 开发过程需求分析概要设计详细设计编码单元测试集成测试集成测试方案系统测试方案系统测试验收测试形成文档发布维护SRSHLDCODEDD策划软件配置管理软件质量管理评审管理2.5.1 Development Phase 开发阶段 需求分

19、析阶段n 需求收集n 需求总结 总体设计阶段n 总体架构n 部署模型 概要设计阶段n 模块划分n 数据库设计 详细设计阶段n 具体实现 编码阶段n 测试用例n Codingn 单元测试 测试阶段n 测试用例n 测试n 修正 发布阶段n 安装测试n 安装系统n 维护2.5.2 Phase Product 阶段制品 需求阶段n SRS：需求规格说明书 总体设计阶段n 总体设计说明书 概要设计阶段n HLD：概要设计说明书n DB：数据库设计n DFD：数据流图n UI：用户界面 详细设计阶段n DD：详细设计说明书 编码阶段n Test Case：测试用例n Coding：源代码n UT Test

20、 Result：单元测试报告 测试阶段n Test Task：测试任务书n Test Case：测试用例n Test Result：测试报告n Test Approvals：测试总结 发布阶段n 发布申请书2.6 Role Duty 角色职责 角色责任研发经理【研发团队】为软件工程提供足够的资源.保证SQA小组的独立性.解决SQA检查时发现的问题.审批对外的承诺。定期审查SCM、SQA、工程方案和跟踪的相关活动。规定系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控设计和开发以保证他们符合其规格说明；代表公司下达任务书。SA团队负责网络工程方案的制定及实施；负

21、责对客户的技术支持与培训；负责工程效劳部内部人员素质与技术培训负责系统集成工程标识、测试、验收及质量保证；负责硬件、网络和系统软件产品的最后交付；负责组织自产软件储运、防护、交付和安装；负责工程工程的配置管理QA研究制定测试标准和方案；参加实施测试和质量保证过程；对系统测试中发现的缺陷进行验证；负责组织软件工程任务书、开发方案、里程碑等管理评审；负责公司的配置管理；工程经理负责软件和硬件整个工程的协调、管理进行需求分析，并进行文档的编写组织技术评审等活动组织制定工程开发方案SDP、风险管理方案等方案配合与协调SQA和SCM小组的活动.管理工程组，执行SQA方针和过程以及SDP.监督和跟踪SDP

22、、工程估算SA负责硬件工程的实施；负责系统的上线；负责系统的维护；SCCB授权建立软件基线和标识配置项/单元；审查和审定对软件基线的更改；审定由软件基线库制造的产品的生成。SCM协助软件工程经理制定SCM方案、维护SCM 方案；制定并维护工程标识标准；按时归档配置项；标识并管理置于配置管理过程之下的软件工作产品集合；进行软件工程的软件基线生成、管理和备份；软件配置状态的统计和审计，并向工程组、软件工程经理、高级管理者汇报有关活动情况；将基线的变更情况通知受影响的组和个人；保存并管理各项评审记录、与工程相关的技术文档、标准和规程。SQC 依据测试方案模板制定测试方案.执行测试方案进行测试并记录测

23、试发现的缺陷提供测试报告.SQA主要是筹划软件质量保证活动、检验软件产品或活动对可用的标准、需求和规那么的遵守程度、组织处理工程内部不能解决的不一致问题；定期报告检查情况，发现偏差组织制定纠正、预防措施并监督更正；参与制定SQA方案，实施SQA活动，并向SQA经理、软件工程经理工程组、高级管理者汇报有关的情况。DBA负责DB的创立和维护；为DE提供一个稳定的环境；DE按软件开发方案进行开发，并记录相关数据；遵守公司质量管理体系的要求.Deployer根据发布申请，提取代码，发布系统和SA、DBA一起配置环境重构和重建系统2.7 Constraints 限制 3 Specific Require

24、ments 详细描述本局部按照角色划分详细描述开发过程。3.1 Precondition 前提3.1.1 SCM配置库 目录结构n 开发库：开发工作区文档和代码u 工程文档l 工程启动l 工程筹划l 工程方案l 工程报告u 开发文档l 需求l 设计l 测试u 代码l 代码目录u 参考资料l 客户资料等等n 基线库：评审通过后的文档u ?文档同开发库?n 测试库：测试代码和测试发布包u 文档l 方案l 用例l 测试报告u 代码l 版本1l 版本2u 参考资料n 产品库：测试通过后的文档和代码u 工程交付制品l 工程总结l 验收报告l 。u 工程产品l 版本1l 版本2 权限n 测试库：u 测试人

25、员可以读写u 其它人员只能读，不能增加、修改和删除un 基线库：只能增加，不能删除和修改n 产品库：只能增加，不能删除和修改n 开发库：3.1.2 Test Environment 测试环境 测试需要一个独立的环境n DB独立n FTP等资源独立n Pass9等外部系统独立 最好是一个单独的局域网环境，完全和开发分开nn 每次测试，应当是一个完整的测试过程n 安装系统u DBu Webu AppServeru Clientu 其它n 配置系统u DB配置u AppServer配置n 系统初始化u 去除所有历史数据u 执行初始化脚本，插入初始数据n 测试系统3.2 Development Con

26、trol Process 开发控制流程3.2.1 工程启动和筹划阶段本阶段的关键是定义工程、估算工作量和制定详细方案。一个软件工程的正式启动从?软件工程任务书?的下达开始。任务书中写明工程的根本信息及相关责任人和详细分工，规定工程必须提交的产品清单。任务书由研发经理或者工程负责人起草，研发经理批准后下达给相关负责人。工程任务书必须为打印纸质文档，由相关人员签字确认后，入配置管理库归档。软件工程任务书主要作用是明确工程人员职责以及各组之间的协调确认。估算工作量，从确认需求后开始。由工程经理指定评估人员，先按照头脑风暴法估计各个子系统或者模块的难易程度，然后按照Delphi法估算各个局部的工作量。

27、工程经理和PMO成员，根据估算的工作量，制定工程方案。SQA和SCM分别制定各自的方案。SCM需要确定资源库的目录结构和权限结构。工程经理召集PMO、SQA、SCM评审及审核工程方案、SQA方案、SQA审核方案、SCM方案和测试方案。对于发布后的一般性程序修改，不需要下达软件工程任务书。对于关系重大，需要各组人员协调工作的重大修改，工程负责人可以以任务书的形式明确职责、协调关系。测试负责人评估测试资源【人员及机器】，并决定测试人员是否介入工程的需求分析和设计阶段。3.2.2 需求分析、设计、编码阶段本阶段的关键是评审和修订控制，关键评审需要需求、设计、编码、测试、工程管理、用户等的参与。需求阶

28、段，需求分析人员收集需求，根据SRS模版，作出需求规格说明书。设计阶段，设计人员根据总体设计、概要设计、数据库设计和详细设计，作出设计文档。编码阶段，编码人员根据详细设计，设计单元测试用例，编写代码，进行单元测试。关键评审：SRS评审，设计评审，代码走查3.2.3 提交测试阶段工程启动后，工程经理填写测试任务通知单，将测试任务下达给测试组。概要设计评审完成后，由各子系统或者模块的负责人测算完成时间，在确定完成时间后正式开始编码前将测试任务通知单提交给工程测试负责人，工程测试负责人审核通过在通知单上签字后返回给子工程负责人。开发及单元测试完成后，由开发人员将测试内容提交配置管理员入测试库后，将测

29、试任务通知单提交给发布人员申请测试发布。发布人员将测试库中本次测试的内容发布到测试机后，在测试任务通知单上签字后，提交给测试人员开始测试。测试完成后，测试人员在任务单上填写测试意见后，交测试负责人确认后，返还给开发人员。如测试没有通过，开发人员修改测试内容，进入下一个测试流程。如通过测试，开发人员将测试任务通知单提交给工程负责人，由工程负责人、SCCB签字确认后，提交配置管理员将测试内容入基线库。过程关键：发布实施人员确保发布到测试机上的源程序在配置管理库中得到了有效的标识。3.2.4 生产发布、终测程序通过测试入库以后，根据需要，由工程的负责人负责填写发布申请单。发布申请单由工程测试负责人、

30、配置管理员、SCCB、客户代表、研发经理签字确认后，由工程负责人提交给实施发布人员。发布人员拿到签完字的发布申请后，才能从基线库中提取程序向生产机上发布。如以上发布确认人员没有全部签字同意发布，必须由工程经理签字同意后发布。程序发布到生产机上以后，进入终测【UAT】流程。测试人员和用户代表要对生产机上的程序进行最后测试，确保生产机上的系统符合需求。工程负责人负责同用户协调，工程负责人、测试人员和用户共同编写测试用例。工程负责人将?终测意见书?提交三方签字，根据签字意见决定修订系统或者提交正式发布。终测出现的问题修改按照基线变更流程进行。实施人员只有拿到有三方签字的?终测意见书?后才能将系统正式

31、公开发布。系统正式发布三天之后一周之内，由实施人员负责到用户处取得有用户主要负责人签字的?系统运行报告?，工程负责人负责监督执行。根据?系统运行报告?做相应的处理。过程关键：发布到生产机上的程序都在基线库中得到了有效的标识。3.2.5 发布后问题反应修改正程系统发布之后，用户反应的意见要形成问题清单或者变更申请单，记录需要修改的地方，提交给工程负责人。工程负责人负责判断改动是否会影响需求或者设计，负责将任务分配给相关人员进行修改。修改完成后，提交测试直至发布。这个阶段的最重要的是保证所做的修改文档、代码都在配置管理库的基线库中得到表达。即基线库中的文档和代码要进行同步更新，关键是发布人员严格根

32、据发布申请单进行控制，并确保发布的代码都是从基线库中取出的。没有经过流程直接要求发布的，发布人员必须予以拒绝。3.3 TSP 团队软件过程3.3.1 会议组织 会议前，确定会议主持人和记录员 向参与会议人员发送会议资料 参与会议人员阅读会议资料 确定会议主题、日期时间和地点n 注意：留出阅读资料的时间 确定会议议程 准备会议用品【如投影仪等】 重要会议，需要签到 会议开始前，申明会议纪律n 发言时间限制n 发言顺序n 除主持人外，不得打断别人 记录员记录会议纪要 会议后，发送会议总结3.3.2 沟通问题 原那么n 目标明确n 明确反应n 反复沟通 请求答复n 当有疑问时，发出请求n 明确求助对

33、象，指定第一对象和辅助对象n 第一对象接收到请求后，不能及时答复的应当转发给自己认为适宜的答复人，并告知求助人n 求助方式【高低】：当面， ，邮件 公告3.3.3 代码走查 工程负责人指定代码走查对象n 相互走查n 循环走查 代码走查发现的问题n 首先记录n 告知代码作者 更新CheckList3.3.4 其它3.4 PSP 个人软件过程3.4.1 工作原那么 方案管理：把你想做的写下来 行为管理：按照你写下来的去做 报告管理：把做的事情记录下来 跟踪管理：出现的问题要设法解决3.4.2 日常工作 每日工作n 每日早晨，规划当日工作；u 方案必须细化到一个明确的目标u 方案要有余地，比方会议等

34、u 方案是可执行的，能够完成的u 方案是可监控的n 每日下班，总结当日工作；u 方案完成情况u 未能完成原因u 个人心得：新的发现，新的方法，新的问题 会议n 会议之前，仔细阅读会议资料n 如有疑问，可以发邮件向会议主持人提出n 或者在会议上提出n 会议中，记录会议要点n 如要参与讨论，请在别人发言结束后发言，不要打断别人n 会议后，如有新的想法，发邮件或者当面向会议主持人提出 求助n 如果一个问题20分钟还不能理出一个头绪，应当立即求助n 求助对象：u 个人认为能够解决该问题的人为第一对象u 不能确认的，工程负责人为第一求助对象n 发出求助后，个人负责追踪求助，直到解决 报告n 认为个人负责

35、的任务不能按时完成的，应当立即报告给负责人u 重要任务：Leader和工程负责人u 其它任务：Leadern 提前期：u 重要任务：至少提前3天u 其它任务：至少提前任务期的1/33.4.3 DE 开发工程师 接受任务 阅读详细设计文档n 从SCM获取详细设计文档n 阅读文档n 如有疑问，向设计人员请教 规划个人开发方案n 估计开发工作量n 制定方案u 单元测试用例u 代码u 单元测试n 和负责人协商n 提交SCM 设计单元测试用例n SCM获取测试用例模版n 编写测试用例n 提交SCM 编写代码n 从SCM获取代码库n 编写代码n 本地调试n 提交SCM 单元测试n 代码发布到开发机n 请D

36、BA协助n 如果有其它模块，请负责人协调n 测试 代码走查n 根据负责人安排，检查他人的代码n 和代码作者讨论代码n 填写走查报告 提交代码n 提交SCMn 做Tag或者其它标记，以便提交集成测试3.4.4 SCME 配置管理员 规划SCMn 资源库目录结构n 权限n 基线n 备份 基线n 经过评审n 发送通知n 转移资源到相应基线 变更管理n 接收变更申请n 向SCCB发送申请n 申请通过后，发送变更通知n 提取基线到工作区3.4.5 DBA 数据库管理员 规划DB的管理n DB的大小n 权限划分n 备份和恢复n 建立DB脚本n 和SCM协商进入SCM的资源 管理DBn 建立DBn 建立权限

37、n 评审数据库设计n 导入和导出数据n 建立Table、view和indexn3.4.6 Deployer 发布人员 规划n 发布策略n 发布脚本n 发布方案 重构和重建n 根据工程特点制定重构和重建方案n 编写重建脚本n 编写测试脚本n 从SCM提取资源n 重建系统n 执行测试脚本 发布n 接收发布任务书n 从SCM提取资源n 和DBA建立DBn 和SA建立环境n 发布系统4 Tool Specification 工具标准4.1 通用工具 会议报告n PPTn Wordn MPP 会议记录n Word CheckListn Excel4.2 方案 工程方案n MPP 风险方案n Word4.

38、3 需求分析 SRS文档n Word Use Case图n Rational Rose 对象图n Rational Rose 序列图n Rational Rose 流程图n Visio4.4 设计 总体设计n Wordn Rational Rose 概要设计n Wordn Rational Rose 数据库设计n Visio 详细设计n Word4.5 编码 测试用例n Word 编码n Visual Studio 2005 单元测试n Word4.6 测试 Test Director5 Documents 文档5.1 工程管理文档5.1.1 工程筹划 Delphi估算表 工程方案模版 测试方

39、案模版 工程清单5.1.2 工程追踪 工程日进度报告 工程周报 工程周方案报告 工程月度报告 工程月度状态报告 签到簿5.1.3 质量保证 工程筹划过程检查表 配置管理活动检查表 工程跟踪情况检查表5.1.4 工程终止 软件合格验收标准 工程验收报告5.2 开发过程文档5.2.1 软件配置管理 软件配置管理工具 变更申请表 变更通知单5.2.2 会议管理 会议记录5.2.3 方案跟踪 开发方案 测试方案 工作日志5.2.4 评审管理 评审指南 评审申请表 个人评审记录 评审报告5.2.5 质量管理 文档编写标准 SRS 总体设计报告 概要设计报告 详细设计报告 编码标准5.2.6 测试过程 测试用例 测试报告5.2.7 问题解决过程 问题跟踪表 软件工程任务书 测试任务通知单 发布申请单 系统运行报告 终测意见书5.2.8 其他 用户手册6 Appendix 附录6.1 易于理解的代码 经常注释 注释内容是做了什么，不能是为什么做 检查错误，尤其是函数入口 变量名要简洁易懂 经常使用Static常量6.2 Log输出 截获抛出异常的地方，要输出Error 返回True/False的方法，如果返回False，要输出Debug 所有调用其它系统接口的地方，都要输出Info，内容是参数和返回值； 输出前，判断是否允许输出，比方：isDebugEnabled