如何高效快速的项目开发

原本这篇文章是对真两年项目经验的总结，始终把他当做宝贝，还把他加了密，考虑到现如今是一个人人为我，我为人人的社会，特此奉献，整体内容还未完善，后续内容还需完善，望大家指正。。。

高效快速的项目开发
撰稿人 ：刘树勇

指导老师：耿欣

地 址：济南大学自动控制学院电气控制实验室

电 话：13811996993

QQ ：284143781

邮箱 ：shuyong1999@163.com

时 间 ：2011-4-29

修改历史记录

序号	版本号	内容	编制\日期	状态
1	V1	创建	刘树勇\2011-1-4	待发布

目录
声明.... - 1 -

序.... - 1 -

第一部分 粮草篇.... - 1 -

1. 如何打赢这场战争.... - 1 -

2. 工欲善其事，必先利其器.... - 1 -

2.1. 软件需求工具... - 1 -

2.2. 产品原型设计（Product Prototype Design）... - 1 -

2.3. 软件设计工具... - 1 -

2.4. 软件构造工具... - 1 -

2.5. 软件管理工具... - 1 -

2.6. 软件测试工具... - 1 -

2.7. 软件维护工具... - 2 -

2.8. 软件配置管理工具... - 2 -

2.9. 软件工程管理工具... - 2 -

2.10. 软件工程过程工具... - 2 -

2.11. 软件质量工具... - 2 -

3. 软件开发.... - 3 -

3.1. 软件开发步骤... - 3 -

3.2. 软件开发模式... - 3 -

3.3. 软件开发辅助... - 3 -

3.4. 软件设计论证... - 3 -

3.5. 软件开发工具... - 3 -

4. 应用软件人才体系图.... - 4 -

5. 什么是问题.... - 4 -

6. 需求文档与设计文档.... - 4 -

7. BUG的定义.... - 4 -

7.1. BUG的来源... - 4 -

7.2. 通俗BUG的分类(问题) - 5 -

7.3. 程序员之bug.. - 5 -

8. 什么是计划.... - 5 -

9. 标准化.... - 5 -

10. 开发团队之众生相.... - 5 -

11. 做到“人在，刀在；人亡，刀还在”.... - 5 -

12. 软件开发中的蝴蝶效应.... - 6 -

13. 兄弟，你不是一个人在战斗.... - 6 -

14. 狗日的，美国佬总把他们家航母开到我们家门口玩玩.... - 6 -

15. 四大文明古国，只有中国还存在。.... - 6 -

16. 夫战，勇气也.... - 6 -

17. 美国的国会议会制.... - 6 -

18. 沟通？扯蛋？.... - 6 -

19. 4X100接力赛.... - 6 -

20. 让傻子也可以为你玩命.... - 7 -

21. 大将保明主，俊鸟登高枝.... - 7 -

22. 大学之大.... - 7 -

23. 秦朝的货币统一.... - 7 -

24. 蝴蝶效应.... - 7 -

25. 山寨之罪.... - 7 -

26. 有问题不抱怨，可耻；没有问题乱抱怨，可悲.... - 7 -

27. 为什么学历史.... - 7 -

28. 麻雀虽小，却五脏俱全.... - 8 -

29. 管理一个软件团队，就像放牧一群骄傲的猫（Marbara Moo）.... - 8 -

30. 作战方针是非常重要的形式地图（UML）.... - 8 -

31. 科技的先驱掌握话语权.... - 8 -

32. 优点很重要，缺点更重要.... - 8 -

33. 系统的架构决定了系统是否牢固及开发进度.... - 8 -

34. 日本海军的战败，不是日本海军准备不精良，而是装备太精良了，不知道用什么好，败了。 - 9 -

35. 设计缺陷与BUG.. - 9 -

36. Bug不是编出来的，Bug是改出来的.... - 9 -

37. 不要把所有的人变成瞎子.... - 9 -

38. 保皇派、维新派、革命派.... - 9 -

39. 模块设计要看三步，迈一步.... - 9 -

40. 每一条壕沟里，都要标注作战指挥图.... - 9 -

41. 使用合适的工具，做合适的事情.... - 9 -

42. 战场上禁止踢皮球.... - 10 -

43. 男人、女人和红娘.... - 10 -

44. 现有系统框架.... - 11 -

45. 作坊与产业.... - 11 -

46. bug的出现概率.... - 11 -

47. 标准的制定，更有利于项目的开发.... - 11 -

48. 望文生义.... - 12 -

49. 不打没有用的消息.... - 12 -

50. 禁止一厢情愿.... - 12 -

