确定项目选题
图书馆座位管理系统
背景：
针对目前哈尔滨城市环境学院的校图书馆并没有座位管理的政策，我们准备推行一套合理的管理方法来使其人性化，这套图书馆作为管理系统相较于之前同学们自主抢座、自主占座，更为实用且方便，同时更有利于图书馆的管理，避免由于座位的冲突产生的纠纷。
优势：
本套图书馆座位管理系统上线后，学生通过学号密码可以登入系统进行预约，选座，中途离开，退座等一系列操作，它更方便快捷，并且有效。
需求分析
需求获取
通过调查问卷的方式进行需求获取，调查问卷样卷如下：
| 本调查表将被发给所有哈尔滨城市环境学院全部同学。
本调查表的目的是获得一些帮助分析员分析新系统需求的最初信息。此后还将举行进一步的讨论，以使每人都可以详细地阐述系统需求。 第一部分：根据您在学校和图书馆的经历，回答下列问题：
第二部分：根据你同意或反对的强烈程度，在下列表格中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
