软件项目实训设计报告.docx

资源描述

软件项目实训设计报告.docx

《软件项目实训设计报告.docx》由会员分享，可在线阅读，更多相关《软件项目实训设计报告.docx（29页珍藏版）》请在冰点文库上搜索。

软件项目实训设计报告.docx

软件项目实训设计报告

西安科技大学

《软件项目管理》

课程设计报告

题目：

多参数监护系统项目计划书

学院：

计算机科学与技术

专业及班级：

学号：

姓名：

2015年7月

第一章工作任务说明书（SOW）2

1.1整体要求：

1.2系统功能描述2

1.3关键监控指标3

1.4设计3

第二章生存期模型3

2.1选择生存期模型：

2.2生存期各阶段定义如下4

第三章需求规格说明6

3.1编写目的6

3.2背景6

3.3任务概述6

3.4设备规定8

第四章系统WBS8

第五章系统进度计划9

5.1初期项目进度计划10

5.2项目计划的细化10

第六章系统的成本估算12

6.1成本估算13

6.2成本预算15

第七章系统质量计划16

7.1导言略16

7.2项目组织16

7.3质量目标18

7.4质量策略18

7.5质量保证活动19

7.6质量控制活动19

7.7质量保证的报告途径19

7.8记录的收集、维护和保存19

8.1多参数监护系统组织结构19

8.2多参数监护系统项目的责任矩阵（RAM）如表8-1所示21

第九章系统沟通计划21

第十章系统的风险计划22

第十一章系统的执行控制22

11.1范围控制23

11.2进度、成本控制24

11.3风险管理控制25

第十二章总结26

参考文献26

第一章工作任务说明书（SOW）

多参数监护系统能为医学临床诊断提供重要的病人信息，通过各种功能模块，可实时检测人体的心电信号、心率、血氧饱和度、血压、呼吸频率和体温等重要参数，实现对各参数的监督报警。

信息存储和传输，是一种监护病人的重要系统。

本系统用于医院和卫生所的医疗（以下简称医疗中心）信息采集，数据的远程接收以及各医疗中心之间的交互通信。

系统通过对病人的各项生命体征信息进行实时采集处理，帮助医院及时的掌握病人的当前情况

1.1整体要求：

1.系统要求提供医生监控平台和患者信息采集平台。

2.系统要求有严格的权限管理，权限要在数据方面和功能方面都能体现。

3.系统要求有可扩充性，可以在现有系统的基础上，通过前台就可以加挂其他功能模块。

1.2系统功能描述

功能

对于每个医生，登录系统后，都应提供如下功能

1）查看自己病人的具体情况

2）由采集端给监控端发送消息

3）超过设定的阀值自动报警

4）采集病人生命体征

5）设置采集端信息（增、删、改）

5）查看监护端属性

1.3关键监控指标

A（心率）

Q（脉搏氧）

C（血压）

T（体温）

R（呼吸率）

1.4设计

包含三个参与者和用例

第二章生存期模型

2.1选择生存期模型：

针对本项目的开发特点，参考企业的生存期模型说明和软件体系，决定采用瀑布模型，理由如下：

1）多参数监护系统的全部功能分为服务器端、和客户端，客户端又分2部分，一部分是患者信息采集客户端，另一部分是医生监控客户端，因此可以先基服务器做出来，再逐步实现客户端的其余的功能。

这样一来，用户可以先使用小版本的同时，提出更多明确的需求，有助于下一阶段的开发，大大减小了开发的风险。

2）在多参数监护系统需求中，要求系统具有扩充性，而且也需要规范化的文档。

用户明确了需求的大部分，但也存在不很详尽的地方。

3）“系统要求可扩充性，可以在现有系统基础上，通过前台就可以加挂其他功能模块”-----也说明用户可能会增加新的需求。

4）对一个管理方式已经比较成熟的医院，要完全舍弃原有的管理方式，用多参数监护系统代替全部管理，这是不实际的。

所以，可以从最基础的做起，所以选用瀑布模型来开发多参数监护系统。

5）本项目具备瀑布式模型的其他特点：

·项目复杂程度为中等；

·预计开发软件的成本为中等；

·产品和文档的再使用率会很高；

·项目风险较低

2.2生存期各阶段定义如下

项目规划阶段

阶段目标：

根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。

输入：

