软件工程年终总结

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