软件工程_软件工程csdn-优快云博客

本文链接：https://blog.youkuaiyun.com/m0_55661792/article/details/142410570

软件工程的基本要素：

方法：告知软件开发如何做，包括软件项目估算与计划、需求分析、概要设计、算法设计、编码、测试、维护等方面。

工具：为软件工程方法提供自动、半自动的软件支撑环境。

过程：过程将方法和工具综合合理的使用起来，是软件工程的基础。

注：在概要设计阶段进行软件体系结构的设计

一、软件开发模型

软件开发模型是软件开发的指导思想、开发体系。

瀑布模型SDLC

瀑布模型是逐级向下完成，每一步分都设有阶段评审用来评审当前阶段是否达到预期，如果达到则进行下一步，后改进在每一步还添加了回溯，如果当前步骤遇到问题无法解决则回溯到上一步进行修改，然后再返回本阶段。

缺陷：

对需求的变化无法灵活应对。软件开发的初期，用户的需求往往是不明确的，在目标不明确的情况下便进行需求分析然后逐步实现软件，直到软件测试后交予用户。此时往往开发的软件并不符合用户预期，需要进一步修正，此时再要修改便要返回去调整需求分析几乎是从头来过，会浪费大量的时间导致项目失败。

注：项目延期、项目超支、项目难以继续等都属于项目失败。

适用：

需求明确、二次开发，或者需求分析用其他方法明确之后，后面的步骤采用瀑布模型开发。

原型模型

原型与瀑布模型是互补的一对模型，往往只用于软件开发的需求分析阶段。原型主要针对于需求不明确的情况，强调在项目开发的初期构造一个成本较低的简易系统，简易系统体现正式系统完成之后的主要样貌，简易系统可以是界面、按钮、也可以是初步的系统，让用户先接触尝试，记录用户问题对简易系统进行调整，经过多轮调整之后需求逐步明确。具有抛弃性

演化模型

演化模型又称变换模型，是先开发出一个可以使用的原型版本，然后逐步演化、调整最终实现软件产品，不具有抛弃性

增量模型

增量模型包含了瀑布模型的基本成分和原型模型的迭代。他的特点是容易理解管理成本低。

增量模型强调，先做一块、再做一块，每个增量均发布一个可操作的产品。进行软件开发时先用部分时间将核心部分进行开发，核心部分开发完成之后交付用户尝试使用。第一个可交付的版本耗时少、成本低。然后继续开发后面的模块，将软件一部分一部的分交付到用户手中到最终完成所有部分。核心模块最先交付，在使用过程中进行检验，此方法可以使开发的风险有效减小。

螺旋模型

螺旋模型是演化模型的一类，他具有瀑布模型和原型模型的特点，引入独有的风险分析。特别适用于大型发杂的系统。

螺旋模型支持动态变化，但过多的迭代次数可能会增加开发成本从而延迟提交时间。开发过程中可能会产生多个中间版本，但是不强调快速提供初始版本。要求开发人员具有一定的风险分析能力。

V模型

V模型类似于瀑布模型，但是最显著的不同是，V模型将整体测试细化为多个测试，强调尽早进行测试，强调测试贯穿开发始终。

喷泉模型

其他模型都是结构化模型，瀑布模型就是结构化模型的代表，而喷泉模型是面向对象的模型，是面向对象的模型的代表。他以用户需求为动力，其特点是迭代、无间隙、复用性好。

快速开发模型RAD

由瀑布模型SDLC和构建化开发模型CBSD组合而成，用可视化做开发就是快速开发模型，特点是可以快速的构建应用系统。

构建组装模型CBSD

目前来讲应用较为广泛，他的思路是，将软件开发当中的各个模块做成标准构件，然后将构件进行组装集得到软件。

构件库中有许多累积而来的构件，这些构件的来源是之前开发的软件需要的构件，这些构件经过了现投入使用的软件的检验可靠性较高，如果软件需求相同可以使用同一个构件不需要新开发，因此降低了开发时间和开发成本

统一过程模型UP或RUP

应用非常广泛，一般应用于较为大型的开发。

特点

用例驱动

最开始时通过需求分析挖掘出用例，进一步实现用例，然后将这些用例作为指导开发的测试用例，所以在整个开发过程中都是由用例驱动的。

以架构为中心

统一过程强调先要设计好架构，然后再进行构件填充。

迭代和增量

环形循环迭代，每一步都有增量产出。

敏捷开发方法

