（软考笔记）—— 系统架构设计师 – 系统开发基础知识笔记

文章目录

• 系统开发基础知识笔记
• • 软件开发方法
  • • 软件开发生命周期
    • 软件开发模型
    • 瀑布模型
    • 原型模型
    • 螺旋模型
    • 基于可重用构建的模型
    • 基于面向对象的模型
    • 基于四代技术的模型
  • 敏捷方法
  • • 敏捷方法的特点
    • 敏捷方法的核心思想
    • 敏捷型方法的含义及其特征
    • 敏捷方法的适用范围
    • 敏捷方法的主要内容
    • 敏捷开发方法简介
  • RUP(Rational Unified Process)
  • • RUP概述
    • RUP的生命周期
    • RUP的核心概念
    • RUP的特点
    • RUP裁剪
  • 软件系统工具
  • • 编码与排错工具
  • 需求管理
  • • 需求管理原则
    • 需求规格说明的版本控制
    • 需求属性
    • 需求变更
    • 需求跟踪
    • 需求变更的代价和风险
  • 开发管理
  • • 项目的范围、时间、成本
    • 配置管理、文档管理
  • 软件开发的质量与风险
  • • 软件质量
    • 软件开发风险
  • 设计方法
  • • 结构化设计方法
    • 面向对象的分析设计
  • 软件的重用
  • 逆向工程和重构工程

系统开发基础知识笔记

软件开发方法

软件开发生命周期

???? 传统的软件生命期（software life cycle）是指软件产品从形成概念（构思）开始，经过定义、开发、使用和维护，直到最后被废弃（不能再使用）为止的全过程。按照传统的软件生命周期方法学，可以把软件生命期划分为软件定义、软件开发、软件运行与维护三个阶段。

软件定义时期

1. 问题定义： 按照软件系统工程需求来确定问题空间的性质。
2. 可行性研究： 确定问题是否有解，解决办法是否可行。
3. 需求分析：需求分析的任务是确定软件系统的功能需求、性能需求和运行环境的约束，写出软件播求规格说明书、软件系统测试大纲、用户手册概要。

???? 需求分析该过程是非常重要的，应该由系统分析员、软件开发人员与用户共同完成，反复讨论和协商，并且逐步细化、一致化、完全化等，直至建立一个完整的分析模型。需求分析工作完成后要提交软件需求规格说明（Sofware Requirements Specification，SRS）。

软件开发时期

???? 软件开发时期就是软件的设计与实现，可分成：

1. 概要（总体）设计： 是在软件需求规格说明的基础上，建立系统的总体结构（含子系统的划分）和模块间的关系，定义功能模块及各功能模块之间的关系。
2. 详细设计： 对概要设计产生的功能模块逐步细化，把模块内部细节转化为可编程的程序过程性描述。详细设计包括算法与数据结构、数据分布、数据组织、模块间接口信息和用户界面等的设计，并写出详细设计报告。
3. 编码： 又称编程，编码的任务是把详细设计转化为能在计算机上运行的程序。
4. 测试： 分成单元测试、集成测试、确认测试和系统测试等。通常把编码和测试称为系统的实现，

软件运行和维护

???? 软件运行就是把软件产品移交给用户使用。软件投入运行后的主要任务是使软件持久满足用户的要求。
???? 软件维护是对软件产品进行修改或对软件需求变化做出响应的过程，也就是尽可能地延长软件的寿命。

软件开发模型

???? 软件生存周期模型又称软件开发模型（software develop model）或软件过程模型（software process mndel），它是从某一个特定角度提出的软件过程的简化描述。软件过程模型的基本概念;软件过程是制作款件产品的一组活动以及结果，这些活动主要由软件人员来完成，软件活动主要如下一些：

1. 软件描述： 必须定义软件的功能以及使用的限制。
2. 软件开发： 软件的设计与实现，软件工程人员制作出满足描述的软件。
3. 软件有效性验证： 软件的有效性必须经过严格的验证，以保证能够满足客户的需求。
4. 软件进化： 软件随着客户的需求变化而不断地改进。

瀑布模型

???? 瀑布模型（waterfall model）可以说是最早使用的软件生存周期模型之一。由于这个模型描述了软件生命的一些基本过程活动，所以它称为软件生命周期模型。

