软件工程实施体会.doc

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