软件工程学习.docx

软件工程学习.docx

《软件工程学习.docx》由会员分享，可在线阅读，更多相关《软件工程学习.docx（37页珍藏版）》请在冰豆网上搜索。

软件工程学习

绪论

0.1软件工程的背景

从定义上说，软件工程是一门工程学，因此它和其它工程学科有一系列相同的职责。

一个相同的特征是都必须有一个彻底说明要做什么东西的过程，及需求分析；但另外，软件项目受制于非常频繁的变更矚慫润厲钐瘗睞枥庑赖。

0.2软件工程的活动

●定义要使用的软件开发过程

●管理项目的开发活动

●表述想要的软件产品

●设计产品

●产品实现，即编程

●测试产品的单独模块

●产品集成并做整体测试

●产品维护

软件工程涉及4P，即People（人）,Process（过程）,Project（项目）,Product（产品）聞創沟燴鐺險爱氇谴净。

软件开发工作的产品不仅仅包含目标代码和源代码。

文档、测试结果和生产率的度量也是。

0.3过程

瀑布过程、迭代过程、增量过程、螺旋过程、…

0.4项目（Project）

项目是为了生产所需要的工件应该采取的一组活动的集合。

它包括和客户交流、撰写文

档、设计、编码和对产品做测试。

0.5人员（People）

软件项目中涉及到人与人之间的交互作用对于项目的成功与否有着深切的影响。

人员问题影响项目的另一个因素与项目的风险承担者有关。

残骛楼諍锩瀨濟溆塹籟。

0.6产品（Product）

软件过程各阶段的输出都是产品。

第一章：

过程

1.1区分各种开发的过程，指出各自的优缺点

●瀑布过程模型：

概念分析，分析，设计，实现（编码），单元测试，集成，系统集成，维护；易于控制文档

●迭代过程模型：

不断重复的瀑布过程被称为迭代模型；能够在每次迭代中都收集到过程中产生各种度量。

●螺旋过程模型：

该过程需要经历多次需求分析/设计/实现/测试这组顺序活动。

这样做的主要原因是基于规避风险的需要；缺点：

每次都要保持文档的一致性。

酽锕极額閉镇桧猪訣锥。

●增量过程模型：

在迭代过程模型基础上，每次迭代只是前一次的基础上增加少量功能。

●统一软件开发过程（面向对象开发过程）

1.2量化定义软件的质量

1.3理解所需要的文档

第二章：

项目管理

2.1项目管理简介

2.1.1项目管理的含义

项目管理是指在有限的时间和资金内管理产品的生产过程。

因为需要人力资源，所以项目管理不仅涉及到技术和组织方面的技能，而且涉及到管理人员的艺术。

彈贸摄尔霁毙攬砖卤庑。

2.1.2项目管理的要素

●结构（涉及到组织元素）

●管理过程（参与人员的职责和监督）

●开发过程（方法、工具、语言、文档和支持）

●进度（开展工作各部分的时间安排）

2.1.3主要变量：

成本、性能、质量和进度

2.1.4项目管理过程的典型路线图

1.了解项目内容、范围和期限

2.确定开发过程（方法、工具、语言、文档和支持）

3.设定组织结构

4.明确管理过程（各参与人员的职责）

5.制定时间表（工作各部分的时间安排）

6.制定人力计划

7.风险管理

8.确定要生产的文档

9.开始执行项目

2.2管理项目人员

2.2.1专业精神

2.2.2人员管理的重要性

开发软件需要的首要因素是人员

2.2.3企业的视角

2.2.4管理层的视角

2.2.5工程师的视角

2.3组织人员的选择

2.3.1沟通管理

2.3.2职责结构的选择

2.3.3项目人员的来源

2.4识别和规避风险

2.4.1风险定义

风险就是在项目过程中有可能发生的某些意外事情，而且在最糟的情况下将对项目产生巨大的负面影响甚至导致失败。

风险有两种类型謀荞抟箧飆鐸怼类蒋薔。

●能够避免或则绕开的风险（“被消除”），比如项目领导离开公司

●不能避免的风险，比如没法做的事情

识别第二类风险可以在项目浪费资源之前就终止它。

2.4.2风险管理概论

●识别（心态：

设法持续的识别风险）

●规避计划

●划分优先级

●消除或者减弱风险

