软件工程期末复习

太极生两鱼

已于 2022-09-08 23:49:30 修改

阅读量866

点赞数 1

分类专栏：笔记文章标签：软件工程期末笔记

于 2022-07-08 11:23:08 首次发布

本文链接：https://blog.csdn.net/qq_45823731/article/details/125674556

版权

笔记专栏收录该内容

16 篇文章 0 订阅

订阅专栏

一、二基础知识

软件的定义

指令的集合（计算机程序），通过执行这些指令可以满足预期的特性、功能和性能的需求。
数据结构：使得程序可以合理利用信息。
软件描述信息：用来描述程序的操作和使用。

软件的特点

软件是开发或设计出来的，而不是传统意义上的制造。
软件不会”磨损“。
尽管行业正在朝着基于组件的构件方向发展，但大多数软件仍然是定制的。

软件失效曲线图

在这里插入图片描述
横轴是时间，纵轴是失效率，在软件完整的生命周期中，将会面临变更(change)，就会由于（变更的）副作用而导致失效率突然提高。不断地变更是软件退化的根本原因。

软件工程的IEEE定义

将系统化的、规范化的、可量化的方法应用于软件的开发、运行与维护，即将工程方法运用于软件。
对上面所述方法的研究。

软件工程是一种层次化的技术

支持软件工程的质量根基在于质量关注点。
软件工程的基础是过程层，软件工程将各个技术层次结合在一起，使得合理，及时的开发计算机软件成为了可能。
过程定义了一个框架，构建该框架是有效实施软件工程技术必不可少的。
软件工程方法为构建软件提供技术上的解决方法。
软件工程工具为过程和方法提供自动化或半自动化的支持。

过程框架（包含框架活动和普适性活动）

框架活动

沟通：在技术工作开始之前，和利益相关者进行沟通，目的是理解利益相关者的项目目标，并收集需求来定义软件特性和功能。

策划：软件项目计划，定义和描述了软件工程工作，包括需要执行的技术任务，可能的风险，资源需求，工作产品和工作进度计划。

建模：需求分析，设计

构建：代码生成，测试

部署：全部或者部分分量交给用户，用户对其评测并给出反馈意见。

对于很多软件项目来说，随着项目的开展，框架活动可以迭代应用。在项目的多代迭代过程中，上述五个活动不断重复。每次软件迭代都很产生一个软件增量，每个软件增量实现了部分软件特性和功能。

普适性活动

软件项目跟踪和控制：软件根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。

风险管理：对可能影响项目结果，或者产品质量的风险进行评估。

技术评审：评估软件工程产品，尽量在错误传播到下一个活动之前发现并清除错误。

软件质量保证：确定和执行保证软件质量的活动。

测量：定义和收集过程，项目，以及产品的度量，以帮助团队在发布软件时满足利益相关者的要求。同时，测量还可以和其他框架的普适性活动配合使用。

工作产品准备和生产：包括生成产品（如建模，文档，日志，表格和列表等）所必须的活动。

可复用管理：定义工作产品复用的标准（包括软件构件），并且建立构件复用机制。

软件配置管理：在整个软件过程中管理变更所带来的影响。

过程的适应性调整
活动，动作和任务的总体流程以及相互依赖关系。
在每一个框架活动中，动作和任务细化的程度。
工作产品的定义和要求的程度。
质量保证活动应用的方式。
项目跟踪和控制活动应用的方式。
过程描述的详细程度和严谨程度。
客户和利益相关者对项目的参与程度。
软件团队所赋予的自主权。
队伍组织和角色的明确程度。

Hooker’s 通用原则
存在价值：能为用户提供价值而具有存在价值。
保持简洁：所有的设计都应该尽可能简洁，但不是过于简化。这有助于构建更易于理解和易于
维护的系统。
保持愿景：清晰的愿景是软件项目成功的基础。
关注使用者：在需求说明，设计和实现过程中，牢记要让别人理解你所做的事情。
面向未来：生命周期持久的系统具有更高的价值，永远不要把自己的设计局限于一隅。
提前计划复用：提前做好复用计划将降低开发费用，并增加可复用构件以及构件化系统的价
值。
认真思考：在行动之前清晰定位，完整思考通常能产生更好的结果。