合同文本、SOW

过程：

项目规划，计划确认

输出：

项目计划

需求分析阶段

阶段目标：

确定客户需求

输入：

项目计划、SOW

过程：

需求获取，需求分析，需求控制

输出：

原型系统，需求规格

设计阶段

阶段目标：

总体系统结构设计

输入：

原型系统，需求规格

过程：

总体设计

输出：

系统设计说明书

实施阶段

1.阶段目标：

实现系统服务器的功能

输入：

系统设计说明书

过程：

详细设计，编码，代码走查，代码评审，单元测试

输出：

详细设计说明书，源代码。

服务器端

2.阶段目标：

实现数据采集客户端功能

输入：

系统设计说明书

过程：

详细设计，编码，代码走查，代码评审，单元测试

输出：

详细设计说明书，源代码,数据采集端。

3.阶段目标：

实现数据监护客户端功能

输入：

系统设计说明书

过程：

详细设计，编码，代码走查，代码评审，单元测试

输出：

详细设计说明书，源代码，数据监护端。

测试阶段

阶段目标：

找出软件产品的错误并改正

输入：

测试计划，测试用例

过程：

单元测试，集成测试，系统测试

输出：

系统软件包，测试报告，产品说明书

提交阶段

阶段目标：

实现需求规格中的功能。

能够正常使用

输入：

系统软件包

过程：

产品提交

输出：

验收报告

第三章需求规格说明

3.1编写目的

某医院需要开发一个多参数监控系统方便医生对患者具体情况的掌握和了解患者生命体征的变化，以应对病情的变化，提前做好预测。

将大大提高医生的工作效率。

节省了很多人工测试和记录的时间和成本。

3.2背景

基于目前很多医院对患者生命体征的测量都是手工测量和记录的。

为了减少工作量，解放生产力。

提高效率。

3.3任务概述

3.3.1模块一：

服务器端

功能描述：

该模块主要实现网络通信的功能和设备管理的功能。

1.网络通信的功能：

实现数据采集客户端和数据监护端的数据通信的功能，该模块提供的数据通讯功能是基于TCP/IP的数据转发。

使得数据采集客户端的数据能够传输到指定的数据监护端，同时数据监护端可以和数据采集端进行交流。

2.设备管理的功能：

实现数据采集端和数据监护端的设备管理，并且可以指定采集端和监护端的对应关系，服务器进行数据转发时，根据采集端和监护端的对应关系将数据转发给相对应的客户端。

3.3.2模块二：

数据采集客户端

功能描述：

实现对人体的生命体征参数（心率、脉搏氧、血压、体温、呼吸率）的采集，并以图像化的方式显示到程序的界面上，如果采集端登陆了服务器，就将数据发送给指定的监护端，并且可以监护端进行信息交流（文字、语音、视频）。

图3-1功能模块图

图3-2数据采集流程图

3.3.3模块三：

数据监护客户端

功能描述：

实现对指定数据采集客户端的人体特征数据进行监护，可以根据采集端病人的实际情况，设置和调整相关的监护指标，并可以通过图形化的方式实时的查看采集端的生命体征数据，当病人的体征参数，不在正常范围时，提供预警的功能，同时，可与监护端进行信息交流（文字、语音、视频）。

3.4设备规定

操作系统：

Windows7/Windows8

开发工具：

MicrosoftvisualC++6.0

第四章系统WBS

根据对本项目的需求规格的分析，采用图表方式进行任务分解，其分解结果如图4-1所示，他是按照功能组成标准进行的部分分解。

WBS是可以随着系统的完善而不断增加和完善的。

图4-1多参数监护任务分解结果

MicrosoftProject也是创建WBS的好工具，可以将上面创建好的WBS条目加入到MicrosoftProject中，图4-2是采用MicrosoftProject开发的WBS.

图4-2多参数监护系统清单式WBS

第5章系统进度计划

多参数监护系统项目的进度计划采用渐进完善的方式进行的

5.1初期项目进度计划

由于初期项目计划只是一个计划表格，相当于一个大计划，简单说明计划的执行步骤，如表5-1

表5-1项目初期计划

任务

完成时间

负责人

资源

备注

需求讨论

2015-1-4

魏楠楠

2开发人员参与

项目规划

2015-1-6

黄朝来

全体人员参与

需求确定

