天津理工大学软件工程A 期末复习（完整版）

本文主要是介绍天津理工大学软件工程A 期末复习（完整版），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

第一章 软件工程概论

• 软件工程四个阶段

  • 程序设计阶段
  • 软件=程序+文档阶段
  • 软件工程阶段
  • 第4代技术阶段

• 软件工程是什么

  • 软件工程是软件开发、运行、维护和引退的系统方法。
  • 软件工程是指导计算机软件开发和维护的工程学科。
  • 软件工程三要素：方法、工具、环境

• 瀑布模型

  

  优点

  • 前一阶段完成后，您只需要去关注后续阶段

  缺点

  • 各个阶段之间极少有反馈
    只有在项目生命周期的后期才能看到结果

  特点

  • 文档驱动
    线性 阶段固定

  适用于

  • 用户需求明确、完整、无重大变化的软件项目开发

• 快速原型模型

  

  优点

  减少设计中的错误和开发中的风险，也减少了对用户培训的时间
  缩短了开发周期，加快了工程进度 降低成本
  缺点

  原型被建造仅仅是用户用来定义需求，之后便部分或全部抛弃，
  最终的软件是要充分考虑了质量和可维护性等方面之后才被开发
  特点

  可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率
  适用于

  用户不能给出完整、准确的需求说明
  不能预先确切定义需求

• 增量模型

  

  优点

  • 较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品
    渐进地开发逐步完善的软件版本的模型

  缺点

  • 多个构件并行开发，具有无法集成的风险

  特点

  • 软件体系结构必须是开放的

  适用于

  • 已有产品升级或新版本开发
    完成期限严格要求的产品

• 喷泉模型

  优点

  • 各个阶段没有明显的界限，开发人员可以同步进行开发
    提高软件项目开发效率，节省开发时间

  缺点

  • 要求严格管理文档 审核的难度加大
    开发过程中需要大量的开发人员，不利于项目的管理

  特点

  • 以用户需求为动力，以对象为驱动的模型

  适用于

  • 主要用于描述面向对象的软件开发过程

• 螺旋模型

  简化的螺旋模型

  

  完整的数据模型

  

  优点

  • 有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标

  缺点

  • 需要具有相当丰富的风险评估经验和专门知识
    随着迭代次数的增加，工作量加大，软件开发成本增加

  特点

  • 客户始终参与每个阶段的开发
    核心思想 风险控制

  适用于

  • 大规模软件项目

• rup模型

  优点

  • 提高了团队生产力
    它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性

  缺点

  • 仅仅包含了开发过程
    并没有涵盖软件过程的全部内容

  特点

  • 是一个迭代过程
    用例驱动
    以架构设计为中心

  适用于

  • 需求易变动的高风险项目

• 软件生存期

  软件定义、软件开发、软件维护

  • 软件定义时期包括问题定义、可行性研究以及需求分析三个阶段
    • (1) 问题定义：这是软件生存期的第一个阶段，主要任务是弄清用户要计算机解决的问题是什么。
      • 明确问题的背景、开发系统的现状、开发的理由和条件
      • 开发系统的问题要求、总体要求、问题的性质、类型、范围、要实现的目标
      • 功能规模、实现目标的方案、开发的条件、环境要求等等
      • 然后写出问题定义报告（或称系统定义报告），以供可行性分析阶段使用。
    • (2) 可行性研究：任务是为前一阶段提出的问题寻求一种至数种在技术上可行、且在经济上有较高效益的解决方案。
  • 软件开发时期包括总体设计、详细设计、编码和单元测试、综合测试、前两个阶段是系统设计、后两个阶段是系统实现
  • 软件维护时期主要是对于已经交付的软件做一些必要的修改，时期满足客户的需求
  • 需求分析阶段需要注意的是软件必须做什么，注意的主要是功能，设计阶段确定的是怎么做，而详细设计阶段确定的就是数据结构和算法

• 软件危机

  软件开发和维护过程中所中遇到的这一系列严重问题为软件危机.

