易货beta版本项目展示报告

一、团队成员和个人博客地址

PM:刘猛

开发人员:胡亚坤,董元财

测试人员:马汉虎,赖彦谕

团队名:bestRW

团队博客地址:http://www.cnblogs.com/niceRW/

董元财:http://www.cnblogs.com/dycaly/

胡亚坤:http://www.cnblogs.com/myskety/

刘猛:http://www.cnblogs.com/liumeng-buaa/

马汉虎:http://www.cnblogs.com/xmscse/

赖彦谕:http://www.cnblogs.com/Cocky

二、团队项目简介

1. 团队项目目标:开发一个可用于校园学生之间进行二手商品交易的android应用。

2. 预期典型用户:凡是有出手自己闲置不用的物品但仍有价值需求的学生,尤其是一些升了级的学生们,他们的

课本,资料都可以借助这个应用发布出去。

  • 典型用户和场景1

易货beta版本项目展示报告_第1张图片

  • 典型用户和场景2

易货beta版本项目展示报告_第2张图片

  • 典型用户和场景3

易货beta版本项目展示报告_第3张图片

3. 预期功能:具备浏览商品和发布商品的功能,用户之间的交流通讯功能以及交友功能。

4. 预期用户数量:100-200,但未达到预定下载量。

主要原因:

  • 完成时间比较晚,延误了推广;
  • 软件推广力度欠缺;
  • 该应用是基于用户参与的,在前期推广未能取得良好效果的情况下难以形成对应用热度的正反馈。

5. 团队分工:

我们团队一共有5个成员,在M1阶段时由于PM参与了开发工作,所以团队项目的管理有很大的欠缺,于是在M2阶段我

们将PM换给了刘猛同学,将团队分工更加化,开发的效率有所提高。明确同时董元财、胡亚坤为开发人员,马汉虎、

赖彦谕为测试人员。但是在分工之中我们也存在一些问题,最主要的还是测试相关的,开发人员开发速度有些慢导

致测试测试人员前期任务量较少。

6. 团队项目地址:

服务器:https://github.com/dycaly/TLMSever

android客户端:https://github.com/fishtobeonthetree/yihuo

7. 相关文档:

团队项目功能规格说明书:http://www.cnblogs.com/niceRW/p/4931445.html

团队项目技术规格说明书---服务器:http://www.cnblogs.com/niceRW/p/4932033.html

团队项目技术规格说明书---客户端:http://www.cnblogs.com/niceRW/p/4932567.html

8. 测试:

服务器单元测试代码覆盖率:http://pan.baidu.com/s/1mhuwUZu

http://www.cnblogs.com/niceRW/p/5116139.html

三、Beta阶段更新说明

我们在beta版本主要加入了以下几个功能:

1:增加了用户的发布界面

2:增加了用户的购买界面

3:使用下拉刷新取代了之前的handler后台更新

4:优化了网络连接框架

5:重构了好友请求与消息列表布局

功能描述图片

易货beta版本项目展示报告_第4张图片

易货beta版本项目展示报告_第5张图片

易货beta版本项目展示报告_第6张图片

易货beta版本项目展示报告_第7张图片

易货beta版本项目展示报告_第8张图片

四、项目实际进展

燃尽图

易货beta版本项目展示报告_第9张图片

易货beta版本项目展示报告_第10张图片

易货beta版本项目展示报告_第11张图片

易货beta版本项目展示报告_第12张图片

易货beta版本项目展示报告_第13张图片

易货beta版本项目展示报告_第14张图片

易货beta版本项目展示报告_第15张图片

易货beta版本项目展示报告_第16张图片

易货beta版本项目展示报告_第17张图片

易货beta版本项目展示报告_第18张图片

易货beta版本项目展示报告_第19张图片

从以上燃尽图可以看出来我们有一段时间的进度比较缓慢,这主要是因为开发人员当时忙于编译和数据库等作业,

况且开发人员也比较少,所以拖延了工程的进度,这也间接导致了软件完成日期延迟,没有时间做过多的推广的工作,

导致用户量没有达到预期目标。这是我们需要改进的地方,没有为工程的进度制定合理有效的规划。

五、团队成员M2贡献

