软件工程项目管理实验
论文题目:
|
图书馆座位管理系统
|
学 院:
|
软件学院
|
专 业:
|
软件工程
|
年 级:
|
2020
|
姓 名:
|
我和一亲兄弟
|
学 号:
|
算命的说不方便透露
|
指导教师:
|
印哥
|
2022年 11 月 22 日
实验一 需求概述
确定项目选题
图书馆座位管理系统
背景:
针对目前哈尔滨城市环境学院的校图书馆并没有座位管理的政策,我们准备推行一套合理的管理方法来使其人性化,这套图书馆作为管理系统相较于之前同学们自主抢座、自主占座,更为实用且方便,同时更有利于图书馆的管理,避免由于座位的冲突产生的纠纷。
优势:
本套图书馆座位管理系统上线后,学生通过学号密码可以登入系统进行预约,选座,中途离开,退座等一系列操作,它更方便快捷,并且有效。
需求分析
需求获取
通过调查问卷的方式进行需求获取,调查问卷样卷如下:
本调查表将被发给所有哈尔滨城市环境学院全部同学。
本调查表的目的是获得一些帮助分析员分析新系统需求的最初信息。此后还将举行进一步的讨论,以使每人都可以详细地阐述系统需求。
第一部分:根据您在学校和图书馆的经历,回答下列问题:
- 您的年级是?
- 您经常去图书馆吗?
- 如果您去图书馆,一般呆多久?
- 您有没有遇到过没有座位的情况?
- 如果没有座位,您会采取什么办法?
- 如果找座位您会在该楼层进行寻找,还是换楼层?
- 您是否遇到过占座的情况?
- 如果有遇到过,他们通常是如何占座的?
- 如果您的座位被占用了,您会怎么解决?
- 您有没有占座的情况?
第二部分:根据你同意或反对的强烈程度,在下列表格中1至5范围内的适当数字上画圈。
|
问题
|
强烈反对 非常同意
|
您对目前学校的图书馆座位管理政策的态度?
|
1
|
2
|
3
|
4
|
5
|
如果目前有一套座位管理系统,您会使用吗?
|
1
|
2
|
3
|
4
|
5
|
您赞成采用信誉评级的方式决定学生是否可以进入图书馆吗?
|
1
|
2
|
3
|
4
|
5
|
第三部分:请写下您的意见和建议
请简要地指出您希望在图书馆座位管理系统中加入的功能,并写下您其他的建议。
|
用例图(系统用例图)
系统用例图如下所示:

