背景介绍

分页功能非常常见，当要展示的列表页项目很多的时候，全部加载到页面上会使页面卡顿，此时便需要对列表进行分页显示，分页又分为前端分页和后端分页。

• 前端分页：一次性拉取全部数据，前端对所有数据进行分页显示。

  • 缺点：下载量大，显示慢，加载时用户体验不好。如果有即时性内容，就不能翻回来的时候更新了。
  • 优点：服务器压力请求少，换页时用户体验好。

• 后端分页：后端对数据划分为若干页，前端每次只拉取一页数据并显示。

  • 缺点：每次换页都需要访问后端，加重服务器的压力，换页时显示慢。
  • 优点：不用一次性拉取所有数据，显示快，用户体验较好。

目前能够实现分页的框架有很多，这里只介绍Element-Ui的一个组件el-pagination，该组件在后端分页的基础上实现分页，需要后端提供返回数据总数和每一页数据的接口。

用法介绍

官方文档

1
2
3
4
5
6
7

<el-pagination
    @current-change="handleCurrentChange"
    :current-page="currentPage"
    :page-size="20"
    layout="total, prev, pager, next, jumper"
    :total="questionsNum"
></el-pagination>

以上代码可以显示分页组件，该组件只提供展示功能，当换页时会回调handleCurrentChange返回新的页码，利用新的页码向服务端请求该页数据即可实现分页。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

export default {
  data() {
    return {
      questionsList: [],
      questionsNum: 0,
      currentPage: 1,
    };
  },
  mounted: function() {
    this.$http.get("/api/assignment/qa/" + this.currentPage).then(
      response => {
        this.questionsList = response.data.assignments;
        this.questionsNum = response.data.asgCount;
        console.log(response.data);
      },
      response => console.log(response)
    );
  },
  methods: {
    handleCurrentChange: function(val) {
      this.currentPage = val;
      this.$http.get("/api/assignment/qa/" + this.currentPage).then(
        response => {
          this.questionsList = response.data.assignments;
          this.questionsNum = response.data.asgCount;
          console.log(response.data);
        },
        response => console.log(response)
      );
      console.log(`当前页: ${val}`);
    }
  }
}

questionsList即当前页的数据，questionsNum即数据总数。

个人小结

个人简短小结

我在团队中主要负责UI/UX设计和前端部分功能的开发。

UI/UX设计

经过前期的几次开会讨论，我们大致确定了需求，并确定了任务系统的两个主要任务：问卷和问答。于是我开始着手设计原型初稿，主要参考了问卷星、悟空问答、百度知道和知乎。具体参考UI设计

前端

由于前端工作量较大，人手不足，因此我也帮忙做了一部分开发，前端使用的是Vue框架，我主要完成的是主页面列表的显示和数据获取和发布问答、采纳回答等功能。

PSP 2.1 统计

最得意的工作清单

• 第一次做原型设计，使用墨刀并参考了一些竞品的设计思想，设计出了一套具有自己风格的UI界面。
• 协助前端开发，完成了主页面的列表显示，发布问答、采纳回答等主要功能。
• 帮助前端队友解决问题，减少踩同样的坑的时间，提高了工作效率。

个人GIT总结

Dashboard 文档集合

frontend 文档集合

个人博客清单

• 前端分页功能的实现

特别致谢

• 有过原型设计经验的女朋友对我的指导，给了我很多启发。
• 前端主要负责人16340141-Yuuoniy教我Vue，让我一个晚上速成，快速进入前端开发。
• 以及其他队员耐心指出原型的不足，使我能够更好地完善原型设计。

使用 UMLet 建模

1、使用类图，分别对 Asg_RH 文档中 Make Reservation 用例以及 Payment 用例开展领域建模。然后，根据上述模型，给出建议的数据表以及主要字段，特别是主键和外键

• 注意事项：

  • 对象必须是名词、特别是技术名词、报表、描述类的处理；
  • 关联必须有多重性、部分有名称与导航方向
  • 属性要注意计算字段

• 数据建模，为了简化描述仅需要给出表清单，例如：

  • Hotel（ID/Key，Name，LoctionID/Fkey，Address…..）

