软件工程文档格式.docx

软件工程文档格式.docx

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

衡量软件质量的6个特性：

功能性、可靠性、可使用性、效率、可维护性和可移植性。

1.2.3软件工程的基本原理

1983年美国TRW公司的B.W.Boehm概括出著名的软件工程7条基本原理：

1.按软件生存周期分阶段制订计划并认真实施；

2.坚持进行阶段评审；

3.坚持严格的产品控制；

4.使用现代程序设计技术；

5.明确责任；

6.用人少而精；

7.不断改进开发过程。

1.3软件生命周期

软件有一个孕育、诞生、成长、成熟和衰亡的过程，称此过程为软件生命周期或软件生存期。

软件生存期由软件定义、软件开发和运行维护3个时期组成。

软件定义时期的主要任务是解决“做什么”的问题，它通常又分为3个阶段：

问题定义、可行性研究和需求分析。

软件开发时期的主要任务是解决“如何做”的问题，通常由概要设计、详细设计、编码和测试4个阶段组成。

软件运行维护时期的主要任务是使软件持久地满足用户的需要，通常有四类维护活动：

改正性维护、适应性维护、完善性维护和预防性维护。

里程碑对于软件开发的管理非常重要。

开发过程中的典型文档包括：

A.软件需求规格说明书；

B.项目计划；

C.软件测试计划；

D.软件设计说明书；

E.用户手册。

各个阶段所要完成的基本任务有：

1）问题定义和可行性研究

本阶段要回答的关键问题是“到底要解决什么问题？

在成本和时间的限制条件下能否解决问题？

是否值得做？

”

2）需求分析

本阶段要回答的关键问题是“目标系统应当做什么？

3）软件设计

设计是软件工程的核心技术。

本阶段要回答的关键问题是“如何做出目标系统？

4）程序编码和单元测试

本阶段要解决的问题是“正确地实现已做的设计”，即“如何编写正确的、可维护的程序代码？

5）集成和系统测试

测试是控制软件质量的重要手段，本阶段的主要任务是做集成测试和系统测试。

6）软件运行和维护

已交互的软件投入正式使用，便进入运行阶段。

通常有4种类型的维护：

改正性维护、适应性维护、完整性维护和预防性维护。

1.4软件工程方法学

把在软件生命周期全过程中使用的一整套技术的集合称为方法学（methodology），也称为范型（paradigm）。

软件工程方法学包含3个要素：

方法、工具和过程。

1.4.1结构化方法学

结构化方法学也称为传统方法或生命周期方法。

它采用结构化技术来完成软件开发的各项任务。

这种方法学将软件生命周期的全过程分为若干个阶段，然后顺序地逐步完成每个阶段的任务。

1.4.2面向对象方法

面向对象方法把数据和行为看成同等重要，是将数据和对数据的操作紧密地结合起来的方法。

1.5软件工程知识体系及知识域介绍

软件工程教育分为3个历史时期：

A.1978年以前：

软件工程的教育以计算机专业的一门孤立的课程形式存在；

B.1978-1988年期间：

早期的研究生教育；

C.1988年以后：

快速发展的研究生学科教育。

“SWEBOK指南”项目：

A.软件工程知识体系指南的目标：

a）促使软件工程本体知识成为世界范围的共识；

b）澄清软件工程与其它学科的关系，并且确定软件工程学科的范围；

c）反映软件工程学科内容的特征；

d）确定软件工程本体知识的各个专题；

e）为相应的课程和职业资格认证材料的编写奠定基础。

B.软件工程知识体系指南的内容：

10个知识域（KA），分为两类过程，一类是开发和维护过程，包括：

软件需求、软件设计、软件构造、软件测试和软件维护；

另一类是支持和组织过程，包括：

软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法和软件质量。

1.6软件产业的形成与发展

1.6.1我国软件产业的形成

主要经历了四个阶段：

●第一阶段：

萌芽期（20世纪70年代至80年代初）

●第二阶段：

起步期（20世纪80年代初至80年代末）

●第三阶段：

进入期（20世纪90年代初至2000年初）

●第四阶段：

发展期（网络软件时期，2000年至今）

1.6.2全球软件产业的发展

已经经历了比较完整的5代：

●第一代：

