软件工程实验心得体会

软件工程实验心得体会合集5篇

　　【前言】本文是会员“e81”分享的软件工程实验心得体会合集5篇，以供参考。

软件工程实验心得体会 篇1

　　软件工程心得体会未接触软件工程之前一直都很想学这门课程，因为觉得这门课很牛，是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课，终于知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑一种很茫然的感觉。曾经以为程序就是软件，软件就是程序。学习这门课程第一个收获是，知道了二者的不同之处。以前做过的一些小型的软件比如加密软件，我也只是在程序旁边附上一个软件的说明，看来已经很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生，使得人们不得不探索新的解决方法。

　　经过倪老师的讲解，理解了软件工程，就是一套用于软件的团队开发，以提高软件质量和程序员工作效率为目的的规范。其核心就是，对于软件开发的5个重要组成部分：需求分析，设计，编码，调试，维护，如何组织这5个部分的工作，以及如何完成每一个工作。吾生也有涯，而知也无涯，学习永无止境。起初，对软件工程处于一知半解的状态，分工比较混乱。

　　在划分模块后明确了各自分工，渐渐形成良性循环。在学习过程中，知道了团队合作十分重要，争议固然存在，但通过讨论、协商，群策群力，在不断磨合中能够达成一致与默契。团队成员中能力各有高下，互相尊重，各取所长，不宜妄自菲薄。组长多加协调，组员积极配合，才能合作愉快。学习能力体现在能尽快接受新的知识，顺应变化，学为所用。

　　上《软件工程导论》这门课，我的收获大概如下：我们为什么需要软件工程呢?上面已经给出了一些原因。专业点讲，软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计，没有设计指导的编程是无序的忙碌的。根据开发的软件的规模，应该适当程度的运用软件工程化的思想，需要灵活，毕竟我们开发的软件大多数是中小型的，大型的并不多见(我是这么认为的)。但只要涉及人员间的交流和沟通，或多或少都要需要软件工程才能更有效率，工作成果更稳定。

　　其实开发软件，就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法，即我写的这个程序是要干什么的;然后就是对要实现的核心功能大概构思一种或多种实现方法，并从中选出一种自认为是较好的;接下来就是将涉及的各种主要或次要功能分成各个模块;最后就是分模块来编码和DEBUG。在我看来，除了第一步外，其余的步骤应该是一个循环的过程。在编码的过程中，你总是需要不断地回过头来修改原先的模块设计，甚至最初选定的实现算法。具体到每一步的工作要怎样完成，是非常灵活的，只要把握住大体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的就是文档的编写。1.可行性分析就是关于当前项目能不能干的分析结果。

　　2.项目描述这是在决定立项以后，对当前项目的一份扼要说明。

　　3.需求分析就是对客户要求的功能的定义。

　　4.软件设计这就是对程序的每一个模块的详细设计的说明文档。

　　5.开发日志我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档，它的形式可以很随意，主要是记录一些在写程序时突然萌发的灵感，或对代码的一些微小的修改，或对程序结构的一些微小变动等，还要对上述这些修改变动作些说明。

　　6.测试分析用于指出程序存在或潜在的缺陷和错误，以及程序性能的数字描述。

软件工程实验心得体会 篇2

　　软件是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。软件工程（SoftwareEngineering，简称为SE）是针对软件这一具有特殊性质的产品的工程化方法。SE涵盖了软件生命周期的所有阶段，并提供了一整套工程化的方法，来指导软件人员的工作。任何事物都是从无到有的，软件当然也不例外。上世纪中期，软件产业从零开始起步，经过半个多世纪的发展，其大致经历的3个阶段：程序设计阶段、软件设计阶段和软件工程时代，现已成为推动人类社会发展的龙头产业，随着信息化时代的发展，软件对人类社会也将越看来越重要。人们对软件的认识自然经历了一个由浅入深的过程，在得到巨大需求的同时，也遇到了一系列严重问题，即软件危机。所谓软件危机，是指在计算机软件的开发和维护过程中所遇到的一些严重问题，其实质是软件产品的供应赶不上需求的增长。概括的说包含两方面的问题：一、如何开发软件，以满足不断增长，日趋复杂的要求；二、如何维护数量不断膨胀的软件产品。为研究和解决软件危机，一门新兴的学科软件工程，应运而生。

