卢晓东：一周完成了设计模式和统一建模的两个大作业，感觉收获颇丰，无论是在编程能力上还是制作UML图上都有了一定的巩固，当然啦，最重要的是加深了自己对数据库和前端界面的一些了解，相信会对小学期的实践有一定的帮助，至于说代码的话，我就贴一下数据库部分的代码吧，因为都是现学现用的，所以有些地方还要理解好。

奚佳峰：

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，就是项目经理——PM

项目管理的复杂度似乎跟人员数量的平方成正比。一个团队里若有4个成员，就有6种双向依赖和交流的途径，然后增加一位新成员，就要增加4条新的双向依赖交流的途径。对于N个成员的团队来说，交流的途径总数是n×(n–1) /2，这种N的平方的增长意味着这样的交流对人类来说是不可持续的。

PM做开发和测试之外的事情，开发和测试都是专注于代码，代码之外，还有什么呢？还有很多不确定性——风险。PM要在整个项目的生命周期管理风险。对于软件项目来说，风险是在正常软件生命周期事件之外的、可能发生的影响项目的成功的事件。

应对风险的手段

进一步研究 

例如，“听说新的HTML5标准快要出来了，可能会极大地改进用户体验，我们目前用的原生代码很快会被淘汰！”，最好的回应就是做扎实的技术研究。

接受，不必为团队完全掌控不了的事情而过多操心 

例如，公司高层可能有人事变动，也许会影响到本项目……

规避：能否改变项目的范围，躲开这个风险？ 

例如，听说6个月后，监管机构会严格控制视频播放软件和机顶盒的资质，我们的项目能否避开这一领域？

转移，能否像击鼓传花那样，把风险交给真正有能力应对风险的团队负责？ 

例如，如果我们的软件进军到一个新的国家，可能会受到专利方面的许多指控。那么，我们能否让公司的法务和专利团队负责此事？

降低：降低某个风险对团队的危害程度 

例如，我们知道飞行总是有一定的风险，但是我们不能因为这种可能性而不出门。有些公司就有明确规定不能让三个或以上的副总裁搭乘同一个航班

制定应急计划 下半年的预算很可能会缩减，我们不能支持所有的开发和测试人员，但是团队的目标不会有大的变化。这时候我们要准备一两套预案。

王彦凯：

PM

product manager核心要求：根据市场和用户需求，协调各部门资源，正确的把握产品定位和方向，解决用户的痛点，持续优化产品。

project manager核心要求：正确的协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项。

program manager 微软的职位名称。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。

风险的类别和来源

风险的类别　　　　风险的来源

人员　　　　　　　客户，最终用户，利益关系人，项目成员，合作伙伴

流程　　　　　　　项目的预算，成本，需求

技术　　　　　　　开发和测试工具，平台，安全性，发布产品的技术，与我们产品相关的技术

环境　　　　　　　法律，法规，市场竞争环境，经济情况，基数大趋势，商业模式，自然界

风险管理的水平有多个层次

第一层次：啊呀，大问题

第二层次：缓和兵防止问题

第三层次：预计

第四层次：把问题变为机会

PM的能力要求和任务

1、观察、理解和快速学习能力

2、分析管理能力

　　重要而紧急的

　　重要而不紧急的

　　不重要而紧急的

　　不重要且不紧急的

3、一定的专业能力

4、自省的能力

李凯城：

所谓"需求分析"，是指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。可以说，在软件工程当中的"需求分析"就是确定要计算机"做什么"，要达到什么样的效果。可以说需求分析是做系统之前必做的。

需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。

需求分析有一下方法：获取和引导需求，分析和定义需求，验证需求，在软件产品的生命周期中管理需求。但是，针对需求的客户也是十分重要的。

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家"兼听则明"。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

 一个软件项目要在一段时间内完成诸多任务，光是满足用户的需求，就要做大量的用户需求分析，实现团队的目标，所以需要每个成员之间的配合和效率，大家各司其职，一起努力。

杨嘉豪：

第十三章的内容是关于各种测试方法和测试的设计方法。

一个软件开发团队统一思想首先要从基本名词解释开始，第一节为我们解释了一些基本名词并进行分类（例：Bug是指软件的缺陷，可以分解为症状（Symptom）、程序错误（Fault）、根本原因（Root Cause））；在对这些基本名词进行分类时，可以按测试设计的方法分类（分为黑箱和白箱），也可以按测试的目的（分为功能测试和非功能测试）或者测试的时机和作用分类。

在第二节中，详细介绍了各种测试方法——单元测试、代码覆盖率测试、构建验证测试、验收测试.....  

第三节介绍了实战中的测试，实战中的测试是在项目的稳定阶段执行的。这一节为我们纠正了几个似是而非的测试观念；在测试工作的过程中，要写很多的文档——计划阶段的测试计划（Test Plan）、测试设计说明书（TDS）、测试用例（Test Case）、程序错误报告（Bug Report）和测试报告（Test Report）。

第四节向我们介绍了该如何运用测试工具。利用测试工具，我们可以记录手工测试、记录自动测试，还可以进行效能测试、负载测试、压力测试。

第五节向我们说明了在软件开发的不同阶段我们该做的测试工作并介绍了测试工作中可能遇到的一些问题。

第五次小组报告