• 它的表现是什么

  • 对软件开发成本和进度的估计常常很不准确
  • 用户对“已完成的”软件系统不满意的现象经常发生
  • 软件产品的质量往往靠不住
  • 软件常常是不可维护的
  • 软件通常没有适当的文档资料
  • 软件成本在计算机系统总成本中所占的比例逐年上升
  • 软件成本在计算机系统总成本中所占的比例逐年上升

第二章 可行性研究

• 可行性研究的任务：确定问题是否值得去解决【最根本任务：为以后的行动方针提出建议】
  • 可行性研究的任务是用最小的代价、在尽可能短的时间内确定问题是否能够解决。
• 可行性研究的的研究方面：
  • 技术可行性，使用现有的技术能实现这个系统吗?
  • 经济可行性，这个系统的经济效益能超过它的开发成本吗?
  • 操作可行性，系统的操作方式在这个用户组织内行得通吗?
  • 社会和法律可行性，软件开发是否会侵犯他人、集体或国家的利益，是否违反国家的法律并可能由此而承担法律责任。

第三章 软件需求

• 绘画数据流图【大题】

• 数据流图的四要素

  • 正方形表示数据的终点和源点
  • 圆角矩形代表变换的数据的处理
  • 开口矩形代表数据存储
  • 箭头代表数据流也就是数据的流动方向

• 数据流图的概念

  • 数据流图秒回数据在软件系统中，从输入移动到输出过程所经受的变换
  • 数据流图是系统逻辑功能的图形表述，没有任何具体的物理部件

• 数据字典

  • 数据字典书关于数据的信息的集合，也就是对于数据流图中包含元素的定义的集合
  • 通常数据字典包括：名字、定义、使用特点、控制信息、分组信息

第四章 总体设计

• 设计五大准则

  • 模块化与模块独立
    • 把大型软件按照规定的原则划分为一个个较小的、相对独立但又相关的模块的设计方法，叫做模块化设计（modular design）。
    • （1）模块化程度较高的软件容易开发
    • （2）模块化程度较高的软件也比较容易测试和维护
    • 模块的独立性的度量标准：耦合和内聚。
  • 抽象
    • 在软件需求分析阶段，用“问题所处环境的为大家所熟悉的术语”来描述软件的解决方法。
    • 在从概要设计到详细设计的过程中，抽象化的层次逐次降低。当产生源程序时到达最低抽象层次
  • 逐步求精
    • 自上而下
  • 信息隐藏和局部化
    • 信息隐蔽是指，每个模块的实现细节对于其它模块来说是隐蔽的。也就是说，模块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用
  • 局部化
    • 局部化就是把一些关系密切的软件元素物理放的彼此靠近、局部化和信息隐藏密切相关、局部化有助于信息隐藏

• 耦合和内聚

  • 耦合：是模块之间的互相连接的紧密程度的度量
  • 内聚：是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量
  • 模块独立性比较强的模块应是高内聚、低耦合的模块

• 七种耦合七种内聚的优先顺序重要顺序

  • 非直接耦合：如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强

  • 数据耦合 (Data Coupling)：如果一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的，则称这种耦合为数据耦合。

  • 标记耦合 (Stamp Coupling)：如果一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。

  • 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。

  • 外部耦合（External Coupling）：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

  • 公共耦合（Common Coupling）：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

  • 内容耦合 (Content Coupling)：如果发生下列情形，两个模块之间就发生了内容耦合

    • (1) 一个模块直接访问另一个模块的内部数据;
    • (2) 一个模块不通过正常入口转到另一模块内部;
    • (3) 两个模块有一部分程序代码重迭(只可能出现在汇编语言中);
    • (4) 一个模块有多个入口

  • 信息内聚 (Informational Cohesion)
    这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。这个模块将根据不同的要求，确定该执行哪一个功能。由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块。

  • 通信内聚 (Communication Cohesion)

    如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。通常，通信内聚模块是通过数据流图来定义的。

  • 过程内聚（Procedural Cohesion） 使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。例如，把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。

  • 时间内聚（Temporal Cohesion）时间内聚又称为经典内聚。这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。例如初始化模块和终止模块。

  • 逻辑内聚这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。

  • 巧合内聚 巧合内聚又称为偶然内聚。当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块。

• 软件结构图【大题】

