- 学习和使用的新软件 Mockplus原型设计软件 PowerDesigner数据库设计软件
- 学习和使用的新工具 Enterprise Architect UML分析和设计工具 EPP php编译工具 My sql 数据库管理系统 WampServer PHP安装集成环境
- 学习和掌握的新语言、新平台 语言：HTML、PHP、CSS、JavaScript 平台：EPP 新浪云平台
- 在这次软件工程实践中，完成了2000行代码
- 学习和掌握的新方法 软件开发方法及其测试方法； 数据库设计及连接； 原型界面的设计； 使用PHP和MySQL制作动态网页。
- 总结与展望
- 记录自己在软件工程上课程上的经验总结 在进行实际的项目操作之前，要做好需求分析，UML建模，根据自己具体的项目进行典型用户分析，原型设计，最后编写代码，进行软件测试。每一步都要按部就班的来，不可偷懒及懈怠，每一步都是为了最终的项目最后可以实现的更好打下了坚实的基础。另外，在团队实践之前，一定要明确分工，每天针对各自负责的模块进行总结，把各自的问题汇总解决。一定要进行软件测试，这是必要的，只有在测试的过程中才能发现出在开发过程中发现不到的隐藏问题。对于软件工程这门课程，我确确实实学到了很多，不管是从专业技术开发软件还是从团结协作团队合作与人沟通上，我都受益匪浅。
- 对于下一届的学弟学妹的建议和告知。 在开发之前一定要慎重选择自己的项目，选择适合自己并且感兴趣的项目，在其基础上加入自己的东西，使其逐渐成为自己的东西。一定不要厌烦除了项目之外老师留的作业，因为每一次作业都是你所做的项目的基础，只有这些完全做好了，后期在编写代码创建数据库等才不会有差错。
- 分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？ 基本上吧，萌芽阶段，磨合阶段，规范阶段到创造阶段都经历过了。一开始，大家刚刚组队，对自己的任务和工作也没有太大的认识，所以处于一种萌芽，中间的磨合过程，有意见不统一，有争论，但是最后大家还是会通过投票的方式抉择出一种最合理的 办法。磨合之后，逐渐有了默契，配合度极高，渐渐的自觉地都知道自己的任务，有的时候任务完成得很好并且还去自己多揽一些任务，大家齐心协力，共同进步。最后每个人都很享受那种默契和齐心协力的感觉，当项目完成时，大家内心的成就感是无法言表的。通过这次难忘的经历，每个人都或多或少地学会怎样去和身边的人欣赏、沟通和学习。
- 个性发挥，包括图文、照片和创意等
再一次放上我们五朵小花的合照，永远忘不了每天在图书馆五个人奋斗的场景，感恩你们给我带来的欢乐和幸福感，是你们让我对于团队这个词语有了更加深刻的理解。Reversal-destiny！希望每个人在未来的道路上扬帆远航！
- 问题 1、我看了这一段文字（2.12小节《好的单元测试的标准》单元测试不能解决所有的问题，不必期望它会发现所有的缺陷。），有这个问题（如果单元测试不能发现每个模块的所有缺陷，那做单元测试的意义又在于什么？）我查了资料，有这些说法（单元测试能发现约80%的软件缺陷，当然要发现这80%的缺陷也是要依靠设计出良好的测试用例，另外，软件测试行业有个二八原则，就是软件80%的缺陷存在与20%的代码中，因为缺陷放大理论，在单元测试阶段发现的bug会在系统测试阶段被放大。）由于还只是一个初学者所以没有太多经验，不过会在以后的实践中积累经验。但是我还是不太懂（究竟怎样才能做到100%的正确率？）（对于现阶段是无法很完美地做到拥有100%的正确率的） 2、我看了这一段文字（5.36小节《渐进交付的流程》中，正如所有的方法论那样，MVP也有它的适用范围，和它相对应的是MBP的思路。），有这个问题（看过书上对MVP的介绍了解这种开发方法，着眼于基本的客户需求，快速构建一个可满足客户需要的初步产品原型。通过客户反馈，逐步修正产品设计和实现，最终达到完全满足客户需要。是最符合敏捷思想的产品开发方法，特别具有实用性。但是它适用一个怎样的范围呢？MBP方法就是特别完美的吗？）我查了资料，有这些说法（MVP模式的问题在于，它并不总是开发颠覆性技术的最好办法。只是有些市场不合适。产品到底可以做到多好或者做到什么程度最好？答案或许永远也找不到。这种模式也不一定就是做大事情的最好方式。有些产品是小调，有的则是交响曲，而有时候你还是要先让音乐演奏起来。）但我还是不太懂，有这样的困惑（MBP方法有怎样的适用范围呢？） 3、我看了这一段文字（6.3《敏捷的团队》中，如果你的团队很弱，那么强行把敏捷（或其他高级方法）套在上面也没有用，也许还会适得其反。），有这个问题（能力比较弱的团队不能选择敏捷开发吗？怎样的团队适合敏捷开发？）我查了资料，有这些说法（实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。这样的团队适合敏捷开发：1、小团队 2、需求聚焦 3、工作内容无边界 4、团队无明显短板 5、互相信任 6、拥抱变化）但我还是不太懂，有这样的困惑（敏捷开发对于团队每个成员的能力具体有怎样的要求呢？）（最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工作，而且有能力承担他们面前的任务。） 4、我看了这一段文字（11.5.5《小强地狱》），有这样的问题（如果每个开发人员每天都对自己写的代码进行复审和单元测试可以在一定程度上避免“小强地狱”吗？） （是可以在一定程度上避免的） 5、我看了这一段文字（13《软件测试》）,有这样的问题(怎样才能做到避免Bug的发生？)我查了资料，有这样的说法（ 一、规范需求。对可能出现的客户体验类的开发效果事前做出明确的说明。 二、透彻理解需求+全面集成测试。 三、开发人员开发流程控制，单元测试。）根据我的实践（可以尽量减少Bug但是无论做到怎样全面的测试还是不能够完全避免Bug的产生。）但我还是不太懂（我认为不会存在可以完全避免Bug的软件，任何成功的软件都是在时时更新修复Bug，根据各种情况下用户的需求来进行修改的。）