| 这个作业属于哪个课程 | 2019学年02学期单红老师软件工程实践 |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件评测 |
| 这个作业的目标 | 对腾讯即时通信IM的demo进行调研、评测后阅读《构建之法》相关内容完成随笔写作 |
| 作业正文 | https://www.cnblogs.com/ginphy/p/12731787.html |
| 其他参考文献 | 构建之法 |
第一部分：调研，测评
评测：
1.体验Web端Demo
Web发起聊天
Web查找好友
Web语音通话：Web端语音通话无法传达到移动端，发现一个疑似Bug，在Safari浏览器中即使停止语音通话之后仍会识别为还在通话中影响其它页面的声音播放
Web创建群聊：在移动端中创建群聊不需要填写这么多信息，群名称在web端中必填但在移动端不必须，用户体验不统一
2.体验iOS端Demo
iOS添加好友
iOS接受语音通话：发现BUG，iOS端接受Web端发来的语音通话时会现实为无法识别的消息
iOS换头像
iOS群组聊天
iOS个人聊天：发现疑似Bug，iOS端拉黑对方后仍然可以向对方发送消息，但是无法撤回，取消拉黑后撤回成功
iOS查找用户：会出现UI与系统重叠的问题
3.体验小程序端Demo
小程序语言通话
小程序修改资料
小程序群组聊天：点击弹起的输入选择面板会遮挡下层的几条消息
小程序好友列表：拉黑后仍然存在于好友列表中不会消失！
小程序私人消息：消息UI中文字没有与气泡对齐！
4.其它BUG总结
1.在微信小程序中查找用户发起聊天的过程中，即使输入了正确的、存在的用户名也会现实【未找到该用户】，直接导致发起群聊功能无法使用。
分析：开发者的数据库出现问题，查找的用户为用户名还是用户昵称并未指明，设计上有缺陷。
2.在iOS客户端中即使对方已经读取了你发送的消息并且对你进行了回复，界面中仍然显示该消息未读。
分析：开发者未对该功能进行详细测试，或者在测试过程中疏忽了。
3.语音通讯存在多个BUG，在iOS端接受语音通话请求时无法正常显示，只会提示为【不支持的自定义消息】，在Android中更是没有语音消息入口。而在小程序接受语音消息时偶尔会出现对方接通但本地没有显示接通仍然停留在拨号状态的问题。
分析：开发者在不同平台的语音通讯Demo没有统一。
构思产品：
产品描述
一款面向校园的校内通讯系统，针对教学科研过程进行开发，同学和老师可以在该产品中交流教学信息。
主要功能
支持教学相关文件传输，对敏感文件做好隐私保护，支持复杂公式显示，支持.pdf、.caj等格式文档的显示，方便查阅文献，支持图表等数据展示。
面向用户
大学师生
用户分析
该类群体是需求明确，学习能力强，生活中常使用各类软件产品，需要经常需要接触各类文献数据，信息交流频繁。
采访：
采访对象背景&需求
采访对象为一名学习经济管理类专业的大学生
平日里有通过QQ、微信等常用软件收发Office文档并编辑查看的习惯。在学习过程中经常需要使用手机内的Office软件打开通过通讯软件下载的文档进行学习。
采访对象使用demo
对SDK的建议
“注册有点太简单了，找回密码会不方便，还是要换个界面，现在这个太丑了，如果有了安卓和苹果版应该就不会用小程序版了，打开很麻烦，还不如直接用微信。”
对我想开发产品的意见
“听起来还不错，但是老师可能不会用这个，已经习惯用QQ了，如果可以直接编辑一些数据就更好了，希望可以对报表的一些数据自动格式转换。”
对腾讯即时通信的评价
推荐：“和QQ差不多，一看就会用，苹果和安卓都可以下载，占内存也不大，如果有其他人一起使用的话自己也会跟着一起用。但是有点卡卡的，如果不卡就更好了。”
第二部分：分析
估计时间
一个由福州大学软件工程系毕业生组成的六人小组预计开发项目所需时间为2-3个月。
优劣分析
与类似软件相比优势在于平台分布广，大学师生使用的数码硬件产品种类繁多，跨多个平台的特性有利于向师生群体推广；并且背靠腾讯在技术支持和推广上有利；软件轻量化，专注性强，相比较于一些臃肿的即时通讯软件更易获得目标群体青睐。劣势是进入市场较晚，面对即时通讯软件的红海市场难以打开局面，让师生用户放弃原本的交流方式有一定难度。跨多个平台也会导致开发成本上升，对于一个小团队而言负担过重。
具体建议
在各类即时通讯软件竞争激烈的今日，这类专注性强针对特定群体的产品需要在需求阶段就找到准确的产品定位，切入细分市场吸引特定用户，在开发过程中要注意进度控制，不同平台的开发过程需要团队的及时交流来保证产品的体验是统一的、一贯的，降低用户学习成本，注意提升产品效率，保证忙碌的师生用户群体能够在该产品上“用完即走”。
第三部分：建议和规划
目前市场上的同类产品
CAJView（论文阅读软件）
Tim（商务轻量通讯软件）
叮叮（商务办公软件）
......
NABCD分析
Need：本产品主要是针对大学师生，在师生的网路交流过程中，经常需要发送一些学科相关的内容，其中就包括了复杂的数学公式、代码片段、数据图表、论文文献等内容，这些内容种类复杂，现在存在的一些工具并不难做到这类数据的保真传输，往往需要借助截图等手段才能发送，这就导致了在交流过程之中严谨的教学资料无法原原本本的发送给对方查看，也照成了很多不便。目前许多论文平台如CNKI等下载的文档有多种格式，有些格式不被常用软件支持，如果下载专用阅读器一来效率较低，二来部分数据在不同阅读器上显示效果也会有差异。所以需要一个平台能够完善信息的显示并且将信息的“传输”与“显示”两部分统一结合起来，方便师生用户的使用。
Approach：
【技术方法】基于SDK进行开发，先以Web的形式完成该项目，因为Web平台的应用可以被大部分不同平台的硬件产品打开。在即时腾讯通讯的基础上添加类似CAJView的文档显示功能板块用于阅读信息，使用md格式来进行文本传输，支持多种格式的数据显示，包括代码格式。
【运营模式】首先在校内进行推广，联系到校内相关人员将其先作为校内交流工具进行早期迭代，前期免费使用接受赞助，等到产品反响良好产品形态成熟后向社会推广，后期作为专业软件向使用单位收取少量费用作为平台运营成本。
Benefit：
对于在校师生来说具有了专业平台进行数据分享，有利于避免因文档图表信息传输失真照成的资源浪费。校内平台有利于信息保护，有在一定程度上保护了教师原创内容的知识产权。学生在与教师交流时与传统的邮件途径相比也提升了效率，减少了不同平台的学习成本。
Competitors：
【优势】与类似软件相比优势在于平台分布广，大学师生使用的数码硬件产品种类繁多，跨多个平台的特性有利于向师生群体推广；并且背靠腾讯在技术支持和推广上有利；软件轻量化，专注性强，相比较于一些臃肿的即时通讯软件更易获得目标群体青睐。打通了信息的“传输”与“显示”两部分，大大的提升了交流效率。
【劣势】部分师生已经习惯了使用竞品软件进行交流，转变平台需要一定的学习成本，作为小团队的产品在博取社会信任上有一定难度，前期推广有压力。
Delivery：前期依靠校内人员使用进行产品迭代并积累口碑，后期依靠院校积累的口碑进行下一步推广，当使用人数规模达到一定程度以后主打专业性进行面向全国院校的大规模推广。
团队领导方案
如果是我来领导这个团队，我会注重需求的分析与进度的把控，作为一个小团队，在开发过程中需要进行合理的任务分配，在前期迭代中采取敏捷开发模式，对于师生的需求建议快速响应迭代产品。
配置人员
1人前端设计 1人文档撰写与测试 2人后端开发 2人前端开发；项目的需求分析与后期的迭代建议由所有成员一起完成。
16周安排
| 时间安排 | 目标任务 |
|---|---|
| 第1周 | 需求分析、确定开发环境 |
| 第2-3周 | 软件设计、制作产品原型、撰写需求规格说明书 |
| 第4周 | 进行数据库设计、完善系统结构设计、撰写系统设计说明书 |
| 第5-6周 | 进行基础信息传输部分开发 |
| 第7周 | 接口对接 |
| 第8周 | 测试修改与美化 |
| 第9-13周 | 进行各类数据传输部分开发 |
| 第14周 | 测试修改与美化 |
| 第15周 | 发布Demo版本，获取用户反馈 |
| 第16周 | 针对用户反馈优化后上线正式版本 |
项目部署
| 设备 | 数量 |
|---|---|
| 后端服务器8核32G | 4台 |
| 应用服务器4核8G | 2台 |
| 关系型数据库 | MySQL数量6（读写分离4、备份2） |
| 分布式缓存数据库 | Redis数量4 |
| 安全性 | WAF、DDOS |
注意大量数据文件对于存储设备的压力