湘潭大学软件工程头歌多选题-期末考试复习资料

说明

从后面往前面来复习，章节对于考试不重要，重要的是有一个印象

主要不是内容，主要是挑一些可能会选错的来记录，一眼的就不再进行记录

其中加入了笔者的一些思考，不一定准确和严谨，仅供参考

题目

以下哪些属于软件质量保证活动。
A、
测试程序代码
B、
审查开发活动
C、
审核软件制品
D、
组织人员培训

软件配置项及其之间的关系可以用树来加以表示。

注意这句话是不选的，看上去可能是正确的，其实是错误的

多选题改成单选题的话应该是考察不选的选项，接下来整理不选的选项

多选题不选的选项

软件基线不可对它进行修改（注意，这个说法是错误的）

（还是把正确的知识写在这儿吧，别到时候记混了）
软件项目跟踪不需要关注软件规模

软件项目计划不包括软件质量计划（大概是他也控制不了之类的）

可以用甘特图和网络图来表示软件项目计划

度量测量估算考的太简单

有文档就不需要再看代码去理解软件的设计信息了

完善性维护会改变软件系统的功能（因为完善了相关的功能）

软件逻辑老化给出的选项全选，大概就是啥都不行了

导致软件逻辑老化的原因是各种原因，基本能想到所有原因

软件维护和软件演化的区别需要注意一下，软件演化的粒度大，主动应对变化（选这两个选项）

笔记和碎碎念

记录着记录着发现和标题不符合了
换个标题

app的运行环境是全选，安卓，手机，服务端软件，移动互联网，都算运行环境

测试用例不是一组测试数据，这个用做算法题来类比就很好理解

运行程序代码：调试和测试（代码走查不知道是干啥，反正不需要运行程序代码）

编写的输出包括源代码，可执行程序，程序单元测试报告，不包括用户使用手册

群智其实就是字面意思

只有XXX 才叫做XXX 一般就是错的

所有报告的软件缺陷最终都应处于关闭状态，其他的软件缺陷问题都谨慎一些即可

“对程序员的要求不高” 政治不正确哈哈

编写类的主要工作，和类有关的全选上

用户界面代码的主要工作，和界面有关的全选上

数据设计的主要工作，把和数据库有关的全部选上

c语言编译器，包括cl,clang，比较明显，都是以c开头，javac很明显不是c语言编译器

题目给的都是集成开发环境，pycharm不是很熟悉，其他都比较常见

程序员不需要编写异常定义

c语言不是面向对象程序设计语言

程序设计语言的选择需要考虑很多元素，全选

很多相关人员都要参与软件详细设计评审，全选，注意用户也要参加

关联表示两个类之间存在稳定的关系（关联，结合现实中的关系比较好理解，比如说QQ号关联在一起，关系比较稳定）

类设计的成果不包括用例实现图，并且成果选项都包括“类”这个字眼

不同阶段的图是不一样的，不然阶段的划分毫无意义

两个图一般是不一样的

单例模式提供一个全局的实例对象变量，这句话是错误的

UML 活动图不可以用来描述结构特征（记少的选项更适合期末考试备考）
UML 图中下划线表示对象
终止节点不应有外出的连线（很好理解，都是终点了，为啥还能继续往前走）

软件详细设计不包括界面设计（个人感觉可能属于美术团队的任务）

精化和细化的对象是全选

精化不需要实现最终界面（大概是不断迭代优化吧）

个性化不是原则，但是可以提供一个选项给用户来操作

跳转关系可以用顺序图和类图来表示（记住即可）

该截图有静态元素和输入元素（静态元素容易理解，单选钮表示的就是输入元素，静态文本图标表示静态元素，所以静态元素几乎是必选）

软件体系结构评审不需要考虑创新性，创新性主要是指软件本身的创意，不是技术创新（个人理解）

构件和模块都属于设计元素

体系结构设计阶段代码片段不可重用。可能是因为太细小了（？）

不可以对其他公司制品进行破解，应该是违法的

软件体系设计阶段不会产出详细设计文档，类似于提纲阶段不会写详细的细节，但是会形成软件部署模型

部署中的边没有继承关系，感觉是比较平等的关系，但是有依赖关系，但是依赖关系也可以是比较平等的关系，比如说恋人

构建接口包括供给接口和需求接口，有需求就有供给

软件体系结构不包括数据流（体系结构感觉是点层次的东西）

包图和部署图用来描述软件体系结构（前面有写跳转关系是什么图表示）
这里回顾下：跳转关系用顺序图和类图来表示

软件体系结构不包括适配器（其他的都没有接触过，属于专业名词，适配器可以强记成电源适配器，属于硬件，和软件体系结构无关，强加关系记忆哈哈）

软件设计模型不包括用例图（）

B、
StarUML
C、
IBM Rational Rose
这两个既是需求分析工具也是设计工具。UML和IBM，简记

设计工具只能提供设计相关的帮助

面向对象软件设计不需要尽量开放

面向对象的软件设计并没有技术更加简单，技术可能没有发生什么变化

变换型数据流图里面是各种流，没有事务中心

