软件工程-笔记

软件工程笔记

软件工程

• 软件生存周期的主要活动：
  • 可行性分析与项目开发计划
  • 需求分析
  • 概要设计
  • 详细设计
  • 编码和单元测试
  • 综合测试
  • 维护

复习大纲

第一章 概述

• 软件的定义和特性。
  • Software is a set of programs instruction, data structure, documents.
• 软件工程的定义
  • Software engineering is about designing and developing high-quality software
  • 软件工程是用计算机或计算机技术来求解实际问题的分析、设计、构建、验证、管理的过程，即将系统化的、规范化的、可度量化的方法应用到软件开发、运行、维护的过程中
  • 与计算机科学的关系
    • 计算机科学关注计算机的结构及其理论；软件工程关心的则是开发和提交有用软件的实践活动
    • 计算机科学解决的是计算机本身的问题，而软件工程是将计算机作为工具以生产有质量的软件
  • 
  • 涉及人员：
    • 客户：为软件付费的公司、组织和人
    • 开发者：创建软件的人（包括管理者和测试者）
    • 用户：真正使用该系统的人
• 软件质量定义及质量指标。
  • CMM：quality of the development process of software product （性能、可靠、安全、功能）
  • McCall’s: quality of the software product（开发团队、人际沟通、规程的规范性）
  • ROI: quality in the context of the business environment（用户评价、投资回报）
• 软件质量的McCall 模型
  • The McCall’s quality model concerns the quality of the software product
• way to get good software
  • System approach
    • 活动和对象
    • 关系和系统边界
    • 相关的系统
  • 工程化方法
    • 引入工程经验和过程管理标准

第二章 过程和生命期

• 过程、模型、生命期

  • 过程

    

  • 生命期

    • 软件定义：问题定义、可行性研究
    • 软件开发：需求分析、概要设计、详细设计、编码、测试
    • 软件运行：软件维护

