Last Update Date:2007.11.26
软件工程能否作为一门独立的学科实在是值得怀疑，其学科的理论(形式化技术还虚无缥缈)和实践成果都没有足够的成绩支撑。
软件工程无疑还是一门工程，同样具备标准工程实践的“三段论”，即分析、设计与实现(有的时候分的更细，但意义差不多)。由于软件的易修改性(建筑可不好推倒重来，软件起码看起来是容易些)，这是优点也是缺点(2个)，一是容易养成不好的分析和设计，二是更容易让人们产生超出正常的频繁更改的欲望，而这又常常超出其能力，最后满足不了这些欲望还同时背了不少黑锅)。对于一般工程实践而言，瀑布方法都是自然而然的选择（这时候，段=”活动”＝”阶段”），而对于软件尤其是商务软件则由于总总不明确因素和易修改性能力，迭代方法使用也很多(段=”活动”)，如RUP过程模型等。
软件工程的学说太多，反而掩盖了一些很简单、基本的本质要素。最根本的要素毫无疑问就是人，怎么提高个体生产力PSP、团队生产力TSP。但这里还是借用传统的表述，按软件工程的行话叫做软件工程三要素：方法、过程与工具，软件是对现实事物/事务的抽象，所以软件工程方法本质就是抽象，其产物就是模型，软件开发过程就是对这个模型是由粗到细、不断调整修正的过程，这个过程需要各种各样的工具支撑。
如同优秀建筑必然是通过好的项目管理来落实优秀的设计与工艺。软件工程是一种围绕产品生命周期的工程化方法，是软件产品的生产工艺。软件项目管理就是以通用的项目管理知识体系为基础，结合软件工程自身的科学规律(项目管理者在具体应用领域中的专业知识)，采用适合软件产品自身特点的管理方法。产品是目标，实现过程是手段。要做好软件项目的管理，就必须首先对软件工程具有深刻的理解。
软件开发用一句话总结：通用工程项目管理＋“双向可回溯的、可验证的建模与抽象”！
1，方法要素：模型与抽象：
在分析、设计与实现这些活动环节中，就本质而言和其它各类工程实践一样，即模型与抽象。各专家在此基础上各抒己见，在不同层面上推出各种所谓的五花八门的方法，参考二.2。如OO、AOP等不过是一些抽象手法，是为了更好的描述事物(一般应该多侧面描述)，而设计模式、框架等力图搞出分工(就像硬件行业有芯片级、板级、组装级的分工)。
模型和抽象在高一层面实际上是和应用域密切相关的，水平高的人不管在那个工程领域，模型和抽象能力都容易达到高水平，这需要一点悟性。反之依然。
=================================================================
发现“现实”问题－》抽象－》模型－》解决“现实”问题＝＝＝》下一轮
技术N人和一般高手的区别：
第一点是：不断抽象已知的东西。现实生活总是包括很多零散的东西，待解决的问题不会只有一面，所以抽取零散东西的共同属性，聚合不同角度的同一面向，成为从问题领域进入编程领域的第一步。抽象的层次越高，你架构设计就越简单。
第二点是：面对未知的东西用已有的抽象经验来模拟体验，从而不断调整直至达到可以控制未知东西的程度。有了上面第一点的基础，才可能到达这第二点的境界。现实问题总是不断变化着的推陈出新的，从未知到半知到已知，是人认识客观世界的一个过程，恰如人生从天真到懵懂到成熟的过程。
2，过程要素：双向可回溯性、可验证性
软件开发比其它工程相比特殊一些，要求开发过程更灵活。对于软件开发而言，其根本任务保证各开发环节中，保持对抽象模型的“双向可回溯性”。尤其是对于需求变更复杂的，双向要求尤其明显。
“可验证性”要素。现在流行的“测试驱动开发”－本质是可验证性的设计。主要方法是“模拟与仿真”分别对应不同层面。
3，工具要素：工具链、知识库
软件工具则是使上述要素更可操作而已，也是软件工程领域最有独立成果的部分，尤其是编码相关基础工具CVS/Coding...应该说已经发展的比较成熟。//很多非方法论角度的技术方法也都放在工具里面考虑。
另外几个有用的工具：
r CheckList：每个公司/各人开发必须具备的，每个环节都应该有CheckList，不论是有经验还是无经验，都能起到很好的作用。这就是积累。
r 日志：如果项目时间紧急，可能是唯一的方式，但要注意每过一个阶段最好整理一下。
r Best Practice：最佳实践是经过验证的一些做法。
阅读(1766) | 评论(0) | 转发(0) |
