团队项目：
作业管理互评系统
1.学习和使用的新软件
（1）VS2010：在我们的项目中学习了新功能还包括:C# 中的动态类型和动态编程;使用Visual C++ 2010创建界面
（2） Dreamweaver：DreamWeaver主要学会的就是做WEB前台应用的，功能很强大，而且修改完直接就能看到效果，但是难以精确达到与浏览器完全一致的显示效果也就是说在所见即所得网页编辑器中制作的网页放到浏览器中是很难完全达到我们真正想要的效果，这一点在结构复杂一些的网页中便可以体现出来。
2.学习和使用的新工具
（1）Git
（2）HTML
(3)学会运用了ps
3.学习和掌握的新语言、新平台
数据库
JAVA语言的深入了解
Coding代码上传
在JAVA基础上了解并学习了C#
4.统计一下，你在这软件工程实践中，完成了多少行的代码
统计了一下大概1000左右的代码
5.学习和掌握的新方法
asp.net来创建动态web页
软件测试
数据库的链接（C#连接SQL Server）
-
总结与展望
1.记录自己在软件工程课程上的经验总结
这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容而且团队沟通起到很大的作用，在这个过程中大家可以相互讨论总结问题，当接触到没有学过的东西时我们可以通过网络查询等渠道，因为项目中接触到我们许多没有接触的东西类似于数据库连接就一直存在很多问题，以及网页制作过程中的具体功能实现，都需要平常需要多加练习和巩固；进行项目分工时要根据每个人的实际水平来合理分配，否则会给项目上合作带来一些困难和矛盾，通过一个学期的不断学习和老师的教导也渐渐了解了这门课程的重要性，在每次实验中也提高了自己的编程和团队协作能力，希望以后自己可以多多练习这方面知识。
2.对于下一届的学弟学妹你有什么建议和告知呢？
要认真听讲及时巩固老师所说的知识点，课下可以通过向同学老师询问来完善自己项目不足的地方，在平时的训练中提升自己的编程能力；做项目的过程中小组成员一定团结协作，多沟通，合理分配任务，因为我们的项目中就存在这些问题，如果大家及时改正相互理解会容易许多。
3.分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？
- 萌芽阶段：团队刚成立时大家不适应不熟悉，意见也很难得到统一，所以项目一直停滞不前。
- 磨合阶段： 大家提出意见后互相谈论交流，相对于难点的任务大家都不愿意做，互评的功能做好又纠结上传作业等功能，大家也磨合了很长时间。
- 规范阶段：项目慢慢走向正轨，大家分配好自己的任务及代码，根据每个人的爱好和水平进行了一次合理的分工，大家都积极参与让我们的团队更加有序。
- 创造阶段： 大家在编程过程中提出意见相互改进，通过上网查找资料询问老师使我们的项目有更好的提升，虽然在整个过程中我们遇到过很多困难，但项目最终完成还是非常开心。
4.个性发挥，包括图文、照片和创意等
团队合作确实存在一些问题，在整个互评系统中一些功能还需要完善，通过这次的合作发现团队合作真的起到很大的作用。
个人总结的补充
请大家回顾我们软件工程第一次作业，通过本学期的学习，对第一次作业中的5个问题重新回答。
（引用了：软件工程第一次作业补充）
（1）在第三章《软件工程师的成长》中看到“高级工程师下班回家了，新手还在电脑面前工作，他们的行为没有什么区别：同样是在电脑前敲敲打打，有时候查邮件，有时候上网，有时看手机，讨论......似乎看不出谁更高级”而且在通常情况下软件工程师比普通程序员工资高，那么相比较之下如何才能成为一名合格的软件工程师？
答:通过查找阅读需要有良好的编程能力而且至少要精通一门编程语言才可以提高项目开发效率；认识和运用数据库的能力；具有软件工程的概念；求知欲和进取心；
根据我的实践认为最重要的一点要拥有良好的团队意识，只有团队可以更好的解决大规模的项目。
(2)在第二章《个人技术流程》单元测试中有的不是特别理解，例如书中VSTS,测试，我查了资料才知道是由微软开发的一套具有高生产力、高集成性、可扩展的生命周期开发工具，VSTS使得整个开发团队拥有更好的沟通与合作，并且保证了更好的质量的一套开发工具，那么这个单元测试对程序来说重要吗？检验一个单元测试的具体标准呢？
答:单元测试结果的好坏，是检验一个程序好坏的标准，是检验一个程序是否有隐藏的bug的标准，一个好的标准的单元测试能找到程序运行快慢的原因。
我通过查书和网上搜索了解到单元测试的具体标准包括以下几个方面：
1. 单元测试应该在最基本的功能/参数上验证程序的正确性
2. 单元测试必须由最熟悉代码的人来写
3. 单元测试过后，机器状态保持不变
4. 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
5. 单元测试应该产生可重复、一致的结果
6. 独立性—单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性
7. 单元测试应该覆盖所有代码路径
8. 单元测试应该集成到自动测试的框架中
9. 单元测试必须和产品代码一起保存和维护
（3）第五章《团队和流程》书后主要介绍了“”瀑布模型跟圆形模型都有它的特点——瀑布模型需求明确但不实用，圆形模型实用但需求分析不明”那么瀑布模型是否适应个人或者只有两个人的开发呢？
答：第一、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。
第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。面对以上的工作，所以瀑布模型并不怎么适合个人或者两个人的开发
（4）在阅读第八章《需求分析》后我学到了软件需求的类型，利益的相关者，获取用户需求的常用方法和步骤，四象限方法，可以说，在软件工程当中的"需求分析"就是确定要计算机"做什么"，要达到什么样的效果。需求分析是做系统之前必做的，需求分析确定了整个团队的方向，那么怎么在一个项目中如何做好需求分析呢？
答:需求分析人员对收集到的需求要做好进一步的分析，我认为主要有下面几个基本要求：
- 对于用户提出的每一条需求都要知道“为什么”；
- 需求分析阶段关注“做什么”而不是“怎么做”；
- 分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求。经常因为对隐含需求考虑的不够充分而引起需求变更；
- 需求要符合系统的整体目标；
- 需求项之间不应有矛盾。基于前面五点要求对收集到的需求进行系统可行性分析，对需求进行技术可行性分析、人力成本分析、时间分析；描述需求的分解功能项，需求分析不仅针对新收集的需求。我认为还应包括对产品研发过程中变更需求的分析。在产品研发过程中，需求变更不可避免。在需求变更后，需要准确分析此次变更对整个系统的波及，在这个过程中沟通成本巨大。但若分析不到位就有需求反复变更的风险。
（5）阅读第十章《典型用户和场景》了解到在做研究前，产品或交互需要能够明确列出这次想要衡量比较的场景。那么当没有场景可从中挑选时如何应对呢？
答:如果本身没有一个场景库可以从中挑选，那么可以简单的做一个场景脑暴，或快速访问搜集一下身边朋友的场景故事。最后选择出一些存在疑惑的场景来进行研究。