软件开发程序.pdf

《软件开发程序.pdf》由会员分享，可在线阅读，更多相关《软件开发程序.pdf（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1目的 详细策划软件产品研发，对资源、成本及进度进行合理的估算，严格按照计 划的要求组织各项研发活动，以保证软件产品的研发质量和进度要求。2适用范围 适用对象：技术部（软件开发部）业务范围：适用于软件开发项目；适用于项目的整个生存周期。3方针和职责 技术部（软件开发部）成立软件研发项目组；指定的项目负责人负责组织研 发计划、需求分析、软件设计、编码实现（含单元测试）、验收等主流程活动的 实施；技术部（软件开发部）项目组软件设计工程师（Software Engineer）负责需 求分析和概要/详细设计；技术部（软件开发部）项目组程序员（Coding）负责编码；项目负责人主持设计开发评审、验证（系

2、统测试）、确认（验收与鉴定）；技术部（软件开发部）测试工程师（Test）负责软件测试（详见软件测试 程序）;配置管理员（SCM）负责设计与开发配置管理，并协调更改控制；由技术部（软件开发部）项目负责人组织技术骨干，必要时包括销售经理和 客户代表，组成变更控制委员会（CCB）,对审批设计与开发变更。4工作程序 4.1 软件需求 项目经理和项目技术负责人接受过软件工程、项目的应用领域知识、项目管 理的培训或具备相应的能力。软件需求分析人员接受过业务领域、软件需求分析理论、方法、工具等的培 训，或具备相应的能力。软件需求分析人员根据项目计划中定义的项目软件过程，通过系统地分 析需求，对软件需求进行开

3、发、维护、建立文档并进行验证。4.1.1 软件需求分析准备 Requirement Analyzing Preparation 过程活动 Process activities 1、需求负责人确定项目的需求分析准则，如应遵守的标准、规范和针对本 项目的约定等，这些准则应具备可操作和可验证性。2、需求负责人确定有效的需求分析方法。常用的需求分析方法有：功能分 解方法。4.1.2 软件需求分析、建立文档 Requirement Analyzing&Documenting 输入Input 1.经过评审并形成基线的合同或可行性分析报告中的需求；2.项目进度计划（MSP）。过程活动 Process act

4、ivities 1、在开始需求分析之前，需求组应确保需求中影响软件需求分析的各种问 题得到识别和解决。2、需求组采用确定的分析方法，在需求分析准则的约束下，识别和推导软 件需求。3、如果需求组根据合同中的需求，通过调研等方式获取足够详细的用 户需求，形成了用户需求说明书，则该文档必须有用户的书面确认，并纳入配置管理。项目组以此为基础进行需求分析，形成软件需求分 析说明书。如果直接根据合同中的需求进行需求分析，形成软件 需求分析说明书，则该文档必须有用户的书面确认。4、需求组讨论需求分析结果和有关问题，确保需求是可行的、适合软件实 现的、陈述清楚的、彼此一致的、可测试的并且也是完整的。5、需求组

5、将所采用的需求分析方法及需求分析结果均写入软件需求分析 说明书（参照软件需求分析说明书模板）。6、确认测试组分析每部分软件需求，验证其可测试性，并应在确认测试 方案中描述如何测试各需求项得到满足。输出Output 1.用户需求说明书（必要时）2.软件需求分析说明书 4.1.3 软件需求评审 Requirement Reviewing 输入Input 1、用户需求说明书（必要时）2、软件需求分析说明书 3、项目进度计划（MSP）过程活动 Process activities 1、软件需求分析说明书要通过同行评审，参与编码和软件设计的人员、确认测试组必须参加评审，确保影响编码、软件设计和测试的各种

6、问题 得到识别和解决。2、通过评审的软件需求分析说明书需项目分管高层经理签字批准。3、对于合同项目，参照本程序”5.2节过程活动2”的要求取得用户代表书面 确认。具体方式有两种：一是邀请用户参加需求评审；二是内部评审通 过后提交用户确认。4、用户需求说明书（必要时）、软件需求分析说明书在评审通过（合 同项目的用户需求说明书或软件需求分析说明书需得到用户确 认，参照5.2节过程活动21后纳入配置管理之下。输出Output 1、形成基线的软件需求分析说明书 2、评审记录 4.1.4 变更 Requirement change 如果需求发生变更，应识别需要变更的工作产品，并按照配置管理程序 实施变更

7、，并记录于变更请求跟踪表，以保持工作产品的一致性。随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动 方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。当需要更改用 户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更 改。4.1.5 度量 Measurement 软件需求活动中应进行的度量包括：1、需求评审发现的缺陷数、严重程度、缺陷起源阶段；2、需求的基线变更次数；3、花在评审、纠正和批准各任务活动/软件工作产品上的工作量；4、变更各任务活动软件工作产品的规模、费用、工作量。以上数据分别体现在里程碑报告及项目状态报告中。4.1.6 验证 Verif

