团队总结

------------恢复内容开始------------

这个作业属于哪个课程	课程的链接
这个作业要求在哪里	作业要求的链接
团队名称	goldenexpress
这个作业的目标	团队总结

队员学号列表
王伟 201731062214
刘冬 201731062227
张旭 201731062129
秦裕航 201731062432 （组长）
git地址https://github.com/isliudong/eyoo2

组员总结文章

1张旭

博客链接https://www.cnblogs.com/wocaishizhangxu/p/12036870.html

第一次博客链接

• 尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实际，或者讨论弄明白的
  问题1：横向对比，自己与小组成员或他人在同样技术的学习中开发项目的能力，出错次数来比较
  问题2：可以采用奖励的方式进行用户调研

• 是否产生了新的问题？请提出
  其实通过这门课程的学习我发现在开发过程中很容易出现自己无法估计的问题，在解决问题的过程中很费时间，而且解决这个问题后有可能会出现因为解决这个问题而出现的新的问题，所以我想知道如何避免或减少这类情况的发生。

• 经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
  1.javaweb开发，通过自学java学习网站和做项目。暑假时学过java，但还是有很多忘记了，通过这次的项目联系，巩固了自己的java知识。
  2.查找资料的能力。之前自己连需要查找什么问题都不知道该怎么描述，现在我常用谷歌查找或者使用github查找问题
  3.绘制uml图，数据库设计。我学会了使用Visio，navicat工具
  4.和小组成员之间的沟通，项目规划。

• 有什么深刻的体会，对自己一学期学习过程的总结。
  一学期的时间对于自己认真学习的话真的很快，总觉得时间不够，学的也不够。但还是收获了很多，其中有团队开发项目的经验和个人自学技术的经验。
  比如在开发工作的规划，我们小组会首先分析该工作的难易程度，然后分配给不同的人。在项目前期准备时，我学会了项目文档的编写，各种类图的绘制。在团队合作方面，我学会了git版本控制工具。通过小组编程，真正的体验了敏捷开发的过程和妙处。也学会了用到了很多实际开发中需要用到的工具，比如前端的自动工具。
  在测试的过程中知道了如何对自己的代码和别人的代码进行测试

2刘冬

《构建之法》——个人总结

一、请回望第一次博客作业，你对于软件工程课程的想象和提出的问题

在我的第一次博客作业中，我认为软件工程是个关于软件创造的学文，现在看来其实也差不多；

在第一次写博客时我提出了几个关于软件工程的问题，虽然当时也有一点思考但是只是片面，现在来看当初的我是多么的才疏学浅，这门课让我懂得了许多。

二、链接到以前的博客链接

第一次的博客链接（稚嫩却不失真诚，哈哈哈）

三、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄明白的

1.第一章概论中我对：软件=程序+软件工程的说法不是很理解。这样写是不是就是程序和软件工程是分开的意思呢？意思说软件工程不包括程序是吗？

个人观点：其实我发现是大致这样的，但是软件工程是不包括程序的，它是一种方法。以前我认为这里的软件工程是一种狭义的说法，将程序本身认为是工程的原料，而不是要达成的目标。意思是：软件是将原料通过工程后的产物；这相当于从来源定义软件。还有一种说法是：软件等于程序加文档，这应当是从组成来定义软件的。

2.在第四章两人合作结对编程中，两个人共同完成一个任务，如何确保两人的工作量?如果有人偷懒岂不是很难发现？

个人观点：以前我认为这应该是这个模式最大的缺点，合作必然造成极大的耦合，责任难分。在允许的条件下可以加入第三方监督者，这样既可以发挥结对编程的优势又可以避免其带来的负面影响。其实也不错，只是现在知道了一种方法很难十全十美。

3.第十三章中讲了很多种软件测试方法，但是我怎么知道要用哪种合适呢？

个人观点：以前我认为既然没有明确提出测试程度分类，是否可以认为这是个极大依赖经验的地方呢。其实这里是需要测试者有一定的能力，知道用什么方法去测试。

4.第五章团队和流程中，5.3.5老板驱动流程中作者归纳该方法的原因为如下四点：1.订单靠老板个人关系 2 .大型企业，往往软件功能由行政部体系决定 3.老板更懂市场和竞争 4.团队未成熟

个人观点：以前我认为可能老板本身就是技术大牛，团队也很成熟，所以老板可以把方案说得很仔细，也是一种因素吧。其实大致没错

