能力成熟模型与软件工程模型

能力成熟度模型（CMM)将软件能力成熟度自低到高依次划分为5级。目前，达到CMM第3级（已定义级）是许多组织努力的目标，该级的核心是 B 。
A.建立基本的项目管理和实践来跟踪项目费用、进度和功能特性
B.使用标准开发过程（或方法论）构建（或集成）系统
C.管理层寻求更主动地应对系统的开发问题
D.连续地监督和改进标准化的系统开发过程
软件能力成熟度模型（CMM)的第4级（已管理级）的核心是 C 。
A.建立基本的项目管理和实践来跟踪项目费用、进度和功能特性
B.组织具有标准软件过程
C.对软件过程和产品都有定量的理解和控制
D.先进的新思想和新技术促进过程不断改进
能力成熟度集成模型CMMI是CMM模型的最新版本，它有连续式和阶段式两种表示方式。基于连续式表示的CMMI共有6个（0〜5)能力等级，每个能力等级对应到一个一般目标以及一组一般执行方法和特定方法，其中能力等级 C 主要关注过程的组织标准化和部署。
A.1 B.2 C.3 D.4
以下关于过程改进的叙述中，错误的是 B 。
A.过程能力成熟度模型基于这样的理念：改进过程将改进产品，尤其是软件产品
B.软件过程改进框架包括评估、计划、改进和监控4个部分
C.软件过程改进不是一次性的，需要反复进行
D.在评估后要把发现的问题转化为软件过程改进计划
以下关于软件系统文档的叙述中，错误的是 C 。
A.软件系统文档既包括有一定格式要求的规范文档，又包括系统建设过程中的各种来往文件、会议纪要、会计单据等资料形成的不规范文档
B.软件系统文档可以提高软件开发的可见度
C.软件系统文档不能提高软件开发效率
D.软件系统文档便于用户理解软件的功能、性能等各项指标
为了有效地捕获系统需求，应采用 C .
A.瀑布模型 B.V模型 C.原型模型 D.螺旋模型
关于过程改进，以下叙述中不正确的是 D 。
A.软件质量依赖于软件开发过程的质量，其中个人因素占主导作用
B.要使过程改进有效，需要制定过程改进目标
C.要使过程改进有效，需要进行培训
D.CMMI成熟度模型是一种过程改进模型，仅支持阶段性过程改进而不支持连续性过程改进
以下关于喷泉模型的叙述中，不正确的是 D 。
A.喷泉模型是以对象作为驱动的模型，适合于面向对象的开发方法
B.喷泉模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性
C.模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统
D.各开发活动（如分析、设计和编码）之间存在明显的边界试题
若全面采用新技术开发一个大学记账系统，以替换原有的系统，则宜选择采用 A 进行开发。
A.瀑布模型 B.演化模型 C.螺旋模型 D.原型模型
软件开发的增量模型 B 。
A.最适用于需求被清晰定义的情况
B.是一种能够快速构造可运行产品的好方法
C.最适合于大规模团队开发的项目
D.是一种不适用于商业产品的创新模型试题
假设某软件公司与客户签订合同开发一个软件系统，系统的功能有较清晰的定义，且客户对交付时间有严格要求，则该系统的开发最适宜采用 A 。
A.瀑布模型 B.原型模型 C.V模型 D.螺旋模型
某开发小组欲开发一个规模较大、需求较明确的项目。开发小组对项目领域熟悉且该项目与小组开发过的某一项目相似，则适宜采用 A 开发过程模型。
A.瀑布 B.演化 C.螺旋 D.喷泉

系统工程

c是性能需求

可行性分析

某公司因业务需要，准备建立电子商务网站。
建立电子商务网站之前，应对建立电子商务网站的可行性进行分析，可行性分析的四个主要方面是什么？