51. 各司其职.... - 12 -

52. 编程高手与编程老手.... - 13 -

53. 詹天佑在今天还是英雄吗？.... - 13 -

54. 各流编程人员.... - 13 -

55. 韩国PK朝鲜.... - 13 -

56. 特种部队与未来战争.... - 13 -

57. 软件架构师与Team Leader.. - 13 -

58. 能上天却不能入地.... - 13 -

59. 权利职能的越位.... - 13 -

60. 由专业的人，审查设计专业的模块.... - 14 -

61. 应答机制.... - 14 -

62. 不要做花心男人，处处留情.... - 14 -

63. 工作经验的作用.... - 14 -

64. 学会定位问题.... - 14 -

65. 软件开发模型.... - 14 -

65.1. 边做边改模型（Build-and-Fix Model）... - 14 -

65.2. 瀑布模型（Waterfall Model）... - 15 -

65.3. 快速原型模型（Rapid Prototype Model）... - 16 -

65.4. 增量模型（Incremental Model）... - 16 -

65.5. 螺旋模型（Spiral Model）... - 17 -

65.6. 喷泉模型（fountain model）... - 18 -

65.7. 敏捷开发模型... - 18 -

65.8. XP极限开发模型... - 18 -

第二部分 策略篇.... - 18 -

66. 兵贵神速.... - 18 -

67. 动车组为什么快.... - 18 -

第三部分 战斗.... - 18 -

第四部分 庆功.... - 18 -

第五部分 总结.... - 18 -

第六部分 反思篇.... - 19 -

第六部分 总结.... - 19 -

声明

本故事纯属虚构，切勿对号入座。如有雷同，实属巧合。

本文档是本人在毕业四周年之际，取天地之精华，酝酿而成，最终注释权归本人所有。

济南大学自动控制学院电气控制实验室是本文档思想的发源地，本人导师：耿欣先生拥有此文档的所有版权。侵权违法，翻版必究。

序

第一部分 粮草篇

1. 如何打赢这场战争

作战计划。

2. 工欲善其事，必先利其器

2.1. 软件需求工具

包括需求建模工具和需求追踪工具

Xmind，Demo-builder，

2.2. 产品原型设计（Product Prototype Design）

Axure / GUI Design Studio

2.3. 软件设计工具

用于创建和检查软件设计，因为软件设计方法的多样性，这类工具的种类很多。

2.4. 软件构造工具

2.5. 软件管理工具

SOS

SVN

GIT

2.6. 软件测试工具

包括测试生成器、测试执行框架、测试评价工具、测试管理工具和性能分析工具

2.7. 软件维护工具

包括理解工具（如可视化工具）和再造工具（如重构工具）。

2.8. 软件配置管理工具

包括追踪工具、版本管理工具和发布工具。

2.9. 软件工程管理工具

包括项目计划与追踪工具、风险管理工具和度量工具。

2.10. 软件工程过程工具

包括建模工具、管理工具和软件开发环境。

2.11. 软件质量工具

包括检查工具和分析工具。

软件开发服务器的搭建：便于代码的集中管理。

测试服务器的搭建：1.便于解决测试板不足。2.减少测试环境的反反复复的搭建，节约项目的开发时间。

软件设计建模语言：UML

思维导图软件：Xmind

实体关系图(ER图)

硬件设计建模语言or工具：UML（非专业硬件设计人员和专业硬件设计人员）；altium designer-层次原理图设计（专业硬件设计人员）。

对于非专业人员，对于

3. 软件开发

3.1. 软件开发步骤

需求分析，软件架构，软件设计，软件编程，软件测试，软件部署。

3.2. 软件开发模式

敏捷开发，cleanroom，迭代式开发，RAD，统一过程，螺旋模型，瀑布模型，极限编程，SCRUM。

3.3. 软件开发辅助

配置管理，文档管理，质量管理，项目管理，使用者经验设计。

3.4. 软件设计论证

对于整个项目的设计及论证，必须采用三人表决的方式进行，禁止出现项目中一人独大的现象。一个优秀的帝王是国家之福。但这样的帝王一般比较稀少，千年一遇。所以必须采用西方国家的议会制，制衡最高领导人的私欲，这样可以避免项目走入极端，导致最终的失败。

3.5. 软件开发工具

编译器，出错器，性能分析，GUI设计，集成开发环境。

4. 应用软件人才体系图

5. 什么是问题

地震引发了福岛核设施泄露是问题？还是福岛核设施已经老化是问题。

6. 需求文档与设计文档

