学堂在线_软件工程 专业基础知识点 笔记

  • 基本概念:

    • 软件工程诞生:1968年北大西洋公约组织召开国际会议,提出软件工程的概念和术语。
    • 软件的定义:程序 + 数据 + 文档。
    • 软件的本质特性:复杂性、一致性、可变性、不可见性。
    • 软件工程定义:将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护,即将工程化应用于软件,及对上述方法的研究。
    • 软件工程的基本要素:过程、方法、工具;
    • 软件开发的基本策略:软件复用(已有构建组装)、分而治之(复杂问题分解)、逐步演进(增量或迭代)、优化折中(整体质量最优);
    • 软件质量:用户角度,关注功能质量;开发角度,关注结构质量;投资者角度,关注过程质量;
    • 软件过程:包括问题定义、需求开发、软件设计、软件构造、软件测试,软件项目管理和软件配置管理。
  • 常见软件过程模型:瀑布、原型化、迭代式(有分块的增加增量模型和逐步完善的迭代模型)、可转换(适用于对安全性和可靠性要求极高的系统)等四种模型。

  • 敏捷开发方法中最具影响力的两种方法是:极限编程和Scrum小周期迭代。

  • 编程规范:

    • 注释,好的注释解释为什么,而不是是什么;注释不是代码的描述;修改代码同时修改周边注释。
    • 命名,好的名字见文知义;尽量编写自文档化代码;类名为驼峰风格(逐个字母连接且首字母大写),变量名为下划线风格(小写字母用下划线连接)。
    • 语句,应该删繁就简,避免奇技淫巧。
  • 高质量的设计:模块化设计、面向抽象编程、错误与异常处理。

  • 代码审查(code review):是确认方案设计与代码实现的质量保证机制,通过阅读代码来检查源代码与编码规范的符合性及代码质量。

  • 代码优化:是代码的等价变换,优化前后结果相同,效率(时间或空间)提升。优化步骤:找瓶颈(如用profile找出python代码中各函数的执行时间),先全局后局部,先数据结构和算法后代码。

  • 单元测试(Unit testing)是对软件中的最小可测试单元进行的检查和验证。指标,单元测试的测试通过率要求100%,代码覆盖率,用来度量测试完整性,了解测试是否充分及弱点。

    • 黑盒测试:是功能测试,不考虑内部结构和逻辑,只按需求说明,验证功能是否实现。
    • 白盒测试:是结构测试,根据程序内部逻辑,设计测试用例,对程序的逻辑路径也进行测试。
  • 开发团队的组织模式:民主式结构(团队成员平等协商)、主程序员式结构(以主程序员为主分工配合)、矩阵式结构(管理与技术分离)。

    Brooks法则:向一个进度延迟的软件项目中增加人员可能会使其进度更加推迟。

  • 项目沟通之前需要明确:与沟通的对象是什么关系类型?需要什么类型的信息?详尽程度和频率如何?沟通的目标是什么?采用哪种方式沟通为宜?

  • 项目估算:对时间和成本进行预算和估计的过程,有6种方法:专家判断、参数估计;功能点估计、用例点估算;结构性成本模型、机器学习方法。

  • Scrum框架中

    • 角色:product Owner(定义产品需求、发布计划、产品收益、定义需求优先级)、Scrum Manager(直接管理项目、组织每日站立会议、引导促进团队协作)、team(合作完成每次的Sprint开发工作);

    自组织团队是敏捷软件开发的基本概念,即团队被授权自己管理他们的工作过程和进度,并且决定如何完成工作。每日站立会议主题是三个问题:上次例会后完成了什么?遇到了什么困难?下次例会前计划做什么?

    • 制品:product backlog(从客户价值角度理解的产品功能列表)、Sprint backlog(从开发技术角度理解的迭代开发任务)、working software(是可交付的软件产品)、burndown charts(展示剩余工作量与时间的关系图);
    • 活动:Sprint planning / daily scrum Meeting / Sprint review / Sprint retrospective。
  • 用户故事与估算

    • 用户故事:(User Stroy)是从用户角度对功能的简要描述。有独立性、可协商、有价值、可估算、短小可测试的特点。
    • 故事点:是一个相对度量单位,用以结合开发者水平估计开发任务的耗时程度。(理想时间,是一个绝对度量单位,是剔除外围活动后的所需时间,通常为一天有效工作时间的60%-80%)。
    • 估算原则:开发团队一起估算,owner / manager 不参与实际估算。(敏捷估算扑克方法:分牌—>用户故事讲解—>估算—>争论与讨论—>共识)
  • 软件配置管理:对软件开发全周期进行标识、组织和控制修改的技术, 目的是为了使错误达到最小并有效地提高生产率。使软件开发过程完整、一致、可追溯。

    • 2种版本控制模式:独占工作模式(编辑时文件被锁定)、并行工作模式(同时复制,后提交者需要先checkout)
    • 常用工具:SVN / Git;
  • 需求工程师:

    • 需求管理的三个任务:学习以获取需求、剪枝以需求优选、文档化即撰写需求规格说明书。
    • 好的需求描述:
      • 单个需求项:concise / correct / Non-ambiguous / feasible / verifiable;
      • 整个需求集合:realistic / concise / complete / consistent。
    • 不好的需求描述:含糊、错误、不完整、矛盾或不一致、无法测试。
    • 需求分类:
      • 产品需求:功能性需求、非功能性需求(服务质量、依从性 { 描述软件对国家法律、国际公约、文化政治习俗、标准等环境约束的满足程度 } 、体系结构约束、设计开发约束)。
      • 抽象层次详细程度:业务需求(业务陈述,系统的业务目标)、用户需求(影响用户接受程度的需求)、系统需求(从用户角度描述功能)、软件需求(软件部分的需求,帮助实现系统需求)。
    • 需求规格说明(software requirements specification): 清楚地描述软件在什么情况下,需要做什么,不能做什么;以输入/输出及之间的转换方式来描述功能性需求;描述经干系人磋商达成共识的非功能性需求。一般要参考模板、具有一定法律效力,可作为后续软件评估的依据和变更的基准。
  • 用例建模(Use Case Modelling):情景驱动的建模方法,用例定义一个参与者要用到的系统功能、行为序列、交互活动,是从用户角度出发,完整的实现特定用户价值的事件流。

    • 构建用例模型的步骤
    • 寻找用例的方法
    • 用例建模过程
    • 用例建模工具:UML
  • 面向对象分析(object-oriented analysis, OOA):

    • 五个核心概念:对象、属性、结构、服务和主题。
    • 对象建模五大有力武器或原则:抽象(找出共性、忽略不相关细节)、分解(区分整体与部分关系)、多视角映射、模块化、模式。
    • 识别类的方法:使用CRC(class responsibility collaboration)分析法:根据类的职责确定类。分为边界类、控制类、实体类。
    • 抽象的接口:让用户知道关于类的内部实现细节越少越好。
    • 确定对象行为的原则:开闭原则(软件实体在扩展性方面开放、在更改性方面是封闭的)、LSP替换原则(子类可以替换父类出现在父类出现的任意地方)、依赖倒置原则(依赖关系应该尽量依赖接口,而不是具体的类)、接口分离原则(采用多个和特定客户类有关的接口,而不是采用通用接口)。
  • 顺序图-交互行为建模:

    • 顺序图:用来刻画系统实现某个功能的必要步骤;
    • 消息:用于描述对象间的交互操作和值传递过程;
    • 顺序图的构造