• 四个（瀑布、V、原型、螺旋）模型的异同点。

  • 瀑布Waterfall（中、小型软件开发）

    • 优点
      • 可强迫开发人员采用规范化的方法
      • 严格地规定了每个阶段必须提交的文档
      • 要求每个阶段交出的所有产品都必须是经过验证的
      • 客户和开发人员很容易理解该模型
      • 从一个非常高层的角度描述了开发过程中进行的活动，并且提出了要求开发人员经过的事件序列；说明了每一个主要的开发阶段完成的里程碑或可交付制品
      • It can be very useful in helping developers lay out what they need to do. Its simplicity makes it easy to explain to customers who are not familiar with software developent; it makes explicit which intermediate products are necessary in order to begin the next stage of development.
    • 缺点
      • 由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要
      • 只适用于项目开始时已经确定的情况，没有提供如何处理在开发过程中可能出现的产品或活动的变化相关指导
      • 将软件开发视为制造过程而不是一个问题的求解过程
      • 没有说明创建最终产品过程中所需要的往返活动的相关信息
      • 往往需要很长时间才能得到最终产品
      • It does not reflect the way code is really developed; software development is a creative process, not a manufacturing one; always changing requirement; the very necessary try & error activities in a problem solving process becomes costly.
    • 主要活动：
      • 需求分析、系统设计、程序设计、编码、单元测试和集成测试、系统测试、验收测试、运行和维护
    • 特点：
      • 是第一个软件过程模型
      • 适应理解非常充分的问题，且需求变化很小或几乎没有变化的情况
      • 优点+缺点

  • V

    • is a variation of the waterfall model that demonstrates how the testing activities are related to analysis and design.

      The V model makes more explicit some fo the iteration and rework that are hidden in the water fall depiction. Whereas the focus of the water fall is often deocuments and artifacts, the focus of the V model is activity and correctness. bottom of P52虽然瀑布的焦点通常是文档和工件，但V模型的重点是活动和正确性。

    • 特点：

      • 瀑布模型的变种，采用参与测试来验证程序设计
      • 采用单元测试、集成测试来验证程序设计
      • 采用验收测试来确认需求分析
      • 采用系统测试来验证系统设计
      • 若在确认和验证过程中发现问题，那么在再次执行V右边的测试步骤之前，重新执行左边的步骤加以修正和改进需求、设计和编码

    • 主要活动：

      • 需求分析、系统设计、程序设计、编码、单元测试和集成测试、系统测试、验收测试、运行和维护

  • 原型（prototyping）

    • 优点：

      • 有助于满足用户的真实需求
      • 原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确的描述用户需求
      • 软件产品的开发基本上是按线性顺序进行
      • 建造出原型系统后，开发人员可以加速软件开发过程，节约软件开发成本
      • 较早地进行可行性分析

    • 缺点：

      • 更高的开发要求
      • 由于时间进度的原因，导致原型成为产品的一部分，存在潜在危险

    • 特点：

      • 允许重复检查需求或设计
      • 减少开发过程中的风险和不确定性

    • 主要活动：

      • 原型需求、原型测试、原型系统、测试

    • prototyping need bot be solely an adjunct of a waterfall; it can itself be the basis for an effective process model.

      The prototyping model allows all or part of a system to be constructed quickly to understand or clarify issues, it has the same objective as an engineering prototype, where requirements or design require repeated investigation to ensure that the developer, user, and customer have a common understanding both of what is needed and what is proposed.

    • in rapid prototyping, the prototype will ba part of the delivered software在快速原型制作中，原型将成为交付软件的一部分

  • 螺旋（spiral）

    • 优点：

      • 对可选方案和约束条件的强调有利于已有软件的重用，也助于把软件质量作为软件开发的一个重要目标
      • 减少了过多测试或者测试不足所带来的风险
      • 维护只是模型的另一个周期，因此在维护和开发之间并没有本质区别

    • 缺点：

      • 要求开发人员必须具有丰富的风险评估经验和专门知识

    • 特点：

      • 将开发活动与风险管理结合以最小化和控制风险
      • 模型表示为一个螺旋形状，在其中每一次迭代用包含四个主要活动的环形表示

    • 主要活动：

      • 计划、确定目标、可选方案和约束、评价可选方案和风险、开发和测试

    • view the software development process in light of the risks involved

      With each iteration, the risk analysis weighs different alternatives in light of the requirements and constraints, and prototyping verifies feasibility or desirability before a particular alternative is chosen.

  • Phased Development阶段开发【增量(Incremental) and iterations】

    • 优点：

      • 能在较短时间内向用户提交完成一些有用功能的工作产品
      • 逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品
      • 项目失败的风险较低
      • 优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来，这意味着，最重要的部分将接受最多的测试

    • 缺点：

      • 与其他模型相比，需要更精心的设计

    • 特点：

      • 优点+缺点
      • 两个系统并行运行：
        • 产品系统是当前正在被客户和用户使用的系统
        • 开发系统是转变用来替换现行产品系统的下一个版本

    • 主要活动：

      • 需求分析、系统设计、程序设计、编码、单元测试和集成测试、系统测试、验收测试、运行和维护

    • the system is designed so that it can be delivered in pieces, enabling the users to have some fuctionality while the rest is being developed. The two most popular approaches are incremental development and iterative development.

      In increment development, the system as specified in the requirements documents is partitioned into subsystem by functionality. The releases are defined by beginning with one small, functional subsystem and then adding functionality with each new release.

      In iterative development, it delivers a full system at the very beginning and then changes the functionality of each subsystem with each new release.

第三章 项目管理

• Project organization项目组织

  • Chief programmer team首席程序员制度：由他做最后决定，适用与规模较大的large scale，确定程度比较高的high certainly，重复工作比较多的repetition
  • Egoless approach忘我：项目组中所有成员地位平等，共同决策 （is suited for adopting a new programming language projects）与上一个相反，加上涉及新技术比较多的

