软件工程基本原理的理解与感悟
一、软件工程基本原理
软件工程(Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
概括地说，软件工程是指导计算机软件开发和维护的工程学科。
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时问考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程.自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。
美国著名的软件工程专家 BOehm 综合这些专家的意见，并总结了TRW公司多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。
（一）用分阶段的生命周期计划严格管理
这一条是吸取前人的教训而提出来的。
统计表明，50%以上的失败项目是由于计划不周而造成的。
在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。
这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。
Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、
运行维护计划。
（二）坚持进行阶段评审
统计结果显示：大部分错误是在编码之前造成的，大约占63%;错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。
因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。
（三）实行严格的产品控制
开发人员最痛恨的事情之一就是改动需求。
但是实践告诉我们，需求的改动往往是不可避免的。
这就要求我们要采用科学的产品控制技术来顺应这种要求。
也就是要采用变动控制，又叫基准配置管理。
当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。
（四）采纳现代程序设计技术
从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。
采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。
（五）结果应能清楚地审查
软件是一种看不见、摸不着的逻辑产品。
软件开发小组的工作进展情况可见性差，难于评价和管理。
为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。
（六）开发小组的人员应少而精
开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。
这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通讯信道为
N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。
（七）承认不断改进软件工程实践的必要性
遵从上述六条基本原理，就能够较好地实现软件的工程化生产。
但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。
因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。
根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。
这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。
二、软件工程基本原理感悟
学习了这门课程, 还有老师们的多元化教课,不但使我们从理论上掌握软件工程,还有从不同的实例,让理论和实践得到了很好的结合,老师主要是从六个方面来描述软件工程,分别是信息和多媒体,JAVA编程技术,数据库系统,布线系统,管理信息系统,网络编程.有很多都是老师们多年的工作经验的总结,下面是我听课后自己的一点心得和自己对软件开发一点感想,我知道还
有好多的不懂,只有通过不断的学习才能一一解开.
软件工程课程虽已结束，但我对于软件工程的学习才刚刚开始。
我体会到项目管理的重要性，随着软件规模、复杂度的不断增加，项目开发中更多的是协作、管理和控制。
我学习到很多一般性的方法，例如：需求获取、模块化、计划等等。
同时，我也认识到使用计算机解决实际问题的复杂性，人们认识表达的过程不断反复、逐步深化，软件工程方法要提供给程序员们一种更加有效的对客观世界问题域进行形式化的过程方法。
首先需要完善订立计划的方式，最开始的，是之前提到的订立里程碑计划的方式，要尽可能地把每个里程碑的内容做好详细规划，将所有的系统，内容，细节都列举出来，同时需要考虑到流程的因素，哪些工作是其他工作的前续，需要优先完成，哪些工作只能等到资源到位才能开始，都需要考虑在内，为每个里程碑订立具体可行的计划。
分隔里程碑时，应该按照迭代开发的原则，先从基本的框架做起，使之能够正确的运行，然后再逐步细化。
每个里程碑都应该是一个可供运行的集合体，并且相较上一个，能够有较大的突破，从框架到最终形态，逐步实现。
在开发之前就预想好所有的状况难以实现，因此在开发中需要对计划进行不断的改进与完善，这些甚至包括一些对计划进行改变的部分，只有有更好的想法而且时机和条件允许，就应该对计划和目标进行修正。
这一步和迭代开发同时考虑，就可以很有
针对性，在框架的搭建阶段不断思索和探讨框架的改进办法，在内容填充阶段不断完善对细节对品质的雕琢。
不过对计划进行改进，修正还是需要有一定的限度，必须要考虑到对项目周期和预算的影响，尤其不要更改一些已完成很久的工作，连带关系与影响都很难预计。
计划基本确定后，就需要开始一些保证计划实施的工作了。
只要计划足够合理，就应该能够按部就班地进行下去，这一阶段，没有大问题的话，只需要不断跟进各部门的开发进度，定期召开全项目组及各部门间的会议，确认工作进度的进展，并且得到一些对计划的反馈，在任何时候跟进游戏内容，保证游戏品质和内容向着预定的目标前进。
即使计划照常进行，各部门间也应该保持周期性的交流，了解本部门，其他部门的开发进展，充分地了解整个项目的状况。
如果出现一些意外状况，如未考虑到的难题，突发的大型BUG，需要加入一些之前漏掉的内容等，就需要立即召开相关人员的会议，和仍然需要完成的剩余工作放在一起，重新进行计划的制订工作。
由于各种不确定性的因素，所以在订立计划时，还需要预留一些应对风险的时间，过分压制开发时间，导致不得不延期对士气和项目的伤害都会很大。
在过程中，应该多听取一些团队成员的意见，而且我自认为很重要的一点，是不应该保密，有任何困难和需求都应该直说，
对常接触的团队成员来说，很多事情很难瞒住，不仅没有作用，而且会加深他们对项目的不信任感，有所保留能够换取的也只是别人的有所保留。
事实上，不同项目组的管理方式肯定不会完全相同，都会有一些符合自身特点的管理流程，以上的不过是我自己理想中的一套流程，并不可能适合大部分的情况。
但是，有一点我认为是不会有问题的：无论采用什么样的项目管理方式，确保团队成员明白这些管理方式每一个步骤的实施方法与原因是十分必要的，如果只是需求每天的日报而不去说明日报对开发进度把控的重要性，很可能能够得到的也就是一堆流水账似的表单罢了。
我认为的项目管理，不是一两个人的事，而是一个团队努力的结果，这点在漫长的开发过程中，尤为重要。
软件工程课程虽已结束，但我对于软件工程的学习才刚刚开始。
我体会到项目管理的重要性，随着软件规模、复杂度的不断增加，项目开发中更多的是协作、管理和控制。
我学习到很多一般性的方法，例如：需求获取、模块化、计划等等。
同时，我也认识到使用计算机解决实际问题的复杂性，人们认识表达的过程不断反复、逐步深化，软件工程方法要提供给程序员们一种更加有效的对客观世界问题域进行形式化的过程方法。
首先需要完善订立计划的方式，最开始的，是之前提到的订立里程碑计划的方式，要尽可能地把每个里程碑的内容做好详细规划，将所有的系统，内容，细节都列举出来，同时需要考虑到流程的因素，哪些
工作是其他工作的前续，需要优先完成，哪些工作只能等到资源到位才能开始，都需要考虑在内，为每个里程碑订立具体可行的计划。