Make Reservation

• Hotel (ID/Key, name, address, cityID/Fkey)
• City (ID/Key, name)
• Room (ID/Key, type, availability, hotelID/Fkey)
• Customer (ID/Key, fullName, emailAddress)
• ReservationItem (ID/Key, roomID/Fkey, basketID/Fkey, checkInDate, checkOutDate, adultNum, childrenNum, price, isSmoking)
• ReservationBasket (ID/Key, customerID/Fkey)

Payment

• Payment (ID/Key, totalPrice)
• PaymentWithCard (ID/Key, paymentID/Fkey, creditCardNum/Fkey)
• CreditCard (CardNum/Key, type, securityCode, expiryDate, cardHolderAddressID/Fkey)
• CardHolderAddress (ID/Key, title, firstName, lastName, address1, address2, city, countyOrState, country, postcode, daytimeTelephone, eveningTelephone)
• ReservationItem (ID/Key, paymentID/Fkey, roomID/Fkey, basketID/Fkey, checkInDate, checkOutDate, adultNum, childrenNum, price, isSmoking)

2、使用 UML State Model，对每个订单对象生命周期建模

• 建模对象： 参考 Asg_RH 文档， 对 Reservation/Order 对象建模。
• 建模要求： 参考练习不能提供足够信息帮助你对订单对象建模，请参考现在 定旅馆 的旅游网站，尽可能分析围绕订单发生的各种情况，直到订单通过销售事件（柜台销售）结束订单。

使用 UMLet 建模：

1、根据订旅馆建模文档，Asg-RH.pdf：

绘制用例图模型（到子用例）

给出 make reservation 用例的活动图

2、根据课程练习“投递员使用投递箱给收件人快递包裹”的业务场景

分别用多泳道图建模三个场景的业务过程

case1

case2

case3

根据上述流程，给出快递柜系统最终的用例图模型

• 用正常色彩表示第一个业务流程反映的用例
• 用绿色背景表述第二个业务场景添加或修改的用例，以及支持 Actor
• 用黄色背景表述第三个业务场景添加或修改的用例，以及支持 Actor

1. 简答题

1.1 用例的概念

用例是一系列相关的成功和失败场景的集合，这些场景描述了一个参与者使用一个系统来支持一个目标。用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

1.2 用例和场景的关系？什么是主场景或 happy path？

• 场景是参与者和系统之间一个特定的行为和会话，也被称为用例实例。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。
• 主场景/happy path：每个用例提供了一个主场景和若干个可选场景，主场景/happy path对应于主要的系统交互，通常是“成功”的场景，它最常用，直接地实现用户目标的故事，是没有异常或错误条件的默认场景。

1.3 用例有哪些形式？

• 简洁形式：简短的一段总结，通常是主要的成功场景。在早期的需求分析中，快速了解主题和范围。可能只需要几分钟来创建。
• 非正式形式：非正式的段落格式，包含多种场景的多个段落。
• 完整形式：所有的步骤和变化都写得很详细，并有支持部分，如先决条件和成功的保证。在以一种简短的格式确定并编写了许多用例之后，在第一个需求研讨会期间，会详细地编写一些(例如10%)具有体系结构重要性和高价值的用例。

1.4 对于复杂业务，为什么编制完整用例非常难？

对于复杂业务，场景多而复杂，在编制用例时很难不遗漏一些业务和需求，且这些需求还可能发生变化，所以编制完整用例非常困难。

1.5 什么是用例图？

用例图是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

1.6 用例图的基本符号与元素？

• 参与者（Actor）
  参与者是与系统交互的人或物。包括开发系统用户和与开发的系统有关联的其他系统。在UML图中用一个小人表示。

  

• 用例（use case）
  用例是参与者可以感受到的系统服务或功能单元。在UML图中用椭圆表示。

  

• 系统边界（system boundaries）
  系统与系统之间的边界。在UML图中用矩形表示。

  