• Risk management风险管理

  • Risk Assessment风险评估

    • Risk identification 提出潜在破坏项目进度风险

      • 风险辨识是指查找企业各业务单元、各项重要经营活动及其重要业务流程中有无风险，有哪些风险。　

    • Risk analysis 评估每一个风险出现的可能性及影响

      • 风险分析是对辨识出的风险及其特征进行明确的定义描述，分析和描述风险发生可能性的高低、风险发生的条件

    • Risk prioritization 根据影响大小排出一个风险的优先级

      ​ 风险评价是评估风险对企业实现目标的影响程度、风险的价值等。

  • 风险控制

    • Risk management planning制定一个方案
    • Risk resolution对应计划执行
    • Risk monitoring识别新的风险

• 项目范围的WBS表示

• 项目进度的GANTT图表示

  • A Gantt chart helps the project manager to understand which activities can be performed concurrently, and also to see which items are on the critical path.

  • 他是一种简单的水平条形图，它以日历为基准描述项目任务，水平轴表示日历时间线，每一个线条表示一个任务，任务名称垂直的列在左边列中，图中的线条的起点和终点对应水平轴上的时间，分别表示任务的开始时间和结束时间，线条的水平长度表示该任务的持续时间。同一时间短内有多个线条，表示这些任务是并发进行的。

  • 能清晰的描述每个任务从何时开始，到何时结束，以及任务之间的并行关系。但是他不能清晰的反应出各任务的依赖关系。但可以反应出在关键路径上的活动。

  • 甘特图可用于表示项目的工作分解结构

    A gantt chart can be used to represent the work breakdown structure of a project

• 关键路径的定义及其求解方法

  • PERT图：不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系。
  • 

第四章 需求分析

• 需求的定义

• 需求的类型

  • 功能需求：指系统需要完成那些事情，即向用户提供哪些功能。
  • 非功能需求：指产品所具备的品质和属性，比如可靠性、扩展性、响应时间、性能等等
  • 设计约束：也称条件约束、补充规则。比如系统对操作系统的要求、硬件环境的要求，平台，接口等等
  • 过程约束：对于构建系统的技术和资源的限制，客户可能坚持使用敏捷方法

• （高质量）需求的特征

  correct 正确的

  consistent 一致性（文档前后是否有冲突

  unambiguous 明确的

  complete 完备性（指定了所有的约束、所有状态、所有的I/O以及必须的行为【比如大小约束】

  feasible 切实可行的（需求可行？需要的解决方案存在？

  relevant 相关性（必须的需求

  testable 可测试的（验收测试的是否符合需求

  Traceable 可追踪的（唯一标识需求

• 需求的表示方法及其应用

  • 实体关系图

  • 【statechart diagram】状态机（state machine）

    • 描述了系统与其环境之间的所有对话，对应UML中的状态图，包含节点、边
    • State Machine is a graphical desctiption of all dialog between the system and its environment

  • E-R图【class diagram】

    • 表示概念模型的一种方法，包含实体、联系和属性三个要素，这些结构组合在一起说明问题的元素和它们之间的相互关系，对应UML中的类图。
    • E-R Diagrams is popular graphical notional paradigm for representing conceptual models
    • a sophisticated ER diagram used to to emphasize the problem’s entities and their interrelationships.
    • ER图虽然简单，但是在实践中很难运用。在一些问题中，对于三个要素的判定是不明显的。比如，数据库里的订单，可以作为属性也可以作为实体

  • 数据流图（DFD）

    • 对功能以及从一个功能到另一个功能的数据流建模，对应UML中的用例图
    • Data Flow Diagram models functionality and the flow of data from one function to another
    • The data flow diagram depicts relationships between data objects

  • 【sequence diagram】事件踪迹（event trace）

    • 关于现实世界实体之间交换的事件序列的图形描述，对应UML中的交互图（序列图和协作图）
    • Event Traces is a graphical description of sequence of events that are exchanged between real world entities

  • UML use-cases Diagram is similar to a top-level data-flow diagram that depicts observable, user-initiable functionality in terms of interactions between the system and its environment有个方框，外面有个小人的那种

  • Functions and relations功能和关系

    • Decision table决策表

  • UML Class Diagrams: 像类继承图那样的

  • Message Sequence Charts are an enhanced eventtrance notation消息序列图表是一种增强的事件跟踪表示法

  • UML Statechart Diagrams depicts the dynamic behavior of the objects in a UML classUML状态图表描述了UML类中对象的动态行为

  • Petri Nets are a forms of state-transition notation that is used to model concurrent activities并发活动

  • 代数规格说明

  • 判定表