　　软件工程的概念是为了有效地控制软件危机的发生而被提出来的，它的中心目标就是把软件作为一种物理的工业产品来开发，要求“采用工程化的原理与方法对软件进行计划、开发和维护”，它的主要对象是大型软件，它的最终目的是摆脱手工生产软件的现状，逐步实现软件开发和维护的自动化。软件工程的概念自提出来后，经过几十年的发展，虽然软件危机没有得到彻底的解决，但在软件开发方法和技术方面已经有了很大的进步，提出了软件工程知识体系、软件工程三段论、软件工程生存期模型、服用原则等等。

　　软件开发过程大致经过7个阶段：可行性分析、需求分析、概要设计、详细设计、编码、测试、提交与维护。接下来逐一分析本人见解：

　　一、可行性分析：顾名思义，就是看项目究竟“能不能做”。有3个方面：技术可行性、经济可行性和操作可行性。要确定项目，首先要客观的、科学的了解项目的规模、难度和时间限制，才可以确定应该投入多少人力、物力和财力去做这个项目，必须准确的估计项目的规模与难度。看项目是否有价值去做，如果没有价值，就放弃；如果有价值，就要看目前的资源是否能满足项目的开发。如果项目有价值，且有必需的资源，那么就可以确定能做这个项目了。

　　二、需求分析阶段：解决“做什么、不做什么”的问题。围绕两个核心问题开展需求分析：应该了解什么？通过什么方式去了解？

　　1、了解什么：应该先了解宏观的问题，再了解细节的问题。最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适的技术来实现此需求。同时，需求说明不可有额二义性，更不能前后矛盾，如果有二义性货前后相矛盾，则要重新分析此需求。然后，选择合适的生存周期，建立合适的需求模型；

　　2、通过什么方式去了解：直接与客户交谈；有些需求客户讲不清楚，分析人员又猜不透，这是就要请教行家。需求分析是非常重要的阶段，如果做不好的话，后果很麻烦。

　　三、概要解决“怎么做”的问题。将需求描述的“做什么”问题变为一个实施方案的创造性过程，使得整个项目在逻辑上和物理上能够得意实现。概要设计是第一个开发活动，也是最重要的活动，是软件项目实现的关键阶段。设计质量的高低直接决定了软件项目的成败，缺乏或者没有软件设计的过程会产生一个不稳定的、甚至是失败的软件系统。一个良好的软件设计是进行快速软件开发的根本，没有良好的设计，会将时间花在不断的调试上，无法添加新功能，修改时间越来越长，随着给程序打上一个有一个的补丁，新的功能需要更多的代码实现，就变成一个恶性循环了。概要设计是软件设计级别中的高级设计，是从需求出发，描述了总体上系统架构应该包含的要素。概要设计尽可能模块化，因此描述了各个模块之间的关联，主要是根据需求规格或规格定义，合理、有效地实现产品规格中定义的各项需求，完成软件模块的划分并描述模块之间的关系，并不断分解系统模块，从高层分解到低层分解。它注重框架设计、总体结构设计、数据库设计、接口设计、网络环境设计等，将产品分割成一些可以独立设计和实现的部分并保证各个部分可以和谐的工作。此过程中画数据流图、IPO图、E-R图、界面设计等。

　　四、详细解决“具体做什么”的问题，将解决问题的办法进行具体化。软件设计的低级设计，亦即详细设计，主要描述实现各个模块的算法和数据结构以及用特定计算机语言实现的初步描述，是针对程序开发部分来说的，但这个阶段不是真正编写程序，而是设计

　　出程序的详细规格说明，这种规格说明类似于其他工程领域中工程师经常使用的工程蓝图，程序员根据其中所包含的必要的细节写出实际的程序代码。用另一种方式说就是，详细设计是将概要设计的框架内容具体化、明细化，将概要设计转化为可以操作的软件模型，但在实际项目进行过程中，依据项目的具体情况和项目要求，这个过程可能可以省略（逻辑上没有省略，表现在概要设计阶段或者编码阶段），直接按照概要设计进行编码；不过，个人认为最好有，有详细设计可以更好的保证编码顺利的进行，可以预先扫清编码过程中的障碍，提高代码的质量和编码的效率。主要包括模块描述、算法描述、数据描述，可以采用图形、表格或者文字描述等方式表达出来。