2015-1-7

王青枝

全体人员参与

设计

2015-1-8

魏楠楠

魏楠楠参与

项目实施

2015-1-18

黄朝来

黄朝来、魏楠楠参与

有待细化

测试

2015-1-20

黄朝来

王青枝、黄朝来参与

提交

2015-1-26

王青枝

5.2项目计划的细化

表5-1的大计划不能作为指导详细工作的计划，是比较粗的，还需要进一步细化。

随着对项目了解的深入，项目计划也会逐步完善和细化的。

首先根据WBS的分解情况，继续分解相应的活动（任务），使用myproject工具，将分解后的所有活动（任务）和WBS的代码录入项目计划文件中，然后确定各个活动间的关系，由于采用增量式的生存期模型，在需求设计之后，系统的功能采用增量方式实现，实施阶段分个增量，对各个任务分配相应的资源，然后经过不断地资源调整优化以及工期、活动关系的调整等，再经过多次的评审讨论，最后计划通过评审，将此计划存为基准计划。

项目的基准计划如下。

（1）进度计划

表5-2的进度计划是细化后的项目进度计划。

表5-2项目计划

任务名称

工期

开始时间

结束时间

资源

软件规划

2工作日

2015-01-02

2015-01-04

黄朝来魏楠楠

项目规划

1工作日

2015-01-05

魏楠楠王青枝

计划评审

1工作日

2015-01-06

魏楠楠

需求开发

6工作日

2015-01-07

2015-01-12

黄朝来

用户界面设计

1工作日

2015-01-13

黄朝来

用户界面评审

1工作日

2015-01-14

王青枝魏楠楠

修改界面,需求

1工作日

2015-01-15

黄朝来

编写规格说明书

2工作日

2015-01-16

2015-01-17

魏楠楠

需求验证

1工作日

2015-01-18

王青枝

系统测试

2工作日

2015-01-19

黄朝来

系统集成测试

1工作日

2015-01-20

魏楠楠

环境测试

1工作日

2015-01-21

魏楠楠王青枝

提交

2工作日

2015-01-22

2015-01-23

黄朝来

完成文档

2工作日

2015-01-24

2015-01-25

魏楠楠

验收、提交

1工作日

2015-01-26

王青枝

（2）项目甘特图

图5-1项目甘特图

（3）里程碑

本项目也需要里程碑计划，因为一些人员（例如高层领导）可能更加关注里程碑的进展，里程碑如下：

1）需求讨论（2个工作日）

2）项目规划（3个工作日）

3）需求确定（2个工作日）

4）设计（5个工作日）

5）项目实施（10个工作日）

6）测试（2个工作日）

7）提交（2个工作日）

第6章系统的成本估算

多参数监护系统估算是循序渐进的过程，随着项目的不断发展，估算可以重复多次进行的，而且是逐步精确的。

本项目采用自下而上和参数综合的成本估算方法，然后结合进度形成项目成本预算基线。

6.1成本估算

（1）合同签署前：

签订合同前，根据以往类似项目的经验，采用类比估算方法，进行粗略的估算根据用户要求采用C/S结构，团队VC++6.0的MFC的技术比较成熟，以前成功完成过类似的项目，根据SOW的说明，基本上需要1~2个开发人员，一个月左右的开发时间，基本上是3-4人月的规模，所以1-3万可以作为合同的参考价格。

这个阶段只需要一个粗略量级的成本估算，可以不进行详细的成本预算。

（2）合同签署后：

根据现有资源和WBS分解的结果，进一步细化估算，由于WBS分解是针对项目功能进行的分解，在成本估算的时候，首先估算每个任务的开发规模，然后通过系数获得相应的质量、管理任务的规模，从而计算直接成本，再计算间接成本，最后计算总成本，具体过程如下：

首先分析资源：

·人力资源：

一个开发人员

一个项目管理人员

一个项目质量人员

一个配置管理人员

·设备资源：

4台电脑

下表给出了项目规模的估算。

表6-1项目规模估算表

WBS

名称

估计值（人天）

小计（人天）

总计（人天）

多参数监护系统

服务器端

1.1

启动服务器

1.2

设置

1.2.1

采集端信息

1.2.1.1

增加

1.2.1.2

删除

1.2.1.3

修改

1.2.2

监护端信息

1.3

停止服务器

