个人总结——Beta版本

我们这次项目因为种种原因失败了，没办法达到预期的效果，这一点着实让人难过。但是作为一门课程，并不能说因为此次项目的失败就完全一无所获。在不断遇到困难和解决困难中学习，成长。虽然失败，但此次失败的经验教训，对我来说确实是一笔宝贵的财富。让我认识到了，软件工程不是简简单单的把程序合并就可以完成的，团队配合，统一标准，以及知识能力的不同都会影响到项目的成功，一个紧密的团队，和一套稳定敏捷的开发流程不可或缺。以下，我将从我个人的角度开分析我们此次项目的失败原因。
一：我们对安卓版编程的开发还存在许多需要学习的地方。因为是初次接触安卓开发，有许许多多的地方把握的不够到位，对于安卓连接 数据库方面的知识，欠缺严重。特别是本人在此次项目担任数据库开发工作，对此了解不够给团队和项目的进一步推进带来了很大的困难。例如，在数据库链接过程中，我们无法完全实现对数据库的增删改查。这个也是我们此次项目失败的最大原因。
二：我们对于软件工程的开发流程把握的不够到位，在不同的阶段我们对软件的认识不够，完全没有了解到在不同的阶段软件应该要完成到什么样子，因此我们在项目上的推进受到了较大的阻碍。我们在对前期对软件进行设计的时候，设想并不完善，但是在后期站立议会和冲刺阶段的时候被原本的设想限制了我们的思维拓展，导致我们一直在向一个有问题的方向推进项目。

回答问题：有些在前一个阶段所存在的问题，这一个阶段我们仍然继续存在，但是对于数据库的认识我有所加深，数据库的管理并不是一个简单的工作，数据库给软件提供件不可缺少的支持，只要数据库有了问题，软件就相当于瘫痪的状态，前台的所有程序的目的都是为了在用户和数据库之间架起连接的桥梁。

提出问题：1·第七章第四第五节中的MSF过程模型虽然对敏捷开发的有提供支持，但是我认为这样的模型，不具备团队稳定性，在各个阶段能够完成应有的部分，但是各方进行整合的时候，还是会存在许多不能够对接的地方，这种团队内部各司其职，软件细分各个阶段的方式固然有其优点，但是缺乏统一性，和稳定性，必须有人对此在每个步骤都进行统筹规划。

               2·在第八章第四节竞争性需求分析框架介绍时，提高软件的性能，和更完善功能真的就可以满足用户的需求了吗？

               3·在第九章中介绍到了PM（项目经理）这个角色，因为其做代码开发，和测试意外的工作，其中风险管理中除了人员，流程，技术，以及环境这么多类别，是否真的需要做到如此这般完满的风险管理，对于特别是对于环境问题，我认为这个更多应该是销售应该要去做到的东西，而不是我们开发人员应该去考虑的。

              4·第十一章第二节（data flow diagrama）介绍了表达数据流动的例子，但是并没有给出更加具体的设计方法和思想，表达数据流要怎样才能更好的分析数据的走向？怎么设计数据流动规则才能更好的提高软件处理能力
               5 ·第十三章第三节中介绍了一些测试概念，这些概念都非常模糊，我们知道测试无法把所有的bug都找到，但是，是否存在某种测试模型，和测试流程能够尽可能的减少bug出现在用户一方??