团队有一些共同的特点：有一致的集体目标，成员之间有各自的分工，合作完成任务。团队一开始可能是"一窝蜂模式"，都想写出好的软件，但是没有各自的分工，一般不会这种模式不会存活太久。慢慢会演化成其他模式，比如"主治医师模式"，本来是不错的模式，但是在学生身上退化为了一个学生干活，其余打酱油的情况。还有比如明星模式，社区模式，业余剧团模式等，当然其中不乏一些好的模式，秘密团队，交响乐团模式，功能团队模式等。
学校里面的软件工程专业的学生可能是"写了再改模式"，因为作业是这么要求，但是这种开发方法的缺点特别大。
软件行业一开始也会使用"瀑布模型"，即分析-设计-实现-销售-维护的模式，但是对于软件工程来说，需要做很多次的回溯。但是慢慢发现回溯很困难等等的其他问题，需要在生产出产品之后才能知道产品的实用性，这是很头疼的问题。
后来根据"瀑布模型"提出了生鱼片模型，但是问题是：不知道上一个阶段什么时候结束。后来引入了子瀑布模型，但是难度相当大，用户只有到了最后才能看到结果，也不实用。
后来提出了Rational统一流程，即后面的统一建模，用精确的语言把用户的活动描述出来。流程为：业务建模，需求，分析和设计，实现，测试，部署，配置和变更管理，项目管理和环境。RUP分为四个阶段：初始，细化，构造，交付。
在UML这门课中，我们学习了用例这一概念，用例包括标题、角色、主要成功场景、步骤、扩展场景这些元素。我们在使用用例时要遵守其使用规则。但同时，用例使用也有它的局限性：不适合交互式之外的系统；故事的粒度没有固定的标准，和具体的项目有关，初学者难以掌握；如果关键在于用户体验的细节，不能把UI的细节嵌入故事中，并保持故事的简明性。
规格说明书包括软件功能说明书和软件技术说明书。功能说明书，主要用来说明软件的外部功能和用户的交互情况，从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率、国际化、本地化、异常情况等，不涉及软件内部的实现细节。技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。
把用户的需求变成团队可以直接操作等工作，这是功能驱动设计。要进行构建总体模型、构建功能列表、制定开发计划、功能设计、实现具体功能五个步骤。
如果软件团队在软件测试方面没有足够的投入，最终的系统会存在许多问题。
有一种流程为老板驱动的流程，这种流程有好处也有坏处。好处是老板比一般技术人员懂的市场和竞争；坏处是领导毕竟对于软件开发是外行，并且不一定能管理好软件团队。
还有渐进交付的流程，重复开发-发布-听取反馈-根据反馈做改进这个过程，直到完成迭代次数，或者客户满意。