软件工程 项目管理 实验 图书馆座位管理系统
软件工程项目管理实验
论文题目: |
图书馆座位管理系统 |
学 院: |
软件学院 |
专 业: |
软件工程 |
年 级: |
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功能点的值如下:
FP |
62*1=62 |
本项目采用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图:
二、建立甘特图
三、建立里程碑
四、建立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
本文来自博客园,作者:王回甘,转载请注明原文链接:https://www.cnblogs.com/WScoconut/p/16975509.html