前言
软件工程在我整个大学的课程里是选修课，学的是电子工业出版社的《软件工厂--方法与实践 第2版》
软件工程呢，我觉得是一门很需要实践的学科，光靠这样简单地靠老师讲或者看看书是学不到什么东西的。软件工程涉及到很多内容，其中软件项目管理也包括了。概念性东西很多，一些专业术语和名词在整个软件工程中也频繁地出现了。其中近些年比较火的技术领域，面向服务的软件架构和云计算。云计算这个名词，我想IT界的从业人员并不陌生，已经不是什么新鲜东西，不过近些年确实是被捧得水深火热了，我都想尽快涉足这个领域当中去。因为这就是趋势，云服务、云存储等改变了软件行业的格局，对传统的软件开发商是一个很大的冲击，我想会有越来越多的软件开发商会提供这样的服务。原因很简单，它是一个双赢的模式。不过这也是我浅薄的看法，关于云计算并不是简单就能说清楚的东西，我觉得它是技术上的创新，它能给人类带来很多的好处。
当然，这个世界上没有完全完美的东西，双面性在云计算也有体现，云计算为我们节省了成本，节约了劳动力，那么也会丧失一些就业机会，我也不清楚中国现在的格局是怎样。还有就是，云计算是一个绝对安全的东西么，我们把所有的数据都放在云中，集中在一起真的没问题么。关于隐私问题，现在的我们随时随地都可以被一些云计算公司搜集到信息，在网上可以很轻易找到一个人各种信息，包括很多我们不希望被别人知道的信息。这又如何解决呢。总之，好东西都是需要经过锤炼的，不过我相信云计算肯定是利大于弊的东西，我很期待未来的信息化世界。
软件工程知识点总结
有以下知识点（考试内容，当然不止这些）
1. 软件工程的定义
2. 软件生存周期
3. 软件过程模型
4. 需求分析的定义、获取
5. 常见的软件体系结构（B/S 、C/S 、软件总线中间件）
6. SOA 的定义、特点、和工作模型（松耦合、明确定义的接口）
7. 云计算的定义、优势和应用模型
8. 软件测试的概念、原则、方法和测试策略
9. 软件维护的类型
10. 软件项目管理的管理过程和领域
11. 成本估算模型、进度计划的方法
12. 风险管理、质量管理的概念
13. CMM（软件能力成熟度模型）
第一章
1. 软件工程的定义：（P3）
软件工程是一门指导软件开发的工程学科，它以计算机理论及其他相关学科的理论为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经实践证明的科学的管理措施与最先进的技术方法结合起来。软件工程研究的目标是“以较少的投资获取高质量的软件”。
2. 软件生存期（P5）
软件生命周期（SDLD）是指一个从用户需求开始，经过开发、交付使用，在使用中不断地增补修订，直至软件报废的全过程，亦称软件生存期（Life Cycle）。
软件生命周期分为以下阶段：
①可行性研究和项目开发计划。该阶段必须要回答的问题是“要解决的问题是什么”。
②需求分析。该阶段的任务不是具体地解决问题，而是准确地确定“软件系统必须做什么”，确定软件系统必须具备哪些功能。
③概要设计。概要设计就是设计软件的结构，该结构由哪些模块组成，这些模块的层次结构是怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系等。
④详细设计。即对每个模块完成的功能进行具体描述，要把功能描述变为精确的、结构化的过程描述。
⑤编码。该阶段把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某特定程序设计语言表示的“源程序”。
⑥测试。它是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。测试分为，模块测试、组装测试、确认测试等。
⑦维护。软件维护是软件生存期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。
在大部分文献中将生存期划分为5个阶段，即 要求定义、设计、编码、测试及维护。其中 要求定义阶段包括可行性研究和项目开发计划及需求分析，设计阶段包括概要设计和详细设计。
为了描述软件生存期的活动，提出了多种生存期模型，如瀑布模型、循坏模型、螺旋模型、喷泉模型、智能模型等。
3. 目前常见的软件过程模型如下：瀑布模型、增量模型、螺旋模型、喷泉模型、智能模型等。
1) 瀑布模型
优点：在软件工程的第一阶段，瀑布模型得到了广泛的应用，它简单易用，在消除非结构化软件，降低软件的复杂性，促进软件开发工程化方面起了很大的作用。
缺点：由于瀑布模型是一种理想的线性开发模式，它将一个充满回溯的软件开发过程硬性分割为几个阶段，无法解决软件需求不明确或者变动的问题。这些缺点对软件开发带来了严重影响，由于需求不明确，会导致开发的软件不符合用户的需求而夭折。
2) 增量模型(incremental model)
- 增量模型是一种非整体开发的模型。是一种进化式的开发过程。
- 根据增量的方式和形式的不同，分为：
- 基于瀑布模型的渐增模型
- 基于原型的快速原型模型
该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
增量模型和瀑布模型之间的本质区别是什么？
增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产生工作软件。
一般的增量模型如下：
3)螺旋模型
对大型软件,需要多个原型描述系统的生存期，螺旋模型将瀑布模型与原型化模型结合起来,并加入了风险分析。
该模型将开发过程分为几个螺旋周期，每个螺旋周期可分为4个工作步骤：
①制定计划：确定目标、方案和限制条件；
②风险分析：评估方案、标识风险和解决风险；
③实施工程：开发确认产品；
④客户评估：计划下一周期工作。
一般的螺旋模型如下图：沿着螺旋线每转一圈，表示开发出一个更完善的新的软件版本。如果开发风险过大，开发机构和客户无法接受，项目有可能就此中止；多数情况下，会沿着螺旋线继续下去，自内向外逐步延伸，最终得到满意的软件产品。
4) 喷泉模型
喷泉模型以面向对象的软件开发方法为基础，以用户需求作为喷泉模型的源泉。如下图：
6. 喷泉模型是对象驱动的过程，对象是所有活动作用的实体，也是项目管理的基本内容。
7. 喷泉模型在实现时，由于活动不同，可分为系统实现和对象实现，这既反映了全系统的开发过程，也反映了对象族的开发和重用过程
5）智能模型
智能模型也称为基于知识的软件开发模型，是知识工程与软件工程在开发模型上结合的产物，以瀑布模型与专家系统的综合应用为基础建立的模型，该模型通过应用系统的知识和规则帮组设计者认识一个特定的软件的需求和设计，这些专家系统已成为开发过程的伙伴，并指导开发过程。
从图中可以清楚地看到，智能模型与其他模型不同，它的维护并不在程序一级上进行，这样就把问题的复杂性大大降低了。
智能模型的主要优点有：
① 通过领域的专家系统，可使需求说明更加完整、准确和无二义性。
② 通过软件工程的专家系统，提供一个设计库支持，在开发过程中成为设计的助手。
③ 通过软件工程知识和特定应用领域的知识和规则的应用来提供开发的帮助。
但是，要建立合适于软件设计的专家系统，或建立一个既适合软件工程由适合应用领域的知识库都是非常困难的。目前，在软件开发中正在使用AI技术，并已取得局部进展；例如在CASE工具系统中使用专家系统，又如使用专家系统实现测试自动化。
第二章
1.需求分析的定义
在传统软件工程生命周期中，涉及软件需求的阶段称做需求分析。
2.需求工程的定义
需求工程是一个包括创新和维护系统需求文档所必须的一切活动，是对系统应该提供的服务和所受到的约束进行理解、分析、检验和建立文档的过程。
3. 需求的获取和分析
需求的获取和分析是需求工程的关键和核心步骤，直接影响到后期的开发工作和系统的成败。
·需求获取
在深入实际调查研究，充分理解用户需求的基础上，获取系统需求。获取过程为：
①了解领域知识，工程技术人员需要依靠领域专家，学习和理解相关的专业知识，才能正确抽取用户需求。
②需求收集，与项目相关人员进行沟通，在进一步了解专业领域的基础上，发现系统需求的过程。
·需求分析
需求分析的过程是对收集到的需求进行提炼、分析和审查的过程，最终确定需求，并确保所有项目相关人员对需求取得一致性认识。分析阶段的主要工作包括：
①确定系统范围。确定系统与其他外部实体或其他系统的边界和接口。
②分类排序。对所收集的需求进行重新组织、整理、分类和筛选，并对每类需求进行排序，确定哪些是最重要的需求。
③建立需求分析模型。这是分析阶段的核心工作。需求分析模型是对需求的主要描述手段，是根据不同的分析方法建立的各种视图，例如数据流图（DFD）、实体关系图（E-R）、用例图（Use Case）、类图、状态图、各种交互图等。还可建立辅助的说明，如数据词典。
④建立需求规格说明。软件需求规格说明（Software Requirement Specification,SRS）是将需求的结果按照不同开发方法规定的格式用图形和文档形式描述出来。需求规格说明在整个开发过程中具有很重要的作用，是用户和开发人员之间进行交流和理解系统的手段。用户通过需求规格说明检查是否符合和满足所提出的全部需求。开发者则通过需求规格文档，了解和理解所开发系统的内容，并以此作为软件设计和软件测试的依据。项目管理人员以它为依据，规划软件开发过程、计划，估算软件成本和控制需求的变更过程。
第三章
·软件体系结构设计
仓库模型（The repository model）
也称“容器模型 ”，是一种集中式的模型。在这种结构模型当中，应用系统用一个中央数据仓库来存储各个子系统共享的数据，其它的子系统可以直接访问这些共享数据。当然，每个子系统可能会有自己的数据库。为了共享数据，所有的子系统之间紧密耦合的，并且围绕中央数据仓库，如下图：
仓库模型的主要优点：
①数据由一个子系统产生，并且被另外一些子系统共享；
②共享数据能得到有效的管理，各子系统之间不需要通过复杂的机制来传递共享数据。
③一个子系统不必关心其他的子系统是如何使用它产生的数据的。
④所有的子系统都拥有一致的基于中央数据仓库的数据视图。如果新子系统也采用相同的规范，则将它集成与系统中是容易的。
仓库模型的主要缺点：
①为了共享数据 ,各子系统必须有一致的数据视图 ，不可避免地会影响了整个系统的性能。
②一个子系统发生了改变，它产生的数据结构也可能发生改变。为了其他共享的目的，数据翻译系统会被用到。但这种翻译的代价是很高的，并且有时是不可能完成的。
③中央数据仓库和各子系统拥有的数据库必须有相同的关于备份、安全、访问控制和恢复的策略，这可能会影响子系统的效率。
④集中式的控制使数据和子系统的分布变得非常困难甚至成为不可能。这里分布指的是将数据或子系统分散到不同的机器上。
一般来说，命令控制系统、CAD系统等常采用这种结构。
分布式结构
分布式结构有如下一些优势：
①资源共享：系统中每个服务结点上的资源都可以被系统中的其他结点访问。
②开放性高：系统可以方便地增删不同软、硬件结构的结点。
③可伸缩性好：系统可以方便的增删新的服务资源以满足需要。
④容错能力强：分布式系统中的信息冗余可以容忍一定程度的软、硬件故障。
⑤透明性高：系统中的结点一般只需知道服务的位置而不必清楚系统的结构。
分布式结构有如下一些不足：
①复杂性：分布式系统比集中式系统要复杂的多。集中式系统的性能主要依赖于主机的处理能力，而分布式系统的性能则还要依赖于网络的带宽，这让情况变得更加复杂。
②安全性：网络环境随时面临着各种威胁，如病毒、恶意代码、非法访问等，如何保证安全性是一个让人头痛的问题。
③可管理性：分布式系统的开放性造成了系统的异构性，显而易见，管理异构的系统比管理主机系统要困难得多。
④不可预知性：这主要指系统的响应时间。网络环境本身的特点决定了网络负载会明显地影响整个系统的响应时间。
下面主要讨论几种不同的分布式结构.
1)客户-服务器模型（Client/Server Architectural Model）
客户-服务器结构（Client/ServerArchitecture）是一种典型的分布式结构。典型的客户-服务器C/S 结构的系统包括三个组成部分：
①服务器（Server）:多个独立的服务器为系统提供诸如Web、文件共享、打印等服务。
②客户（Client）:多个并发客户应用访问多个服务器提供的服务，每个客户应用都是独立的同样的客户应用可以同时有多个实例。
③网络（Network）:客户和服务器通过网络连接在一起。这是C/S结构的常用模式。有时客户应用和服务器应用会在同一台机器上运行，但两个应用还是要通过本机的网络协议进行通信，其效果就像在不同的机器上运行一样。
C/S 结构的应用都由三个相对独立的逻辑部分组成：
①用户界面部分：数据表示层，实现与用户交互。
②应用逻辑部分：业务逻辑层，进行具体运算和数据处理；
③数据访问部分：数据访问层，完成数据查询、修改、更新等任务。
以上三种逻辑之间的关系如下图：
根据应用逻辑层所处的位置，C/S 结构的应用系统常可以分为两层结构、三层/多层应用结构。
1)两层客户-服务器模型（Two Tier Client/ServerArchitectural Model）
在两层C/S 结构中，应用系统有两个典型的应用组成，其中一个是主要负责用户界面部分的客户端，另一个是主要负责数据访问的服务器，两者通过网络进行数据交换。其结构如下图：
现在举数据库应用的例子来说明两层C/S结构的工作方式。
客户应用工具需求向数据库服务器发出数据访问请求，数据库服务器会响应这个请求，查询、更新数据，然后将结果返回给客户端。这是典型的“请求-响应-得结果”模式。当然，不是所有的请求都需要返回结果。实际上，C/S 的工作模式是一种远程过程调用（Remote Procedure Call, RPC）模式。允许客户端和服务器端有不同的软硬平台。
·完整的应用包含三个相对独立的逻辑部分，而两层的C/S结构只有两个端应用。应用逻辑应该映射到哪一端上呢？ 三种情况：
在上图中：
C/S 应用1的结构中，客户端应用负责用户界面和应用逻辑部分，因此他的工作比较繁重。这种结构往往被称为胖客户端（Fat-Client）结构，一般的数据库应用都是属于这种结构的。以此相反，
C/S 应用3的结构中，服务器负责了更多的工作，而客户端的工作就变得非常单纯。这种结构成为瘦客户（Thin-Client）结构。浏览器/Web 服务器结构就属于瘦客户结构，而且常被称为Browser/Server(B/S)结构。
不过，越来越多的B/S应用包含了一些可以迁移的代码，例如包含客户端脚本的网页，这些代码从服务器端下载到客户端并在客户端执行，这样一来，客户端也或多或少地要处理一部分的应用逻辑。这种B/S结构实际上介于胖客户和瘦客户结构之间，就如上图中的C/S 应用2的结构。
由于两层C/S 架构将数据表示和处理逻辑分开，这样，客户端和服务器的功能相对来说就比较单一，两端的维护和升级也比集中式结构简单。
但C/S 架构也存在着明显的缺陷：
由于应用逻辑和两端之一是紧耦合的，因此当它发生改变时，不是客户端就是服务器也要跟着做出相应的改变，同时这种改变极有可能会影响到另一端。因此，C/S 架构不适合用在多用户、多数据库、非安全的网络环境中。另外，客户端应用程序越来越大，对使用者的要求也越来越高。
3）三层/多层应用模型(Three/Multi Tier Model)
第一级是数据库管理结点(databasemanagement node)。
第二级或中间级是“商业逻辑结点” (business logic node),是指具体应用中实施的 程序逻辑和法则。
第三级是用户界面级，强调高效、方便易用的用户界面。
在下图所示的多层应用模型中，为了有效地管理那些完成业务逻辑的组件，中间层会用到应用服务，包括事务服务、消息服务等。常见的事务服务器有Microsoft Transaction Server，消息服务器有Microsoft Message Queue。
常见的三层结构应用有浏览器-Web服务-数据服务结构。这是一种典型的B/S结构。在这种结构中，
客户应用是一个通用的浏览器，如 Microsoft Internet Explorer(IE),它完成网页的显示和客户端脚本的远行；
Web服务器，如Microsoft Internet Information Server,它响应客户的网页访问请求，运行服务端脚本，并通过Microsoft ADO组件对象向数据库服务器发出数据请求；
数据库服务器，如Microsoft SQL Server ,响应数据请求并返回结果。
·多层应用模型的优点相当的明显：
①客户端的功能单一，变得更“瘦”。
②每一层可以被单独改变，而无须其他层的改变。
③降低了部署与维护的开销，提高了灵活性、可伸缩性。
④应用程序各部分之间松散耦合，从而使应用程序各部分的更新相互独立。
⑤业务逻辑集中放在服务器上有所有用户共享，使得系统的维护和更新变得简单，也更安全。
4) 分布式对象结构(Distributed Objects Architecture)
采用分布式对象结构 ：
·服务的提供者是被称为“对象(Object)”的系统组件(System Component)。
·每个对象在逻辑上是平等的，它们可以互相为对方提供所需的服务。
·提供服务的对象就是服务器，而提出服务请求的对象就是客户。
·为了能够提供服务，每个对象都有一个服务接口。
下图是分布式对象结构：
分布式对象结构的另一个重要特点是，对象可能分布在网络的各个结点上而不是集中在一台硬件服务器上。为了将分散的对象提供的服务“串”起来，一种被形象地称为“软件总线（Software Bus)”的中间件起了关键的作用。
由于分布式对象结构具有相当好的开放性和透明性，用户可以非常方便地在总线上添加或者删除组件对象，从而完成增加、更新或删除功能。
“软件总线(Software Bus)”的中间件(Middleware) ，即对象请求代理(Object Request Broker，简称ORB) 。
1 、CORBA(Common Object Request BrokerArchitecture)
公共对象请求代理体系结构。由对象管理组织OMG （Object Management Group）提出的应用软件体系结构和对象技术规范。
2、DCOM(Distributed Component ObjectModel)
组件对象模型。为组件之间、组件与应用程序之间的通信和互操作提供了统一的标准和技术规范，使不同语言开发的组件可进行基于组件的软件开发。
3、 EJB（Enterprise Java Bean）