- 基于软件功能的划分
- 系统软件
- 支撑软件
- 应用软件
- 基于软件工作方式的划分
- 实时处理软件
- 分时软件
- 交互式软件
- 批处理软件
- 基于软件规模的划分
- 微型软件
- 小型软件
- 中型软件
- 大型软件
- 巨大型软件
- 极大型软件
- 基于软件失效的影响进行划分
- 基于软件服务对象的范围进行划分
- 定制软件
- 产品软件
- 产品不符合用户的实际需要；
- 软件开发生产率不高，不能满足客观需要；
- 软件产品质量差；
- 对软件开发成本和进度的估计不准确；
- 可维护性差；
- 软件的文档资料不完整和不合格；
- 软件成本逐年上升。
1.中心思想
把软件当作一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护。
2.目的
实现按预期的进度和经费完成软件生产计划，提高软件的生产率和可靠性。
3.基本流程
- 首先进行系统调查和系统分析;
- 再进行逻辑设计、物理设计;
- 最后才编制实施；
- 反复测试;
- 试运行后，再投入长期运行;
- 在运行中不断维护、完善。
4.原则
- 分解
- 信息隐蔽
- 模块化
- 标准化
1.概念
任何有生命的动物、植物和人，都有一个生存周期(Life Cycle)，例如人的生存周期为胎儿、婴儿、幼儿、儿童、少年、青年、中年、老年、死亡。
没有生命的事物或实体，例如PC机、路由器、家具、房子、汽车，它们也有一个生存周期，这个生存周期就是使用寿命，即生产周期加上使用周期。
软件生存周期与开发模型有关。
2.常见过程
-
制定计划——解决什么问题，目标及其可行性（技术、人员、财力、社会）
-
需求分析——做什么、验收标准
-
总体设计——怎么做
-
详细设计——具体怎么做
-
程序编写——实现
-
软件测试——保证软件质量
-
运行/维护——保证正常而可靠地运用
1.瀑布模型（重点）
瀑布模型(WaterfallModel)又称流水式过程模型，它将软件开发过程模仿旅游景点的阶梯瀑布，由上向下一个阶梯一个阶梯地倾泻下来，最后进入一个风平浪尽的大湖，这个大湖就是软件企业的产品库。 
2.增量模型
增量模型将软件产品看作一组增量构件，每次设计、实现、集成、测试和交付一块构件，直到所有构件全部实现为止。 
3.迭代模型
迭代是产生可执行的产品发布的完整开发循环，所发布的产品是开发过程最终产品的子集，它将通过一次又一次的迭代递增成长，最后形成最终软件系统或产品。 
4.原型模型
以某个软件原型为参照模型的开发方法，叫做原型法。在初步需求分析之后，马上向客户展示一个软件产品原型，对客户进行培训，让客户试用，在试用中收集客户意见，修改原型，再让客户试用，反复循环几次，直到客户确认为止。
5.敏捷开发
- 结构化设计：切合瀑布模型，从上而下的分析思路
- 面向对象：从下至上
1.问题定义阶段
目的：弄清用户需要计算机解决的问题根本所在，以及项目所需的资源和经费。
任务：在向用户调查的基础上，编写《关于系统规模和目标的报告书》。
2.可行性研究要做什么（重点）
-
回答“对于上一个阶段所确定的问题有行得通的解决办法吗?”
-
系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程。
-
研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。
3.可行性研究主要方面（重点）
-
技术可行性，使用现有的技术能实现这个系统吗?
-
经济可行性，这个系统的经济效益能超过它的开发成本吗?
-
操作可行性，系统的操作方式在这个用户组织内行得通吗?
4.可行性研究其他方面
-
运行可行性，系统的运行方式是否可行？
-
法律可行性，系统是否侵犯他人、集体或国家的利益，是否违反法律？
-
分析员应该为每个可行的解法制定一个粗略的实现进度。
-
如果问题没有可行的解，分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，分析员应该推荐一个较好的解决方案，并且为工程制定一个初步的计划。
-
可行性研究需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。
1.基本符号
2.系统符号
3.如何画系统流程图（例子）
某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件上。当仓库零件数量发生变化时，应该及时修改库存清单主文件。如果哪种零件的库存量少于它的库存临界值，则应该报告给采购部门以便定货，规定每天向采购部门送一次定货报告。
该装配厂使用一台小型计算机，处理更新库存清单主文件和产生定货报告。零件库存量的每一次变化称为一个事务，由放在仓库中CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。
分析 部件：包括程序、文档、数据库、人工过程等
程序：更新库存清单程序、产生定货报告程序
文档：定货报告
数据：磁盘上的库存清单主文件、磁带上的定货信息、CRT终端输入事务
人工过程：无
流程图：
4.分层
首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能；然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。
第一层：描绘系统关键功能（仅用基本符号） 
第二层：扩展系统关键功能 
第三层：合成后的系统流程图 
1.数据流图主要做什么？
数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
2.符号（看图描述功能）
基本符号 
数据源点/终点：通常是人或部门，可重复表示；
处理：一个处理框可以代表一系列程序、单个程序或程序的一个模块；
数据存储：可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等，数据存储是处于静止状态的数据；
数据流：描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件 ，数据流是处于运动中的数据。
附加符号 
3.例子
假设采购部每天需要一张定货报表，报表按零件编号排序，表中列出所有需要再次定货的零件。对于每个需要再次定货的零件，应该列出下述数据：零件编号，零件名称，定货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存量少于库存量的临界值时，就应该再次定货。
- 从问题描述中提取数据流图的4种成分
-
数据的源点/终点
-
“通过放在仓库中的CRT终端把事务报告给定货系统”——仓库管理员是数据源点；
-
“采购部每天需要一张定货报表”——采购员是数据终点。
-
-
处理
-
“采购部需要报表”，——产生报表；
-
事务的后果是改变零件库存量，因此对事务进行的加工是另一个处理——处理事务。
-
-
数据流：
-
“系统把定货报表送给采购部”——定货报表；
-
“事务需要从仓库送到系统中”——事务。
-
-
数据存储：
-
处理事务和产生报表这两个处理在时间上明显不匹配，用来产生定货报表的定货信息必须存放一段时间——定货信息；
-
零件库存量和库存量临界值需要存储——库存清单。
-
-
- 画基本系统模型 由若干个数据源点/终点和一个处理组成。
- 细化，描绘系统的主要功能（功能级数据流图）
- 对系统主要功能进一步细化.
- 当进一步分解涉及如何具体的实现一个功能时就不应该再分解了。
- 当对数据流图分层细化时必须保持信息连续性，也就是说，当把一个处理分解为一系列处理时，分解前和分解后的输入输出数据流必须相同。
- 注意对处理进行编号的方法。
数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。
是数据流图和数据字典共同构成系统的逻辑模型。
1.主要任务
- 确定对系统的综合要求
-
功能需求
-
性能需求
-
可靠性和可用性需求
-
出错处理需求
-
接口需求
-
约束
-
逆向需求
-
将来可能提出的要求
-
- 分析系统的数据要求
-
建立数据模型——ER图
-
描绘数据结构——层次方框图和Warnier图
-
数据结构规范化
-
- 导出系统的逻辑模型
- 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
- 修正系统开发计划
- 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
2.需求分析目的
需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。
1、数据模型
2、功能模型
3、行为模型 
1.概念
概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，且与在软件系统中的实现方法无关。
2.作用
实体-联系图(Entity-Relation Diagram)用来建立数据模型,在数据库系统概论中属于概念设计阶段，形成一个独立于机器，独立于DBMS的ER图模型。
1.层次方框图（填空）
层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；
下面的各层矩形框代表这个数据的子集；
最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。 
2.IPO图（了解）
IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。
基本形式：是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。在IPO图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。 
改进的IPO图：这种图中包含某些附加的信息，在软件设计过程中将比原始的IPO图更有用。
在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。 
1.怎样验证？
一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。
2.验证方法
-
验证需求的一致性
-
人工技术审查
-
形式化的描述软件需求的方法
-
-
验证需求的现实性
- 仿真或性能模拟技术
-
验证需求的完整性和有效性
- 开发原型系统
1.结构化设计总体设计步骤
- 设想供选择的方案
- 选取合理的方案
- 推荐最佳方案
- 功能分解
- 设计软件结构
- 设计数据库
- 制定测试计划
- 书写文档
- 审查和复审
2.结构化分析的方法（图）（理解）（未完成）
1.模块化（原理）
就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
2.模快化和软件成本（图)（判断模块化好不好）
评价一种设计方法定义模块能力的五条标准：
1、模块可分解性
2、模块可组装性
3、模块可理解性
4、模块连续性
5、模块保护性
1.耦合
是对一个软件结构内不同模块之间互连程度的度量。
2.内聚
标志一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。
3.怎样把需求分析转化魏模块图（未完成）
1.层次图
层次图用来描绘软件的层次结构。很适于在自顶向下设计软件的过程中使用。 
2.结构图
结构图是进行软件结构设计的另一个有力工具。结构图和层次图类似，也是描绘软件结构的图形工具。
■层次图和结构图并不严格表示模块的调用次序，多数人习惯按调用次序从左到右画模块； ■层次图和结构图并不指明何时调用下层模块； ■层次图和结构图只表明一个模块调用那些模块，没有表示模块内还有没有其他成分； ■通常用层次图作为描绘软件结构的文档； ■由层次图导出结构图的过程，可以作为检查设计正确性和评价模块独立性的好方法。
1.两个方法
-
变换流
- 信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统。
-
事务流
-
数据沿输入通路到达一个处理T，T根据输入数据的类型在若干个动作序列中选出一个来执行。处理T称为事务中心，它完成下述任务：
-
接收输入数据；
-
分析每个事务以确定它的类型；
-
根据事务类型选取一条活动通路。
-
-
-
2.懂得拆分以及懂得判断（未完成）
107-109 ep.511图
5.3判定表图（重点）
127-128
5.5程序复杂度
给图分析节点、边、区域、计算复杂度 
给代码判断风格 
1、软件是一种©。 A、 程序 B、 数据 C、 逻辑产品 D、 物理产品
2、软件生存周期中花费最多的阶段是( )。 A、 详细设计 B、 软件编码 C、 软件测试 D、 软件维护
3、软件开发方法是( )。 A、 指导软件开发的一系列规则和约定 B、 软件开发的步骤 C、 软件开发的技术 D、 软件开发的思想
4、瀑布模型本质上是一种( )模型。 A、 线性顺序 B、 顺序迭代 C、 线性迭代 D、 能及早见到产品的
5、在软件开发模型中,提出最早、应用最广泛的模型是( )。 A、 瀑布模型 B、 喷泉模型 C、 快速原型模型 D、 螺旋模型
6、瀑布模型不适合用于( )的软件开发。 A、 需求模糊不清 B、 用户不能参与开发 C、 用户对计算机不了解 D、 开发人员对业务知识不熟悉
7、软件工程的出现是由于( )。 A、 软件危机的出现 B、 计算机硬件技术的发展 C、 软件社会化的需要 D、 计算机软件技术的发展
8、瀑布模型突出的缺点是不适应( )的变动。 A、 算法 B、 程序语言 C、 平台 D、 用户需求
9、快速原型的主要优点不包括( )。 A、 能让用户参与开发、给出反馈 B、 尽早把需求分析清楚,以降低风险 C、 尽早地发现问题、纠正错误 D、 对软件分析设计人员的素质要求不高
10、在软件生存周期中,能准确地确定“软件系统必须做什么”的阶段是( )。 A、 总体设计 B、 详细设计 C、 可行性研究 D、 需求分析
11、螺旋模型是一种将瀑布模型和(a )结合起来的软件开发模型。 A、 增量模型 B、 专家系统 C、 喷泉模型 D、 变换模型
12、快速原型的主要问题在于( )。 A、 缺乏支持原型开发的工具 B、 要严格控制原型构造的迭代 C、 终端用户对原型不能理解 D、 软件的测试和文档更新困难
13、软件可行性研究的目的是( )。 A、 证明软件开发项目可行 B、 证明软件开发项目不可行 C、 阐述软件开发项目值得或不值得做 D、 为了确定软件开发项目要不要做
14、技术可行性研究要解决的问题是( )。 A、 从技术方面说明项目是否可行 B、 从技术上定义项目要解决的问题 C、 给出项目开发可行的技术路线 D、 给出精简的项目需求设计报告
15、可行性研究的步骤首先是( )。 A、 确定项目目标,即对要解决的问题进行定义 B、 研究项目要求 C、 对项目目标进行可行性分析 D、 给出可行的解决方案
16、可行性研究的任务不包括( )。 A、 技术可行性 B、 经济可行性 C、 法律可行性 D、 政治可行性
17、系统流程图是一种传统工具,用于描绘( )。 A、 逻辑模型 B、 程序结构 C、 体系结构 D、 物理系统
18、可行性研究实质上是要进行一次( )需求分析,设计过程。 A、 简化、压缩的 B、 详细的 C、 彻底的 D、 深入的
19、需求分析最终结果是产生( )。 A、 项目开发计划 B、 需求规格说明书 C、 设计说明书 D、 可行性分析报告
20、数据词典是用来定义( )中的各个成分的具体含义。 A、 流程图 B、 功能结构图 C、 结构图 D、 数据流图
21、在数据词典中,以下哪一项表示允许重复0至任意次( )。 A、 {} B、 0{ } C、 0{ }n D、 { }n
22、需求分析的任务是( )。 A、 正确说明让软件“做什么” B、 用DFD建模 C、 用DD建立数学模型 D、 给出需求规格说明书
23、需求分析是分析员经了解用户的要求,认真细致地调研、分析,最终建立目标系统的逻辑模型并写出( )的过程。 A、 模块说明书 B、 软件规格说明书 C、 项目开发计划 D、 合同文档
24、DFD的每个加工都必须有( )。 A、 一个输入和输出数据流 B、 一个输入数据流 C、 一个输出数据流 D、 一个输入或输出数据流
25、软件需求分析阶段的工作,可以分为四个方面:需求获取、需求分析、编写需求规格说明书以及( )。 A、 阶段性报告 B、 需求评估 C、 总结 D、 都不正确
26、DFD用于描述系统的( )。 A、 数据结构 B、 控制流程 C、 基本加工 D、 软件功能
27、数据流图(DFD)是( )方法中用于表示系统的逻辑模型的一种图形工具。 A、 SA B、 SD C、 SP D、 SC
28、需求规格说明书的作用不包括( )。 A、 软件验收的依据 B、 用户与开发人员对软件要做什么的共同理解 C、 软件可行性研究的依据 D、 软件设计的依据
29、结构化分析方法(SA)是一种面向( )的分析方法。 A、 数据结构 B、 数据流 C、 结构化数据系统 D、 对象
30、软件开发的需求活动,其主要任务是( )。 A、 给出软件解决方案 B、 给出系统模块结构 C、 定义模块算法 D、 定义需求并建立系统模型
31、借助于软件工具,可将( )容易地转换为高级语言源程序。 A、 程序流程图 B、 N-S图 C、 PAD图 D、 判定表
32、程序的三种基本结构是( )。 A、 过程、子过程和子程序 B、 递归、堆栈和队列 C、 顺序、选择和重复 D、 调用、返回和转移
33、软件详细设计的主要任务是确定每个模块的( )。 A、 算法和使用的数据结构 B、 外部接口 C、 功能 D、 程序
34、不属于详细设计工具的是( )。 A、 DFD图 B、 PAD图 C、 PDl D、 N-S图
35、下面描述中,符合结构化程序设计风格的是( )。 A、 使用顺序、选择和重复(循环)三种基本控制结构表示程序的控制逻辑 B、 模块只有一个入口,可以有多个出口 C、 注重提高程序的执行效率 D、 不使用goto语句
15、可行性研究的步骤首先是( )。 A、 确定项目目标,即对要解决的问题进行定义 B、 研究项目要求 C、 对项目目标进行可行性分析 D、 给出可行的解决方案
20、数据词典是用来定义( )中的各个成分的具体含义。 A、 流程图 B、 功能结构图 C、 结构图 D、 数据流图
26、DFD用于描述系统的( )。 A、 数据结构 B、 控制流程 C、 基本加工 D、 软件功能
29、结构化分析方法(SA)是一种面向( )的分析方法。 A、 数据结构 B、 数据流 C、 结构化数据系统 D、 对象
- 软件在运行和使用中也存在退化问题。
- 软件危机的产生主要是因为程序设计人员使用了不适当的程序设计语言。
- 软件同其他事物一样,有孕育、诞生、成长、成熟和衰亡的生存过程。
- 原型是软件的一个早期可运行的版本,它反映最终系统的部分重要特性。
- 软件开发过程中,一个错误发现得越晚,为改正它所付出的代价就越大。
- 文字处理软件Word属于系统软件。
- 面向对象开发方法的主要缺点是在适应需求变化方面不够灵活。
- 软件的维护与硬件维护本质上是相同的。
- 快速原型模型对软件开发人员的水平要求不高。
- 软件需求分析阶段要确定软件系统要“做什么”。
- 需求分析员可以参加最后的需求评审工作。
- 在软件生产过程中,需求信息的来源是项目经理。
- 需求分析阶段的任务是确定软件的功能。
- 软件需求规格说明书可作为可行性研究的依据。
- 画数据流图时可以加少量的控制流,使加工之间有时序的关系。
- 在数据流图中,带有箭头的线段表示的是控制流。
- 在数据代码设计时,应尽量让一条代码代表多个信息。
- 在输出界面设计时,要尽可能使用代码或缩写,以求简洁。
- 详细设计评审应尽可能和概要设计评审一同进行。
- 详细设计也称模块设计。
- 在数据代码设计时,应可能设计字母和数字混合代码。
10111 00001 10100 00001 0
“瀑布模型”名字的来源是，该模型将软件生命周期中六个阶段自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 
A、√ B、×
2、A公司计划开发一款应用软件，项目时间较为充裕，拟采用顺序化的流程开发，以下比较适合的软件过程模型是（ ）。 A、瀑布模型 B、快速原型模型
3、A公司计划开发一款应用软件，客户要求尽快看到软件的概貌，以便提出修改意见和建议，以下比较适合的软件过程模型是（ ）。 A、瀑布模型 B、快速原型模型
4、下图展示的是哪种软件过程模型？（ ） 
A、快速原型模型 B、瀑布模型
5、随着互联网产业不断发展，优化教育资源配置工作的不断进行，慕课（Massive Open online Course，MOOC）已成为互联网在教育领域下的一大应用成果和新兴的教育模式，受到国内外知名高等院校、企业、媒体和大众的关注。慕课作为一款在线教育产品，其需求是明确且清晰的，下图给出了慕课制作过程与软件过程之间的映射关系。请问，这是那种软件过程模型？（ ） 
6、《论语·为政》中孔子对自己的评价说：“吾十有五而志于学，三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲，不逾矩。”请问，如果把人生作为一个软件开发项目，孔子人生的生命周期属于哪种过程模型？（ ） A、瀑布模型 B、快速原型模型
7、包含风险分析的软件过程模型是（ ）。 A、增量模型 B、瀑布模型 C、螺旋模型 D、喷泉模型
8、A公司计划开发一款文本编辑软件，由于项目时间不够充裕，开发人员计划将项目分为几个版本发布，第一个版本只提供核心功能，以下最合适的软件过程模型是？ A、敏捷过程模型 B、快速原型模型 C、瀑布模型 D、增量模型
9、A公司计划开发一款商业软件，由于项目风险较大，可能需要经常项目变更，故开发人员希望在软件开发过程中加入风险分析，以下最适合的软件过程模型是？ A、瀑布模型 B、螺旋模型 C、快速原型模型 D、增量模型
10、增量模型本质上是一种 A、线性顺序模型 B、整体开发模型 C、非整体开发模型 D、螺旋模型
11、A公司计划开发一款应用软件，拟采用面向对象的方法进行开发，以下软件过程模型中最适合的是？ A、喷泉模型 B、瀑布模型 C、微软过程模型 D、Rational统一过程模型
12、软件生命周期模型不包括 A、瀑布模型 B、喷泉模型 C、Rational统一过程模型 D、用例模型
13、软件生命周期模型决定了软件系统的开发过程都必须按6个典型阶段顺序组织。 A、√ B、×
0ABBA ACDBC AD0
软件危机的典型表现：
- 产品不符合用户的实际需要；
- 软件开发生产率不高，不能满足客观需要；
- 软件产品质量差；
- 对软件开发成本和进度的估计不准确；
- 可维护性差；
- 软件的文档资料不完整和不合格；
- 软件成本逐年上升。
解决软件危机 既要有技术措施，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴科学。
（重点）瀑布模型特点 1、阶段间具有顺序性和依赖性 2、推迟实现的观点 3、质量保证的观点 瀑布模型的过程：制定计划 需求分析 设计 程序编写 软件测试 运行/维护
其他模型：快速原型模型、增量模型、螺旋模型、喷泉模型、Rational统一过程、敏捷过程
可行性研究方面：
- 技术可行性
- 经济可行性
- 操作可行性
可行性研究过程
- 复查系统规模和目标
- 研究目前正在使用的系统
- 导出新系统的高层逻辑模型
- 导出和评价可供选择的解法
- 推荐行动方针
- 草拟行动计划
- 书写文档提交审查
确定对系统的综合要求
- 功能需求
- 性能需求
与用户沟通获取需求的方法 1、访谈，访谈有两种基本形式，分别是正式的和非正式的访谈。 2、面向数据流自顶向下求精，结构化分析方法就是面向数据流自顶而下逐步求精进行需求分析的方法。 3、简易的应用规格说明技术 4、快速建立软件原型，快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。
（重点）软件需求规格说明 通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。
需求分析的工具： 1、实体联系图，为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型。 2、状态转换图，通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。 3、其他图形工具，层次方框图、Warnier图、IPO图
（重点） 1、模块化94页图5.1 概念：当模块数目增加时每个模块的规模将减小，开发单个模块需要的成本确实减少了；但是随着模块数目增加，设计模块间接口所需要的工作量也将增加。
2、抽象 3、退步求精 4、信息隐藏和局部化 5、模块独立 6、耦合：耦合是一个软件结构内不同模块之间互连程度的度量。 7、内聚：标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。
（重点）描绘软件结构的图形工具 1、层次图和HIPO图，看102页图5.3 2、结构图，看103页图5.5、104页图5.6 图5.7
面向数据流的设计方法 1、变换流 2、事物流
设计步骤 1、第一步，复查基本系统模型 2、第二步，复查并精化数据流图 3、第三步，确定数据流图具有变换特性还是事物特性 4、第四步，确定输入流和输出流的边界，从而孤立出变换中心 5、第五步，完成“第一级分解”（记得看109页图5.14） 6、第六步，完成“第二级分解”
面向数据结构的设计方法：Jackson图：顺序结构、选择结构、重复结构 （重点）计算环形复杂度的方法 1、流图中线性无关的区域数等于环形复杂度 2、流图G的环形复杂度V（G）=E-N+2，其中，E是流图中边的条数，N是结点数 3、流图G的环形复杂度V（G）=P+1，其中，P是流图中判定结点的数目。 看138页图6.15
了解编码风格 1、程序内部的文档 2、数据说明 3、语句构造 4、输入输出 5、效率
软件测试基础的目的：为了“破坏”已经建造好的软件系统—竭力证明程序中有错误，不能按照预定要求正确工作。
软件测试的目标 1、测试是为了发现程序中的错误而执行程序的过程 2、好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。 3、成功的测试是发现了至今为止尚未发现的错误的测试。
软件测试准则 1、所有测试都应该能追溯到用户需求 2、应该远在测试开始之前就制定出测试计划 3、把Pareto原理应用到软件测试中 4、应该从“小规模”测试开始，并逐步进行“大规模”测试 5、穷举测试是不可能的 6、为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
白盒测试技术（没有明确概念）
黑盒测试技术：黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，它可能发现白盒测试不易发现的其他类型的错误。
软件维护的定义 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 完善性维护占全部维护活动的50%-66% 改正性维护占17%-21% 适应性维护占18%-25% 其他维护活动只占4%左右
（重点）维护是软件生命周期的最后一个阶段，也是持续时间最长、代价最大的一个阶段。软件工程学的主要目的就是提高软件的可维护性，降低维护的代价。
面对对象的特点 1、以数据为中心 2、对象是主动的 3、实现了数据封装 4、本质上具有并行性 5、模块独立性好
（重点） 状态转换图表示行为 实体联系图表示数据 数据流图表示功能模型
非老师部分 1、软件生命周期概念对软件的开发有哪些指导作用。 软件生命周期是软件工程的一个重要的概念。把整个软件生命周期划分为若干个较小的阶段,每个阶段都有相对独立的任务和完成任务的步骤和方法,然后逐步完成各个阶段的任务,这有利于软件开发过程的组织和管理,从而降低了整个软件开发过程的困难程度,从而使规模庞大、结构复杂和管理复杂的软件开发变得容易控制和管理。
2、简述软件工程在软件开发中的作用和意义。 软件工程的主要思想是强调软件开发过程中应用工程化原则的重要性。软件工程的目标是实现软件的优质高产。软件工程的目的是在经费的预算范围内,按期交付出用户满意的、质量合格的软件产品。
3、简述可行性研究的步骤。 确定项目规模和目标；分析现有系统；建立新系统的逻辑建模；提出并评价解决方案；确定最终推荐的解决方案；草拟开发计划；提交可行性研究报告。
4、软件开发的早期,为什么要进行可行性研究?目标的可行性研究有几个方面? 许多软件开发问题都不能在预期的时间范围内或资源限制下得到解决。如果开发人员 没有尽早停止没有可行解决方案的开发项目,就会造成时间、资金、人力、物力的浪费。为 了降低软件开发失败的可能性, 需要进行软件可行性研究。可行性研究要从经济可行性、技术可行性、运行可行性和法律可行性四方面进行。
5、某航空公司为了方便旅客，拟开发一个机票预订系统。将旅客的信息（姓名、性别、工作单位、身份证号、旅行时间、旅行目的地等）输入该系统后，系统自动为旅客安排航班。打印出取票通知和票务账单。旅客可在航班的前一天凭取票通知和票务账单交款取票。系统校对无误后即打印出机票给旅客。要求： （1）提出问题定义；人工不易管理，手续繁琐 （2）分析此系统的可行性；技术 操作 经济 法律 技术可行性:使用现有的技术能够实现此系统,在现有资源(包括硬件资源、软件资源、技术人员的技术水平和已有的工作基础)条件下,技术风险不大,项目可以实现。 经济可行性:此系统能够方便旅客订票,具有一定的经济效益和社会效益。 法律可行性:此项目开发要符合航运系统相关要求。 操作可行性:现有制度、人员素质、操作方式可行。 （3）画出系统流程图。暂时不画
6、需求分析的任务是什么?怎样理解“做什么”和“怎么做”? 需求分析的基本任务是要准确地理解旧系统、定义新系统的目标,为了满足用户需要,回答“系统必须做什么”的问题,即确定系统必须完成哪些工作,对新系统提出完整、准确、清晰、具体的要求。具体任务是:明确问题定义、导出软件的逻辑模型、编写软件需求规格说明书。 “做什么”,即深入描述软件的功能和性能,确定软件设计的限制和软件与其他系统元素的接口细节,定义软件的其他有效性需求。 “怎么做”,即着手软件需求的实现:用比较抽象概括的方式确定目标系统如何完成预定的任务,确定系统的物理模型。
7、数据流图的作用是什么?它有哪些基本成分? 作用:(1)作为交流信息的工具(2)作为分析和设计的工具 基本成分:数据的源点或终点、数据加工、数据存储和数据流
8、数据输入界面设计的主要原则有哪些? 在设计数据输入界面时应做到:尽量简化用户的工作、减少输入的出错率;减轻用户的记忆负担、尽可能减少输入量并实现自动输入; 对共同的输入设置默认值; 使用代码或缩写; 自动填入已输入过的内容;列表式输入; 数据分组输入。
9、软件的详细设计阶段完成的主要任务是什么? (1)算法设计;(2)数据结构设计;(3)模块接口细节设计;(4)测试用例设计;(5)数据库物理设计;(6)数据代码设计;(7)其他设计;(8)编写详细设计说明书并进行评审。
10、代码设计的原则有哪些? 代码设计的原则是标准化、唯一性、可扩充性、简单性、规范性和适应性。
2015 年的时候，Facebook 推出了一个跨平台的移动端解决方案 React Native，只要用 Javascript 一门语言就可以将写好的代码运行于 iOS、Android 移动平台。所以在 2016 年的时候，某著名大型互联网公司的移动部门负责人非常看好这个技术，专门成立了项目组，用了不少人力，花了大半年时间将移动端 iOS、Android 产品迁移到 React Native 技术框架上。就在项目快要上线的时候，法务部门却发现 React Native 的开源许可协议是“BSD+ 专利”。 这个“BSD+ 专利”的许可协议是什么呢？BSD 的许可协议本身是开放的、没有限制的，但 Facebook 在此基础增加了一个“专利”协议。也就是说，如果对 Facebook 及其子公司提出专利诉讼，不管诉讼的项目是否与该协议有关，用户的所有专利权利也都会自动终止。也就是说，如果未来该公司因为专利问题与 Facebook 产生纠纷，那么该公司将会无条件输了官司。而目前该公司和 Facebook 是有竞争关系的，所以法务部门为了避免未来可能的纠纷，不得不叫停这个项目。而此时，他们在这个项目上投入的大量人力财力，相当于全打水漂了。即使后来 2018 年的时候，Facebook 把 React Native 的开源协议修改为友好的 MIT 协议，也为时晚矣。 类似的案例其实不在少数。许多公司老板或者部门负责人不是很懂技术，天马行空想到一个点子，或者看到某个热门技术（比如说团购、共享经济、人工智能、区块链），不做可行性研究就直接立项去做，耗费了不少人力、物力和时间成本不说，最后项目也不得不以失败告终。 为什么软件项目很少做可行性研究？ 可行性研究不是软件项目的专利，在很多其他工程领域，项目正式启动前，都会有可行性研究这一环节，而且一般都会请一家甚至多家专业的评估机构帮助做可行性分析，并出具可行性研究报告，然后项目方来决定是不是立项。拿建筑工程来说，你要在某条街上盖房子，却不做可行性研究，那么如果这条街两年后要拆迁，那就意味着你的房子也会面临被拆掉的命运，那损失就大了。
- “因为我们是软件项目，所以我们很特殊。” “我们很特殊”，这句话听着有没有很熟悉？软件项目确实有和其他工程项目不一样的地方。比如说软件项目很抽象，以至于在立项之前对于问题的描述（需求）和解决方案（技术方案）通常都是模糊不清的，只有随着项目的推进，才能逐步搞清楚需求。而可行性研究是基于问题和解决方案来分析的，因此这有点像“先有鸡还是先有蛋”的问题：你得先立项才能慢慢搞明白需求是什么，然后才能有解决方案；而你只有搞明白需求是什么，以及解决方案是什么，才能去做可行性研究。但“我们很特殊”，不能成为不做可行性分析的借口，可能项目需求最开始是模糊不清的，还不具备可行性研究的条件，那么等到项目有了一定的进展，需求逐步明确后，要继续对可行性做研究。如果发现方案不具备可行性，也应及时调整方案或停止项目以止损。 2.“老板拍板的项目，明知道不可行也得硬着头皮干呀！”这个问题要分类讨论，有两种情况。第一种情况，多半是由于老板或者项目负责人控制决策权，且对于不同意见容忍度较低。底下人不敢提不同意见，明知道不对也只能执行。如果你是项目执行人员，不能参与决策，但觉得项目明显不可行，我仍然建议你尽可能站在专业的角度给出科学的分析，通过合理的方式反馈意见。毕竟，项目如果失败了，你也一样可能遭受损失。如果你就是老板或者项目负责人，则应该建立可行性研究的意识，并理性听取不同意见，科学客观地进行可行性分析，以便有效降低项目失败概率。第二种情况，老板或者项目负责人能接触到的信息更多、更全面，同时还有战略上的一些考虑，所以下面执行的人觉得不靠谱，并不代表真的不靠谱。举个例子，2009 年阿里巴巴决定做阿里云的时候，公司反对者占绝大多数，只有马云和王坚等少数人觉得这个项目可行，而且必须做。最后，事实证明他们是对的。所以有时候，也不要着急下结论，可以换个角度思考下，也许是你因为条件限制还没想清楚。 3.“软件项目是鼓励创新、鼓励试错的，可行性研究会阻碍创新！”这也是一种很典型的错误观点，认为创新就可以不做可行性研究，否则会阻碍创新。实际上可行性研究和创新从来就不是矛盾的，它反而可以帮助你提前过滤掉那些不靠谱的创新想法，提前发现可能的风险。想一想前面关于 React Native 开源协议冲突的案例，虽然是一个创新性的项目，却未绕过开源协议引起的法律纠纷。如果当初有法律方面的可行性研究，完全可以改用开源协议更友好的同类开源技术，避免项目的失败。 如何做好可行性研究？ 当你决定要做可行性研究，你就已经成功一半了，怎么做反而是相对简单的部分！软件工程的教材里面，通常会讲如何写可行性研究报告，很繁琐，要撰写诸如引言、背景、定义等内容。在这里，我们关注的重点是，软件工程中是如何去做可行性研究的。如文章开头所说的，通常从三个方面着手做： 经济可行性。从成本和收益角度分析，看投入产出比。不仅要分析短期利益，还要分析长期利益，看是不是值得做。 技术可行性。软件项目最终是需要人通过技术来实现的，所以要分析技术上是不是可行，如果有技术上解决不了的问题又能否规避。 社会可行性。社会可行性涉及法律、道德、社会影响等社会因素。比如，触犯国家法律的事情肯定不能做；产品如若不符合道德标准，可能带来较大的社会负面影响，那么也要慎重考虑。 仍然以文章开头提到的 React Native 项目为例，我们从这三个方面出发，来做一个简单的可行性研究。 先来看看经济可行性。按照投入成本和收益估算，我们在此仅做一些简单假设：这个项目要投入 10 个人，每个人的人力成本预计是 10000 元 / 月，预计要花半年时间上线；每个人在项目实施过程中，所需要的硬件和软件成本预计在 1000 元 / 月；每年该部门预计完成 10 个项目，每个项目收益预计 1000000 元；该项目导致 2 个项目延期半年；该项目预计可以节约项目成本，所以每个项目收益可以提高 50000 元；该项目可以让部门每年完成的项目提升到 12 个。预计投入 1660000 元 / 半年，投入使用后每年可以产生约 2600000 元的收益，不到一年可以收回成本。
就像上面这样一个 10 个人的项目，半年下来就要花一百多万。当然如果项目成功的话，不到一年就可以收回成本，而且后面还会持续创造价值。所以从经济可行性分析，还是可行的。 然后再来看看技术可行性。从技术本身来说，经过一年多的发展，技术已经成熟稳定，并且已经有了几个成功案例。从人员储备来说，部门已经有 5 名成员有 React Native 项目经验，其他人员可以通过 3 个月左右的培训上手。从风险角度看，部分老的安卓机型无法支持，但是这部分机型占有率非常低，可以不予考虑。另外，部分视频组件需要自己实现，技术上可行，需要把这部分的开发任务放入项目计划中。 
技术可行不可行，关键还是在人。就算技术成熟，如果短时间内找不到人来做，也是有很大风险的。同时也要评估可能存在的技术风险，像本例中的设备兼容问题，如果不兼容设备很多，那技术就不可行了。像这个项目，已经有一定的人才储备，不会成为技术上的瓶颈，另外不支持的设备只占极少数，可以忽略不计，所以总体上技术还是可行的。 最后再来看看社会可行性。道德可行性是没有问题的，不会有任何不良道德行为。社会影响方面，也没有负面影响。法律可行性上，项目本身不违反国家法律法规。版权上，React Native 采用 BSD+ 专利开源协议，存在法律风险！ 