2.4.3风险识别

2.4.4风险规避

风险规避是指减轻甚至消除风险的过程。

有两种方法：

一时改变项目的需求，这样引起

风险的问题就不再存在；第二种方法是通过技术开发解决这个问题。

2.5选择开发工具和支持

2.5.1过程方法：

可选的方法有瀑布、螺旋、统一和增量

2.5.2工具

2.5.3抉择：

开发还是购买

2.5.4语言选择

2.5.5文档

2.5.6支持服务

一个项目需要众多人的支持，包括系统管理员、网络管理员、数据库管理员、秘书等等。

项目经理需要确保能够获得这些人员的服务。

厦礴恳蹒骈時盡继價骚。

2.6创建时间表：

概要的计划

1.标出必须关注的里程碑

●通常包括交付日期

2.基于上述内容引入所需要的里程碑

●例如：

在交付之前做好系统测试

3．列出第1次迭代

●通常应该在功能上保持简单

●好处：

磨练自身的开发过程

4.列出识别和规避风险的任务

●从项目启动就开始

5.标出中期附近还没有分配任务的时间（例如，周）

6.完成时间表

第三章需求分析

（一）

本章讨论对于软件需求的整体分析。

3.1.1需求分析的含义

要建造某个事物，必须首先了解这个“事物”是什么样子。

了解并用文档描述这个事物的过程被称为“需求分析”。

需求通常表达应用是用来做什么的；需求分析的输出是一份文档，通常被称为需求规格说明书或者软件需求规格说明书（SRS）。

茕桢广鳓鯡选块网羈泪。

3.1.2C需求和D需求

将需求分为两个层次，第一层记录了客户的需要和要求，使用他们明白的语言进行描述。

这个结果被称为“客户需求”或者“C需求”。

C需求的首要读者是客户群体，其次是开发人员。

第二层需求则按明确的、有组织的形式来记录。

他们被称为“开发人员需求”或者“D需求”。

D需求的首要读者是开发人员，其次是客户群体。

鹅娅尽損鹌惨歷茏鴛賴。

3.1.3为什么必须书写需求

没有这样的文档，小组无法真正了解需要完成的目标是什么，无法正确地检查产品，无法正确地测试产品，无法跟踪生产效率，无法获得足够的实践数据，无法估计下一项工作的规模和工作量，更无法满足客户的要求。

籟丛妈羥为贍偾蛏练淨。

3.1.4典型的需求分析过程路线图

1.识别“客户”

2.访谈“客户代表”

●识别需要和要求

●使用工具帮助表达

●绘制GUI草图

●确定硬件环境

3.用标准文档格式撰写C需求

4.检查C需求（当客户批准后）

5.构建D需求

3.1.5需求分析的挑战和益处

使开发人员和客户将要开发的应用取得理解并达成一致。

含有缺陷的需求将导致项目代价增加20到50倍。

3.2与客户交流

3.2.1需求的来源

人是需求的唯一来源

3.2.2识别风险承担者

对于项目的成果承担风险和享有利益的人被称做风险承担者。

因此，它们是应用的“客户”：

使用该软件的人，公司的业主，应用开发人员etc.預頌圣鉉儐歲龈讶骅籴。

3.3描述客户（C）需求

3.3.2用例

需求通常可以被看成是应用和应用的外部代理（例如用户）之间的交互。

用用例图可以描述。

3.3.3数据流图（为与客户沟通所用）

某些需求可以是很自然地描述为进程元素之间的数据流。

在数据流图中，节点表示进程单元，用圆形或者矩形表示。

节点之间的箭头代表数据流，箭头上标注数据的类型。

数据存储用一对水平的平行线表示，平行线之间是数据储存的名字，代表数据存放的位置。

外部代理用矩形表示。

渗釤呛俨匀谔鱉调硯錦。

3.3.4状态变迁图（为与客户沟通所用）

对于事件驱动型的应用，采用状态变迁图来描述是非常有效的。

（自动机和Petri网的变形）

3.3.5草拟用户界面的其它接口

客户通常在看到应用的图形界面（GUI）时才能够想象这个应用未来的样子，所以帮助客户描述应用的一个好办法就是开发GUI的草稿。

铙誅卧泻噦圣骋贶頂廡。

3.3.6C需求表述总结和指南

1/2