• 需求文档

  • Requirements definition 需求定义
  • Requirements specification 需求规格说明

第五章 系统设计

• 设计的定义

• 软件体系结构的定义和要素

  • 软件体系结构包括构件(Component)、连接件(Connector)和约束(Constraint)三大要素。

• 体系结构风格与策略（7种）Architecture style

  • 管道和过滤器风格 （Pipe-Filter Style）

    • 西电管理系统【也允许并行执行】
    • 图像处理系统
    • unix命令解释系统
    • 编译系统
    • In this sytem, functionality is achieved by passing input data through a sequence of data-transforming components, called filters, to produce output data. Pipes are connectors that simply transmit data from one filter to the next without modifying the data.
    • In pipe and filters, concurrent executing of filters is permitted

  • Implicit invocation隐式调用(发布-订阅，基于事件、选择性)Publish Subscribing

    • 天气预报系统

    • components interact by broadcasting and reacting to events. A component expresses interest in an event by subscribing to it. Then, when another component announces(publishes) that the event has taken place, the subscribing components are notified.

      Implicit invocation is a common form of publish-subscribe architecture, in which a subscribing aomponent associates one of its procedures with each event of interest. In this case, when the event occurs, the publish-subscribe infrastructure invokes all of the event’s registered procefures.

  • Client/Server 客户端/服务端风格

    • 银行系统
    • the design is divided into two types of components: clients and servers. Server components offer services, and clients access them using a request/reply protocol. There maybe one centralized server, several replicated servers distributed over several machines, or several distinct servers each offering a different set of services.

  • Process control过程控制

  • Repositories 信息库

    • consists of two types of components: a central data store and associated data-accessing components. Shared data are stockpiled in the data store, and the data accessor are computational units that store, retrieve, and update the information.
    • 搜索引擎（例如图书馆
    • 智能诊断和医疗系统

  • Laying 分层体系结构风格

    • unix操作系统
    • 网络通信的OSI模型

  • Object-oriented design 面向对象设计

  • Interpreters 解释器

  • Peer to Peer对等网络P2P（类似请求/应答模式）

    • 军事装备系统、file-sharing networks such as Napster, Freenet, 迅雷
    • is one in which each component executes as its own process and acts as both a client of and a server to other peer components. Each component has an interface that specifies not only the services it provides, but also the services that it requests from other peer components.