• 扇入扇出：

  • 深度表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
  • 宽度是软件结构内同一个层次上的模块总数的最大值。一般宽度越大越复杂。
  • 扇出是指一个模块直接控制(调用)的模块数目，扇出过大则宽增加；扇出过小(例如总是1)深度增加。通常取3或4扇出太大时应该适当增加中间层次的控制模块。
  • 扇入表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多
  • 尽可能减少高扇出结构，随着深度增大扇入。如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块。应当适当增加中间层次的控制模块。

• 模块作用域控制域

  • 模块的作用域：受该模块内一个判定影响的所有模块的集合。
    模块的控制域：是这个模块本身以及所有直接或间接从属于它的其它模块的集合

• 启发式规则：

  • （1）改进软件结构提高模块独立性
  • （2）模块规模应该适中 (通常不超过60行语句)
  • （3）深度、宽度、扇出和扇入应适中
  • （4）模块的作用域应该在控制域之内
  • （5）力争降低模块接口的复杂程度
  • （6）设计单入口、单出口的模块
  • （7）模块功能应该可以预测
    如果一个模块可以当做一个黑盒子，也就是说，只要输入的数据相同就产生同样的输出，这个模块的功能就是可以预测的。

第五章 面向对象

• 面向对象的需求分析：

  • 任务：
    • 确定对系统的综合要求
    • 分析系统的数据要求
    • 导出系统的逻辑模型
    • 修正系统开发计划和工程进度表
  • 设计准则：
    • 模块化
    • 抽象
    • 信息隐藏
    • 强内聚
    • 可重用
  • 启发式规则
    • 设计结果应该清晰移动
    • 一般特殊结构深度适当
    • 设计简单的类
    • 使用简单的协议
    • 使用简单的服务
    • 把设计变动减小到最小

• 什么是UML

  • “统一建模语言”，是一种面向对象的建模语言

  • 20世纪70年代中期产生了面向对象的软件开发方法，面向对象的分析（OOA）和面向对象的设计（OOD）方法已逐渐取代了传统的方法，成为我国当前计算机软件工程学中的主流方法。

  • 特点

    • UML是Booch方法、OMT方法、OOSE方法以及其他面向对象方法的优秀思想、成果和符号的统一体。
      UML应该在发展中不断进化、完善。
      UML是一种可视化的建模语言，而不是一门程序设计语言。
      UML独立于软件开发过程，即用户可以对任何适合的过程使用UML进行建模。
      UML是一种面向对象技术的标准建模语言，它支持软件开发中从需求分析到测试的全过程。

  • 组成：

    1. 元素是模型的抽象, 也称事物 ；
    2. 元素之间的连接纽带是关系；
    3. 图将元素的集合进行分组。

  • 4种元素：

    • 结构元素：类、接口、协作、用例、活动类（也称主动类）、组件（也称构件）和节点。

    • 行为元素：交互作用和状态机
      交互作用：一组对象之间为完成某一任务（如实现某个操作）而进行的一系列消息交换的行为. 在UML图中，交互的消息通常画成带箭头的直线。
      状态机：对象为响应事件而经历的一系列状态以及对事件作出响应的行为。包括状态、跃迁 、事件等。

    • 分组元素：在UML中的作用是组织其他元素。

    • 注释元素：是UML模型的解释部分。这些注释元素用来描述、说明和标注模型中的任何元素。只有一种注释元素，称为注解 。

• 用例图【大题】：

  从用户角度描述系统功能，并指出各功能的操作者

  • 参与者与用例之间
    关联关系：描述参与者与使用用例之间的关系。在UML中，关系用实线表示，实线可以有箭头，也可以没有箭头。

  • 用例与用例之间

    • 包含关系 (include)

      包含关系中一个用例总是使用另一个用例的功能
      如果两个以上用例有大量一致的功能，则可以将这个功能分解到另一个用例中。
      一个用例的功能太多时，可以用包含关系建模两个小用例。
      包含关系中基用例本身是不完整的。

    • 扩展关系 (extend)

      扩展关系允许一个用例（可选）扩展另一个用例的功能。
      当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称作基用例，这种关系被称为扩展关系。
      基用例可以单独存在，但在一定的条件下，他的行为可以被另一个用例的行为延伸。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。

    • 泛化关系 (generalization)：

      泛化关系其实是子类与父类的关系。象类之间的泛化关系一样，用例和参与者也可以继承另一个用例和参与者。

  • 参与者与参与者之间
    泛化关系 (generalization)

  用例命名：动词 + 宾语

  • 事件流：

    事件流是通过文字描述一个用例的行为，说明用例的逻辑流程。发起用例的参与者是谁，用例的前置条件是什么，主事件流，其他事件流和完成后的后置条件是什么，从用例中获益的参与者是谁。
    事件流包括：简要说明、前置条件、主事件流、其他事件流和后置条件

