系统开发过程及其项目管理
过程模型
-
瀑布模型： 结构化开发，需求不明确时有很大缺陷；
-
增量模型： 每次开发一部分功能（每个版本可独立操作）；
-
原型模型（演化模型）： 针对需求不明确的情况，不适合超大项目；
-
螺旋模型（演化模型结合瀑布模型）： 增加风险分析，适合大型项目开发；
-
喷泉模型： 面向对象模型，迭代思想和无间隙开发；
-
形式化方法模型： 建立在严格数学基础上；
-
统一过程（UP） 模型
针对大型项目；
特点：用例和风险驱动；以架构为中心；迭代并且增量；
阶段：起始（确认需求和风险评估）；精化（完成架构设计）；构建（开发剩余构建，组装构件）；移交（进行测试，交付系统）；生产阶段；
RUP：是UP的商业扩展，针对前面四个阶段；
-
敏捷方法
- 极限编程（XP）：对费用控制严格的公司中使用；
- 水晶法（Crystal）：以人为中心，用最少纪律约束而仍能成功的方法，效率与运作平衡；
- 并列争球法（Scrum）：把每段时间一次的迭代称为一个“冲刺”，按需求的优先级来实现产品；
- 自适应软件开发（ASD）：三个非线性的、重叠的开发阶段——猜测、合作与学习；
- 功用驱动开发方法（FDD）：开发人员分为首席程序员和类程序员；
过程评估
软件能力成熟度模型（CMM）
| 级别 |
说明 |
| 初始级（Initial） |
软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用；
无关键过程区域 |
| 可重复级（Repeatable） |
建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性。有必要的过程准则来重复以前在同类项目中的成功；
软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理； |
| 已定义级（Defined） |
管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件；
同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点； |
| 已管理级（Managed） |
制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制；
软件质量管理、定量过程管理； |
| 优化级（Optimized） |
加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进；
过程更改管理、技术改革管理、缺陷预防； |
能力成熟度模型集成（CMMI）
阶段式模型（关注组织的成熟度）：
| 级别 |
说明 |
| 初始级 |
过程不可预测且缺乏控制 |
| 已管理级 |
过程为项目服务 |
| 已定义级 |
过程为组织服务 |
| 定量管理级 |
过程已度量和控制 |
| 优化级 |
集中于过程改进 |
连续式模型（关注每个过程域的能力）：
| 级别 |
说明 |
| CL0（未完成级） |
过程域未执行或未得到CL1中定义的所有目标。 |
| CL1（已执行级） |
其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。 |
| CL2（已管理级） |
其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。 |
| CL3（已定义级） |
其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进上。 |
| CL4（定量管理级） |
其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。 |
| CL5（优化级） |
使用量化（统计学）手段改变和优化过程域，以对付客户要求的改变和持续改进计划中的过程域的功效。 |
工具与环境
ISO/ICE 25010系统和软件质量模型
ISO/ICE 9126已被ISO/ICE 25010取代
| 功能合适性 |
性能效率 |
兼容性 |
易用性 |
可靠性 |
安全性 |
可维护性 |
可移植性 |
完整性
适当性
正确性 |
时间特性
资源利用率
容量 |
互操作性
共存性 |
可识别性
易学习性
易操作性
错误防御
界面美观性
可访问性 |
成熟度
可用性
容错性
易恢复性 |
机密性
完整性
不可抵赖性
可审计性
真实性 |
模块性
可复用性
易分析性
易修改性
易测试性 |
适应性
易安装性
可替代性 |
系统分析知识
系统需求的定义
-
功能需求： 所开发的系统必须具备什么样的功能；
-
非功能需求： 产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性、保密性和安全性等；
-
设计约束： 也称为限制条件、补充规约，这通常是对解决方案的一些约束说明；
需求分析的基本任务
需求分析阶段主要解决“做什么”的问题，而“怎么做”则是由设计阶段来完成。
-
确定系统的综合要求： 主要包括系统界面要求、系统的功能要求、系统的性能要求、系统的安全和保密性要求、系统的可靠性要求、异常处理要求和将来可能提出的要求；
-
分析系统的数据要求： 包括基本数据元素、数据元素之间的逻辑关系、数据量和峰值等；常用的数据描述方法是实体-关系模型（E-R模型）；
-
导出系统的逻辑模型： 在结构化分析方法中可用数据流图来描述；在面向对象分析方法中可用类模型来描述；
-
修正项目开发计划： 在明确了用户的真正需求后，可以更准确地估算系统的成本和进度，从而修正项目开发计划；
- 如有必要，可开发一个原型系统。对一些需求不够明确的软件，可以先开发一个原型系统，以验证用户的需求；
需求建模
面向数据流的结构化分析方法（SA）；
面向数据结构的分析方法：数据流图、实体联系图、状态迁移图；
面向对象的分析方法（OOA）；
系统设计知识
系统设计概述
系统设计主要目的： 为系统指定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法；
系统设计方法： 结构化设计方法、面向对象设计方法；
系统设计主要内容： 概要设计、详细设计；
概要设计基本任务： 系统总体结构设计，将系统的功能需求分配给软件的模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图；
详细设计基本任务： 模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入/输出格式、用户界面）、编写详细设计说明书、评审；
结构化设计
结构化设计内容：
- 体系结构设计：定义软件的主要结构元素及其关系；
- 数据设计：基于实体联系图确定软件涉及的文件系统的结构及数据库的表结构；
- 接口设计：描述用户界面，软件和其它硬件设备、其它软件系统及使用人员的外部接口，以及各种构件之间的内部接口；
- 过程设计：确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法；
结构化设计原理： 抽象化、自顶向下、模块化、模块独立；
结构化设计原则： 保持模块的大小适中、尽可能减少调用的深度、多扇入少扇出、单入口单出口、模块的作用域应在该模块内、功能应该是可预测的；
内聚种类： 内聚高到低
- 功能内聚：这是最强的内聚，指模块内所有元素共同作用完成一个功能，缺一不可；
- 顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入；
- 通信内聚：指模块内所有处理元素都在同一个数据结构上操作，或者指各处理使用相同的输入数据或者产生相同的输出数据；
- 过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程执行；
- 时间内聚：把需要同时执行的动作组合在一起形成的模块称为时间内聚模块；
- 逻辑内聚：指模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能；
- 偶然内聚（巧合内聚）：指一个模块内的各处理元素之间没有任何联系；
耦合种类： 耦合低到高
- 无直接耦合：指两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息，因此模块间耦合性最弱，模块独立性最高；
- 数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递；
- 标记耦合：指两个模块之间传递的是数据结构；
- 控制耦合：指一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择地执行模块内某一功能。因此，被调用模块内应具有多个功能，哪个功能起作用受调用模块控制；
- 外部耦合：模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合；
- 公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合；
- 内容耦合：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部，这种模块之间的耦合为内容耦合；
面向对象设计
面向对象设计原则： 单一职责、开放—封闭、李氏替换、依赖倒置、接口隔离、组合重用、迪米特原则（最少知识法则）；
其它杂项
UML构造块
-
事务
-
关系
- 依赖：可能有方向的虚线
- 关联：一条直线
- 聚合：直线，一端是空心菱形
- 组合：直线，一端是实心菱形
- 泛化：直线，一端是空心箭头
- 实现：虚线，一端是空心箭头
- 图
常见UML图：
-
类图（class diagram）： 展现了一组对象、接口、协作和它们之间的关系；
-
对象图（object diagram）： 展现了一组对象以及它们之间的关系，描述了在类图中所建立的事物实例的静态快照；
-
用例图（use case diagram）： 展现了一组用例、参与者（actor）以及它们之间的关系，描述了谁将使用系统以及用户期望以什么方式与系统交互；
-
序列图（sequence diagram）： 是场景（scenario）的图形化表示，描述了在一个用例或操作的执行过程中以时间顺序组织的对象之间的交互活动；
-
通信图（communication diagram）： 强调收发消息的对象之间的结构组织；
-
交互概览图（interaction overview diagram）： 组合了序列图和活动图的特征，显示了每个用例的活动中对象如何交互；
-
定时图（timing diagram）： 是另一种交互图，关注一个对象或一组对象在改变状态时的时间约束条件，描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务；
-
状态图（state diagram）： 展现了一个状态机，它由状态、转换、事件和活动组成，用于建模时间如何改变对象的状态以及引起对象从一个状态向另一个状态转换的事件；
-
活动图（activity diagram）： 是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程；
-
组合结构图（composite structure diagram）： 用于描述一个分类器（类、组件或用例）的内部结构，分类器与系统中其他组成部分之间的交互端口，展示一组相互协作的实例如何完成特定的任务，描述设计、架构模式或策略；
-
组件图（component diagram）： 展现了一组构件之间的组织和依赖；
-
部署图（deployment diagram）： 展现了运行时处理结点以及其中构件（制品）的配置；
-
包图（package）： 用于把模型本身组织成层次结构的通用机制，描述类或其他UML构件如何组织成包，以及这些包之间的依赖关系；
设计模式：
-
创建性设计模式——创建对象
工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式；
-
结构性设计模式——处理类或对象的组合
适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式；
-
行为性设计模式——描述类与对象怎样交互、怎样分配职责
职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式；
系统实施知识
基线
-
功能基线： 在系统分析与软件定义阶段结束时，经过正式批注签字的系统规格说明书、项目任务书、合同或协议书中所规定的对待开发软件系统的规格说明；
-
分配基线： 在需求分析阶段结束时，经过正式评审和批准的需求规格说明。分配基线是最初批准的分配配置标识；
-
产品基线： 在综合测试阶段结束时，经过正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最终批准产品的配置标识；
系统测试
测试目的
测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。
测试原则
- 应尽早并不断地进行测试；
- 测试工作应该避免由原开发软件的人或小组承担；
- 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果；
- 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件；
- 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事；
- 严格按照测试计划来进行；
- 妥善保存测试计划、测试用例;
- 测试用例可以为重新测试或追加测试提供方便;
测试过程
- 拟定测试计划；
- 编制测试大纲；
- 根据测试大纲设计和生成测试用例；
- 实施测试；
- 生成测试报告；
测试方法
-
静态测试
-
动态测试
- 黑盒测试（功能性测试，不需要知道软件代码结构，根据功能设计测试）
- 功能分解
- 等价类划分
- 边界值分析
- 判定表
- 因果图
- 随机测试
- 猜错法
- 正交试验法
- 白盒测试（结构性测试，需要软件知道代码结构，根据代码逻辑设计测试）
- 语句覆盖：使程序中每一条语句至少执行一次；
- 判定（分支）覆盖：使程序中每个分支语句至少执行一次；
- 条件覆盖：使每个判断中的每个条件至少满足一次；
- MC/DC（判定/条件）覆盖：使每个判断中的每个条件在可能的情况下至少影响判定结果一次；
- 条件组合覆盖：使每个判断中条件的各种组合至少出现一次（这种覆盖包含了分支覆盖和条件覆盖）；
- 路径覆盖：使程序沿所有可能的路径执行；
- 灰盒测试（黑盒+白盒）
测试级别
单元测试、部件测试、配置项测试、系统测试；
系统调试
| 方法 |
说明 |
| 试探法 |
根据症状猜测问题所在位置，效率低适合简单程序， |
| 回溯法 |
从症状位置开始，沿程序控制流程往回跟踪代码找到错误根源，适合小型程序 |
| 对分查找法 |
用来缩小错误范围 |
| 归纳法 |
收集所有正确或不正确的数据，分析找出错误原因 |
| 演绎法 |
列出所有可能错误原因，对各个原因使用已有数据分析假设来发现错误 |
系统运行和维护知识
软件维护根据原因分类：
-
改正性维护： 识别和纠正错误、改正性能缺陷；
-
适应性维护： 使用过程中外部环境、数据环境变化，为了适应变化；
-
完善性维护： 使用过程中扩充功能、增强性能、改进效率和可维护性等；
-
预防性维护： 预先提高可维护性、可靠性等；
软件维护根据内容分类：
-
程序维护： 为了改正错误或改进效率而改写一部分或全部程序，通常充分利用源程序；
-
数据维护： 对文件或数据中的记录进行增加、修改和删除等操作，通常采用专用的程序模块；
-
代码维护： 为了适应用户环境的变化，对代码进行变更，包括修订、新设计、添加和删除等内容；
-
硬件设备维护： 为了保证系统正常运行，应保持计算机及外部设备的良好运行状态。如建立相应的规章制度、定期检查设备、保养和杀病毒；
遗留系统评价与演化：
高水平、低价值
集成
|
高水平、高价值
改造
|
低水平、低价值
淘汰
|
低水平、高价值
继承
|
