软件开发项目规范标准详Word格式文档下载.docx
- 文档编号:21370661
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:31
- 大小:1.06MB
软件开发项目规范标准详Word格式文档下载.docx
《软件开发项目规范标准详Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《软件开发项目规范标准详Word格式文档下载.docx(31页珍藏版)》请在冰豆网上搜索。
研究产品所在领域的状况,为项目论证提供依据。
研究容包括:
▪
o产品领域的现状和前景
o产品领域的商业模式和业务流程
o产品的价值和盈利空间
o产品的特性和复杂度
∙技术可行性研究
研究产品的实现技术,总结技术可行性。
o
o类似产品的当前实现技术和技术趋势
o实现技术的候选方案
o各个方案的优点、本钱和风险
o开发团队与实现技术的匹配情况
∙项目论证
基于商业和技术等方面对项目的可行性进展论证,确定项目是否开展。
如果开展项目,那么进一步论证项目的总体方案。
论证的容包括:
o商业可行性
o技术可行性
o当前产品与类似产品的比拟
o项目收益和前景
o项目的本钱和风险
o项目的总体方案
∙确定项目目标和围
项目开场时,所有相关人员必须对项目的目标和围达成共识,形成共同的项目愿景。
并把愿景表达为《项目开发大纲》向相关人员传达。
《项目开发大纲》的容包括:
概述
用三到五图表来描述产品目标、功能、平台、客户、进度表和开发职责
高级功能
用一个段落来综述产品,再用一个段落来描述每个重要的功能
不实现的功能
用一个段落来描述每个对产品有用的但本项目不实现的功能
涉众
用一个段落来明确每个重要的涉众群体和他们的风险股本
项目需求
用一个段落来讲述每个重要的项目需求
项目风险
按风险暴露量对每个重要的项目风险都用一个段落来讨论
项目回报
用一个段落综述产品的回报,其后再对每个重要的项目回报都用一个段落来讨论
结论
用一到三个段落将上述所有局部联系起来,明确项目的需求和风险,再用论点和论据来总结为什么这个项目会成功
表3-1项目开发大纲
计划阶段
图4-1计划阶段的任务和工件
∙规模、工作量评估
围绕各项计划的制定工作对项目的规模、工作量等进展评估,评估的容包括:
o模块数量与复杂度
o输入、输出和对外接口等数量与复杂度
oSLOC和功能点
o非生产性的支持工作量
o开发工作量〔人月〕
o进度与里程碑
o进度风险
∙定制项目开发计划
项目开发计划表达了项目组对整个开发周期的预期,指定了项目开发的总体方针。
与其他计划一样,项目开发计划不是固定不变的,在执行过程中要对计划进展监控,可能会根据实际情况修改计划并重新发布。
《项目开发计划》的容包括:
用三到五图表来描述产品目标、功能、平台、客户、进度表和开发职责。
〔《项目开发计划》的概述局部应该是《项目开发大纲》中概述局部的拷贝。
当项目计划改变时,修订《项目开发计划》的概述局部而不是修订《项目开发大纲》。
这样,以后在进展项目评价时,通过比拟《项目开发大纲》和《项目开发计划》的概述,就能看出项目是如何改变的〕
用一到五页的篇幅来概述产品的功能,其中,要包括这些功能的附加信息〔开发者需要这样的信息来了解实现需求〕。
项目成员
确定软件工程职能角色,以与分配到这些角色的人员数量。
软件过程
概述这个项目中所应用的软件过程。
〔具体容可在《质量保证计划》中定义〕
软件工程方法
概述这个项目中所应用的软件工程方法和技术。
〔具体容可在《质量保证计划》中定义〕
进度和工作量
这一局部要表达出整个项目进度和工作量的估计。
其中要包括:
∙对固定不变的里程碑和同步点的解释
∙在评估中的设想情况、评估中的不准确性的可能来源
∙随着项目的进展如何更新评估
〔具体进度表容可在《开发进度表》中定义〕
风险管理计划
概述这个项目中风险管理计划。
〔具体容可在《风险管理计划》中定义〕
测量
概述这个项目中要收集的测量。
软件工具
列出要使用的每一项软件工具,以与该工具所支持的任务。
项目支持
硬件支持明确所需的硬件,包括那些需要移动、获取或升级的硬件。
软件支持明确所需的软件,包括需要获取、安装或升级的软件件。
人力支持由哪个人、部门或团队为开发组的哪项任务提供支持。
表4-1项目开发计划
∙定制风险管理计划
风险管理任务包括:
风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解和风险监控【如:
图4-2】。
图4-2风险管理任务
《风险管理计划》定义这些任务的执行流程和人员分配。
《风险管理计划》的容包括:
用文字和图表概述风险管理任务的总体执行流程。
风险识别
详细说明“风险识别〞任务的实施细节和各项工作的负责人。
风险分析
详细说明“风险分析〞任务的实施细节和各项工作的负责人。
确定风险优先级
详细说明“确定风险优先级〞任务的实施细节和各项工作的负责人。
定制风险化解方案
详细说明“定制风险处理方案〞任务的实施细节和各项工作的负责人。
风险化解
当风险发生时,需要采取相应的措施化解风险。
这局部的容是描述风险化解工作的操作规和流程。
风险监控
详细说明风险监控任务的实施细节和各项工作的负责人。
表4-2风险管理计划
风险管理常会用到《TopN风险列表》,风险列表按照风险暴露量排序列出当前项目中主要的N个风险,《TopN风险列表》的容包括:
本周排名
本周的排名〔如果本周已被完全化解用“---〞表示〕
上周排名
上周排名〔如果是新识别的风险用“---〞表示〕
上表周数
该风险已上表的周数
风险
风险的名称或简述
类型
风险类型〔只针对进度相关的风险〕:
o计划编制
o组织和管理
o设计和实现
o客户和需求
o承包商
o产品
o人员
o过程
o技术
o外部环境
o开发环境
发生概率
风险发生的百分比概率
损失程度
风险发生时损失的进度〔工作日或工作周〕
暴露量
发生概率X损失程度
状态
风险的当前状态:
未发生、已发生、已化解
化解方案
简述风险的化解方案,如果有具体的化解方案文档那么到相应文档
化解进度
对已发生的风险,简述化解进度〔未发生的风险用“---〞表示〕
表4-3风险列表
∙定制质量保证计划
保证工作质量的一个重要步骤是制定一套合理的质量保证计划并贯彻执行。
《质量保证计划》的容包括:
说明编写的目的、适用围以与对相关人员的要求等
详细说明这个项目中所应用的软件过程。
详细说明这个项目中所应用的软件工程方法和技术。
工作规
对工程方法中的各种工作任务进展规,明确执行的时机、流程和准那么等。
这些工作任务包括:
常规开发活动〔需求分析、架构设计、详细设计、编码和测试、发布和实施等〕
会议〔工作例会、进度会议、审查会议等〕
评审〔方案评审、技术评审、质量评审等〕
测量〔产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等〕
其他活动〔技能培训、资料收集、部流、客户沟通等〕
表4-4工作规
∙定制开发进度计划
基于当前对项目的规模和工作量评估,定制初步的开发进度表,作为项目开发计划的组成局部。
《开发进度表》的容包括:
o项目的开场和完毕时间
o项目各个阶段的开场和完毕时间
o每个阶段的工作任务与其开场和完毕时间
o每个工作任务的子任务的与其开场和完毕时间
o里程碑和同步点
o角色的定义和任务分配
作为跟踪项目进度的重要依据,进度表在项目推进过程中需要不断细化。
另外,当实际进度与计划进度出现偏差时,需要修改良度表并重新发布。
执行阶段
图5-1执行阶段的任务和工件
∙需求分析
分析产品的关键需求、对架构设计有影响的需求和风险较高的需求,直到分析的程度能开展足界面原型设计和架构设计工作。
《需求规格说明书》的容包括:
商业或业务需求
从商业或业务角度宏观上对产品或系统的要求。
它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。
1.做什么
2.做的围
3.对结果的要求
使用者需求
从客户对软件产品或系统使用方案的角度出发,描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。
功能需求
根据上述使用者需求列出的使用方案,列出开发者必须为软件产品或系统实现的功能。
性能需求
1.运行速度、容量、并发性能
2.对资源的利用率
3.对外界输入的反应速度和准确性
4.对过失的负荷能力
系统需求
o必须适应的运行环境的要求〔包括运行平台、网络与其他硬件要求〕
o与其他系统兼容的要求〔包括与操作系统、数据库、浏览器与其他应用软件的兼容要求〕
o与外部其他系统和组件的接口要求
质量需求
o对用户重要的质量标志〔可靠性、效率性、灵活性、平安性、互操作性、稳定性、健全性、可用性〕
o对开发者重要的质量标志〔可维护性、多用转换性、重复使用性、可测试性〕
其他需求
不属于上述需求围的,但受到其他环境和商业合同影响的要求。
1.国家或地区的任何特别的标准
2.软件使用界面的特别要求
3.与知识产权有关的要求
4.软件所面对的市场和行业的规
5.客户的特别要求
开发的局限
对开发的成功与否起很大影响的因素,是开发能力的局限:
1.人员的局限
2.技术的制约和局限
3.客户的特别要求
表5-1需求分析告
《需求分析报告》的编制方式可以是多样的,例如把所有“非功能性需求〞组织成“外部接口需求〞、“质量属性需求〞和“需求约束〞。
【如:
图5-2】
图5-2需求规格说明书
∙界面原型设计
明确了系统的关键需求后,就可以进展界面原型设计工作,获取用户的反应,尽快确定产品的界面基调。
同时要编写一份《界面设计概要》文档,作为后续的界面设计工作的指导。
《界面设计概要》的容包括:
o设计的理念
o理念的来源或参考
o设计的要点
o与类似产品界面的比照
∙架构设计
架构设计从关键需求开场,建立概念性的架构,并逐步细化和验证。
最终生成架构设计说明书和架构基线代码。
架构设计的方法:
可以从几个不同的视角进展架构设计,然后汇总综合得出完整的设计。
〔架构设计的五个视图【如:
图5-3】〕
图5-3架构设计的五视图
《架构设计说明书》的容包括:
说明编写的目的、适用围以与设计原那么等。
逻辑架构
关注功能。
其设计着重考虑功能需求。
1.细化功能单元
2.发现通用机制
3.细化领域模型
4.确定子系统接口和交互机制
开发架构
关注程序包。
其设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性和易测试性等。
1.确定要开发或直接利用的程序包之间的依赖关系
2.确定采用的技术、框架等
数据架构
关注持久化数据的存储方案。
其设计着重考虑“数据需求〞。
1.持久化数据存储方案
2.数据传递、数据复制、数据同步等策略
运行架构
关注进程、线程、对象等运行时概念,以与相关的并发、同步、通信等问题。
其设计着重考虑运行期质量属性,例如性能、可伸缩性、持续可用性和平安性等。
1.确定引入哪些进程与线程
2.确定主动对象、被动对象,以与控制关系
3.处理进程线程的创立、销毁、通信机制、资源争用等
4.协议设计
物理架构
关注软件系统最终如何安装或部署到物理机器。
其设计着重考虑“安装和部署需求〞。
1.确定物理配置方案
2.确定如何将目标程序映射到物理节点
总结
基于上述的设计进展总结,并描述架构基线。
表5-2架构设计说明书
架构设计的另一个重要任务是编写架构基线代码,基线代码表述和验证架构,同时也是指导后续开发的根底代码。
架构基线代码的容包括:
o所有工程项目
o工程目录结构
o软件包结构
o导入所有依赖包
o根底公共代码
o架构框架代码
o架构框架示例代码和测试代码
o数据库框架
图5-4和图5-5展示了软件架构师的工作和成功的软件架构设计包含的容:
图5-4软件架构师的工作
图5-5成功的软件架构设计
1软件构建
软件可以分阶段进展构建,每个阶段可以使用增量的方式开发,用通过假设干个Build构建,最后发布阶段性产品成果。
〔注意:
在这里,名词“阶段〞的含义和本文其他地方的含义不一样〕
∙阶段计划
构建阶段计划的容包括:
o确定本阶段要实现的功能
o列出阶段任务
o计划Build构建数量
o细化《开发进度表》中本阶段的工作容
∙Build构建
详见:
下一节
∙阶段产品发布
构建阶段完成后发布阶段产品成果,向用户展示并承受用户反应,同时做好阶段总结。
《发布清单》的容包括:
o产品版本号和日期
o改正的Bug
o修改的功能
o实现的新功能
o其他说明
《阶段总结报告》的容包括:
o阶段任务的完成情况
o进度计划的执行情况
o用户的反应情况
o本阶段碰到的主要问题
o下一阶段的改良建议
2Build构建
Build构建以增量的方式执行阶段的开发任务,每个Build构建的周期一般不超过两星期,每一次Build构建都会发布为一个部版本,并提交测试。
测试发现的问题留待以后的Build构建解决。
∙Build计划
《Build计划》的容包括:
o本次Build的版本号
o本次Build的历时
o本次Build的工作任务
▪要解决的遗留Bug
▪本应由以前的Build实现的,但推迟到本次Build实现的功能
▪要实现的新功能
▪其他工作任务
o工作任务分配
∙需求细化
根据《Build计划》,细化本次Build要实现的需求,细化到能进展详细设计为止。
有了细化的需求后就编写本次Build的测试计划。
《测试计划》的容包括:
o功能测试
▪要测试的功能
▪测试时间
▪测试方式
▪验收标准
o其他测试〔性能测试、边界测试、使用界面测试、可用性测试、平安性测试等〕
▪要测试的容
▪测试时间
▪测试方式
o。
。
∙界面设计
根据细化的需求设计用户界面,当界面确定后即可编写测试用例。
《测试用例》的容包括:
o测试用例对应的功能模块
o测试用例的性质〔功能测试用例、性能测试用例、。
〕
o输入〔或操作步骤〕
o期望输出
o实际输出〔执行测试后再填写〕
o是否通过〔执行测试后再填写〕
∙详细设计
详细实际每项需求的实现方法,对于重要的设计决策、算法、公共模块和外部接口等必须以模块设计文档的形式进展记录。
《模块设计文档》的容包括:
o模块名称
o设计思想
o设计图表〔类图、流程图等〕
o要点描述〔包、接口、类、方法、算法、设计模式〕
o测试方式
∙编码、单元测试
编码和单元测试是开发人员的工作,对于重要的代码都必须进展单元测试,编写代码必须遵守以下准那么:
o遵守编码规
o编码前必须充分理解相关的需求
o编码前先进展设计,把流程理顺
o注意设计方法和设计模式的灵活运用
o总体考虑问题,使代码遵从架构并容易测试
o设计时要充分考虑异常情况和临界条件
o严禁Copy-Paste,注意提取公共代码,在编码过程中实现重构
o异常处理必须记录日志,严禁草率地直接打印异常信息
o灵活运用ASSERT()/VERIFY()等断言来帮助调试程序
o单元测试是程序员的工作,所以编码完成后必须对代码严格测试
o功能代码完成后必须先做以下4件事情:
▪编译代码,保证编译通过
▪〔不运行程序〕对代码进展全面检查
▪用调试模式启动程序,一行一行单步执行代码,并注意调试输出
▪改变条件,让代码尽可能走遍所有程序分支
oCheckIn代码前必须保证能编译通过
∙创立Build
代码集成发布前需冻结代码,所有人把要提交的代码CheckIn,并保证编译后的程序能在测试效劳器上正常启动,界面能正常翻开。
同时还要提交Build清单。
《Build清单》的容包括:
oBuild版本号和日期
∙集成测试
按照《测试计划》针对《Build清单》执行《测试用例》,测试完成后编写测试报告。
《测试报告》的容包括:
o测试用例汇总〔用例数量、通过的用例数量、未通过的用例数量等〕
oBug汇总〔Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等〕
o测试计划执行情况
o测试总结
控制阶段
图6-1控制阶段的任务和工件
∙风险管理
开发期间要对风险进展监控,定期检查、更新和发布《风险列表》。
∙质量管理
1〕评审
评审是质量保证的重要环节,原那么上每个重要的工作任务或阶段完毕前都必须经过评审,如:
方案评审、计划评审、需求评审、设计评审和代码评审等,工作是否被通过、是否需要修改或重做均由评审结果断定,评审结果以《评审报告》的形式发布。
《评审报告》的容包括:
根本信息
评审主题、时间、提交者、评审者等
评审容
评审容的列表和简述
问答记录
评审过程中重要的问答记录
评审结论
整个评审的结果,如:
1.完全通过,无需修改
2.根本通过,需要作小量修改,但不必再评审
3.大体通过,需要作一些修改,之后再评审
4.不通过,需要作大幅修改,之后必须重新评审
评审意见
针对评审结论提出的意见和建议
表7-1评审报告
2〕测试
测试是对被构建产品最直接有效的质量保证措施,测试完毕后需要提交《测试报告》。
∙变更管理
开发过程中经常会出现多种变更,如:
需求变更、设计变更或人员变更等。
这些变更通常会对开发进度造成影响,因此要对变更与其处理过程进展跟踪,最后报告变更的处理结果。
《变更处理报告》的容包括:
变更主题、发生时间等
详细信息
变更的详细描述
变更处理
变更的处理方式和步骤
处理结果
变更的处理结果
变更影响
变更对项目造成的影响
表7-2变更处理报告
∙进度监控
项目进度会议是了解项目实际进度的有效措施,在会议中评审工作报告,解决遇到的问题并计划下一步工作:
《工作报告》的容包括:
1.
1.根本信息:
报告者、汇报时间、工作时间段等
2.工作情况:
已完成的工作、未完成的工作
3.遇到的问题:
工作中碰到的阻碍
4.工作计划:
下一步的工作计划
项目进度会议的另一个重要议题是审查进度表,了解项目实际进度与计划进度的差异。
为进度表调整和资源调配提供重要依据。
∙测量
在项目开发过程中,收集一些关键的测量,对了解项目状态和进展项目决策很有帮助,同时也为以后的项目提供历史数据参考。
每个测量都要生成测量报告并存档。
《测量报告》的容包括:
1.根本信息,包括测量主题、测量时间、测量者等
2.测量容和测量值
3.测量分析
完毕阶段
图7-1控制阶段的任务和工件
∙产品测试
因为产品即将验收和发布,所以必须对产品进展完整测试,产品测试比其他测试要求更严格,当产品的质量到达发布的要求后才能发布。
产品的质量由《测试报告》表达。
∙RC版本发布
发布RC版本让用户体验并收集反应意见,为产品验收作准备。
RC版本发布后,产品不应该有大改动,一般只是界面的局部调整。
∙编制用户文档
针对不同的使用者角色,编制相应的用户文档,对管理者用户需要提供《安装、维护指南》,对普通用户需要编制《产品使用手册》。
《安装、维护指南》的容包括:
1.产品各组件的说明
2.产品部署架构
3.安装、配置和卸载等步骤
4.启动、停止和重启等操作
5.其它操作:
日志、备份、复原等
《产品使用手册》的容包括:
1.产
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 项目 规范 标准
![提示](https://static.bdocx.com/images/bang_tan.gif)