• 时序图【大题】：

  • 时序图只显示对象，不显示类。即时序图是针对某个特定情况、特定对象进行的描述。
  • 活动者、对象、消息、生命线和控制焦点

• 协作图【大题】：

  • 时序图主要描述对象间消息发送的时间顺序，而协作图侧重于描述交互对象之间链接关系（或称交互关系），而不专门突出这些消息发送的时间顺序。
  • 协作图不像时序图一样具备时间维,为了表示消息的时间顺序,通常要为消息加一个数字前缀.

• 类图【大题】：

  • 类图用于定义系统中的类。包括描述类之间的关系（如：关联、依赖、泛化、聚合等）以及类的内部结构(即类的属性和操作)。类图描述的是系统中类的静态结构,在系统的整个生命周期都是有效的。

  • 依赖关系:

    指一个元素的变化将影响另一个元素或向接收者提供信息。
    例如，对于两个对象X、Y，如果对象X发生变化，可能会引起对另一个对象Y的变化，则称Y依赖于X。通常，X在Y的方法的参数中。

  • 泛化关系:

    UML中的泛化关系（也称类属关系）定义了一般元素和特殊元素之间的分类关系，与C++及Java中的继承关系有些类似。
    泛化是一般事物（称为超类或父类）和该事物的较为特殊的种类（称为子类）之间的关系，子类继承父类的属性和操作，除此之外通常子类还添加新的属性和操作，或者修改了父类的某些操作。

  • 关联关系

    • 关联关系表示两个类之间存在某种语义上的联系。
      它描述了一个对象与另一个对象连接的一种结构化关系。
      从一个类可以导航到另一个类。
      关联关系是所有关系中最通用的，语义最弱

  • 聚合关系

    • 聚合关系（Aggregation Relationship）是一种特殊形式的关联。聚合表示类之间的关系是整体与部分的关系。
      　一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，这是聚合的一个例子。在需求分析中，“包含”、“组成”、“分为……部分”等经常设计成聚合关系。

  • 组合关系：

    • 组合关系（Composition Relationship）是聚合的变种，它加入了一些重要的语义.
      整体拥有各部分，部分与整体共存，如整体不存在了，部分也会随之消失，这称为组合(Composition)。
      例如，我们打开一个窗口,它就由标题栏、滑动条和面板所组成。一旦消亡则各部分同时消失。

  • 类的三种类型：

    • 实体类(entity)

    • 边界类(boundary)

    • 控制类(control)

• 能设计类的属性和方法（可见性，数据类型，返回值要写全）

  • 类的设计:

    • UML中类属性的语法为：
      [可见性] 属性名[：类型][=初值]
      可见性的表示形式：

      • public
      • private
      • #protected

    • UML中类操作的语法为：
      [可见性] 操作名 [（参数列表）] [：返回类型]

      • 举例：
        • display() : Area
        • #create()
        • getLocation (Point : currentPoint)

第六章 详细设计

• PAD图

• 流程图（计算环形复杂度，写出测试路径，测试用例）

  • Method 1：V(G)=E-N+2
    其中，E是流图中边的条数，N是结点数。
  • Method 2：V(G)=P+1
    其中，P是流图中判定结点的数目。
  • 注： 环形复杂度定量度量程序的逻辑复杂度。
    实践表明，模块规模以V(G)≤10为宜

• NS图

第七章 测试

• （1）测试是为了发现程序中的错误而执行程序的过程；
  （2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
  （3）成功的测试是发现了至今为止尚未发现的错误的测试

