软件开发程序.docx

软件开发程序.docx

《软件开发程序.docx》由会员分享，可在线阅读，更多相关《软件开发程序.docx（13页珍藏版）》请在冰点文库上搜索。

软件开发程序

1目的

详细策划软件产品研发，对资源、成本及进度进行合理的估算，严格按照计划的要求组织各项研发活动，以保证软件产品的研发质量和进度要求。

2适用范围

适用对象：

技术部（软件开发部）

业务范围：

适用于软件开发项目；适用于项目的整个生存周期。

3方针和职责

技术部（软件开发部）成立软件研发项目组；指定的项目负责人负责组织研发计划、需求分析、软件设计、编码实现（含单元测试）、验收等主流程活动的实施；

技术部（软件开发部）项目组软件设计工程师（SoftwareEngineer）负责需求分析和概要/详细设计；

技术部（软件开发部）项目组程序员（Coding）负责编码；

项目负责人主持设计开发评审、验证（系统测试）、确认（验收与鉴定）；

技术部（软件开发部）测试工程师（Test）负责软件测试（详见《软件测试程序》）；

配置管理员（SCM）负责设计与开发配置管理，并协调更改控制；

由技术部（软件开发部）项目负责人组织技术骨干，必要时包括销售经理和客户代表，组成变更控制委员会（CCB），对审批设计与开发变更。

4工作程序

4.1软件需求

项目经理和项目技术负责人接受过软件工程、项目的应用领域知识、项目管理的培训或具备相应的能力。

软件需求分析人员接受过业务领域、软件需求分析理论、方法、工具等的培训，或具备相应的能力。

软件需求分析人员根据《项目计划》中定义的项目软件过程，通过系统地分析需求，对软件需求进行开发、维护、建立文档并进行验证。

4.1.1软件需求分析准备RequirementAnalyzingPreparation

过程活动Processactivities

1、需求负责人确定项目的需求分析准则，如应遵守的标准、规范和针对本项目的约定等，这些准则应具备可操作和可验证性。

2、需求负责人确定有效的需求分析方法。

常用的需求分析方法有：

功能分解方法。

4.1.2软件需求分析、建立文档RequirementAnalyzing&Documenting

输入Input

1.经过评审并形成基线的《合同》或《可行性分析报告》中的需求；

2.项目进度计划（MSP）。

过程活动Processactivities

1、在开始需求分析之前，需求组应确保需求中影响软件需求分析的各种问题得到识别和解决。

2、需求组采用确定的分析方法，在需求分析准则的约束下，识别和推导软件需求。

3、如果需求组根据《合同》中的需求，通过调研等方式获取足够详细的用户需求，形成了《用户需求说明书》，则该文档必须有用户的书面确认，并纳入配置管理。

项目组以此为基础进行需求分析，形成《软件需求分析说明书》。

如果直接根据《合同》中的需求进行需求分析，形成《软件需求分析说明书》，则该文档必须有用户的书面确认。

4、需求组讨论需求分析结果和有关问题，确保需求是可行的、适合软件实现的、陈述清楚的、彼此一致的、可测试的并且也是完整的。

5、需求组将所采用的需求分析方法及需求分析结果均写入《软件需求分析说明书》（参照《软件需求分析说明书模板》）。

6、确认测试组分析每部分软件需求，验证其可测试性，并应在《确认测试方案》中描述如何测试各需求项得到满足。

输出Output

1.《用户需求说明书》（必要时）

2.《软件需求分析说明书》

4.1.3软件需求评审RequirementReviewing

输入Input

1、《用户需求说明书》（必要时）

2、《软件需求分析说明书》

3、项目进度计划（MSP）

过程活动Processactivities

1、《软件需求分析说明书》要通过同行评审，参与编码和软件设计的人员、确认测试组必须参加评审，确保影响编码、软件设计和测试的各种问题得到识别和解决。

2、通过评审的《软件需求分析说明书》需项目分管高层经理签字批准。

3、对于合同项目，参照本程序“5.2节过程活动2”的要求取得用户代表书面确认。

具体方式有两种：

一是邀请用户参加需求评审；二是内部评审通过后提交用户确认。

4、《用户需求说明书》（必要时）、《软件需求分析说明书》在评审通过（合同项目的《用户需求说明书》或《软件需求分析说明书》需得到用户确认，参照“5.2节过程活动2”）后纳入配置管理之下。

输出Output

1、形成基线的《软件需求分析说明书》

2、评审记录

4.1.4变更Requirementchange

如果需求发生变更，应识别需要变更的工作产品，并按照《配置管理程序》实施变更，并记录于《变更请求跟踪表》，以保持工作产品的一致性。

随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。

当需要更改用户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。

4.1.5度量Measurement

软件需求活动中应进行的度量包括：

1、需求评审发现的缺陷数、严重程度、缺陷起源阶段；

2、需求的基线变更次数；

3、花在评审、纠正和批准各任务活动/软件工作产品上的工作量；

4、变更各任务活动软件工作产品的规模、费用、工作量。

以上数据分别体现在《里程碑报告》及《项目状态报告》中。

4.1.6验证Verification