敏捷开发方法适用于小项目，敏捷开发方法是一类开发方法包含：自适应开发、水晶开发、特征驱动开发、SCRUM、极限编程是将不必要的流程取消、会议时间缩短、不必要的文档取消等。

水晶方法

水晶法以人为中心，认为每个不同项目需要不同的方法论、约定、策略。

scrum

使用迭代方法，把每段时间一次的迭代称为冲刺，并按需求的优先级别来实现产品，多个组并行递增实现产品。

极限编程

只处理当前的需求，使测试变得简单。要求测试先行，先写单元测试代码，再开发。可以按日、小时为客户提供可运行的版本，系统最终用户代表应该全程配合团队，双方共同对系统负责，不影响编码速度，主要是解决代码质量问题。

敏捷统一过程AUP

大型任务连续，小型任务迭代。采用经典的up阶段性活动，初始、精化、构建、转换。

工作量估算模型

工作量估算模型又称项目成本估算模型。是一种原型化开发方法。

估算点：对象点、功能点、代码行

开发高风险软件时可采用基于对象点的估算；

软件设计早期的体系结构采用基于功能点的估算；

软件开发时期，可采用基于代码行的估算。

后体系结构阶段模型基于早期设计模型。

二、信息系统的开发方法

原型化方法适用于需求不清晰且规模不大的情况，结构化方法适用于数据处理领域，需求变化不大的情况。

结构化法

缺点

结构化方法进行开发，一旦开发完成，他的结构几乎是定性的，牵一发而动全身，不能灵活的应对变动，一旦需要修改一般是要进行大修，极不方便。

原型法

面向对象方法

开发之前先将所涉及到的人、物都抽象为对象，以对象为基准，建立一个全面、合理、统一的模型，对象与对象之间使用同一个模型，对象之间的区别使用属性来区分，这样系统与系统之间如果对象相同可以进行复用，不同的对象之间如果有相同的属性也可以进行复用。面向对象方法中分析、设计、实现三个阶段的界限不明确。

面向服务方法

三、需求

需求分类

需求分析

需求分析阶段主要任务是：

确定软件的综合要求

系统的界面、功能、性能，安全性，保密性，可靠性方面的要求；确定系统运行的要求，异常处理，将来的扩充和修改等。

分析软件系统的数据要求

基本数据元素，数据元素之间的逻辑关系，数据量和峰值等。

导出系统的逻辑模型

修正项目开发计划

需求说明书

对于已经确定下来的需求应当得到清晰准确的描述。这种只能描述需求的文档称之为软件需求说明书。

说明书主要内容是

系统的数据描述，数据流图，数据字典描述，系统接口描述，内部接口说明，系统的功能描述，处理说明，系统设计的限制系统性能的描述，性能参数，对系统进行测试的种类等。

三、结构化设计

设计接口：依据数据流图描述软件与外部环境之间的交互关系，软件内模块之间的调用关系。

架构：定义软件的主要结构元素。

数据存储设计：确定软件涉及的文件系统的结构及数据库的表结构。

详细设计：确定各个模块的详细算法和数据结构。

概要设计：系统架构、模块划分、系统接口、数据设计。

模块

模块应该保持大小适中，减少调用的深度

多扇入少扇出：多箭头指向自己，少箭头由自己指出

单入口，单出口

作用域在本模块之内

功能可预测

内聚

模块内部

注：偶然内聚属于最低内聚，不易修改，不易维护，不绎理解，影响模块耦合关系。

耦合

模块与模块之间

注：耦合程度不取决模块功能数

模块结构（系统结构）

结构化分析方法组成：分层数据流图、数据字典、加工逻辑说明、补充说明

四、软件测试

测试原则

尽早、不断的进行测试

程序员避免测试自己设计的程序

合理不合理数据都要测

既要选择有效、合理的数据测试程序，也要选择无效不合理的数据测试程序反应

修改后应该进行回归测试

即修改完软件中的一个模块之后应该把其他的模块再测一遍

尚未发现的错误数量与已发现的错误数量成正比

例如程序A测出了10个错误，程序B测出了50个错误，都各自修改完成后，重点测试的应该是程序B，因为，测出的错误越多说明程序越不成熟，可能隐藏的错误也越多，而且修改错误的同时也会引入新的错误，即已发现错误数与未发现错误数成正比。

测试类型

测试用例设计

黑盒测试

将程序视作整体黑盒，无法直接查看程序内部内容，只能将程序看作一个整体，测试出入输出。

等价类划分