可行性包括以下四个方面：
1．运行可行性
运行可行性是对方案在组织中的合适程度的度量也是人们对该系统的感觉的度量
2．技术可行性
技术可行性主要涉及三个问题：建议的技术或方案在现有技术水平下是否可以实现企业目前拥有所需的技术吗企业拥有所需的技术专家吗
3．经济可行性
从经济上考虑包括对项目所需费用的预算和对项目效益的估算这是非常重要的如果忽略了就会造成巨大的损失
4．社会可行性
要考虑各种社会因素才能确定项目是否可行由于电子商务应用系统是在社会环境中工作的除了技术和经济等因素之外还有许多社会因素对于项目的开展起着制约的作用与项目有直接关系的人处于变动中的企业的管理制度和工作人员的文化水平等都必须作为社会和人的因素考虑在内

需求工程

乘客应当能够随时打印自己已经办好登机手续的所有航段的登机牌，如果乘客信息没有指定座位偏好，机票预订系统就应当为它分配。( 功能需求 )
机票预定系统在一个月内发生故障的次数低于三次，系统中存储的数据应该避免发生缺失。(可靠性需求 )
机票预定系统在处理一个业务请求平均响应时间为100ms，系统支持的QPS（Query Per Second，每秒处理请求数）在500以上。( 性能需求 )
因乘客身份认证未通过导致机票预定失败时，机票预定系统会给用户显示错误提示并给出反馈，同时通知人工客服来进行进一步核实。( 出错处理需求 )
在任何时刻机票预定系统中的服务器或备份服务器至少有一个是可用的，一个月内系统中的不可用时间不能超过系统运行总时间的3%。( 可用性需求 )
机票预定系统应该提供第三方的登录和支付接口。( 接口需求 )
乘客不能预定同一时间点的多张机票。( 逆向需求)
机票预定系统需要按照国际化（用户界面提供多种语言）进行开发。( 约束 )
机票预定系统应该为以后多家航空公司的入驻提供预留空间。(将来可能提出的需求 )
与用户沟通获取需求的方法

访谈

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。

访谈有两种基本形式，分别是正式的和非正式的访谈。

正式访谈

正式访谈时，系统分析员将提出一些事先准备好的具体问题，

例如，向间客户公司销售的商品种类、雇用的销售人员数目以及信息反馈时间应该多快等。

非正式访谈

在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法，例如，询问用户对目前正在使用的系统有哪些不满意的地方。当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问些用户，以便向他们询问在分析调查表时发现的新问题。

情景分析技术

在访问用户的过程中使用情景分析技术往往非常有效。

所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

例如，假设目标系统是一一个制定减肥计划的软件，当给出某个肥胖症患者的年龄、性别身高、体重、腰围及其他数据时，就出现了一个可能的情景描述。系统分析员根据自己对目标系统应具备的功能的理解，给出适用于该患者的菜单。客户公司的饮食专家可能指出，某些菜单对于有特殊饮食需求的患者(例如，糖尿病人、素食者)是不合适的。这就使分析员认识到，目标系统在制定菜单之前还应该先询问患者的特殊饮食需求。系统分析员利月情最分析技术，往往能够获知用户的具体需求。

情景分析技术的用处主要体现在下述两个方面：

①它能在某种程度上演示目标系统的行为，从而便于用户理解.而且还可能进一步揭示出一些分析员目前还不知道的需求。

②由于情景分析较易为用户所理解,使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的唯一来源是用户.因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。

面向数据流自顶向下求精

软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输人数据转变成需要的输出信息。数据决定了需要的处理和算法、看来数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。

结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标就是把数据流和数据存储定义到元素级。

为了达到这个目标，通常从数据流图的输出端着手分析,这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。输出数据是由哪此元索组成的呢?通过调查访问不难搞清这个问题。

那么，每个输出数据元素又是从哪里来的呢?既然它们是系统的输出，显然它们或者是从外面输入到系统中来的,或者是通过计算由系统中产生出来的。沿数据流图从输出端往输入端回溯应该能够确定每个数据元素的来源，与此同时也就初步定义了有关的算法。

