软件工程各阶段各图
软件工程---交互建模之交互图,顺序图与协作图
2.5 消息
格式
[前缀][守卫条件][顺序表达式][返回值:=]消息名([参数列表])
例：
2: display ()
简单消息
1.3.1: p:=find()
带返回值的嵌套消息
[x<0] 4: invert(x, color) 条件消息
3.1 *[x = 1..10] : update() 循环消息
[ 条件子句 ] 条件子句一般用来表示分枝而不是用作守卫条件[x<0]是两个可
以用来分枝的条件子句这两个条件只能有一个为真因而只有一 个分枝被执行(即发送与分枝有关的消息) 条件子句和循环子句都可以用伪代码或真正的编程语言来表示 序列表达式用冒号结束
返回值、消息名和参数表
返回值表示一个操作调用(即一个消息)的结 果
顺序图中消息编号可显示，也可不显示。 协作图中必须显示Procedure Call） 异步（Asynchronous） 返回（Return） 自关联消息（Self Message）
2.5 消息
UML三种消息：
调用（Procedure Call） 发送者把消息发送后，等待直到接收者返回控制， 可以表示同步(synchronous message)； 实心箭头符号
包括对象名和类名 类名（匿名对象） 对象名（不关心类）
2.3 生命线
生命线（Lifeline）：
每个对象都有自己的生命线，用来表示在该用例中一个对象在一段时 间内的存在
垂直的虚线 如果对象生命期结束， 则用注销符号表示 对象默认的位置在图 顶部，表示对象在交互 之前已经存在 如果是在交互过程中 由另外的对象所创建， 则位于图的中间某处。
顺序图
面向时间描述对象交互的图
协作图
《软件工程》PPT课件
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程生命周期各阶段中的图示例
软件工程中的图软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２.可行性研究３.需求分析４.总体设计（概要设计）５.详细设计６.编码和单元测试７.综合测试８.软件维护下面我们就说说各个阶段中与图的难解难分。
１. 问题定义问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功能。
２. 可行性研究可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。
这个阶段的分析主要涉及以下几个图形工具。
2.1 系统流程图系统流程图是描述系统物理模型的一种传统工具。
它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。
系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
2.2 数据流图数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。
数据流图的基本符号：数据流图的使用例子：2.3 数据字典数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。
数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。
３. 需求分析需求分析阶段主要确定系统必须做什么。
比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。
3.1 E-R图E-r图的主要作用就是把用户的数据要求用可视化的图形呈现出来。
3.2 状态转换图状态转换图说白了就是系统的行为建模，就是通过描述系统的状态以及引起状态变化的事件来表示系统的行为，将系统运行时详细的状态变化呈现给用户。
软件工程各种图结构
调用模块 A,B,C
2. 结构图的绘制 • 学生成绩管理系统的结构图
概要设计方法
结构化方法 • 结构化方法又称面向数据流设计方法(Structured
Design，SD)。 • 设计步骤是先根据系统数据流图建立系统逻辑模型，
再进行结构设计。 1. 建立系统逻辑模型 （１）变换型数据流 （２）事务型数据流
如： 成绩单＝学号＋姓名＋1{课程名＋成绩}3
• 也可写为 成绩单＝学号＋姓名＋ {课程名＋成绩}
数据字典与图形工具
• 数据字典与图形工具应相辅相成、互相配 合，既要互相补充又要避免冗余。
• 系统分析员在编写数据字典和使用图形工 具时应遵守一些约定
需求分析举例
•
概要设计
软件结构设计的图形工具
盒图 盒图是Nassi和Shneiderman提出的，又称N_S图。
1. 盒图的符号
将下述含有GOTO语句的用程序流程图，改为N_S图。
学生成绩管理系统的 N-S 图。
PAD 图
基本符号
学生成绩管理系统的 PAD 图
判定表
1. 判定表的组成 • 左上部列出所有条件。 • 左下部列出所有可能做的工作。 • 右上部每一列表示各种条件的一种可能组合，所有列
画出学生成绩管理 系统的 IPO 图。
数据字典
• 数据字典(Data Dictionary ，DD) 是对实体-关系图、状态转换图和数据流图中出现的 所有数据对象、属性、关系、状态、数据流、文件、 处理等元素的定义的集合。
数据字典的内容 • １. 数据元素 • ２. 数据流 • ３. 数据存储 • ４. 数据处理
数据代码设计
产品开发流程图-五个阶段及PDT组织示意图(V1.0)
PAC-b20 计划决策评审
PAC-b30 YES 拟制合同书
合同书
NO LPDT-b110
计划阶段 项目总结
计划阶段 总结报告
流程终结
LPDT-b110
计划阶段 项目总结
计划阶段 总结报告
PA-b30
资料归档及更 新项目环境
进入开发 阶段流程
-
产品决策委员会 （PAC）
组建PDT 团队
PDT任命模 板
LPDT-a10 召开项目
开工会
PA-a10 构建项目
环境
项目环境检 查清单
制定里程碑计划与概 念阶段详细计划
LPDT-a20
制定里程碑计划 与概念阶段详细
计划
PA-a20
协助制定里程碑 计划与概念阶段
详细计划
里程碑计划 模板
概念阶段详 细计划模板
PQA-a10 参与制定里程碑 计划与概念阶段
LPDT-b90
准备计划决策 汇报材料
计划决策 汇报PPT
PQA-b50 参与优化商业
计划书
RDPDT-b40
参与优化商业 计划书
PQA-b60 参与制定开发至发布 阶段项目详细计划
RDPDT-b50 参与制定开发至发布
阶段项目详细计划
TEPDT-b20 参与TR2评审
PROPDT-b20 参与TR2评审
MFPDT-b40
参与概要设计 评审
MFPDT-b50 整合物料需求 计划
研发物料需 求计划
TEPDT-b50 参与优化商业
计划书
PROPDT-b40 参与优化商业
计划书
MFPDT-b60 参与优化商业
计划书
软件工程各种图结构
软件工程各种图结构本文档旨在提供一个软件工程中各种图结构的详细说明和范例。
1.引言软件工程中的图结构是表示软件系统的重要工具之一。
通过对图结构的使用，可以清晰地描述软件系统中各个组件之间的关系，帮助开发人员理解系统的结构和功能。
本文档旨在介绍常见的软件工程图结构，并提供范例供参考。
2.需求图需求图是软件工程中最基础的图结构之一，用于表示系统的需求和功能。
需求图通常由用例图和活动图组成，用例图用于描述系统的外部行为，活动图用于描述系统的内部行为。
以下是一个需求图的范例：[插入需求图范例]3.静态结构图静态结构图用于表示系统的静态结构，主要包括类图、对象图和包图。
类图用于描述系统中的类及其关系，对象图用于描述系统中的对象及其关系，包图用于描述系统中的包及其关系。
以下是一个静态结构图的范例：[插入静态结构图范例]4.动态行为图动态行为图用于表示系统的动态行为，主要包括序列图、状态图和活动图。
序列图用于描述系统中的交互过程，状态图用于描述系统中的状态变化，活动图用于描述系统中的业务流程。
以下是一个动态行为图的范例：[插入动态行为图范例]5.部署图部署图用于表示软件系统的部署结构，包括系统中的各个节点和节点之间的关系。
节点可以是物理设备或者软件执行环境。
以下是一个部署图的范例：[插入部署图范例]6.附件本文档附带的附件包括需求图范例、静态结构图范例、动态行为图范例和部署图范例。
7.法律名词及注释在本文档中，涉及到的法律名词及其注释如下：●著作权：指创作作品的权利，包括复制、发行等权利。
●商标：指标识商品来源的标志，可以是图形、文字、颜色等。
●专利：指对发明的技术解决方案的专有权利。
软件工程完整PPT课件
2021/3/9
10
④局部化。要求在一个物理模块内集中逻辑上相互关联 的计算资源，保证模块间具有松散的耦合关系，模块 内部有较强的内聚性，这有助于控制解的复杂性。
⑤确定性。软件开发过程中所有概念的表达应是确定的、 无歧义且规范的。
⑥一致性。包括程序、数据和文档的整个软件系统的各 模块应使用已知的概念，内外部接口应保持一致，系 统规格说明与系统行为应保持一致。
2021/3/9
14
2. 需求分析方法 常见的需求分析方法有：
①结构化分析方法。 ②面向对象的分析方法。
2021/3/9
15
2.2结构化分析方法
（1）关于结构化分析方法 结构化分析方法的实质是着眼于数据流，自顶向下，逐层分解，
建立系统的处理流程，以数据流图和数据字典为主要工具，建 立系统的逻辑模型。 结构化分析的步骤如下：
3. 信息隐蔽 信息隐蔽使得一个模块内包含的信息（过程和数据）
对于不需要这些信息的模块来说，是不能访问 的。
2021/3/9
24
4. 模块独立性 每个模块完成一个相对独立的特定子功能，并且 和其他模块之间的接口很简单。
模块的独立程度可以由两个定性标准来衡量，这 两个标准分别称为耦合性和内聚性。藕合衡量不 同模块彼此间互相依赖（连接）的紧密程度；内 聚衡量一个模块内部各个元素彼此间结合的紧密 程度。
⑦完备性。软件系统不丢失任何重要成分，完全实现系 统所需的功能。
⑧可验证性。开发大型软件系统需要对系统自顶向下， 逐层分解。系统分解应遵循容易检查、测评、评审的 原则，以确保系统的正确性。
2021/3/9
11
1.5软件开发工具与软件开发环境
1. 软件开发工具 软件开发工具是指可以用来帮助开发，测试、分 析、维护其他计算机程序及其文档资料，实现软 件生产过程自动化的一类程序。 软件工具主要包括需求分析工具、设计工具、编 码工具、确认工具、维护工具等。
软件工程-第2章-数据流图
Data flow diagram of the main graphic elements （主要图形元素）
编号 加工 名称
Example of DFD:
DFD of Bank Withdrawals Process
描述银行取款过程的数据流图
Example of DFD:
Each element must have a name DFD can not be attached to control flow In the beginning, the trivial details could be ignored, in order to concentrate on the main data stream
图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节，以集中精力于主要数据流
Naming for each elements of DFD If it is difficult to give a name, it is possible because DFD decomposition problem Data Flow (Database): Using data noun Processing: using verb-object phrase. Data source: using normal noun
Tools of Software Need Analyzing 需求分析工具
Ning Hong-yun 2009.8
Tools of Software Need Analyzing 需求分析工具
Data flow diagram ( DFD, 数据流图)
软件工程---状态图
语法形式： exit/动作名
3.内部转移---Do动作（do action），用于标 记内部活动，用来指定处于该状态时执行的 动作。 语法形式： do/动作名
内部转移不会改变对象的状态，内部转移在 入口动作执行完毕后开始执行。
4. 还可以添加其他事件和动作
event用来指定当特定事件触发时发生指定动 作，但此事件不会激发状态的改变，属于内部 活动。
（2）中间状态----由一个带圆角的矩形表示。
内部活动
注意：由于入口动作和
与状态相关的动作
出口动作是隐式地激活， 因此它们既没有参数也
在一个状态中允许有多个动作。没有守卫条件。
1.入口动作 （entry action），用来指定进入状态时
发生的动作。
语法形式： entry/动作名 2.出口动作（exit action），用来指定离开该状态时
状态图
状态和状态图 状态图的组成 转换的种类 状态图建模技术
用例图（功能模型）： 从用户的角度描述系统能提供哪些功能。
• 结构模型视图（静态）： 类图：描述系统的静态结构； 对 象图：描述系统在某个时刻的静态结构； 包图：将类分组成更高层次的静态结构。
• 行为模型视图（动态） 顺序图：按时间顺序描述系统元素之间的交互； 协作图：从时间和空间的顺序描述系统元素之间的交互； 状态图：描述系统元素对事件的响应引起的状态转换； 活动图：描述系统元素的活动。
图 带有历史指示器的软件安装过程状态图
2.2 转换（转移）
转换用带箭头的直线表示，一端连接源状态即转 出的状态，箭头一端连接目标状态即转入的状态。
转移连接了源状态和目标状态。但需要各种条件 才能激活转移。这些条件包括事件、监护条件和 动作。
计算机科学导论：第十章-软件工程
十软件工程软件工程是建立在这样一个基础上，即利用合理的工程方法和原则来获得在真实机器上工作的可靠软件10.1 软件的生命周期软件最初由开发者小组开发。
通常，在它需要修改之前会使用一段时间。
由于软件中会发现错误、设计改变规则或公司本身发生变化，这些都导致需要经常修改软件。
为长久使用考虑软件应该被修改。
使用和修改，这两个步骤一直进行下去直到软件过时。
“过时”意味着因效率低下、语言过时、用户需求的重大变化或其他因素而导致软件失去它的有效性。
开发过程模型开发过程包括4个阶段：分析、设计、实现和测试最常见的两种开发过程模型1.瀑布模型: 开发过程只有一个方向的流动，这意味着前一个阶段不结束，后一个阶段不能开始优缺点–优点：在下一个阶段开始前每个阶段已经完成–缺点：如果过程中一部分有问题，必须检查整个过程1.增量模型(迭代模型): 软件的开发要经历一系列步骤。
开发者首先完成整个系统的一个简化版本，这个版本表示了整个系统，但不包括具体的细节10.2 分析阶段整个开发过程始于分析阶段，这个阶段生成规格说明文档，这个文档说了软件要做什么，而没有说明如何去做分析阶段的两种独立方法•面向过程分析：依赖于实现阶段使用过程编程语言•面向对象分析：依赖于实现阶段使用面向对象编程语言面向过程分析如果实现阶段使用过程式语言，那么面向过程分析（也称为结构化分析或经典分析）就是分析阶段使用的方法。
这种情况下的规格说明有使用多种建模工具•数据流图: 数据流图显示了系统中数据的流动。
•实体关系图: 用于数据库设计•状态图: 它通常用于当系统中的实体状态在响应事件时将会改变的情况下面向对象分析如果实现阶段使用面向对象语言，那么面向对象分析就是分析阶段使用的方法。
规格说明文档至少使用下列几个工具,•用例图: 给出了系统的用户视图:它显示了用户与系统间的交互。
4种组件–系统、用例、动作者和关系。
•系统(用矩形表示)执行功能。
•系统中的行动由用例(圆角的矩形)显示•动作者(线条人物)是使用系统的某人或某事。
UML各种图总结-精华
UML各种图总结-精华UML（UnifiedModelingLanguage）是一种统一建模语言，为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
下面将对UML的九种图+包图的基本概念进行介绍以及各个图的使用场景。
一、基本概念如下图所示，UML图分为用例视图、设计视图、进程视图、实现视图和拓扑视图，又可以静动分为静态视图和动态视图。
静态图分为：用例图，类图，对象图，包图，构件图，部署图。
动态图分为：状态图，活动图，协作图，序列图。
1、用例图（UseCaseDiagrams）：用例图主要回答了两个问题：1、是谁用软件。
2、软件的功能。
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。
2、类图（ClassDiagrams）：用户根据用例图抽象成类，描述类的内部结构和类与类之间的关系，是一种静态结构图。
在UML类图中，常见的有以下几种关系:泛化（Generalization）,实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序：泛化=实现>组合>聚合>关联>依赖2.1.泛化【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。
例如：老虎是动物的一种，即有老虎的特性也有动物的共性。
2.2.实现【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现。
2.3.关联【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。
双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
【代码体现】：成员变量2.4.聚合【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。
软件工程的23种设计模式的UML类图
软件工程的23种设计模式的UML类图0 引言谈到设计模式，绝对应该一起来说说重构。
重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，能够让我们在写程序的时候能够不需事先考虑太多的代码组织问题，当然这其中也包含了应用模式的问题。
尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到要紧的模块划分我觉得就够了。
换句话说，这时就能写代码了。
这就得益于重构的思想了。
假如没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多事实上并非非常稳固的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。
在重构与设计模式的合理应用之下，我们能够相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构与模式来改善我们的代码质量。
因此，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的懂得。
重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提早考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全能够先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。
1 创建型1.1FactoryMethod思想：Factory Method的要紧思想是使一个类的实例化延迟到其子类。
场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者者比较容易变化。
如今，假如直接将实例化过程写在某个函数中，那么通常就是if-else或者select-case代码。
假如，候选项的数目较少、类型基本确定，那么这样的if-else还是能够同意的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时，这样的if-else代码就会变得比较不那么容易保护了。
软件工程-第15章第3节图文模板
版本 1.1.1
版本 1.1.2
4
5
15.3.3 版本控制
软件工程过程中某一阶段的变更，均要引起软件配 置的变更，这种变更必须严格加以控制和管理，保 持修改信息，并把精确、清晰的信息传递到软件工 程过程的下一步骤。 变更控制包括建立控制点和建立报告与审查制度。 对于一个大型软件来说，不加控制的变更很快就会 引起混乱。因此变更控制是一项最重要的软件配置 任务，变更控制的过程如图15.8所示。其中“检出”
15.3.2 软件配置项
(9) 数据库描述(模式和文件结构、初始内容)。 (10) 用户手册。 (11) 维护文档(软件问题报告、维护请求和工程 变更次序)。 (12) 软件工程标准。 (13) 项目开发小结。 此外，许多软件工程组织把配置控制之下的软件
15.3.3 版本控制
软件配置实际上是一动态的概念，它一方面随着软 件生存期向前推进，SCI的数量在不断增多，一些 文档经过转换生成另一些文档，并产生一些信息； 另一方面又随时会有新的变更出现，形成新的版本。 系统不同版本的一种表示如图15.7所示，在这个版 本演变图中各个结点是一个完全的软件版本。软件 的每一个版本都是SCI(源代码、文档及数据)的一 个收集，且各个版本都可能由不同的变种组成。
15.3.3 版本控制
图的右边具体说明一个简单的程序版本：它由1，
2，3，4和5版本使用单色显示器
版本
版本
时使版本用。版本因此版，本 可以1.3 定义1.4版本的两个变种1 。
1.0
1.1
1.2
版本
版本
2
3
此演变图显示了
2.0
2.1
变种
软件的修改情况
15.3.1 基线
系统工程 需求分析 软件设计 程序编写
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
我们通常都是对图形化的东西情有独钟，我们小时候的启蒙教育基本上也都是从图形化开始的，我们曾经看过的连环画、漫画、看图识字等等。
因为图形能将一个抽象的东西具体化、形象化，图形化的表述能将一个用文字语言无法表达清楚或很难表达的观点、事物、科学概念等清晰的呈现出来。
这就是为什么我们相比晦涩难懂文字更喜欢形象生动的图形的原因。
软件工程导论作为软件工程中非常重要的一门课程，通常因为其偏文科性、理论性、概念性而得不到人们的重视，但幸运的是在软件工程导论中有我们非常易于接受、理解的东西——图，否则我们自己会把自己害得很惨（软件工程导论真的很重要哦！）。
软件工程导论中一般把软件的开发分为八个阶段：１.问题定义２.可行性研究３.需求分析４.总体设计（概要设计）５.详细设计６.编码和单元测试７.综合测试８.软件维护。
下面我们就说说各个阶段中与图的难解难分。
１. 问题定义
问题定义阶段主要是根据用户的需求来定义用户需要解决的问题，用户要实现哪些功能。
２. 可行性研究
可行性研究阶段就是看是否有一种使其在最小的代价，尽可能短的时间内，利益最大化的情况下解决问题的方案。
这个阶段的分析主要涉及以下几个图形工具。
2.1 系统流程图
系统流程图是描述系统物理模型的一种传统工具。
它是表达数据在系统各部件之间流动的情况，而不是对数据加工处理的控制过程，它是物理数据流图而不是程序流程图。
系统流程图形象的呈现了软件的功能，即使不懂软件的人也可以轻松的看懂，可以说它是软件设计师与用户之间沟通、交流的有效工具。
2.2 数据流图
数据流图是从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
如果说系统流程图能让用户更好的明白系统的功能，那么数据流图则让用户更加明白系统的工作原理。
2.3 数据字典
数据字典就是数据的信息的集合，也可以说就是对上面提到的数据流图中的所有元素的定义的集合。
数据字典的主要作用就是在软件的分析与设计阶段方便我们查阅不甚了解的数据的描述信息。
３. 需求分析
需求分析阶段主要确定系统必须做什么。
比如用户对系统的要求，确定目标系统所有的功能，确定系统运行的硬件和软件环境，系统性能要求，出错处理要求，接口需求，验证软件需求等等。
3.1 E-r图
E-r图的主要作用就是把用户的数据要求用可视化的图形呈现出来。
3.2 状态转换图
状态转换图说白了就是系统的行为建模，就是通过描述系统的状态以及引起状态变化的事件来表示系统的行为，将系统运行时详细的状态变化呈现给用户。
3.3 层次方框图
层次方框图像用户呈现的是数据的层次结构。
3.4 Warnier图
Warnier图的作用和层次方框图的作用基本相同，只不过Warnier图的描述手段更多。
3.5 IPO图
IPO图是输入、处理和输出图的简称，它清楚的描述了输入数据、处理数据、输出数据之间的关系。
４. 总体设计
需求分析阶段已经确定了系统要做什么的问题，而总体设计就是要弄明白怎么做的问题，总体设计的目的就是从宏观上概括的说系统应该怎样实现，具体一点就是要明确系统有哪些模块组成，以及这些模块之间的关系是怎样的。
4.1 层次图
层次图是用来描述软件的层次结构的。
4.2 HIPO图
HIPO图= 层次图+输入+处理+输出
4.3 结构图
结构图和层次图类似，都是描述软件结构的图形工具。
５. 详细设计
详细设计阶段就是在总体设计的基础上要确定怎样具体的详细的实现系统所要求的功能，要对系统进行精确的描述。
5.1 程序流程图
程序流程图是对程序控制流程的直观描述。
5.2 盒图
出于要有种不允许违背结构设计精神图形工具考虑Nassi和shneiderman提出了盒图又称为N—S图。
5.3 问题分析PAD图
PAD图就是用二维树形结构图来表示程序的控制流。
６. 编码和单元测试
编码和单元测试阶段主要是对详细设计阶段的详细描述给以具体的实现和模块的测试。
７. 综合测试
综合测试包括对系统的各个组件和功能的测试，要求覆盖软件系统的各个功能点，并根据被测软件的需求测试软件的性能、易用性等方面的内容，达到对软件全方面测试的目的。
８. 软件维护
软件维护阶段是软件生命周期中最后的一个阶段，也是最长的一个阶段，软件维护主要任务是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改，修改时应充分利用源程序。
修改后要填写程序改登记表，并在程序变更通知书上写明新旧程序的不同之处。