设计约束：带有约束制约字眼的，不需要考虑其他的

不需要尽量使用新技术，很多东西其实不是越新越好，常规的成熟的技术可能可以达到意想不到的极佳效果

需求阶段不需要设计工程师
（程序员就类似于设计工程师）

软件需求模型的UML图可能包括，用例图，顺序图，通信图，类图，状态图（全部傻傻分不清楚）

反正是原题的话，是不是记住答案就好了……
感觉整理完一遍之后还需要再多看看，一遍根本记不住

软件需求模型的分析类不包括虚拟类（提出需求的一般都是比较现实的？）

优先级主要看重要性和紧急程度，和现实生活中一样

软件需求的行为模型：状态图，顺序图，通信图（各种图……）

详细刻画软件需求：用例和行为

以上是第十七章到第七章的内容

图的一些汇总

可以用甘特图和网络图来表示软件项目计划
类设计的成果不包括用例实现图，并且成果选项都包括“类”这个字眼
不同阶段的图是不一样的，不然阶段的划分毫无意义
两个图一般是不一样的
UML 活动图不可以用来描述结构特征（记少的选项更适合期末考试备考）
UML 图中下划线表示对象
跳转关系可以用顺序图和类图来表示（记住即可）
包图和部署图用来描述软件体系结构（前面有写跳转关系是什么图表示）
软件设计模型不包括用例图（）
变换型数据流图里面是各种流，没有事务中心
软件需求模型的UML图可能包括，用例图，顺序图，通信图，类图，状态图（全部傻傻分不清楚）
软件需求的行为模型：状态图，顺序图，通信图（各种图……）
UML对软件需求分析进行建模和分析：用例图，类图，状态图

以下是第六章到第一章的内容

外部执行者和用例之间的关系是触发和交互，类似于人和机器的关系

初步软件需求可以用自然语言，UML用例图，软件原型表示，就是不能是UML类图相关

软件原型并不简单，自然语言应该更加简单吧，直接口头或者书面描述即可

非功能需求：开发约束和质量

分析不是获取阶段需要做的事情，是后面阶段的任务

软件需求确实和测试人员没啥关系

UML是一种建模语言（软件需求分析和软件工程确实有一些重叠的部分，之前软件需求分析课程学习的时候也有接触到一些相关的概念）

UML模型不可以在计算机上执行，只有可执行程序才可以在计算机上执行吧

UML对软件需求分析进行建模和分析：用例图，类图，状态图

面向对象数据流：抽象建模，自顶向下，逐步求精
（十六字诀）

数据里分析只能分析功能需求，性能属于非功能需求，不可以分析非功能性需求

外部实体和数据流画错了（反正是考原题）

需求工程的工具不可以用来设计，就像设计的工具不可以用来干别的

注意语言描述，基于需求的软件设计，落脚点是设计，设计不属于需求工程的活动

软件项目经理不是软件利益相关方，我非常难以理解……

只有核心人员才有资格提问是错的，在开放的互联网环境，都可以进行提问

只要就基本是错的，否则质量难以得到保证

代码会经过审核，所以其实质量是可以保证的

Scrum开发方法不是以质量为优先，吃惊

测试驱动开发：字面意思，先编写测试代码，再编写功能代码

所以其实敏捷开发方法就是快速，质量其实比不过其他方法

增量和迭代：快速交付和重型软件

迭代开发：原型模型和螺旋模型，螺旋模型比较好理解，螺旋式上升和迭代升级比较接近，原型模型强记

有效应对需求变化：迭代和原型

综上：原型既可以迭代，又可以有效应对需求变化

工程不需要使用最新的技术，很多事都不需要使用最新的技术，只有在科技前沿才需要使用最新技术（？）比如XX最新产品，科技比拼

软件工程的基本要素是过程和辅助工具，语言太细小了，不属于基本要素

软件工程师并不是越多越好

文档是起到一个记录的作用，就好像我们学习或者刷算法题用blog进行记录，这并不会减少我们需要学习的总量，但是也许可以帮助我们提高学习效率，方便以后回顾和复习

B、
Sonarqube
C、
CheckStyle
可以完成程序代码的静态分析工作，另外两个选项其实都有见过，熟悉的不选哈哈

人工审查应该就是干瞪眼，不需要运行程序

多编写程序居然不是提高程序质量的办法（）

注释：提升代码内部质量，方便理解

内部质量就是指可理解性，可维护，可重用，外部质量指的是展现出来的，确实比较形象

LearnerHub英文已经说明这是一个学习平台了

任务不一定是软件缺陷

开源的群体协同开发模式在开源领域以及企业开发实践中广泛应用。以下说法哪些是错误的？（这题选ABC）有点难以总结，把整个题搬过来了
A、
要进行基于PR模式的开发，必须要首先Fork项目
B、
根项目管理者对Fork产生的副本项目具有管理权限
C、
提交PR的源分支和目标分支可以相同
D、
PR提交可以在同一个项目内部进行

需求变化是迭代和原型，迭代是原型和螺旋

人类对XX的认知已经比较全面，感觉基本是错误说法