将程序每个等级进行测试，例如将成绩进行分类的程序，90分以上为优等，70分以上为良好，60分以上为及格，60分以下不及格，在优等划分里面选择96进行测试，在良好里面选择79进行测试，在及格里面选择65进行测试，在不及格里面选择就12进行测试，此为等价类划分。

边界值分析

对边界值进行测试，例如上改为述例子中，其实是存在问题的，但是等价类划分不能测出，如果输入90进行测试，90本质属于优等，但是测出来是归为了良好，此时便需要进行边界值分析，将上述改为：≥90分为优等。边界值的选择往往选四个边界值进行测试：略小于最小值的、最小值、略大于最大值、最大值，例如年龄0-150岁，边界值分析应该选择-1、1、150、151。

错误推测

凭借经验中总结的易错点对程序进推测测试。

因果图

由结果分析原因。

白盒测试

基本路径测试

循环覆盖测试

逻辑覆盖测试

语句覆盖

语句覆盖是层级最低的，将所有语句全部用用例覆盖一遍。

判定覆盖

将所有分支全部覆盖，例如 if 判断语句中需要将Y、N分支都覆盖一次。

条件覆盖

例如 if 判断语句中有两部分 if（A>0&&B<0）则需要将A>0走一遍Y、N语句；将B<0也走一遍Y、N语句；

路径覆盖

路径覆盖是层级最高的，将所有可能的路径全部覆盖一遍。

测试阶段

一般软件项目只做单元、集成、确认测试；集成项目会加做系统测试。

单元测试

集成测试

确认测试

系统测试

系统测试项目众多，包含：恢复测试、安全性测试、压力测试、性能测试、可靠性测试、可用性测试、可维护性测试、安装测试。

一般主要从压力测试、性能测试、可靠程度测试几个方面来进行测试。

五、McCabe复杂度

将流程图转化为有向图计算复杂度，其实不转化也可以计算。

在转化过程中，流程图中线的交点可以转换成有向图的结点，也可以不转化成有向图的结点，因为结点减少的同时线也在减少，节点增多线也会增多，因此不会影响最终的计算结果。

环路复杂度是：边数量 - 结点数量+2

环路复杂度也可以是：图中的环路个数+1

六、系统维护

软件包括声明周期：立项阶段、开发阶段、运行维护阶段、消亡阶段。

软件维护阶段是软件生命周期的一个完整部分，也是耗时最长的部分，软件维护主要工作是通过维护确保系统可以正常的运行。

可维护性

维护类型

适应性维护和完善性维护：

在原有基础上提升是适应性维护；

在原有基础上补充是完善性维护；

软件能力软件过程改进CMMI

CMMI是由软件开发的能力成熟度模型CMM发展而来，主要用来衡量软件开发的承包商改善软件质量的能力。

注：此部分往往以选择的方式考察阶段与特点的对应。

阶段式：根据组织能力成熟度划分

成熟度等级	级别特点	助记
一级：混乱级	所有未通过CMMI相应级别的机构	极其依赖个人
二级：已管理级 (个人项目级)	需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证达到CMMI相关标准	建立基本的项目管理过程，某个项目经理有过此类项目经验可以将经验应用到下一个类似的项目中。
三级：已定义级 (企业组织级)	文档化、标准化、组织级集成环境	强调公司内部组织可以给我提供此类项目的模板、经验、工具指导，在完成项目之后也可以将自身积累的经验传进去
四级：定量管理级	组织级过程性能、定量项目管理	关键词:量化，有详细的度量标准
五级：优化级	组织改革与实施、因果分析和解决方案	持续优化

连续式：根据组织过程能力划分

CL0未完成	过程域未执行，一个或多个目标未完成
CL1已执行	将可标识输入转换成可标识输出产品，用来实现过程域特定目标
CL2已管理	已管理的过程制度化，项目实施遵循文档化的计划和过程。项目成员有足够的资源使用，所有工作、任务都被监听控制评审。
CL3已定义级	已定义的过程制度化，按标准进行剪裁，收集过程资产和过程度量，便于将来的过程改进
CL4定量管理	量化管理的过程制度化。利用量化、质量保证、测量手段进行过程域改进和控制，管理准则是建立、使用过程执行和质量的定量目标
CL5优化的	使用量化手段改变、优化过程域

七、项目管理知识领域

时间管理、风险管理较为重要。其余领域分别是：范围、成本、质量、人力资源、沟通、采购、整体管理。

时间管理

甘特图（Gannt）