• 设计特性

  • 独立性

  • 高内聚，低耦合是好的

  • 构件内聚（component cohesive）7种

    • 当一个控件的功能越单一，它的内聚性就越高，动词要少

    • 一个构件功能强度的度量。分为：

      • 偶然内聚

        The worse degree of cohesion is found in a module whose parts are unrelated to one another. In this case, unrelated functions, processes, or data are combined in the same module for reasons of convenience or serendipity.

      • 逻辑内聚（整个框架只是一个分支语句）

        if its parts are related only by the logic structure of its code

      • 时间内聚（因执行时间一样而被安排在了一起）

        sometimes a design is divided into modules that represent the different phases of execution: initializaiton, read input, compute, print output, and cleanup.

        fuctions are related only because they are used at the same time in an execution.

      • 过程内聚（特定次序执行）

        fuctions must be performed in a certain order.

        when functions are grouped together in a module to encapsulate the order of their execution

      • 通信内聚（使用了相同的输入或输出）

        Alternatively, we can associate certain fuctions because they operate on the same data set.

        For instance, unrelated data may be fetched together because the data are collected from the same input sensor or with a single disk access

        比如c++中的栈操作 pop(), push(), top(), size(), empty()…

      • 顺序内聚（输出作为另一功能的输入）

        two conditions hold: all elements essential to a single function are contained in one module, and all of that module’s elements are essential to the performance of that performance of that fuction.

        所有的参数都是在该module中得到的，并且参数缺一不可

      • 功能内聚

        A functionally cohesive module performs only the function for which it is designed, and nothing else.

        功能单一的module

  • 构件耦合（component coupling） 6种

    • 两个构件之间相互依赖或者相互作用的程度的度量。分为：

      • 非耦合（通过上层模块联系）

      • 数据耦合（传递一般类型）

        if only data values but not structed data are passed

      • 标记耦合（传递结构体）

        when complex data structures are passed between modules

      • 控制耦合（传递参数或返回代码来控制另一模块的行为）

        when one module passes parameters or a return code to control the behavior of another module

      • 公共耦合（全局变量）

        we can reduce the amount of coupling somewhat by organizing our design so that data are accessible from a common data store. However, dependence still exists: making a change to the common data means that, to evaluate the effect of the change, we have to look at all modules that access those data.

      • 内容耦合

        the least desirable occurs when one module actually modifies another. In such a case, the modified module is completely dependent on the modifying one.

        Content coupling might occur when one module is imported into another module, modifies the code of another module, or branches into the middle of another module.

• Decomposition分解

  • No matter the design approach, each kind of decomposition separates the design into modules无论设计方法如何，每种分解都将设计分为模块

  • Functional decomposition

    This method partitions functions or requirements into modules. The designer begins with the functions that are listed in the requirements specification; these are system-level functions that exchange inputs and outputs with the system’s environment. Lower-level designs divide these functions into subfunctions, which are then assigned to smaller modules. The design also describes which modules(subfunctions) call other.

  • Feature-oriented design

    This method is a type of functional decomposition that assigns features to modules.

  • Data-oriented decomposition

    This method focuses on how data will be partitioned into modules.

  • Process-oriented decomposition

    This method partitions the system into concurrent processes.

  • Event-oriented decomposition

    This method focuses on the events that the system must handle and assigns responsibility for events to different modules.此方法关注系统必须处理的事件，并将事件的责任分配给不同的模块。

  • Object-oriented design

• good design

  • 可量化的
    • 构建独立性
    • 异常标志和处理
    • 防错和容错技术
  • 主观上的：
    • 易于理解
    • 易于实现
    • 易于测试
    • 易于修改

• 重要的设计问题

  • Modularity and levels of abstraction 模块性与抽象层次
  • Collaborative design 协同设计
  • Design the user interface 设计用户界面
  • Concurrency 并发
  • Design patterns and reuse 设计模式与复用

第七章 软件实现

• 标准文档
• 文档化方法（内部文档、外部文档）

第八章 单元测试

• 黑盒法与白盒法的适用范围

  • 白盒测试技术：结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行。必须完全了解程序内部结构和处理过程，才能按照程序内部的逻辑测试，以检验程序中每条路径是否正确，因此一般用于规模较小的程序和单元测试。

    • statement coverage 语句覆盖

      decision coverage 判定覆盖

      condition coverage 条件覆盖

      decision/condition coverage 判定/条件覆盖

      branch condition combination 条件组合覆盖

      path coverage 路径覆盖

      boundary test

  • 黑盒测试（功能测试）：它是通过测试来检测每个功能是否都能正常使用；检查输入输出，不考虑内部结构和处理过程），必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出，但这是不可能的。

    • equivalence class partitioning 等价类划分方法
    • 因果图
    • 正交设计