5.第十一章软件设计与实现的11.5.3构建大师一节中，将构建的任务交给每次导致构建失败的人，会不会容易导致项目构建出现不稳定，或者增加隐藏bug呢？

个人观点 ：以前我认为将构建的任务交给每次导致构建失败的人，因此这个人大概是轮换的，不是专业的，容易出现问题，还可能发生责任不明确的问题。确实可以这样，但是不妨加一个监管者

四、是否产生了新的问题？请提出。

产生的新的问题：

暂无

五、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

包括以下内容：

1、哪一次作业让你印象最深刻？为什么？

　　关于写博客，发现博客原来不是那么难写但也不是一件简单的事

2、累计花了多少个小时在软工实践上？　

　　

3、学习和使用的新软件；

git、服务器控制相关软件

4、学习和使用的新工具；

git、墨刀、Axure、idea git插件等

5）学习和掌握的新语言、新平台；

无

6. 学习和掌握的新方法；

项目管理，敏捷的开发、结对编程，软件项目开发流程控制

7. 其他方面的提升。

团队协作能力、编码能力、查找能力、交流能力、文档撰写能力

项目开发过程中可能会写到的文档：

1、可行性分析报告
说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。
2、项目开发计划
为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
3、软件需求说明书（软件规格说明书）
对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。
4、概要设计说明书
该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。
5、详细设计说明书
着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
6、用户操作手册
本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
7、测试计划
为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
8、测试分析报告
测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
9、开发进度月报
该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
10、项目开发总结报告
软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。
11、软件维护手册
主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。
12、软件问题报告
指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。
13、软件修改报告
软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

3王伟

博客地址https://www.cnblogs.com/westweishao/p/12039963.html
一、请回望第一次博客作业，你对于软件工程课程的想象和提出的问题
在我的第一次博客作业中，我把软件工程的东西概括为就是搞软件的，但是现在来看的话，事情并不像我曾经想象的那样就是单纯的编代码。经过我一学期的学习我现在对软件工程这个概念的理解是一个工程，一个类似于修建高楼大厦一样的工程，软件在准备开发以及开发完成的时候，它包含了很多的流程，比如：需求分析、概要设计、详细设计、编码、测试、软件交付、验收、维护等。并不是单纯的像我当初那样一个人写了些小程序就认为理解了软件工程的全部，实际上那只是属于软件工程中编码实现的一点点部分，这完全是就是在坐井观天，我曾经提出了几个问题，现在我准备在后面的内容中来回答一下，学习了一学期之后的我现在的理解。

二、链接到以前的博客链接
第一次的博客链接（现在看到就很呆，哈哈哈）

三、尝试对自己提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄明白的
1.如果在代码长期维护过程中会有更新升级，这个时候就会有新的单元测试，但是如果每个都去重写，那么维护的代价就会变得很大，而且工作量也会变多，到底该怎样去解决这个问题呢？

如果在项目一开始的时候就采用了一些合理的设计模式的话，代码的重写就不会很难，况且在本次实验中我还学会了Idea的一个JUnit4的插件，他可以对我们的类方法进行一键生成测试框架，只需要写出具体的测试逻辑代码就行了，还有在开发的时候对一些可能会发生变更的东西进行封装或者定义，这样在之后修改的过程中对于这一类的数据就会很好的进行修改，通过查阅资料我了解到了一个叫做测试自动化这样一个概念，有很多工具可以提供帮助，比如Parasoft Jtest，有些第三方库甚至还提供内置参数化的功能，这大大减小了测试的难度与复杂度，更重要的当然还是写代码的时候就要注意代码的可维护性和可读性，并且一般来说，使用mock（模拟）作为依赖项使我们作为测试人员的生活更容易，因为我们可以为社会化代码生成“单独的测试”。对复杂代码的社交测试可能需要大量设置，并且可能违反被隔离和可重复的原则。但是由于模拟是在测试中创建和配置的，因此它是自包含的，我们可以更好地控制依赖项的行为。另外，我们可以测试更多代码路径。例如，我可以返回自定义值或从模拟中抛出异常，以覆盖边界或错误条件。

2.结对编程

对于结对编程这个我提出了一些疑问，而且我当时认为结对编程在现实中可能并不是一个比较好实现的编程方法，但是现在我能说在一般情况下确实比较难实现，因为你需要考虑到很多地方

