软件项目研发管理流程精编版Word文档下载推荐.docx
《软件项目研发管理流程精编版Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《软件项目研发管理流程精编版Word文档下载推荐.docx（40页珍藏版）》请在冰豆网上搜索。
★说明：
对此规则或建议进行必要的解释。
★示例：
对此规则或建议从正或反两个方面给出例子。
本软件开发过程行为规范由技术研发部负责解释和维护。
二、软件项目整体开发流程
三、各阶段岗位职责与工作内容
序号
工作名称
负责人
参与人
审批人
工作内容
交付物
工作说明
1
立项管理
项目经理
售前经理
总经理
1.项目或产品建设内容；
2.项目风险分析；
3.明确后续工作；
4.讨论解决方案。
1.风险分析报告；
2.如需进一步讲解，交付展示PPT;
3.如确定立项，交付立项报告及解决方案
4.立项后，确认开发经理
1.立项报告、解决方案提交到开发经理后，开始需求调研准备。
1.1
项目介绍
总经理或售前经理
系统或方案简介
无
2
需求分析
售前经理、开发经理
总工程师
确认用户需求及功能边界
需求规格说明书
1.需求规格说明书由售前经理编制，提交开发经理后；
开发经理开始开发计划编制
3
开发计划
开发经理
项目经理、售前经理
1.确定开发工期；
2.明确开发人员。
3.开发计划交付甲方
项目开发计划书
开发经理完成计划编制，人员配置完成后，经项目经理提交客户审核通过，开发经理完成人员分工，开发业务启动
4
软件设计
开发工程师
1.数据库设计
2.概要设计
1.数据字典；
2.概要设计说明书
公司采用敏捷开发，开发经理需按通用模块-基础数据管理模块-业务管理模块-数据应用模块进行设计，区分无需设计的模块可直接进行开发
5
软件编码
开发工程师、测试工程师
1.完成软件编码；
2.完成详细设计说明书；
3.代码迭代及版本控制
1.软件代码及数据库
2.详细设计说明书
详细设计说明书由该功能的开发工程师编写
5.1
内部审核
1.审核数据库及代码是否按公司技术规范执行
采用定期抽样审核方式工作
5.2
版本控制
1.按公司要求进行代码迭代与版本控制；
2.完成代码备份
各研发组，可自行确认代码进行本地迭代方式，并定期将代码提交贵阳总部迭代、备份
5.3
静态质量审查
代码提交到SonarQube进行静态代码审核
代码静态质量审核报告及整改说明
进入动态测试环节前，必须提交静态质量报告
6
软件测试
测试经理
测试工程师、开发工程师
完成软件测试
1.测试计划
2.功能测试报告（含测试用例）
3.压力测试报告
采用敏捷测试，测试经理根据开发进度，逐个模块跟进测试
6.1
试运行
实际生产环境进行软件运行测试
1.软件试运行报告
取决于甲方是否提供试运行时间
7
软件部署
实施经理
项目经理、开发工程师
在生产环境进行正式系统部署及投运
项目实施报告
8
验收交付
实施工程师、售前工程师
完成项目验收并交付客户使用
验收报告
验收通过后，进行项目总结。
开发组明确运维职责后，人员开始进入其他项目
9
项目运维
1.及时发现对项目运行期间的问题和客户新需求；
2.需求甄别，需及时更改的提交开发经理；
3.保持客户沟通
运维报告、需求更改说明书
四、各阶段工作要求
1．软件需求分析
1-1：
软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。
1-2：
当产品的需求规格发生变更时，必须修订软件需求规格文档。
软件需求规格的变更必须经过评审，并保存评审记录。
1-3：
必须对软件需求规格文档进行正规检视。
1-4：
软件需求分析过程活动结束前，必须经过评审，并保存评审记录。
1-5：
在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。
说明：
参考建议1-1到1-16。
采用以下检查表检查软件需求规格文档中需求的清晰性。
问题
所有定义、实现方法是否清楚地表达了用户的原始要求？
在功能实现过程、方法和技术要求的描述上，是否没有背离了功能的实际要求？
是否没有不能理解或造成误解的描述？
采用以下检查表检查软件需求规格文档中需求的完备性。
需求定义中是否包含了有关文件（指质量手册、质量计划以及其它有关文件）种所规定的需求定义所应该包含的所有内容？
需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？
功能性需求是否覆盖了所有非正常情况的处理？
是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作了规定？
是否对所有功能与时间因素有关的方面都作了考虑？
是否标识出了所有与时间因素有关的功能？
它们的时间准则是否都说明了？
时间准则的最大、最小执行时间是否都定义了？
是否标识并定义了在将来可能会变化的需求？
是否定义了系统所有的输入？
是否标识清楚了系统输入的来源？
10
是否标识出了系统的输出？
11
是否说明了系统输入、输出的类型？
12
是否说明了系统输入、输出的值域、单位、格式等？
13
是否说明了如何进行系统输入的合法性检查？
14
是否定义了系统输入、输出的精度？
15
是否定义了系统性能的各个方面？
16
在不同负载情况下，是否规定了系统的处理能力？
17
在不同情况下，是否规定了系统的响应时间？
18
是否充分定义了关于人机界面的需求？
19
是否对需求定义进行了可行性分析和相关文件（资料）是否已归档？
20
是否对影响需求实现的因素进行了调查，调查结果是否已归档？
21
是否有经济效益分析，分析结果是否已归档？
22
是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？
23
是否评估了本项目对用户、其它系统、环境的影响特性？
24
是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？
采用以下检查表检查软件需求规格文档中需求的兼容性。
界面需求是否使软硬件系统具有兼容性？
需求定义的文档是否满足项目文档编写标准？
在矛盾时，是否有适当的标准可供选择？
采用以下检查表检查软件需求规格文档中需求的一致性。
各个需求之间是否一致？
是否有冲突和矛盾？
所规定的模型、算法和数值方法是否相容？
是否使用了标准的术语和定义形式？
需求是否与其软硬件操作环境相容？
是否说明了软件对其系统和环境的影响？
是否说明了环境对软件的影响？
所采用的技术是否与用户要求的技术一致？
采用以下检查表检查软件需求规格文档中需求的正确性。
需求定义是否满足标准的要求？
算法和规则是否有科技文献或其它文献作为基础？
是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应？
是否参照了有关的标准？
是否对每一个需求都给出了理由？
理由是否充分？
对设计和实现的限制是否都有论证？
1-6：
采用以下检查表检查软件需求规格文档中需求的可行性。
需求定义是否使软件的设计、实现、操作和维护都可行？
所规定的模型、数值方法和算法是否对待解决问题合适？
是否能够在相应的限制条件下实现？
是否能够达到关于质量的要求？
1-7：
采用以下检查表检查软件需求规格文档中需求的易修改性。
对需求定义的描述是否易于修改（如是否采用良好的结构和交叉引用表等）？
是否有冗余的信息？
是否一个需求被定义了多次？
1-8：
采用以下检查表检查软件需求规格文档中需求的健壮性。
是否有容错的需求？
1-9：
采用以下检查表检查软件需求规格文档中需求的易追溯性。
是否可从上一阶段的文档中找到需求定义中的相应内容？
需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖了？
需求定义是否便于向后继开发阶段查找信息
1-10：
采用以下检查表检查软件需求规格文档中需求的易理解性。
是否每一个需求都只有一种解释？
功能性需求是否以模块方式描述的？
是否明确地标识出了其功能？
是否有术语定义一览表？
是否使用了形式化或半形式化的语言？
语言是否有歧义性？
需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？
是否过分细致了？
需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？
需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？
1-11：
采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。
需求是否可以验证（即是否可以检验软件是否满足了需求）？
是否对每一个需求都指定了验证过程？
数学函数的定义是否使用了精确定义的语法和语义符号？
1-12：
采用以下检查表检查软件需求规格文档中的性能需求描述。
是否精确的描述了所有的性能需求和可容忍的性能降低程度？
对每一个性能应包含两方面的内容：
a.在最坏情况的执行结果
b.本性能失效后，对系统产生的影响
1-13：
采用以下检查表检查软件需求规格文档中功能需求描述。
是否清楚、明确地描述了所有的功能？
所有已描述的功能是否是必须的？
是否能满足任务书或系统目标的要求？
1-14：
采用以下检查表检查软件需求规格文档中的接口需求描述。
是否清楚地定义了所有的接口？
所有接口是否必须？
各接口间的关系是否一致、正确？
1-15：
采用以下检查表检查软件需求规格文档中的数据需求描述。
在某异常数据（如条件、标志等）下，是否有真正没有考虑到的结果？
对异常数据产生的结果是否作了精确的描述？
升级会员 