<---------------------------------------------------------------------------------------------------------------------->

当软件系统的规模和复杂性不断增加,对系统 的全局结构设计和规划变得比算法的选择和数据结构的设计,更为重要。

  • 软件体系结构 = 构件 + 连接件 + 约束;
    • 构件:可复用的软件结构单元,表示系统中主要的计算要素和数据存储。
    • 连接件:连接是构件之间建立和维护行为关联与信息的途径, 实现构件之间交互连接的专用构件,一般构件是软件功能设计和实现的载体。
    • 建立体系结构的目标:可重用、可扩展(易增功能)、可变化性(易变更功能)、简单化(复杂问题分块化简)、有效性(体现早期的设计决策)。
  • 软件设计原则:抽象(关注解决事物问题的部分,忽略无关部分的一种思考方法)、封装(各功能单元由外部可见接口描述)、模块化(在逻辑上和物理上将整个系统分解成多个更小部分)、层次化(分解为对等的模块单元)、复用(利用已有)。
    • 单元接口设计,应尽量降低对环境的假设和要求。
    • 模块化的模块分解原则:高内聚、低耦合。
    • 复用包括:源代码复用、软件体系结构复用、框架复用、设计模式。
  • 软件体系结构风格:描述特定系统组织方式的惯用范例,强调了软件系统中通用的组织结构。有以下几种:
    • 主程序-子程序:从功能的观点设计系统,通过逐步分解细化,形成整个系统的体系结构
    • 面向对象风格:系统被看做是对象的集合,每个对象有自己的功能集合,经封装再交互。
    • 管道-过滤器风格:把系统任务分成若干连续的处理步骤,由通过系统的数据流连接,一个步骤的输出是下一个步骤的输入。如:媒体播放器。
    • 以数据为中心风格(仓库体系结构):适用于数据由一个模块产生,多个模块使用的情况。eg:程序设计语言编译器、基于数据库的系统结构
    • 层次结构:如安卓系统、网络分层。
    • 客户机/服务器(C/S)体系结构:服务器负责为其他客户机提供服务,客户机作为子系统负责与用户交互。
    • 两层C/S结构:
      • 胖客户机模型:服务器只负责数据的管理,客户机实现应用逻辑和用户的交互。
      • 瘦客户端:客户端具有很少或没有业务逻辑。
    • 三层C/S结构:表示层(包括所有与客户机交互的边界对象)、功能层(实现业务逻辑)、数据层(实现对数据库的存储、查询和更新)。B/S结构,是三层c/s的一种实现方式。
    • 集群结构:集群内服务器内容一致,或集群服务器内容之和构成完整系统功能/数据。
    • MVC结构:将数据模型、业务逻辑、用户界面分别放在独立构件中,这样用户界面的修改不会对数据模型/业务逻辑造成太大影响。
    • 事件风格:将应用看成一个构建集合,每个构建直至发生对它有影响的事件时才使用。
  • 软件体系结构风格的选择:基于经验,考虑复合、技术因素、质量因素等。
  • 软件设计过程:
    • 系统总体设计 :在需求分析基础上定义系统的设计目标,划分子模块,建立体系结构,选择合适的设计策略;
  • 数据库选择策略:怎么存?怎么增删改查?操作是否安全?可用性(指故障恢复)?常用数据库特点:
    • Mysql :开源型关系数据库,大量第三方插件,支持快速复杂查询、较高安全性。查询并发量2000;
    • mongodb:模式自由,支持海量数据的查询和插入,修改方便;支持完全索引;大空间以索引,高级别安全性无法保证。查询并发量5000;
    • Redis:内存访问高效,也能持久化存储,字典模式存储;不适合安全性高的情景。
  • 软件设计 = 编码设计 + 交互设计(UI)基于人机交互的界面设计,更关注可用性。
    • GUI设计原则:可视化(分组、排序、对齐、装饰、留白)、一致性(有相似的操作、相似任务用相似的元素、目的是让界面更好去学习和使用)、直接映射(控制、动作、结果建立关联)、有效反馈。
    • KLM效率模型:
    • Fitts定律:
  • 软件测试(以改进software过程):正向思维,验证软件正常工作(check functions);逆向思维,假定软件有缺陷(find error)。
    • 测试局限性:不彻底、不完备、间接性。——>测试应尽早介入

    缺陷的集群性:软件错误具有聚集性,对存在错误的部分应重点测试。
    杀虫剂悖论:用同样的测试用例多次重复测试,最后将不能发现新的缺陷。——>要定期修改测试用例。

    • 软件测试类型:
      • 测试对象角度:单元测试、集成测试、系统测试、性能测试、验收测试、安装测试
      • 测试技术角度:黑盒测试(功能)、白盒测试(结构)
      • 程序执行角度:静态、动态测试
      • 人工干预角度:手工测试、自动化测试。
    • 软件测试计划:why、what、when、where、who、how;
      • 缺陷报告内容:基本描述(一句话描述清楚问题)、详细描述(基本环境、异常发生操作步骤、截图、日志或出错信息、测试人员角度的简单分析、被测软件基本信息、修改优先级、提交日期提交人等)、相关附件。
    • web应用功能测试:网页测试(内容、链接、表单、cookies)、网站测试(设计语言、数据库等测试、特定功能、兼容性)。
    • 软件性能测试:及时性、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性。
    • 性能测试策略:应用在客户端性能的测试(虚拟并发用户数渐增)、应用在网络性能的测试(网络带宽、延时、负载、TCP端口变化下的响应时间)、应用在服务器性能测试(关键点资源占用情况、数据库性能和故障报警、工具监控)。
  • 软件部署模式:面向单机(脚本编程实现安装和注册)、集中式服务器(用户访问量小500下)、集群式服务器(并发访问量大10000上,对系统稳定和性能要求高的分布式平台部署)。
  • 软件维护类型:改正型(修改缺陷或不足)、适应性(修改适应系统软硬件环境变化)、完善性(增删功能以适应业务变化)。

    维护成本:业务应用系统,维护费用与开发费用大体相当,嵌入式实时系统的维护费用是开发成本的四倍以上。

    • 软件再工程:重新构造或编写现有系统的部分或全部,不改变其功能。目的是使系统更易于维护,需要再构造和再文档化。
    • 逆向工程:是以复原软件的规格说明和设计为目标的软件分析过程。

你可能感兴趣的:(网课学习,计算机考试,软件工程)