• 关系（relation）
  用例图中的关系有4种：关联，泛化，包含和扩展。

  • 关联：表示参与者和用例之间的交互，任何一方都可发送或可接收消息。在UML图中用直线表示。

    

  • 泛化：用例的泛化指的是一个父用例可以被特化形成多个子用例，类似于继承。在UML图中用空心箭头表示，箭头指向的是父用例。

    

  • 包含：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。在UML图中用带箭头的虚线段加<>表示，箭头指向被包含的用例。

    

  • 扩展：扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。在UML图中用带箭头的虚线段加<>表示，箭头指向基用例。

    

1.7 用例图的画法与步骤

• 确定参与者
  • 谁将使用该系统的主要功能。
  • 谁将需要该系统的支持以完成其工作。
  • 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
  • 系统需要处理哪些硬件设备。
  • 与该系统那个交互的是什么系统。
  • 谁或什么系统对本系统产生的结果感兴趣。
• 识别用例
  • 特定参与者希望系统提供什么功能。
  • 系统是否存储和检索信息，如果是，由哪个参与者触发。
  • 当系统改变状态时，是否通知参与者。
  • 是否存在影响系统的外部事件。
  • 哪个参与者通知系统这些事件。
• 识别用例间的关系

1.8 用例图给利益相关人与开发者的价值有哪些？

• 用例已经证实更容易被业务用户理解，因此它也是开发人员和最终用户的很好的沟通桥梁。
• 用例对于确定范围很有用。用例使分阶段交付从而一步步完成项目变得容易；它们能够在优先度变化时相对较容易的添加或从软件项目移去。
• 用例可跟踪。
• 用例能够作为估计，制定进度和验证成果的基础。
• 用例防止了不成熟的设计。
• 用例不使用特定语言。
• 用例允许我们去讲故事。能够容易的采用将需求转换为故事或场景这一具体的方法来描述用例。
• 用例在项目中可复用。用例在每一次迭代中都能进一步演化，用例可以用于捕获需求，成为程序员的开发依据，发展为测试用例，到最后成为用户手册。
• 用例与用户和系统交互相关。它们使软件开发者在开发之前或当中就能够开始用户接口设计。
• 用例将需求置于上下文中，它们能够清楚地描述业务活动间的关系。

2. 建模练习题（用例模型）

2.1 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

• 请使用用户的视角，描述用户目标或系统提供的服务
• 粒度达到子用例级别，并用 include 和 exclude 关联它们
• 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
• 尽可能识别外部系统和服务

2.2 回答下列问题：

2.2.1 为什么相似系统的用例图是相似的？

因为在相似的系统中，用户的需求是相似的，所以这些系统有着类似的功能，提供给用户类似的服务，因此它们的用例图是相似的。

2.2.2 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术

在Asg_RH用例图中，当搜索不到用户指定的城市时，会提供用户搜索地点的服务；而在当今时代的去哪儿定旅馆业务中，不会出现搜索不到的情况，该系统利用先进的技术，智能匹配与用户输入最接近的城市。从对比中可以发现，不同时代对于相同的业务有可能有不同的需求，因此在软件发展的过程中，我们需要更新用例图，采用更先进的技术，展现、突出创新业务。

2.2.3 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

对于不同方面的创新的用例，使用不同颜色背景的用例图表示，直观地观察其在系统中的作用。如果创新位于较高的父级，则作用比较大。如果是子类或者是被包括的关系，则作用相对较小。

2.2.4 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

2.2.5 根据任务4，参考使用用例点估算软件成本 给出项目用例点的估算

• 简单用例：1到3个事务，权重=5
• 一般用例：4到7个事务，权重=10
• 复杂用例：多于7个事务，权重=15

简答题

简述瀑布模型、增量模型、螺旋模型（含原型方法），并分析优缺点。从项目特点、风险特征、人力资源利用角度思考

1. 瀑布模型
   • 优点
     • 为项目提供了按阶段划分的检查点。
     • 当前一阶段完成后，我们只需要去关注后续阶段。
     • 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
   • 缺点
     • 在项目各个阶段之间极少有反馈。
     • 只有在项目生命周期的后期才能看到结果。
     • 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
2. 增量模型
   • 优点
     • 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
     • 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
     • 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
   • 缺点
     • 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
     • 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
     • 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