用例描述
1 查看座位用例
用例名
|
查看座位
|
用例类型
业务需求
|
用例ID
|
MSM1201
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、图书馆座位管理系统
|
项目相关人员期望
|
学生:希望能够查看全部座位信息
|
描述
|
该用例描述了学生查看的过程。
|
前置条件
|
学生通过身份验证,成功登录系统。
|
后置条件
|
如果该用例顺利执行,图书管理系统显示座位表给学生
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.查看座位
[学生]:学生选择进入“查看座位”
[系统]:系统显示“查看现场座位”和“查看预约座位”
[学生]:学生选择进入“查看现场座位”
[系统]:系统显示座位情况,座位情况分为维修中,已被选,可选,选中。
|
替代流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.查看座位
[学生]:学生选择进入“查看座位”
[系统]:系统显示“查看现场座位”和“查看预约座位”
[学生]:学生选择进入“查看预约座位”
[系统]:系统显示座位情况,座位情况分为维修中,已被选,可选,选中。
|
结束
|
学生成功完成图书馆座位信息的查看。
|
2 提前预约座位用例
用例名
|
提前预约座位
|
用例类型
业务需求
|
用例ID
|
MSM1202
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、图书馆座位管理系统
|
项目相关人员期望
|
学生:希望通过预约的方式能够提前选择座位
|
描述
|
该用例描述了学生预约座位的过程。
|
前置条件
|
学生成功登录系统,通过身份验证,一个用户只能选择预约一个座位。
|
后置条件
|
如果该用例顺利执行,图书管理系统留出并保留座位给学生
|
触发条件
|
当学生选择预约座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.查看座位
[学生]:学生选择进入“查看座位”
[系统]:系统显示座位情况,学生选择一个可选座位
- 选择预约
[学生]:学生选择该座位后进入“预约座位”
[系统]:系统显示座位剩余时间情况。
[学生]:选择预约的时间段,并点击确认。
[系统]:系统显示预约成功。系统将该座位可选时间中的被选择时间段去掉,同时将该同学的选座权限关闭。
|
替代流程
|
1 登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2 查看座位
[学生]:学生选择进入“查看预约座位”
[系统]:系统显示座位情况,提示学生预约的所有座位的所有时间段都已经被选择,建议到达现场选择座位。
|
结束
|
学生成功完成一个座位的预约或到达现场选座座位。
|
备注
|
预约选择座位和现场选择座位的座位总和是图书馆所有座位,为保证同学们的相对公平选择座位,每个模块占比各50%。
|
3 现场选择座位用例
用例名
|
现场选择座位
|
用例类型
业务需求
|
用例ID
|
MSM1203
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、图书馆座位管理系统
|
项目相关人员期望
|
学生:到达图书馆以后,希望在现场选择座位
|
描述
|
该用例描述了学生选座的过程。
|
前置条件
|
学生成功登录系统,通过身份验证,一个用户只能选择一个座位。
|
后置条件
|
如果该用例顺利执行,图书管理系统更改学生选定座位状态,给学生开启座位
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.查看座位
[学生]:学生选择进入“查看现场座位”
[系统]:系统显示座位情况,座位情况分为已被选,可选,选中。
3.选择座位
[学生]:学生选择进入“选择座位”,选择可选座位
[系统]:系统显示座位情况,将学生选的改座位的座位情况改为“选中”。
4.确定时间
[学生]:学生输入需要使用座位的时间
[系统]:系统记录下学生填写的时间,在对应表中保存好。
5.确定选座
[学生]:学生选好座位后,确认无误后点击“确定”
[系统]:系统显示座位情况,将学生选的改座位的座位情况改为“已被选”,并且开始计时;同时将该学生“学生是否可以选座”,改为“否”。
|
替代流程
|
无
|
结束
|
学生在图书馆现场成功完成一个座位的选择。
|
4 保留座位用例
用例名
|
保留座位
|
用例类型
业务需求
|
用例ID
|
MSM1204
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、座位管理系统
|
项目相关人员兴趣
|
学生:有事临时离开图书馆,希望图书馆能够给自己保留座位,回来可以继续使用
|
描述
|
该用例描述了学生保留座位的过程。
|
前置条件
|
学生成功登录系统,通过身份验证。
|
后置条件
|
如果该用例顺利执行,图书管理系统将给学生保留座位或留座失败
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.保留座位
[学生]:学生选择进入“保留座位”
[系统]:系统判断是否有座位可以保留,如果存在即可保留。
3.确定时间
[学生]:学生输入需要离开的时间
[系统]:系统记录下学生填写的时间,在对应表中保存好。
4.确定保留
[学生]:填好信息后,确认无误后点击“确定”
[系统]:系统暂停计时。
- 继续使用
[学生]:学生返回座位,继续使用座位
[系统]:系统继续计时。
|
替代流程
|
当该座位后续时间已被预约情况下
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.保留座位
[学生]:学生选择进入“保留座位”
[系统]:系统显示保留座位系统界面
3.确定时间
[学生]:学生输入需要离开的时间
[系统]:系统提示学生该座位后续时间已经被预约出去,无法保留,同时返回功能界面
|
结束
|
学生成功完成一个座位的保留。
|
5 座位续时用例
用例名
|
座位续时
|
用例类型
业务需求
|
用例ID
|
MSM1205
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、座位管理系统
|
项目相关人员兴趣
|
学生:希望可以继续继续使用该座位
|
描述
|
该用例描述了学生座位续时的过程。
|
前置条件
|
学生成功登录系统,通过身份验证。
|
后置条件
|
如果该用例顺利执行,图书管理系统将给学生延迟座位可用时间,或续时失败
|
触发条件
|
当学生选择座位续时时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.座位续时
[学生]:学生选择进入“座位续时”
[系统]:系统显示座位续时系统界面
3.确定时间
[学生]:学生输入需要续用的时间
[系统]:系统记录下学生填写的时间,在对应表中保存好。
4.确定续时
[学生]:填好信息后,确认无误后点击“确定”
[系统]:系统增加学生可用时间。
|
替代流程
|
当该座位后续时间已被预约情况下
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.座位续时
[学生]:学生选择进入“座位续时”
[系统]:系统显示座位续时系统界面
3.确定时间
[学生]:学生输入需要续用的时间
[系统]:系统提示学生该座位后续时间已经被预约出去,无法续时,同时返回功能界面
|
结束
|
学生成功完成一个座位的续时。
|
6 退选座位用例
用例名
|
退选座位
|
用例类型
业务需求
|
用例ID
|
MSM1206
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、座位管理系统
|
项目相关人员兴趣
|
学生:离开图书馆,退选已选座位
|
描述
|
该用例描述了学生退选座位的过程。
|
前置条件
|
学生成功登录系统,通过身份验证。
|
后置条件
|
如果该用例顺利执行,图书管理系统显示座位表给学生
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.退选座位
[学生]:学生选择进入“退选座位”
[系统]:系统更改座位信息,将该学生对应的座位状态改为“可选”,并且同时将该学生“学生是否可以选座”,改为“是”。
|
替代流程
|
无
|
结束
|
学生成功完成一个座位的退选。
|
7 报修座位用例
用例名
|
报修座位
|
用例类型
业务需求
|
用例ID
|
MSM1207
|
主要业务参与者
|
学生
|
其他参与者
|
座位管理数据库、座位管理系统
|
项目相关人员兴趣
|
学生:希望能够换一个可用座位
图书馆:希望能够及时修理故障座位
|
描述
|
该用例描述了学生座位报修的过程。
|
前置条件
|
学生成功登录系统,通过身份验证,选好座位后,到自己实际座位后发现座位有问题
|
后置条件
|
如果该用例顺利执行,图书管理系统将座位状态改为“维修中”
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[学生]:学生选择进入“登录”功能。
[系统]:如果学生学号密码正确,则进入系统功能界面
2.座位报修
[学生]:学生选择进入“故障报修”
[系统]:系统更改座位情况,将该学生对应的座位状态改为“维修中”,并且同时将该学生“学生是否可以选座”,改为“是”。
|
替代流程
|
无
|
结束
|
读者成功完成一个座位信息的报修。
|
8 修理座位用例
用例名
|
修理座位
|
用例类型
业务需求
|
用例ID
|
MSM1208
|
主要业务参与者
|
管理员
|
其他参与者
|
座位管理数据库、座位管理系统
|
项目相关人员兴趣
|
管理员:希望能够及时修理故障座位
图书馆:希望能够及时修理故障座位
|
描述
|
该用例描述了管理员维修座位的过程。
|
前置条件
|
管理员成功登录系统,通过身份验证。
|
后置条件
|
如果该用例顺利执行,管理员成功修理座位
|
触发条件
|
当学生选择查看座位时该用例被触发。
|
基本流程
|
1.登录系统
[管理员]:管理员选择进入“登录”功能。
[系统]:如果管理员账号密码正确,则进入系统功能界面
2.查看座位
[管理员]:管理员选择进入“查看座位”
[系统]:系统显示座位情况,座位情况分为维修中,已被选,可选,选中。
- 维修座位
[管理员]:管理员寻找维修工人修理故障桌椅,并修改座位状况数据
[系统]:系统显示座位情况,将对应座位情况更改为“可选”
|
替代流程
|
无
|
结束
|
管理员成功完成一个座位的维修。
|
顺序图
1 现场选座