项目分管高层经理定期通过《项目周报》、《项目状态报告》、《项目月报》、重大里程碑评审来评审需求分析活动。

项目经理定期通过项目例会、《项目月报》、重大里程碑评审或遇到重要需求分析问题时来评审需求分析活动。

QA人员评审和验证：

1、软件需求被评审，确保它们是完整的、正确的、一致的、可行的、可测试的。

2、需要进行评审的需求文档，已进行了评审；

3、软件需求活动满足准备就绪准则和完成准则；

4、软件产品符合规定的标准和要求；

5、评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；

4.2软件设计

4.2.1设计准备DesigningPreparation

过程活动Processactivities

1、设计负责人负责确定项目的设计准则，如应遵守的国际、国内和行业标准、设计规范和针对本项目的约定等，这些准则应具备可操作和可验证性并且经过设计组的评审。

2、确定适合本次设计的有效方法。

常用的软件设计方法有：

面向过程设计（参见《面向过程的软件开发指南》）、面向对象设计（参见《面向对象的软件开发指南》）。

4.2.2概要设计HighLevelDisign

输入Input

1、纳入基线的《软件需求分析说明书》

2、项目进度计划（MSP）

过程活动Processactivities

1、在软件生命周期和所用技术的约束下，首先根据《软件需求说明书》开发出软件体系结构，编写《概要设计说明书》。

建立软件的顶层框架，完成对内部接口和外部接口的准确定义（参见《概要设计说明书模板》）。

2、设计组检查概要设计，确保设计是可行的、适合实现的、陈述清楚的、彼此一致的并且也是完整的。

3、设计组依据《评审程序》组织对《概要设计说明书》进行同行评审，综合测试组与实现组参加评审，以验证其可测试性，并确保影响编码的各种问题得到识别和解决。

4、软件设计文档置于配置管理之下，在评审通过后纳入基线。

输出Output

1、纳入基线的《概要设计说明书》

2、评审记录

4.2.3详细设计LowLevelDesign

输入Input

1、纳入基线的《概要设计说明书》

2、项目进度计划（MSP）

过程活动Processactivities

1、设计组基于《概要设计说明书》进行软件详细设计（含必要的数据库设计），编写《详细设计说明书》（参见《详细设计说明书模板》）；必要时，编写《数据库设计说明书》（参见《数据库设计模板》）。

2、设计组检查《详细设计说明书》、《数据库设计说明书》（必要时），确保设计是可行的、适合编码实现的、陈述清楚的、彼此一致的并且也是完整的。

3、设计组依据《评审程序》组织对《详细设计说明书》进行同行评审，综合测试组与实现组参加评审，以验证其可测试性，并确保影响编码的各种问题得到识别和解决。

4、软件设计文档置于配置管理之下，在评审通过后纳入基线。

输出Output

1、纳入基线的《详细设计说明书》、《数据库设计说明书》（必要时）

2、评审记录

4.2.4变更Change

如果用户需求或其他原因导致软件设计工作产品变更，则应按照《配置管理程序》实施变更，并记录于《变更请求跟踪表》，以保持工作产品的一致性。

随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。

当需要更改用户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。

4.2.5剪裁指南TailoringGuideline

在以下两种情况可以把概要设计过程和详细设计过程合并，产生一个设计文档。

1、小型项目，一般指估计代码行数小于XX的项目；

2、有类似项目可以参考。

4.2.6过程度量Measurement

软件设计活动中应进行的度量包括：

1、设计评审发现的缺陷数、严重程度、缺陷起源阶段；

2、设计基线变更次数；

3、花在评审、纠正和批准各任务活动/软件工作产品上的工作量；

4、变更各任务活动软件工作产品的规模、费用、工作量。

以上数据分别体现在《里程碑报告》及《项目状态报告》中。

4.2.7验证Verification

项目分管高层经理定期通过《项目周报》、《项目状态报告》、《项目月报》、重大里程碑评审来评审软件设计活动。

项目经理定期通过项目例会、《项目月报》、重大里程碑评审或遇到重要需求分析问题时来评审软件设计活动。

QA人员评审和验证：

1、需要进行评审的设计文档，已进行了评审；

2、软件设计活动满足准备就绪准则和完成准则；

3、软件产品符合规定的标准和要求；

4、评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；

4.3软件产品实现

项目经理和项目技术负责人接受过软件工程、项目的应用领域知识、项目管理的培训或具备相应的能力。

软件实现人员接受过软件编码及单元测试理论、方法、技术、工具等的培训或具备相应能力。

实现人员根据《项目计划》，进行软件代码的开发、维护、建立文档和验证，以实现软件需求和软件设计。

4.3.1准备Preparation

过程活动Processactivities

1、实现负责人根据项目实际情况识别可能影响项目性能（速度、稳定性、内存等）的问题并提出解决方法。

2、实现负责人确定编程的有效方法。

常用的编程方法有：

结构化编程，代码重用。

3、实现负责人确定单元测试的测试内容、测试方法、测试用例的设计方法、测试用例对程序的覆盖情况及要达到的测试覆盖率。