• 集成测试的两种策略（自底向上、自顶向下）

  • 自顶向下（第一层到最后一层
  • 自底向上（从叶子到根
  • 三明治（上两者结合
  • 大爆炸（一次性

• 语句测试、分支测试、路径测试方法及其应用

  • 大题里会有

• code review

  • 代码走查（code walkthroughs ）
    • 程序员向评审小组提交代码及其相关文档，然后评审小组评论它们的正确性
  • 代码审查（code inspection ）
    • 与走查类似，但更正式一些。按照一个事先准备好的关注问题清单来检查代码和文档

• 故障类型

  • 算法故障algorithmic fault
    • 分支太早
    • 分支太迟
    • 对错误条件进行了测试
    • 忘记了初始化变量或忘记设置了循环不变量
    • 忘记针对特定的条件进行测试（例如可能出现除数为零的情况）
    • 对不合适的数据类型变量进行比较
  • 计算故障computation fault和精度故障precision fault
  • 文档故障documentation fault
  • Stress fault压力故障 overload fault过载故障
  • Capacity fault能力故障 boundary fault边界故障
  • Timing fault计时故障 coordination fault协调故障
  • throughput fault吞吐量故障 performance fault性能故障
  • Recovery fault恢复故障
  • Hardware and system software fault硬件和系统软件故障
  • Standards and procedure fault标准和过程故障

第九章 系统测试

• 软件配置的定义。

• 系统测试过程：测试整个软件系统

  • 单元测试unit test （测试单个模块）和集成测试integration test （测试集成的模块）之后，进行系统测试，系统测试主要包括四个步骤：

    • 功能测试（Function test）：检查集成的系统是否按照需求中指定的那样执行它的功能

    • 性能测试（Performance test）：将集成的构件与非功能需求进行比较

      • Stress tests 压力测试 在系统处于极限状态下停留短暂时间来估测系统性能；所有设备和用户同时激活时进行系统性能评估
      • Volume tests 容量测试 用来测试系统中大容量数据的处理；例如，我们检查是否数据结构（队列或堆栈）被定义的足够大，以处理各种可能的情况；例如，检查域，记录和文件来看是否它的大小可以容纳所有的数据；我们还应确定当数据集达到最大尺寸时，系统是否工作正常
      • Configuration test 配置测试 software and hardware分析在需求中定义的不同的软件和硬件配置
      • Compatibility test 兼容性测试 between systems 比如接口是否执行了需求指定的功能；比如系统和一个大数据库通信，兼容性测试检查检索数据的速度和精确性

      • Regression tests 回归测试 between versions

        • 当被测试的系统是用来代替现存系统时，就需要回归测试；保证性能至少和旧版本一样好；回归测试总是使用在分阶段开发中
        • 回归测试是用于新的版本或发布的一种测试，以验证与旧版本或发布相比，它是否仍然以同样的方式执行相同的功能。由于在测试过程中可能在修复已有故障的同时引入新的故障，故需要进行回归测试

      • Security test 测试相关数据和服务的可用性，一致性，完整性和机密性

      • timing tests 计时测试 评估涉及对用户的响应时间和一个功能的执行时间的相关要求
      • 环境测试 environmental test
      • quality test质量测试
      • recovery test恢复测试
      • maintenance test维护测试
      • documentation test文档测试
      • human factors test人为因素测试
      • usability test可使用性测试

    • 验收测试（Acceptance test）：客户参与的测试，目标是确保系统符合他们对需求的理解

    • 安装测试（Installation test）：在实际运行环境中进行测试

• 功能测试的主要方法（因果图法）

  • 
  • 
  • 
  • 
  • 

• 性能测试（１３种测试及举例）