软件开发神话是一个谬论。

三过程模型

通用过程模型

每个框架由一系列软件工程动作构成;动作由任务集来定义,这个任务集明确了将
要完成的工作任务，将要产生的工作产品，所需要的质量保证点，以及用于表明过程状态的里程碑。

过程流:描述了执行顺序和执行时间上如何组织框架中的活动,动作和任务。

在这里插入图片描述

线性过程流：从沟通到部署顺序执行五个框架活动；
迭代过程流：在执行下一个活动前重复执行之前的一个或多个活动；
演化过程流：采用循环的方式执行各个活动，每次循环都能产生更为完善软件版本；
并行过程流：将一个或多个活动与其他活动并行执行。

明确任务集
任务集：定义了为完成软件工程活动的目标而需要完成的实际工作。

完成一系列任务
完成一系列工作产品
应用一系列质量保证的过滤器
项目里程碑
电话交流这个动作所包含的任务集
通过电话和利益相关者取得联系
讨论需求并做记录
将笔记整理成一份简单的书面需求
通过邮件请利益相关者审阅并认可

惯用过程模型

惯用过程模型对软件工程提倡了一种有序的方法。活动和任务都是按照过程的特定指引顺序进行的。

the code-and-fix model
软件开发是一个人的任务；这是一个科学或工程应用；开发人员也是软件的用户；需求是完全知道的；软件产品的开发主要涉及编写代码并修复bug(如果有的话)。

瀑布模型（经典生命周期）

在这里插入图片描述
优点：适用于工程量小，人力资源少并且开发过程中改动不大的项目。
缺点：错误发现时间迟，产生的风险代价高。

V模型

和瀑布模型并没有本质的区别，将验证和确认动作应用于早期软件工程工作中的直观方法。
在这里插入图片描述
遇到的问题：

实际的项目很少遵循瀑布模型提出的顺序
客户难以清楚的描述所有需求
客户必须要有耐心，只有项目接近尾声的时候，他们才能得到可执行程序。

增量模型

在这里插入图片描述

以增量的方式应用瀑布模型的元素
第一个增量通常是核心产品
后续元素提供了扩展功能
随后的特性被创建，而核心产品可能要进行评估
如果客户要求的截至日期是不可能满足的，那么一系列的发布可能会解决这个问题。
允许一个团队的人员配置波动。

优点：

能在短时间内向用户提交可完成部分工作的产品。
逐步增加产品功能使用户有充裕的时间学习和适应新产品，从而避免一个全新的软件可能给客户组织带来冲击。
规避技术风险
可并行开发构件，加快开发进度
对于在业务截至日期之前完全实施的人员配置非常有用。

缺点：

并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

适用范围：

进行已有产品升级或新版本开发，增量模型是非常适合的；
对完成期限严格要求的产品，可以使用增量模型；
对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
项目在既定的商业要求期限之前不可能找到足够的开发人员

平行模型

在这里插入图片描述

强调短的开发周期
如果需求被很好的理解，那么项目范围会受到限制
对于大型项目可能需要大量的人力资源
对于不高度模块化的系统，并行方法可能不起作用；
如果系统需要相互调优各种组件，并行方法可能不起作用；
平行可能不适用于技术风险高(新技术)

演化模型（原型开发）

在这里插入图片描述

当客户有合法的需求，但对细节一无所知时有用
最初的原型可能没什么用:太慢，太大，太不友好，等等。

危险：

顾客可能会“喜欢”用“口香糖”粘在一起的原型（整个软件是随意搭成的）。当被告知这只是一个需要重新构建的原型时，他可能只需要“少量修复”，稍加修改让软件成为一个可运行产品。
开发者可能会试图将原始原型作为最终产品，牺牲质量以换取快速收益

螺旋模型

在这里插入图片描述
优点：

它结合了原型模型的迭代性质和瀑布模型的系统性和可控性特点。
强调风险
强调阶段质量
提供纠错的机会
使用原型作为风险降低机制，进一步使开发人员能够在产品演变的任何阶段应用原型方法。

缺点：

每个阶段都要提出备选方案，进行风险分析，研发周期长，效率低
必须要专业的风险分析人员参与
如果没有发现和管理重大风险，问题无疑将会发生

适用范围：大型项目