螺旋模型

???? 螺旋模型（Spiral Model）是在快速原型的基础上扩展而成。也有人把螺旋模型归到快速原型。实际上，它是生命周期模型与原型模率的一个结合，这种模型将软件开发流程分为多个阶段，每一个阶段由4部分组成：

1. 目标设定；
2. 风险分析；
3. 开发和有效性验证；
4. 评审；

???? 开发过程就是上面4个部分的迭代，每迭代一次，软件系统生成一个新的版本，这个版本实际上是对目标系统的的一个逼近。具体的过程如图：

???? 显然，一个系统将依赖构件的健壮性。但是毫无疑问，构件组装模型使软件可以重用，而重用给软件工程师提供了大量的好处。构件组装模型具有极其广阔的实用性和深远的意义。

基于面向对象的模型

???? 面向对象技术自从问世后，很快被人们所接受，并得到广泛的应用。面向对象技术确实有很多的优点，其中构件重用是非常重要的技术之一。对象技术强调了类的创肆与封装，一旦一个类创建与封装成功，就可以在不同的应用系统中被重用。在这个模型中，一个系统可以由重用构件组装而成，甚至通过组装可重用的子系统而创建更大的系统，模型结构如图所示：

???? 需求管理强调：

1. 控制对需求基线的变动；
2. 保持项目计划与需求一致；
3. 控制单个需求和需求文档的版本情况；
4. 管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；
5. 跟踪基线中的需求状态。

需求管理原则

???? 过程能力成熟度模型（Capability Maturity Model，CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件处理能力的5 个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有6个关键过程域（Key Process Area，KPA）。

需求规格说明的版本控制

???? 在软件开发过程中，可能出现测试人员使用已过时的软件规格说明，结果发现了—大堆的错误，为了避免这种情况的发生，需求规格说明的版本暂理就翼得非常重要了。版本控制管理需求的一个必要方面，是必须要统一确定需求文档的每一个版本。

需求属性

???? 除了文本，每一个功能需求应该有一些相关的信息与它联系，我们把这些信息称为需求属性。对于一个大型的复杂项目来说，丰富的属牲类别显得尤为重要。在文档中，明确考虑和明确如下的属性：

1. 创建需求的时间；
2. 需求的版本号；
3. 创建需求的作者；
4. 发热者认可该需求的人员；
5. 需求状态；
6. 需求的原因和根据；
7. 需求涉及的子系统；
8. 需求涉及的产品版本号；
9. 使用的验证方法或接受的测试标准；
10. 产品的优先级或者重要程度；
11. 需求的稳定性；

需求变更

???? 软件需求文档应该精确地描述要交付的产品，这是一个基本的原则，为了能够使开发组织能够严格的控制软件项目，应该确保如下事项：

1. 仔细评估已建议的变更；
2. 挑选合适的人选对变更作出决定；
3. 变更应及时通知所有涉及的人员；
4. 项目要按一定的程序来采纳需求变更；

变更控制过程

???? 需求变更管理过程如图所示：

1. 客户需求向前追溯软件需求
2. 从软件需求回溯相应的客户需求
3. 从软件需求向前追溯到下一级工作产品
4. 从产品部件回溯到软件需求

???? 跟踪能力联系链记录了单个需求之间的父层、互相连接和依赖的关系。当某个需求变更（被删除或修改）后，这种信息能够确保正确的变更传播，并将相应的任务做出正确的调整。一个项目不必拥有所有种类的跟踪能力联系链，要根据具体的情况调整。

需求变更的代价和风险

???? “变更是免费的”这种误解是造成项其范围延伸的主要原因之一。影响分析是需求管理的一个重要组成部分。影响分析可以提供对建议的变更的准确理解，帮助做出信息量充分的变更批准决策。

开发管理

项目的范围、时间、成本

范围

???? 范围定义的输入包括以下的内容：

1. 项目章程
2. 项目范围管理计划
3. 组织过程资产
4. 批准的变更申请

时间

???? 项目时间管理包括按时完成所必须的管理过程。项目提出后比较明确的一般只是项目的目标，为了使得项目目标得以实现并且制订出比较完善的项目进度计划，则在对项目进行分解的基础上还必须对分解出的目标进行定义，只有这样才能使目标更明确，因此对活动的定义是非常必要的。

