软件工程实施体会.doc

软件工程实施体会 ——本学期对软件工程实验使我学会的 软件工程项目是需要团体作业才能够完成的。团体作业就需要交流，有交流，就必然会有合作；有合作，就需要有分工；有分工，就需要有协调；有所有这些，就需要有管理。然而一个人的项目是否不需要管理？当然不是，因为有文档，有代码，有灵感，有经验，等等都需要管理。只是此刻的管理是自己完成的，可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验，也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论，在开发过程中的作用，就是指导如何做好管理，以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标，就可以抛开一些对自己不适用的枝节。 那么我们如何实现它呢？ 我认为软件工程中最重要的，最有实际意义的，是它界定了工作职能，从而也确定了责任归属。什么意思？说白了，就是什么人做什么事，出了问题谁负责。那么它是怎么界定工作职能的？是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段，每一个阶段都有相关的人员来实现，也就有相关的人员来负责。分工不清，责权不明，是导致管理混乱的最主要的因素。所以即使是两个人的项目，也是需要软件工程来指导的，因为通过它，可以更好的知道如何可以合理分工，划分工作职权以取得最终的成果。当然，走教条主义的道路是非常愚蠢的。 软件工程是针对“软件危机”提出来的。它是一种工程，把经验和理论应用到实践中来，解决软件开发中出现的各种问题。这是什么意思？就是说，软件工程是用来解决实际问题的。如果软件开发中没有遇到管理问题，软件工程就不需要管理的内容；如果软件开发中没有遭遇文档混乱，软件工程就不需要文档的部分。但是如果很幸运的遭遇到了这些，那么这一切都是不可或缺的。软件工程不是一个固定的呆板的框框，而是一个有弹性的概念。 所以，如果不是要去申请iso或是cmm认证，完全不必要一板一眼的按照iso或是cmm的规范去做。所谓“有企业特色的软件工程”，完全可以从吸收现有的模式和规范中完善起来。但这并不是说所有在开发过程中出现的都是软件工程，只有那些能引导开发走向成功的才是真正有意义的软件工程。其他的，最多只是失败的尝试。 软件工程实施的时机； 首先要知道软件工程，理解软件工程；然后要了解现有的软件工程的模式和规范。ISO、CMM或是Agility，都定义了一套规范。这些规范是经验与技术，以及理论的积累。它们存在很多合理的、可行的模式，可以引用和参考；但银弹是没有的。当然，我们可以重头再来，造他们造过的轮子，摔他们摔过的跤；但很明显，这是不必要的。 实施的最好方法，也是最可行的方法，成本最小的方法，是根据开发的客观的因素，修改那些规范，以符合我们的开发过程；但是最主要的，是修改我们的主观认识，以符合那些规范；而最重要的，是在实施中发现那些规范不合理的地方，并改正它。 我们担心过小的项目应用软件工程是否会陷入官僚主义，从而加重项目的负担？我们再来看什么是软件工程？软件工程并没有定义什么才是软件工程！也没有定义软件工程自身的规模。软件工程的意义在于对开发阶段的划分，以及分工和责任归属。这与项目的规模没有什么冲突。相反，越是小的项目越是需要软件工程的管理。 软件开发的一个共识，是把一个大的项目划分成一些小的模块，再把小的模块划分成更小的模块。如果这些小模块是独立的（或者原来就是一个独立的项目），那么软件工程至少可以提高它的重用性。对于一个软件工程观念不深的团队，不要期望他们在接手大的项目的时候可以使用软件工程，如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。 软件工程对工作量有什么影响？针对那些在不使用软件工程管理的项目中很轻松的人而言的。软件工程会使他们要么失业，要么负起责任来。相对工程师而言，他们会从混乱的毫无头绪的状态中解放出来，他们的工作会变得有效率。损失的是以前尸位素餐的人将暴露出来——这可能是它的唯一的缺陷，同时也是它受到很多企业/个人抵制的可能原因之一。