●如果需求涉及到用户和应用软件之间的交互，则通过用例进行描述

1.给用例命名。

2.识别用例的“主角”。

（外部的使用角色——通常是一个人）

3.描述用户和应用的活动系列

●尽量减少分支

●使用通用的形式

2/2

●如果需求涉及到进程元素，并需要获得输入并产生输出，则使用数据流图进行描述。

1.识别进程元素（通常是概要的）：

使用圆形或者矩形表示

2.识别数据的来源和去向：

使用位于一对平行线之间的名称来表示

3.在进程之间标识数据的流向，说明每个数据的类型

●若需要涉及到应用软件的全部状态（或者部分状态）

4.识别状态（每个状态通常都是一个动词的被动形式）：

使用圆角的矩形来表示。

5.用特殊的箭头标识初始状态

6.识别引起状态变迁的事件（指模块外部发生的事情）：

使用带有标识的箭头来表示它

7.识别子状态：

使用嵌套的矩形表示。

3.4应用于C需求的方法论、工具和网络

有大量的方法论可以用于表述需求。

这里仅给出关于其中一部分方法论的总结。

●结构化分析给数据流和功能分解定义了正式的形式。

特别是结构化分析和设计技术是处理体系规格的一种系统方法。

结构化分析方法主要是从系统功能的角度来观察应用软件，这个功能视图最终将被分层的详细功能所实现；擁締凤袜备訊顎轮烂蔷。

●实时系统可以通过状态变迁图得到有效的描述。

3.5快速原型、可行性研究和概念证明

3.5.1“快速原型”是对目标软件的部分实现，通常会涉及到重要的图形用户界面（GUI）部分。

建立快速原型能够有效地获取客户的需求，并且识别和规避部分项目的风险。

增进对客户真实需求的充分理解能够省去因需求误会导致的昂贵的返工费用，并可提前消除未来可能引发的障碍。

（原型越详细，客户的需求就越容易被理解）。

贓熱俣阃歲匱阊邺镓騷。

3.5.2可行性研究

有些时候我们根本无法确定客户所提出的需求是否能够真正实现。

换句话说，项目都存在一个整体风险，而不是若干集中于某些特定需求的风险。

而且，如果这个风险成为现实的话，那么这个项目就变的不可行——不值得开发。

在这种情况下，就必须对项目进行可行性研究坛摶乡囂忏蒌鍥铃氈淚。

第四章需求分析

（二）

4.1详细D需求简介

4.1.1详细D需求的含义

软件工程师基于一个基础来进行软件设计和实现，这个基础就是由详细需求构成的。

它们也称为“细节需求”、“功能规格说明”、“面向开发人员的需求”或者“D需求”。

D需求是一个系统所必须的详细属性和功能的完整列表，它描述了最终的需求细节。

其中的每条需求都进行了编号、标识，并且在开发过程中始终保持跟踪。

D需求是从C需求扩展而来的，与C需求保持一致。

蜡變黲癟報伥铉锚鈰赘。

4.1.2D需求分析的典型路线图

●选择D需求的组织方式

●根据用例生成序列图

●3a.从C需求中和客户处获得D需求

●3b.概述测试计划

●3c.核查

●交由客户确认

4.2D需求的类型

1.功能性需求

●应用软件的功能

2.非功能性需求

2.1性能

●速度

●能力（通信速率）

●储存占用

●a.内存，b.硬盘

2.2可靠性和易用性

2.3出错性

2.4接口需求

应用软件与客户如何交互

与其它应用如何接口

2.5限制

●精确性

●工具和语言限制

●设计限制

●采用标准

●使用的硬件平台

3.反面需求

反面需求说明软件不应该去做那些事情。

从理论上说，反面需求应该有无数条，我们选择那些可以反面说明真正的需求，以及能够消除可能存在的误解的反面需求。

買鲷鴯譖昙膚遙闫撷凄。

4.3D需求的预期属性

我们已知遗漏需求可能对项目造成巨大的影响。

为了确保细节得到足够的覆盖，这里

我们介绍D需求应该具备的属性。

特别要注意，D需求应该保持整体完整性和一致性。

每一条需求都应该能够追溯到设计和实现，能够测试它们的正确性，而且按照恰当的优先顺序来实现这些需求。

在实施质量评审时，我们将对需求的这些属性进行评审和检查。