• 黑盒测试技术（边界值分析】等价类划分】错误推测法基本思想）

  • 黑盒测试时完全不考虑程序内部的结构和处理过程，只按照规格说明书的规定来检查程序是否符合它的功能要求。黑盒测试是在程序接口进行的测试，又称为功能测试。
  • 程序的功能是否正确或完善；
    数据的输入能否正确接收，输出是否正确；
    是否能保证外部信息（如数据文件）的完整性等。
    用黑盒法设计测试用例时，必须用所有可能的输入数据来检查程序是否都能产生正确的输出。
  • 等价类划分：

    • 思路：将程序输入域划分成若干个部分，即子集，然后从每个子集中选取具有代表性的数据作为测试用例。

    • 等价类的划分在很大程度上依靠的是测试人员的经验，下面给出几条基本原则：
      （1）输入条件的取值范围 （2）输入数据的个数限定
      （3）相同处理的一组输入 （4）无效的等价类
      （5）空值检查

    • 例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

    • （1）为每个等价类编号。
      （2）设计新的测试用例，使它能包含尽可能多的尚未被覆盖的“有效”等价类。重复这一过程，直到所有的有效等价类都被覆盖。
      （3）设计新的测试用例，使它包含一个尚未被覆盖的“无效”等价类。重复这一过程，直到所有的无效等价类都被覆盖。

    • 边界值分析

      • 选取恰好等于、小于和大于边界的值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。

    • 错误推测法

      • 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例

• 白盒测试技术（写测试用例、逻辑覆盖法、基本路径测试等测试方法）

  • 将程序看作是一个透明的盒子，也就是说测试人员完全了解程序的内部结构和处理过程。所以测试时按照程序内部的逻辑测试程序、检验程序中的每条通路是否都能按预定的要求正确工作。白盒测试又称为结构测试

  • 利用白盒测试设计测试用例时，应包括以下三类测试：
    （1）语句测试：要求程序中的每个语句至少测试一次
    （2）分支测试：要求程序中的每个分支至少测试一次
    （3）路径测试：要求程序中的每条路径至少测试一次

  • 逻辑覆盖法

    • 语句覆盖:设计足够的调试用例，使得程序中的每个语句至少执行一次。
    • 判定覆盖
    • 条件覆盖
    • 判定／条件覆盖
    • 条件组合覆盖

  • 基本路径测试法

第八章 维护

• 维护是什么：软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程

• 四种维护：

  • 改正性维护：把诊断和改正错误的过程。
  • 适应性维护：也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
  • 完善性维护：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。
  • 预防性维护：当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。

• 五个步骤：

  • Step 1. 建立维护组织

  • Step 2. 填写维护申请报告: 是由软件组织外部提交的文档，它是计划维护活动的基础。软件组织内部应依此制定相应的软件修改报告，这个报告包括以下内容：
    （1）为满足某个维护申请要求所需的工作量；
    （2）所需修改变动的性质；
    （3）申请修改的优先级；
    （4）与修改有关的事后数据。
    软件修改报告应提交修改负责人进行审核批准，以便进行下一步工作。

  • Step 3.维护的工作流程

  • Step 4. 软件维护记录：维护记录中的内容有下述的项目表：
    （1）程序名称；
    （2）源程序语句条数； （3）机器代码指令条数；
    （4）使用的程序设计语言；（5）程序的安装日期；
    （6）程序安装后的运行次数；
    （7）与程序安装后运行次数有关的处理故障的次数；

  • Step 5. 维护评价

    （1）每次程序运行时的平均出错次数；
    （2）用于每一类维护活动的总“人时”数；
    （3）每个程序、每种语言、每种维护类型所做的平均修改数；

第九章 项目管理

• 功能点技术（输入信息】数据输入越多工作量越大）

  • Step 1. 确定信息域：
    （1） 输入项数(Inp) ：用户向软件输入的项数
    （2） 输出项数(Out) ：软件向用户输出的项数
    （3） 查询数(Inq) ：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
    （4） 主文件数(Maf) ：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。
    （5） 外部接口数(Inf) ：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。

  • Step 2. 估算功能点数（即软件规模）
    用下述3个步骤，可估算出一个软件的功能点数（即软件规模）
    (1)计算未调整的功能点数UFP
    UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf
    其中，ai(1≤i≤5)是信息域特性系数

    (2)计算技术复杂性因子TCF.

    TCF=0.65+0.01×DI 其中，DI是技术因素对软件规模的综合影响程度

    （3）计算功能点数FP

    FP = UFP × TCF