其中语句覆盖率要求不低于90%，对重要单元要求分支覆盖率增强到80%以上。

常用的单元测试方法是以白盒测试为主，黑盒测试为辅。

白盒测试的测试用例设计方法：

逻辑覆盖、基本路径测试；黑盒测试的测试用例设计方法：

等价类划分、边界值分析、错误推测法等。

4.3.2编码和单元测试CodingandUnitTest

4.3.2.1编码

输入Input

1、形成基线的《详细设计说明书》（说明：

《程序设计说明书》等同于《详细设计说明书》）

2、必要时，形成基线的《数据库设计说明书》

3、项目进度计划（MSP）

过程活动Processactivities

1、实现组根据项目进度计划（MSP）定义的代码单元的开发顺序，编制软件代码，并保证程序编译正确。

2、软件需求或软件设计更改时，按照新纳入基线的软件需求或软件设计更改相关代码。

输出Output

1、软件源代码

4.3.2.2实施单元测试

输入Input

1.完成的代码单元

过程活动Processactivities

1.依据《概要设计说明书》，实现组负责完成测试环境搭建。

2.实现组依据《概要设计说明书》对每个代码单元实施单元测试。

3.实现负责人跟踪缺陷至关闭。

4.被测试软件或软件环境发生变化时，适当进行回归测试。

输出Output

1.经单元测试通过的代码

4.3.3同行评审Peerreviewing

输入Input

1、已通过单元测试的软件源代码

2、项目进度计划（MSP）

过程活动Processactivities

1.依据项目进度计划（MSP）的安排，参考《评审程序》的要求，组织完成每个软件源代码单元的同行评审。

2.通过同行评审的源代码置于配置管理之下，并形成基线。

输出Output

1、通过同行评审的软件源代码

4.3.4编写《操作手册》completeoperationmanual

输入Input

1、已形成基线的项目进度计划（MSP）

过程活动Processactivities

1、项目经理依据项目进度计划（MSP），指定文档编写人员，参照《操作手册模板》，采用恰当的方法和工具（例如，MicrosoftWord，Photoshop等），编写和维护《操作手册》。

2、《操作手册》的编写最早可开始于软件界面确定之时，最晚必须于确认测试实施前完成。

文档编写人员应尽早参与计划和编写《操作手册》。

，使得用户、确认测试人员在软件生命周期的初期可获得《操作手册》。

当用户需求或软件界面更改时，文档编写人员应及时完善《操作手册》。

3、依据项目进度计划（MSP）和《评审程序》，组织完成《操作手册》的同行评审。

合适时，由用户对最终文档进行评审和认可。

4、通过同行评审的《操作手册》置于配置管理之下，并形成基线。

输出Output

1、通过同行评审的《操作手册》

2、评审记录

4.3.5模块集成UnitIntegration

输入Input

已形成基线的软件源代码

过程活动Processactivities

实现组进行各单元的集成，并保证编译通过，以准备综合测试。

输出Output

编译通过并集成各单元后的程序

4.3.6变更Modification

源代码形成基线后，其更改（一般为当软件需求或软件设计更改时，或后续测试发现缺陷时）应按照软件配置管理程序进行。

随着对软件理解的加深，如果需要对软件工作产品、计划、过程定义和活动方面进行更改时，应先分析更改对软件的影响，合适时予以采纳。

当需要更改用户需求时，应先得到批准，然后再与相关小组协商对软件产品和活动作出相应更改。

4.3.7过程度量Measurement

软件实现过程中应进行的度量包括：

1、评审和测试发现的缺陷数、严重程度、缺陷起源阶段；

2、编码相关的基线变更次数；

3、花在评审、纠正和批准软件编码上的工作量；

4、变更软件编码的规模、费用、工作量。

以上数据分别体现在《里程碑关闭报告》中。

4.3.8验证Verification

项目分管高层经理定期通过《项目周报》、《项目状态报告》、《项目月报》、重大里程碑评审来评审软件实现活动。

项目经理定期通过项目例会、《项目月报》、重大里程碑评审或遇到重要需求分析问题时来评审软件实现活动。

QA人员评审和验证：

1.软件编码已进行了同行评审和单元测试；

2.软件编码前，需求和设计已完成并通过评审，编码完成后阶段工作产品满足输出标准；

3.软件编码符合项目定义的标准和要求；

4.软件实现活动满足准备就绪准则和完成准则；

5.按照测试计划，完成所要求的单元测试，而且测试满足其验收准则；

6.已完成了计划的测试，并记录了测试结果；

7.评审和测试发现的问题和缺陷已记录，并进行了跟踪和解决；

6相关文件

《软件测试程序》

《设计评审程序》

《服务控制程序》

《软件开发规范汇编》

7质量记录

《项目开发计划》

《配置管理计划》

《质量保证计划》

《需求分析说明书》

《概要设计说明书》

《数据库设计说明书》

《详细设计说明书》

代码

《产品安装与使用说明》

《设计评审表》

《变更请求跟踪表》

【本文档内容可以自由复制内容或自由编辑修改内容期待你的好评和关注，我们将会做得更好】

感谢您的支持与配合，我们会努力把内容做得更好！