早期专业的服务公司（1949年-1959年）

●第二代：

早期软件产品公司（1959年-1969年）

●第三代：

强大的企业解决方案提供商的出现（1969年-1981年）

●第四代：

客户大众市场软件（1981年-1994年）

●第五代：

互联网增值服务（1994年至今）

1.6.3软件产业的发展模式

1.美国模式—技术与服务领导型

2.印度模式—国际加工服务型

3.爱尔兰模式—生产本地化型

4.日本和欧洲模式—嵌入式系统开发型

5.德国模式—企业级应用及自主研发型

1.6.4软件工程在软件产业中的应用

一方面，软件产业离不开软件工程理论及其标准的指导；

另一方面，软件产业的发展需要大量的软件工程人才。

第2章软件需求获取与确认

2.1软件需求获取的任务

软件需求是为了解决用户的问题和实现用户的目标，用户所需的软件必须满足的能力和条件。

业务需求、用户需求、系统需求、功能需求和非功能需求。

2.2软件需求的获取与确认过程

a）获取

b）协商

c）说明与定义

d）确认

2.3快速原型化方法

原型法是这样一种软件开发技术，通过开发软件的初期版本让用户进行反馈来确认软件的可行性，研究开发技术或开发过程支持的其它问题。

快速原型法的重点是在开发过程的早期就开发出原型，使用反馈和分析提前，以支持开发过程。

使用原型可达到3个主要目的：

明确并完善需求，研究技术选择方案，把原型发展为最终产品。

2.4基于用况的方法

基于用况的方法通过建立用况模型来获取与确定需求。

2.4.1系统边界

系统边界是系统的所有内部成分与系统以外各种事物的分界线。

现实世界中的事物与系统的关系包括以下几种情况：

a）某些事物位于系统边界以内，作为系统成分；

b）某些事物将是与系统进行交互的参与者，系统中没有相应的成分作为它们的抽象表示，它们位于系统边界以外；

c）有的事物可能既在系统内部有一个对象作为其抽象描述，而事物本身又在系统边界以外与系统进行交互；

d）某些事物属于问题域，但与系统责任没有关系。

2.4.2参与者

a）概念与表示法

一个参与者（actor）定义了一组在功能上密切相关的角色，当一个事物与系统交互时，该事物可以扮演这样的角色。

参与者的标准图符是一个“人型符号”，参与者的名字放在图符的下方。

b）识别参与者

参与者是在系统之外的与系统进行交互的任何事物。

从3个方面识别参与者：

●人员：

直接使用系统的人员是参与者；

●外部系统：

所有与本系统交互的外部系统都是参与者；

●设备：

识别所有与系统交互的设备。

识别与组织参与者的指导策略：

i.首先将精力集中于启动系统的参与者；

ii.考虑如何使用系统；

iii.对识别出来的参与者，记录其责任；

iv.若参与者存在着继承关系，则要予以建立。

2.4.3用况

1.概念与表示法

用况（usecase）是描述系统的一项功能的一组动作序列，这样的动作序列表示参与者与系统间的交互，系统执行该动作序列要为参与者产生结果。

上述定义具有如下含义：

1）使用用况来可视化、详述、构造和文档化所希望的系统行为；

2）用况描述中的一个动作应该描述参与者或系统要完成的交互中的一个步骤；

3）在用况中只描述参与者与系统彼此为对方直接做了些什么事，不描述怎么做，也不描述间接地做了些什么；

4）系统所产生的结果，是指系统对参与者的动作要做出响应；

5）用况描述的是参与者所使用的一项系统功能，该项功能应该相对完整，也即应该保证用况是某一项功能的完整的规格说明，而不能只是其中的一个片段；

6）在用况描述中，由参与者首先发起交互的可能性较大，但有些交互也可能是由系统首先发起的。

在图形上，把用况表示成一个包含用况名字的椭圆。

对用况的描述，可使用自然语言、活动图和伪码，也可使用用户自己定义的语言。

2.用况与参与者之间的关系

在用况图中，一个参与者可以同多个用况交互，一个用况也可以同多个参与者交互。

把参与者与用况间的交互关系称为关联，用一条实线连起来。

3.用况之间的关系

3种关系：

包含、扩展和继承。