1）对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。

2）有时候，程序员们会对一个问题各执己见（代码风格可能会是引发技术人员口水战的地方），争吵不休，反而产生重大内耗。

3）两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。

4）结对编程可能让程序员们相互学习得更快。有些时候，学习对方的长外，可能会和程序员们在起滋生不良气氛一样快。比如，合伙应付工作，敷衍项目。

5）面对新手，有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐

6)有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。

因此就我目前来说，我还是不太看好这种方法，可能对于一些特定项目实现的时候可能会用到，但是就目前在学习实际体验的情况来说我不太看好

3.敏捷的开发原则怎么来实现一个动态平衡，我现在体会也不是特别多，但是我还是愿意用我粗略的知识来谈一谈我的看法，在实施敏捷的过程中，我发现有些东西是比较理想化的，但是实际也有很多办法可以解决这类问题，比如一些有经验的PM就会运用以往项目开发的经验来应对这样一些问题，敏捷的开发模式不是代表一种特定固有的模式，他会有很多根据实际项目变化的地方，并且在敏捷开发的过程中，对于很多问题都已经有了办法解决，有些甚至可以用到一些计算公式来解决，因此实现一个动态平衡的时候，是需要一些项目经验的，而不是空口说怎么实现，应该具体的问题用具体的办法来解决。

4.产品经理(PM，Project Manager)，对于这个可以直接参看现成的博客，这是一些比较成功的产品经理的总结，其中那个包含了我的问题甚至还有一些更多的我没能涉及到或者想到的问题。

参见博客：

作为产品经理，你真的知道如何收集用户反馈吗

5.关于对做中学的看法或者说新阶段的理解，值得一提的是目前大部分人都是采用这种方法的，并且这也是效率最高的用来学习一个技术的地方，但是注意如果你是一个小白，请不要使用这种做法，在打基础的阶段也就是学习基本指示操作的时候不能使用这种方法，对于基础薄弱的同学，我建议还是要一步一步扎实基础比较好，对于如果能清楚知道原理，并且懂得如何进行简单操作的人，可以采用这种方法，不然的话你就会发现，每个地方你都不知道该干嘛，也不知道下一步怎么做，对于自己的基础没有把握或者基础不好，没有思路的同学，我不建议采用这种方法，当然如果你已经基础很扎实了，那么这种方法还是非常值得推荐的，毕竟这是最有效率的最快的方法。

四、是否产生了新的问题？请提出。
产生的新的问题：

1.在测试web项目中对于一些传值，不像传统的一些数据，而是一些其他通过一些方式封装的，该如何对此类方法或者类进行测试，对于这种是不是没有办法测试，对传入的数据该如何找到。

2.在软件开发过程中没有遇到过这样一个问题，假设成员技术水平不高，则到最后完成的项目就会延期甚至完不成，在对团队使用敏捷方法的时候，有没有看滤过每个人的技术水平，各自技术水平不够的话，该如何处理这种情况，（假设都是学生，学习知识的熟练度各不相同，而团队成员中没有能够挑大梁的成员存在），这样的团队就会完不成任务，有没有考虑过这样的情况。

五、经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
包括以下内容：

1）哪一次作业让你印象最深刻？为什么？

　　Alpha版本这是第一次在这我的电脑上进行团队项目的开发，从克隆开发提交都是花了很大的功夫，每一步我感觉基本上都查了互联网（这纯属我比较菜），而且在搭建项目环境的时候也遇到很多的问题，不过好在在团队成员的帮助下，我成功完成了项目环境的搭建，并成功运行了一个demo

2）累计花了多少个小时在软工实践上？　

　　在实际开发过程中我编码的时候比较少，项目找过来的时候是个半成品，但是在一些原理探究或者说基础上我还是花　了一些时间，特别是在实践写博客这样一个事上我是比较认真的，基本上都是一到两个时，每天在学习基础技术上基本在1小　　时左右的样子

3）学习和使用的新软件；

git、码云（强烈推荐这个软件很好地解决了git慢的问题）、idea

4)学习和使用的新工具；

墨刀、Axure、

5）学习和掌握的新语言、新平台；

Java，SQL server，IDEA

6. 学习和掌握的新方法；

简单项目管理，敏捷的开发原理、结对编程，软件项目开发过程

7. 其他方面的提升。