成本

???? 它包括在批准的预算内完成项目所需要的诸过程，主要有如下一些。

1. 成本估算：编制一个为完成项目各项活动所需要的资源成本的近似估算。
2. 成本预算：将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。
3. 成本控制：控制项目预算的变更。

???? 项目成本管理这种广义的观点常被称为“全生命周期成本计算”。为保证项目能够完成预定的目标，必须要加强对项目实际发生成本的控制，一旦项目成本失控，就很难在预算内完成项目，不良的成本控制常常会使项目处于超出预算的危险境地。可是在项目的实际实施过程中，项目超预算的现象还是屋见不鲜。

配置管理、文档管理

配置管理

???? 配置管理在项目管理中具有重要的地位和作用。近年来，信息系统项目的规模越来越大，复杂性越来越高;管理上的失误给我们的教训也越来越深刻。这都使得人们不得不重视配置管理问题。配管理是过按术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。

文档管理

???? 总的来说，软件文档应该满足下述要求：

1. 必须描述如何使用这个系统，没有了这种描述即使是最简单的系统也无法使用。
2. 必须描述怎样安装和管理这个系统。
3. 必须描述系统需求和设计。
4. 必须描述系统的实现和测试，以便使系统成为可维护的。

用户文档

???? 用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述 5方面的内容：

1. 功能描述： 说明系统能做什么。
2. 安装文档： 说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。
3. 使用手册： 简要说明如何着手使用这个系统。
4. 参考手册： 详尽的描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错的信息的含义。
5. 操作员指南：说明操作员应该如何处理使用中出现的各种情况。

系统文档

???? 所谓系统文档指从向题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

软件开发的质量与风险

软件质量

???? ISO9000 对项目质量的定义是∶一组固有特性满足需求的程度。需求指明示的、通常隐含的或必须履行的需求或期望。特性是指可区分的特征，可以是固有的或赋予的、定性的或定量的、有各种类别（物理的、感官的、行为的、时间的、功能的等）。

???? 质量与范围、成本和时间是项目成功的关键因素。

软件开发风险

???? 项目风险是一种不确定的事件或条件，一旦发生，会对项目目标产生某种正面或负面的影响。对项目风险进行管理，国际上已经成为项目管理的重要方面。如世界银行对每一个贷款项目都进行风险分析，制定风险管理计划，写在有关的文件之中，并付诸行动。

设计方法

结构化设计方法

???? 何谓结构程序设计，目前尚无定论，较流行的定义为;绪构程序设计是程序设计技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制构件。程序设计结构一般可以定义为：顺序结构、分支结构和循环结构。随着面向对象、软件重用等新的软件开发方法和技术的发展，更现实、更有效的开发途径可能是自顶向下和自底向上两种方法有机的结合。

面向对象的分析设计

???? 面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。面向对象的软件设计流程如下图所示：

???? 使用重用技术可以减少软件开发活动中大量的重复性工作，这样就能够提高软件生产率，降低开发成本，缩短开发周期。同时，由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此重用软部件有助于改善软件质置。此外，大量使用软部件，软件的软件逆工程灵活性和标准化程度也可望得到提高。

逆向工程和重构工程

???? 逆向工程与重构工程是目前预防性维护采用的主要技术。一般认为，凡是在软性生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。

恢复信息的级别

???? 逆向工程导出的信息可以分为如下4个层次：

1. 实现级： 包括程序的抽象语法树、符号表等信息；
2. 结构级： 包括反映程序分量之间的相互依赖关系的信息；
3. 功能级： 包括反映程序段功能以及程序段之间关系的信息；
4. 领域级： 包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息；

恢复信息的方法

???? 在逆向工程中用于恢复信息的方法有 4 类：

1. 在用户指导下的搜索与变换(User-Directed Search and Transformation)
2. 变换式方法(Transformational Approaches)
3. 基于领域知识的(Domain Knowledge-Based)
4. 铅板恢复法

???? 尽管每个软件组织都可能有数百万行代码可供重构，但由于缺乏时机和支持工具或者因为经济上得不偿失，往往只有那些决定或移植、或重新设计、或为重用而需验证正确性的程序才被选择实施逆向工程。

来源：赵萱婷