3. 螺旋模型
   • 优点
     • 设计上的灵活性,可以在项目的各个阶段进行变更。
     • 以小的分段来构建大型系统,使成本计算变得简单容易。
     • 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
     • 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
     • 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
   • 缺点
     • 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
     • 过多的迭代次数会增加开发成本，延迟提交时间。

简述统一过程三大特点，与面向对象的方法有什么关系？

统一过程的三大特点：1. 软件开发是一个迭代过程。2. 软件开发是由Use Case驱动的。3. 软件开发是以架构设计为中心的。
与面向对象的方法的关系：
统一过程是敏捷方法的实践者，在设计阶段，设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），并体现类的对象之间的作用关系；在实现阶段，以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；在测试和集成阶段，需要测试类本身的功能和类间作用关系。

简述统一过程四个阶段的划分准则是什么？每个阶段关键的里程碑是什么？

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。四个阶段的划分准则是在阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

1. 初始阶段里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。
2. 细化阶段里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
3. 构造阶段里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
4. 交付阶段里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

软件企业为什么能按固定节奏生产、固定周期发布软件产品？它给企业项目管理带来哪些好处？

软件企业对软件的生产过程具有明确的阶段划分，由于每个阶段都会有显著的里程碑，使得每个迭代阶段都有明确的目标。各个阶段的生命周期具有固定长度， 所以产品的的迭代开发过程有较为明确的时间限制，因此软件企业能按固定节奏生产、固定周期发布软件产品。每个迭代都是瀑布的工作流程，在迭代内部需求明确的情况下，差错较少。每个迭代在增量且制品可运行，能够及时交付并得到反馈。固定迭代周期有利于量化团队和个人的生产率。

简答题

用简短的语言给出对分析、设计的理解。

• 分析： 分析关注的是对问题和需求的调查研究，而不关注具体的解决方案。
• 设计： 设计关注的是对问题的解决方案，而不是具体实现。

用一句话描述面向对象的分析与设计的优势。

面向对象的分析与设计缩小了项目开发各部分沟通的鸿沟，便于后续工作的展开。

简述 UML（统一建模语言）的作用。考试考哪些图？

UML（统一建模语言）的作用： 将分析与设计的结果可视化，使用统一的建模语言便于程序员理解。

考试考的图：

• 用例图：用户角度：功能、执行者
• 静态图：系统静态结构
  • 类图：概念及关系
  • 对象图：某种状态或时间段内，系统中活跃的对象及其关系
  • 包图：描述系统的分解结构
• 行为图：系统的动态行为
  • 交互图：描述对象间的消息传递
    • 顺序图：强调对象间消息发送的时序
    • 合作图：强调对象间的动态协作关系
  • 状态图：对象的动态行为。状态-事件-状态迁移-响应动作
  • 活动图：描述系统为完成某功能而执行的操作序列
• 实现图：描述系统的组成和分布情况
  • 构件图：组成部件及其关系
  • 部署图：物理体系结构及与软件单元的对应关系

从软件本质的角度，解释软件范围（需求）控制的可行性

软件的本质决定了软件开发的困难，软件本身具有复杂性、不可见性、不一致性、可变性，因此软件范围在多数情况下对于客户和开发者都是模糊的，但是在保证需求的前提下，可以砍去一些客户都没思考清晰的业务，通过多次反馈和迭代进行开发和升级，使得软件的范围和需求受控。

项目管理实践

看板使用练习（提交看板执行结果贴图，建议使用 Git project）

• 使用截图工具（png格式输出），展现你团队的任务 Kanban
• 每个人的任务是明确的。必须一周后可以看到具体结果
• 每个人的任务是1-2项
• 至少包含一个团队活动任务

UML绘图工具练习（提交贴图，必须使用 UMLet）

UML和模式应用（第3版），第9页，图1-6

JVM的内存模型分为五个区域

PC寄存器

由于在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令。为了使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，用以记录当前执行到的指令。

Java栈

Java栈中存放的是一个个的栈帧，每个栈帧对应一个被调用的方法，栈帧中存放了：

1. 局部变量表
2. 操作数栈
3. 指向运行时常量池的引用
4. 方法返回地址
5. 一些额外的附加信息。