（1）包含

在两个或多个用况中经常存在着重复行为，为了避免重复，把重复行为放在一个用况中，原有的用况（基用况）再引入该用况（供应者用况），这样就在用况间建立了包含关系。

用一个带箭头的虚线表示用况之间的包含关系。

（2）扩展

在一个或几个用况描述中，有时存在着可选的描述系统行为的片段。

若存在这种情况，可以从用况中把可选的行为描述部分抽选出来，放在另一个用况（扩展用况）中，原来的用况（基用况）再用它扩展自己，以此来解决候选路径的复杂性。

这样在描述基本动作序列的基用况和描述可选动作序列的扩展用况之间就建立了扩展关系。

用虚箭线表示用况之间的扩展关系。

（3）继承

用况之间的继承关系的含义和同类之间或参与者之间的继承关系一样。

用指向一般用况的带有封闭的空心箭头的实线来表示用况之间的继承关系。

4.获取用况

可以从以下几个方面来获取用况：

（1）从参与者的角度获取用况；

（2）从系统功能的角度获取用况；

（3）利用场景获取用况。

2.4.4用况图

用况图是一幅由参与者、用况以及这些元素之间的关系组成的图。

这些关系是参与者和用况之间的关联、参与者之间的继承，以及用况之间的包含、扩展和继承。

2.5需求管理

需求管理要标识、控制和跟踪需求。

（1）需求标识和分类

最简单的方式是为每个需求赋予一个唯一的序列号。

也可以按需求的抽象层次来进行数字编号。

若需求量较大，则应进行分类组织，以便编写文档和使用。

（2）变更管理

（3）需求跟踪

进行需求跟踪的一个常见做法是建立需求矩阵。

可根据需要定义需求矩阵中的需求关系，如依赖关系、从属关系、精化关系、实现关系等。

第二部分结构化软件开发方法

第3章结构化分析建模

深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性分析。

3.1软件需求分析阶段的任务

分为四个步骤：

获取需求、分析需求、定义需求和验证需求：

N、R1、R2和R3。

i.获取需求

通过启发、引导从客户（或用户）那里得到原始需求是他们的业务要求（needs），简称为N。

ii.需求分析

需求分析人员考虑以下几个方面：

（1）完整性；

（2）正确性；

（3）合理性；

（4）可行性：

a）技术可行性；

b）经济可行性；

c）社会可行性。

（5）充分性。

iii.需求定义

作为软件开发的依据，必须将已经分析的需求清晰、全面、系统准确地描述为正式的文档。

iv.需求验证

为了确保已经定义的需求R2（需求规格说明）准确无误，并能为客户（或用户）理解或接受，需要对其进行严格的评审。

这一评审一定要有客户（或用户）参加，并充分听取他们的意见。

3.2结构化分析方法简介

传统的分析建模方法称为结构化分析（SA）方法。

它是一种建模技术，在模型的核心是数据字典，它描述了所有的在目标系统中使用的和生成的数据对象。

围绕这个核心有3种图：

数据流图（DFD），实体-关系图（ER图）和状态-迁移图（STD）。

3.3功能建模

其思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。

功能模型用数据流图来描述。

3.3.1数据流图的基本图形符号

数据源或数据汇点表示图中要处理数据的输入来源或处理结果要送往何处。

数据流表示数据沿箭头方向的流动。

加工是对数据对象的处理或变换。

数据存储在数据流图中起保存数据的作用，可以是数据库文件或任何形式的数据组织。

3.3.2环境图

环境图（contextdiagram）也称为顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标文件。

3.3.3数据流图的分层

按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。

画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。

3.3.4功能建模的方法和过程

（1）识别外部实体及输入输出数据流

（2）画出环境图（顶层数据流图）

（3）画出一层数据流图

（4）画出二层数据流图

3.4数据建模

在结构化分析方法中，使用实体-关系建模技术来建立数据模型，也称为ER图。

图中仅包含3种相互关联的元素：

数据对象（实体）、描述数据对象的属性及数据对象彼此间相互连接的关系。

3.4.1数据对象

数据对象是目标系统所需要的复合信息的表示，所谓复合信息是具有若干不同属性的信息。

3.4.2属性