统一过程

统一过程：“用例驱动、以体系结构为中心、迭代和增量的”软件过程，与统一建模语言(UML)紧密结合。

在这里插入图片描述

inception:开始；elaboration：细化；construction：构建；transition:过渡；production：生产

场景：
假设你是ABC公司的一名分析师，这是一家在世界各地都有办事处的大型咨询公司。该公司希望建立一种新的知识管理系统，可以根据世界各地的咨询师的教育和他们参与的各种咨询项目，识别和跟踪他们的专业知识。假设这是一个从未在ABC或其他地方尝试过的新想法。美国广播公司有一个国际网络，但每个国家的办事处可能使用不同的硬件和软件。ABC管理部门希望该系统在一年内启动并运行。

你建议ABC公司用什么方法?为什么?

回答
由于许多原因，Throwaway prototyping将是此场景的一个很好的选择。

首先，这是一个全新的想法，因此可能会有一些模糊或混乱的功能系统。
其次，由于世界各地不同地点的多样性，与集成现有硬件和软件有关的技术问题。
第三，交付的时间框架是一年。

五、敏捷开发

什么是敏捷？

对变化的有效（快速和适应性）反应
和所有利益相关者之间的有效沟通
组织一个团队，使其能够控制所执行的工作
快速、增量的软件交付

变更成本图
在这里插入图片描述

传统软件过程变更成本：开发数月之后，项目处于开发期，可能已经在做确认测试，这时需要变更一个主要功能。这一变更需要对软件的体系结构设计进行修改，包括设计和构建三个新构件，修改另外五个构件，设计新的测试等等。所以成本会迅速提高。
敏捷模型为什么前面比传统模型高：敏捷模型前期对团队的要求较高，且完成的工作量要大于传统模型。

敏捷开发的12原则

我们最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。
即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天在一起工作。
围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最富有效果和效率的信息传递方法就是面对面交谈。
可运行软件是进度的首要度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者、用户应该能够长期保持稳定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单–使不必要做的工作最大化的艺术–是必要的。
最好的架构、需求和设计出自于自组织团队。
每隔一定时间，团队会反省如何才能更有效的工作，并相应调整自己的行为。

人为因素：
该过程根据人员和团队的需求进行塑造，而不是反过来。

敏捷团队成员和团队本身必须具备的关键素质:

能力
决策能力
模糊的解决问题的能力
协作
常见的焦点
相互信任和尊重
自组织

极限编程

是敏捷软件开发中使用最广泛的一种方法。

五个因素：沟通，简单，反馈，尊敬，鼓励；

在这里插入图片描述
XP Planning

从创建“用户故事”开始
敏捷团队评估每一个故事并为其分配成本
故事被分组以获得可交付增量
对交付日期的承诺:
所选定的故事将尽快（几周之内）实现
具有高价值的的故事将移到进度表的前面并首先实现
高风险故事将首先实现
所选定的故事将尽快（几周之内）实现
具有高价值的的故事将移到进度表的前面并首先实现
高风险故事将首先实现
项目第一个发行版本交付之后，XP团队计算项目速度。项目速度用于：
帮助估计后续发行版本的发布日期和进度安排
确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，调整软件发行版本的内容或者改变最终交付日期。

XP design
6. 严格遵循KIS(keep it simple，保持简洁)原则；
7. 鼓励使用CRC（类-职责-协作者）卡作为在面向对象环境中考虑软件的有效机制。CRC卡确定和组织与当前软件增量相关的面向对象的类。
8. 在故事设计中遇到困难，推荐立即建立这部分的可执行原型。实现并评估设计原型被称为spike解决方案。其目的是在真正实现开始时就降低风险，对可能存在设计问题的故事确认其最初的估计。
9. 鼓励重构，重构是不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。---------内部程序设计的迭代改进；

XP coding

建议在开始编码之前先开发一系列用于检测本次（软件增量）发布的包括的所有故事的单元测
试。
为什么测试优先开发可以帮助程序员更好地理解系统需求。测试优先开发的潜在困难是什么?
鼓励结对编程（实施解决问题和实时质量保证的机制，使开发者能集中精力在手头的问题）
为什么成对工作的程序员的生产率与单独工作的程序员的生产率大致相同?

XP testing