Java栈是线程私有的，当线程执行一个方法时，就会创建一个栈帧并压栈；当方法执行完毕之后，便会将栈帧出栈。

本地方法栈

本地方法栈与Java栈的作用和原理非常相似，区别在于Java栈是为执行Java方法服务的，而本地方法栈则是为执行本地方法服务的。

Java堆

Java堆是用来存储对象和数组。堆是被所有线程共享的，在JVM中只有一个堆。

方法区

方法区是被所有线程共享的，它存放了：

1. 每个类的信息（包括类的名称、方法信息、字段信息）
2. 静态变量
3. 运行时常量池（包括class文件中的常量池和运行时产生的常量）
   • class文件中的常量池包含了字面量和符号引用。字面量相当于Java语言的常量，如文本字符串，声明为final的常量等。符号引用包括类和接口的全限定名、字段名称和描述符、方法名称和描述符。
4. 编译器编译后的代码

JMM(Java内存模型)

JMM规定了所有的变量都存储在主内存（Main Memory）中。每个线程还有自己的工作内存（Working Memory），线程的工作内存中保存了该线程使用到的变量的主内存的副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程之间值的传递都需要通过主内存来完成。主内存包括Java堆、方法区；线程的工作内存包括Java栈、本地方法栈、PC寄存器。

软件工程的定义

软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

解释导致 software crisis 本质原因、表现，述说克服软件危机的方法

软件危机（software crisis）是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

本质原因

计算能力的提高已经超过了程序员有效利用这些能力的能力。

表现

软件危机其原因，衔接到硬件的整体复杂度，与软件开发流程。危机表现在几个方面：

1. 项目运行超出预算。
2. 项目运行超过时间。
3. 软件质量低落。
4. 软件通常不匹配需求。
5. 项目无法管理，且代码难以维护。

克服软件危机的方法

1. 正确认识计算机软件的内涵。
2. 采用工程项目管理方法实施软件开发的组织管理。软件开发应该是一种组织良好、管理严密、协同配合的工程活动。
3. 采用成熟的软件开发技术和方法，开发和使用适当的软件工具。

软件生命周期

计算机软件有一个孕育、诞生、成长、成熟、衰亡的生存过程，这样的过程称为软件的生命周期 (也称软件开发生命周期 SDLC)。软件生命周期将软件开发过程划分为若干阶段，每个阶段有明确的任务目标和运行机制，从而使复杂的软件开发过程能够得到适当的控制和管理。其生命周期包括：

1. 可行性分析与计划阶段
   • 确定软件开发的总体目标，给出功能、性能、可靠性以及接口等方面的要求，进行可行性分析。
   • 估计可利用的开发资源 (硬件、软件、人力等)、成本、效益、开发进度，进行投资-收益分析，制订开发计划。
   • 提交可行性分析报告、开发计划等文档。
2. 需求分析阶段
   • 分析用户提出的要求，给出用户需求详细定义，确定软件系统的各项功能、性能需求和设计约束，确定对文档编制的要求。
   • 提交软件需求说明、软件规格说明、数据要求说明等文档和初步的用户手册。
3. 设计阶段
   • 概要设计/逻辑设计：把各项软件需求转换成软件的体系结构。结构中的每一个组成部分意义明确，并和某些需求相对应。
   • 详细设计/物理设计：对按照概要设计分解的每个模块所要完成的工作进行具体的描述，提供源程序代码编写的直接依据。
   • 提交概要结构设计说明书、详细设计说明书和测试计划初稿等文档。
4. 实现阶段
   • 完成源程序的编码、编译 (或汇编) 和运行调试，得到没有语法错误的程序清单。程序结构良好、清晰易读，且与设计相一致。
   • 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
   • 编制测试计划。
   • 提交用户手册、操作手册等面向用户的文档。
5. 测试阶段
   • 全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所实现的程序、文档以及开发工作本身，提交项目开发总结报告。
6. 运行与维护阶段
   • 软件提交给用户后，在运行使用中得到持续维护，根据用户新提出的需求进行必要而且可能的扩充、删改、更新和升级。
   • 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环境变化) 和完善性维护 (增强功能)。