在项目中，需求文档看着想设计文档；设计文档看着像需求文档。在项目中存在了大量的文档，文档间的内容相互耦合，相互冗余。

7. BUG的定义

7.1. BUG的来源

原来，第一代的计算机是由许多庞大且昂贵的真空管组成，并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热，引得一只小虫子Bug　钻进了一支真空管内，导致整个计算机无法工作。研究人员费了半天时间，总算发现原因所在，把这只小虫子从真空管中取出后，计算机又恢复正常。后来，Bug这个名词就沿用下来，表示电脑系统或程序中隐藏的错误、缺陷或问题。

与Bug相对应，人们将发现Bug并加以纠正的过程叫做“Debug”，意即“捉虫子”或“杀虫子”。遗憾的是，在中文里面，至今仍没有与“Bug”准确对应的词汇，于是只能直接引用“Bug”一词。虽然也有人使用“臭虫”一词替代“Bug”，但容易产生歧义，所以推广不开。

7.2. 通俗BUG的分类(问题)

l 前期设计不足

l 意料之外的事情

l 架构调整

l 需求不清（做而不对）

7.3. 程序员之bug

程序员所定义的bug-意料之外的事情，即异常。其他问题都不应为bug。

8. 什么是计划

如果所有的实施步骤都没按计划办事，这个计划的意义还有多大？

9. 标准化

公司标准化

项目组标准化。槽号，标准规定用1个字节表示。实际后台

10. 开发团队之众生相

在这个社会上无非存在三种人：想有所建树的人、整天混日子的人、制造麻烦的人。这三种人在不同的时期，会相互依存，也会相互转换。这三种人，同样存在于项目开发团队中。当第一种人占上风时，整个团队会良好的运作。当第二种人占上风时，整个团队会非常的消极和低迷，如果不能很快的改变局面，将会很快拖垮整个团队也会影响整个公司的运作。第三种人（制造麻烦的人）在整个团队中起到鲶鱼效应的人。当这种人占据上风时，整个公司就会出现相互扯皮的

11. 做到“人在，刀在；人亡，刀还在”

这个信条的原因是防备；人在的时候，这个人的代码是宝贝。这个人走了，这个人写的代码却成了一堆垃圾。

12. 软件开发中的蝴蝶效应

13. 兄弟，你不是一个人在战斗

做事情的时候，不要只想着自己。现在已经不是改革开发的那个年代，出了不少的暴发户。

14. 狗日的，美国佬总把他们家航母开到我们家门口玩玩

建模的重要性。主要包括：系统的软件设计及新技术的探讨及应用。

环境尽可能的相同。有的段是165段，有的段是1端

15. 四大文明古国，只有中国还存在。

历史传承的重要性

16. 夫战，勇气也

先秦•左丘明《左传•庄公十年》：“夫战，勇气也。一鼓作气，再而衰，三而竭。

17. 美国的国会议会制

美国的国会议会制应该引入到项目开发中。

18. 沟通？扯蛋？

19. 4X100接力赛

20. 让傻子也可以为你玩命

21. 大将保明主，俊鸟登高枝

22. 大学之大

大公司之大

23. 秦朝的货币统一

公司标准化的确定。

24. 蝴蝶效应

25. 山寨之罪

我们采用了XXXXX模式，可以提高XXX%的效率，实际上效率并没有提高，还降低了，却蒙蔽了一些人（哪些人？有待思考）。中国人最大的能力就是山寨，唐骏的成功可以复制，他的思想、阅历是任何人带不走的。

26. 有问题不抱怨，可耻；没有问题乱抱怨，可悲

27. 为什么学历史

让历史的悲剧不再重演。

28. 麻雀虽小，却五脏俱全

29. 管理一个软件团队，就像放牧一群骄傲的猫（Marbara Moo）

Barbara Moo:

现任AT&T网络体系结构部门负责人。在1983年加入贝尔实验室不久，她开始从事Fortran 77编译器的研究工作，这是第一个用C++编写的商业产品。她负责AT&T的C++编译器项目直到AT&T转让出软件开发业务。她还负责指导SIGS会议、Lund技术学院和Stanford大学。

Andrew Koenig和Barbara Moo堪称C++研究领域的“第一神仙眷侣”，他们不光有着多年的C++开发、研究和教学经验，而且还亲身参与了C++的演化和变革，是对C++的变化和发展起到重要影响的人。他们两人还曾经合著了Accelerated C++: Practical Programming by Example。

30. 作战方针是非常重要的形式地图（UML）

31. 科技的先驱掌握话语权

C++ + C的开发模式

C++作为一种粘合剂，C作为功能的快速实现。

