5.1 软件工程
软件危机的表现：
●软件开发进度难以预测；
●软件开发成本难以控制；
●软件功能难以满足用户期望；
●软件质量无法保证；
●软件难以维护；
●软件缺少适当的文档资料。
为了解决软件危机，1968、1969年NATO连续召开了两次会议，提出了软件工程的概念。
5.1.1 软件工程定义
缺乏统一的定义：
● Barry Boehm:运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护
这些程序所必须的相关文件资料。
●IEEE:软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运
行和维护，即将工程化应用于软件；②对①中所述方法的研究。
● Fritz Bauer:在NATO会议上给出的定义，建立并使用完善的工程化原则，以较经济的手
段获得能在实际机器上有效运行的可靠软件的一系列方法。
●《计算机科学技术百科全书》:软件工程是应用计算机科学、数学、逻辑学及管理科学
等原理，开发软件的工程。软件工程借鉴传统工程的原则和方法，以提高质量、降低成
本和改进算法。其中，计算机科学、数学用于构建模型与算法；工程科学用于制定规
范、设计范型(Paradigm)、评估成本及确定权衡；管理科学用于计划、资源、质量、
成本等管理。
软件工程活动4个方面：
P(Plan)---软件规格说明。规定软件的功能及其运行时的限制。
D(Do)----软件开发。开发出满足规格说明的软件。
CCheck）------软件确认。确认开发的软件能够满足用户需求。
A(Action)------软件演进。软件在运行过程中不断改进。
5.1.2 软件过程模型
软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的过程，叫软件的生命周期。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予约束，这样的工作模型称为软件过程模型，也叫软件生命周期模型。
1.瀑布模型Waterfall Model
它是最早的使用的过程模型之一，特点：因果关系紧密相连，前一个输出是后一个输入，每阶段都是建立在前阶段结果上，每阶段完后都有一个里程碑(一组检查条件)，对该阶段的工作进行审查和确认。
优点：工作流程结构化，严谨，按步骤每阶段完成一定工作，并配有相关文档，利于开发和后期的维护等。
缺点：软件的需求要想一开始完全清楚准确是不可能的；它是一个严格的串行化过程，使得用户和软件负责人需要相当长的时间才能看到成果，而且一旦出现与用户期望不一致或需求变更将带来巨大损失；该模型的基本原则是每阶段一次性解决所有工作，不出现遗漏或错误等，但实际是不可能的。
适应：适应于较小的结构不复杂的小型系统，另外该方法可结合面向对象用于大型系统
2.原型化模型Prototype Model
基于瀑布的缺点，借鉴建筑师、工程师造原型经验而提出。创建一个快速原型，满足项目干系人与未来用户与原型交互(原型开发阶段)，在经过充分讨论和分析，弄清楚当前系统需求(目标软件开发阶段)。
抛弃式原型是原型用完后仍了，演化性原型则是在原型的基础上继续演化。
原型模型的使用应注意：
- 用户对系统的认识模糊不清，无法准确提出需求；
- 需要一定环境和工具支持；
- 经过对原型若干次修改，应收敛到目标范围内否则可能会失败；
- 对于大型软件来说，原型可能非常复杂而难以快速形成，如果没有现成的原型模型，不建议考虑使用。
特点：实际可行；具有最终系统的基本特征，构造方便、快速、造价低；对用户的需求动态响应逐步纳入。
适应：适应于需求不明确的情形
3.螺旋模型Spiral Model
它是一个演化软件过程模型，将原型实现的迭代特征和线性顺序(瀑布)模型中控制的和系统的方法结合起来。
目标设定：为项目进行需求分析，定义和确定这一阶段的专门目标，指定对过程和产品的约束，并且指定详细的管理计划。
风险分析：对可选方案进行风险识别的和详细分析，制定解决办法，采取有效措施避免这些风险。
开发和有效性验证：风险评估后，可为系统选择开发模型，并且进行原型开发，即开发软件产品。
评审：对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如决定继续，制定下一阶段计划。
特点：具有周期性重复的螺旋线状；4个阶段(过程)：制定计划，风险分析，实施工程，客户评估；强调风险分析，特别适合庞大而复杂、高风险系统。
适用：庞大而复杂的高风险系统，也可与其他模型结合使用，如面向规格说明、面向过程和面向对象等等。涉及风险分析的一般都选择它。
5.1.3 敏捷模型
敏捷方法Agile的特点：适应性而非预设性、面向人而非面向过程。
这两个特点是区分敏捷与计划驱动或重型开发方法的主要特征。
重型方法：对一个软件开发项目在很长时间跨度内做成详细的计划，然后按照计划开发。计划制定后，拒绝变化。敏捷方法是欢迎变化的或者说敏捷的目的就是适应变化的过程而产生的。
适应性而非预设性：传统的开发方法基本借鉴其他工程领域而来，非常强调设计规划，充分考虑合理性，有多年的经验可用，关键部分建立在严格的数学分析之上。但软件开发没有这些基础，而且而且一些错误只能在编码和测试的时候才能发现，而且还存在需求的不稳定等等，于是Agile方法引入适应性，用反馈机制对不可预测过程控制。
面向人而非面向过程：软件开发工作充分发挥人的创造能力，强调软件开发是一种愉快活动。
传统开发方法使得参与人员是可替代的，将人看作一种资源，具有不同角色(分析员、程序员、测试员...)，个体不重要，角色才重要。这样可尽量减少人的因素。敏捷型开发方法正好相反。
计划驱动方法是让开发人员服从一个过程，而非接受一个过程。但是开发人员是管理人员指定的，管理人员已经很久不开发了。敏捷方法要求迹象方面的决定必须由技术人员决定，共同为开发负责。
敏捷方法特别强调相关人员间的信息交流，尤其是面对面的交流。按照高内聚、低耦合原则将项目划分若干组，以增加沟通，提高敏捷性和应变能力。
敏捷方法的核心思想：
1.它是适应型，而非预测型。拥抱变化，为了适应变化的需求，利用变化发展改变自己完善自己。
2.以人为本，而非以过程为本。传统方法以过程为本，它是充分发挥人的特性，并且在无过程控制和过于严格繁琐的过程控制中取得平衡。
3.迭代增量式开发过程。以原型思想为基础，迭代增量式开发，版本小型化，根据优先级和风险制定发行计划，主表扩充直至满足用户需求。
主要敏捷方法：
1.极限编程Extreme Programming XP，最引人瞩目的。基础和价值观：交流、朴素、反馈、勇气。加强交流，从简单做起，需求反馈，用于实事求是。它是一种近螺旋式的开发方法，复杂过程分小周期，积极交流、反馈，并根据实际情况及时地调整开发过程。
2.水晶系列方法Crystal，与XP类似，以人为中心，但实践上不同，其目的是发展一种提倡“机动性
的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
Crystal家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷
团队可以根据其项目和环境选择最合适的Crystal家族成员。
3.Scrum。该方法侧重于项目管理。它包括了一系列实践和预定义角色的过程骨架。
4.特征驱动开发方法(Feature Driven Development,FDD)。
- 3个要素： 人、过程和技术。
- 6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
- 5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。
5.1.4 统一过程模型RUP
Rational Unified Process RUP，描述了如何有效利用商业的、可靠的方法开发和部署燃尽，是一种重量级过程。它类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及示例支持。
1.RUP生命周期
二维的软件开发模型，9个核心工作流：
- 业务建模Business Modeling：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
- 需求Requirements：定义系统功能及界面，使客户知道系统的功能，使开发人员理解需求，为项目预算及计划提供基础。
- 分析与设计Analysis&Design：把需求分析的结果转化为分析与设计模型。
- 实现Implementation：把设计模型转换为实现结果，并单测，姜不同模块集成为可执行系统。
- 测试Test：类似集成测试，各系统集成、交互如何，需求都实现了吧，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
- 部署Deployment：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
- 配置与变更管理(Configuration&Change Management)：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
- 项目管理Project Management：微软将开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
- 环境Environment：开发环境，提供过程管理和工具的支持。
RUP把软件开发生命周期划分为多个循环，每个循环生成一个新版本，每个循环4个连续的阶段：
- 初始Inception阶段：定义最终产品视图和业务模型，并确定系统范围。
- 细化elaboration阶段：设计及确定系统架构，制定工作计划及资源要求。
- 构造construction阶段：构造产品并继续演进需求、架构、计划直至产品提交。
- 移交transition阶段：把产品提交给用户使用。
每个阶段都由一个或多个连续的迭代Iteration组成，每个迭代都是一个完整的开发过程。迭代是针对不同用例的细化和实现。每个阶段结束后都有一个里程碑Milestone评估该阶段工作，未通过的要决定继续该阶段还是取消该项目。
2.RUP中的核心概念
- 角色Role：who的问题。RUP预先定义了很多角色，如体系结构师Architect、设计人员Designer、实现人员Implementer、测试员tester、配置管理人员Configration Manager等。
- 活动Activity：how的问题。是一个有明确目的的独立工作单元
- 制品Artifact：what的问题。它是活动生成、创建或修改的一段信息，也叫产品、工件等。
- 工作流Workflow：when的问题。它描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色间关系。
- 除了上面4个核心概念，还有工具教程Tool Mentor、检查点Checkpoints、模板Template、报告Report等
3.RUP特点
1).用例驱动：即需求分析、设计、实现、测试等活动都是用例驱动的。
2).以体系结构为中心：RUP中的开发活动是围绕体系结构展开的。
体系结构层次的设计问题：系统的总体组织和全局控制、通信协议、同步、数据存取、给设计元素分配功能、设计元素的组织、物理分布、系统的伸缩性和性能等。
RUP采用4+1视图模型来描述软件系统的体系结构：
3).迭代与增量
RUP采用迭代和增量的方式来开发软件，整个项目分多个迭代过程。每次只考虑一部分需求，进行分析、设计、实现、测试、部署等过程，而且每次都是在前面的基础上进行，直至完成项目。
这样做的意义：
1.软件开发早期就可对关键的、影响大的风险进行处理。
2.可提出一个体系结构来指导开发
3.更好的处理不可避免的需求变更
4.可较早得到一个可运行的系统，鼓舞团队增强信心。
5.为开发人员提供一个能更有效工作的开发过程。
5.1.5 软件能力成熟度模型
软件能力成熟度模型(Capability Maturity Model for Software,CMM)是一个概念模型，模
型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。
CMMI(Capability Maturity Model Integration for Software,软件能力成熟度模型集成)是
在CMM的基础上发展而来的。
CMMI提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成5个成熟度等
级，共包括18个关键过程域，52个过程目标，3168种关键时间，它为软件过程不断改进奠定
了一个循序渐进的基础。
5.2 需求工程
需求工程是软件工程的子领域。
它是指应用已经证实有效的原理、方法，通过合适的工具和符号，系统地描述待开发系统及其行为特征和相关约束。
它的目标：确定客户需求，定义设想中系统的所有外部特征。
需求工程覆盖了体系结构设计之前的各项开发活动，主要包括：分析客户需求，对未来系统的各项功能性及非功能性需求进行规格说明。
它缺乏统一的定义，单都包含以下几方面：
- 用户解决问题或达到目标所需条件或权能(Capability)。
- 系统和系统部件都要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
- 一种反应上面两条的所述条件或权能的文档说明
关联要点：需求的三个层次：
- 业务需求：反应组织机构或客户对系统、产品高层次的目标要求。
- 用户需求：用户使用产品必须完成的任务，是用户对该产品的期望。
- 功能需求：开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。
- 补充：业务需求和用户需求构成了用户原始需求文档的内容。作为补充，SRS还应包括非功能性需求。
需求工程的阶段：
1.需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
2.需求分析：为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
3.形成需求规格(或称之为需求文档化):按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
4.需求确认与验证：以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
5.需求管理：包括需求文档的追踪管理、变更控制、版本控制等管理性活动。
需求开发文档经过评审后就形成需求基线，这个基线就是开发和客户间计划产品功能需求和非功能需求的一个约定，这个约定就是需求开发和需求管理之间的桥梁。
需求管理强调的内容如下：
(1)控制对需求基线的变动。
(2)保持项目计划与需求一致。
(3)控制单个需求和需求文档的版本情况。
(4)管理需求和联系链，或管理单个需求和其他项目可交付产品之间的依赖关系。
(5)跟踪基线中的需求状态。
5.2.1 需求获取
需求获取是开发者、用户间为了定义新系统而进行的交流，是获得新系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。它是强调 ”做什么“，而不是 ”怎么做“。
用户的需求可能来自用户写出，也可能来自业务分析员、系统分析员配合用户书写；需求内容包括问题范围、功能需求、应用环境及假设条件，甚至包含相关的软件工程标准、技术方案、将来可能有的扩展和维护性等方面的要求和约束等等。
需求获取的基本步骤
不同规模或类型的项目，过程不尽相同，参考步骤如下：
1.开发高层的业务模型：
对应用的领域(行业)充分了解，建立一个业务模型，描述用户的业务过程，确定原始需求，然后迭代，深入了解应用领域，对业务模型改进。
做一个系统是在整个行业的背景下的，应用的领域了解的越充分获取的需求就越清晰，建立的业务模型就更具体。
2.定义项目范围和高层需求
在项目开始之前，应当在所有涉众(项目的利益攸关方)之间建立共同的项目愿景，即定
义项目范围和高层需求。项目范围描述系统的边界以及系统与系统交互的参与者之间(包括组
织、人、硬件设备、其他软件等)的关系。高层需求不涉及过多的细节，主要表示系统需求的
概貌。常见的建模手段包括系统上下文图和系统顶层用例图等。
项目必须要有范围，哪些该做哪些不该做，高层需求所有利益相关方都要照顾到，做到平衡。
3.识别用户角色和用户代表
涉众不仅包括传统的用户、客户等，还包括测试人员、维护人员、市场人员等，他们也对
项目有利益诉求。因此，首先确定所有涉众，然后挑选出每一类涉众并与他们一起工作。
用户角色可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用
程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。
所有涉众选出代表一起工作，都有各自的角色，对项目涉及到不同方面的问题由相应角色人员给出解决方案和建议，以保证项目的顺利进行。
4.获取具体的需求
确定了项目范围和高层需求，并确定了所有涉众后，就需要获取每个涉众的具体、完整和
详细的需求。
不同的利益相关方站的角度不同，对同一个系统的要求就会不同，所以要综合所有涉众的需求和观点，消除差异，平衡需求，让所有涉众达成一个共识。
5.确定目标系统的业务工作流
具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。往往需要采取
多重方法来获取所需的信息。
明确业务工作流和主要的业务规则。
6.需求整理与总结
最后对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的
需求。并提出这些需求的实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需
求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与
开发进度需求等。
这就是软件规格说明书了SRS。
需求获取方法
针对不同类型的软件项目，需要采用不同的需求获取方法。常见的需求获取方法如下:
1.用户面谈
面谈最为常见的方法，理解用户需求最有效的方法。但是需要充分的计划和准备，后期要复查笔记，把收集的信息转换为模型和文档。
2.需求专题讨论会
也是一种有效方法，拉一批人(都是有价值的涉众代表)开会。优点：
- 协助建立一只搞笑的团队，围绕项目成功的目标。
- 所有风险承担人畅所欲言。
- 促进风险承担人和开发团队间达成共识。
- 揭露和解决妨碍项目的行政问题。
- 能够很快的产生初步的系统定义。
- 可以有效解决不同涉众间需求冲突。
3.问卷调查
这种方式可用于确认假设和收集统计倾向数据。存在的问题是：不能事先决定，问题背后的假设对答案造成偏颇，难以探索新领域，难以继续用户的模糊相应。它可以在面谈和分析后作为一种协作技术。
4.现场观察
通过观察用户的实际执行业务过程，来直观地了解业务执行过程，全面了解需求细节。
5.原型化方法
需求早期，用户不能完全具体的描述出来所需要的，尤其是人机界面和查询报表上，此方法可选。
6.头脑风暴法
新拓展的新出现的业务上，高度不确定性，一群人围绕该业务，发酸思维，不断产生观点，创造性风暴，来确定需求。
5.2.2 需求变更
变更是不可避免的，需求的遗漏，不完整，理解误差等等都是原因。但是需求的变更及其影响范围也是需要控制的。软件需求文档应该精确描述要交付的产品，这是一个基本的原则，为了使开发组织能够严 格控制软件项目，应该确保以下事项：
- 仔细评估已建议的变更。
- 挑选合适的人选对变更做出判定。
- 变更应及时通知所有相关人员。
- 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。
1.变更控制过程
变更控制过程用来跟踪已建议变更的状态，使变更不会丢失，一旦确定了需求基线，所有已建议变更都需要遵循变更控制过程。
1.问题分析和变更描述：提出变更后需要对该提议进一步分析，检查有效性，从而产生更明确的需求变更提议。
2.变更分析和成本计算：接受该提议后，需要对变更进行影响分析和评估。成本的是因变更引起所有的改动包括文档、设计等。分析完成并确认后，进行是否执行变更的决策。
3.变更实现：确定执行变更后，需要根据其影响范围，安装刚开发的过程模型执行变更。在计划驱动模型中，往往需要回溯到需求分析阶段开始，重新分析、设计、实现等等；敏捷模型中，下一次迭代。
变更过程控制的目的不是阻碍变更，相反它是一个渠道和过滤器，通过它可把变更影响降至最小。
常见的需求变更策略：
- 所有变更祖训变更控制过程。
- 未经批准的变更，不做设计和实现工作。
- 变更应由CCB决定实现哪些变更。
- 项目风险承担者应了解吧ing内容。
- 原始需求需要保留不能因变更而删除，保留原始文档。
- 每个基础的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性。
2.变更控制委员会
变更控制委员会(Change Control Board,CCB)，项目所有权益代表，涉众是多方成员，它是决策机构不是作业机构，只决策不提出变更方案。
成员组成：
产品或计划管理部门、项目管理部门、开发部、测试部、市场部或客户代表、制作用户文档部、技术支持部、帮助桌面或用户支持热线部、配置管理部。
过程及操作步骤：
1.制定决策
制定决策过程的描述应确认：
- 变更控制委员会到会人数和有效决定必须出席的人数。
- 决策的方法(比如投票)
- 主席是否由一票否决权
2.交流情况
一旦CCB做出决策，指派人员及时更新请求的状态。
3.重新协商约定
变更是有代价的，即使是未批准的也消耗了资源。通过的重要变更，为适应变更情况需与管理部门和客户沟通，比如推迟交货时间、增加人手，推迟实现不重要需求，质量上折中等等。
5.2.3 需求追踪
编制每个需求同系统元素之间的联系文档，在整个项目的工件之间形成水平可追踪性。
跟踪能力信息使变更影响分析十分便利，有利于确认和评估实现某个建议的需求变更所必须的工作。
5.3 系统分析与设计
系统分析：系统分析师和用户在充分了解用户需求的基础上，把双方对新系统的理解表达为系统需求规格说明书。
系统设计：目标是根据系统分析的结果，完成系统的构建过程。其主要目的是绘制系统的
蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方
案和相关模型，指导系统实施工作的顺利开展。系统设计的主要内容包括概要设计和详细设计。
5.3.1 结构化方法
ASD(Structured Analysis and Structured Design)方法，也可称为面向功能的软件开发方法或面向数据流的软件开发方法。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它有结构化分析(SA)、结构化设计(SD)和结构化编程(SP)等方法。
1.SA
一组帮助系统分析人员产生功能规约的原理与技术，手段主要有数据流图（常用）、数据字典（常用）、结构化语言、判定表以及判定树等。
步骤：
分析业务情况，做出反映当前物理模型的数据流图(Data Flow Diagram,DFD);
推导出等价的逻辑模型的DFD;
设计新的逻辑系统，生成数据字典和基元描述；
建立人机接口，提出可供选择的目标系统物理模型的DFD;
确定各种方案的成本和风险等级，据此对各种方案进行分析；
选择一种方案；
建立完整的需求规约。
数据流图
DFD需求建模方法，也称为过程建模和功能建模方法。DFD建模方法的核心是数据流，从
应用系统的数据流着手以图形方式刻画和表示一个具体业务系统中的数据处理过程和数据流。
DFD建模方法首先抽象出具体应用的主要业务流程，然后分析其输入，如其初始的数据有哪
些，这些数据从哪里来，将流向何处，又经过了什么加工，加工后又变成了什么数据，这些数
据流最终将得到什么结果。通过对系统业务流程的层层追踪和分析把要解决的问题清晰地展现
及描述出来，为后续的设计、编码及实现系统的各项功能打下基础。
4种基本元素(模型对象)组成：数据流、处理/加工、数据存储和外部项。
建立DFD图的目的是描述系统的功能需求。过程及步骤：
1) .明确目标，确定系统范围：明确模型描述的问题域
2) .建立顶层DFD图：表达系统主要功能，确定内外关系和边界，是进一步分解基础。
3) .构建第一层DFD分解图：顶层DFD细化。
4) .开发DFD层次结构图：对第一层DFD分解，其原则：保持均匀的模型深度；按困难程度进行选择；如果一个处理难以确切命名，可以考虑对它重新分解。
按照规则检查和确定DFD图
- 父图中描述数据流必须有相应子图中出现；
- 一个处理至少有一个输入流和输出流；
- 一个存储必定有流入的数据流和流出的数据流；
- 一个数据流至少有一端是处理端；
- 模型图中表达和描述的信息是全面、完整、正确的一部分。
数据字典
数据字典(Data Dictionary)是一种用户可以访问的记录数据库和应用程序元数据的目录。其目的是对数据流程图中的各个元素做出详细的说明，作用是作为分析阶段的工具。
数据流图中数据块的数据结构中的数据项说明，不可再分。
数据流图中数据块的数据结构说明。数据结构反映了数据之间的组合关系。
数据流图中流线的说明。
数据流图中数据块的存储特性说明。
数据流图中功能块的说明。
2.SD
结构化设计(Structured Design,SD)是一种面向数据流的设计方法，它以SRS和SA阶段 所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。其基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段，其中概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；详细设计的主要任务是为每个模块设计实现的细节。
在SD中，这种功能分解就是将系统划分为模块，模块是组成系统的基本单位，它的特点是可
以自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。
1).信息隐藏：
封装，模块间独立，易于实现易于理解和维护。
抽象原则：提取事物最基本的特征和行为，忽略非本质的细节，分层抽象可控制开发过程复杂性，有利于理解和开发过程管理。抽象层次：过程抽象、数据抽象、控制抽象。
2).模块化
模块3个基本属性：功能(做什么)、逻辑(怎么做)、状态(使用环境和条件)。
描述模块时，必须按模块外部特性(名字、参数表、对整个程序影响等等)与内部特性(程序代码和仅自己使用的数据)分别描述，软件设计阶段先外部后内部。
3).耦合
表示模块间联系的程度，紧密耦合联系非常强，松散耦合联系非常弱，非直接耦合无任何联系。
模块间耦合强度，主要依赖：模块间调用，模块间传递数据量，模块间施加控制多少，模块间接口复杂度。
4).内聚
模块内部各代码成分间联系程度，是从功能角度来衡量的。
耦合低模块独立可单独开发维护，，内聚高模块的可理解性和维护性强，高内聚，低耦合。
2.系统结构图
系统结构图(Structure Chart,SC)又称为模块结构图，它是软件概要设计阶段的工具，反
映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总
体结构。
详设基本步骤：
分析并确定输入/输出数据的逻辑结构。
2).找出输入数据结构和输出数据结构中有对应关系的数据单元。
按一定的规则由输入、输出的数据结构导出程序结构。
列出基本操作与条件，并把它们分配到程序结构图的适当位置。
用伪码写出程序。
详细设计的表示工具有图形工具、表格工具和语言工具。
图形工具
业务流图、程序流程图、PAD(Problem Analysis Diagram)图、NS流程图(由Nassi和Shneiderman开发，简称NS)等。
程序流程图又称为程序框图，是使用最广泛然的一种描述程序逻辑结构的工具。它用方框
表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。其优点是：结构清晰，易于
理解，易于修改。缺点是：只能描述执行过程而不能描述有关的数据。
NS流程图，也称为盒图，是一种强制使用结构化构造的图示工具，也称为方框图。其具有
以下特点：功能域明确、不可能任意转移控制、很容易确定局部和全局数据的作用域、很容易
表示嵌套关系及模板的层次关系。
PAD图是一种改进的图形描述方式，可以用来取代程序流程图，相比程序流程图更直观，
结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制
结构的图示，并允许递归使用。PAD的特点如下：
使用PAD符号设计出的程序代码是结构化程序代码；
PAD所描绘的程序结构十分清晰；
用PAD图表现程序的逻辑易读、易懂和易记；
容易将PAD图转换成高级语言源程序自动完成；
既可以表示逻辑，也可用来描绘数据结构；
支持自顶向下方法的使用。
表格工具
可以用一张表来描述过程的细节，在这张表中列出了各种可能的操作和相应的条件。
语言工具
用某种高级语言来描述过程的细节，例如伪码和PDL(Program Design Language)等。
PDL的优点：可以作为注释直接插在源程序中；可以使用普通的文本编辑工具或文字处
理工具产生和管理；已经有自动处理程序存在，而且可以自动由PDL生成程序代码。
PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动作间对应关系时，不如
判定树清晰简单。
3.SP
结构化程序设计(Structured Programing,SP)是“面向结构”的程序设计方法即结构化程序设计方法，是“面向过程”方法的改进，结构上将软件系统划分为若干功能模块，各模块按要求单独编程，再组合构成相应的软件系统。该方法强调程序的结构性，所以容易做到易读易懂。该方法思路清晰，做法规范，程序的出错率和维护费用大大减少。
结构化程序设计采用自顶向下、逐步求精的设计方法，各个模块通过“顺序、选择、循环”的控制结构进行连接，并且只有一个入口和一个出口。
结构化程序设计的原则可表示为：程序=(算法)+(数据结构)。
结构化程序设计提出的原则可以归纳为32个字：自顶向下，逐步细化；清晰第一，效率第
二；书写规范，缩进格式；基本结构，组合而成。
4.数据库设计
数据库设计是指根据用户的需求，在某一具体的数据库管理系统上，设计数据库的结构和
建立数据库的过程。数据库设计的内容包括：需求分析、概念结构设计、逻辑结构设计、物理
结构设计、数据库的实施和数据库的运行和维护。
概念结构设计 ：使用E-R图。
E-R图：实体、属性、联系(1:1,1:n,m:n)
5.3.2 面向对象方法
面向对象(Object-Oriented,OO)本质是主张参照人们认识一个现实系统的方法，完成分析、设计与实现一个软件系统，提倡用人类在现实生活中常用的思维方法来认识和理解描述客观事物，强调最终建立的系统能映射问题域，使得系统中的对象，以及对象之间的关系能够如实地反映问题域中固有的事物及其关系。
面向 对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程，主要包括需求分析、系统分析、系统设计和系统实现4个阶段，但是，各个阶段的划分不像结构化开发
方法那样清晰，而是在各个阶段之间迭代进行的。
1.面向对象分析
面向对象的分析方法(Object-Oriented Analysis,OOA),是在一个系统的开发过程中进 行了系统业务调查以后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。 OOA所强调的是在系统调查资料的基础上，针对OO方法所需要的素材进行的归类分析和整 理，而不是对管理业务现状和方法的分析。
OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识 对象类、标识结构、定义主题、定义属性和定义服务)组成。在这种方法中定义了两种对象类 之间的结构，一种称为分类结构；另一种称为组装结构。分类结构就是所谓的一般与特殊的关 系。组装结构则反映了对象之间的整体与部分的关系。
1).OOA原则
①抽象
②封装
③继承
④分类
⑤聚合
⑥关联
⑦消息通信
⑧粒度控制
⑨行为分析
2).基本步骤
①确定对象和类
问题域的复杂性和连接关系。
事物的总体概貌和总体分析模型。
④确定属性
⑤确定方法
2.面向对象设计
面向对象设计方法(Object-Oriented Design,OOD)是OOA方法的延续，其基本思想包括 抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在 数据结构上定义的操作算法封装在一个对象之中。由于现实世界中的事物都可以抽象出对象的 集合，所以OOD方法是一种更接近现实世界、更自然的系统设计方法。
在OOD中，类可以分为3种类型：实体类、控制类和边界类：
1).实体类
2).控制类
3).边界类
3.面向对象编程
面向对象程序设计(Object Oriented Programming,OOP)是一种计算机编程架构。OOP的 一条基本原则是计算机程序由单个能够起到子程序作用的单元或对象组合而成。OOP达到了软 件工程的3个主要目标：重用性、灵活性和扩展性。OOP=对象+类+继承+多态+消息，其中核心概念是类和对象。
OOP的基本特点有封装、继承和多态：
1).封装
2).继承
3).多态
4.数据持久化
对象只能存在于内存中，需要进行对象的持久化(Persistence)，引入持久层(Persistence Layer)，
主流的持久化技术框 架包括Hibermate、iBatis和JDO等。
5.4 软件测试
软件测试的目的就是确保软件的质量、确认软件以正确的方式做了用户所期望的事情，所 以软件测试工作主要是发现软件的错误、有效定义和实现软件成分由低层到高层的组装过程、验证软件是否满足任务书和系统定义文档所规定的技术要求、为软件质量模型的建立提供依据。
软件测试不仅是要确保软件的质量，还要给开发人员提供信息，以方便其为风险评估做相应的
准备，重要的是软件测试要贯穿在整个软件开发的过程中，保证整个软件开发的过程是高质量的。
5.4.1 测试方法
静态测试(Static Testing,ST)和动态测试(Dynamic Testing,DT);以具体实现算法细节和系统内部结构的相 关情况为根据可分黑盒测试、白盒测试和灰盒测试3类；从程序执行的方式来分类，可分为人
工测试(Manual Testing,MT)和自动化测试(Automatic Testing,AT)。
1).静态测试：程序不运行，通过分析和检查语句、结构、过程来检查是否有错误。即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而来找出错误。例如不匹配的参数，未定义的变量等。
2).动态测试：运行程序。3个步骤：构造测试实例、执行程序以及分析结果。
3).黑盒测试：
根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范 说明准确无误的运行。其主要是对软件界面和软件功能进行测试。对于黑盒测试行为必须加以 量化才能够有效的保证软件的质量。
4).白盒测试：
借助程序内部的逻辑和相关信息，通过检测内部动作是否按照设计规格说明书的设定进行，检查每一条通路能否正常工作。
常用的白盒测试法有控制流分析、数据流分析、路径分析、程序变异等。根据测试用例的覆盖程度，分为语句覆盖、判定覆盖、分支覆盖和路径覆盖等。
5).灰盒测试：白+黑
6).自动化测试：
5.4.2 测试阶段
单元测试、集成测试和系统测试，系统测试中又包含了 多种不同的测试种类，例如功能测试、性能测试、验收测试、压力测试等。
模块进行测试。首先要读懂逻辑，而且应通过静态测试，如静态分析、代码审查等。黑盒测一遍，白盒再验证。条件覆盖路径覆盖等。
已经严格按照程序设计要求和标准组装起来的模块同时进行测试，
系统测试一般采用黑盒测试。主要测试内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。
负载测试和压力测试都是。
通过负载测试， 确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化 情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大 服务级别的测试。
最后一个阶段的测试。验收测试的主要目标是为用户展示所开发出来的软件符合预定的要求和有关标准，并验证软件实际工作的有效性和可靠性，确保用户能用该软件顺利完成既定的任务和功能。
通过了验收测试，应进行Alpha测试或Beta测试。Alpha测试是在软件开发环境下由用户进行的测试，或者模拟实际操作环境进而进行的测试，主要是对软件产品的功能、局域化、界面、可使用性
以及性能等等方面进行评价；而Beta测试是在实际环境中由多个用户对其进行测试，并将在测试过程中发现的错误有效反馈给软件开发者。
如AB测试(web/app或多个版本)、Web测试中的链接测试、表单测试等。
链接测试：它是在页面之间切换和指导用户去一些未知地址页面的主要手段。3方面：
首先，测试所有链接是否按指示的 那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系 统上没有孤立的页面。
表单测试：当用户通过表单提交信息的时候，都希望表单能正常工作。
5.5 净室软件工程
净室(Cleaning Room)软件工程是一种应用数学与统计学理论以经济的方式生产高质量软 件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件。
净室软件工程(Cleanroom Software Engineering,CSE)是一种在软件开发过程中强调在软件中建立正确性的需要的方法。在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。
运用数学和统计学理论在设计之初就尽可能的消除缺陷和错误，以合理的成本开发高质量软件的面向工作组的方法。
5.5.1 理论基础
净室软件工程的理论基础主要是函数理论和抽样理论。
1.函数
一个函数定义了从定义域到值域的映射。一个特定的程序好似定义了一个从定义域(所有可能的输入序列的集合)到值域(所有对应于输入的输出集合)的映射。这样，一个程序的规范就是一个函数的规范。
一个明确定义的函数应当具有以下特性。
●完备性：对定义域中的每个元素，值域中至少有一个元素与之对应。对程序而言，每种
可能的输入都必须定义，并有一个输出与之对应。
●一致性：在值域中最多有一个元素与定义域中的同一元素对应。对程序而言，每个输入只能对应一个输出。
●正确性：函数的正确性可以由上述性质判断。对程序而言，某项设计的正确性可以通过基于函数理论的推理来验证。
2.抽样理论
不可能对软件的所有可能应用都进行测试。把软件的所有可能的使用情况看作总体，通过统计学手段对其进行抽样，并对样本进行测试，根据测试结果分析软件的性能和可靠性。
5.5.2 技术与手段
1.统计过程控制下的增量式开发(Incremental Development)
增量开发基于产品开发中受控迭代的工程原理——控制迭代。增量开发不是把整个开发过程作为一个整体，而是将其划分为一系列较小的累积增量。小组成员在任何时刻只须把注意力集中于工作的一部分，而无须一次考虑所有的事情。
2.基于函数的规范与设计
盒子结构方法按照函数理论定义了3种抽象层次：行为视图、有限状态机视图和过程视图。规范从一个外部行为视图(称为黑盒)开始，然后被转化为一个状态机视图(称为状态盒),最后由一个过程视图(明盒)来实现。盒子结构是基于对象的，并支持软件工程的关键原则：信息隐藏和实现分离。
3.正确性验证
正确性验证被认为是CSE的核心，正是由于采用了这一技术，净室项目的软件质量才有了极大的提高。
4.统计测试(Statistically Based Testing)和软件认证
净室测试方法采用统计学的基本原理，即当总体太大时必须采取抽样的方法。首先确定一个使用模型(Usage Model)来代表系统所有可能使用的(一般是无限的)总体。然后由使用模型产生测试用例。因为测试用例是总体的一个随机样本，所以可得到系统预期操作性能的有效统计推导。
净室软件工程是软件开发的一种形式化方法，它可以生成质量非常高的软件。它使用盒子
结构规约进行分析和设计建模，并且强调将正确性验证(而不是测试)作为发现和消除错误的
主要机制。
5.5.3 应用与缺点
缺点：
1)CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。CSE要求采用增量式开发、盒子结构、统计测试方法，普通工程师必须经过加强训练才能掌握，开发软件的成本比较高昂。
2)CSE开发小组不进行传统的模块测试，这是不现实的。工程师可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的bug也可能导致未预期的错误。
3)CSE毕竟脱胎于传统软件工程，不可避免地带有传统软件工程的一些弊端。
5.6 基于构建的软件工程
基于构件的软件工程(Component-Based Software Engineering,CBSE)是一种基于分布对
象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。
ommercial-Off-The-Shelf)构件，也可是自行开发构件。
它体现了"购买而非重新构造"，工程师焦点从 "实现"变成"集成"，软件开发从程序编写到了基于构件组装。
意义：更快的构造系统，减轻用了支持和升级大型系统所需的维护负担，降低成本。
前提基础：很多大型软件系统中存在足够多的共性。
5.6.1 构件和构件模型
CBSE的构件应该具备以下特征。
可组装型：公开定义接口交互。
可部署性：自包含，独立实体，二进形式，无需部署前编译。
文档化：根据文档查看是否满足需求。
独立性：独立的，无特殊情况下可进行组装和不少，如确需提供其他构件服务需声明。
标准化：在CNSE过程中使用的构件必须符合某种标准化的构件模型。
目前主流的构件模型是Web Services模型、Sun公司的EJB模型和微软的.NET模型。
构件模型包含了一些模型要素，这些要素信息定义了构件接口、在程序中使用构件需要知 道的信息，以及构件应该如何部署。
构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义
中应该包含的要素，如操作名、参数以及异常等。
为使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。构件元数据是构件本身相关的数据，比如构件的接口和属性信息。用户可以通过元数据找到构件提供的服务。构件模型的实现通常包括访问构件的元数据的特定方法。构件是通用实体，在部署的时候，必须对构件进行配置来适应应用系统。
构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的信息和它的二进制构成的信息。
构件模型提供了一组被构件使用的通用服务，这种服务包括以下两种。
●平台服务，允许构件在分布式环境下通信和互操作。
●支持服务，这是很多构件需要的共性服务。例如，构件都需要的身份认证服务。
5.6.2 CBSE过程
CBSE过程是支持基于构件组装的软件开发过程，需要考虑构件复用的可能性，以及在开发和使用可复用的构件中所涉及的不同过程活动。成功的构件复用需要一个经过裁剪、适配的开发过程，以便在软件开发过程中包含可复用的构件。
CBSE过程中的主要活动包括：
(1)系统需求概览；
(2)识别候选构件；
(3)根据发现的构件修改需求；
(4)体系结构设计；
(5)构件定制与适配；
(6)组装构件，创建系统。
这种CBSE过程与传统的软件开发过程存在几点不同。
(1)CBSE早期需要完整的需求，以便尽可能多地识别出可复用的构件。而增量式开发中，早期并不需要完整的需求。
(2)在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。通过劝说用户修改需求，以便能节省开支且快速开发系统。
(3)在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
(4)开发就是将已经找到的构件集成在一起的组装过程。其中包括将构件与构件模型基础设施集成在一起，有时还需要开发适配器来协调不匹配的构件接口，可能还需要开发额外的功能。
在CBSE中，体系结构设计阶段特别重要。在这个阶段，将选择一个构件模型和一个实现平台。而模型和平台也决定和限制了可选构件的范围。
5.6.3 构件组装
构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造
一个系统或另一个构件的过程。
1.顺序组装：顺序调用已经存在的构件
2.层次组装：在一个构件直接调用由另一个构件所提供的服务时
3.叠加组装：发生在两个或两个以上构件放在一起来创建一个新构件的时候。
发生的不兼容情况：
(1)参数不兼容。接口每一侧的操作有相同的名字，但参数类型或参数个数不相同。
(2)操作不兼容。提供接口和请求接口的操作名不同，
(3)操作不完备。一个构件的提供接口是另一个构件请求接口的一个子集，或者相反。
5.7 软件项目管理
5.7.1 软件管理概述
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
5.7.2 软件进度管理
所谓进度，指的是对执行活动和里程碑所制定的工作计划，而进度管理指的是为了确保项目按期完成所需要的管理过程。在软件进度管理过程中，一般包括：活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制。
1.工作分解结构
软件项目往往是比较大而复杂的，往往需要进行层层分解，将大的任务分解成一个个的单一小任务进行处理。工作分解结构(Work Breakdown Structure,WBS)就是把一个项目，按照一定的原则分解成任务，任务在分解成一项项工作，再把一项项工作分配给个人，直到分解不下去为止。即：项目->任务->工作->日常活动。
工作分解结构以交付成果为导向，对项目要素进行的分组，它归纳和定义了项目的整个工作范围。
WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划的基础。
WBS树最底层被成为工作包，是最低层次的交付成果，它是应当由唯一主题负责完成。
WBS常见分解方式：按产品的物理结构、按产品或项目的功能、按实施过程、按项目的实施单位、按项目的目标、按部分或职能。
WBS分解的基本要求：
1).WBS工作包是可控和可管理的，不能过于复杂。
2).任务分解也不能过细，一般原则WBS的树形结构不超过6层。
3).每个工作包要有一个交付成果。
4).每个任务必须由明确定义的完成标准。
5).WBS必须有利于责任分配
2.任务活动图
它是项目进度管理、项目成本管理等一系列项目管理活动的基础。多采用甘特图来展示和管理。
工作分解后会得到一组活动图，这是需要对每个活动进行定义，并确定活动间关系。
活动定义：完成项目的各个活动必须完成的具体活动。需要明确每个活动的前驱、持续时间、必须完成日期、里程碑或交付成果。
- 前驱：该活动开始前必须发生的事件集
- 持续时间：完成该活动的时间
- 必须完成日期：必须完成具体日期
- 里程碑：判定该活动的一组条件。
以上明确了后，活动间关系(顺序等)也就确定了，根据活动顺序就可得到任务活动图。
57.3 软件配置管理
SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。
软件配置管理核心内容包括版本控制和变更控制。
(1)版本控制(Version Control)。
(2)变更控制(Change Control)。
5.7.4 软件质量管理
软件质量就是软件与明确地和隐含地定义的需求相一致的程度，更具体地说，软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准以及所有专业开发的软件都应具有的隐含特征的程度。
从管理角度出发，可以将影响软件质量的因素划分为3组，分别反映用户在使用软件产品时的3种不同倾向和观点。这3组分别是：产品运行、产品修改和产品转移
软件配置管理(Software Configuration Management,SCM)是一种标识、组织和控制修改的技术。
1.软件质量保证
软件质量保证(Software Quality Assurance,SQA)是建立一套有计划，用系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。目的是使软件过程对于管理人员来说是可见的。
软件质量保证的关注点集中在于一开始就避免缺陷的产生。质量保证的主要目标是：
(1)事前预防工作，例如，着重于缺陷预防而不是缺陷检查。
(2)尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段。
(3)作用于过程而不是最终产品，因此它有可能会带来广泛的影响与巨大的收益。
(4)贯穿于所有的活动之中，而不是只集中于一点。
软件质量保证的主要任务是以下3个方面：
(1)SQA审计与评审。
(2)SQA报告。
(3)处理不符合问题。
2.软件质量认证
1)ISO 9000
能力成熟度模型(Capability Maturity Model,CMM)。
5.7.5 关键风险管理
风险管理的主要目标是预防风险。
软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。
美国Boehm的软件风险管理体系，把风险管理活动分成风险估计(风险辨识、风险分析、风险排序)和风险控制(风险管理计划、风险处理、风险监督)两大阶段。该体系偏重理论。
美国Charette的风险分析和管理体系，把风险分成分析(辨识、估计、评价)和管理(计划、控制、监督)两大阶段。该体系偏重理论，与Boehm体系接近。
美国卡内基梅隆大学软件研究所的CMU-SEI风险管理体系，包括SRE、CRM(Continuous Risk Management)、TRM(Team Risk Management)与CMM配合的软件风险管理，是基于实践的全面风险管理体系，并将软件需求方作为软件风险管理的要素。