团队协作能力、文档编写能力,

项目开发过程中可能会写到的文档：

1、可行性分析报告
说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。
2、项目开发计划
为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。
3、软件需求说明书（软件规格说明书）
对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。
4、概要设计说明书
该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。
5、详细设计说明书
着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。
6、用户操作手册
本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。
7、测试计划
为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。
8、测试分析报告
测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
9、开发进度月报
该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
10、项目开发总结报告
软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。
11、软件维护手册
主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。
12、软件问题报告
指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。
13、软件修改报告
软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

六、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？
萌芽阶段
团队初期，我可以感受到，组员比较依赖我发布任务，那个时候，我队每个组员的能力也尚处于了解之中，任务的安排有些不是很合理，并且很多地方是通过传统的丢骰子的办法来分配任务的

磨合阶段

团队的组员都比较负责，基本没出现什么冲突，会议还是再开，不过比较随意并不是特别严谨（不过这种氛围很好）

规范阶段
经历过alpha阶段，我们小组在beta阶段冲刺时就更加合作无间，组员各自从teambition上领取任务完成。测试同学在teambition反馈bug，开发同学领取bug任务修复，整个beta阶段的工作有条不紊的进行着。

七、怎样证明你学会了软件工程？软件工程的有些什么内容
1）研发出符合用户需求的软件

必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件；

第一天注册用户达到4人

第二天注册用户达到9人

第三天注册用户达到14人

有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件

通过一些列的工具、流程、团队合作

4秦裕航

（也是个人博客）

1.回答问题

问题一
我看到第四章的结对编程，百度了一下什么是结对编程。书上81页说到结对编程是一个相互督促的过程，每个人的一举一动都在别人的视线之内，所有的想法都要受到对方的评价。 当一个程序员处于流模式（Flow），另一个在一旁学习（Learning）——若另一个程序员时不时地打断他，并要求对一些基本的但与挑战性问题没有直接关系的事情做出解释，那么他很难专注于解决挑战性的问题。-引用自（什么时候该采用结对编程）因为两人的能力不一样，相互督促的话起到的作用并不大，同时每个人的想法不一样，有些人就不愿意接受别人评价，碍于所谓的面子。所以我觉得结对编程不仅双方性格要合得来，还要虚心接受别人的意见。那结对编程是利大于弊，还是弊大于利呢？ 我感觉还是利要多点，俗话说“三个臭皮匠，顶个诸葛亮”，团队合作比单打独斗更好一些。
回答:

利:程序员互相帮助，互相教对方，可能得到能力上的互补。
降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。
可以让编程环境有效地贯彻Design。
增强代码和产品质量，并有效的减少BUG。
在编程中，相互讨论，可能更快更有效地解决问题。