　　五、编码：实现项目。由项目的概要设计和详细设计，将设计变为代码需要通过编码过程来完成。实现设计有很多种选择，有很多实现语言、工具等可供选择，但一般而言，在设计中会直接或间接地确定了实现语言。编码过程的一个主要标准时变成与设计的对应性和统一性。如果编码没有按设计的要求进行，设计就失去意义了。设计过程中的算法、功能、接口、数据结构都应该在编码过程中体现。如果需求发生变更，设计业对应地发生变更，同时代码也应该一致地发生变更，这可以通过配置管理配置控制。可见，如果编码和设计不一致，很容易“跑偏”，走火入魔。编码时要严格遵循编码标准和规范，并提供必要的程序注释，增加可读性。另一个就是重构的理解，所谓重构是对软件内部的一种调整，目的是在不改变软件基本功能和性能的前提下，提高其可理解性，降低成本，当添加功能、修改代码和复查

　　代码的时候，更不要错过重构，另外，重构可以和设计互补。还有一点值得注意，要在必要的时候部署编码文档。

　　六、测试：看软件是否符合标准。软件编码完成之后，将软件提交给用户之前，需要对软件进行测试，这是保证软件产品质量的一个重要标准，也是评估产品质量的主要手段。软件测试是从软件工程中演化出来的一个分支，有着非常广泛的内容，并且随着软件产业的发展，它已经变得越来越重要。软件与生俱来就可能存在缺陷，为了防止和减少这些可能存在的缺陷，进行软件测试是有必要的，测试是最有效的的排错和防止缺陷和故障的手段。最原始的测试莫过于直接运行软件了，后来测试手段逐渐多样化。测试手段有静态测试、动态测试面向对象的测试、自动化测试等等之分。静态测试或称静态分析是指一种不通过执行程序来进行测试的一种技术，主要是检查软件的表示和描述是否一致，覆盖程序的编码格式、程序语法、检查独立语句的结构和使用等，主要包括代码检查、静态结构分析、代码质量等等，可以通过人工进行，亦可借助工具（如：语法分析器）自动进行。动态测试是运行被测试的程序，通过输入测试用例，对其运行情况进行分析，以达到检测的目的，显然动态测试封像我们通常意义上的“测试”。动态测试主要包括白盒测试、黑盒测试、灰盒测试（介于黑盒和白盒之间）。其他测试不再一一介绍。

　　七、提交与维护：测试完之后，就要把软件交给用户使用了。提交不是剪裁，给人家就行了，还要教会客户怎么使用这个系统。如果用户不会使用系统，就会不满意系统的性能，那之前的努力就白费了，

　　打水漂了。为了保证成功地将我们开发的软件提交给用户，我们需要对用户进行培训，同时提交必要的文档及用户手册软件。维护就不用多说了，就是售后服务了。维护需要分析人员、编码人员和设计人员等角色的参与，有纠错行维护、适应性维护、完善性维护、预防性维护等。维护后，要写软件维护过程文档，至少提交一个软件维护记录。以上是软件工程及其几个阶段的介绍，知道怎样开发软件只是软件工程的一部分，搞好团队合作也是很重要的。项目是一个很大的工程，需要一个团队的统筹规划，团结协作，集思广益，举一反三，才能够按预期完成。

软件工程实验心得体会 篇3

　　经过长时间对国贸软件的的使用，在不断练习操作的过程中，我对国贸软件的最深刻感觉是：学以致用、有趣、必须细心耐心反应迅速。

　　1.学以致用