2 座位维修

需求变更替提交单
软件产品修改提交单
|
申请人
|
李艳春
|
申请日期
|
2022.11.20
|
项目名称
|
图书馆座位管理系统
|
阶段名称
|
系统设计阶段
|
文件名称
|
Test point model.doc
|
修改内容
|
变更叙述如下所示:
增加测试点数量,在原有的基础上额外扩展5个测试样例,扩展的测试样例的测试范围不与之前相重复,详情见Test point model.doc。
|
修改意见
|
同意Test point model.doc 的变更。
|
验证人
|
杨过
|
验证日期
|
2022.11.25
|
SCCB
|
周比特、王帅、李艳春
|
填表人
|
李艳春
|
工作分解结构
建立WBS图

建立WBS表
WBS表
|
WBS
|
任务名称
|
1
|
1
|
图书座位管理系统
|
2
|
1.1
|
计划初始阶段
|
3
|
1.1.1
|
软件规划
|
4
|
1.1.2
|
项目规划
|
5
|
1.1.3
|
计划评审
|
6
|
1.1.4
|
需求开发
|
7
|
1.1.5
|
编写需求规格说明书
|
8
|
1.2
|
概要设计阶段
|
9
|
1.2.1
|
建立数据库
|
10
|
1.2.2
|
设计数据库ER图
|
11
|
1.3
|
详细设计阶段
|
12
|
1.3.1
|
实现登录功能
|
13
|
1.3.2
|
实现查看座位功能
|
14
|
1.3.3
|
实现保留座位功能
|
15
|
1.3.4
|
实现报修座位功能
|
16
|
1.3.5
|
实现预约选座功能
|
17
|
1.3.6
|
实现现场选座功能
|
18
|
1.3.7
|
实现维修座位功能
|
19
|
1.3.8
|
实现退选座位功能
|
20
|
1.3.9
|
实现座位续时功能
|
21
|
1.3.10
|
实现查看日志功能
|
22
|
1.4
|
测试阶段
|
23
|
1.4.1
|
系统测试
|
24
|
1.4.2
|
环境测试
|
25
|
1.5
|
提交阶段
|
26
|
1.5.1
|
完成文档
|
27
|
1.5.2
|
验收
|
建立WBS字典
1
WBS字典
|
项目名称:图书馆座位管理系统
|
日期:2022.7.1
|
WBS号码:1.2
|
WBS名称:概要设计
|
父级WBS:1
|
父级WBS名称:图书馆座位管理系统
|
责任人/组织(如有必要):王帅、周比特
|
工作描述:完成系统的概要设计阶段,把需求分析得到的系统扩展用例图转换为软件结构和数据结构。
|
子级WBS号码:1.2.1
|
子级WBS名称:建立数据库
|
子级WBS号码:1.2.2
|
子级WBS名称:设计ER图
|
指定人:王帅 审批人:周比特 日期:2022.7.1
|
职务:项目负责人: 职务:项目干事
|
2
WBS字典
|
项目名称:图书馆座位管理系统
|
日期:2022.7.1
|
WBS号码:1.4
|
WBS名称:系统测试
|
父级WBS:1
|
父级WBS名称:图书馆座位管理系统
|
责任人/组织(如有必要):王帅、周比特
|
工作描述:完成系统的测试阶段,测试人员会同项目负责人根据软件需求,制定和确定测试进度时,必须要有开发人员和相关的测试部门人员共同参与。
|
子级WBS号码:1.4.1
|
子级WBS名称:系统测试
|
子级WBS号码:1.4.2
|
子级WBS名称:环境测试
|
指定人:王帅 审批人:周比特 日期:2022.7.1
|
职务:项目负责人: 职务:项目干事
|
实验二 成本估算
功能点估算
由实验讲义要求相应的功能计数项的复杂度如下所示:

又根据实验一计算功能点如下:
有 7个外部输入(预约、现场、报修、保留、续时、退选、维修)1个外部输出(查看日志)
3个外部查询(座位信息,座位状态,操作反馈信息)
4个内部逻辑文件(座位表,用户信息表,选座表,座位状态日志)
0个外部接口文件(没有引用其他软件的控制系统)
说明:
用户信息表:存储学号或管理员编号、姓名等相关信息
座位表:存储座位号、座位状态等相关信息
选座表:存储学号、座位号等相关信息
操作反馈信息:确认信息、失败信息等
座位状态日志:存储学号、座位号、时间、座位状态更改情况等信息
由实验讲义要求相应的技术复杂因子如下所示:

由实验讲义要求相应的技术复杂因子的取值范围如下所示:

又根据实验一计算对应的项目复杂度因子值如下:
可靠的备份和恢复:4
数据通信:1
分布式函数:3
性能:1
大量使用的配置:1
联机数据的输入:3
操作简单性:4
在线升级:1
复杂界面:1
复杂的数据处理:2
重复使用性:5
安装简易性:4
多重站点:1
易于修改:4
计算总和为:4+1+3+1+1+3+4+1+1+2+5+4+1+4=35
根据TCF的计算公式,同时需要符合范围 Fi:0-5 TCF:0.65-1.35
TCF=0.65+0.01(sum(Fi))
带入后等于1
最后根据以上所有计算FP:62*1=62
组件类型
|
复杂因子
|
计算
|
低
|
中
|
高
|
累计
|
输入
|
7*3=21
|
0*4=0
|
0*6=0
|
21
|
输出
|
1*4=4
|
0*5=0
|
0*7=0
|
4
|
查询
|
3*3=9
|
0*4=0
|
0*6=0
|
9
|
内部文件
|
4*7=28
|
0*10=0
|
0*15=0
|
28
|
外部文件
|
0*5=0
|
0*7=0
|
0*10=0
|
0
|
UFP
|
21+4+9+28+0=62
|
TCF
|
0.65+0.01*35=1
|
FP
|
62*1=62
|
由实验讲义假设每一功能项的代价为5万元钱,计算成本:
62*5=310万元
代码行估算
由实验讲义假设的功能点与代码行的转换如下所示:

又根据实验一计算出的FP功能点的值如下:
本项目采用C语言进行相应转换:150*62=9300行
用例点估算
用例图如下:

用例点估算模型如下:

1 计算未调整的角色权值 UAW
复杂度级别
|
复杂度标准
|
权值
|
数量
|
结果
|
简单
|
角色通过API与系统交互
|
1
|
4
|
4
|
普通
|
角色通过协议与系统交互
|
2
|
1
|
2
|
复杂
|
角色通过GUI与系统交互
|
3
|
7
|
21
|
总计(UAW)
|
1*4+2*1+3*7=27
|
2 计算未调整的用例的权值UUCW
复杂度级别
|
复杂度标准
|
权值
|
数量
|
结果
|
简单
|
1 - 3
|
5
|
10
|
50
|
普通
|
4 - 7
|
10
|
0
|
0
|
复杂
|
> 7
|
15
|
0
|
0
|
总计(UUCW)
|
10*5=50
|
3 计算技术因子 TCF
因子
|
说明
|
权重
|
复杂度
|
结果(权重*复杂度)
|
T1
|
分布式系统
|
2
|
2
|
4
|
T2
|
性能要求
|
1
|
2
|
2
|
T3
|
终端用户效率
|
1
|
3
|
3
|
T4
|
内部处理复杂度
|
1
|
2
|
2
|
T5
|
可重用性
|
1
|
3
|
3
|
T6
|
易安装性
|
0.5
|
1
|
0.5
|
T7
|
易用性
|
0.5
|
3
|
1.5
|
T8
|
可移植性
|
2
|
3
|
6
|
T9
|
易更改性
|
1
|
4
|
4
|
T10
|
并发性
|
1
|
4
|
4
|
T11
|
安全功能特性
|
1
|
4
|
4
|
T12
|
提供给第三方访问
|
1
|
3
|
3
|
T13
|
需要特别的用户培训
|
1
|
1
|
1
|
总计(TCF)
|
4+2+3+2+3+0.5+1.5+6+4+4+4+3+1=38
|
4 计算环境复杂度因子 ECF
因子
|
说明
|
权重
|
复杂度
|
结果(权重*复杂度)
|
E1
|
熟悉UML程度
|
1.5
|
4
|
6
|
E2
|
开发应用程序经验
|
0.5
|
3
|
1.5
|
E3
|
面向对象经验
|
1
|
4
|
4
|
E4
|
主分析师能力
|
0.5
|
4
|
2
|
E5
|
团队激励
|
1
|
3
|
3
|
E6
|
需求稳定度
|
2
|
3
|
6
|
E7
|
兼职人员比例
|
-1
|
0
|
0
|
E8
|
不同编程语言难度
|
2
|
1
|
2
|
总计(ECF)
|
6+1.5+4+2+3+6+0+2=24.5
|
计算公式如下:
UAW =角色数*相应权重 之和
UUCW =用例数*相应权重 之和
UUCP =UAW+UUCW
TCF =技术因子权值乘以相应的影响等级之和,再乘以0.01,加上0.6
ECF =环境因子权值乘以相应的影响等级之和,再乘以-0.03,加上1.4
UCP =UUCP*TCF*ECF
EFFORT =UCP*PF (PF为生产力)
计算结果如下:
UAW=27
UUCW=50
UUCP=UAW+UUCW=77
TCF=0.6+0.01*38=0.98
ECF=1.4+(-0.03)*24.5=0.665
UCP=77*0.98*0.665=50.1809
实验三 项目进度计划
一、根据WBS建立PDM图和ADM图
1 PDM图:

2 ADM图:

二、建立甘特图

三、建立里程碑
代码提交
11/24
各个子系统测试
09/24
编码
05/24
代码设计
02/24
需求分析
11/23
四、建立PERT图
分别估算每一活动的O、M和P,估算算每一个活动的Ei、δ及δ2及整个项目的标准差和方差。
计算项目完成时间的范围和概率如下图所示。
说明:
PERT历时(Te期望值)=(O+4M+P)/ 6
标准差 σ = (P-O)/ 6
O为项目完成的最小估算值(乐观估算值)
P为项目完成的最大估算值(悲观估算值)
M为活动完成的最大可能估算值(最可能值)
E为活动的平均历时
风险分析:
使用标准差和方差表示历时估计的可信程度或者项目完成的概率。
项目
|
O M P
|
Ei
|
标准差 σ
|
方差
|
需求分析
|
7,8,9
|
8
|
0.33
|
0.11
|
需求验证
|
2,3,4
|
3
|
0.33
|
0.11
|
项目规划
|
5,6,7
|
6
|
0.33
|
0.11
|
概要设计
|
10,14,18
|
14
|
1.33
|
1.78
|
详细设计
|
9,13,17
|
13
|
1.33
|
1.78
|
编码
|
20,30,40
|
30
|
3.33
|
11.11
|
单元测试
|
15,16,17
|
16
|
0.33
|
0.11
|
集成测试
|
7,8,9
|
8
|
0.33S
|
0.11
|
系统测试
|
3,4,5
|
4
|
0.33
|
0.11
|
图书馆座位管理项目
|
102
|
3.91
|
15.3
|
利用正态分布图的3σ定律

总平均历时E=102, δ =3.91
|
范围
|
概率
|
Start
|
Over
|
T1
|
± δ
|
68.3%
|
98.09
|
105.91
|
T2
|
± 2 δ
|
95.5%
|
94.18
|
109.82
|
T3
|
± 3 δ
|
99.7%
|
90.27
|
113.73
|
五、编写项目进度计划图 确定关键路径
最早开始时间(ES)最晚开始时间(LS)最早完成时间(EF)最晚完成时间(LF)

关键路径为:
需求分析->需求验证->概要设计->详细设计->编码->单元测试->集成测试->系统测试。
关键路径长度为:
96
非关键路径活动:
项目规划
自由浮动(FF)为:5(12-7)
总浮动(TF)为: 0