SWEBoK 的 15 个知识域（An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明）

软件工程实践相关的知识领域

1. 软件需求
   软件需求知识领域关注软件需求的启发，协商，分析，规范和验证。在软件行业中，人们普遍认为，当这些活动表现不佳时，软件工程项目非常容易受到攻击。软件需求表达了对软件产品的需求和限制，这些需求和约束有助于解决一些现实问题。
2. 软件设计
   定义系统或者组件的体系结构、组件、接口和其他特征的过程，以及这个过程所得到的结果。
3. 软件构建
   软件构建是指通过结合详细设计，编码，单元测试，集成测试，调试和验证来详细创建工作软件。
4. 软件测试
   测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。这些测试用例是从（通常非常大的）执行域中选择的。软件测试知识领域包括软件测试的基础知识; 测试技术; 人机界面测试与评估等。
5. 软件维护
   软件维护包括增强现有功能，调整软件以在新的和修改的操作环境中运行，以及纠正缺陷。这些类别称为完善，自适应和纠正性软件维护。软件维护知识领域包括软件维护的基础知识（维护的性质和需求，维护类别，维护成本）; 软件维护中的关键问题（技术问题，管理问题，维护成本估算，软件维护测量）; 维护过程; 软件维护技术（程序理解，重新设计，逆向工程，重构，软件退役）; 灾难恢复技术和软件维护工具。
6. 软件配置管理
   系统的配置是硬件，固件，软件或这些的组合的功能和/或物理特征。它还可以被视为根据特定构建过程组合的特定版本的硬件，固件或软件项的集合，以满足特定目的。因此，软件配置管理（SCM）是在不同时间点识别系统配置的规则，用于系统地控制配置的改变，以及在整个软件生命周期中维持配置的完整性和可追溯性。软件配置管理KA涵盖SCM过程的管理; 软件配置识别，控制，状态核算，审计; 软件发布管理和交付。
7. 软件工程管理
   软件工程管理涉及规划，协调，测量，报告和控制项目或程序，以确保软件的开发和维护是系统化的，规范化的和量化的。软件工程管理知识领域涵盖了启动和范围定义（确定和协商要求，可行性分析以及要求的审查和修订）; 软件项目计划（过程计划，工作量估算，成本和进度，资源分配，风险分析，质量计划）; 软件项目制定（计量，报告和控制;收购和供应商合同管理）; 产品验收; 审查和分析项目绩效; 项目结束等。
8. 软件工程过程
   软件工程知识领域关注软件生命周期过程的定义，实施，评估，测量，管理和改进。
9. 软件工程模型与方法
   软件工程模型和方法知识领域解决了涵盖多个生命周期阶段的方法。
10. 软件质量
    软件质量是许多SWEBOK V3 知识领域中普遍存在的软件生命周期问题。此外，软件质量知识领域还包括软件质量的基础知识（软件工程文化，软件质量特性，软件质量的价值和成本以及软件质量改进）; 软件质量管理流程（软件质量保证，验证和确认，审核和审核）; 和实际考虑（缺陷表征，软件质量测量和软件质量工具）。
11. 软件工程专业实践
    软件工程专业实践关注软件工程师必须具备的专业，负责和道德的软件工程知识，技能和态度。软件工程专业实践知识领域涵盖专业性（专业行为，专业协会，软件工程标准，雇佣合同和法律问题）; 道德准则; 小组动态（团队合作，认知问题复杂性，与利益相关者互动，处理不确定性和模糊性，处理多元文化环境）和沟通技巧。

软件工程教育要求相关的知识领域

1. 软件工程经济学
   软件工程经济学知识领域关注的是在业务环境中做出决策，以使技术决策与组织的业务目标保持一致。涵盖的主题包括软件工程经济学的基本原理（提案，现金流量，货币时间价值，计划视野，通货膨胀，折旧，替代和退休决策）; 非营利性决策（成本效益分析，优化分析）; 估计，经济风险和不确定性（估算技术，风险决策和不确定性）; 和多属性决策（价值和衡量尺度，补偿和非补偿技术）。