　　作为国贸专业，经过长时间的理论学习，急需通过实际操作或某种近似于实际操作的平台对所学的理论知识加以实践，以求进一步掌握和巩固，而国贸软件正提供了这样一种平台。该软件涉及了及出口贸易的各个方面和环节，从外贸公司的经营运作到实际的进出口业务流程，都能进行模拟实训。在使用过程中，会遇到很多国贸的基础理论知识和实务技能，这是对国贸理论掌握程度的最好考察。眼过千遍不如手过一遍，相对于理论部分而言，国贸实务更注重实际操作，通过这种理论结合实践的方式，巩固基础知识，查找理论学习的不足，以前学习的实物理论基础知识会更加的具体和直观。同时，该软件的实务操作部分与报关员报关实务所涉及的知识基本一致，这对于我的报关员考试复习提供了很大的帮助。

　　2.有趣

　　该软件通过“实战”方式训练，会在操作过程中遇到很多难题和挑战，这些必须自己想办法解决。由于大家进行了角色划分，形成了一个虚拟市场，所以大家之间相互的竞争是必不可少的，大家会从各个方面进行竞争。竞争在现在是无法避免的，意识正是现代社会生存发展所需要的。正是这种竞争，使得我(相信大家)对该软件产生了浓厚的兴趣。

　　3.细心、耐心、反应迅速

　　国贸软件涉及大数据计算的繁琐的单证填写，所以必须做到细心耐心，例如，在填制外贸合同时，一个小小的数据错误或是货物装运、指运港名称的错误都会是合同填写失败;填写保险单或是报关单证，没有严格按照合同数据填制就会导致填写出现错误，无法进行下一步骤，影响实验效率。

　　在操作过程中，除了复习、巩固所学国贸理论外，另一个重要任务就是想办法“赚钱”，提高自己企业的盈利水平和生存能力，这就要求必须反应迅速、判断准确，否则会觉得企业经营的举步维艰。

　　以上就是经过一段时间对国贸软件的操作使用产生的心得体会。

　　aaa篇2

　　我们是20xx年3月7号进入宏天实训公司参加软件开发实训的，在此次实训中，除了让我明白工作中需要能力，素质，知识之外，更重要的是学会了如何去完成一个任务，懂得了享受工作。当遇到问题，冷静，想办法一点一点的排除障碍，到最后获取成功，一种自信心就由然而生，这应该就是工作的乐趣。有时候不懂的就需要问别人了，虚心请教，从别人的身上真的能学到自己没有的东西，每一次的挫折都会使我更接近成功。还有学会了在工作中与人的合作与交流，同乐同累，合作互助，这是团体的精神，也是必须学习的东西。

　　经过之前的在校学习，对程序设计有了一定的认识与理解。在校期间，一直都是学习理论知识，没有机会去参与项目的开发。所以说实话，在实训之前，软件项目开发对我来说是比较抽象的，一个完整的项目要怎么分工以及完成该项目所要的步骤也不是很明确。 而经过这次实训，让我明白了一个完整项目的开发，必须由团队来分工合作，并在每个阶段中进行必要的总结与论证。

　　一个完整项目的开发它所要经历的阶段包括：远景范围规划和用例说明、项目结构和风险评估、业务功能说明书、详细设计说明书、代码实现、测试和安装包等等。一个项目的开发所需要的财力、人力都是很多的，如果没有一个好的远景规划，对以后的开发进度会有很大的影响，甚至会出现在预定时间内不能完成项目或者完成的项目跟原来预想的不一样。一份好的项目结构、业务功能和详细设计说明书对一个项目的开发有明确的指引作用，它可以使开发人员对这个项目所要实现的功能在总体上有比较明确的认识，还能减少在开发过程中出现不必要的麻烦。代码的实现是一个项目开发成功与否的关键，也就是说，前期作业都是为代码的实现所做的准备。

　　我深刻的认识到要成为一名优秀的软件开发人员不是一件容易的事情，不仅要有足够的干劲和热情，还要有扎实的编写代码基础，必须要有事先对文档进行可靠性报告，功能说明书，详细设计说明书等的编写和一些风险评估的编写的能力。

　　除了图书馆，最能让我感觉到身在大学的就是实训机房，在匆匆过去的两个月内，我往返于实训机房与宿舍之间，使我享受了一个充实的学习时期，让我感受到了大学的魅力，对自己充满信心，对大学充满信心，以积极的心态迎接明天挑战。

　　实训中要求有扎实的理论基本知识，操作起来才顺心应手，我这时才明白什么是“书到用时方恨少”。这就激发了学习的欲望。

