软件工程--个人总结
回想开学初对于软件工程这门课的期望，总结本课程对你带来的提升：
1.学习和使用的新软件：
本学期软件工程的学习中，学到的新的东西就是UML建模工具(Enterprise Architect)
2.学习和使用的新工具：
UML建模工具的设计及分析部分
3.学习和掌握的新语言、新平台：
微信公众平台的应用、新浪云云端服务器。
4.统计一下，你在这软件工程实践中，完成了多少行的代码
在软件工程实践中，我的任务是网页设计制作，项目的优化及需求规格说明书的撰写，所以代码量相对较少，大概完成了450行左右的代码。
5.学习和掌握的新方法
在软件工程这门课中，我学习到了分析软件需求的方法、UML设计方法、项目原型的设计方法和软件测试步骤等。
总结与展望
1.记录自己在软件工程课程上的经验总结
对于首次团队合作完成任务的我们来说，在这次项目制作中，我学到了，我们不能仅仅靠一个人的想法活着方法来实现或者说要以团队合作为主，任何事情都需要沟通和商量、所谓三人行必有我师，要在学习过程中发现别人的优点并向小组成员学习。
在设计过程中，我们不能不考虑用户的需求分析，不能以自我为中心，一个项目的实现不能单靠自己的想法来做，要从用户的角度考虑项目需求，根据项目背景做出合理的期望，要既符合用户的要求，又突出项目的技术性。
对于下一届的学弟学妹你有什么建议和告知呢？
首先，一定要选好自己的项目，不要觉得无所谓，项目的选择决定了你接下来所要做的一系列工作。其次，千万不要觉得自己能力不够或者觉得别人能力不够你就不去与团队沟通，要知道在团队中沟通交流才是最重要的。最后，在团队合作中要虚心接受别人的建议，不懂就问，不会就学才是精髓。
分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？
我们团队从刚开始组队时每个人的拘谨害羞到简单的沟通到团队取名到私下聚会，其实每个阶段我们每个人都能感觉到一种惺惺相惜。我们团队名草帽队，取自海贼王漫画，意思是希望我们团队有海贼王漫画中的海贼团队一样团结，也意味着我们应该像主人公一样要有坚韧不拔，永不放弃的精神。所以我认为我们应该达到《创建之法》中的创造阶段了。
三、通过本学期的学习，对第一次作业中的5个问题重新回答
1）软件开发流程中有很多模型，但是在软件开发过程中我们该如何选择最合适的模型？（第五章 团队和流程）
答：根据自己团队的特点进行筛选。
2）需求和任务之间的关系是怎么体现的？（第六章 敏捷流程教材107页 提问原因：各个需求和任务之间有种种复杂的依赖系，但是这些依赖关系到底该如何去体现）
答：在开发的时候，需求和任务有明显的区别。需求是功能点，任务是完成功能点需要执行的工作。
其他阶段，需求和任务并没有明显的区别，最大的区别在于，需求没有周期概念，任务有预期时间，完成时间。
3）怎样才能尽可能地减少Bug？
答：在编写代码时要认真，然后不断地进行软件测试。
4）团队如何测量并跟踪软件的效能？
答：不断地进行软件测试。
5）一个程序的代码如何去复审？
1 、在复审前代码必须成功地编译
2 、 程序员必须测试过代码。
3 、程序员必须提供新的代码，以及文件差异分析工具。
4 、复审者可以选择面对面的复审、独立复审或其他方式。
5 、在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。
6 、复审者必须把反馈意见逐一提出。
7 、开发者必须负责让所有的问题都得到满意的解释或解答，或者在TFS 中创建新的工作项以确保这些问题将来会得到处理。
8 、对于复审的结果，双方必须达成一致的意见。
a. 打回去——复审发现致命问题，这些问题解决之前不能签入代码；
b. 有条件地同意——发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；
c. 放行——代码可以不加新的改动，签入源码控制服务器。
6）试验MVP时，添加VIP服务的链接，观察有多少用户点击此链接，若点击量小，VIP服务就可以不用做，那么这个点击量应该怎么确定，用户和点击量的比例是多少的时才算是点击量小？（第五章 团队和流程 教材101页）
答：看情况而定，拟定一个比例。
7）MVP有适用范围，和它对应的是最强最美产品，若在软件开发过程中太过注重产品的外在形态，而不注重其“内涵”，是否太理想化。（第五章 团队与流程 教材101页）
答：软件开发过程中既要注重外在形态也要注重其“内涵”
个性发挥，包括图文、照片和创意等
1.第六章：什么时候选择敏捷开发？它的缺点是什么？（在看到第六章敏捷流程的步骤的时候想到我们应该在什么情况下选择敏捷开发呢，如果敏捷开发那么它的缺点是什么？中国软件开发的情况又是什么呢）
工作在小的团队中
团队是跨功能的-包括测试人员，开发人员，文档开发人员等等
短迭代-利用短迭代方法来交付软件
相较于文档，敏捷开发更注重面对面的交流
敏捷不是一个过程，而是一个软件开发的形式或者方法
敏捷可以与软件过程如CMMI等一起实施
选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:
(1)方法的复杂度。确保你的团队或组织能够应付这种复杂度。
(2) 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。
(3)实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。
(4)对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。
(5)你的团队规模。较小规模的团队最好从简单的方式入手。
(6) 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。
2.第七章：怎样理解并有效运用MSF？
MSF(微软解决方案框架结构)是一组建立、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业和技术的目标，降低采用新技术后系统整体的费用，以及成功的应用微软技术整合商业过程的方法。他负责制定计划,每天找出完成该计划的风险所在,排除风险,每天交付应该完成的内容,确保计划按质、按量实施。 ·用户教育。设计友好的用户界面,对用户进行培训,确保用户能够并且愿意和喜欢使用开发出的产品。 ·开发。开发者在开发前期就参与用户需求分析和项目计划制定,他最清楚具体的开发过程。在开发期开始后,他负责进行代码开发,在每一个阶段,交付每一项内容的代码。 ·测试。负责开发出的代码的测试。测试者并不是要找到每一个开发者的每一段代码的每一个错误(bug),而是要找到代码错误之间的关系,解决最根本的错误,掌握错误的状态,从而迅速排除错误。
3.第七章：怎样快速辨别用那种模式开发？
根据团队自身情况分析，对照《构建之法》中各种开发模式，选择与自己团队项目相近的模式开发。
4.第八章：怎样才能准确的分析出用户的需求？（用户需求无疑来说很重要，但是我们在没有条件或者没有很多用户调研的情况下应该怎样才能准确分析出用户需求？）
首先要圈定明确的客户群，只有明确的客户群才能让我们很好去研究，其次，要学会用客户的语言来描绘产品。最后要想说服客户，就必须了解他当前的需要，然后着重从这一层次的需要出发，动之以情，晓之以理。在与客户沟通的过程中，你可以通过观察客户的非语言行为了解他的需要、欲望、观点和想法。总而言之，通过适当地问问题，认真倾听，以及观察他们的非语言行为，可以了解客户的需求和想法，更好地为他们服务。
5.第十三章：在众多测试方法中如何选择合适的测试方法来测试系统？
根据几个分类来选择：
(1)从测试设计方法分类：实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。
(2)从测试是手动还是自动上分类：对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试，总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。
(3)从测试的目的分类：测试的范围从小到大，从内到外， 从程序开发人员（单元测试）到测试人员，到一般用户Alpha/Beta测试。非功能测试：一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段-基本功能完成后做这些测试。
(4)按测试的时机和作用分类
(5)按测试测策略分类（文章来自于http://bbs.jointforce.com/topic/26283）
就我个人来说，我认为要根据用户要求对比上述方法分类，对软件的性能、功能、兼容性等方面进行测试。要具体问题具体分析，结合测试软件实际，科学有效的测试你的软件，细心、客观的判断，当然测试过程中要积极交流，虚心学习，一旦发现测试方法不对时应及时总结经验，善于学习，勤奋思考
