软件项目管理课程设计 第一组Word格式文档下载.docx
- 文档编号:21360314
- 上传时间:2023-01-30
- 格式:DOCX
- 页数:30
- 大小:628.33KB
软件项目管理课程设计 第一组Word格式文档下载.docx
《软件项目管理课程设计 第一组Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《软件项目管理课程设计 第一组Word格式文档下载.docx(30页珍藏版)》请在冰豆网上搜索。
对丢失图书的赔偿金额设置
(四)应达到的技术指标和参数
为了保证系统能够长期、安全、稳定、可靠、高效的运行,图书管理系统应该满足以下的性能需求:
1、系统处理的准确性和及时性
系统处理的准确性和及时性是系统的必要性能。
在系统设计和开发过程中,要充分考虑系统当前和将来可能承受的工作量,使系统的处理能力和响应时间能够满足学校对信息处理的需求。
2、系统的开放性和系统的可扩充性
图书管理系统在开发过程中,应该充分考虑以后的可扩充性。
例如用户查询的需求也会不断的更新和完善。
所有这些,都要求系统提供足够的手段进行功能的调整和扩充。
而要实现这一点,应通过系统的开放性来完成,既系统应是一个开放系统,只要符合一定的规范,可以简单的加入和减少系统的模块,配置系统的硬件。
通过软件的修补、替换完成系统的升级和更新换代。
3、系统的易用性和易维护性
图书管理系统是直接面对使用人员的,而使用人员往往对计算机并不时非常熟悉。
这就要求系统能够提供良好的用户接口,易用的人机交互界面。
要实现这一点,就要求系统应该尽量使用用户熟悉的术语和中文信息的界面;
针对用户可能出现的使用问题,要提供足够的在线帮助,缩短用户对系统熟悉的过程。
4、系统的标准性
系统在设计开发使用过程中都要涉及到很多计算机硬件、软件。
所有这些都要符合主流国际、国家和行业标准。
5、系统的先进性
目前计算系统的技术发展相当快,做为图书管理系统工程,在系统的生命周期尽量做到系统的先进,充分完成企业信息处理的要求而不至于落后。
这一方面通过系统的开放性和可扩充性,不断改善系统的功能完成。
另一方面,在系统设计和开发的过程中,应在考虑成本的基础上尽量采用当前主流并先进且有良好发展前途的产品。
6、系统的响应速度
图书管理系统系统在日常处理中的响应速度为秒级,达到实时要求,以及时反馈信息。
在进行统计分析时,根据所需数据量的不同而从秒级到分钟级,原则是保证操作人员不会因为速度问题而影响工作效率。
3、项目进度计划
(一)分解项目工作
采用图表方式进行任务分解的分解结果如下图所示。
(二)项目工作关系表
任务
编码
任务名称
工作代号
前期工作
后期工作
持续时间
(天)
101
投资必要性
A
201
1
102
技术的可行性
B
103
财务的可行性
C
104
组织的可行性
D
105
经济的可行性
E
106
社会的可行性
F
107
风险因素控制的可行性
G
了解客户的业务及目标
H
101,102,103,104,105,106,107
202
5
编写软件需求报告
I
203,206
3
203
性能需求
J
204
可靠性和可用性需求
K
205
出错处理需求
L
206
接口需求
M
207
将来可能提出的需求
N
208
约束
O
209
逆向需求
P
2
301
系统的基本处理流程
Q
203,204,205,206,207,208,209
302
系统的组织结构
R
303
模块划分
S
307
304
功能分配
T
305
接口设计
U
306
运行设计
V
10
数据结构设计
W
303,304,305,306
308
9
出错处理设计
X
401
6
主要算法
Y
402
15
数据结构
Z
403
类的层次结构
A1
501
B1
401,402,403
601
测试
C1
701
软件交付
D1
(三)项目甘特图
(四)网络进度计划图
(五)里程碑计划
序号
里程碑事件
交付成果
预计完成时间(天)
需求分析完成期
需求分析报告说明书
19
概要设计完成期
总体设计书(包括模块划分、功能分配、接口设计、运行设计、数据结构设计、出错处理设计)
40
详细设计完成期
主要算法设计说明书、数据结构设计说明书、用户手册
30
4
编码完成期
编码报告
测试完成期
测试报告
软件交付完成期
验收报告
4、项目规模成本估算
(二)项目规模估算表
编号
估计值
(人天)
小计
总计
100
可行性分析
98
200
需求分析
300
概要设计
400
详细设计
(三)计算开发成本
项目规模是90人天,开发人员成本参数为:
750元/天
内部的开发成本为:
750*98=73500
开发成本为:
73500元
(四)计算管理、质量成本
根据经验,
管理任务和质量任务为:
20%*开发任务
所以,项目的管理和质量成本为:
20%*开发成本
=20%*73500
=14700元
(五)直接成本
14700+73500=88200元
(六)计算间接成本
间接成本包括前期合同费用、房租、水电、培训、员工福利、客户服务等。
根据经验,采用公式:
间接成本=25%*直接成本
间接成本=25%*88200
=22050元
(七)计算总估算成本
项目总估算成本=直接成本+间接成本
=88200+22050
=110250元
(八)项目报价
利润是40%,其中风险基金10%,利润为15%,税费为5%。
则:
项目总报价=110250*1.4
=154350元
5.项目质量计划
(一)项目质量保证组织
1)组织机构
在项目实施期间成立项目质量保证组织,该组织由质量保证人员和项目经理等组成。
项目经理负责质量监督工作及项目进展过程中各环节的质量把关,开发经理负责质量控制工作,质量保证人员负责质量保证的工作。
组织结构如下图所示:
2)职责
在本项目中,质量保证组织的职责如下:
(1)高层管理
高层管理是公司负责质量的高级管理,其质量职责如下:
.受理项目内不能解决的不符合问题。
.负责听取质量保证组的工作报告,评审质量保证活动和结果。
.参加有关质量保证过程改进的评审。
(2)项目质量保证人员
质量保证人员的质量职责如下:
.
.负责项目实施过程中,对项目实施情况进行监督,包括对项目实施过程和工作产品进行监督检查。
.实施项目组成员的质量保证培训。
.制定质量保证计划。
.按计划实施审计活动,依照质量保证计划执行评审/审计,并记录执行中发现的不符合项。
.对不符合问题提交不符合项报告,跟踪并验证纠正措施的执行情况。
.对项目内不能解决的不符合项问题,向高层管理提交报告。
.向项目经理报告项目质量工作状况和质量度量结果。
.定期向项目组报告质量活动的结果。
.制定质量保证的过程改进计划,记录过程数据。
(3)项目经理
项目经理的质量职责如下:
.评审质量计划。
.与质量保证人员一起协商不符合项问题的纠正措施,并安排资源实施纠正措施。
.定期评审质量保证活动和结果。
(二)质量目标
根据企业的质量方针和质量目标,结合本项目特点,制定项目的总体质量目标:
1)基于需求的测试覆盖率为100%。
2)软件功能测试用例通过率不低于95%。
3)每个阶段评审中发现的问题都已经解决或得到适当处理。
4)产品发布时不存在严重问题,以及以上的缺陷。
注:
严重问题指导致系统或模块不能正常工作的问题。
结合以往的项目经验和企业的质量相应标准,制定质量标准如下表所示。
项目
具体描述
计划
实际
缺陷排除率
(缺陷数/页)
需求检查
系统总体设计检查
(缺陷数
/KLOC)
详细设计复核
25
详细设计检查
代码复查
65
50
代码检查
20
18
编译
单元测试
14
系统集成
系统测试
(三)质量策略
为了保证提交给用户的产品是高质量的,实施过程中采取的质量保证措施包括:
1)将质量贯彻到日常的项目进展过程中;
2)应该特别注意项目工作产品质量的早期评审工作,无论是质量保证还是质量控制,采取的策略都是早期预防和早期排除缺陷。
(四)质量保证活动
1)产品审计
产品审计由质量保证人员来进行,检查项目产品是否达到质量目标。
质量保证人员可以有选择性地审计项目生存期中创建的工作产品,以验证是否符合适当的标准,是否进行了质量检查。
下表便是质量审计一览表。
质量审计一览表
项
审计对象
审计阶段
参照标准
软件项目计划
计划结束
企业质量体系
软件配置管理计划
软件质量保证计划
总体设计文档
设计结束
企业质量体系和项目计划
详细设计文档
数据库表和编码规范
7
产品代码
每个阶段实施结束
8
测试结束
测试计划
用户文档
2)过程评审
项目严格按照组织定义的软件过程进行开发,过程评审的具体依据参照企业的过程规范,保证项目中的所有过程活动都在实施范围内。
在每次评审之后,要对评审结果做出明确的决策并形成评审记录。
评审可采取文件传阅、评审会等形式。
质量保证人员负责对项目过程进行监督,将发现的问题和解决情况在每周的例会上通报,对没有解决的问题进行讨论,对不能解决的问题提交高级管理者处理。
每个周末,进行一次配置管理审核,确认配置管理工作是否正常进行。
根据公司的质量保证体系和本项目的具体特点,确定项目执行过程如下:
(1)项目规划过程及产品标准。
(2)项目跟踪管理过程。
(3)需求分析过程及产品标准。
(4)系统设计过程及产品标准。
(5)详细设计过程及产品标准。
(6)调试运行过程及产品标准。
(7)代码走查过程及代码编写标准。
(8)产品集成测试过程及产品标准。
(9)开发环境中的执行规则。
(10)测试环境中的执行规则。
(11)质量保证过程及其标准。
(12)配置管理过程及其标准。
(五)质量控制活动
质量控制活动包括代码走查、单元测试、集成测试、环境测试等,由开发人负责,详见进度计划。
编码人员在编写代码时要进行同步单元测试,单元测试要达到分支覆盖,产品通过单元测试和编码检查后,应提交给测试部进行集成测试、系统测试。
测试部的测试应达到质量目标要求,软件发布时应达到测试通过准则的要求。
(六)质量保证的报告途径
质量保证人员对于每次审计活动发现的不符合项,应该和项目经理协商不符合项的纠正措施并预定完成日期,若和项目经理存在意见分歧,质量保证人员可以上报给高层管理者,由高层管理者决定最后的措施。
同时,不符合项在项目周例会中汇报。
对不符合项,质量保证人员要在预定完成日期内重新审计,验证不符合项的纠正情况,若超过预定完成日期1周仍然有没解决的不符合项,质量保证人员上报给高级管理者,由高级管理者决定最后的措施。
质量保证人员有独立的汇报途径,日常的汇报途径如下:
.将发现的问题通知项目经理,协调纠正措施。
.将项目组内不能协调的问题汇报给高级管理者,由高级管理者协调解决。
.将日常工作和过程数据汇报给质量经理,由其统一收集并进行统计。
(七)记录的收集、维护和保存
项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录,对于项目中问题的处理也需要形成记录保存。
每周由质量保证人员根据任务清单的审计任务进行审计活动,并收集各活动的过程数据。
6、软件项目团队
(一)团队组织及职责
·
市场部:
负责与用户的协调工作
负责项目相关的商务活动
负责用户需求的接口
配合项目经理的资源协调活动
负责产品的验收活动
负责系统的维护活动。
项目经理:
负责项目的组织和规划
负责项目计划制定和维护
负责项目的跟踪和管理
负责资源的分配和协调活动
负责各组织和计划之间的协调活动
负责与市场部的协调活动
软件开发:
负责项目的软件开发,包括设计、编码、单元测试和集成测试
负责产品质量控制的工作
负责配合质量保证的活动,如系统测试、文档编制等
配合产品验收的相关活动
质量保证:
负责项目过程和产品规范的制定
负责项目过程的质量保证活动,包括过程评审和产品审计
配置管理:
负责项目的配置管理活动
负责软件产品的提交。
用户:
确保相关责任的实施
参与项目的组织和规划
负责产品的验收工作
(二)项目的沟通计划
为了保证项目开发过程的顺利进行和信息的有效沟通,特要求如下的沟通计划:
1)每天17:
00-17:
30,项目组成员进行口头交流。
2)每周五的14:
00前提交周报告,格式见模板。
3)每周五的15:
00,召开项目周例会,会后发布会议纪要给相关的项目人员,其中说明项目的进展和存在的问题。
4)及时提交问题报告,问题报告可以通过网络提交,项目经理会及时获取问题信息。
7、软件项目配置管理计划
(一)引言
(二)组织及职责
1)确定配置管理者,SCCB(配置控制委员会)成员。
2)项目经理是SCCB的负责人。
3)配置管理的角色和职责见下表。
配置管理角色职责表
角色
人员
职责
配置管理员
曾申申
1)制定《配置管理计划》
2)创建和维护配置库
SCCB负责人
徐周
1)审批《配置管理计划》
2)审批重大变更
SCCB
张锦晖
审批某些配置或基线变更
(三)配置管理环境
由于本项目属于中小型项目,工期也不是很长,所以采用SourceSafe作为配置管理工具。
1)目录结构(见下表)
配置库的目录结构
内容
说明
路径
TCM
技术合同管理
$\prj_TSGL\TCM
RM
需求管理
$\prj_TSGL\RM
SPP
$\prj_TSGL\SPP
SPTO
软件项目跟踪与管理
$\prj_TSGL\SPTO
SCM
软件配置管理
$\prj_TSGL\SCM
SQA
软件质量保证
$\prj_TSGL\SQA
SPE
软件
产品
工程
设计
$\prj_TSGL\SPE\DESIGN
源代码
$\prj_TSGL\SPE\SOURCECODE
目标代码
$\prj_TSGL\SPE\BUILD
$\prj_TSGL\SPE\TEST
发布
$\prj_TSGL\SPE\RELEASE
2)用户及权限(见下表)
类别
权限
配置管理者
负责项目配置管理,对库拥有所有权限
项目经理
读
质量保证人员
张祥
开发人员
曾申申、张锦晖、徐周
高层管理
奇张
(四)配置管理活动
1)配置项标识
命名规范
命名规范适用于过程文档、生存期中各阶段的计划、需求、设计、代码、测试、手册等文件。
本项目文件命名规范由5个宇段组成,从左到右依次为:
公司、项目、类型、编号和版本号,如下图所示。
这些字段用一横线(—)分隔。
、
类型
主要配置项
标识符
预计正式
发表时间
技术
合同
《合同》
LIG-TSGL-TCM-Contract-V1.0
SOW
LIG-TSGL—TCM-SOⅥLVl.0
《项目计划》
LIG-TSGL-SPP-PP-V1.0
《质量保证计划》
LIG-TSGL-SPP-SQA-V1.0
《置管理计划》
LIG-TSGL-SPP-CM-V1.0
需求
《需求规格说明书》
LIG-TSGL-SRS-V1.0
用户DEMO
LIG-TSGL-RM-Demo-V1.0
《总体设计说明书
LIG-TSGL-eSign-HL-V1.0
《数据库设计》
LIG-TSGL-Design-DB-V1.0
《详细设计说明书》
LIG-TSGL-DeSign-LL-V1.0
《设计术语及规范》
LIG-TSGL-Design-STD-V1.0
编程
源程序
LIG-TSGL-Code-ModUleName-V1.0
编码规则
LIG-TSGL-Code-STD-V1.0
《测试计划》
LIG-TSGL-TeSt-P1an-V1.0
《测试用例》
LIG-TSGL-TeSt-ase-V1.0
《测试报告》
LIG-TSGL-TeSt-Report-V1.0
提交
运行产品
LIG-TSGL-Product-Exe-V1.0
《验收报告》
LIG-TSGL-Product-Repoort-V1.0
《用户手册》
LIG-TSGL-Product-Manual-V1.0
项目基线
基线名称/标识符
基线所包含的主要配置项
预计建立时间(天)
《需求规格说明书》、用户DEMO
总体设计
《总体设计说明书》、《数据库设计》
60
项目实现
软件源代码、编码规则
90
《测试用例》、《测试报告》
配置项的版本管理
配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支,让它们分别对应4类工作空间。
.主干分支
.私有分支
.小组分支
.集成分支
上面定义的四类工作空间(分支)由项目执行负责人统一管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作。
在变更发生时,应及时做好基线的推进。
对配置项的版本管理在不同分支具有不同的策略:
a)主干分支
系统默认自动建立的物理分支——主干分支(/main)。
b)私有分支‘
如果多个开发工程师维护一个配置项时建议建立自己的私有分支。
配置管理员对其基本不予管理,如个别私有空间上的版本树过于冗余,将对其冗余版本进行限制。
c)小组分支
如果出现小组共同开发该配置项,该分支可视为项目组内部分组的私有空间,存放代码开发过程中的版本分支,由项目组内部控制。
d)集成分支
集成测试时在主干分支的特定版本上建立集成分支,测试工作在集成分支上完成。
私有分支和小组分支均为可选,必要时建立。
2)变更管理
变更管理的流程是:
a)由请求者提交变更请求,S
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件项目管理课程设计 第一组 软件 项目 管理 课程设计 一组