　　“学以致用”，就是要把学来的知识能运用到实际操作当中，用实践来检验知识的正确性。我想，这是实训的最根本目的。

　　“纸上得来终觉浅，绝知此事要躬行!”,在短暂的实训过程中，让我深深感受到自己在实际运用中专业知识的匮乏。以前总以为自己学的还不错，一旦应用到实际就大不一样了，这时才真正领悟“学无止境”的含义。

　　经过为期两个月的电子政务服务平台系统开发的实训，我对Visual 软件开发平台有了更深一步的了解，对微软基础类库的认识与使用也有了大大的提高。以及如何使用SQL Server数据库进行连接操作方面有了本质的提高。

　　短短的实训结束了，为我将来的就业打下了良好的基础，也提高了我的软件开发的水平，今后我将会更加努力的学习，不断提高自身素质，开拓创新，与时俱进，做一个优秀的软件开发工程师。

　　aaa篇3

　　这学期学习了软件工程实践这门课，我觉得这是对上学期的软件工程课程学习的检验，上学期学习软件工程只是我们浅显的认识，相比之下，这学期就更加全面的说明了开发一个项目所需要的步骤以及开发项目过程中所需要注意的诸多细节。如果说上学期的课程注重理论基础的话，那么这学期的软工实践，顾名思义，就是侧重我们动手操作的能力。

　　原来我认为开发一个项目最重要的就是写代码，似乎整个软件都是编代码，因为自己动手能力不强所以就很排斥做项目。可是经过我们学习软工课程到团队做项目再到学习软件工程实践课程之后，我才真正意识到实施一个软件工程项目并不是说简单的会编码就能够解决问题的，因为一个软件的生命周期分为三个时期：软件定义时期、开发时期、维护时期，而这三个时期整体又分为七个阶段，他们分别是：问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试，由此可看出，当我们开发一个项目时，更多的精力不是放在编码上，编码只是一个很小的模块，而是项目的整体结构上。

　　在写软工实践体会之前，我想在这里总结一下上学期三人团队做 项目的相关事宜。上学期我们三人团队根据软件开发的步骤开发一个名为“西大老乡‘荟’”的社交系统，主要是为西大学子提供一个找老乡的平台。虽然只进行到详细设计阶段，没有进一步实现，但是我还是从中学到很多东西的。首先要先确定项目主题，也就是这个项目用来做什么，可以解决什么问题。接着就是这个项目是否有研究的必要以及是否有解决的办法，针对我们的项目，我们对西大的一些学生做了问卷调查，并从调查中继续完善系统本身的做用户。第三步根据我们确定的项目主题进行需求分析，这一步骤当时做的不是很好，比如所画E-R图、数据流图等都有考虑不周的问题，导致接下来的概要设计、详细设计进行的很困难，有些步骤甚至还需要返工。

　　从我们在需求分析中出现的问题，使我们明白了软件定义阶段对于一个项目的开发是至关重要的，当软件定义阶段完成时必须要用正式的文档准确的地记录目标系统的需求。只有前期的准备工作做得好，后面的工作才能顺利进行。虽然项目最后没有完全实现，但是起码我们已经初步体会到软件项目开发的步骤，以及每一步所需要完成的文档等内容。

　　这学期的软件工程实践虽然不是亲自动手开发一个系统，但是张元平老师以“物联网物流仓储管理系统”为主给我们讲解了一个真实系统的开发过程，从计划到项目系统的发布实施，以及每一步必须生成的文档。我主要从以下五个方面谈一下我的心得体会。

　　第一、行业背景说明方面

　　对于一个软件系统的开发，第一步就是问题定义，了解所开发系统的行业背景，制定计划。当我们计划确定以后就要对项目系统本身进行可行性研究，主要从技术可行性、经济可行性和操作可行性三个方面着手。就比如《物联网物流仓库管理系统》的行业背景说明文档中非常详细地分析了当下物联网物流行业的整体业务说明、应用背景、未来发展趋势以及相关应用案例等四个方面，项目团队中系统分析员就可以根据这份文档以及相关的调查资料对将要开发系统的进行定义等工作。

