【软件工程】

软件工程

  • 1.初识软件工程
    • 1.1 软件的本质特性
    • 1.2 软件工程历史
    • 1.3 软件工程基本概念
    • 1.4 软件质量实现
    • 1.5 软件开发方法
  • 2. 编写高质量代码
    • 2.1 编码过程与规范
    • 2.2 良好的编程实践
      • 模块化设计
    • 2.3 代码静态检查
    • 2.4 代码性能分析
    • 2.5 结对编程
  • 3. 单元测试
    • 3.1 单元测试概述
    • 3.2 黑盒测试方法
    • 3.3 白盒测试方法
  • 4. 软件开发过程
    • 4.1 软件过程
    • 4.2 软件过程模型
      • 瀑布模型
      • 原型化模型
      • 迭代式开发
      • 可转换模型
    • 4.3 敏捷开发过程
  • 5. 团队开发管理
    • 5.1 团队组织与管理
    • 5.2 项目沟通管理
    • 5.3 软件项目计划
    • 5.4 软件项目估算
  • 6. Scrum
    • 6.1 Scrum概述
      • 角色
      • 制品
      • 活动
    • 6.2 用户故事与估算
      • 用户故事
      • 敏捷估算
    • 6.3 团队协作工具Tower
  • 7. 需求获取
    • 7.1 需求工程师
    • 7.2 需求定义
      • 问题划分(重点)
    • 7.3 需求的类型
    • 7.4 需求工程过程
    • 7.6 需求获取技术
    • 7.7 撰写需求文档
  • 经验理论
  • 8. 用例建模
    • 8.1 情境需求的需求方法——用例建模
  • 拓展阅读笔记
    • 1. 用例

学堂在线地址

1.初识软件工程

1.1 软件的本质特性

定义

程序:计算机可以接受的一系列指令,运行时可以提供所要求的功能和性能。 数据:使得程序能够适当地操作信息的数据结构。
:描述程序的研制过程、方法和使用的图文资料

软件文档非常的重要,然而初学者往往不重视。