但是,可行性研究阶段产生的是高层数据流图.许多具体的细节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题:

为了得到某个数据元素需要用到数据流图中目前还没有的数据元素,或者得出这个数据元素需要用的算法尚不完全清楚。

为了解决这些问题，往往需要向用户和其他有关人员请教.他们的回答使分析员对目标系统的认识更深人更具体了，系统中更多的数据元素被划分出来了,更多的算法被搞清楚了。通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO图中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。

必须请用户对上述分析过程中得出的结果仔细地复查,数据流图是帮助复查的极好工具。从输入端开始，分析员借助数据流图、数据字典和IP0图向用户解释输人数据是怎样一步一步地转变成输出数据的。

这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统的认识。

这些认识正确吗?有没有遗漏?用户应该注意倾听分析员的报告,并及时纠正和补充分析员的认识。

复查过程验证了已知的元素,补充了未知的元素,填补了文档中的空白。反复进行上述分析过程,分析员越来越深人地定义了系统中的数据和系统应该完成的功能。为了追踪更详细的数据流，分析员应该把数据流图扩展到更低的层次。通过功能分解可以完成数据流图的细化。

对数据流图细化之后得到一组新的数据流图,不同的系统元素之间的关系变得更清楚了。对这组新数据流图的分析追踪可能产生新的问题，这些问题的答案可能又在数据字典中增加一些新条目,并且可能导致新的或精化的算法描述。随着分析过程的进展，经过提问和解答的反复循环,分析员越来越深人具体地定义了目标系统最终得到对系统数据和功能要求的满意
了解。

下图粗略地概括了上述分析过程。

简易的应用规格说明技术

使用传统的访谈或面向数据流自顶向下求精方法定义需求时,用户处于被动地位而且往往有意无意地与开发者区分"彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想(经常发生误解，还可能遗漏重要的信息)。

为了解决上述问题，人们研究出一.种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。今天,简易的应用规格说明技术已经成为信息系统领域使用的主流技术。

使用简易的应用规格说明技术分析需求的典型过程如下:

首先进行初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。然后开发者和用户分别写出“产品需求”。选定会议的时间和地点,并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并在开会前预先把写好的产品需求分发给每位与会者。

要求每位与会者在开会的前几天认真审查产品需求，并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。此外,还要求每位与会者列出操作这些对象或与这些对象交互的服务(即处理或功能)。最后还应该列出约束条件(例如成本、规模、完成日期)和性能标准(例如速度、容量)。并不期望每位与会者列出的内容都是毫无遗漏的，但是，希望能准确地表达出每个人对目标系统的认识。

会议开始后,讨论的第一个问题是,是否需要这个新产品，一旦大家都同意确实需要这个新产品,每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论。可以
把这些列表抄写在大纸上钉在墙上，或者写在白板上挂在墙上。理想的情况是,表中每一项都能单独移动,这样就能方便地删除或增添表项，或组合不同的列表。在这个阶段，严格禁止批评与争论。

在展示了每个人针对某个议题的列表之后，大家共同创建张组合列表。在组合列表中消去了冗余项，加人了在展示过程中产生的新想法,但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后，由协调人主持讨论这些列表。组合列表将被缩短、加长或重新措辞,以便更准确地描述将被开发的产品。讨论的目标是，针对每个议题(对象、服务、约束和性能)都创建出一张意见致的列表。一旦得出了意见一致的列表 ,就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。然后,每个小组都向全体与会者展示他们制定的小型规格说明，供大家讨论。通过讨论可能会增加或删除一些内容，也可能进一步做些精化工作。在完成了小型规格说明之后,每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见致的确认标准。最后,由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。

简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是，这种面向团队的需求收集方法确实有许多突出优点:开发者与用户不分彼此,齐心协力，密切合作;即时讨论并求精;有能导出规格说明的具体步骤。

