软工团队作业3

一.需求分析

1.题目

• 我们团队做的项目是微信记账小程序。因为属于新项目，所以使用问卷调查的形式对用户进行需求分析。

• 问卷链接：https://www.wjx.cn/jq/22110886.aspx

• 问卷结果：https://files.cnblogs.com/files/Team-Blog/记账小程序.rar

• 结果分析：

  首先，学生比上班族对于自己支出的规划更有需要，后面两个选项因为分别只有一个人，所以不太具有参考性，故先跳过
  

    这一张分析结果表明，学生月底资金更加不具有稳定性，可能会因为各种原因导致月底吃土，但是这不是一定的，通常会根据当月情况变化。所以如果说有这么一个软件可以规划每天的使用金额额度的话，会不会好很多呢？ 

    同样是上面的一个选项的另一种交叉分析，不论是哪个消费阶层的人，都还是有月底钱包空空的烦恼的。

    这张图就有一个很清晰的分界了，每个月的消费越高的人群，对于超前消费的一个态度。（不过这一点对于我们小程序好像没什么帮助......就单纯的觉得挺有意思的，然后就放上来了）

    经过前面的一个总体的问卷，大概还是能得出，学生比起上班族来说，对于这个记账的需求还是更强烈的。只是说大家还是会担心半途而废的问题，所以我们也在规划加入提醒的这个功能

    最后是一个对于我们这个软件，除了上述提到的核心功能以外，还有哪些需求。这边做了词频分析，更具体的内容在上面的压缩文件里有。其实基本上就是能想到的一些功能。比如说提醒，分类，账单之类的功能，大概都是从市面上有的这些产品出发的，果然有时候用户的需求要靠我们去引导和挖掘啊

2.软件需求规格说明书

• https://gitee.com/SE-Tally/Tally/attach_files
• 目前版本为1.0，很多东西还没完成，只有大体框架，等后续继续完善

3.NABCD写作

• N（需求）：

  （1）解决学生每月入不敷出的痛苦，他们需要合理的安排每月金钱，但是现有的方案并没有很好的解决这些需求。现在市面上的产品，只能说告诉你，你的钱花在哪了，还剩多少。没法告诉你，你怎么花钱，钱才够用。
  （2）另外，用户对于图表和账单的需求也是很大的，自己到底把钱花在哪些地方，这也是很重要的。另外就是用户需要自由的添加和删除消费记录，这些都属于一个正常的需求范畴。
  （3）不少用户提到的提醒问题，就是担心自己会忘了记或者是懒的记的问题。
  （4）界面美观且操作简单
  

• A（做法）：

  （1）我们有独特的消费账单和总生活费相结合的办法，再加以日历的帮助，能够更加全面清晰的展示出当前消费，可用余额，是否超支，花钱趋势，让用户更明确的感受到自己每天花钱的一个具体额度在哪。
  （2）账单和图表统计部分我们也会提供，常规操作就不多说了
  （3）关于如何“治懒”的问题，我们有想过加入提醒功能，比如说现在微信小程序里的打卡提醒之类的。另外，我们也有考虑微信小程序关联公众号，公众号用户可以置顶。在公众号里输入单笔消费，程序就可以自动加入到当天消费里，也算是方便了添加方式，省去了用户开小程序的时间了吧。
  （4）关于上述第四点，做法就是相信我们的前端小姐姐的审美了！
  

• B（好处）：

  （1）能够更好的控制每天的开销，最大程度的在生活费有限的情况下，避免很多冲动消费。比如说，当你看到今天已经超支了多少多少，那一定程度上，肯定不会愿意再花钱了（当然，毕竟是个记账的小程序，要是用户实在不愿意把开销记上去也没办法，毕竟我们不能直接关联到支付宝或者微信。但是真的需要的人，是真的会认真记录的）
  （2）方便查看明细，对自己后面的一些支出能够有所选择
  （3）方便用户操作
  

• C（竞争）：

  对于我们这一个功能，其他的记账软件好像还没有实现？下面会举一些例子，至少我看到的一些程序都没能实现我们这样的功能（也可能是我孤陋寡闻，没看到其他的）
  

• D（推广）：

  首先小程序基于微信平台，是现目前比较火热的一种应用使用方式。第二是我们这个小程序主要面向学生，身处校园我们更有推广的渠道优势。况且，我目前也没有很远大的目标......非要有多少人能用这样的......主要是自己就很需要这么一款软件
  

• 杀手功能：

  金额规划，就是前面一直在说的帮助用户管理的功能。实现每天金额的可控，每天使用多少都是根据一个月的总收入和支出来决定的。这个功能是我们最核心的功能，也是和其他同类产品最不同的地方。开发重点都放在这里，但实际的代码量可能没有一些外围功能多。因为这个功能的实现说不上太复杂，我们只能是胜在想法。

• 演说部分：

  致各位合作伙伴：我们的产品，微信记账小程序，是为了解决学生每月入不敷出的痛苦。他们需要合理的安排每月金钱，但是现有的方案并没有很好的解决这些需求。我们有独特的消费账单和总生活费相结合的办法，再加以日历的帮助，能够更加全面清晰的展示出当前消费，可用余额，是否超支，花钱趋势，让用户更明确的感受到自己每天花钱的一个具体额度在哪。虽然现在市场上以支付宝账单为首的一系列产品比较流行，但是他们都没有每天消费额度的提醒，这对于自制力较差的学生来说，是比较不友好的。我们现在处于市场中心，周围都是对此有需要的学生，传播的空间是非常广阔的。