• 可靠性、可用性、可维护性的定义及度量方法

  • MTTF（mean time to failure)平均失效等待时间
  • MTTR（mean time to repair)平均修复时间
  • MTBF（mean time between failures)平均失效间隔时间$MTBF=MTTF+MTTR$
  • 可靠性：是指一个系统对于给定的时间间隔内、在给定条件下无失效（without failure）运作的概率，$R=\frac{MTTF}{1+MTTF}$
  • 可维护性：是指在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动（a maintenance activity can be carried out)的概率$M=\frac{1}{1+MTTR}$
  • 可用性：是指在给定的时间点上，一个系统能够按照规格说明正确（successfully）运作的概率 $A=\frac{MTBF}{1+MTBF}$

• 验收测试的基本方法

• 测试技术

  • 构建或螺旋化渐进测试计划
  • 配置管理

第十章 系统交付

• 文档的定义和类型

  • 每一个系统都有正式的文档，这些文档为培训提供支持。用于遇到问题或有疑问的时候进行参考
  • 类型
    • 考虑读者
    • 用户手册
    • 操作员手册
    • 系统概况指南
    • 教学软件和自动化系统的概述
    • 其他的系统文档

• 培训对象和类型

• 培训辅助方法

第十一章 系统维护

• 系统类型

  • S-Systems 静态系统。无改变需要，如代数运算
  • P-Systems 可行系统，基于问题的一个可行的抽象，而不是完全定义好的说明。可能变化，如模式识别
  • E-Systems 嵌入系统，问题不能完全被说明。成功取决于客户评价，如银行系统，ERP

• 维护的四种基本类型

  • Corrective maintenance 改正性维护：控制日常功能，对故障立即作出反应
    • To control the day-to-day system functions, we on the maintenance team respond to problems from faults. This kind of maintenance is called corrective maintenance .
  • Adaptive maintenance 适应性维护：系统修改
    • Suppose the existing database management system is upgrade to a new version, this maintenance is called adaptive maintenance.
  • Perfective maintenance 完善性维护：完善现有功能
    • If the customer wanted to add a new function, this kind of maintenance is called perfective maintenance，包括改变文档以阐明相关事项，改变测试集以增加测试覆盖，修改代码和设计以增强可读性
  • Preventive maintenance 预防性维护：防止出错
    • 增加类型检查，增强故障处理，或在情况语句中增加“catch-all”语句，以确保系统能够处理所有可能的情况

• 可维护性的两种度量方法（外部方法：记录时间；内部方法：环路数）

  • 环路数
    • 等于判定语句数+1
    • 等于划分平面数，包括图外区域
    • 等于e-n+2

• Any work done to change the system after it is in operation is considered to be maintenance

  在系统运行后更改系统所做的任何工作都被认为是维护

题型

一 单选 152
二 对错 101
三 简答 5*6
四 大题 知识点

关键路径

活动是那个点，且最早开始时间写1，下一个点是1+线段长度；开始时间不是完成时间！！！！

1. | 序号 | 后继 | 前驱 |
   | —— | —— | —— |
   | 1 | | |
   | 2 | | |
   | 3 | | |

序号	活动	最早开始时间	最晚开始时间	松弛时间
1	A◇B
2
3

1. You are required to find out the critical path(s).

   CP1: 0-2-3…列出即可，若有多条，列出多条

（白盒）测试

1.走每一条分支，走到return 结束

2.对于有循环的，写到进入循环后的第一个点，例如1->2->3->4->2

覆盖准则

内聚耦合

列举

risk exposure calculation

1. $$1M=10^6\space\space\space\space\space\space\space\space$1K=10^3$
2. $\sum可能性formal_cost$ 如果其部分含有delivered cost，则这一分项为$可能性(formal_cost+delivered_cost)$
3. 其中花费最少的，是最好的

decision table（表）

条件		规	则
a	N	N	Y	Y
b>=0	N	Y	N	Y
操作
A	X
B		X	X
C				X