綾镝鯛駕櫬鹕踪韦辚糴。

4.3.1跟踪功能性需求

把需求隐射到相关的设计和实现模块中的能力称之为“可追塑性”。

实现这种映射的方法之一是将每条功能性需求对应到目标语言的具体函数中。

随着项目的发展，需求文档需要与设计和实现部分保持一致。

有些时候为了满足一条需求做出的修改可能会影响到其它需求的实现。

正是因为这种多对多的关系非常难以管理，所以我们要设法在需求和函数之间一一映射。

驅踬髏彦浃绥譎饴憂锦。

4.3.1.2跟踪非功能性需求（可以是性能要求）

上述讨论关注的是功能性需求。

设计阶段的目标之一是把每一条非功能性需求对应到单独的设计元素中。

对于性能需求，需要去测试速度最慢的处理单元。

为了确认非功能性需求，需要把每条需求和一份测试计划联系起来，并最好是在撰写需求的时候进行这个工作。

猫虿驢绘燈鮒诛髅貺庑。

4.3.2可测试性和清晰性

一条需求必须能够通过测试加以验证，表明该需求得到了正确的实现。

只有当一个D需求描述的清晰而且没有二义性，我们才能肯定它是否被正确地实现锹籁饗迳琐筆襖鸥娅薔。

4.3.3优先级

通常很难按照进度实现应用软件计划的预算的全部需求。

如果进度、成本预算和质量水平都不能变动的话，惟一选择就是改变产品的能力，即：

削减预计实现的部分需求。

选择那些需求进行削减的过程是有计划地进行的。

其中的一种技术就是划分详细需求的优先级别。

但是通常区分所有需求的优先级往往会很浪费时间，所以，很多组织把需求分为三个类别（有时是四个）：

“基本的”、“希望的”和“可选的”。

首先我们要确保项目实现“基本的”需求。

需求的优先级会影响到设计，因为希望的和可选的需求通常暗示了应用软件发展的方向。

構氽頑黉碩饨荠龈话骛。

4.3.4完整性

我们尽力想要使每一条详细需求保持独立，但是在现实中这是不可能的，因为一个需求常常要提到其它需求。

一个需求集合的完整性是指该集合中不存在会对集合中所叙述的需求造成危害的遗漏情况。

輒峄陽檉簖疖網儂號泶。

4.3.5出错条件

对于每一条需求，我们都要思考如果它在错误的环境下实现时会发生什么事情。

良好的需求分析应该能够正确处理“非法”输入。

尧侧閆繭絳闕绚勵蜆贅。

4.3.6一致性

一组D需求是一致的，指的是它们之间没有矛盾冲突。

但是随着D需求的数量的增长，保持它的一致性将会变得越来越困难。

可以按照面向对象的方式来组织需求避免不一致性，面向对象的方式把D需求划分为若干类。

识饒鎂錕缢灩筧嚌俨淒。

4.3.7总结详细需求的撰写过程

撰写一条详细需求

（1）

1.把需求归类于功能性或者非功能性的

●IEEESRS提示了大部分非功能性需求

●选择组织功能性需求的方法

2.详细的控制规模

●一条功能性需求基本对应于类中的一个方法

●过大：

难以管理

●过小：

不值得单独跟踪

3.尽量保持可追溯性

●确保适于跟踪至设计和实现

4.使之可被测试

●草拟测试要点，用于确认需求得到满足

撰写一条详细需求

（2）

5.确保需求含义清晰、不模糊

●意图不会被误解

6.划定需求的优先级

●例如：

最高（“最基本的”）；最低（“可选的”）；中等（“希望的”）

7.检查需求集合的完整性

●对每条需求，确保其它必要的相关需求都已经包括在集合之中

8.包含出错条件

●说明非正常情况的具体特征

●包括关键位置的编程错误

9.检查一致性

●确保每条需求不会对其它任何需求的任何方面造成矛盾

备注：

1．关于需求的组织方法在开始撰写D需求之前就必须确定下来

2．评估一条需求是否可追溯就是构想该需求的设计并且想象设计如何能够满足这条需求。

如果这条需求直接对应类中的一个方法，那么这种追溯性的评估最为简单。

凍鈹鋨劳臘锴痫婦胫籴。