32. 优点很重要，缺点更重要

Git的特点用一句话概括：分布式。SVN的特点用一句话概括：集中式。这两种策略即是优点也是缺点。在现有项目中Git因为太分布了，导致了每个人版本的不同步。

33. 系统的架构决定了系统是否牢固及开发进度

不要向中国的建筑队学习，不要总是建了拆，拆了再建。

34. 日本海军的战败，不是日本海军准备不精良，而是装备太精良了，不知道用什么好，败了。

35. 设计缺陷与BUG

Bug一词的来源。

36. Bug不是编出来的，Bug是改出来的

战线不要拉的太长，战线太长bug越多

37. 不要把所有的人变成瞎子

瞎子做的工作就是，简单的重复劳动，如果开发小组的成员变成了瞎子，就应该为瞎子准备所必须的所有物资。

38. 保皇派、维新派、革命派

39. 模块设计要看三步，迈一步

将模块的使用环境，及相邻模块的设计及实现纳入本模块的设计中，可将本模块设计的更加人性化和实用性。如云控制协议，在编码端的解析，就是有点别扭。

40. 每一条壕沟里，都要标注作战指挥图

程序文件描述，及功能介绍

41. 使用合适的工具，做合适的事情

使用C++做框架，使用C做算法。

42. 战场上禁止踢皮球

兔崽子，不要命了，敢在战场上踢皮球。出现踢皮球的现象是责任的不明确造成的，每个人都难得糊涂。

43. 男人、女人和红娘

编程的理念。任何的东西都不能做到十全十美，包括软件中的模块，所以在软件的开发中，不能闷着头子做事，不能把所有的事情往底层压（就像于先原（同事）说的），只有将模块的功能进行划分清楚，才能做好项目的开发。这个问题就像三峡大坝放水水一样，你必须知道下游河道能承受多少水，大坝才能放多少水，不能大坝一放水就撒手不管了。这样轻则溢坝，重则溃坝。比如在系统cgi_log_get()（CGI模块）中，就是相当于大坝，transmit_log_get(),就当于河道，对于相关buff放在cgi_log_get()中处理，而不能简单的认为cgi_log_get()要调用transmit_log_get()，transmit_log_get()就必须要对buff进行相关的限制。总体来讲还是要做好模块的功能设计。就如总文章开头所说的：兄弟，你不是一个人在战斗！

44. 现有系统框架

系统为分布架构，没有主控模块

45. 作坊与产业

作坊呢，使我们首先想到的是手工业者，手工业者做事情都是以自己为中心，自己想干就干，不相干就歇着，产品有买的才能卖掉，没有买的则没有价值的体现。

当事情发展到产业的时候，我们会想起两个词：产业链，产业结构。他的主要特点是以市场为导向，别人的需求是我发财的捷径。

手工作坊生产出来的东西，好多都不能满足市场的要求。代码也一样。

46. bug的出现概率

按传统的开发方式，bug的出现概率必定是由下向上，出现频率高发。基石决定了上层建筑。如何快速的进行项目开发，必须平衡基石与上层建筑的关系。

47. 标准的制定，更有利于项目的开发

合作不只是团队内的相互合作，团队间的合作更重要。比如PID有的团队使用十进制，有的团队使用十六进制，有的团队使用8进制。

48. 望文生义

模块定义混乱，郑立博，所有的控制软件都叫一个名字。马斌所有的东西都叫移植库。终端组：云插件，云控制，都叫云XXX

49. 不打没有用的消息

消息既然打印出来，那就必须有用，不然你耗费CPU的资源干什么呢？玩吗？打印的消息要包括：是谁打的，消息的等级（TRACE_LEVEL? DEBUG_LEVEL? INFO_LEVEL? WARNING_LEVEL？ERROR_LEVEL）在哪个文件， 在哪个函数，在第几行。还要考虑在项目发布的不同阶段，根据调试的等级，自动去掉等级低的调试信息，不然白白耗费CPU资源干什么呢？在项目中，禁止直接使用太标准的打印函数：比如perror()；在项目中，出现的问题：在开始的程序测试中没有出现问题，但在后期的程序中出现了问题，所有一开始没有怀疑是后台程序的问题。在CGI中将错误消息，推向了了浏览器，因为信息内容太过标准，在抓包中发现了此错误信息，但无法定位错误消息是由浏览器打出来的，还是webserver打出来的，还是后台打出来的。

在软件调试阶段，集成阶段。错误消息必须打。要不出现问题，光超找问题。就要花费很长的时间。