2. 计算基础
   计算基础知识领域涵盖了提供软件工程实践所需的计算背景的基础主题。涵盖的主题包括问题解决技术，抽象，算法和复杂性分析，编程基础，并行和分布式计算的基础知识，计算机组织，操作系统和网络通信的知识等。
3. 数学基础
   数学基础知识领域涵盖了提供软件工程实践所必需的数学背景的基础主题。涵盖的主题包括集合，关系和功能; 基本命题和谓词逻辑; 证明技术; 图论和树; 离散数学; 概率论; 语法和有限状态机; 数论。
4. 工程基础
   工程基础知识领域涵盖了提供软件工程实践所必需的工程背景的基础主题。涵盖的主题包括经验方法和实验技术; 统计分析; 测量和指标; 工程设计; 仿真与建模; 根本原因分析。

简单解释 CMMI 的五个级别

1. Level 1 - Initial：无序，自发生产模式。
2. Level 2 - Managed: 管理，对整个开发生产流程有监测与控制。
3. Level 3 - Defined: 定义，管理体系在不同类的项目上一样能够得到成功的实施。
4. Level 4 - Q-Managed: 量化管理，对管理流程要做到量化与数字化，实现控制管理的精度。
5. Level 5 - Optimizing: 优化，利用信息资料，能够主动地改善流程，运用新技术，优化流程。

用自己语言简述 SWEBok 或 CMMI

CMMI是能力成熟度模型集成，CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。CMMI里面所有的要求，都是来自于成功企业的最佳实践。CMMI有两种表述方式：连续式与阶段式。阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别，帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路；而连续式表现方法则通过将CMMI中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

Linked List Cycle II

题目描述

Given a linked list, return the node where the cycle begins. If there is no cycle, return null.
To represent a cycle in the given linked list, we use an integer pos which represents the position (0-indexed) in the linked list where tail connects to. If pos is -1, then there is no cycle in the linked list.

Note:
Do not modify the linked list.

Example 1:

Input: head = [3,2,0,-4], pos = 1
Output: tail connects to node index 1
Explanation: There is a cycle in the linked list, where tail connects to the second node.

Example 2:

Input: head = [1,2], pos = 0
Output: tail connects to node index 0
Explanation: There is a cycle in the linked list, where tail connects to the first node.

Example 3:

Input: head = [1], pos = -1
Output: no cycle
Explanation: There is no cycle in the linked list.

解题思路

本题要在一个有环的链表中找环的入口点。
链表寻环最常见的解法就是使用竞速法，用一对快慢指针去遍历链表，如果链表中有环，那么快指针必定会从慢指针后面追上慢指针。本题还要求环的入口点，假设环入口距离链表头的长度为L，环的长度为R，快慢指针相遇的位置为cross，且该位置距离环入口的长度为S。考虑快慢指针移动的距离，慢指针走了L+S，快指针走了L+S+nR(假设相遇之前快指针已经绕环n圈)。由于快指针的速度是慢指针的两倍，那么快指针走的距离也是慢指针的两倍，所以有2(L+S)=L+S+nR，化简得L+S=nR，即L=nR-S=(n-1)R+R-S，此时我们可以用两个指针，一个从链表头开始走，一个从快慢指针相遇点开始走，那么第一个节点走L距离到达环的入口点，第二个节点走（n-1）个环（回到原点）之后，再往前走R-S的距离（即走到环入口点的距离）。所以此时两个节点走了相同的距离并在环的入口点相遇。

源代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

/**
 * Definition for singly-linked list.
 * struct ListNode {
 *     int val;
 *     ListNode *next;
 *     ListNode(int x) : val(x), next(NULL) {}
 * };
 */
class Solution {
public:
    ListNode *detectCycle(ListNode *head) {
        ListNode* slow = head;
        ListNode* fast = head;
        while(fast != NULL && fast->next != NULL) {
            slow = slow->next;
            fast = fast->next->next;
            if(slow == fast) break;
        }
        if(fast == NULL || fast->next == NULL) {
            return NULL;
        }
        ListNode* p1 = head;
        ListNode* p2 = slow;
        while(p1 != p2) {
            p1 = p1->next;
            p2 = p2->next;
        }
        return p1;
    }
};