采集端

2.1

2.2

登出

2.3

发送与接收消息

数据监护端

3.1

阀值设置

3.2

发送和接收消息

估算步骤如下：

1）获取项目分解结果WBS。

·任务分解是根据项目的功能分解的。

2）计算开发成本。

·由于任务分解的结果主要是针对开发任务的分解，管理任务和质量任务可以通过计算开发任务得到，根据以往经验，管理任务和质量任务=20%*开发任务。

·从表2-1得知项目规模是24人天，开发人员成本参数=400元/天，则内部开发成本=400元/人*24天=9600元

3）计算管理、质量成本

·项目的管理和质量成本=开发成本*20%=1920元

4）直接成本9600+1920=11520元

5）计算间接成本。

·间接成本包括前期合同费用、房租水电、培训、客户服务、员工福利等。

·根据以往经验，采用公式：

间接成本=直接成本*25%=2880元

6）计算总估算成本

·项目的总估算成本=11520+2880=14400元

7）重新评估项目的报价

·重新评估一下项目报价准确性，当然这时候，项目合同已经签署了，报价是不可能更改的，但是通过再次评估可以进一步明确企业的项目运作和利润情况等。

·如果项目的利润是30%，其中风险利润10%，利润15%,水费5%则项目的报价=14400*1.3=18720元，应该说报价还是比较合适的。

6.2成本预算

在编制多参数监护系统项目计划中考虑到，2个开发人员全职在这个项目中，而项目经理、质量保证和配置管理人员不是全职在这个项目中，他们还要同时管理其他的项目，进行成本估算的时候，应该根据项目人员付出时间以及各项任务的具体情况进行成本预算，最后可以得到比较详细的成本分配情况，即成本基准。

资源费用比例表如3-1所示

资源名称

类型

缩写

最大单位

标准费率

加班费率

每次使用成本

成本累算

基准日历

魏楠楠

工时

楠

100%

¥50/工时

¥0./工时

¥0.00

按比例

标准

黄朝来

工时

来

100%

¥60/工时

¥0./工时

¥0.00

按比例

标准

王青枝

工时

枝

100%

¥50/工时

¥0./工时

¥0.00

按比例

标准

表3-1

根据每个任务的资源分配和时间安排，确定项目的预算，如表3-2，预算总成本为4430元，与估算的成本基本持平，这样4430元可以作为项目的成本控制参考。

任务名称

开始时间

完成时间

比较基准

多参数监护系统

2015/1/5

2015/1/23

¥4430.00

项目规划

2015/1/5

¥220.00

计划评审

2015/1/6

¥300.00

用户界面设计

2015/1/7

¥120.00

用户需求评审

2015/1/8

¥230.00

修改需求、界面

2015/1/9

¥250.00

编写需求规格说明书

2015/1/10

¥240.00

需求验证

2015/1/11

¥120.00

概要设计

2015/1/12

2015/1/13

¥150.00

设计评审

2015/1/15

¥460.00

服务器功能实现

2015/1/16

2015/1/17

¥470.00

数据监护功能实现

2015/1/18

2015/1/19

¥500.00

数据采集功能实现

2015/1/20

¥310.00

系统集成测试

2015/1/21

¥180.00

环境测试

2015/1/21

¥130.00

完成文档

2015/1/22

¥200.00

验收、提交

2015/1/23

¥220.00

表3-2

项目规模成本估算是项目规划的基础，也是项目成本管理的核心，通过成本估算方法，分析并确定项目的估算成本并以此为基础进行项目成本预算和计划编排，开展子昂木成本控制等管理活动。

软件项目规模成本估算最常用的三种方法是类比估算法，参数模型估算法，自下而上估算法。

实际应用中可以综合应用。

第7章系统质量计划

在制定项目计划的时候，质量经理参与整个项目计划的制定过程，同时负责制定质量计划，根据项目的特点和企业质量保证体系，制定项目质量计划。

7.1导言略

7.2项目组织

7.2.1组织机构

在项目实施期间成立质量保证组织，该组织由质量保证人员和项目经理组成，项目经理负责质量监督工作及项目进展过程中各环节的质量把关，开发经理负责质量控制工作。

质量保证人员负责质量保证的工作。

组织结构如图1所示：

图7-1项目的组织结构

7.2.2职责