8、ication 项目分管高层经理定期通过项目周报、项目状态报告、项目月报、重大里程碑评审来评审需求分析活动。项目经理定期通过项目例会、项目月报、重大里程碑评审或遇到重要需求 分析问题时来评审需求分析活动。QA人员评审和验证：1、软件需求被评审，确保它们是完整的、正确的、一致的、可行的、可测 试的。2、需要进行评审的需求文档，已进行了评审；3、软件需求活动满足准备就绪准则和完成准则；4、软件产品符合规定的标准和要求；5、评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；4.2软件设计 4.2.1 设计准备 Designing Preparation 过程活动 Process activiti

9、es 1、设计负责人负责确定项目的设计准则，如应遵守的国际、国内和行业标 准、设计规范和针对本项目的约定等，这些准则应具备可操作和可验证 性并且经过设计组的评审。2、确定适合本次设计的有效方法。常用的软件设计方法有：面向过程设计（参 见面向过程的软件开发指南 卜面向对象设计（参见面向对象的软件 开发指南）。4.2.2 概要设计 High Level Disign 输入Input 1、纳入基线的软件需求分析说明书 2、项目进度计划（MSP）过程活动 Process activities 1、在软件生命周期和所用技术的约束下，首先根据软件需求说明书开 发出软件体系结构，编写概要设计说明书。建立软件

10、的顶层框架，完 成对内部接口和外部接口的准确定义（参见概要设计说明书模板）。2、设计组检查概要设计，确保设计是可行的、适合实现的、陈述清楚的、彼此一致的并且也是完整的。3、设计组依据评审程序组织对概要设计说明书进行同行评审，综 合测试组与实现组参加评审，以验证其可测试性，并确保影响编码的各 种问题得到识别和解决。4、软件设计文档置于配置管理之下，在评审通过后纳入基线。输出Output 1、纳入基线的概要设计说明书 2、评审记录 4.2.3 详细设计 Low Level Design 输入Input 1、纳入基线的概要设计说明书 2、项目进度计划（MSP）过程活动 Process activit

11、ies 1、设计组基于概要设计说明书进行软件详细设计（含必要的数据库设计）,编写详细设计说明书（参见详细设计说明书模板）；必要时，编写 数据库设计说明书（参见数据库设计模板）。2、设计组检查详细设计说明书、数据库设计说明书（必要时），确保 设计是可行的、适合编码实现的、陈述清楚的、彼此一致的并且也是完 整的。3、设计组依据评审程序组织对详细设计说明书进行同行评审，综 合测试组与实现组参加评审，以验证其可测试性，并确保影响编码的各 种问题得到识别和解决。4、软件设计文档置于配置管理之下，在评审通过后纳入基线。输出Output 1、纳入基线的详细设计说明书、数据库设计说明书（必要时）2、评审记录

12、4.2.4 变更 Change 如果用户需求或其他原因导致软件设计工作产品变更，则应按照 配置管理程 序 实施变更，并记录于变更请求跟踪表，以保持工作产品的一致性。随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方 面进行更改时，应先分析更改对软件的影响，合适时予以采纳。当需要更改用户 需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。4.2.5 剪裁指南 Tailoring Guideline 在以下两种情况可以把概要设计过程和详细设计过程合并，产生一个设计文 档。1、小型项目，一般指估计代码行数小于 XX的项目；2、有类似项目可以参考。4.2.6 过

13、程度量 Measurement 软件设计活动中应进行的度量包括：1、设计评审发现的缺陷数、严重程度、缺陷起源阶段；2、设计基线变更次数；3、花在评审、纠正和批准各任务活动/软件工作产品上的工作量；4、变更各任务活动软件工作产品的规模、费用、工作量。以上数据分别体现在里程碑报告及项目状态报告中。4.2.7 验证 Verification 项目分管高层经理定期通过项目周报、项目状态报告、项目月报、重大里程碑评审来评审软件设计活动。项目经理定期通过项目例会、项目月报、重大里程碑评审或遇到重要需求 分析问题时来评审软件设计活动。QA人员评审和验证：1、需要进行评审的设计文档，已进行了评审；2、软件设计

14、活动满足准备就绪准则和完成准则；3、软件产品符合规定的标准和要求；4、评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；4.3软件产品实现 项目经理和项目技术负责人接受过软件工程、项目的应用领域知识、项目管 理的培训或具备相应的能力。软件实现人员接受过软件编码及单元测试理论、方法、技术、工具等的培训 或具备相应能力。实现人员根据项目计划，进行软件代码的开发、维护、建立文档和验证，以实现软件需求和软件设计。4.3.1 准备 Preparation 过程活动 Process activities 1、实现负责人根据项目实际情况识别可能影响项目性能（速度、稳定性、内 存等）的问题并提出解决方法。