条件		规	则
a	Y	Y	N	-
b	-	Y	Y	-
操作	X
A		X
B			X
C				X

两种类型都可以呢

杂七杂八的选择、判断

1. 选择模型

   Waterfall model： 需求明确时使用，最基础的模型，过程固定，偏向死板；稳定的产品定义和易理解的技术解决方案时；对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上时【代替老版本】；易理解但很复杂的项目【用顺序方法处理问题】；在质量需求高于成本需求和进度需求的时候；当开发队伍的技术力量比较弱或者缺乏经验时；小规模软件开发

   V model：在waterfall model的基础上发展形成，加强了iteration & rework的部分

   Prototyping model：通过prototype的多次展示中不断加强对需求的认识，需求不明确时使用，适应于需引出（elicit）需求，适合市场驱动下使用的开发模式

   Spiral model：快速开发，有完善软件的潜力，在每次的iteration中加入了风险控制；内部软件开发的大规模软件项目

   phases development通过首先递交不完整的产品，一步步地在之前的基础上进行开发

   Increment development通过每次递交一个完成的功能，最终实现产品；软件开发周期较长的软件，有持续的合作。

   Iterative development通过首先递交一个不完整的系统，之后的开发在其基础上提升功能

2. 测试是为了发现错误（但是不必修改它们），不是也不能证明程序无错；好的测试，发现了尚未发现的错误；穷举测试是不可能的

   we test a program to demonstrate the existence of a fault a success test if the one discovering a fault which has never been found so far

3. 一个系统是由可能存在或包含在另一个系统里的

   In many software projects, we should capture the development process as a collection of process models, rather than focusing on a single one

   在许多软件项目中，我们应该将开发过程作为一组过程模型来捕获，而不是只关注一个过程模型

4. many effort-estimation methods can not produce accurate estimates

   许多努力估计方法无法产生准确的估计

5. 编程人员不用直接接触需求文档

   因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。

   但项目开发人员、软件测试人员、顾客需要直接接触文档

6. 在单元和集成测试之后是function test功能测试

7. software engineering is about designing and developing high-quality software

8. prioritization is especially helpful in resolving conflicts among quality requirement 优先排序特别有助于解决质量要求之间的冲突

9. 维护所需的精力多于开发

10. client 开发者 customer买这个软件的人

11. False: For each identified exception, we can retry it, i.e. restore the system to its previous state and try again to perform the service using a same strategy.

    对于每个已识别的异常，我们可以重试它，即将系统恢复到先前的状态，然后再次尝试使用相同的策略执行服务。retry shouldn’t be involved with rollback. Just retry it .

12. False: While examining the code, we need to find faults and fix them

    在检查代码时，我们需要找到错误并修复它们

13. True: module “pocessPurchase” removes the purchases product from inventory, prints a receipt for the customer and updates the log. This module is high cohesion one

    模块“pocessPurchase”从库存中删除购买产品，为客户打印收据并更新日志。此模块具有高凝聚力

14. the path in the communication paths is bi-connected path

    通信路径中的路径是双连接路径

15. 没有初始化是算法错误；跟算法性错误形成对比的是无法设计的错误、需求认识的错误

16. “what are the appropriate reactions to possible stimuli”（什么是对可能的刺激的适当反应）是功能需求！！！

17. 典型异常：typical exception:
    未能提供服务 failure to provide a serivce
    提供错误服务 providing the wrong serivice
    破坏数据 corrupting data

19. Failure [user sees] fault

20. T：computer engineer focuses on the computer as a problem-solving tool

22. A computer engineer focuses on the computer as a problem-solving tool

23. A computer engineer focuses on the computer as a problem-solving tool

24. A computer engineer focuses on the computer as a problem-solving tool

单词啊！！！

Rational 理性的 intuitive感性的

Extrovert 外向的 introvert 内向的

转载请注明出处，谢谢。

愿 我是你的小太阳