项目总结报告第一期Word格式.docx

项目总结报告第一期Word格式.docx

《项目总结报告第一期Word格式.docx》由会员分享，可在线阅读，更多相关《项目总结报告第一期Word格式.docx（17页珍藏版）》请在冰豆网上搜索。

项目目标，项目目标为能够完成会议核心功能。

一、主席、代表席可以发言并能够收听各个译员频道实时翻译。

二、译员可以收听会议席语音并可以并将实时翻译语音发送到会议席和旁听席。

三、旁听席可以实时收听各个频道的声音。

四、会议可以录音并回放。

五、在同传教学过程中，教师可以选择不同的音源来模拟会议。

3实际开发结果

3.1产品

简要说明项目所完成的产品的功能、特点。

包括：

同传会议系统主要是用于辅助同传课堂教学和同传会议，系统建立在TCP/IP网络协议基础上以传软方案实现，下面为系统中核心功能介绍

⏹管理控制台

1）同传会议中用于主席主持会议控制会议开始和停止、是否录制会议声音、回放会议、收听会议各频道声音。

2）同传教学中教师选择不同的音源（会议语音、教师机声音、教师机麦克风、教师机媒体文件）作为同传会议原声、控制是否录音、收集学生训练语音、实时监听学生训练、同时系统还有授课过程中常用的文件下发和收集、语音室功能。

⏹译员客户端

1）同传会议中用于译员收听会议频道原声，并译员的翻译实时广播出去，同时会双轨录音，左声道为原声、右声道为翻译录音。

2）同传教师中用于学生在同传训练收听教师端发出的原声，学生实时进行翻译。

同时系统将进行双轨录音。

⏹代表席频道选择器

同传会议中代表席收听会议席、译员间频道实时语音，单声道对应一个频道。

⏹旁听席红外转化器

系统会议中将会议席、译员间实时语音转化为红外发射接收端的输入信号。

⏹文件服务器

用于收集同传会议、同传训练中各个频道的录音。

并在回放时提供下载。

3.2系统框架

系统总体部署图

系统功能图

系统总结功能图

3.3主要功能和性能

逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。

一级模块

二级功能

三级功能

描述

会议席位

手拉手会议主机

购买

代表话筒

主席话筒

收听设备

定制安卓设备

调查

代表席频道选择器

语音技术预研

1、组播。

2、延时。

3、平台选择

频道选择

1、单声道收听。

2、音量。

3、静音。

主席频道选择器

译员间

PC客户端

频道选择器

频道同步

翻译并录音

上传录音

旁听席

多路音频输出

　技术预研

可研究一下采用一个设备驱动多个声卡，或者多通道的声卡，输出不同频道的声音

多音频输出客户端

从教师机读取频道配置

接收多个频道声音，并输出到对应的USB声卡

频道配置声卡

保存频道配置信息

多频道同时接收语音

红外耳机选型

发射器

辐射板

耳机

录音服务器

录音上传

上传客户端、服务端

用于保存会议录音

会议相关web服务器接口

web服务客户端、服务端

录音下载

web客户端、服务端

录音回放

查询会议web接口

用于回放录音服务器上的录音

查询频道web接口

下载频道录音文件

回放界面

旁听席集成一起

将录音和服务器放在一起

教室管理

布局图

布局图编辑

可编辑布局图，集成到控制台中，可进行旋转与缩放

布局图显示

根据编辑的布局图进行显示，并区分已连线与已登录的状态

客户端设定位置

客户端可自行设置位置，使用MAC地址进行识别

基础管理

网络唤醒

根据作为的MAC地址，发送唤醒包，进行网络唤醒

点名

询问学生姓名，提示学生输入姓名（学号）

关机/重启/注销

控制所有的学生机或选中的学生机关机/重启/注销等操作

导出学生名单

导出在堂的学生名单

行为控制

禁止上网

禁止USB

禁止应用

基础功能

全班讲话

点对点通话

点对点通话并广播

音频广播

桌面广播

文件传输

发送文件

发送单个或多个文件到学生电脑

发送/打开文件

发送文件到学生电脑并打开

收集文件

收集学生电脑系统工作文件夹下的文件

删除文件

删除学生电脑系统工作文件夹下的文件

查看教师电脑上的文件

查看教师电脑系统工作文件夹下的文件

文件活动

Word文档

发送Word文档到学生电脑，并打开，停止活动时保存文档，并收集到教师电脑

PPT

同上

Excel

其他类型

音频活动

教师麦克风

使用教师麦克风作为音源，进行教学活动，学生端双轨录音

教师机音频

使用教师机音频作为音源，学生端可双轨录音

媒体文件

使用一个媒体文件（MP3或WAV）作为音源进行教学活动

选取桌面区域，进行视频广播（同时也可以广播音频）进行教学活动

同传训练活动

与语音室音频活动类似，客户端需做对应的调整

会议音源

从会议设备输入音源

其他音源

其他可配置成为输入的音源

桌面区域广播

演示版功能

数据库本地化

暂时用sqlce

webapi服务器端-大文件上传

wcfwebapi

webapi客户单大文件上传下载

webapiclient

webapi接口服务客户端和服务端

演示版和正式版切换

配置工具、适配功能。

系统授权

教师端集成

授权信息显示

3.4开发工具、技术

系统开发使用了当前比较流行的一些技术，系统设计到CS客户、web服务端、FTP文件服务器、android端，具体详情见下图