属性定义数据对象的特征，在ER图中用椭圆或圆角矩形表示属性。

3.4.3关系

不同数据对象的实例3之间是有关联关系的，在ER图上用无向边表示，在无向边上可以标明关系的名字，也可以不标名字。

可以将实例的关联分为三种：

一对一关联、一对多关联、多对多关联。

3.5行为建模

在需求分析过程中，应该建立起软件的行为模型。

状态转换图（简称转换图）通过描绘系统的状态及引起系统状态转换的事件来表示系统的行为。

3.5.1状态

状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式，状态规定了系统对事件的响应方式。

在状态图中定义的状态可能有：

初态、终态和中间态。

初态用实心圆表示，终态用牛眼圆形表示，中间态用圆角矩形表示。

中间态可能包括三个部分：

第一部分为状态的名称，第二部分为状态变量的名字和值，第三部分为活动表。

第二、三部分可选。

活动部分的语法如下：

事件名（参数表）/动作表达式

3.5.2状态转换

状态图中两个状态之间带箭头的连线称为状态转换。

3.5.3事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外部事件的抽象。

事件表达式的语法如下：

事件说明（守卫条件）/动作表达式

事件说明的语法如下：

事件名（参数表）

守卫条件是一个布尔表达式，动作表达式是一个过程表达式。

3.6数据字典

数据字典以词条方式定义在数据模型、功能模型和行为模型中出现的数据对象和控制信息的特征，给出它们的准确定义，包括数据流、加工、数据文件、数据元素，以及数据点、数据汇点等。

3.6.1词条描述

对于在数据流图中每一个被命名的图形元素均加以定义，其内容包括图形元素的名字，图形元素的别名或编号，图形元素的类别（如加工、数据流、数据文件、数据元素、数据源点或数据汇点等）、描述、定义、位置等。

具体如下：

（1）数据流词条；

（2）数据元素词条；

（3）数据存储文件词条；

（4）加工词条；

（5）数据源点及数据汇点词条。

3.6.2数据结构描述

有定义式、Warnier图等。

（1）定义式

（2）Warnier图

3.7加工规格说明

在对数据流图的分解中，位于层次树最低层的加工也称为基本加工或原子加工，对于每一个基本加工都需要进一步说明，这称为加工规格说明。

它应满足如下要求：

（1）对数据流图的每一个基本加工，必须有一个加工规格说明。

（2）加工规格说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规格。

（3）加工规格说明必须描述实现加工的策略而不是实现加工的细节。

（4）加工规格说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息。

加工规格说明的内容可以包含叙述性正文、数学方程、图表等，也可以使用决策表和决策树。

3.7.1决策表

在某些数据处理问题中，某个加工的执行需要依赖于多个逻辑条件的取值，此时可以用决策表（decisiontable）来描述。

它由4个部分构成：

左上部分是条件（conditionstub）、左下部分是动作（actionstub）、右上部分是条件项（conditionentry）、右下部分是动作项（actionentry）。

通常，将每一列条件项和动作项称作一条处理规则，它包含了一个条件取值组合和相应要执行的一组动作。

建立决策表的步骤如下：

（1）列出与一个具体过程（或模块）有关的所有操作。

（2）列出过程执行期间的所有条件（或所有判断）。

（3）将特定条件取值组合与特定的处理相匹配，消去不可能发生的条件取值组合。

（4）将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作。

3.7.2决策树

它也是用来表达加工逻辑的一种工具。

在构造决策树时，首先应从文档叙述中分清哪些是判定条件，哪些是判定结果。

然后，从文档叙述中的一些连接词中，找出判定条件的从属关系、并列关系、选择关系等。

3.8需求规格说明

按照国家标准GB/T8567-2006《计算机软件文档编制规范》。

3.8.1软件需求规格说明

SRS描述了计算机软件配置项的需求以及为确保需求得到满足所使用的方法。

3.8.2数据需求说明

DRD描述了在整个开发过程中所需处理的数据，以及采集数据的要求等。

第4章总体设计

在软件生存期中，软件设计处于需求分析阶段及软件构造阶段（或编码阶段）的中间位置。

4.1软件设计的概念和目标

4.1.1软件设计的概念

软件设计包括一套原理、概念和实践，可以指导高质量的系统或产品开发。

