软件工程（Software Engineering）是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科，[1]它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等多方面。
现代社会，软件几乎应用于各个行业，如工业、农业、银行、航空、政府部门等，这些应用促进了经济和社会的发展，使得人们的工作效率和生活效率得以提高。典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。
中文名软件工程
授予学位工学学士
修业年限四年
学科门类工学
级别本科
专业类计算机类
专业代码80902
基本简介
软件工程一直以来都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己的定义。
BarryBoehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
IEEE：在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究
FritzBauer：在NATO会议上给出的定义：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
《计算机科学技术百科全书》：软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
ISO 9000对软件工程过程的定义是：软件工程过程是输入转化为输出的一组彼此相关的资源和活动。
主要内涵
一、软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四个方面：
1、P（Plan）：——软件规格说明。规定软件的功能及其运行时的限制。
2、D（DO）——软件开发。开发出满足规格说明的软件。
3、C（Check)——软件确认。确认开发的软件能够满足用户的需求。
4、A（Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。
二、从软件开发的观点看，它就是使用适当的资源（包括人员，软硬件资源，时间等），未开发软件进行的一组开发活动，在活动结束时输入（即用户的需求）转化为输出（最终符合用户需求的软件产品）。
三个阶段：定义阶段：可行性研究初步项目计划、需求分析；开发阶段：概要设计、详细设计、实现、测试；运行和维护阶段：运行、维护、废弃
原则：1、抽象；2、信息隐蔽；；3、模块化；4、局部化；5、确定性；6，一致性；7、完备性；8、可验证性
学科信息
软件工程是指导计算机软件开发和维护的工程学科。
采用工程的概念、原理、 技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够 得到的最好的技术方法结合起来，这就是软件工程。
软件工程强调使用生存周期方法学和各种结构分析及结构设计技术。它们是在七十年代为了对付应用软件日益增长的复杂程度、漫长的开发周期以及用户对软件产品经常不满意的状况而发展起来的。人类解决复杂问题时普遍采用的一个策略就是“各个击破”，也就是对问题进行分解然后再分别解决各个子问题的策略。软件工程采用的生存周期方法学就是从时间角度对软件开发和维
护的复杂问题进行分解，把软件生存的漫长周期依
次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。采用软件工程方法论开发软件的时候，从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发。
前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的物理细节。每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。在每一个阶段结束之前都必须进行正式严格的技术审查和管理复审，从技术和管理两方面对这个阶段的开发成果进行检查，通过之后这个阶段才算结束；如果检查通不过，则必须进行必要的返工，并且返工后还要再经过审查。审查的一条主要标准就是每个阶段都应该交出“最新式的”（即和所开发的软件完全一致的）高质量的文档资料，从而保证在软件开发工程结束时有一个完整准确的软件配置交付使用。文档是通信的工具，它们清楚准确地说明了到这个时候为止，关于该项工程已经知道了什么，同时确立了下一步工作的基础。此外，文档也起备忘录的作用，如果文档不完整，那么一定是某些工作忘记做了，在进入生存周期的下一阶段之前，必须补足这些遗漏的细节。在完成生存周期每个阶段的任务时，应该采用适合该阶段任务特点的系统化的技术方法──结构分析或结构设计技术。
把软件生存周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生存周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。总之，采用软件工程方法论可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。
划分软件生存周期阶段的方法有许多种，软件规模、种类、开发方式、开发环境以及开发时使用的方法论都影响软件生存周期阶段的划分。在划分软件生存周期的阶段时应该遵循的一条基本原则就是使各阶段的任务彼此间尽可能相对独立，同一阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程度，简化不同阶段之间的联系，有利于软件开发工程的组织管理。一般说来，软件生存周期由软件定义、软件开发和软件维护三个时期组成，每个时期又进一步划分成若干个阶段。下面的论述主要针对应用软件，对系统软件也基本适用。
软件定义时期的任务是确定软件开发工程必须完成的总目标；确定工程的可行性，导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成三个阶段，即问题
定义、可行性研究和需求分析。
开发时期具体设计和实现在前一个时期定义的软件，它通常由下述四个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。
维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
下面扼要介绍软件生存周期每个阶段的基本任务和结束标准。
１问题定义
问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。
通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。
问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。
２可行性研究
这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。
可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。
在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。
可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。
３需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。
用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。
在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，
然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。
４总体设计
这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”
首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库。通常至少应该考虑下述几类可能的方案：
低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。
中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。
高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。
系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。
上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的
结构，也就是确定程序由哪些模块组成以及模
块间的关系。通常用层次图或结构图描绘软件的结构。
５详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”
这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
通常用ＨＩＰＯ图（层次图加输入／处理／输出图）或ＰＤＬ语言（过程设计语言）描述详细设计的结果。
６编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。
７综合测试
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。
最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。
必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。
为了使用户能够积极参加验收测试，并且在系统投入生产性运行以
后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。
通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。
应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，做为软件配置的一个组成成分。
８软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。
通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。
虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件
定义和开发的全过程。
都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。
研究领域
软件工程与应用 Software Engineering andApplications 是一本关注计算机领域最新进展的国际中文期刊，由汉斯出版社发行。本刊支持思想创新、学术创新，倡导科学，繁荣学术，集学术性、思想性为一体，旨在为了给世界范围内的科学家、学者、科研人员提供一个传播、分享和讨论计算机领域内不同方向问题与发展的交流平台。
研究领域：
软件架构
软件设计方法
软件领域建模
软件工程决策支持
软件工程教育
软件测试技术
自动化的软件设计和合成
基于组件的软件工程
计算机支持的协同工作
编程语言和软件工程
计算机网络
信息与通信安全
计算机图形学与人机交互
多媒体技术应用
人工智能与识别
嵌入式软件与应用
自动控制
分布式计算与网格计算
云计算技术
存储技术
数据库技术研究
计算机辅助设计与应用技术
开发方法
软体工程的方法有很多方面的意义。包括专案管理，分析，设计，程序的编写，测试和质量控制。
软体设计方法可以区别为重量级的方法和轻量级的方法。重量级的方法中产生大量的正式文档。
著名的重量级开发方法包括IS
O9000，CMM，和统一软体开发过程（RUP）。
轻量级的开发过过程没有对大量正式文档的要求。着名的轻量级开发方法包括极限编程（XP）和敏捷流程（AgileProcesses）。
根据《新方法学》这篇文章的说法，重量级方法呈现的是一种防御型的姿态。在应用重量级方法的软体组织中，由于软体项目经理不参与或者很少参与程序设计，无法从细节上把握项目进度，因而会对项目产生恐惧感，不得不要求程式设计师不断撰写很多“软体开发文档”。而轻量级方法则呈现“进攻型”的姿态，这一点从XP方法特别强调的四个准则—“沟通、简单、反馈和勇气上有所体现。有一些人认为
，重量级方法合于大型的软体团队（数十人以上）使用，而“轻量级方法”适合小型的软体团队（几人、十几人）使用。当然，关于重量级方法和轻量级方法的优劣存在很多争论，而各种方法也在不断进化中。
一些方法论者认为人们在开发中应当严格遵循并且实施这些方法。但是一些人并不具有实施这些方法的条件。实际上，采用何种方法开发软体取决于很多因素，同时受到环境的制约。
发展过程
软件是由计算机程序和程序设计的概念发展演化而来的，是在程序和程序设计发展到一定规模并
且逐步商品化的过程中形成的。软件开发经历了程序设计阶段、软件设计阶段和软件工程阶段的演变过程。
程序设计阶段
程序设计阶段出现在1946年～1955年。此阶段的特点是：尚无软件的概念，程序设计主要围绕硬件进行开发，规模很小，工具简单，无明确分工（开发者和用户），程序设计追求节省空间和编程技巧，无文档资料（除程序清单外），主要用于科学计算。
软件设计阶段
软件设计阶段出现在1956年～1970年。此阶段的特点是：硬件环境相对稳定，出现了“软件作坊”的开发组织形式。开始广泛使用产品软件（可购买），从而建立了软件的概念。随着计算机技术的发展和计算机应用的日益普及，软件系统的规模越来越庞大，高级编程语言层出不穷，
应用领域不断拓宽，开发者和用户有
了明确的分工，社会对软件的需求量剧
增。但软件开发技术没有重大突破，软件产品的质量不高，生产效率低下，从而导致了“软件危机”的产生。
软件工程阶段
自1970年起，软件开发进入了软件工程阶段。由于“软件危机”的产生，迫使人们不得不研究、改变软件开发的技术手段和管理方法。从此软件产生进入了软件工程时代。此阶段的特定是：硬件已向巨型化、微型化、网络化和智能化四个方向发展，数据库技术已成熟并广泛应用，第三代、第四代语言出现；第一代软件技术：结构化程序设计在数值计算领域取得优异成绩；第二代软件技术：软件测试技术、方法、原理用于软件生产过程；第三代软件技术：处理需求定义技术用于软件需求分析和描述。
本质特性
虽然软件软件工程的不同定义使用了不同词句，强调的重点也有差异，但是，人们普遍认为软件工程有下述的本质特性：
（1）软件工程关注于大型程度的构造
“大”与“小”的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。传统的程序设计技术和工具是支持小型程序设计的，不
能简单地把这些技术和工具用于开发大型程序。
事实上，在此处使用术语“程序”并不十分恰当，现在的软件开发项目通常构造出包含若干个相关程序的“系统”。
（2）软件工程的中心课题是控制复杂性
通常，软件所解决的问题十分复杂，以致不能把问题作为一个整体通盘考虑。人们不得不把问题分解，是的分解出的每个部分是可理解的而且各部分之间保持简单的通信关系。用这种风发并不能见底问题的整体复杂性，但是却可使它变成可以管理的。注意，许多软件的复杂性主要不是由问题的内在复杂性造成的，而是由必须处理的大量细节造成的。
（3）软件经常变化
绝大多数软件都模拟了现实世界的某一部分，例如，处理读者对图书馆提出的需求或跟踪银行内钱的流通过程。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统教父使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能发生的变化。
（4）开发软件的效率非常重要
社会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。
（5）和谐地合作是开发软件的关键
软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。事实上仅有上述规定还不够，每个人还必须严格地按规定行事。为了迫使大家遵守规定，应该运用标准和规程。通常，可以用工具来支持这些标准和规程。总之，纪律是成功地完成软件开发项目的一个关键。
（6）软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。如果用户对软件系统不满意，可以启用该系统，或者立即提出新的需求。因此仅仅用正确的方法构造系统还不够，还必须构造出正确的系统。
有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求（例如，可靠性、响应时间等）。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料，此外，还必须注意建立使用新系统的环境。例如，一个新的图书馆自动化系统将影响图书馆的工作流程，因此应该适当地培训该用户，使他们习惯于新的工作流程。
（7）在软件工程领域中通常由具有一中文化背景的人替具有另一中文化背景的人创造产品
这个特性与前两个特性紧密相关。软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言（UML）等方面的专家，他们通常并不是图书馆管理、航空控制或银行事物等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。
软件工程师不仅缺乏应用领域的实际知识，他们还缺乏该领域的文化知识。例如，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现这个工作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程。对于局外人来说，这个问题更难回答。
基本目标
软件工程的目标是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，
减少维护的困难。
（1）适用性：软件在不同的系统约束条件下，使用户需求得到满足的难易程度。
（2）有效性：软件系统能最有效的利用计算机
的时间和空间资源。各种软件无不把系统的时/空开销作为衡量软件质量的一项重要技术指标。很多场合，在追求时间
有效性和空间有效性时会发生矛盾，这时不得不牺牲时间有效性换取空间有效性或牺牲空间有效性换取时间有效性。时/空折衷是经常采用的技巧。
（3）可修改性：允许对系统进行修改而不增加原系统的复杂性。它支持软件的调试和维护，是一个难以达到的目标。
（4）可靠性：能防止因概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因操作不当造成软件系统失效的能力。
（5）可理解性：系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制系统软件复杂性，并支持软件的维护、移植或重用。
（6）可维护性：软件交付使用后，能够对它进行修改，以改正潜伏的错误，改进性能和其它属性，使软件产品适应环境的变化等。软件维护费用在软件开发费用中占有很大的比重。可维护性是软件工程中一项十分重要的目标。
（7）可重用性：把概
念或功能相对独立的一个或一组相关模块定义为一个软部件。可组装在系统的任何位置，降低工作量。
（8）可移植性：软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。
（9）可追踪性：根据软件需求对软件设计、程序进行正向追踪，或根据软件设计、程序对软件需求的逆向追踪的能力。
（10）可互操作性：多个软件元素相互通信并协同完成任务的能力。
开发介绍
生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产
生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活
动贯
穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。
开发原则
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
软件工程的原则有以下四项基本原则：
选取适宜开发范型
该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其他因
素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。
采用合适的设计方法
在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。
提供高质量的工程支持
“工欲善其事，必先利其器”。
在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。
重视开发过程的管理
软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。
这一软件工程框架告诉我们，软件工程的目标是可用性、正确性和合算性；实施一个软件工程要选取适宜的开发范型，要采用合适的设计方法，要提供高质量的工程支撑，要实行开发过程的有效管理；软件工程活动主要包括需求、设计、实现、确认和支持等活动，每一活动可根据特定的软件工程，采用合适的开发范型、设计方法、支持过程以及过程管理。根据软件工程这一框架，软件工程学科的研究内容主要包括：软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。
开发方法
国外大的软件公司和机构一直在研究软件开发方法这个概念性的东西，而且也提出了很多实际的开发方法，比如：生命周期法、原型化方法、面向对象方法等等。下面介绍几种流行的开发方法：
结构化方法
结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的，即所谓的SASD 方 法， 也可称为面向功能的软件开发方法或面向数据流的软件开发方法。
Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）
方法进行总体设计，最后是结构化编程（SP
）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。
面向数据结构的软件开发方法
Jackson方法是最典型的面向数据结构的软件开发方法，Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构。三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。
面向问题的分析法
PAM（Problem Analysis Method）是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综 合。这一方法的具体步骤是
：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的PAD图。这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图
，是最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间同样存在着鸿沟，这一方法仍只适用于中小型问题。
原型化方法
产生原型化方法的原因很多，主要随着我们系统开发经验的增多，我们也发现并非所有的需求都能够预先定义而且反复修改是不可避免的。当然能够采用原型化方法是因为开发工具的快速发展，比如用VB，DELPHI等工具我们可以迅速的开发出一个可以让用户看的见、摸的着的系统框架，这样，对于计算机不是很
熟悉的用户就可以根据这个样板提出自己的需求。
开发工具
手机软件开发工具
1.Android SDK
Android是谷歌(Google)公司推出的手机开发平台。 与iPhone相似，Android采用WebKit浏览器引擎，具备触摸屏、高级图形显示和上网功能，用户能够在手机上查看电子邮件、搜索网址和观看视频节目等，比iPhone等其他手机更强调搜索功能，界面更强大
2.集成开发环境 Eclipse
Eclipse是著名的跨平台的自由集成开发环境（IDE）。最初主要用来Java语言开发，但是亦有人通过插件使其作为其他计算机语言比如C++和Python的开发工具。 Eclipse的本身只是一个框架平台，但是众多插件的支持使得Eclipse拥有其他功能相对固定的IDE软件
3.Android组件界面设计工具 DroidDraw
DroidDraw 是一个基于Java Swing的Android界面设计器，我们可以通过它来生成复杂的Android LayoutXML文件，据作者介绍，Android的Layout和Swing Layout中有很好的对应，设计器的代码编写起来还是比较容易的。 android下，高级组件，通过xml来配置，书写
4.NetBeans开发Android的插件
这是一款在 NetBeans 中开发 Android 平台应用的插件。
5.微软.NET for Android MonoDroid
微软.NET for Android，也就是MonoDroid，是Novell公司的MonoTouch项目在Android系统的开源实现，MonoDroid将马上进入 Beta测试阶段，最终的MonoDroid产品将在该年秋季发布——和Windows Phone 7基本在同一时间段。 Novell公司从开发者对MonoTouch的兴趣中。
研究原理
自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。美国著名的软件工程专家巴利·玻姆（Barry Boehm）综合这些专家的意见，并总结
了美国天合公司（TRW）多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。
玻姆认为，这七条原理是确保软件产品质量和开发效率的原理的最小集合。它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。
下面简要介绍软件工程的七条原理：
用分阶段的生命周期计划严格管理
这一条是吸取前人的教训而提出来的。统计表
明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。
玻姆认为，在整个软件生命周期中应指定并严格执行6类计划：
项目概要计划；
里程碑计划；
项目控制计划；
产品控制计划；
验证计划；
运行维护计划。
坚持进行阶段评审
统计结果显示：大部分错误是在编码之前造成的，大约占63%错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，
应坚持进行严格的阶段评审，以便尽早发现错误。
实行严格的产品控制
开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。
采纳现代程序设计技术
从六、七十年代的结构化软件开发技术，到面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大于气力。采用先进的技术既可以提高软件开发的效率，又可以减少软件维护的成本。
结果应能清楚地审查
软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。
开发小组的人员应少而精
开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。 这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多；当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。
承认不断改进软件工程实践的必要性
遵从上述六条基本原理，就能够较好地实现软件的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，玻姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。
工程需求
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，本文以医院管理系统为例详细介绍了需求工程的构成和进行方法。
首先人们必须了解需求工程和其他项目过程的关系：
软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求：业务需求说明了提供给客户和产品开发商的新系统的最初利益，反映了组织
机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明；用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方
案脚本说明中予以说明；功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
需求工程分为了需求开发和需求管理两个阶段：下面就以这两个阶段说明：
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。需求的获取和分析包括对原始需求变更控制，版本控制，从需求到产品和模块的可追溯性，成品交付和产品的状态跟踪。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
确定需求开发过程
确定需求开发过程确定如何组织需求的收集、分析、细化并核实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。
编写项目视图和范围文档
项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。
项目视图和范围文档的模板
a.1背景在这一部分，总结新产品的理论基础，并提供关于产品开发的历史背景或形势的一般性描述。
a、2业务机遇描述现存的市场机遇或正在解决的业务问题。描述商品竞争的市场和信息系统将运用的环境。包括对现存产品的一个简要的相对评价和解决方案，并指出所建议的产品为什么具有吸引力和它们所能带来的竞争优势。
a.3业务目标用一个定量和可测量的合理方法总结产品所带来的重要商业利润，把重点放在给业务的价值上。
a.4客户或市场需求描述一些典型客户的需求，包括不满足现有市场上的产品或信息系统的需求。提出客户所遇到的问题在新产品中将可能（或不可能）出现的阐述，提供客户怎样使用产品的例子。确定了产品所能运行的软、硬件平台。
a.5提供给客户的价值确定产品给客户带来的价值，并指明产品怎样满足客户的需要。
a.6业务风险总结开发（或不开发）该产品有关的主要业务风险，例如市场竞争、时间问题、用户的接受能力、实现的问题或对业务可能带来的消极影响。预测风险的严重性，指明你所能采取的减轻风险的措施。
b.1项目视图陈述编写一个总结长远目标和有关开发新产品目的的简要项目视图陈述。项目视图陈述将考虑权衡有不同需求客户的看法。它可能有点理想化，但必须以现有的或所期待的客户市场、企业框架、组织的战略方向和资源局限性为基础。
b.2主要特性包括新产品将提供的主要特性和用户性能的列表。强调的是区别于以往产品和竞争产品的特性。可以从用户需求和功能需求中得到这些特性。
b.3假设和依赖环境在构思项目和编写项目视图和范围文档时，要记录所作出的任何假设。通常一方所持的假设应与另一方不同。
c.1首次发行的范围总结首次发行的产品所具有的性能。描述了产品的质量特性，这些特性使产品可以为不同的客户群提供预期的成果。c.2随后发行的范围如果你想象一个周期性的产品演变过程，就要指明哪一个主要特性的开发将被延期，并期待随后版本发行的日期。
c.3局限性和专用性明确定义包括和不包括的特性和功能的界线是处
理范围设定和客户期望的一个途径。列出
风险承担者们期望的而你却不打算把它包括到产品中的特性和功能。
d.1客户概貌客户概述明确了这一产品的不同类型客户的一些本质的特点，以及目标市场部门和在这些部门中的不同客户的特征。
d.2项目的优先级一旦明确建立项目的优先级，风险承担者和项目的参与者就能把精力集中在一系列共同的目标上。达到这一目的的一个途径是考虑软件项目的五个方面：性能、质量、计划、成本和人员。e.产品成功的因素明确产品的成功是如何定义和测量的，并指明对产品的成功有巨大影响的几个因素。不仅要包括组织直接控制的范围内的事务，还要包括外部因素。如果可能，可建立测量的标准用于评价是否达到业务目标。用户群分类
产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业
务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。用户类不一定都指人，你可以把其它应用程序或系统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求
的情
况，要将可能使都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。选择产品代表
择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。建立核心队伍
建立起典型用户的核心队伍把同类产品或产品的先前版本用户代表召集起来，从他们那里收集产品的功能需求和非功能需求。这样的核心队伍
对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员通常没有决定权。确定
使用实例
让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需
求。
一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个使用实例是相关的用法说明的集合，并且一个说明是使用实例的例子。在描述时列出执行者和系统之间相互交互或对话的顺序。当这种对话结束时，执行者也达到了预期的目的。
对于一些复杂的使用实例，画出图形分析模型是有益的，这些模型包括数据流程图、实体关系图、状态转化图、对象类和联系图。
使用实例的描述并不向开发者提供他们所要开发的功能的细节。为了减少这种不确定性，需要把每一个使用实例叙述成详细的功能需求。每一个使用实例可引伸出多个功能需求，这将使执行者可以执行相关的任务；并且多个使用实例可能需要相同的功能需求。使用实例方法给需求获取带来的好处来自于该方法是以任务为中心和以用户为中心的观点。比起使用以功能为中心的方法，使用实例方法可以使用户更清楚地认识到新系统允许他们做什么。
每一个使用实例都描述了一个方法，用户可以利用这个方法与系统进行交互，从而达到特定的目标。使用实例可有效地捕捉大多数所期望的系统行为，但是你可能
有一些需求，这些需求与用户任务或其他执行者之间的交互没有特定的关系。这时你就需要一个独立的需求规格说明。召开应用程序开发联系会议
召开应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。分析用户工作流程
分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使
用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系
统就能达到他们的业务目标。确定质量属性
确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点，这会使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是
一种非功能需求。听取那些描述合理特性的意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义。检查问题报告
通过检查当前系统的问题报告来进一步完善需求客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。需求重用
跨项目重用需求如果客户要求的功能与已有的产品很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。
体系结构
软件体系结构表示了一个软件系统的高层结构，主要特点有：1）软件系统结构是一个高层
次上的抽象，它并不涉及具体的系统结构（比如B/S还是C/S），也不关心具体的实现。2）软件体系结构必须支持系统所要求的功能，在设计软件体系结构的时候，必须考虑系统的动态行为。3）在设计软件体系结构的时候，必须考虑有现有系统的兼容性、安全性和可靠性。同时
还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。
当前已经有一些关于规范化软件体系结构，比如：ISO的开放系统互联模型、X Window系统等等。软件系统的结构通常
被定义为两个部分：一个是计算部件。另一个就是部件之间的交互。如果把软件系统看成一幅图的话，计算部件就是其中的节点，而部件之间的交互就是节点之间的弧线。部件之间的连接可以被认为
是一种连接器，比如过程调用、事件广播、数据库查询等等。正确的体系结构设计是软件系统成功的关键。
软件需求
软件需求包括 3 个不同的层次――业务需求、用户需求和功能需求。
除此之外，每个系统还有各种非功能需求。
业务需求
业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什
么要开发一个系统，即组织希望达
到的目标。
使用前景和范围（ vision and scope ）文档来
记录业务
需求，这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market requirement ）文档。
用户需求
用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成
的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描
述了用户能使用系统
来做些什么。
功能需求
功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需
求有时也被称作行为需求（ behavioral requireme
nt ），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求
描述
是开发人员需要实现什么。
系统需求
系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规
则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的
质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
功能需求记录在软件需求规格说明（ S
RS ）中。 SRS 完整地描述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。
除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。
质量属性
质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
约束功能
约束（constraint）限制了开发人员设计和构
建系统时的选择范围。
专业设置
本专业是培养适应计算机应用学科的发展，特别是软件产业的发展，具备计算机软件的基
础理论、基本知识和基本技能，具有用软件工程的思想、方法和技术来分析、设计和实现计算机软件系统的能力，毕业后能在IT行业
、科研机构、企事业中从事计算机应用软件系统的开发和研制的高级软件工程技术人才。
培养原则
软件工程领域（管理信息化方向）工程硕士应掌握从事本工程领域坚实的基础理论和宽广的专业知识，了解当代信息管理技术发展前沿、应用前景和最新发展动态，能熟练地阅读本领域的外文资料，掌握解决信息管理问题的先进技术方法和现代技术手段；具有创新意识和独立承担软件工程技术管理或信息系统管理工
作的能力。
主要课程
主干学科：马克思主义理论、大学外语、高等数学、大学物理、物理实验、线性代数、概率论与数理统计、程序设计语言、数据结构、离散数学、操作系统、编译技术、软件工程概论、统一建模语言、软件体系结构、软件需求、软件项目管理该专业除了学习公共基础课外，还将系统学习离散数学、数据结构、算法分析、面向对象程序设计、现代操作系统、数据库原理与实现技术、编译原理、软件工程、软件项目管理、计算机安全等课程，根据学生的兴趣还可以选修一些其它选修课。
就业方向
本专业学生毕业后可以从事各级各类企事业单位的办公自动化处理、计算机安装与维护、网页制作、计算机网络和专业服务器的维护管理和开发工作、动态商务网站开发与管理、软件测试与开发及计算机相关设备的商品贸易等方面的有关工作。
行业需求
企业在招聘软件测试人员时主要看中应聘者的项目经验、逻辑思维能力、一定的技术能力和综合素质，而对学历、年龄、性别、工作经验等的要求较低，相对于IT行业其他职位而言，软件测试的入行更加容易。
开发模型
1.瀑布模型：瀑布模型是1970年Winston Royce提出的最早出现的软件开发模型。
2.渐增模型
3.演化模型
4.螺旋模型
5.喷泉模型
6.转换模型
7.智能模型
8.原型开发模型
软件学院
注：按照拼音字母顺序排名
1.北京大学 软件与微电子学院 2.北京工业大学 软件学院 3.北京航空航天大学 软件学院
4.北京交通大学 软件学院 5.北京理工大学 软件学院 6.北京邮电大学 软件学院
7.重庆大学 软件学院 8.大连理工大学 软件学院
9.电子科技大学 软件学院
10.东北大学 软件学院 11.东南大学 软件学院 12.复旦大学 软件学院
13.国防科技大学 软件学院 14.哈尔滨工业大学 软件学院 15.湖南大学 软件学院
16.华东师范大学 软件学院 17.华南理工大学 软件学院 18.华中科技大学 软件学院
19.吉林大学 软件学院 20.南京大学 软件学院 21.南开大学 软件学院
22.清华大学 软件学院 23.山东大学 软件学院 24.上海交通大学 软件学院
25.四川大学 软件学院 26.天津大学 软件学院 27.同济大学 软件学院
28.武汉大学 软件学院 29.西安电子科技大学 软件学院 30.西安交通大学 软件学院
31.西北工业大学 软件与微电子学院 32.厦门大学 软件学院 33.云南大学 软件学院
34.重庆正大软件学院 35.浙江大学 软件学院 36.中国科学技术大学 软件学院 37.中南大学 软件学院
38..中山大学 软件学院 39.电子科技大学中山学院40.哈尔滨工程大学软件学院（原哈军工）
开设院校
哈尔滨工程大学软件学院（原哈军工）
天津大学 南开大学天津师范大学 天津工业大学
天津理工大学 河北大学 黄河科技学院 北方民族大学 北京城市学院
集美大学 福建农林大学 安徽工业大学 哈尔滨学院
北华大学 内蒙古大学 内蒙古工业大学 天津农学院 浙江工商大学
苏州大学 南京信息工程大学 烟台大学 华北电力大学科技学院
南昌大学科学技术学院 武汉工业学院 武汉科技学院 天津财经大学
华北电力大学(保定)西南大学 哈尔滨工程大学 长春理工大学
中国石油大学 北京交通大学 中国地质大学(北京) 太原理工大学
华北电力大学 上海交通大学 复旦大学 同济大学
华东师范大学长沙学院 韩山师范学院 广东技术师范学院
华东理工大学 大连理工大学 大连民族学院 湖北经济
学院 东北大学
西安交通大学北京信息工程学院 天津城市建设学院 临沂师范学院
北京航空航天大学 中山大学 北京理工大学 北京工业大学
上海第二工业大学 北京邮电大学 大连海事大学 北京工商大学
大连交通大学 中南大学 广西民族大学 北京信息科技大学
大连民族学院辽宁工程技术大学 北京电子科技学院 鞍山科技大学
山东大学东华大学 辽宁工学院 重庆大学 常熟理工学院
重庆邮电大学 沈阳航空工业学院 咸宁学院 华中科技大学
西南交通大学 成都理工大学 南京大学 四川师范大学 河北工业大学
西南石油大学 西南科技大学 河北农业大学 江西师范大学
西华大学 杭州电子科技大学 四川理工学院 成都信息工程学院
重庆工学院 电子科技大学中山学院 北京化工大学北方学院
安徽大学 宁夏大学 湖北工业大学 湖北工业大学工程技术学院 南华大学 天津科技大学
长安大学 桂林电子科技大学 电子科技大学 武汉科技大学
湖北汽车工业学院科技学院 河北科技大学 中原工学院 浙江大学
浙江工业大学 东南大学 南京理工大学 惠州学院 中国地质大学
复旦大学太平洋金融学院 江苏大学 河北科技大学理工学院
西南师范大学 南京邮电大学 黄冈师范学院 南昌大学
江西财经大学 南昌航空工业学院 华东交通大学 重庆三峡学院
江西农业大学 东华理工学院 西南民族大学 厦门大学 新疆大学
福建师范大学 华侨大学 吉林大学 闽江学院 西北工业大学
长春大学 西安电子科技大学 西北大学 云南大学 青岛大学
湖南大学中北大学 江西理工大学 西安理工大学 东北师范大学
西安科技大学 西安石油大学 暨南大学 西安工业大学 华南农业大学
广州大学 五邑大学 西安邮电学院 东莞理工学院 华南理工大学
哈尔滨工业大学黑龙江大学 泰山学院 黑龙江工程学院
华南师范大学 哈尔滨理工大学 集美大学城毅学院 广东工业大学
深圳大学 广东外语外贸大学 广东商学院 韶关学院 成都学院
澳门大学 山东大学威海分校 东华理工大学 首都师范大学
南昌航空大学 首都师范大学科德学院 东北大学东软信息学院
南京邮电大学通达学院 北京理工大学珠海学院 厦门大学嘉庚学院
中国石油大学(北京) 中国石油大学(华东)沈阳理工大学应用
技术学院
天津城市建筑学院上海电机学院 杭州师范大学 内蒙古农业大学
辽宁科技大学 南阳理工学院 黄淮学院 北京师范大学珠海分校
西安文理学院 西安工业大学北方信息工程学院 河北师范大学
鞍山科技大学信息技术学院 四川大学锦江学院 武汉理工大学
西安电子科技大学长安学院 山西大学 中南民族大学 武汉大学
海南大学三亚学院 四川大学 南通大学 福州大学 清华大学 曲阜师范大学
辽宁对外经贸学院 河南科技大学 河南师范大学 郑州大学 河南大学
北京航空航天大学北海学院湘潭大学 软件学院
出版图书
全书共分为四篇，分别讲解了如下知识点：软件工程与需求分析，软件设计方法与技术，软件编码、测试与维护，软件工程项目管理等基本理论和相关技术。本书是按照教育部高等学校计算机科学与技术专业教学指导分委员会颁布的《高等学校计算机科学与技术专业发展战略研究报告暨专业规范（试行）》中“软件
工程”课程教学大纲的要求编写而成的，适合作为高等学校计算机和相关专业软件工程课程的教材，也可作为软件
开发人员与软件项目管理人员的学习参考书。
第一篇 软件工程与需求分析
第1章 软件工程概述
第2章 软件项目可行性分析
第3章软件需求分析
第4章 软件开发工具与环境
第二篇 软件设计的方法与技术
第5章 软件设计方法概述
第6章 软件的总体设计与详细设计
第7章 结构化开发方法
第8章 面向对象的开发方法
第9章 人机交互界面设计
第10章软件重用技术
第三篇 软件编码、测试与维护
第11章 软件编码
第12章 软件测试
第13章 软件维护
第四篇 软件工程项目管理
第14章 软件项目组织与人力资源管理
第15章软件项目计划与进度控制
第16章软件质量管理
第17章软件配置管理
第18章软件项目风险管理
媒体推荐
计算机专业图书在不同领域都有双峰峙立的情形，软件工程类综述性的巨著也有两本：第一本就是Roger Pressman所著的《软件工程：实践者的研究方法》，另一本就是Ian Sommerville所著的本书。这两本书名著都有多年历史（初版可追溯到20世纪80年代早期），对于软件工程学科的形成，尤其是在教育界和学术界影响极大。相比Pressman的书，Sommerville的这本教材将全部内容划分为四个部分，每个部分可以单独使用或者是结合其他部分作为软件工程课程的基本内容，更加适合不同类型软件工程课程的教学需求，叙述也更趋
清晰和简明。
——摘自业界专业人士的推荐
这本软件工程的经典教材不仅展现了软件工程的广阔视野，还着重阐述了在开发大型系统中一些广泛采用的技术，并辅以大量的例子和图解；而且作者将所有的话题控制在适度的篇幅，用简练到位的文字把最重要的内容呈现给读者，并提供进一步阅读资料，供有兴趣的读者深入学习，使得本书更符合国内软件工程课程的教学需求。书中没有学院派布道式的说教，作者认为并不存在解决软件工程问题的灵丹妙药，而是强调读者需要学习和掌握更广泛的技术和工具以解决软件工程问题。从内容选材上，本书不落俗套，大胆舍弃了传统的软件工程内容和一些繁琐的软件工程理论，代之以简洁实用的软件工程新知识、新方法，增加了教材的实用性和可读性；从专题安排上，本书避虚就实，没有对软件工程的技术泛泛而谈，而是针对那些大型系统开发技术进行分析，避免了对个别产品中的技术进行过多阐述。
图书目录
中文版
出版者的话
译者序
前言
第一部分软件工程导论
第1章概述
11专业化软件开发
111软件工程
112软件工程的多样性
113软件工程和Web
12软件工程人员的职业道德
13案例研究
131胰岛素泵控制系统
132用于心理健康治疗的患者信息系统
133野外气象站
要点
进一步阅读材料
练习
参考书目
第2章软件过程
21软件过程模型
211瀑布模型
212增量式开发
213面向复用的软件工程
22过程活动
221软件描述
222软件设计和实现
223软件有效性验证
224软件进化
23应对变更
231原型构造
232增量式交付
233Boehm的螺旋模型
24Rational统一过程
要点
进一步阅读材料
练习
参考书目
第3章敏捷软件开发
31敏捷方法
32计划驱动开发和敏捷开发
33极限编程
331极限编程中的测试
332结对编程
34敏捷项目管理
35可扩展的敏捷方法
要点
进一步阅读材料
练习
参考书目
第4章需求工程
41功能需求和非功能需求
411功能需求
412非功能需求
42软件需求文档
43需求描述
431自然语言描述
432结构化描述
44需求工程过程
45需求导出和分析
451需求发现
452采访
453脚本
454用例
455深入实际
46需求有效性验证
47需求管理
471需求管理规划
472需求变更管理
要点
进一步阅读材料
练习
参考书目
第5章系统建模
51上下文模型
52交互模型
521用例建模
522时序图
53结构模型
531类图
532泛化
533聚合
54行为模型
541数据驱动的建模
542事件驱动模型
55模型驱动工程
551模型驱动体系结构
552可执行UML
要点
进一步阅读材料
练习
参考书目
第6章体系结构设计
61体系结构设计决策
62体系结构视图
63体系结构模式
631分层体系结构
632容器体系结构
633客户机-服务器体系结构
634管道和过滤器体系结构
64应用体系结构
641事务处理系统
642信息系统
643语言处理系统
要点
进一步阅读材料
练习
参考书目
第7章设计与实现
71利用UML进行面向对象设计
711系统上下文与交互
712体系结构的设计
713对象类识别
714设计模型
715接口描述
72设计模式
73实现问题
731复用
732配置管理
733宿主机-目标机开发
74开源开发
要点
进一步阅读材料
练习
参考书目
第8章软件测试
81开发测试
811单元测试
812选择单元测试案例
813组件测试
814系统测试
测试驱动开发
83发布测试
831基于需求的测试
832情景测试
833性能测试
84用户测试
要点
进一步阅读材料
练习
参考书目
第9章软件进化
91进化过程
92程序进化的动态特性
93软件维护
931维护预测
932软件再工程
933通过重构进行预防性维护
94遗留系统管理
要点
进一步阅读材料
练习
参考书目
第二部分可依赖性和信息安全性
第10章社会技术系统
101复杂系统
1011系统总体特性
1012系统非确定性
1013成功标准
102系统工程
103系统采购
104系统开发
105系统运行
1051人为错误
1052系统进化
要点
进一步阅读材料
练习
参考书目
第11章可依赖性与信息安全性
111可依赖性特征
112可用性和可靠性
113安全性
114信息安全性
要点
进一步阅读材料
练习
参考书目
第12章可依赖性与信息安全性描述
121风险驱动的需求描述
122安全性描述
1221危险识别
1222危险评估
1223危险分析
1224风险降低
123可靠性描述
1231可靠性度量
1232非功能性的可靠性需求
1233功能可靠性描述
124信息安全性描述
125形式化描述
要点
进一步阅读材料
练习
参考书目
第13章可依赖性工程
131冗余性和多样性
132可依赖的过程
133可依赖的系统体系结构
1331保护性系统
1332自监控系统体系结构
1333N-版本编程
1334软件多样性
134可依赖的编程
要点
进一步阅读材料
练习
参考书目
第14章信息安全工程
141信息安全风险管理
1411生存期风险评估
1412运行风险评估
142面向信息安全的设计
1421体系结构设计
1422设计准则
1423部署设计
143系统生存能力
要点
进一步阅读材料
练习
参考书目
第15章可依赖性与信息安全保证
151静态分析
1511检验和形式化方法
1512模型检测
1513自动静态分析
152可靠性测试
153信息安全性测试
154过程保证
155安全性和可依赖性案例
1551结构化论证
1552结构化的安全性论证
要点
进一步阅读材料
练习
参考书目
第三部分高级软件工程
第16章软件复用
161复用概览
162应用框架
163软件产品线
164COTS产品的复用
1641COTS解决方案系统
1642COTS集成系统
要点
进一步阅读材料
练习
参考书目
第17章基于组件的软件工程
171组件和组件模型
172CBSE过程
1721面向复用的CBSE
1722基于复用的CBSE
173组件合成
要点
进一步阅读材料
练习
参考书目
第18章分布式软件工程
181分布式系统的问题
1811交互模型
1812中间件
182客户机-服务器计算
183分布式系统的体系结构模式
1831主从体系结构
1832两层客户机-服务器结构
1833多层客户机-服务器结构
1834分布式组件体系结构
1835对等体系结构
184软件作为服务
要点
进一步阅读材料
练习
参考书目
第19章面向服务的体系结构
191服务作为可复用的组件
192服务工程
1921可选服务的识别
1922服务接口设计
1923服务实现和部署
1924遗留系统服务
193使用服务的软件开发
1931工作流设计和实现
1932服务测试
要点
进一步阅读材料
练习
参考书目
第20章嵌入式软件
201嵌入式系统设计
2011实时系统建模
2012实时编程
202体系结构模式
2021观察和反应
2022环境控制
2023处理管道
203时序分析
204实时操作系统
要点
进一步阅读材料
练习
参考书目
第21章面向方面的软件工程
211关注点分离
212方面、连接点和切入点
213采用方面的软件工程
2131面向关注点的需求工程
2132面向方面的设计和编程
2133检验和有效性验证
要点
进一步阅读材料
练习
参考书目
第四部分软件 管理
第22章项目管理
221风险管理
2211风险识别
2212风险分析
2213风险规划
2214风险监控
222人员管理
223团队协作
2231成员挑选
2232小组的结构
2233小组的沟通
要点
进一步阅读材料
练习
参考书目
第23章项目规划
231软件报价
232计划驱动的开发
2321项目计划
2322规划过程
233项目进度安排
234敏捷规划
235估算技术
2351算法成本建模
2352COCOMO Ⅱ模型
2353项目的工期和人员配备
要点
进一步阅读材料
练习
参考书目
第24章质量管理
241软件质量
242软件标准
243复查与审查
2431复查过程
2432程序审查
244软件度量和量度
2441产品量度
2442软件组件分析
2443度量歧义
要点
进一步阅读材料
练习
参考书目
第25章配置管理
251变更管理
252版本管理
253系统构建
254发布版本管理
要点
进一步阅读材料
练习
参考书目
第26章过程改善
261过程改善过程
262过程度量
263过程分析
264过程变更
265CMMI过程改善框架
2651分阶段的CMMI模型
2652连续CMMI模型
要点
进一步阅读材料
练习
参考书目
术语表
英文版
CONTENTS
Preface v
Part 1 Introduction to Software Engineering 1
Chapter 1 Introduction 3
1．1 Professional software development 5
1．2 Software engineering ethics 14
1．3 Case studies 17
Chapter 2 Software processes 27
2．1 Software process models 29
2.2 Processactivities 36
2．3 Coping with change 43
2．4 The rational unified process 50
Chapter 3 Agile software development 56
3．1 Agile methods 58
3．2 Plan-driven and agile development 62
3．3 Extreme programming 64
3．4 Agile project management 72
3．5 Scaling agile methods 74
Chapter 4 Requirements engineering 82
4．1 Functional and non-functional requirements 84
4．2 The software requirements document 91
4．3 Requirements specification 94
4．4 Requirements engineering processes 99
4．5 Requirements elicitation and analysis 100
4．6 Requirements validation 110
4．7 Requirements management 111
Chapter 5 System modeling 118
5．1 Context models 121
5．2 Interaction models 124
5．3 Structural models 129
5．4 Behavioral models 133
5．5 Model-driven engineering 138
Chapter 6 Architectural design 147
6．1 Architectural designdecisions 151
6．2 Architectural views 153
6．3 Architectural patterns 155
6．4 Application architectures 164
Chapter 7 Design and implementation 176
7．1 Object-oriented design using the UML 178
7．2 Design patterns 189
7．3 Implementation issues 193
7．4 Open source development 198
Chapter 8 Software testing 205
8．1 Development testing 210
8．2 Test-driven development 221
8．3 Release testing 224
8．4 User testing 228
Chapter 9 Softwareevolution 234
9．1 Evolution processes 237
9．2 Program evolution dynamics 240
9．3 Software maintenance 242
9．4 Legacy system management 252
Part 2 Dependability and Security 261
Chapter 10 Sociotechnical systems 263
10．1 Complex systems 266
10．2 Systems engineering 273
10．3 Systemprocurement 275
10．4 System development 278
10．5 Systemoperation 281
Chapter 11 Dependability and security 289
11．1 Dependability properties 291
11．2 Availability andreliability 295
11．3 Safety 299
11．4 Security 302
Chapter 12 Dependability and security specification 309
12．1 Risk-driven requirements specification 311
12．2 Safety specification 313
12．3 Reliability specification 320
12．4 Security specification 329
12．5 Formal specification 333
Chapter 13 Dependability engineering 341
13．1 Redundancy and diversity 343
13．2 Dependable processes 345
13．3 Dependable system architectures 348
13．4 Dependable programming 355
Chapter 14 Security engineering 366
14．1 Security risk management 369
14．2 Design for security 375
14．3 System survivability 386
Chapter 15 Dependability and security assurance 393
15．1 Static analysis 395
15．2 Reliability testing 401
15．3 Security testing 404
15．4 Process assurance 406
15．5 Safety and dependability cases 410
Part 3 Advanced Software Engineering 423
Chapter 16 Software reuse 425
16．1 The reuselandscape 428
16．2 Application frameworks 431
16．3 Software product lines 434
16．4 COTS product reuse 440
Chapter 17Component-based software engineering 452
17．1 Components and component models 455
17．2 CBSE processes 461
17．3 Component composition 468
Chapter 18 Distributed software engineering 479
18．1 Distributed systems issues 481
18．2 Client–servercomputing 488
18．3 Architectural patterns for distributed systems 490
18．4 Software as a service 501
Chapter 19 Service-orientedarchitecture 508
19．1 Services as reusable components 514
19．2 Service engineering 518
19．3 Software development with services 527
Chapter 20 Embedded software 537
20．1 Embedded systems design 540
20．2 Architectural patterns 547
20．3 Timing analysis 554
20．4 Real-time operating systems 558
Chapter 21 Aspect-oriented software engineering 565
21．1 The separation of concerns 567
21．2 Aspects, join points and pointcuts 571
21．3 Software engineering with aspects 576
Part 4 Software Management 591
Chapter 22 Project management 593
22．1 Risk management 595
22．2 Managing people 602
22．3 Teamwork 607
Chapter 23 Project planning 618
23．1 Software pricing 621
23．2 Plan-driven development 623
23．3 Project scheduling 626
23．4 Agile planning 631
23．5 Estimation techniques 633
Chapter 24 Quality management 651
24．1 Software quality 655
24．2 Software standards 657
24．3 Reviews and inspections 663
24．4 Software measurement and metrics 668
Chapter 25 Configuration management 681
25．1 Change management 685
25．2 Version management 690
25．3 System building 693
25．4 Release management 699
Chapter 26 Process improvement 705
26．1 The process improvement process 708
26．2 Process measurement 711
26．3 Process analysis 715
26．4 Process change 718
26．5 The CMMI process improvementframework 721
Glossary 733
Subject Index 749
Author Index 767
相关推荐
最新文章