本质特性

  1. 复杂性
  2. 一致性
  3. 可变性
  4. 不可见性
  • 复杂性
  • 一致性
    1. 软件必须依附一定的运行环境
    2. 软件必须遵循一定的惯例并适应已有的技术和系统
    3. 软件需要随接口不同而改变,随时间推移而变化
  • 可变性
    1. 软件能够随着版本更新不断变化
  • 软件工程过程:从用户需求 –> 软件开发活动 —> 用户满意的产品

      1. UDDI:是一种用于描述、发现、集成Web Service的技术(规范),它是Web Service协议栈的一个重要部分。通过UDDI,企业可以根据自己的需要动态查找并使用Web服务,也可以将自己的Web服务动态地发布到UDDI注册中心,供其他用户使用。
      2. SOAP:简单对象访问协议是交换数据的一种协议规范,是一种轻量的、简单的、基于XML(标准通用标记语言下的一个子集)的协议,它被设计成在WEB上交换结构化的和固化的信息。
      3. WSDL:Web服务描述语言,Web Services Description Language,是为描述Web服务发布的XML格式。
      • 软件工程工具

      1.4 软件质量实现

      软件质量可分为,,

      正确的软件:为用户创建利润、减少成本
      软件运行正确:没有或很少缺陷、可扩展、高性能、高易用

      软件质量模型(ISO9126)

      软件质量不是被测量出来的,而是在开发过程中出来的;
      但未经测试的也不可能开发出高质量软件;
      开发过程的,开发过程不可或缺的。

      软件的质量并非越高越好,绝大部分都是商用,应当平衡好、、之间的关系。

      1.5 软件开发方法

      结构化方法:
      自顶向下、逐步求精;模块化;图形化;结构化分析;面向过程,专注结构;

      面向对象方法:
      一切皆对象,将数据和数据操作封装为对象,整个系统是一个对象的集合。
      使用UML建模

      函数式程序设计:
      命令式编程:根据计算机的执行步骤来编写“命令”
      声明式编程:告诉计算机应该做什么,但不指明如何去做。(如SQL)
      函数式编程:

      • 不可变量:变量只是容器,x=x+1这种操作就是错误的(从数学的角度去看)
      • 纯函数:跟数学的函数一样,函数值(结果)只依赖于参数,而不被外部变量影响(不存在全局变量的说法,只能使用输入的参数),只要输入参数固定,无论外部如何变化,输出总是固定的。
      • 惰性计算
      • 无状态(宗旨)

      面向构件的程序设计:
      就是面向组件,以组件为单位的编程

      面向服务的程序设计:
      以“功能”(服务)为单元,使用统一的规范接口访问服务。以服务为单位进行编程。

      2. 编写高质量代码

      2.1 编码过程与规范

      软件编程是一个复杂而迭代的过程,它不仅仅是,还应该包括、、、等一系列工作。

      2.3 代码静态检查

      代码审查(Code Review)是一种用来确认方案设计和代码实现的质量保证机制,它通过阅读代码来检查源代码与编码规范的符合性以及代码的质量。

      代码审查的作用

      • 检查设计的合理性
      • 互为 Backup (备份)
      • 分享知识、设计、技术
      • 增加代码可读性
      • 处理代码中的“地雷区”

      缺陷检查表

      2.4 代码性能分析

      一些准则:

      1. 满足正确性、可靠性、健壮性、
      2. 全局效率为主,局部效率为辅
      3. 优化效率时,应当先找出限制效率的瓶颈
      4. 时间和空间效率往往对立,先明确优化目标
      5. 从一开始就应该考虑程序性能,而不是等到开发结束后进行调整
      6. 认真选择测试数据
      7. 永远不要再没有进行前后性能评估的时候就尝试优化
      8. 掌握不同内置结构的迭代操作速度
      9. 从算法入手

      常见算法时间复杂度:
      O(1) ==> O(lg n) ==> O(n lg n) ==> O(n^2) ==> O(n^3) ==> O(n^k) ==> O(k^n) ==> O(n!)

      2.5 结对编程

      结对编程是由两名程序员在同一台电脑上结对编写解决同一问题的代码

      结对编程不仅意味着编程活动,也包括分析、设计、测试等全程活动。
      结对编程有助于按时完成项目,并且保证高质量的代码。

      类似模型:

      结对编程的基础是会话和讨论, 不是一个人自得其乐。
      是核实伙伴交流程度的 一个考核标准。

      • 不要连续工作超过1个小时,每1个小时休息10分钟
      • 给同伴一点时间去发现和找到错误,别让他觉得你很烦
      • 常用的资料和规范(可以打印出来)以及书籍等应该放在手边
      • 结对开始之前要协调沟通,彼此互相通告希望对方关注些什么, 自己喜欢做什么
      • 主动参与,任何一个任务都是共同的责任,只有“我们的代码
      • 坚持代码标准和流程规范 注意听取伙伴的意见

      下面的一些情况不适合结对编程:

      • 处于探索阶段的项目
      • 后期维护的技术含量不高
      • 验证测试需要运行很长时间
      • 团队的人员要在多个项目中工作
      • 领航的用处不大

      另外,也不是所有的人都适合结对编程。

      3. 单元测试

      3.1 单元测试概述

      现实的开发问题:
      经常把单元测试任务堆积到系统测试阶段,导致:

      • 大量故障堆积在项目中后期,项目后10% 的工作占用了项目 90%的时间。
      • 3.2 黑盒测试方法

        良好的测试用例能够降低软件测试成本,保证测试工作质量,评估和检验测试效果。

        测试用例的概念

        • 具有代表性和典型性
        • 寻求系统设计和功能设计的弱点
        • 既有正确输入也有错误或异常输入
        • 考虑用户实际的诸多使用场景

        控制流图就是简化版的流程图,他的每一个节点,都是一段过程,简化方法:将顺序计算的所有语句合并为一个矩阵、将判断语句放入棱形,并引出真假分支、将判断结束后的汇聚点作为合并节点。

        如下:

        基于控制流的测试流程

        计算环路复杂度的三种方法:

        1. 一个环为一个区域,加上最外层整体区域
        2. 边数-节点数+2
        3. 判断节点数+1

        如:

        基本路径测试

        过程方法:系统地识别和管理组织内所使用的过程,保证更有效地获得期望的结果。

      • 问题定义:人们通过开展技术探索和市场调查等活动,研究系统的可行性和可能的解决方案,确定待开发系统的总体目标和范围。
        问题提出 可行性研究 可行性分析 告

      • 需求开发:在可行性研究之后,分析、整理和提炼所收集到的用户需求,建立完整的 需求分析模型,编写软件需求规格说明。

      • 软件构造:概括地说是将软件设计转换成程序代码,这是一个复杂而迭代的过程,要求 根据设计模型进行程序设计以及正确而高效地编写和测试代码。

      • 软件维护:系统投入使用后对其进行改进,以适应不断变化的需求。完全从头开发的 系统很少,将软件系统的开发和维护看成是一个连续过程更有意义。

      • 瀑布模型

        开发阶段严格按照线性方式进行,每一个阶段具有相关的里程碑和交付产品,且需要确认和验证。

        以预测性为原则
        以文档驱动开发过程
        以过程控制为核心

        原型化模型

        解决需求不确定;
        通过迅速构建一个软件原型(可理解为提供部分功能的、给用户的操作界面),通过原型的“模拟使用”,迅速确定需求或设计。
        原型可以是可运行软件(慢),也可以是图纸(快,更易修改)

        4.3 敏捷开发过程

        软件开发是一个逐步认知和明晰的活动;
        软件开发中的变化是实际存在和必然的;

        软件开发应更关注于交付的价值
        高质量的交付物是最重要的
        系统不是一次构建而成,而是迭代演进的
        基于完整的场景构建计划,并按优先级执行

        如今的互联 时代:
        快鱼吃慢鱼
        版本发布成本很低
        追求创新
        需要快速响应用户的变化
        需求不确定性高
        关注用户行为

        敏捷开发是一种基于更紧密的团队协作、能够有效 应对快速变化需求、快速交付高质量软件的迭代和 增量的新型软件开发方法。

        更关注协作
        更关注质量
        更关注可工作的产品
        更关注全才化的专才
        基于实践而非基于理论

        由于,,而敏捷开发的特点,就是。

        声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年1月20日
下一篇 2020年1月21日

相关推荐