·在本项目中，质量保证组织的职责如下：

7.2.2.1高层管理

高层管理是公司负责质量的高级管理，其质量职责如下：

·受理项目内不能解决的不符合问题，必要时与项目经理协调；

·负责听取质量保证组的工作报告，评审质量保证活动和结果；

·参加有关质量保证过程改进的评审。

7.2.2.2项目的质量保证人员

质量保证人员的质量职责如下：

·负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查；

·实施项目组成员的质量保证培训

·制定质量保证培训计划

·按计划实施审计活动，依照质量保证计划执行评审/审计，并记录执行中发现的不符合项；

·对不符合问题提交不符合项报告，跟踪并验证纠正实施的执行情况；

·对项目内不能解决的不符项问题向高层管理提交报告；

·向项目经理报告项目质量工作状况和质量度量结果；

·定期向项目组报告质量活动的结果；

·制动质量保证的过程改进计划，记录过程数据。

7.2.2.3项目经理

项目经理的质量职责如下：

·评审质量计划

·与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施；

·定期或时间驱动的评审质量保证活动和结果。

7.3质量目标

根据企业的质量方针和质量目标，结合本项目特点，制定项目的总体质量目标；

1）基于需求的测试覆盖率为100%；

2）软件功能测试用例通过率不低于95%；

3）每个阶段评审中发现的问题都已经解决或得到适当处理；

4）产品发布时不存在严重及以上的缺陷。

注：

严重问题指导致系统或模块不能正常工作的问题

结合以往的项目经验和企业的质量相应标准，制定质量标准如表7-1所示：

项目

具体描述

计划

实际

缺陷排除率

（缺页数/页）

需求检查

系统总体设计检查

缺陷排除率

（缺页数/KLOC）

详细设计复核

详细设计检查

代码复核

代码检查

编译

单元测试

系统测试

表7-1质量计划标准

7.4质量策略

为了保证提交用户的产品是高质量，实施过程中采取的质量保证措施包括：

1）将质量贯彻到日常的项目进展过程中；2）应该特别注意项目工作产品质量的早期评审工作，无论是质量保证还是质量控制采取的策略都是早期预防和早期排除缺陷。

7.5质量保证活动

质量保证的主要活动包括过程审计和产品审计。

过程审计过程审计和产品审计的目的都是为了确保在项目进展过程的各个阶段和各个方面采取各项措施来保证和提高提交给用户的产品质量，每一次过程审计和产品审计都应填写相应的报告或活动记录。

7.6质量控制活动

质量控制包括代码走查、单元测试、集成测试、环境测试等，由开发人员负责，详见进度计划。

编码人员在编写代码是要进行同步单元测试，单元测试要达到分支覆盖，产品通过单元测试和编码检查后，应提交测试部进行集成测试、系统测试。

测试部的测试应达到质量目标要求，软件发布时应达到测试通过准则的要求。

7.7质量保证的报告途径

质量保证人员对每次审计活动发现的不符合项，应该和项目经理协商不符哈项的纠正措施，及预订完成日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理着，高层管理者决定最后的措施。

质量保证人员有独立的汇报途径，日常的汇报途径如下：

·发现的问题通知项目经理，协调纠正措施。

·将项目内不能协调的问题汇报给高层管理者，由高层管理者协调解决。

·日常工作和过程数据要汇报给质量经理统一收集、统计

7.8记录的收集、维护和保存

项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录、对项目中问题的处理也需要形成记录保存。

每周由质量保证人员根据任务清单的审计任务进行审计活动，并收集各活动的过程数据。

第8章系统人力资源计划

8.1多参数监护系统组织结构

由项目的组织结构图7-1可知，它是一个矩阵型组织结构的具体化。

其中：

市场部：

负责与用户的协调工作

负责项目相关的商务活动

负责用户需求的接口

配合项目经理的资源协调活动

负责产品的验收活动

负责系统的维护活动

项目管理：

负责项目的组织和规划

负责项目计划制定和维护

负责项目的跟踪和管理

负责资源的分配和协调活动

负责各组织和计划之间的协调活动

软件开发：

负责项目的软件开发，包括设计、编码、单元测试和集成测试

负责产品质量控制的工作

负责配合质量保证的活动，如系统测试、文档编制

配合产品验收的相关活动

质量保证：

负责项

展开阅读全文