一.回想开学初对于软件工程这门课的期望，总结本课程对你带来的提升：
1.团队名称
风启团队
2.项目名称
寝室分配管理系统
3.学习和使用的新平台
学习了基本的APIcloud手机APP开发平台相关内容，利用APIcloud平台完成项目
APIcloud进行数据库设计
4.学习和使用的新工具
mockplus原型设计工具，设计项目原型。
Enterprise Architect类图，用例图。
coding 远程代码仓库。
5.学习和使用的新语言
css语言
HTML语言
JavaScript语言
6.学习和掌握的新方法
MarkDown的排版方法
7.完成的代码量
因为我负责的是数据库发方面的，所以代码量大约100行。
二.总结与展望
1.经验总结
软件工程这门课程对我来说还是很难学习的，因为有很多知识我不会，学到些不能够很好的应用。
在这次团队合作项目的过程中我明白了很多东西只有团队一起努力才能更好的完成。
2.对学弟学妹的建议和告知
学习每一门课程都会接触很多新东西，对于新的知识要努力学习并掌握。
认真完成老师布置的作业，不懂得问题要多向老师提问以提升自己的编程能力。
好好学习专业课知识，平时有时间多学多问。
要注意团队成员间的合作，有想法和问题要及时讨论，多沟通。
3.对自己团队的分析
萌芽阶段：成员组队，初步讨论要做的项目
磨合阶段：确定要一起合作完成的项目，分工进行资料的查询
规范阶段：小组之间一起讨论，分工，确定要个人完成的部分
创造阶段：通过自己的学习，完成小组组长分配的任务并一起整合，最终完成整个项目的制作
4.个人发挥
团队合作的项目，成员之间的合作沟通才是最重要的
三、对第一次软件工程作业中的五个问题重新回答
1.课本的第六章敏捷流程105页提到敏捷流程，它的开发理念我经过查找资料得到：
（1）个体和沟通胜过实施过程和工具；
（2）可以工作的软件胜过面面俱到的文档；
（3）客户合作胜过合同与谈判；
（4）响应变化胜过遵循计划。
2.2.课本的第十章第207页提到功能驱动设计，只写了怎样分步构成，可到底什么才是驱动功能的设计呢？
驱动功能的设计（FDD）是一种模型驱动开发的软件过程，和XP一样是敏捷软件开发方法的一种。FDD的主要思想是对功能的实现，也就是说FDD是以实现功能为目标。把系统分解成一个一个的功能集，每个功能集又习细分为具体的功能。是移动通信系统中使用的全双工通信技术的一种，与TDD相对应。FDD采用两个独立的信道分别进行向下传送和向上传送信息的技术。为了防止邻近的发射机和接收机之间产生相互干扰，在两个信道之间存在一个保护频段。比如说用户管理是个功能集，而用户管理又包括了增加用户、删除用户等具体的功能。域建模是其系统设计的方法，用到的是color uml，也就是常说的四色原型，在项目设计过程中回有很大的作用。
3.课本第93页提到瀑布模型，什么才是瀑布模型，有没有缺点？
经过查询资料，我知道了瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。但是他也有缺点，因为各个阶段的划分完全固定，阶段之间产生大量的文档，会极大地增加工作量；而且由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险，虽然缺点是有，但还是一个很强的模型。除了这些，他还有许多欧典，每次当前一阶段完成后，只需要去关注后续阶段，而且可以在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能，每次迭代必须经过质量和集成测试；它还提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导，有了这些作用，就能更好的运用瀑布模型。
4.课本第十三章软件测试中提到黑箱测试的方法有哪些：
等价类划分、边界值分析、错误推测、因果图和综合策略，其中因果图测试用例的基本步骤：
⑴ 分析软件规格说明描述中，那些是原因（即输入条件或输入条件的等价类），那些是结果（即输出条件），并给每个原因和结果赋予一个标识符.
⑵ 分析软件规格说明描述中的语义.找出原因与结果之间，原因与原因之间对应的关系. 根据这些关系，画出因果图.
⑶ 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件.
⑷ 把因果图转换为判定表.
⑸ 把判定表的每一列拿出来作为依据，设计测试用例.
5.课本第一章13页提到冒烟测试，那么什么是冒烟测试呢：
对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。冒烟测试是微软首先提出来的一个概念,与微软一直提倡的每日构建有很密切的关系.具体地说,冒烟测试就是在每日构建之后,对系统的基本功能时行简单的测试,冒烟测试这个名称的来历,大概是从电路板测试得来的,因为当电路板做好以后,首先会加电测试,如果板子没有冒烟则进行其他测试,否则电路板冒烟了,则证明电路板有重大缺陷需要重新设计和开发.在软件开发中,冒烟测试的对象 是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作.在持续集成的开发环境下,每天都会生成很多可用的Build,但是并不是每个Build都会送到测试人员或者客户去测试,以确认系统的基本功能.冒烟测试可以避免重要的严重错误被传送到测试人员或者客户手中,以免造成时间浪费和可能的不良印象.