3．它有助于在撰写需求的同时概括描述该需求的测试要点。

这样不仅能够使需求的含义更加清晰，而且还可以检查需求是否可测试恥諤銪灭萦欢煬鞏鹜錦。

4．很多需求依赖于特定的数据，因此我们需要指出当输入数据错误或者不一致的情况下这条需求应该如何处理。

对于关键需求，还应该包括由于低劣的设计和编程引起的错误鯊腎鑰诎褳鉀沩懼統庫。

4.4序列图

序列图是对控制流的一种图形化表示方法，对于表示用例的执行步骤尤其有用。

并且序列图除了可以用于进行需求分析，如本章所描述，还可以通过更详细的形式来用于设计。

硕癘鄴颃诌攆檸攜驤蔹。

序列图要求我们用对象的角度进行思考。

在序列图中，每个所涉及的对象的生命周期都分别用一条垂直的实线来表示，实线的顶端标有对象的名称和它所属的类的名称。

对象之间的每次交互则通过一条带有箭头的水平线来表示，这条带箭头的线把呼叫服务的对象和提供服务的对象连接起来。

（操作：

表示由箭头线起点的对象发起并由箭头线终点的对象承担的工作。

通常操作在设计阶段都会转化为一个具体的函数）在需求分析阶段，序列图只是用于识别关键的类。

阌擻輳嬪諫迁择楨秘騖。

4.4组织D需求的方式

4.5.1组织详细需求的重要性

随着需求的增长，未经组织的需求将会无法管理

4.5.2组织详细需求的方法

主要来说，D需求可以按照下面的几种方法进行组织：

●根据“特性”（希望外界可以觉察到的服务，往往通过刺激——反应这两方面来定义）。

这种方法就是通常所认为的按照“需求”进行组织的方式——也就是说，需求根据应用软件可感知的特性来进行组织。

不过请注意，这种组织方式并没有真正提供任何系统的组织方式，因为它允许应用软件某个部分的特性跳到另一个完全不同的部分的特性。

组织详细需求的途径：

氬嚕躑竄贸恳彈瀘颔澩。

●根据“模式”（比如：

雷达系统可能有训练、正常和紧急三种模式）

●根据“用例”（有时也称做“场景”）。

这种方法是统一软件过程推荐的需求组织方式。

●根据“类”。

这是一种面向对象的分类方法，使用这种组织方式，我们可以把需求划分成各个类。

●根据“功能的分层结构”（即：

把应用软件分解成一组高层的功能集合，继而又把它们分解成为子功能集合，以此类推）。

这种方法就是传统地给详细需求按顺序排列的方法釷鹆資贏車贖孙滅獅赘。

●根据“状态”（表明应用与每个状态的具体需求）。

3.详细需求（非OO）

3.1外部接口

3.2功能

3.3性能需求

3.4逻辑数据库要求

3.5设计限制

3.5.1遵循的标准

3.6软件系统属性

3.6.1可靠性

3.6.2易用性

3.6.3安全性

3.6.4可维护性

3.6.5可移植性

3.7详细需求的组织方式

3.7.1系统模式——或者

3.7.2用例——或者

3.7.3对象——或者

3.7.4特性——或者

3.7.5刺激——或者

3.7.6反应——或者

3.7.7功能分层结构——或者

3.7.8其它

3.详细需求（OO形式）

3.1外部接口

3.1.1用户界面

3.1.2硬件接口

3.1.3软件接口

3.1.4通信接口

3.2类/对象

3.2.1类/对象1

3.2.1.1属性（直接的或者继承的）

3.2.1.1.1属性1….

3.2.1.2函数（服务，方法，直接的或者继承的）

3.2.1.2.1功能性需求

……..

3.3性能需求

3.4设计限制

3.5软件系统属性

3.6其他需求

D需求的组织方式通常与应用软件将要采用的体系结构有着密切的关系。

例如，如果设计采用面向对象的方式，那么需求的组织方式就应该考虑基于“用例”或者“分类”的方式，因为这样便于进行追溯。

怂阐譜鯪迳導嘯畫長凉。

4.5.3基于用例组织详细需求

统一软件开发工程提出一种观点：

许多需求是按照自然的操作序列发生的。

统一软件开发过程推荐按照用例来组织绣球。

如果用这种方式组织需求，小型的用例可以用于生成大型的用例，即使用用例“泛化”。