　　原来我们写这类文档的时候就是草草了事，不会做得这么详细，而这次看到大型项目的行业背景说明也是这么详细，也让自己认识到不管是软件开发的那个阶段都要认真对待，这些琐碎的文档都是后期开发项目的支撑，只要它们做的透彻，后面的开发工作才能更顺利的进行。

　　第二、项目需求说明方面

　　这部分项目需求说明就是软件定义时期中需求分析阶段，而该阶段的主要目的就是了解用户的需要，根据用户的需要确定系统必须完成那些工作，并对目标系统提出完整、准确、清晰、具体的要求。在需求分析结束之前系统分析人员要写出一份需求规格说明，即为《物联网物流仓储管理系统》项目需求说明文档。我们可以看出该文档也是非常详细，相比之下我们之前做项目时写的需求规格说明书就非常不合格，不仅格式不正确内容也是少之又少。

　　在这方面，这篇文档给我启发很大。首先就是文档的格式，要美观整齐，让人看着舒服方便。其次就是文档的内容，原来它不是很重要，写文档的时候也不知道怎么写就借鉴下网上的内容，结果根本就没有把自己项目的需求写明白，以至于自己最后都有些糊涂，所以根据以前的经验教训我会对这部分更加重视。

　　第三、系统概要设计方面

　　这部分内容分说的是软件设计时期的概要设计阶段，该阶段的主要目的就是实现系统的功能、设计软件的结构、模块组成以及模块之间的关系。在概要设计阶段，我们可以站在全局的高度上，花较少的成本，从抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的结构。在这个阶段还会具体画出E-R图、数据流图等方面的设计。

　　比如《物联网物流仓库管理系统》的系统概要设计从项目概述、设计约束、功能单元与功能模块设计、数据E-R图设计、总体设计、界面设计等六个方面介绍，通过读这个文档，我觉得最重要的还是总体设计，分别从逻辑架构设计、物理架构设计、技术架构设计设计系统。在这个阶段中模块要做到高内聚低耦合，这样开发出来的系统才会具有更高的独立性。

　　在原来做项目时没有编写过这类文档，在该阶段只是画了结构图、层次图以及相关的模块划分，对该类文档尚未重视。通过张老师的讲解和自己的学习，我相信在以后做项目的时候一定会注意到这类文档的编写。

　　第四、详细设计与分析方面

　　详细设计阶段就是把概要设计阶段的每个模块进一步设计，确定每个模块所需要的算法和数据结构。在这个阶段还是需要我们设计出程序的详细规格说明，而不是编写程序。在详细设计阶段，系统设计人员可以通过使用程序流程图、盒图、PAD图等过程设计的工具和Jackson图等面向数据结构的设计工具进一步设计系统相关接口，主要包括界面设计接口、业务单设计接口、单元模块设计接口等，这些对于以后的编码工作都是极其重要的。

　　第五、编码和测试方案方面

　　关于编码，我认为编码要想做的完美必备条件就是前面的软件定义和软件设计时期要按部就班的做，文档一定要按要求书写，不能偷懒也不能草草书写。对于编码也要有相应的文档书写规范，要使源程序代码的逻辑简明清晰、易读易懂。这样尽管我们不是设计系统的人员，当看到源程序代码的时候也能容易读懂代码的意思。

　　其次就是测试的内容，从测试的文档中我们可以得出，其实测试在软件开发中同样占据了重要的地位，它主要就是尽可能多的找到问题并排除其中的潜藏的错误，最终把一个高质量的软件系统交给用户使用。它要求测试人员也要有很高的技术水平。

软件工程实验心得体会 篇4

　　我的第一份工作并不顺利，那时刚刚来到南昌，对这里的一切还都很陌生。第一次去面试，根据上面提供的信息我坐上工交车，一个小时过去了可还没到。电话得知我已经过了目的的!哎!第一次面试就这样流产了!

　　大学这么长时间，自己也已经做过好几分工作了，大多是促销员的工作，比如维纳斯婚纱摄影，爱维利斯化妆品促销，美的微波炉之类的工作。一开始毫无经验，工作感觉很困难，但是经过多次的磨练与培训以后，自己收获了很多。不仅工作能力有了一定的提高，自己的意志力也得到了很大的锻炼，工作过程中，受到冷眼是很正常的，也就是说必须忍受!

