关于软件工程的总结五篇
篇一：软件工程总结
摘要：
计算机是20世纪最重大的科学技巧成就之一，使当代社会的经济、军事、科研、教育、服务等方面在概念和技巧上发生了性的变化，对人类社会的进步已经并还将产生极为深刻的影响。目前，计算机是世界各发达国度剧烈竞争的科学技巧领域之一。
电子计算机早期功效主要是计算，后来已远远超越单纯计算的功效，还可模拟、思维、进行自适应反馈处理等等，把它叫做“电脑”更为合实际。由于电子计算机功效的飞跃性发展，应用于生产和生活的各个方面，直接和显著地提高了生产、工作和生活的效率、节奏和水平，在软科学研究和应用中它也起着关键作用，因此它已被公认是现代技巧的神经中枢，是未来信息社会的心脏和录魂。计算机学科分为四个领域，分别是计算机科学，计算机工程，软件工程和信息系统。
正文：
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。包括项目管理，分析，设计，程序的编写，测试和质量控制。它涉及到程序设计语言、数据库、软件开发工具、系统开发平台、标准、设计模式等方面。
学了《软件工程》这门课程和一些有关资料后，感觉一些东西都曾经接触过，但在实际工作中有些理论要完全遵循可能还有些障碍，软件工程只是提供了理论上的一些结论，但对项目的具体可操作性的规范的制定方面却做的很少，《软件工程》发展了几十年，光是开发模型就达到了10多种，对不同的项目采用合适的开发模式，有些项目在不同的开发阶段可能还要转换开发模式，把它们灵活的应用到实际中还是很困难的。
软件技术是信息技术产业的核心之一，软件技术的发展是与信息技术产业的发展互相促进的。当今世界，信息技术正处于新一轮重大技术突破的前夜。预计今后 20~30 年是信息科学技术的变革突破期，可能导致 21 世纪下半叶一场新的信息技术革命。近年来，从 IT 界到一些国家首脑，都高度关注以物联网为标志的新一轮信息技术的发展态势，认为这是继 20 世纪 80 年代 PC 机、90 年代互联网、移动通信网之后，将引发 IT 业突破性发展的第三次 IT 产业化浪潮。每一次重大的技术变革都会引起企业间、产业间甚至国家间竞争格局的重大变化，也促进了软件技术与软件产业的重大变革与发展。
近年来，信息技术、软件技术、软件系统与软件产业的发展备受关注，已有不少论述、分析与判断。近 10 年内网络技术经历宽带化、移动化和三网融合将走向基于 Ipv6 的下一代互联网， 2010 年 1 月，国家 863 计划信息技术领域办公室和国家 863 计划信息技术领域专家组，在上海举办“信息-物理融合系统 CPS发展战略论坛”，提出“信息-物理融合系统 CPS 是一个综合计算、网络和物理环境的多维复杂系统，是信息和物理世界的深度的融合交互，可实现大型工程系统的实时感知、动态控制和信息服务，使系统更加可靠、高效与实时协同，使得人类物理现实和虚拟逻辑逐步融合，具有重要而广泛的应用前景。 业界关于软件工程的代表性观点
1 创立与使用健全的工程原则，以便经济地获得可靠且高效率的软件。
2 应用系统化，遵从原则，可被计量的方法来发展、操作及维护软件；也就是把工程应用到软件上。
3 与开发、管理及更新软件产品有关的理论、方法及工具。
4 一种知识或学科，目标是生产品质良好、准时交货、符合预算，满足用户所需的软件。
5 实际应用科学知识在设计、建构电脑程序，与相伴而来所产生的文件，以及后续的操作和维护上。
6使用与系统化生产和维护软件产品有关之技术与管理的知识，使软件开发与修改可在有限的时间与费用下进行。
7建造由工程师团队所开发之大型软件系统有关的知识学科。
8 对软件分析、设计、实施及维护的一种系统化方法。
9 系统化地应用工具和技术于开发以计算机为主的应用。
10软件工程是关于设计和开发优质软件。
《软件工程》是一门综合性和实践性很强的核心课程，它属于是一门交叉学科，包含有：软件开发技术（软件开发方法学、软件开发过程、软件工具和软件工程环境 ）、软件工程管理（软件管理学、软件经济学、软件心理学）。主要内容包括软件工程概述、可行性分析、需求分析、概要设计、详细设计、面向对象分析与设计、编码、软件测试、项目计划与管理。
本课程是面向准备从事软件开发的毕业生而开设的一门专业课程。针对计算机教学中软件工程这一薄弱环结，结合目前软件开发商对人才的要求，对计算机专业的毕业生进行软件工程强化培训，目的是使毕业生能够了解和掌握软件工程的基本理论和方法，并在实际软件开发中运用这些方法。
我理解，软件工程是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确的软件系统。而且，软件工程在企业范围内运行，一定需要企业资源的支持，要与企业的经营、决策、管理体系联系在一起，才能够被踏踏实实的落实下来。
软件工程项目是一个需要一步一步的计算，分析思考而来的，需要不断思考，研究不断进步，软件业作为一个服务业，要想得到发展，首先必须形成一个对软件服务有迫切需要的市场。其次，这个市场中的消费者必须具备足够的购买力。软件的消费群体简单一点，可以分为个体消费和企业消费。中国的企业群体，数量庞大，但是质量不高。上规模的企业极少。国内目前能够形成比较大规模的独立市场的，肯定是小规模的软件系统。
随着信息化时代的到来其地位越来越受到人们的重视，软件工程从一个学科，或是某一个研究方向来说，人员仅仅是过程，方法的执行者，所以人员素质往往被忽略，软件工程是一门实践性很强的学科，所以在实际的软件研究过程中，人员的素质占有很重要的地位。要有出色的软件问世，研发人员的素质至关重要！
作为软件工程的学习者应该不断创新，不断尝试、实践，不断研究和学习，中国的软件工程技术依旧滞后于国外一些软件工程技术，作为新一代的学习者应该担当起振兴起中国软件事业，使中国科技得到高速发展！
现在已经是信息化时代，信息化潮流不断涌现，想要掌握主动权就是掌握信息化的发展方向，这就需要我们不断学习，时间，研究，学习国外的先进技术，转变自己的技术，然后融合，创新。
软件技术不是一成不变的，是随着社会的进步的不断进步，不需要不断的创新，不断的改善的，需要我们不断的学习，不断的研究，不断进步。
篇二：软件工程工作总结与建议
姓名：
部门：行业开发部 – 超市项目组
出生日期：1980-11-25
个人简介：
没什么爱好，唯软件开发技术情有独钟，常自娱自乐，自小热爱编程，从小学6年级开始正式学习程序设计，至今已有12年有余，18岁中专毕业，参加工作，至今已有5年，近6年的软件开发工作经验，工作期间也不断学习，完善自己的职业技能，理解软件开发的思想，熟悉Delphi、C/C++/VC++、ASP、SQL Server、Html、脚本语言（如：VBScript、JavaScript），汇编，熟悉Win32SDK编程，经过多年的学习和实践相结合对面象对象的设计与开发也有深刻的理解和自己独特的见解。列宁曾说“实践高于（理论的）认识，因为它不仅具有普遍性的品格，而且还具有直接现实性的品格。”，我始终相信。
对软件逆向工程也比较熟悉,熟悉汇编/反汇编，熟悉各种静态反编译（反汇编）工具如DD、W32DASM、C32ASM等，熟悉各种动态跟踪调试工具如SoftICE、OllyDBG等工具，熟悉加密与解密，能够利用这些工具和我的知识对软件进行加密，防止盗版，能够对软件进行解密和逆向工程，研究软件的底层机理，属于中国破解组织BCG/DFCG/OCN/DCM/CZG正式成员(注:这些组织都是以技术研究为主的,跟盗版是两回事)。
同时熟悉多层系统的设计开发，熟悉各种软件工具的使用，对Windows系列操作系统较为熟悉，对Linux操作系统有所了解。掌握面向对象的分析与设计和相关工具的使用，对软件工程化也比较熟悉,由其感兴趣的是敏捷软件开发。曾任技术研发组组长，带领技术研发组完成技术攻关，管理软件项目。有极强的自学能力和归纳总结能力。对一项技术有强烈的钻研欲望.
转入正题了，首先谈谈，我认为我所在的项目组做得好的地方．在我们项目组中使用了CVS做软件的版本控制，用RoboHelp写文档，用TestTrack做Bug跟踪．
做得不好的地方就是需求描述不清晰，而我们过早的进入＂设计＂阶段，过迟的进入测试阶段．
我们需要的需求描述是这样的：只说做什么，不说怎么做，并描述出希望得到的结果，至于操作习惯这些东西可以在得到了正确的软件功能后再作调整．
例如：
再来看看我们的代码：
我们目前的代码根本不具备可测试性，当改动一个地方的时候我们不可能自己把所有代码功能都跑１遍，以保证程序的正确性，保证程序的质量，有可能我们改动的这一个地方会牵扯到另一个地方或N个地方，而我们有可能没有考虑到这个关联性或没有考虑完，于是１个地方的改动造成了N个地方的错误．这样的问题在我们公司开发人员中基本是天天都在上演重复的一幕，造成开发成本／维护成本不断的上升，产品迟迟不能稳定．
还有一个比较严重的问题是过早的进行设计，把程序的结构过早的定下来，这样导致的后果是要当需求发生变化，目前的系统结构无法满足需求时，可想而知后果的什么样的．
再来说说测试：
我们的测试人员可说是做得比较好了的，这点我没什么好说的．我只是想说让我们开发产品应该尽早的提交给测试人员和用户进行测试，这样我们可以更早的得到反馈，对产品作出改进和修改．
我想重点对我们开发谈谈，提出一些自己的建议：
为了保证我们的程序具有可靠性，可维护性，可阅读性，让我们产品达到一个高质量的标准，我想唯一的方法就是让我们代码具有可测试性，可测试性的代码是具有良好结构的，优美的，高质量的并且也是简单的．其中以测试来驱动开发(TDD)的方法是我较为推崇的，我在家自己写的程序基本都有Unit Test．
Unit Test又叫单元测试，是针对程序最基本结构单元所进行的测试。而TDD的过程是这样的，写一个测试程序，使其可以运行，重构。在写这个测试程序的时候你考虑的不应该是基于什么结构单元，而是要考虑需要完成的什么功能。实现和重构的时候，具体是不是这个单元完成了这个功能依然不是你应该去考虑的，你考虑的还是——是不是完成了这个功能、是不是代码真的清晰和可工作。你考虑的问题永远是围绕着具体的功能进行的，而不是围绕某种结构进行的。你写这个测试程序的时候，这个结构并不存在，并且今后也可能不存在（由于重构，你在别的结构部分实现了这个功能）。
明白这个道理就可以明白TDD实际还是基于需求驱动的，还是一种前瞻性的设计手段。只不过TDD让这个需求更加具体，让其前瞻性也更可以预测，并且在多种方法中给了你进行多种尝试的机会。而当你认为这个测试只是单元测试的时候，无疑你就把程序的结构早早的做了一个固定，其是基于结构的而不是基于需求的，并且由于其基于结构的一面则设计的前瞻性很难得到保证，而就根本性的断绝了你进行多种尝试的可能。设计的前瞻性是指你的设计可以带来可以预测的结果。而软件的结构是动态的，并且随着你必须进行的重构活动这样的结构变更会日常性的存在。如果你的一个测试高度的依靠某种特殊的结构，在这样的经常性重构的环境下，其被经常性修改的几率会大大增加。而由于其结构的不确定性是根本不可能逆转的，所以针对结构进行的测试根本不可能带来结构上的可预测性，而谈不上什么前瞻性了。
软件开发是一个不断跌代的过程，我们应该小步前进，不应该一开始就固定的程序的结构，一开始就使用复杂的设计模式，这些程序结构和设计模式都应该是我们通过了N次跌代后得到的结果．应该切忌为了显示自己的水平而在一开始使用这些复杂的东西．
时间有限，就谈到这里，附上两篇我以前写的关于开发的文章，作为参考，详见附件 １．简单设计
２．挑战极限－测试驱动开发
篇三：软件工程心得体会
对于学习软件工程这门课程，我认为有许多东西要学习。其实在我看来学习这门课程的精髓是学习一种方法。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。读完软件工程案例教程这本书，我觉得自己受益匪浅。
整本书的内容逻辑很清晰明了，由浅入深循序渐进，首先我就大概描述下我们所学的内容，第一章是从整体分析软件工程这门学科的发展和所处的社会环境，接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。 对于这本书我主要对需求分析和测试比较感兴趣，在这我要着重的谈一些自己的心得体会以及自己的看法。
一．需求分析
1.1需求分析的重要性
一款成功的软件是建立在成功的需求分析之上的，而高质量的需求来源于用户与开发人员之间有效的沟通与合作。当用户有一个问题可以用计算机系统来解决，而开发人员开始帮助用户解决这个问题，沟通就开始了。由此我们可以看出需求分析的重要性。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求，只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。
其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，忽略了那些被认为是"很明显"的信息。最后是
需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织的执行需求的获取活动。
1.2需求分析的原则
（1）需求分析必须能够表达和理解问题的数据域和功能域。数据域包括数据流、数据内容和数据结构，而功能域反映上述 3 方面的控制信息。
（2）需求分析要把一个复杂问题按功能进行分解并逐层细化。通常，软件系统要处理的问题如果太大、太复杂就很难理解，若划分成几部分，并确定各部分间的接口，就可完成整体的功能。在需求分析过程中，软件系统的用户需求中的数据、功能和行为都应细化。
（3）需求建模。模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为，这些模型是软件工程中下一阶段进行系统设计的基础。
1.3需求分析的注意事项
（1）确定详细的需求，否则经费就算不准。经费估计错误的原因多为：用户需求频繁变动、遗漏重要需求、与用户交流不够、需求规格说明书质量低劣、需求分析不充分等。
（2）在编写需求规格说明书之前，应明确要解决的问题。在试图解决问题之前，要保证已考察了全部可替代的方案。要搞清哪地方有问题，真正的问题出在哪里。这样，在编写需求规格说明书时做到有的放矢，把存在的问题暴露出来。
（3）立即确定需求，并记录下该需求的背景。没有明确问题，就进行下一步的设计，想回避矛盾，可能会带来更大的问题。用户不确定需求，软件设计人员自己决定需求，将会带来严重的问题。为了避免将来可能出现的问题和软件工程项目能够尽快地进入到下一个阶段的系统设计中，要尽可能迅速地把用户需求确定下来。任何决定总比没有决定要好。
（4）一旦在需求规格说明书中发现问题，立即改正。如果把存在的问题拖延到系统设计阶段去改正，就可能要花数倍的时间和精力才能纠正同一错误。
（5）在众多用户需求中确定各个需求的优先顺序，并确定可能存在的子集，以便为软件设计、实施和项目管理等后续阶段提供有利条件。
（6）需求分析时，不要进行系统设计的工作。需求分析的主要目的是确定软件系统的外部特征，充分反映软件系统应有的面貌，便于让软件设计人员根据
用户需求，去全面地考虑软件系统的体系结构、算法等。在需求分析阶段要集中精力解决用户需求存在的问题，尽可能避免产生遗留问题。
（7）对于复杂的软件系统，要从多种视角进行需求分析。根据软件系统的本质，切合实际地组织多种视角的需求。例如，可从根据用户的类型，或根据响应的类型，或根据对象的软件工程案例教程类型，或根据系统的模式等视角来组织用户需求。通过多个视角来研究用户需求问题，把可得到的不同的“投影”组合起来形成完整系统的描述。当试图从整体观点来描述软件系统发生困难，或者有可能发生错误，或者很有可能遗失软件系统的某些特性。而从不同的视角来 描述软件系统，因为每个视角限制了研究的范围并能够将注意力集中于此，所以很容易保证所研究的问题是真正完整的。
（8）重视形式化方法，但不放弃自然语言。为了用户需求表达的精确性和方便用户的可理解性，一个好方法是把自然语言的表达与形式化规格说明并立，互相对照，而且在一般情况下，先用自然语言写出，再给出它的形式模型。
（9）用户需求中不应存在“待确定”的条款。如若有这种需要，应同时说明：何时由谁来解决该问题。
1.4用户需求的类型
需求分析是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程。它实际上是一个对用户意图不断进行揭示和判断的过程，其目的在于细化、精化软件的作用范围，确定拟开发软件的功能和性能、约束、环境等。可将用户的需求分为两大类：功能性需求和非功能性需求。
（1）功能性需求。功能性需求主要说明了系统各功能部件与环境之间的相互作用的本质，即拟开发软件在职能上实际应做到什么。一般来说，它是用户最主要的需求，通常包括系统的输入、系统能完成的功能、系统的输出以及其他反应。在功能性需求中还应包括备选功能的定义识别。
（2）非功能性需求。非功能性要求主要从各个角度对所考虑的可能的解决方案起约束和限制作用。
1.5需求分析的方法
在软件工程中，常用的需求分析方法有面向数据流的结构化分析方法（简称 SA）和面向对象的分析方法（简称 OOA）。此外，还有以用户为中心的需求分析
方法。这些方法都采用图文结合的方式，可以直观地描述软件的逻辑模型。这里仅介绍结构化分析方法和以用户为中心的需求分析方法。
二.软件测试
2.1软件测试概述
软件本身无形态，它是复杂的知识高度密集的逻辑产品，其中不可能没有错误。软件实施工程过程中必须伴随着软件质量保证的活动，而软件测试是主要活动之一。在开发软件的过程中，人们使用了许多保证软件质量的方法分析、设计和实现软件，但难免还会在工作中犯错误。这样，在软件产品中就会隐藏许多错误和缺陷。对于规模大、复杂性高的软件更是如此。在这些错误中，有些是致命的错误，如果不排除，就会导致生命与财产的重大损失。
2.2软件测试的目的
测试的目的是“说明程序能正确地执行应有的功能”，还是“表明程序没有错误”？基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可以接受该产品。而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。因此，他们会选择那些导致程效概率小的测试用例，回避那些易于暴露程序错误的测试用例。同时，也不会刻意去检测、排除程序中可能包含的副作用。显然，这样的测试对完善和提高软件质量毫无价值。因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。如果站在用户的角度，替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。在选取测试用例时，考虑那些易于发现程序错误的数据。
2.3软件测试的原则
（1）应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。由于原始问题的复杂性、软件的复杂性和抽象性、软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。所以不应把软件测试仅仅看成是软件开发的一个独立阶段，
而应当把它贯穿到软件开发的各个阶段中。在需求分析阶段就应该制订测试计划，以保证每个需求，每个设计单元都是可测试的，便于测试。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。
（2）测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。测试以前应当根据测试的要求，选择在测试过程中使用的测试用例（Test Case）。测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。
（3）程序员应避免检查自己的程序。测试工作需要严格的作风、客观的态度和冷静的情绪。自己测试自己的软件不容易发现错误，程序员应避免测试自己的程序。测试是一种“挑剔性”的行为，人们常常由于各种原因具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事，这一心理状态就成为测试自己程序的障碍。心理状态和思维定式是测试自己程序的两大障碍，应由别人或另外的机构来测试程序员编写的程序。另外，程序员对软件规格说明理解错误而引入的错误则更难发现。如果由别人来测试程序员编写的程序，可能会更客观、更有效，并更容易取得成功。要注意的是，这点不能与程序的调试（Debugging）互相混淆，调试由程序员自己来做可能更有效。
（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的、可能引起问题变异的输入条件。在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户软件工程案例教程 在键盘上按错了键或打入了非法的命令。如果开发的软件遇到这种情况时不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。因此，软件系统处理非法命令的能力也必须在测试时受到检验。用不合理的输件测试程序时，往往比用合理的输入条件进行测试能发现更多
篇四：软件工程实践个人总结
在这个学期的软件工程实践课中，我们小组所选的题目为XXX公司全国销售管理系统。按照这个题目及相关需求，我们小组对选题进行了需求分析、模块设计、系统设计、数据库设计、用户界面设计等，并积极完成相应的开发编码工作，后又对开发的系统进行了相应功能的测试工作。
对项目的理解
我们项目小组制作的的是XXX全国销售管理系统，该公司考虑进行集约化经营模式，进军电子商务领域，将全国市场资源进行整合形成有自身特色的经营体系，提升企业核心竞争能力，为此需要运用电子商务的力量对全国经销商资源进行整合，对线上和线下进行双重营销。
经过对该项目的相关分析，我们小组明确了要具体实现的功能模块。我们所开发的系统共有两大模块，一块为XXX公司面向普通用户的在线商城销售系统；另一块为XXX公司用户进行对内的自我管理的管理系统。两个大模块下具体细分包括网上商城、客户管理、市场及销售管理、内部办公系统、仓库管理、财务管理、权限与安全7个子模块
在线商城中，要实现商品信息的展示、浏览，用户将添加商品到购物车，下单购买等功能。
管理系统中，要实现的功能包括：公司的内部人员及人员对应的权限的管理、公司产品库存的管理、公司财务的管理、公司推出的一些市场营销活动（比如：促销、广告等）的管理等。
自己在项目中负责的部分在小组完成该项目的工程中，组内进行了明确的分工，包括项目初期的分析、文档撰写及项目后期的开发测试过程。在小组中，我负责的部分为：项目初期的数据库分析、数据库设计文档的撰写和后期的测试工作。在数据库设计及相应文档撰写方面，我独立完成了数据库的初期设计和数据库设计文档的撰写，数据库文档总页数为11页。我所撰写的数据库设计文档被组内其他人和其他文档整合到一起，后来，实际的开发人员在此基础上进行了一部分的修改。在后期的开发过程中，我负责的部分为系统测试。具体负责的部分为：网上商城、库存管理、系统权限与安全这三个模块的测试工作。
网上商城部分，主要功能包括商品信息的浏览、购物车功能及下订单三大部分。
在编写的测试用例中，包括：
1. 商品信息展示测试：分别以游客及网上商城注册用户身份浏览商城，在商品类目中选择相应的商品信息，查看商品信息的显示是否存在问题。随机打开商品信息条目，查看商品的详细描述信息，查看商品详细信息页面是否能正常显示。
2. 购物车相关功能测试：购物车需要以注册用户身份登录才能正
常使用，游客无法正常使用购物车功能。购物车相关功能包括商品添加到购物车、购物车中浏览已添加的商品、将已添加的商品从购物车中删除、选择购物车中的商品提交订单。每个购物车的相关功能都编写了相应的测试用例。结果发现在网上商城的初期版本中，购物车无法正常删除已添加的商品信息，已作为bug提交给相应的开发人员。在后续的版本中，该bug已经被修复。
3. 由于订单功能设计支付等相关部分，开发人员未完全实现订单的相应功能。所以订单部分无法进行详细的测试。
库存管理部分，主要功能包括商品库存信息查看、出入库单的查看、出入库详情的查看、商品出入库及出入库单的审批。
编写的测试用例中，包括：
1. 商品库存信息的查看：以超级管理员或库存管理员的身份登录后台的管理系统，在库存中查看商品的库存详细信息。
2. 出入库单的查看：查看出入库单是否正确。
3. 商品出入库的测试：新建商品的出入库单，提交知否能否在出入库单中查看到且出入库单的商品信息、数量、出入库单的状态是否正确。
4. 出入库单的审批测试：在出入库单的审批界面中，允许某些出入库单的审批，不允许另一些出入库单的审批，然后在出入库单查看界面，查看审批的订单的状态是否发生改变。
系统角色权限及安全部分，主要的功能包括：新建角色、删除角色、角色权限的管理。测试用例包括：
1. 以超级管理员用户登录后台管理系统，建立新的角色并赋予相应的权限。
2. 以超级管理员身份登录，并删除某些已经存在的角色，看系统是否会产生某些级联的错误。
3. 角色权限的管理：为已存在的角色添加或删除某些权限。 经过测试，在我测试的模块中，只发现商品购物车无法正常删除已添加的商品，其他的功能都能正常使用。
经验总结
本次的实践让我学到了一些我之前不了解的东西。这次的软件工程实践，分工十分明确，有分工的职责也很细，我分到的岗位是软件测试。在此之前，对于软件测试，我只是听说过，却并没有真实地接触过。对于组长指派给我的编写测试用例，我完全不知道要怎么写，也不知道从何下手。后来，同样是负责测试用例的组里其他成员给我发了一份测试用例的文档，我以此为参照，结合自己负责的部分，才渐渐对于测试用例有了一个大致的认识。按照自己对于软件测试的理解，加上同学的测试用例示例，结合同学的指导，我才大致完成了测试用例文档的编写，也顺利的完成了对开发的销售管理系统的测试。 在这些测试用例的编写中，由于我对软件测试及测试用例的了解不深，难免存在一些问题，例如：不能很好的测试到系统中的一些功能，无法测试到一些会引发问题的情况等。
另外，在这次的软件工程实践里，也跟着整组人完整地经历了一遍软件开发的流程。之前的一些课程虽然也有涉及，但总的来说没有这么完整，时间跨度上也没有这么长。在这么课中，第一次接触到了软件开发小组中用到的周报，也学到了其他一些书本上没有的东西。
篇五：软件工程总结
软件的概念
很多人对于软件的理解并不准确，“软件就是程序，软件开发就是编程序”的这种错误观点仍然存在。 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。 程序是按事先设计的功能和性能要求执行的指令序列。
数据是使程序能正常操纵信息的数据结构。
文档是记录软件开发活动的阶段性成果、理解软件所必需的阐述性资料，如需求分析文档、软件设计文挡等 ，目的促进对软件的开发,管理和维护；便于各种人员(用户,开发人员)的交流。
软件的分类
按照软件的作用，一般可以将软件做如下分类。
(1) 系统软件
(2) 应用软件
(3) 支撑软件
(4) 可复用软件
综合上述，软件具有复杂性和易变性。
什么是软件工程
概括地说，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。
生存期的三个时期
软件定义：弄清软件“做什么” 软件定义时期可以划分成问题定义、可行性研究、需求分
析三个阶段，其中，最核心的是需求分析阶段，所以，软件定义时期的工作也就是常说的系统分析。 软件开发：集中解决软件“怎样做”概要设计、详细设计、软件实现和测试四个阶段。
软件维护：聚焦于软件的“修改/完善”
瀑布模型
优点
可强迫开发人员采用规范化的方法。
严格地规定了每个阶段必须提交的文档。
要求每个阶段交出的所有产品都必须是经过验证的。
缺点
瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。
瀑布模型只适用于项目开始时需求已确定的情况。
适用场合：瀑布模型的适用于预先确定型系统（瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。） 抛弃式原型模型特点
抛弃式原型模型建立原型的目的是，评价目标系统的某一个或某一些特性，以便更准确地确定需求，或者更严格地验证设计方案。使用完之后就把该原型系统抛弃掉，然后再重新构造正式的目标系统。
抛弃式原型模型本质上仍属于瀑布模型，建立原型系统只不过是“需求分析”和“有效性验证”的一种辅
助手段，需求分析阶段结束时原型系统的生存周期也就终止。
快速原型模型的特点、适用场合
特点：
用户积极参与
原型的开发没有严密的阶段性
短期获得测试版本，降低风险
适用场合：
需求含糊，用户不能标识出详细的输入、处理和输出需求
设计方案不明确，开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性
增量模型的特点和适用场合
特点：
以功能递增的方式进行软件开发
能较快地产生可操作的系统
在每一步递增中，都可以把用户/开发者的经验结合到不断求精的产品中
可改善测试效果和降低软件开发总成本
适用场合：
项目开始，明确了需求的大部分，但是需求可能会发生变化
对于市场和用户把握不是很准，需要逐步了解
对于有庞大和复杂功能的系统进行功能改进，本身就需要一步一步实施的
螺旋模型的特点和适用场合
特点：
风险驱动，在生命周期早期就开始确定项目中存在的风险
需要开发人员具有相当丰富的风险评估经验和专门知识
要求用户参与阶段评价，对用户要求较高
适用场合：
单位内部开发的大规模软件项目
风险是项目的主要制约因素
可能会发生重大变更
采用新技术
喷泉模型：主要用于面向对象技术的软件开发项目，它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，喷泉模型使开发过程具有迭代性和无间隙性。
喷泉模型以面向对象的软件开发方法为基础，以用户需求作为喷泉模型的源泉，属于面向对象的软件过程模型。
结构化方法的基本思想：从系统功能出发，自顶向下，按照层次逐步分解求精
数据流图 银行储蓄书P46—P48
结构化系统分析中加工逻辑说明的作用、三种表示形式及适用场合。（
结构化语言
判定表
判定树
三种基本语句：
祈使语句
判断语句
循环语句
结构化语言使用的三类词汇：
祈使句中的动词
数据字典中定义的名词
某些逻辑表达式中的保留字
结构化和面向对象两大方法的对比。
面向对象方法有如下优势：
与人类思维方式一致
各阶段过渡平滑
可维护性高、易于重用
生命力强
结构化方法：
容易理解和交流，对于大系统可以从全局逐步展开到局部，整体性较好。但工作费时过长，难以适应环境的急剧变化；对用户需求的变更不能做出迅速的响应；维护工作繁重。
面向对象：
稳定可靠，有利于维护和重用，并容易实现多层分布式结构，技术先进，但对前期分析设计人员要求较高，用户理解模型有困难。
C/S、B/S架构的特点、适用场合
C/S架构的缺点主要是部署、更新的问题。
B/S架构的缺点主要是受制于HTML的限制，无法像C/S那样使用丰富的效果来展示数据，用户体验比较糟糕。
状态图
用例规格说明，会画用例图
图书馆系统用例图
用例规格说明
用例名称 借出图书
参与者 图书管理员（主要参与者），读者（次要参与者）
假设 图书馆是开架借阅，读者总是找到书后办理借书手续，因此，借书不需要验证 库存，而且每本书都是可识别的。
前置条件 图书管理员已被识别和授权
后置条件 存储借书记录，更新库存数量，所借图书状态为出借
主事件流 1．图书管理员将读者借书卡提供给系统；
2．系统验证读者身份和借书条件；
3．图书管理员将读者所借图书输入系统；
4．系统记录借书信息，并且修改图书的状态和此种书的可借数量；
5．系统累加读者的借书数量；
6．重复3-5，直到图书管理员确认全部图书登记完毕；
7．系统打印借书清单，交易成功完成。
备选事件流 2a．非法读者
1．系统提示读者身份错误，用例结束
2b．读者借书数已达限额
1．系统提示读者已达结束限额，用例结束
2c．读者有过期未还书籍
1．系统提示读者应归还的书籍列表和到期日，用例结束
5a．读者借书数已达限额
1．系统提示，并要求结束输入
2．图书管理员确认借书完成
5b．读者有该书的预定记录
1. 删除该书的预定信息
结构化设计要求模块间的耦合程度尽可能小。
为此应：
用过程语句调用其他模块
模块间的参数作数据用
模块间的参数尽可能少
总原则：尽量使用数据耦合，少用控制耦合，限制公共耦合的使用范围，完全不用内容耦合。
结构化模块详细设计的建模工具
程序流程图（程序框图）
盒图（NS图）
PAD图（问题分析图）
程序设计语言（PDL）
面向对象方法的特点
对象、类、属性和操作
封装、隐藏
消息
继承
多态
关系
UML的构架—4+1视图中的具体内容。 略过
“购买商品”用例规格说明
参与者：出纳员（主）、顾客
目标：完成一次商品销售和支付
前置条件：管理员必须已经启动系统，出纳员必须已经登录到这个系统
后置条件：销售信息正确的记录到系统中
触发条件：顾客带着所要购买的商品来到一个POS机终端
主事件流（主成功场景/基本路径）：
出纳员将每项商品的信息录入系统
商品信息录入完毕后，系统计算商品价格总额
出纳员通知顾客商品总额
顾客支付现金，出纳员确认收取现金
【软件工程的总结】相关文章：
对老板总结感想总结二篇03-20
学科总结03-20
电场公式总结06-08
离校总结精选范文03-19
工会总结范本03-19
总结电热的作用12-09
FLASH教程总结01-20
香茅做法总结03-19
工会总结精选范文03-20