系统开发与软件工程

软件开发生命周期模型：

瀑布模型：理想化状态，需求分析很明确，现实几乎不可能。

增量型：把功能分段完成。（又称演化模型）

原型法：最主要的功能做出来，再根据要求，一步步修改。动态定义需求的方法，不需要有明确需求的。

螺旋模型：在以上两者基础上，加上风险分析。

喷泉模型（面象对象模型，面向对象生存期）：迭代，允许开发活动之间交叉进行。

项目管理：核心问题，成本、质量、进度分为六个步骤：启动、估算、度量、风险分析、进度安排、追踪和控制

项目估算：自顶向下，是根据以前完成项目经验推算，耗费时间较少，对大项目较准。

自底向上：比较客观估算方法，将工作细化，将工作累加，没有考虑系统集成成本，整体的规划。

区别与不同：

传统的瀑布模型，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代模型，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

迭代模型其实包含了原型开发法，但原型开发更侧重于需求不明确的，更快出产品的情况。 

 

螺旋模型，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

 

敏捷模型，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷开发有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

注：

各种开发模型，实质是对需求变化情况的不同处理。这也是现实中必然遇到的问题。要明白开发模式的存在的意义；有助于解题：

如：2016年上半年

第30题:以下关于增量开发模型的叙述中,不正确的是(30)。
A. 不必等到整个系统开发完成就可以使用
B. 可以使用较早的增量构件作为原型,从而获得稍后的增量构件需求
C. 优先级最高的服务先交付,这样最重要的服务接受最多的测试
D. 有利于进行好的模块划分

答:如果对增量开发模型实质把握不好的话，误以为是：先开发主要的功能，再添加其他的，这样有利于模块的划分，这就错了！增量型又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

所以说与工程开发的模块 划分基本来说是没有必然的联系的。所以选D。

---

规模估算：

LOC估算法，估算软件行数

FP估算法：功能点＝信息处理规模X技术复杂度。

工作量估算：人／月   等同于   软件规模／产能 

成本估算：基于以上的估算。

组织与计划：

甘特图：水平的线段表示任务的工作阶段。反映计划进度，但不能反映进度间的逻辑关系。

CPM方法：关键路径法

PERT技术：计划评审方法。两种都是用网络图来表示。都是软件开发常用方法。

进度监控与进度修正：

EVA分析法：已获值分析

 软件质量管理：

ISO IEC 9126模型被国标《GB／T 16120－1996软件产品评价质量特性及其使用指南》。

McCall质量模型规定了，产品修正，转移，运行三个方面的要求。

软件需求分析与设计：

解决做什么的问题，设计是解决怎么来做的问题。

分析工作：问题识别（发现需求，描述）、分析与综合（找出问题的解决方案）、编制需求分析的文档（需求规格说明书）、需求分析与评审（对功能正确、完善进行评价）。

原则是必须要理解问题数据域和功能域。按照自顶向下逐层分解的方式不断细化。

设计工作：概要设计：将需求转化为数据结构和软件的系统结构。划分模块及关联

详细设计，对概要设计的模块进行细化。

设计方法：JACKSON方法是将从数据结构导出模块结构

Pamas：将可能引起变化的因素隐藏在有关的模块内部。只提供设计准则没有步骤。

---

结构化分析与设计：面向数据流的需求分析方法

详细设计6种工具：1程序流程图，对控制流程描述直观 2盒图（N－S图）没有箭头，有利于养成结构化的思维方式3PAD图，问题分析图，用二维树型结构图来表示控制流，并且很容易的转成高级语言。4PDL，用伪码表示用文本方式来描述。

模块设计的原则：模块的独立性，信息隐蔽。

内聚：指一个程序内的内聚程度，耦合：不同程序间相对独立性

非直接耦合，没有直接联系，互相不信赖对方

数据耦合：借助参数传递数据。

标记耦合：传递一个数据结构，其实是数据结构 的地址

控制耦合：信息中包含控制逻辑

外部耦合：与软件以外的环境有关，如访问同一全局变量

公共耦合：引用一个全局数据区如共享通信区，全局数据结构 ，内存公共覆盖区

内容耦合：数据、代码重叠等访问另一个模块。直接访问模块的内部不通过正常入口或接口

内聚：

功能内聚

顺序内聚：处理元素相关，而且必须顺序执行

通信内聚：所有处理元素集中在数据区域上。

过程内聚：必须按特定次序执行

瞬时内聚：必须在同一时间间隔内执行。

逻辑内聚：完成逻辑上的一组任务

偶然内聚：完成没有关系或松散关系的任务。

 

软件测试与维护，比较重要

软件测试基础：

测试用例是由测试数据和预期结果所构成的。

一个测试用例能够发现当前还没发现的错误就是一个好的用例。

步骤：1、制定计划，考虑到整个开发时间2、测试大纲，针对某项功能的具体要求3、生成测试用例4、实施5、测试报告。

测试方法：静态测试，不在机器上运行，采用人工检测，计算机辅助的方式。

动态测试：通过运行程序发现错误。白盒和黑盒测试。

---

黑盒测试，功能测试，集成和系统测试阶段，主要看输入和输出的关系。主要方法，边界值分析（边界情况最容易出错）、等价类划分，错误推算法，根据错误的特殊情况选择错误用例。因果图：根据输入条件与输出结果因果设计用例

白盒测试；关注内部结构，逻辑结构。覆盖（程序执行顺序）从弱到强，方法：语句覆盖、判定覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。（条件只是判定的一部分，是整体与部分的关系。）

软件维护：改正错误或新的功能需求，内容补充功能改善。

软件过程改进：

CMMI模型（能力成熟度模型集成）：确定了一个软件成熟度的确定标准。