• 面向FP的估算模型
  (1)Albrecht & Gaffney模型：E=-13.39+0.0545FP
  (2) Maston,Barnett & Mellichamp模型：E=585.7+15.12FP

• 成本核算（cocomo2，三个层次都是什么，工作原理工作思路）

  • 构造性成本模型

  • （1） 应用系统组成模型。这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。

  • （2） 早期设计模型。这个模型适用于体系结构设计阶段。

  • （3） 后期体系结构模型。这个模型适用于完成体系结构设计之后的软件开发阶段。

    • 该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数.
      其中，
      E 是开发工作量（以人月为单位），
      a 是模型系数，
      KLOC 是估计的源代码行数（以千行为单位），
      b 是模型指数，
      fi (i=1~17) 是成本因素。

• 软件质量保证

  • 软件质量是什么：
    • 软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。
    • 1）软件需求是度量软件质量的基础（与需求不一致就是质量不高）
      2）指定的开发标准（没有遵守这些准则，几乎肯定会导致质量不高）
      3）满足隐含的需求（软件满足明确描述的需求，那么质量值得怀疑）
  • 如何保证软件质量
  • 1. 技术复审的必要性
    2. 走查
    3. 审查
    4. 程序正确性证明

• 人员组成形式（民主形式】主程序员组形式等）

  • 主程序员组形式
    • 当所要开发的软件的技术难度较高时，采用民主制程序员组是适宜的。
    • 优点：组员们对发现程序错误持积极的态度，得到更高质量的代码，有利于解决难题。
    • 缺点：组员间将缺乏必要的协调,最终可能导致工程失败。
  • 中心程序员组形式
    • 主程序员：既是成功的管理人员又是经验丰富、
      技术好、能力强的高级程序员。
      优点：协调性好，有权威性。
      缺点：主程序员难找。
  • 现代程序员组
    • 行政组长：专人专职。
    • 优点：降低对主程序员的要求，适于大型项目开发。

• 软件配置管理是什么（5个任务4个活动是什么）

  • 四个活动
  • ①标识变化；
    ②控制变化；
    ③确保适当地实现了变化；
    ④向需要知道这类信息的人报告变化。
  • 五个任务
  • Task 1. 标识管理 Task 2. 版本控制
    Task 3. 变化控制 Task 4. 配置审计
    Task 5. 状态报告

• cmm能力成熟度模型的5个级别（分别叫什么】描述分别是什么）

  • 初始级（又称为1级）：

  软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的（即没有一个定型的过程模型），项目能否成功完全取决于开发人员的个人能力。

  • 可重复级（又称为2级）：

    软件机构建立了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量。
    已经建立起必要的过程规范，对新项目的策划和管理过程是基于以前类似项目的实践经验，使得有类似应用经验的软件项目能够再次取得成功。
    达到2级的一个目标是使项目管理过程稳定，从而使得软件机构能重复以前在成功项目中所进行过的软件项目工程实践。

  • 已定义级（又称为3级）：

    软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。所有项目组都使用文档化的、经过批准的过程来开发和维护软件。这一级包含了第2级的全部特征。

  • 已管理级（又称为4级）

    软件机构对软件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的。

    该软件机构收集了过程度量和产品度量的方法并加以运用，可以定量地了解和控制软件过程和软件产品，并为评定项目的过程质量和产品质量奠定了基础。- 这一级包含了第3级的全部特征。

  • 优化级（又称为5级）

    软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。
    在这样的机构中，可以获得关于软件过程有效性的统计数据，利用这些数据可以对新技术进行成本/效益分析，并可以优化出在软件工程实践中能够采用的最佳新技术。
    这一级包含了第4级的全部特征。

• rationalrose可以画哪些图（比方用例图）基本功能是什么

  • 用例图 类图 部署图 数据流图
  • 软件建模，部分自动程序生成

这篇关于天津理工大学软件工程A 期末复习（完整版）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！