快速建立软件原型

快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能(例如屏幕显示或打印报表)，省略日标系统的“隐含”功能(例如修改文件)。

快速原型应该具备的第–个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型,以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此，原型的某此缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解,就不必管它们。

快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版,以更好地满足用户需求。在实际开发软件产品时，原型的“修改一试用一反馈"过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。

为了快速地构建和修改原型,通常使用下述3种方法和工具。

(1)第四代技术

第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，因此,它们是较理想的快速原型工具。

(2)可重用的软件构件

另外一种快速构建原型的方法，是使用-组已有的软件构件(也称为组件)来装配(而不是从头构造)原型。软件构件可以是数据结构(或数据库)，或软件体系结构构件(即程序),或过程构件(即模块)。必须把软件构件设计成能在不知其内部工作细节的条件下重用。应该注意，现有的软件可以被用作“新的或改进的”产品的原型。

(3)形式化规格说明和原型环境

在过去的20多年中，人们已经研究出许多形式化规格说明语言和工具,用于替代自然语言规格说明技术。今天,形式化语言的倡导者正在开发交互式环境，以便可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码,用户能够使用可执行的原型代码去进一步精化形式化的规格说明。

【软件工程导论】习题集相关推荐

软件工程导论团队项目
软件工程导论团队项目(速课小龙) 一．团队介绍 1.团队成员邓旭 2016012068 (组长) 陈逸璇 2016012056 周紫伊 2016012043 谢月鹏 2016012066 洪泽芳 ...
《软件工程导论》课后习题答案
<软件工程导论>课后习题答案第一章软件工程概论 1．什么是软件危机? 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题.这些问题表现在以下几个方面: (1)用户对开发出 ...
微信小程序云开发体会——总结软件工程导论大作业
微信小程序云开发体会--总结软件工程导论大作业前言第一次接触具体难题好用的技术开发完之后的体会无法不热爱更多前言可能大家完成这次作业都会选择比较擅长的领域--网页前后端.这的确是比较稳 ...
《软件工程导论》考研复试整理
一.名词解释 DFD 数据流图Data Flow Diagram PDL 过程设计语言 Process Design Language PAD 问题分析图 Problem Analysis Diagr ...
软件工程导论复试——一、软件工程学概述
软件工程导论复试本文用书 <软件工程导论>第六版张海藩.牟永敏清华大学出版社一.软件工程学概述软件危机:计算机软件开发和维护时遇到的一系列严重问题典型表现: (1) 对软件开发成 ...
首经贸电子信息复试软件工程导论
一.名词解释 DFD 数据流图Data Flow Diagram PDL 过程设计语言 Process Design Language PAD 问题分析图 Problem Analysis Diagr ...
软件工程导论第三章复习总结附思维导图
软件工程导论第三章复习总结附思维导图概述准确回答"系统必须做什么" 必须理解并描述问题的信息域,根据这条准则应该建立数据模型必须定义软件应该完成的功能,这条准则要求建立功能模 ...
软件工程导论期末考点总结
文章目录一.软件工程学概述 1.1.软件危机 1.2.软件工程 1.2.1.软件工程的介绍 1.2.3.软件工程方法学 1.3.软件生命周期 1.4.软件过程 1.4.1.瀑布模型 1.4.2.快速 ...
软件工程导论（张海藩第六版）期末考试、考研复试重点
这里是一个重点的简介,只是概念性的内容,软件工程导论中还有一些画图的题目,建议先掌握概念性的内容,之后的画图就比较容易了. 文末附有完整的思维导图链接,思维导图里面是完整的知识点,学完一遍之后直接拿着 ...
学习软件工程导论的心得体会
软件工程导论是一门软件工程专业的必修课,在长达一学期的学习中,我认识到为解决"软件危机"引发的一系列困境,使得"软件工程"这一概念面世,其中,软件工程中由&qu ...

【软件工程导论】习题集