调试信息的第一要素：让傻子也能看的懂。如果出了自己，没人能看的懂，就不要在公共版本里出新。

必须明确软件发布对软件不同操作及合理使用assert();

Log的功能就是定位问题，当卫星（产品）已经上天（市场），我们的系统还在不同的打印Log还有用吗？

合理的Log原型：

Log(Module, Author, Level, LogFromat, 参数…)

50. 禁止一厢情愿

51. 各司其职

接力赛，每个人跑完规定的距离。否则就是犯规。

52. 编程高手与编程老手

53. 詹天佑在今天还是英雄吗？

项目中的拖拉推拽

54. 各流编程人员

从单片机发展而来的，从PC机发展而来的。

55. 韩国PK朝鲜

外围环境决定了项目的成功

56. 特种部队与未来战争

“海豹”突击队把本拉登打死了。

57. 软件架构师与Team Leader

软件架构师不一定是TeamLeader，Team Leader也不一定是软件架构师。但如果想要项目高效快速的进行，必须两者

58. 能上天却不能入地

底层的人的本领更大。

59. 权利职能的越位

项目经理，研发经理，产品经理的职能。

60. 由专业的人，审查设计专业的模块

61. 应答机制

接受任务-》完成任务-》返回应答

62. 不要做花心男人，处处留情

在项目的设计中，不要把系统的逻辑关系，放在系统的每个层面上。

63. 工作经验的作用

对项目和新的工作，能够作出正确的评估。

64. 学会定位问题

不要指望GDB能解决一切问题，GDB应作为最后的杀手锏。我的观点是杀鸡焉用宰牛刀。合理打的使用调试信息，更能提高项目的开发速度。

现在操作，光看都后台花花的打印错误消息。就不知道是谁打的….无语！没办法，几把这些消息发给可能的人吧。有时候发对了也行。就怕错误的消息，发给了错误的人。

65. 软件开发模型

65.1. 边做边改模型（Build-and-Fix Model）

遗憾的是，许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.



边做边改型

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2） 忽略需求环节，给软件开发带来很大的风险；

（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

65.2. 瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。



瀑布模型

瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。

65.3. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。


快速原型
通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

65.4. 增量模型（Incremental Model）

又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.


增量模型
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：

（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。

65.5. 螺旋模型（Spiral Model）

1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。


螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3） 实施工程：实施软件开发和验证；

（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。

（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。

（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

65.6. 喷泉模型（fountain model）

(也称面向对象的生存期模型, OO模型)


喷泉模型
喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

65.7. 敏捷开发模型

65.8. XP极限开发模型

第二部分 策略篇

66. 兵贵神速

单兵神速，如蜉蚁撼树

67. 动车组为什么快

68 .让我们学会做梦吧，那么我们就可以发现真理

一天晚上，凯库勒坐马车回家，在车上昏昏欲睡。在半梦半醒之间，他看到原子链似乎活了起来，变成了一条蛇，在他眼前不断翻腾，突然咬住了自己的尾巴，形成了一个环……凯库勒猛然惊醒，受到梦的启发，明白了苯分子原来是一个六角形环状结构。

如果项目中遇到了问题，久攻不克。那么停下来，休息一下也是一个好办法。

69.嵌入式中内存申请还是很重要的

貌似在PC上有Swap分区，使用new or malloc的时候操作系统会比返回一个可用的内存。可在嵌入式系统上那可不一定了。

第三部分 战斗

第四部分 庆功

第五部分 总结

我们的工作总是在挤牙膏，我们工作总是在打扫垃圾，每一次来回都有新的垃圾出现，我们都是驾驶F22的优秀飞行员，却把F22当成了教练机在使用。

编程很难吗？我看了很多种的编程语言，不是if就是else。编程的真正难点在于整个项目中会有成千上万个if+else，并且要这些if else在正确的时间，出现在正确的地方。

合理的规章制度及有效的团队运行机制，要比多几个牛人产生的效率会更高。有公司高呼：我们不招牛人，我们只要踏踏实实干活的人。

我们用了10%的时间在处理每个人的不同开发环境。我们用了10%的时间在不停的拆建测试环境，我们用了20%的时间在测试别人bug，我们用了10%的时间在相互的扯皮。

3天的集成测试，两天半了，我们的系统还没跑起来。我们必须要想想了。

工作主次不分，只凭兴趣做事。

现在我们应该招做项目的人，而不是只是编写带代码的人。两者的区别在于是否有全局观。

Bug的修正是否能迅速的跟得上。

第六部分 反思篇

第六部分 总结

《C++大学教程》

《大话设计模式》

《大规模C++程序设计》