• 视频地址：https://www.bilibili.com/video/av21919462
  （视频部分，由于比较赶，素材选用就不是很严谨，只是选用了以前做MAD的时候留下来的进行简单的剪辑，所以有些地方可能有点违和。另外，选在B站发布的一个原因是因为这里没有广告，对于点进来看的人来说会比较方便。记得老师给的例子里面好像有个视频放在优酷的，一分钟的视频我看了半分钟的广告......）
  

• 一些其他相同类型的小程序
  
  
  
  

4.团队分工

---

二.原型设计

• 具体每个页面的作用在下图有进行分别说明，前端页面没有做过多的优化，所以看上去不是那么好看，主要是把一些主要功能先给标明出来了。当然，第二阶段会在此基础上进行进一步的升级，但是现在这个情况基本是可以符合基本使用了。经过前面的问卷分析，不少用户希望用起来不要太繁琐，我们也参考了一些其他相同的小程序，对于用户添加当天明细的部分讨论了很久，最后还是决定使用大多数程序都采用的设计，把添加放在最中间的位置。
• 另外，上面的gif图是用电脑录屏之后，用PS生成的，其实很简单。
  参考博客链接：http://www.cnblogs.com/ycll/p/6683553.html （悄咪咪给自己打波广告）
  
  
  
  
  

---

三.任务分解WBS

• 关于成员时间预估部分，这边是到第一阶段为止的一个每个人的基本工作分配和大概的时间预估
  

---

四.编码规范

• 代码风格规范：

  • 缩进：4个空格

  • 行宽：默认值

  • 断行与空白的{}行：
    if(...){
    ...
    }
    else{
    ...
    }

    • 异常捕获：
      try{
      ...
      }catch{
      ...
      }

  • 分行：不同类型变量不同行。
    int a;
    char c;
    char d;

  • 变量名称：

    • 命名：小驼峰命名法
    • 下划线：暂时不用

  • 注释：

    • 函数开头注释函数功能：
      /**
      * ...函数--....
      */
    • 语句注释：
      //...

• 代码设计规范

  • 函数：一个函数实现一个功能
  • 成员修饰：使用public、protected、private说明类成员
  • 构造函数：
    • 简单初始化数据成员，不做复杂操作
    • 不返回错误
  • 异常处理：函数中需要适当的try-catch操作

---

五.系统设计

• 我们的一个整体系统设计如下图
  

• 各个层次之间的关系
  

• 数据库部分类图关系
  

---

六. 成员感想

• 杨晨露：这周要做的东西比上周多的多，虽然像用户问卷，NABCD，软件规格需求说明书这一类的东西上周其实我们就已经开始着手在弄了，但最后还是到最后一天才加班完成。需要整体考虑的东西太多了，因为很多地方又要进一步的细化需求和功能。比如在做原型设计的时候，因为沟通问题，我们的几个成员之间关于部分功能的位置和使用方法产生了理解上的偏差，导致做设计的和做开发的代码之间出现了偏差。之后又加紧开了两次会左右，再次进行沟通。开会其实挺重要的，还是我上周说的，面对面交流还是最有效的。（就是好像听说开会要拍照证明......？嗯......我们经常在五号楼下开会的，虽然没有物证，但是人证挺多的......）
• 游舒婷：理想很丰满，现实很残酷。感受到了被色表支配的恐惧，这一步等实际设置界面的时候再调配吧，网页设计常用色彩搭配对小程序好像有那么一点用又好像没用。模型设计是比较理想型的，没有很多界面修饰，主要展现的是一个功能，所以最后真正发布出来的界面可能会不一样，不过主要是围绕功能实现来进行的基本框架不会变。每次搞前端都在怀疑自己的审美。jns你们缺美工吗(ง •_•)ง
• 戴志斌：这周我的任务主要是学习微信小程序，通过官方文档，了解了小程序的代码逻辑，学习了mvvm的设计思想，然后大概的写了这个项目设计到的页面。然后后期由于沟通问题和原型设计做出来的界面有点儿不符合，，这个时候，pm紧急开了个立会，对页面进行调整，，最后确定下大概，也对页面进行了调整，，可以静下心来专门写后端了。后端最后想想还是使用django，然后数据库采用mysql。
• 姚佳希：这周我的任务是根据群众的和回馈的问卷调查做需求分析（感谢组织分配的较为轻松的任务）
  初阶段我们尽可能的想到需求，也会收到很多人的需求，有些很有意义，有些却没有什么实际价值，太多功能会让我们的设计失去核心功能，所以我们需要提炼这些需求。产品需求，正是迎合用户的动机，来帮助产品更好地实现目标，比如赛马的人想要速度更快，我们只需要给他提供一个很快的马，但是要是一个人想要快速的到达另一个地方，我们就需要给他们提供汽车。
  总结一下对需求分析的认知：1.了解产品定位 2.了解目标用户 3.对产品功能需求
  最后，再次向深夜催促我们交任务的PM老阿姨鞠躬，接下来的几个月可能都要一边喝着菊花茶降火一边督促我们了。
• 蒋勃超：Python这一语言的特点就是不用编译，程序在运行的过程中，由对应的解释器向CPU进行翻译，个人理解就是一边编译一边执行。而JAVA这一类语言是需要预先编译的。没有编译最大的痛苦就是无法进行断点调试，唯一的办法就是在有疑问的地方打印各个变量的值来进行调试。这一类语言也没用类型，也就是说一个变量即可能是int型，但是也可能是String型，而且可以随时变化。
• 附：做开发的同学，都不太擅长总结，比较苦恼，其实他们还是做了很多的......