项目流程规范体系Word格式.docx
- 文档编号:16756267
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:29
- 大小:85.09KB
项目流程规范体系Word格式.docx
《项目流程规范体系Word格式.docx》由会员分享,可在线阅读,更多相关《项目流程规范体系Word格式.docx(29页珍藏版)》请在冰豆网上搜索。
测试阶段
该程序将被全面地测试,已编制的文档将被检查审阅。
一般要完成测试分析报告。
作为开发工作的结束,所生产的程序、文档以及开发工作本身将逐项被评价,最后写出项目开发总结报告。
6.
运行与维护阶段
软件将在运行使用中不断地被维护,根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。
备注:
在整个开发过程中(即前五个阶段中),开发集体要按月编写开发进度月报。
2.2.软件开发模型
软件开发模型是指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。
本文列出和我们项目流程规范体系相关的软件开发模型:
瀑布模型和迭代模型。
2.2.1.瀑布模型
1970年WinstonRoyce提出了著名的“瀑布模型”,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。
当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
瀑布模型的致命问题是由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险,并且早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
2.2.2.迭代模型
迭代模型是RUP(RationalUnifiedProcess,统一软件开发过程,统一软件过程)推荐的周期模型。
在RUP中,迭代被定义为:
迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:
(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程,实质上,每一次迭代类似小型的瀑布式项目。
RUP认为,所有的阶段(需求及其它)都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
迭代和瀑布的最大的差别就在于风险的暴露时间上。
任何项目都会涉及到一定的风险。
如果能在生命周期中尽早确保避免了风险,那么您的计划自然会更趋精确。
有许多风险直到已准备集成系统时才被发现。
不管开发团队经验如何,都绝不可能预知所有的风险。
2.3.软件测试模型
该流程规范中软件测试模型将使用V模型。
V&
V:
验证与确认(Verification&
Validation)
2.4.软件测试理论
将软件测试理论总结如下:
测试过程
测试依据
测试方法
测试内容
单元测试
源代码和详细设计文档
白盒测试
集中于单个模块的功能和结构检验,其测试内容主要包括模块接口、局部数据结构、重要的执行路径、错误处理和边界测试。
集成测试
概要设计文档和详细设计文档
灰盒测试
集中于模块组合的功能和软件结构检验,其测试内容主要包括模块组装中可能出现的问题,即数据穿过接口可能丢失、一个模块可能破坏另一个模块的内容、子功能组装可能不等于主功能、全程数据结构问题、误差累积问题。
系统测试
软件需求规格说明书
黑盒测试
集中于论证软件需求的可追溯性,主要包括测试软件功能和性能是否与软件需求一致、测试软件配置的所有程序与文档是否正确完整而且一致。
系统测试还包括如下测试范围:
性能测试
测试的目的就是通过测试,确认软件是否满足产品的性能需求,同时发现系统中存在的性能瓶颈,并对系统进行优化。
性能测试是检测系统在一定负荷下的表现,是正常能力的表现。
压力测试
模拟巨大的工作负荷看系统在峰值使用情况下是否可以正常工作。
增加负载来测试系统性能的变化,确定什么负载条件下系统性能处于失效状态。
压力测试是极端情况下系统能力的表现。
容量测试
测试系统对超额的数据容量的处理能力,确定数据方面的承受能力。
健壮性测试
测试的重点是出现故障后系统是否能够自动恢复或忽略故障继续运行。
安全性测试
检查系统对非法侵入的防范能力
可靠性测试
度量软件的可靠性
恢复性测试
与备份测试
恢复性测试检查系统的容错能力,当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。
备份测试就是检查系统在发生软件或硬件失败时备份数据的能力。
兼容性测试
检查软件之间是否能够正确的进行交互和共享信息。
安装性测试
软件安装过程测试,并且考虑与现有软件系统的配合使用问题。
可用性测试
测试用户使用和学习产品的容易程度。
配置性测试
验证系统在不同的系统配置下能否正确工作。
文档性测试
针对系统提交给用户的文档进行验证。
回归测试
不需要进行全面的测试,而是根据修改情况进行有选择性的测试。
验收测试
客户需求规格说明书
将最终产品与最终用户的当前需求进行比较的过程,在生产环境中而不是开发环境中进行。
用户体验测试
用户感受
----
用户体验测试主要是从用户操作的合理性和易用性等角度对网站系统进行检查,来发现使用或操作上的问题。
要保证用户界面易于使用;
对输入值可容错、响应时间在正常范围、输出信息正确易读、且没有歧义,出错提示信息能够引导用户去解决问题等等。
Alpha测试和Beta测试:
1.Alpha测试是用户在模拟真实环境下进行测试,有测试人员参与。
2.Beta测试是发布一个版本后,用户在真实使用环境下进行测试,无测试人员参与。
在客户场地,由客户进行的对产品预发布版本的测试。
2.5.快速原型设计
当我们需要进行思想交流、概念探索、业务需求表现、交互行为模拟时,快速原型设计无疑是最好的方法。
在产品设计中,快速原型法(RapidPrototyping)是一种有效的、高效的、以用户为中心的技术,可以帮助用户体验专家、设计师、工程师创造更加有用、可用的产品。
通常,快速原型设计指在尽可能短的时间内制作能够表现产品基本特征的原型,包括整体的信息架构、基础的交互功能以及基本的页面元素等,必要时还需要添加色彩因素。
快速原型设计的结果我们通常称之为低保真原型,其目的并不是为了交付,而是为了沟通、测试、修改等,解决产品中主要的不确定问题,所以快速原型设计需要具有快速构建、轻松修改、容易操作、关注流程、抛弃成本低的特点。
推荐使用AxureRP(RapidPrototyping)做原型设计。
3.项目管理流程规范
项目经理需要从整体去把握项目,非常熟悉项目流程,各个项目角色的职责定义,各个阶段的输出文档。
3.1.整体流程规范
项目经理负责将下面表格中的开发流程,以及每一个项目流程的项目工期,开始时间,结束时间体现在《项目开发计划》中。
项目流程
负责部门
输出文档
项目立项阶段
产品分析立项
市场部,产品部
项目立项书
项目调研及分析阶段
产品市场调研
市场调研报告
产品需求分析
产品部
产品规划方案
项目规划设计阶段
产品快速原型设计
产品快速原型,
产品需求说明书
产品页面设计
页面原型
项目开发设计阶段
概要设计
开发部
概要设计说明书
详细设计
详细设计说明书
数据库设计
数据库设计说明书
9.
项目开发编程阶段
开发编程
开发周报
测试分析和系统整合
测试计划
11.
项目测试阶段
产品内测
测试部、产品部
测试分析报告
产品外侧
13.
项目上线商用阶段
产品上线
售后服务部
验收测试报告
运行维护
产品运行报告
季度巡检报告
故障处理方案
上面的项目流程可以和软件生存周期的6个阶段(可行性与计划研究阶段;
需求分析阶段;
设计阶段;
实现阶段;
测试阶段;
运行与维护阶段)很好对应起来。
3.2.项目角色职责
为了实施规范化的过程管理,对软件项目小组的角色必须进行分工。
在项目小组人数较少的情况下,往往一人身兼数职,但是这些角色是绝对不能忽略的。
角色
主要职责
项目管理人员
ProjectManager
制定开发日程,配置资源,与外界沟通,保证项目顺利完成。
系统分析人员
SystemAnalyst
负责项目的调研,设计工作,包括需求分析,概要设计,详细设计等
界面设计人员
UserInterfaceDesigner
界面美工
软件开发工程师
SoftwareDevelopingEngineer
软件测试工程师
SoftwareTestingEngineer
质量控制工程师
QualityControlEngineer
检验产品的质量,保证产品符合客户的需求;
是产品质量检查者。
在软件项目范畴就是软件测试工程师。
7.
质量保证工程师
QualityAssuranceEngineer
CMM模型要求建立QA角色,这里的QA类似于过程警察,是过程质量审计者,主要职责是,检查开发和管理活动是否与已定的过程策略、标准和流程一致,检查工作产品是否遵循模板规定的内容和格式。
8.
配置管理员
ConfigurationManagementOfficer
负责项目期间的配置管理工作
3.3.项目相关文档
很多文档名称不同,但是内容是一致的,比如可行性分析与市场调研报告,还有很多就不一一举例。
该流程规范不会刻意去统一文档名称,主要是让学生对文档有更多的认识。
项目相关文档
答标书
SOC(statementofcompliance)
设备清单
BOQ(billofquantity)
客户需求规格
CRS(CustomerRequirementsSpecification)
工作任务书
SOW(statementofworks)
SRS(SoftwareRequirementsSpecification)
如下的2个都是软件需求规格
需求分析报告
项目开发计划
10.
项目开工报告
明确指出项目参加人员、任务、进度。
设计开发任务书
12.
配置管理计划编写规范
配置管理计划表
14.
RP原型(RapidPrototyping)
产品原型简单的说就是产品设计成形之前的一个简单框架,对网站来讲,就是将页面模块、元素进行粗放式的排版和布局,深入一些,还会加入一些交互性的元素,使其更加具体、形象和生动。
这里设计出来的页面是粗糙的。
15.
对于基于Web的企业应用,则要做一个漂亮的页面原型。
这个页面原型不需要有任何后台程序支持,业务逻辑可以用页面间的跳转、假设的数据简单表示。
这里设计出来的页面是经过美工的。
16.
17.
18.
要求提供ER图
19.
20.
测试组长根据SOW编写《测试计划》,其中包括人员,软件硬件资源,测试点,集成顺序,进度安排和风险识别等内容。
21.
测试方案
测试组长组织测试成员编写《测试方案》,测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介,测试思路和详细测试方法三部分的方案。
测试方案覆盖了测试需求点
22.
测试用例
测试用例根据《测试方案》编写的,保证用例的可执行和对需求的覆盖。
测试用例需要包括测试项,用例级别,预置条件,操作步骤和预期结果。
测试用例应该覆盖测试方案
23.
根据《测试计划》进度安排,测试组长进行多轮次的测试,每轮测试完成后测试组长需要编写测试报告,其中包括用例执行通过情况,缺陷分布情况,缺陷产生原因,测试中的风险等等,这时测试人员就修改增加测试用例。
待到开发修改完bug并转来新的测试版本,测试部开始进行第二轮的系统测试,首先回归完问题单,再继续进行测试,编写第二轮的测试报告,如此循环下去,直到系统测试结束。
24.
25.
在系统测试期间,测试人员还需要编写验收手册,验收用例和资料测试用例等。
26.
27.
用户手册
28.
项目结束报告
29.
30.
31.
3.4.文档裁剪规则
尽管在文件编制中存在着很多灵活性,然而,文件的编制确实是非常必要的,其意义如前所述。
为了控制这种灵活性,保证文件编制能达到应该达到的目的,对于具体的软件开发任务,应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。
一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力,制定一个文件编制实施规定,说明在什么情况下应该编制哪些文件。
为了避免在软件开发中文件编制的不足或过分,一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来,这就是本例的出发点。
软件的规模不妨分为四级:
软件规模
小规模软件
源程序行数小于5000的软件
中规模软件
源程序行数为10000~50000的软件
大规模软件
源程序行数为100000~500000的软件
特大规模软件
源程序行数大于500000的软件,可进一步把本指南规定的十四种文件按实际需要扩展成更多种类。
至于源程序行数为5000~10000(小到中之间),50000~100000(中到大之间)的软件,其文件编制要求介于两级之间,可根据一个软件产品的具体情况,由项目负责人参照《产品文件体系》表的规定,确定需要编制的文件种类。
对上述的四级软件的文件编制要求分别列于如下:
软件需求与开发计划
可行性报告
对应大规模软件所规定的文件可进一步细分
软件需求说明
数据要求说明
软件设计说明
概要设计说明
详细设计说明
数据库设计说明
使用说明
操作手册
模块开发卷宗
项目开发总结
开发进度月报
4.软件开发流程规范
项目启动阶段对应需求分析与规划阶段,项目实施阶段对应软件开发阶段。
4.1.项目启动阶段
在进入具体项目实施之前为获得明确需求或进行完备可行性调研及整体策划所花费的时间,分为第一阶段与第二阶段,第一阶段为明确需求阶段,第二阶段为具体策划阶段。
阶段
明确需求阶段
项目启动进入需求分析,项目负责人负责全程的需求管理,组建需求分析小组,了解并协调客户的软件目标,需求分配,接口标准,测试与验收标准,交付期需求,预算限制,资源限制。
确定明确具体的需求,包括软件开发环境与技术,软件设计、编程、测试的需求和标准,配置管理需求,质量保证需求,项目风险及降低风险的策略。
项目负责人需提交编制详细的《软件需求规格说明书》,并经客户方确认。
具体策划阶段
经过客户方确认后,下达《设计开发任务书》。
指定相关的项目负责人、配置管理员、测试、开发人员等相关人员。
项目负责人编制《项目开发计划》,项目开发计划应包含测试阶段的计划活动;
配置管理员负责依据《配置管理计划编写规范》编制《配置管理计划表》,提交管理部门负责人审批;
并组织《项目开发计划》、《配置管理计划表》的评审。
《项目开发计划》的审批:
《项目开发计划》由研发部门负责人组织评审,参加人员包括但不限于:
项目负责人以及项目相关部门与人员。
评审活动生成记录文件《设计开发评审表》。
评审通过,经管理部分负责人批准后正式生效并执行。
《项目开发计划》得到评审通过后,有项目负责人提供《项目开工报告》。
由软件配置管理员按照《配置管理》对《项目开发计划》、《项目开工报告》进行配置管理。
4.2.项目实施阶段
在获得明确需求或通过可行性评估后为实现项目所做的设计和实现。
系统设计和设计评审。
系统设计报告包括:
✧概要设计说明书
✧详细设计说明书
✧数据库设计说明书
设计人员按《项目开发计划》关于进度和阶段划分的要求,根据《软件需求规格说明书》进行系统设计,设计过程应考虑软件产品和/或软件项目的使用要求,及测试和维护的要求。
《系统设计报告》在提交之前必须进行评审。
主要由项目负责人、项目设计人员参加评审。
评审的内容可以包括以下方面:
�该设计能否满足规定的功能和性能要求;
�设计是否满足相应的设计规范;
�设计是否满足下一阶段工作的输入要求;
在进入下一阶段工作前,所有已发现的错误或缺陷是否均已消除,或虽未消除但继续进行工作的风险已弄清楚。
评审生成《设计开发评审表》。
没有通过评审的《系统设计报告》由设计人员负责按照评审意见进行修改,修改后重新评审。
如果在软件开发过程中需要进行对《系统设计报告》修改时,须填写“设计更改申请单”申请更改,经审核批准后方可修改。
编码实现
编码实现前,项目负责人需要提供《设计任务单》,明确各项任务及其实现人、实现期限、实现文档等。
项目开发人员应根据所要实现的系统要求选用相应的编程工具,并遵守《计算机源代码编写规范》、《项目开工报告》、《设计任务单》中确定的标准与规程进行系统编码。
开发人员按照《系统设计报告》的要求实现系统编码,以满足用户对系统功能和质量的要求。
在编码实现的过程中,开发人员应注意保存必要的编码信息和用户使用信息,完成编码后,应整理这些信息,并编写《用户手册》。
4.3.总结阶段
项目的实现跟踪和评估
《月度工作计划报告》包括以下各项内容:
�项目目前的进度与状态
�本月主要成绩
�下月项目进度
�需要解决的问题和计划变更
1)项目完成后,应进行项目总结,由项目负责人编写《项目结束报告》。
2)《项目开发总结报告》需项目负责人与项目管理部门共同评审。
最终归档
项目完成或终止后,全部项目资料、文档与软件项目交管理部门归档。
质量记录
设计开发评审表
设计更改申请单
月度工作计划报告
项目开发总结报告
5.软件测试流程规范
软件测试流程分3个阶段:
计划与设计阶段,实施测试阶段,总结阶段。
核心原则:
测试从需求开始。
5.1.计划与设计阶段
召开测试启动会议:
测试经理召集项目经理、开发经理开会确定测试交接时间,得到当前最新的相关资料。
进行规模预估并成立测试团队,完成《测试计划》。
输入条件:
项目进入需求分析阶段。
工作内容:
开发团队与测试团队交接测试内容,对测试目标达成一致,商讨测试计划的可行性,统一项目组的目标和测试的工作重点。
退出标准:
明确测试内容与重点,测试方提交《测试计划》
责任人:
项目经理,测试经理
设计测试用例:
在需求分析文档确立基线以后,测试组需要针对测试需求编写测试用例,在实际的测试中,测试用例将是唯一实施标准。
测试需求明确,测试计划明确
根据每一步测试计划编写全部的测试用例
测试用例需要覆盖所有的测试需求
测试工程师
5.2.实施测试阶段
实施
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 流程 规范 体系