15、2、实现负责人确定编程的有效方法。常用的编程方法有：结构化编程，代码 重用。3、实现负责人确定单元测试的测试内容、测试方法、测试用例的设计方法、测试用例对程序的覆盖情况及要达到的测试覆盖率。其中语句覆盖率要求 不低于90%,对重要单元要求分支覆盖率增强到 80%以上。常用的单元 测试方法是以白盒测试为主，黑盒测试为辅。白盒测试的测试用例设计方 法：逻辑覆盖、基本路径测试；黑盒测试的测试用例设计方法：等价类划 分、边界值分析、错误推测法等。4.3.2 编码和单元测试 Coding and Unit Test 4.3.2.1 编码 输入Input 1、形成基线的详细设计说明书（说明：程序设计说明书

16、等同于详 细设计说明书）2、必要时，形成基线的数据库设计说明书 3、项目进度计划（MSP）过程活动 Process activities 1、实现组根据项目进度计划（MSP）定义的代码单元的开发顺序，编制软件 代码，并保证程序编译正确。2、软件需求或软件设计更改时，按照新纳入基线的软件需求或软件设计更改 相关代码。输出Output 1、软件源代码 4.3.2.2 实施单元测试 输入Input 1.完成的代码单元 过程活动 Process activities 1.依据概要设计说明书，实现组负责完成测试环境搭建。2.实现组依据概要设计说明书对每个代码单元实施单元测试。3.实现负责人跟踪缺陷至关闭

17、。4.被测试软件或软件环境发生变化时，适当进行回归测试。输出Output 1.经单元测试通过的代码 4.3.3 同行评审 Peer reviewing 输入Input 1、已通过单元测试的软件源代码 2、项目进度计划（MSP）过程活动 Process activities 1.依据项目进度计划（MSP）的安排，参考评审程序的要求，组织完 成每个软件源代码单元的同行评审。2.通过同行评审的源代码置于配置管理之下，并形成基线。输出Output 3、通过同行评审的软件源代码 4.3.4 编写操作手册complete operation manual 输入Input 1、已形成基线的项目进度计划（MS

18、P）过程活动 Process activities 1、项目经理依据项目进度计划（MSP）,指定文档编写人员，参照操作手 册模板，采用恰当的方法和工具（例如，Microsoft Word,Photoshop等）,编写和维护操作手册。2、操作手册的编写最早可开始于软件界面确定之时，最晚必须于确认 测试实施前完成。文档编写人员应尽早参与计划和编写操作手册 0,使得用户、确认测试人员在软件生命周期的初期可获得操作手册。当 用户需求或软件界面更改时，文档编写人员应及时完善操作手册。3、依据项目进度计划（MSP）和评审程序，组织完成操作手册的同 行评审。合适时，由用户对最终文档进行评审和认可。4、通过同

19、行评审的操作手册置于配置管理之下，并形成基线。输出Output 1、通过同行评审的操作手册 2、评审记录 4.3.5 模块集成 Unit Integration 输入Input 已形成基线的软件源代码 过程活动 Process activities 实现组进行各单元的集成，并保证编译通过，以准备综合测试。输出Output 编译通过并集成各单元后的程序 4.3.6 变更 Modification 源代码形成基线后，其更改（一般为当软件需求或软件设计更改时，或后续 测试发现缺陷时）应按照软件配置管理程序进行。随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动 方面进行更改时，应先分

20、析更改对软件的影响，合适时予以采纳。当需要更改用 户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更 改。4.3.7 过程度量 Measurement 软件实现过程中应进行的度量包括：1、评审和测试发现的缺陷数、严重程度、缺陷起源阶段；2、编码相关的基线变更次数；3、花在评审、纠正和批准软件编码上的工作量；4、变更软件编码的规模、费用、工作量。以上数据分别体现在里程碑关闭报告中。4.3.8 验证 Verification 项目分管高层经理定期通过项目周报、项目状态报告、项目月报、重大里程碑评审来评审软件实现活动。项目经理定期通过项目例会、项目月报、重大里程碑评审或遇到重要需

21、求 分析问题时来评审软件实现活动。QA人员评审和验证：1.软件编码已进行了同行评审和单元测试；2.软件编码前，需求和设计已完成并通过评审，编码完成后阶段工作产品 满足输出标准；3.软件编码符合项目定义的标准和要求；4.软件实现活动满足准备就绪准则和完成准则；5.按照测试计划，完成所要求的单元测试，而且测试满足其验收准则；6.已完成了计划的测试，并记录了测试结果；7.评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；6相关文件 软件测试程序 设计评审程序 服务控制程序 软件开发规范汇编 7质量记录 项目开发计划 配置管理计划 质量保证计划 需求分析说明书 概要设计说明书 数据库设计说明书 详细设计说明书 代码 产品安装与使用说明 设计评审表 变更请求跟踪表