设计原理建立了最重要的原则，用以指导设计人员工作。

4.1.2软件设计的目标

软件设计的目标涉及性能、可靠性、成本、维护等多个方面的目标。

一些可能的准则如下：

（1）性能准则

（2）可靠性准则

（3）成本准则

（4）维护准则

（5）最终用户准则

4.2软件设计的任务

软件设计的主要任务是要解决如何做的问题，要在需求分析的基础之上，建立各种设计模型，并通过对设计模型的分析和评估，来确定这些模型是否能够满足需求。

4.2.1软件设计的阶段与任务

从工程管理的角度，分为两个阶段：

概要设计阶段和详细设计阶段。

传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计和过程设计4部分；

而面向对象方法将软件划分设计划分为体系结构设计、类设计/数据设计、接口设计和构件级设计4部分。

4.2.2结构化设计与结构化分析的关系

软件设计必须依据对软件的需求来进行，结构化分析的结果为结构化设计提供了最基本的输入信息。

4.3模块结构与数据结构

软件的结构包括两个部分，一部分为软件的模块结构，另一部分为软件的数据结构。

4.3.1模块结果及表示

1）模块

一个软件系统通常由很多模块组成，模块用矩形框表示，并用模块的名字标记它。

可以按照在软件系统中的功能将模块划分为四种类型：

A．传入模块

B．传出模块

C．变换模块

D．协调模块

2）模块结构

A.树状结构

B.网状结构

3）结构图

结构图（SC）是精确表达模块结构的图形表示工具。

A.模块的调用关系和接口；

B.模块间的信息传递；

C.两个辅助符号；

D.结构图的形态特性。

4.3.2数据结构及表示

典型的数据结构：

标量项，链表，顺序向量，树状结构，网状结构，n维空间。

4.4创建良好设计的原则

4.4.1分而治之和模块化

4.4.2模块独立性

1）松散耦合：

非直接耦合，数据耦合，标记耦合，控制耦合，外部耦合，公共耦合，内容耦合。

2）高度内聚：

巧合内聚，逻辑内聚，时间内聚，过程内聚，通信内聚，信息内聚，功能内聚。

4.4.3提高抽象层次：

在最高的抽象层次上，可以使用问题所处环境的语言概括地描述问题的解决方案；

在较低的抽象层次上，采用更过程化的方法，将面向问题的术语和面向实现的术语结合起来描述问题的解法；

在最低的抽象层次上，则用某种程序设计语言来描述问题的解法。

过程抽象和数据抽象是两种常用的抽象手段。

4.4.4复用性抽象

复用是指同一实体不做修改或稍加修改就可以多次重复使用，将复用的思想用于软件开发，称为软件复用。

将软件的重用部分称为软构件。

4.4.5灵活性设计

保证软件灵活性设计的关键是抽象。

在设计中引入灵活性的方法如下：

1）降低耦合并提高内聚（易于提高替换能力）；

2）建立抽象（创建有多态操作的接口和父类）；

3）不要将代码写死（消除代码中的常数）；

4）抛出异常（由操作的调用者处理异常）；

5）使用并创建可复用的代码。

4.4.6预防过期

4.4.7可移植性设计

4.4.8可测试性设计

4.4.9防御性设计

4.5面向数据流的设计

面向数据流的设计方法也称为过程驱动的设计方法。

4.5.1设计过程

（1）复查并精化数据流图；

（2）确定数据流图中数据流的类型，典型的数据流类型有变换型数据流和事务型数据流；

（3）导出初始的软件结构图；

（4）逐级分解；

（5）精化软件结构；

（6）导出接口描述和全局数据结构。

4.5.2典型的数据流类型和系统结构

1）变换型数据流与变换型系统结构图

工作过程大致分为3步：

获取数据、变换数据和给出数据。

2）事务型数据流与事务型系统结构图

4.5.3变换型映射方法

是一系列设计步骤的总称。

变换分析方法由4步组成：

重画数据流图；

区分有效（逻辑）输入，有效（逻辑）输出和中心变换部分；

进行一级分解，设计上层模块；

进行二级分解，设计输入、输出和中心变换部分的中、下层模块。

4.5.4事务型映射方法

在很多软