用图表示进度的安排情况，特点是简洁明了，可以直观看到计划。缺点是过于简单明了不能清晰表达任务之间的逻辑关系，无法表达哪个任务先做哪个任务后做。

PERT图

关键路径：

从开始结点到最后结点最长的、包含结点最多的路径，对应的是整个项目最短的工期。

事件最早开始时刻取最大值

例：

事件1的最早开始时刻是0；

事件2的最早开始时刻就是事件1的最早开始时刻加上事件持续时间2，所以事件2的最早开始时刻是2；

事件3的最早开始时刻就是事件2的最早开始时刻加上事件持续时间2，所以事件3的最早开始时刻是4；

以此类推事件7的最早开始时刻是9；

事件6的最早开始时刻从事件4到事件6来看是4；但是从事件1到事件6来看是3，事件最早开始时刻取最大值，所以事件6的最早开始时刻是4；

同理

事件8的最早开始时刻从事件5-8来看是4+5=9，从事件6-8来看是4+1=5，取最大值9；

事件9从事件7-9来看是9+6=15，从事件8-9来看是9+4=13，取最大值-15；

事件最晚开始时刻取最小值

事件最晚开始时刻是事件最早开始时刻的逆过程。

例：

事件15的最晚开始时刻等于其最早开始时刻15；

事件7的最晚开始时刻就是事件15的最晚开始时刻减去事件持续事件15-6=9；

事件5的最晚开始时刻就是事件7的最晚开始时刻减去事件持续事件19-5=4；

事件1的最晚开始时刻从事件2-1来看是2-2=0；从3-1来看是9-2=7，事件最晚开始时刻取最小值，所以事件1的最晚开始时刻是0；

松弛时间

又称最多延迟执行的时间，计算方法是最晚开始时间减去最早开始时间。

例：

答案：DC

风险管理

风险管理是指损失或伤害的可能性做风险管理的时候会关心未来、关心变化、关心选择。

风险分类

项目风险

项目层级的风险，比如项目组没有将项目做好，导致超出预算。或者没有计划好导致资金不够。

技术风险

对采用的技术不熟悉，导致无法控制；采用技术过于前沿存在不确定性；采用技术过于陈旧导致后续更新升级出现问题。

商业风险

项目风险和技术风险之外的风险因素，例如项目很顺利技术无风险但是市场不需要这个项目成果。

风险曝光度

计算方法：风险出现的概率 × 风险可能造成的损失；

用风险曝光度来衡量一个风险应不应该重点管控，风险曝光度大的应该重点管控。

例：

假设正在开发的软件项目可能存在一个未被发现的错误，而这个错误出现的概率是0.5%，给公司造成的损失将是1000 000元，那么这个错误的风险曝光度为：

0.5% x 1000 000=5000

软件危机

软件危机是指在软件的开发和维护过程中所遇到的一系列眼中问题。主要可分为两个大类，一类是软件生产本身存在着复杂性，另一类与软件开发所使用的方法和技术有关

软件需求的增长得不到满足

软件生产成本高、价格昂贵

软件生产进度无法控制

软件需求定义不够明确

软件质量不易保证

软件可维护性差

八、其他

软件质量

用户界面设计

用户界面设计黄金准则

方便用户操纵控制、减轻用户记忆负担、保持界面一致

软件维护

软件交付后的维护过程中虽然存在软件版本更迭，但是这不属于配置管理。

软件体系结构

管道/过滤器模式

面向数据六，用于实现复杂的数据多步转换处理，每个处理步骤封装在一共过滤器软件中。数据通过相邻过滤器之间的管道传输。

特点：

具有良好的隐蔽性且高内聚低耦合；

支持软件重用；

支持并行执行；

在维护和增强方面系统性能简单，但本身不提高性能。

C/S（客户/服务器）体系

允许合理的划分三层功能，使之在逻辑上保持相对独立。

允许各层灵活的选用平台和软件。

各层可以选用不同的开发语言并行开发。

系统安装、维护、修改等需要在客户服务端和服务器两端进行修改。

仓库风格体系

数据库系统、黑板系统、超文本系统等都属于仓库风格。

缺点：

存在测试困难

效率低

开发成本高

缺少并发支持等问题。

优点：

支持更改、维护；

具有可复用的知识源；

支持容错性和健壮性

平均无故障时间MTTF	无故障运行平均时间
平均修复时间MTTR	系统故障到维修结束
平均失效间隔MTBF	两次故障发生之间的时间段的平均值