姓名 角色 贡献 团队贡献分
刘猛 PM 博客 30
胡亚坤 开发人员 博客,android客户端代码1000 84
董元财 开发人员 服务器代码:500,android客户端代码:800 85
马汉虎 测试人员 测试数据、人工测试 31
赖彦谕 测试人员 20

六、项目特色

  • 荷兰式拍卖

荷兰式拍卖(Dutch Auction)是一种特殊的拍卖形式。亦称“减价拍卖”,它是指拍卖标的的竞价由高到低依次

递减直到第一个竞买人应价(达到或超过底价)时击槌成交的一种拍卖。

  • 人工式

人工式无声拍卖:是早期的传统减价拍卖形式,是先由拍卖师当众报出最高价格,然后由投买人据此逐一应价。凡

遇无人应价的价位,拍卖师由此递减报出新的价位,逐次降价,过程一直持续到有人购买为止;凡遇两个以上应价

的价位,拍卖师应由此递增报出新价,即立即转入增价拍卖形式,竞相加价过程一直持续到无人再加为止。

  • 表盘式

表盘式无声拍卖:也是荷兰人发明的,是现代化的减价拍卖形式。即指先由拍卖师当众报出最高价格,用电子拍卖

钟上的相应刻度显示出来,然后再由投买人按动电钮逐一应价,凡无人应价时,则拍卖钟指针逆时旋转,表示递减

降价,直到有人按动电钮使其停转表示购买为止。凡遇两个以上应价时,则拍卖钟指针顺时旋转,表示递增加价,

直到剩下最后一人按钮使其停止。在此,电子拍卖钟取代木制拍卖槌作为成交工具。

  • 特点优势:

相对于普通的校园二手交易平台,我们的平台能够给卖家或者买家更加公平的价格,而且有效的缩短了成交时间,

帮助卖家更快的售出商品。由于它定时降价的特性,也更加容易电子化。

另外,我们认为我们的同学在这样的一个类似于竞价拍卖的过程中,不仅能够以实惠满意的价格购得所需的商品,还

可以体会到竞价购物的乐趣,属于一个轻松愉快的过程,应该会受到很多同学的欢迎。

六、团队从用户那里得到了什么反馈,有什么样的bug?这是预料之中的还是没想到的?

得到的反馈首先是软件中有的商品不多,数量有限,这其实完全是意料之中的,因为发布较晚,只是在我们的一些群里

做了相关的推广,用户不是很多,而我们这个软件又是基于用户分享的,所以前期必然会出现这个问题。另外还有一些

bug,比如说某些页面的信息更新不够及时,没有在第一时间更新,这个其实也在考虑范围内,因为考虑到过于频繁的ui更

新会影响整个程序的性能,所以舍弃了某些及时的用户体验。还有在登录时有时需要多次点击登录按钮才会登录进去,

这个bug目前还没有找到原因。

七、团队和M1相比,在软件工程方面有什么进步?

我认为我们的M2比较M1而言,比较明显的改善就是M2我们做了一些对软件的测试,虽然不多,但比之于M1,还是有很大

进步的,另外团队之间的合作性也明显加强了。

M2 postmortem:http://www.cnblogs.com/niceRW/p/5115381.html

八、总结

1、实现做好项目规划非常重要,要为整个项目制定合理有效的进度规划,确定好每一阶段性任务,并且做好对突发情况的

准备,这样整个开发过程才会有条不紊。

2、团队成员之间的分工要制定明确,确保各个成员都能为整个项目贡献出自己的一份力量,加强团队成员之间的交流协作

是软件工程顺利进行的保障。

3、尽可能多尽可能熟练的掌握相关的开发知识,这样在开发的过程中才能少走弯路,提高效率,同时也能保障性能。

4、重视测试的重要性,要为做出的软件的质量负责,确保开发出来的软件质量可靠,应用性得到保证。

至于建议,就是真正因为做好软件工程这门课,需要我们付出很多的精力,只有这样,才能通过一个充实的过程感受到软件

工程开发这一整个过程内涵所在,我们这学期就是由于编译、数据库等大作业压力的存在,时间比较紧张,没能够很好地做好

软件工程的每一个阶段的工作,非常遗憾,所以希望这门课可以在同学们有足够时间和精力空间的时间开展,比如可以错开

编译之类的课程,这样达到的效果应该会更好一些。

你可能感兴趣的:(易货beta版本项目展示报告)