现代软件工程 第七章 【MSF】练习与讨论

我个人认为项目开发过程中有两件不同类型的事：

（1）事先预计到的要做的事。这就是任务，把要做的事情组合起来实现用户某一个特定的需求，这就是场景，也可以用任务来表达。

（2）事先没有预计到，但是为了项目成功而不得不做的事。这就是缺陷。

软件开发的过程就是做完这些“计划要做的事”和“没计划，但是不得不做的事”，做好就行了。等你们做了三五个项目，写了一万行以上的程序，再来看场景、风险、服务质量需求也不迟。

同学：您说得在理，但是老师让我们用全套敏捷模式，我们怎么办？

阿超：你们可以回去告诉老师说这是最新的“移山精简开发模式”，填补了国内外空白，很好用。

把同学们打发走了以后，阿超转念一想，为什么不呢？“移山精简开发模式”，说不定对小型团队来说是一个很好的模式。

举例说明：例如我们要设计一个网上拍卖的网站，商业用户（简称商户）可以开商店，卖东西；一般的用户可以浏览，购物。

商户可以用我们的系统进行登录。这是场景，也可以叫任务，我们要以此为基础，驱动开发和测试工作：

我们计划要在网络用户界面实现商户登录管理，这是任务。

我们计划要在中间逻辑层实现商户登录管理，这是任务。

我们计划要在数据层实现商户登录管理，这是任务。

我们计划要测试商户登录，这是任务。

我们计划要系统能支持100个以上的商户同时访问，这是任务，同时也是“服务质量需求”。

在某些情况下，商户登录失败，这是缺陷。我们事先没有预计到会出这样的问题。

在标准配置情况下，20个以上的商户同时登录时，系统的响应时间很慢，这是缺陷。我们事先没有预计到会出现这样的问题。

系统在上传某种图像文件时出错，这是缺陷。

对于一个不太复杂的系统来说，每次里程碑（迭代）中要实现的场景应该两个手掰指头能数得过来。而且场景是相对稳定的，不会突然间有大的变化。对于一线的开发和测试人员来说，每天打交道更多的是任务和缺陷。过多的类型会增加管理和交流的成本，一个开发者每天很简单地浏览“我的任务”和“我的缺陷”这两个检索，就能知道今天该做什么。同时开发和测试的交流也主要通过“缺陷”这一类型来完成。管理人员在跟踪进度、报告进度的时候也很简明。在这种情况下，“场景”只是起到一个综合与归类的作用，使管理人员和客户知道哪些功能能够使用了，哪些还差得远。因此，“场景”可以等同于“任务”。因为这是我们预计到要做的事情。

如果加上“服务质量需求”，那么团队中每个人需要接触的工作项类型就有4种，如果测试人员发现“服务质量需求”的某些部分不符合要求，需要重新激活“服务质量需求”，并创建一个新的“缺陷”，并且通报所有相关人员，对于一个小规模、人员相当集中的团队，真的有这个必要么？

对于一个新建的团队，保持一个精简的过程和管理方法是很重要的。只要任务、缺陷这两个类型足以解决问题，就不必考虑更多的工作项类型，而是集中精力把项目开发好。

---

 

 

在软件工程发展的过程中，各个专家在不同时期总结了软件工程的原则，下面是1983 年Barry Boehm在总结了多个项目（各个项目总共耗时约175000人月，主要是国防、航空、航天相关）之后提出的软件工程原则[i]，请把它和MSF、Agile的原则相比，看看有什么异同?