谚辞調担鈧谄动禪泻類。

4.5.4基于类组织的详细需求

面向对象的方式组织需求：

首先确定类别——等同于类的选择——然后把每条需求分别放置在前面所得出的类别或者类中。

做这件事情有两种方法：

一是把类仅仅看做是组织需求的方式，但是不认为它们有必要用于实际的设计。

另一种方法则在实际的面向对象的设计（和实现）中采用需求分析过程所产生的类。

嘰觐詿缧铴嗫偽純铪锩。

按照类来组织需求的缺点是由于后期可能改变类所带来的风险，这样就会打破了需求和类之间的对应关系。

根据将在设计和实现中使用的类来组织需求的最大优点是它为需求、设计和实现提供了紧密的对应关系。

这也是采用OO范型的一个关键益处。

此外，与真实世界的概念保持一致的类比那些没有这样做的类更有可能被重用。

对许多应用来说，基于类的分类方法带来的优点远远超过了它的缺点。

熒绐譏钲鏌觶鷹緇機库。

使用OO的方式获取功能性D需求的典型步骤

1.首先列出用例中提及的类。

2.这样得出的类往往并不完整，还需要进一步寻找剩余的“领域”类，这个过程将在后面作出介绍。

接着对这些类进行检查。

鶼渍螻偉阅劍鲰腎邏蘞。

3.对于得到的每一个类，需求工程师要记录下应用软件需要它提供的所有功能。

主要是通过属性和函数这样的形式来达到这个目的的。

这个类的对象需要处理的事件也应该具体列出。

纣忧蔣氳頑莶驅藥悯骛。

随着过程的进展，对D需求进行检查。

理想情况下，应该同时提供每个D需求的测试计划，

4.然后根据C需求来对D需求做出检查

5.D需求经过客户验证之后进行发布。

4.5.5类的识别

用于组织需求的类必须经过认真和恰当的识别。

这个步骤是通过确定应用软件的“领域”类来完成的——领域类指的是那些特定领域应用软件专用的类。

颖刍莖蛺饽亿顿裊赔泷。

用例是用于识别领域类的主要来源。

从用例中获取所需的类之后，继续补充关键领域类的一个有效方法是进行“罗列和删除”。

这个过程包括

（1）先列出所有可以想到的合理的侯选类，

（2）然后大规模地削减这个列表，直到剩下几个基本的类为此。

濫驂膽閉驟羥闈詔寢賻。

然后对这些侯选类进行筛选。

首先需要指出的是，以后阶段增加一个类比从设计和实现阶段中删除一个类要简单的多，所以只要对侯选类这些领域类的作用有所怀疑，我们就要把它从清单上去掉。

銚銻縵哜鳗鸿锓謎諏涼。

总结

10.建立一组广泛的、没有重叠的用例。

11.为每个用例绘制序列土

●识别类和对象的时候需要特别小心

12.收集序列图中用到的所有类

13.确定其它基本的领域类

14.根据这些类划分详细的功能性需求

5.1把每个属性作为一个需求

5.2列出这个类必须生成的具体对象

5.3列出这个类的对象需要的所有函数

5.4列出这个类的对象必须做出反应的事件

4.5.6对给定的需求选择正确的类

如果按照类组织D需求，遇到的最大困难可能就是决定把一条需求放在哪个类中进行说明。

4.5.7划分实体（实例）的类别

应用软件中存在特定的实体（或者叫实例对象，相对于特定的类来说）。

4.5.8连接到测试文档

当撰写D需求的时候，应该针对这条需求做一些测试方面的工作。

在描述需求的同时准备测试文档有下面几个优点：

第一，这样做能够帮助我们进一步明确详细需求。

第二，它把项目测试阶段的一部分工作提前到需求阶段。

挤貼綬电麥结鈺贖哓类。

第五章软件体系结构

第1部分：

基础篇

5.1系统工程和软件体系结构介绍

5.1.1宏图：

系统工程

系统工程是将应用分解成软件部分和硬件部分的分析与设计过程。

分解的方式有赖于客户的需求，有些则由工程师自行设计。

赔荊紳谘侖驟辽輩袜錈。

系统工程分析通常从整个系统的需求开始，通过界定软件和硬件间的平衡点，进而将系统分解成软件和