弊:对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
结对编程可能让程序员们相互学习得更快。有些时候，学习对方的长处，可能会和程序员们在起滋生不良气氛一样快。比如，合伙应付工作，敷衍项目。
新手在面对有经验的老手时会显得非常的紧张和不安，甚至出现害怕焦虑的的精神状态，从而总是出现低级错误，而老手站在他们后面不停地指责他们导致他们更加紧张，出现恶性循环。最终导致项目进展效率低下，并且团队貌合神离。
有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。]
问题二
针对于复杂的开发确实很有用，回想之前自己开发的几个程序，只是简单的执行，使用敏捷开发并不适用，简单的东西也许敏捷反而不敏捷了？
针对这个问题，确实如此，通过本次的对敏捷开发的学习与具体的实践，真正明白了他的实用的地方，也真正领略了他的魅力。确实对于小项目不用敏捷开发，比如就我自己一个人写的或者就我和我的小伙伴两个人的项目确实不适合，首先是针对敏捷开发起码最少也是三个人，敏捷的含义就是最注重沟通解决问题，两个人之间也很方便，反而增加这样一个流程会显得很麻烦，这样的小规模软件开发可以用原型开发或者边设计边改的模式就可以。
然而对于一个具有工程性需求不明确随时在变动的项目来说，敏捷开发就能真正的恰到好处，因为他天生就是给需求变动的项目设计的一种软件过程，他的三个角色以及里面的三个工件甚至每一个活动，现在真的能够体会到他设置的相应的意义，缺一不可。
问题三
可能当时我去曲解了作者的意思，或者理解的不够彻底，对于秘密团队模式，如果一个人入选了这个团队中去做开发，那么相对于没有入选的人来说，我就在从事一项不为人知的任务，那么其实我们的心理就有一种很高傲的心态，也会很积极的去对待团队中的开发任务，所以团队中的人相对于其他人对于项目就有了更高的热情，也不需要随时随地的向别人报告进度，从而也拥有了极大的自由度，一个团队的成员如果有很大的自由度，又有独特的使命，这就是一个很大的驱动力。
问题四
软件工程的创新
软件工程本就是不断发展着的，就在我敲下这篇博客的时候，软件工程又在他的世界前进了好几年。人类社会对于如何评判一个事务的创新不是看的它的外观（它也确实没有外观），而是它是否符合人类的价值取向。说到底，软件工程就是一种思想，就像马克思主义一样。它依赖于人类的思想而拥有他自己的形态。我认为它已经创新了，对于上世纪的函数式和面向过程编程来说，现代软件工程已经是很先进的思想了，任何事物都是一直处于发展中的。能够降低人们做软件项目的效率就是它进步了，对人类有帮助的就是创新了，这就要看人类对它本身的看法和理解了。但是我认为它创新了，于是它就创新了。
问题五
第十一章的软件设计与实现，书中223页提到了软件是怎么解决这些需求的？现实世界中的实体和属性在软件系统中是怎么表现和交换信息的？，以及224页的两个类似的问题，只是问法不同，解决方法相同。我们在软件的设计和实现的过程中，怎样才能构建一个与客户所要求的软件类似的模型呢？我们不仅要把需求分析透彻，还要建立多个模型相互比较，选择最优的那个。建立的模型就是把用户的需求所描绘了进去，在仿照模型去编写软件，这样就可以解决用户的需求。在开发过程中，模型出现问题，是否得重新建模，还是在原有基础上加以改进?
回答：在数据库设计阶段，就要做好概念模型的分析，然后再创建合理的ER图和关系模型，最后再建立合适的物理模型。其次是项目经理在和客户沟通时，就要把客户的想法了解透彻，然后做好需求分析。建立多个模型，判断多个开发模式的优缺点，择优选取项目需要的开发模式。如果开发的过程中，用户需求又改变，模型要改变，这样大大增大了开发的成本和进度，我个人觉得不一定需要重新建模，可以在原有的基础加以修改，就能适应客户的需求，如果需求变更过大，不得不重新建模，这要双方进行合理的商议后再签订需求变更条约，才能开展下一步的工作。

2.经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

在课堂之上学到了不少关于软件工程的知识，了解什么是软件工程。
重点了解了敏捷开发，并应用敏捷开发作为小组的开发模式，为小组的项目开发，完整的实验了敏捷开发的流程，同时也熟悉了个人软件流程，个人在软件开发中要用到的技能有单元测试、效能分析、回归测试等等。在项目开发过程中，需要用到软件项目管理的知识，需要确立项目经理、产品经理，对项目进行风险管理，合理的安排计划并对项目进行评估，使软件的质量得到保证。
通过此次的项目，让我了解到团队的作用，也让我认识到了团队协作的重要性。每个组员在团队里各司其职，团结协作，相互激励。

3.分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？

• 萌芽阶段
  团队初期，任务布置混乱，大家摸不着头脑

• 磨合阶段

  团队成员开始合作宛城相关任务，开始朝着一个井然有序的方向前进，不再是各搞各的

• 规范阶段
  大家开始在第一个alpha版本发布后，统一遵守团队规范，统一编码格式，统一文档格式等等；再也不是靠自己去猜了。

4.怎样证明你学会了软件工程？软件工程的有些什么内容

1、研发出符合用户需求的软件

必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件；

第一天注册用户达到4人

第二天注册用户达到9人

第三天注册用户达到14人

2、有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ；每个人都自己的事项目井然有序，严格依照流程办事

5.最后说几句：

项目完了，课程也结束了，但这只是个开始。

软件工程这门课教会我的不仅仅是代码工程，它是一种思想，是一种在往后生活工作中无处不用的工程思想；同时谢谢这门课让我体会到实际的工程开发之间的团队合作交流。

文档汇总

汇报ppt

eyoo
团队项目-构建之法
需求分析展示

设计文档

eyoo选题计划书
golden express需求规格说明书模板
概要设计说明书模板
燃尽图
数据库设计
详细设计说明书