软件项目综合实践心得体会
这个学期的软件项目综合实践马上就要结束了，作为我们小组开发组的一员，通过一个学期系统的学习实践后我体会到了许多在基础课程中认识不到的经验和心得。
首先，软件工程项目是需要团体作业才能够完成的。团体作业就需要交流，有交流，就必然会有合作；有合作，就需要有分工；有分工，就需要有协调；有所有这些，就需要有管理。然而一个人的项目是否不需要管理？当然不是，因为有文档，有代码，有灵感，有经验，等等都需要管理。只是此刻的管理是自己完成的，可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验，也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论，在开发过程中的作用，就是指导如何做好管理，以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标，就可以抛开一些对自己不适用的枝节。
我认为软件工程中最重要的，最有实际意义的，是它界定了工作职能，从而也确定了责任归属。什么意思？说白了，就是什么人做什么事，出了问题谁负责。那么它是怎么界定工作职能的？是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段，每一个阶段都有相关的人员来实现，也就有相关的人员来负责。分工不清，责权不明，是导致管理混乱的最主要的因素。所以即使是两个人的项目，也是需要软件工程来指导的，因为通过它，可以更好的知道如何可以合理分工，划分工作职权以取得最终的成果。当然，走教条主义的道路是非常愚蠢的。
软件开发的一个共识，是把一个大的项目划分成一些小的模块，再把小的模块划分成更小的模块。如果这些小模块是独立的（或者原来就是一个独立的项目），那么软件工程至少可以提高它的重用性。对于一个软件工程观念不深的团队，不要期望他们在接手大的项目的时候可以使用软件工程，如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。
其次，通过这学期的实践，我才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不
会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱。
以前在做实验提交文档的时候，总是有一种为了写文档而写文档，是被动的完成工作的感觉。但现在我认识到，维护良好的文档对于保证软件质量是必不可少的。对软件文档的深入接触，让我认识到文档本身就是软件产品，没有文档的软件，不能称其为软件，更谈不上为软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要意义。
文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间起着桥梁作用。软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。
我们初级编程人员总是或多或少的存在对软件文档不够重视的现象，总是把工作重心放在代码编程上。结果编出的代码总是不能尽如人意，因此，在今后的工作与学习之中，我们应该给予软件文档的编制应有的重视，这样才能让开发出来的软件系统更符合客户要求，更少漏洞，更加完善，臻于完美，这也是我们软件开发人员所孜孜以求的。
最后，经过这学期软件工程实验的学习，深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，
这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
还有就是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是
如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。
总而言之，经过一学期的软工实验，深刻感到其重要性的同时也学到了不少的东西 ，将对我在今后的软件开发过程中起极大的作用。
软件项目综合实践心得体会
这个学期的软件项目综合实践马上就要结束了，作为我们小组开发组的一员，通过一个学期系统的学习实践后我体会到了许多在基础课程中认识不到的经验和心得。
首先，软件工程项目是需要团体作业才能够完成的。团体作业就需要交流，有交流，就必然会有合作；有合作，就需要有分工；有分工，就需要有协调；有所有这些，就需要有管理。然而一个人的项目是否不需要管理？当然不是，因为有文档，有代码，有灵感，有经验，等等都需要管理。只是此刻的管理是自己完成的，可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验，也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论，在开发过程中的作用，就是指导如何做好管理，以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标，就可以抛开一些对自己不适用的枝节。
我认为软件工程中最重要的，最有实际意义的，是它界定了工作职能，从而也确定了责任归属。什么意思？说白了，就是什么人做什么事，出了问题谁负责。那么它是怎么界定工作职能的？是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段，每一个阶段都有相关的人员来实现，也就有相关的人员来负责。分工不清，责权不明，是导致管理混乱的最主要的因素。所以即使是两个人的项目，也是需要软件工程来指导的，因为通过它，可以更好的知道如何可以合理分工，划分工作职权以取得最终的成果。当然，走教条主义的道路是非常愚蠢的。
软件开发的一个共识，是把一个大的项目划分成一些小的模块，再把小的模块划分成更小的模块。如果这些小模块是独立的（或者原来就是一个独立的项目），那么软件工程至少可以提高它的重用性。对于一个软件工程观念不深的团队，不要期望他们在接手大的项目的时候可以使用软件工程，如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。
其次，通过这学期的实践，我才真的体会到，良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的，在设计文档的指导下，才能写出安全的代码。如果你不写文档，一开始就写程序，这样你就不
会按已设计好的路线走，而是想到哪写到哪。小功能还好说，要是大功能，就容易混乱。
以前在做实验提交文档的时候，总是有一种为了写文档而写文档，是被动的完成工作的感觉。但现在我认识到，维护良好的文档对于保证软件质量是必不可少的。对软件文档的深入接触，让我认识到文档本身就是软件产品，没有文档的软件，不能称其为软件，更谈不上为软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要意义。
文档在软件开发人员、软件管理人员、维护人员、用户以及计算机之间起着桥梁作用。软件开发人员在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据，这个作用是显而易见的。软件开发过程中软件开发人员需制定一些工作计划或工作报告，这些计划和报告都要提供给管理人员，并得到必要的支持。管理人员则可通过这些文档了解软件开发项目安排、进度、资源使用和成果等。软件开发人员需为用户了解软件的使用、操作和维护提供详细的资料，我们称此为用户文档。以上三种文档构成了软件文档的主要部分。
我们初级编程人员总是或多或少的存在对软件文档不够重视的现象，总是把工作重心放在代码编程上。结果编出的代码总是不能尽如人意，因此，在今后的工作与学习之中，我们应该给予软件文档的编制应有的重视，这样才能让开发出来的软件系统更符合客户要求，更少漏洞，更加完善，臻于完美，这也是我们软件开发人员所孜孜以求的。
最后，经过这学期软件工程实验的学习，深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，
这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
还有就是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是
如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。
总而言之，经过一学期的软工实验，深刻感到其重要性的同时也学到了不少的东西 ，将对我在今后的软件开发过程中起极大的作用。