摘要：
通过了几个月坚持不懈的努力，我们组也终于完成了最终成果。关于趣拼图，我们从最初的界面设计到现在的完成，其中也经历了许多，也遇到了很多问题，但我们也都解决了，也从中了解到完成一个项目有多不容易，也从中体会到了团体合作的重要性，下面就先展示一下关于中等的拼图的代码经，这是经过修改最多的一个部分。 阅读全文
摘要：
用例图主要用来描述用户、需求、系统功能单元 之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。 描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依 阅读全文
摘要：
这是我们现在要做的小程序的简单的迭代目标，我的一部分工作就是修改其中错误的代码，通过找资料和与别人沟通，暂时先修改了一些关于小拼图登录界面的代码。 修改好的可以看下面截图，之前的代码因为监听器设置不到位，触摸的时候不能及时反应，界面不能实现。这是修改后的代码，在给注册登陆按钮安装监听器代码后，原来顠 阅读全文
摘要：
我们的产品：趣拼图是为了更好地解决6-28岁年龄段的痛苦，他们需要更好的小游戏推荐，利用起碎片时间，提高智力开发，但是现有的方案并没有能很好的解决这些需求，我们有独特的办法制作一个趣味拼图的APP，它能给用户带来更多好处，多提供了动脑思考的时间，质量更好的小游戏，更有灵活性，微博上达人的推荐，同时我 阅读全文
摘要：
阅读全文
摘要：
我们的产品：图书鉴赏是为了解决18岁到28岁青年的痛苦，他们需要更好的图书推荐，更多的好书，但是现有的方案并没有能很好的解决这些需求，我们有独特的办法制作一个图书鉴赏的APP，它能给用户带来更多好处，更多高质量书的阅读，远远超过竞争对手，微博上达人的推荐，同时我们有更高效率的一传十，十传百的方法，能 阅读全文
摘要：
我个人觉得渐进交付模型更好 第一：它能更早地获得用户反馈，相比于瀑布模式更加快捷，而且瀑布模式也快要被淘汰。 第二：它更早期地强调商品的用途以及价值，不用做太多的无用功。 第三：客户从一开始介入，做出的产品是符合他们要求的，更容易接受。 但是这样也有一些不好的方面，比如客户一直不满意，不愿意继续投资 阅读全文
摘要：
我们组选择的是交响乐团模式和功能团队模式，交响乐团模式中需要大家精诚合作，每个成员都不可或缺，相互协作，在这种模式中需要一个具备实力的指挥者并且要求指挥者需要很强的组织协调能力。我适合将分配到自己手中的任务较好地完成，因为我编码方面有很多欠缺。 再说功能团队模式，在这种模式中，团队成员之间的磨合所耗 阅读全文
摘要：
还可以降低学习成本。我编程不如刘晓燕，她可以教我很多，我能有效地在实践中进行学习。在编程中，相互讨论，可能更快更有效地解决问题。 但是我们两个人在一起工作可能会出现工作精力不能集中的情况。我们会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。结对编程可能让我们相互学习得更快。学习对 阅读全文
摘要：
LoginActivity中缺少对onClick方法if（） else的判断。添加语句：if(LN.length() <=0 && LP.length()<=0){Toast.makeText(LoginActivity.this,"用户名和密码不能为空",Toast.LENGTH_SHORT).s 阅读全文