3.5支撑平台

无

3.6安全体系

本系统主要部署在局域网中，对网络安全不高，所以我们的一些web接口没有经过加密。

系统中授权模块使用了非对称加密算法。

3.7进度

1）甘特图（摘要任务甘特图）

2）里程碑

时间

里程碑

偏差

2016-01-31

Demo

2016-04-08

演示版

2016-06-01

内测版

略有偏差

2016-06-30

稳定版

3）计划使用工时/实际使用工时

4）出现差异的主要原因

第三阶段里程碑出现错误的主要原因是开发人员变动，核心开发人员病了、新员工刚进入项目组需要一段时间来适应。

3.8人力投入

1）说明计划人员配置和实际人员配置。

以及人员组成。

各个人员的项目角色和工作职责。

人员

角色

职责

鲁云

产品经理

产品设计、平台设计、搭建

王杰

研发

平台维护、客户端研发

语音底层研发

梅元

服务器研发

李亮

测试

系统黑盒测试

杨涵

2）人员投入的时间分布图。

下面统计了2016第一季度和第二季度项目各组员参与的工时。

4项目评价（尽量用图例配合说明）

4.1对生产效率的评价

给出实际生产效率，包括：

⏹程序的平均生产效率，即每人月生产的行数；

⏹文件的平均生产效率，即每人月生产的千字数；

并列出原订计划数作为对比。

4.2变更管理评价

用户需求变更没有，主要模仿比较成熟的系统。

4.3对技术方法的评价

给出对在开发中所使用的技术、方法、工具、手段的评价。

说明采用的技术特点，以及利弊。

技术

优点

缺点

WPF

做界面效率高

开发工具编辑界面不稳定。

WCF

开发效率高

很有经验才能使用好。

配置很繁琐。

FTP

有成熟的开源框架

开源框架简单，无法完成复杂功能。

IBatis

上手快，性能高，自己写sql控制性好.

无法切换数据库，维护了。

很久不更新.

Webrtc

性能高、稳定

框架太大、加功能周期长、需要做跨语言、android平台只能在Linux开发。

Webservice

开发简单

维护难，有性能瓶颈。

RDP

稳定，使用简单

Win7下效果不是很理想。

Sqlserver

功能强大，简单

安装部署复杂。

NAudio

开源库很不稳定，产出现底层bug，极难修复

4.4对产品和过程质量的评价

同传系统总体项目bug统计

同传系统总体bug趋势统计

同传系统每人解决的bug统计

同传系统bug严重级别占比统计

4.5风险管理评价

下面对系统中出现的一些风险做了写评估

风险

结果

经验

紧急人员变动

其他人要花很长时间来熟悉代码。

1、系统还是要有些必要的设计文档。

2、项目组所有成员对代码都要有些了解。

不确定的技术方案

经历了较长时间的摸索和解决问题。

有些技术还是要实现进行识别并进行预研。

但是还是会出现不了的技术难点，这种只能逐渐研究。

产品定位，现在产品的定位不清晰，只是单纯的在模仿别人的功能

暂时还没有解决

4.6出错原因的分析

开发中出现的错误的原因分析。

错误

分析

解决

功能返工

沟通问题。

增加设计时间、流程图、界面原型，添加设计评审环节。

第三方库不稳定

开源库有时会有隐患bug，很难改，不好查原因。

尽量不适用个人开源库、新库、长时间不更新的库。

出现代码丢失

本地代码不安全。

应尽快将代码上传到SVN服务器

项目开发人员能力不均衡

项目组人员开发能力不均衡。

导致任务分配不平衡，有的组员能力得不到锻炼。

1、项目组内互相帮助

2、项目组成员承诺的工期尽量按时完成，有问题及时反馈。

4.7客户满意度分析

4.8遗留问题

说明项目有无遗留亟待解决问题。

如果有，必须针对这些问题进行深入分析，明确责任，提出解决方案。

1）遗留bug，主要有些是开源库底层的导致不是很好处理。

2）没有去真实现场测试。

3）没有压力测试（多个学生、大于2小时）。

4）缺失系统设计文档，测试用例。

5经验及教训

同传系统开发工作中所得到的最主要的经验与教训及对今后的项目开应该注意问题。

收获

1）磨合开发团队、测试团队、项目成员得到了锻炼机会。

2）积累了一些技术（RDP、语音相关、数据库本地化、开发平台）。

3）沟通更透彻，更清晰。

4）晚上提前发布新版本。

不足

1）缺少必要的需求文档和设计文档

2）缺少阶段性成果展示、缺少设计评审。

3）对于延期处理的bug，开发人员尽量批注下说明，避免bug再次激活确认，又被打回的情况出现。

4）在开发过程中，开发人员是否可以避免一些错别字或是页面样式上问题的出现。

开发过程中如有时间的话，尽量做到发现立刻修正习惯。

以此减少测试人员，在提交类似bug且回测bug上的耗时。

5）测试人员配合开发人员重现bug，或者给他们提供测试数据，占用测试时间。

测试人员尽量提供截图、及时抓取系统日志、保留测试数据给开发。

6）产品需求有待完善，以此减少Bug类型为设计如此和不予解决的bug产生。

让开发和测试人员，对需求理解上，达成共识。

6建议

1、执行敏捷开发流程

2、不定期进行代码评审。

7结论

总体来说同传项目是成功的，以完全满足验收标准为成功。