　　有了第一次的教训，第二次好不容易才找到公司所在地址。面试的人还是挺多的。看着这些陌生的面孔，心里有种不安的感觉，我是害怕失败吧!不管怎样，总要面对的!这是第一次参加这样的活动，不免有些紧张，台上没能完全的放松!经过漫长的面试，我还是满幸运的获得了我的第一份工作—-维纳斯促销员工作时间是国庆三天。节假日，八一广场人山人海，我们的工作是负责招揽顾客到摄影电里拍照，对象是情侣，婴儿或是消费能力高的人群(那家的消费可真不是一般人所能愿意花费的}!手里拿着宣传单穿梭在人群里，寻找目标。漫长的一上午也没拉到几个顾客，这真的有点难，不免有些泄气，很想不干了!那时已经有几个中途逃离了!也许，是第一份工作不想就这么结束了，最终我还是坚持里下来!可是我的努力却只换的10块一天的工资，理由是我没拉到很多顾客!第一份 工作很失败……

　　之后是美的微波炉的工作，这次面试相对前次好多了，没有了上次的怯场，痛快地表达自己!和以往不同的是，这次面试增加了辩论这一环节，所有人员分成两组进行辩论!所以，这次要求挺严格的，经验固不可少，更重要的是口才!两个多小时所有环节都一进行完毕，考官当场宣布录取人员名单，这次幸运女神还是照顾我的，我成功的通过了面试!在工作之前，我们进行了一天的培训，半天的实习，然后正式分配任务。对于微波炉的促销，首先必须了解相关产品知识，并掌握一些必要的解说技巧，这些在一天的培训里都已经有所领悟。白猫黑猫，抓到老鼠就是好猫!这次工作感觉还好，收获也不少，当然也包括Money了!

软件工程实验心得体会 篇5

　　经过这学期软件工程实验的学习，深深感到用户需求对软件的重要性。成功的软件产品是建立在成功的需求基础之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。

　　需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。

　　其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。

　　需求获取活动要完成的任务或者步骤的过程如下：

　　1、编写项目视图和范围文档

　　系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

　　非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。

　　2、用户群分类

　　系统用户在很多方面存在着差异，例如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等。根据这些差异，你可以把这些不同的用户分成不同的用户类。与ULM中Usecase的Actor概念一样，用户类不一定都指人，也可以包括其他应用系统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获取和系统设计。

　　3、建立核心队

　　通常用户和开发人员不自觉的都有一种"我们和他们"的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的"边界"，只想自己的利益而忽略对方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功对方需要什么时，才能建立起一种合作关系。

　　为了建立合作关系通常采取一种组队的方式来获取需求，建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意以下原则：小组会议应该由中立方来组织和主持，用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点，但信息来源应该自由;交流目标要明确，并告知所有的成员。

　　4、确定使用实例

　　从用户代表处收集他们将使用系统完成所需任务的描述，讨论用户与系统间的交互方式和对话要求，这就是使用实例，一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点，比起使用以功能为中心和以开发者为中心的方法，使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述，尽量使用主动语态，用"系统"或者"用户"作为主语，比如"用户提交用户密码，系统验证用户密码是否正确"，还有一点在描述中不要设计界面细节，比如"用户从下拉框中选择产品类型"。使用实例为以后写用例场景描述中的`基本路径和扩展路径提供了素材。

　　5、分析用户工作流程

　　分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号,为每个用例分配一个唯一的编号，为需求的追溯提供了方便;参与者，与这个用例交互的 actor;前置条件，开始用例前所必须具备的系统状态;后置条件，用例完成后系统达到的状态;基本路径，用例完成的关键路径，也是用户期望的路径;扩展点，基本路径的分枝，表示意外情况;字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用;设计约束，实现用例的非功能约束。

　　6、检查问题报告

　　通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。

　　7、需求重用

　　如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。

　　总结：经过一学期的软工实验，深刻感到其重要性的同时也学到了不少的东西 ，将对我在今后的软件开发过程中起极大的作用。