目录

• 一、软件及软件工程
• • 1. 软件的本质
  • 2. 软件危机
  • 3. 软件工程定义
  • 4. 软件生命周期
• 二、软件过程及过程模型
• • 1. 软件过程
  • 2. 软件过程模型
  • 3. 通用过程模型
  • 4. 过程流
  • 5. 过程模型
  • • 5.1 瀑布模型
    • 5.2 原型开发模型（快速原型）
    • 5.3 增量模型
    • 5.4 螺旋模型
    • 5.5 专用过程模型
    • 5.6 形式化方法模型
• 三、敏捷开发
• • 敏捷开发
  • 敏捷原则
  • 敏捷过程
  • 极限编程XP
  • Scrum
• 四、软件需求
• • 软件需求
  • 需求工程
  • 需求获取技术
• 五、需求建模
• • 需求建模概述
  • 基于场景的建模
  • 基于数据流的建模
  • 基于数据的建模
  • 面向状态的建模方法
• 六、软件设计
• 七、软件测试
• 八、软件项目管理

一、软件及软件工程

1. 软件的本质

计算机软件 指计算机系统中的程序、数据及其相关文档

三要素：

程序：按照特定顺序组织的计算机数据和指令的集合。

数据：使程序能正常执行的数据结构

文档：为了便于理解程序所需的与开发、维护和使用有关的资料

软件 = 程序 + 文档 + 数据

软件的特点

• 软件是设计开发的，而不是传统意义上生产制造的。

• 软件不会“磨损”，但会退化。

• 大多数软件还是用户定制的。

计算机软件可分为七个大类：

• 系统软件
• 应用软件
• 工程/科学软件
• 嵌入式软件
• 人工智能软件
• 产品线软件
• WebApp
• 移动App

另一种分类

• 系统软件：
  位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。

• 支持软件：
  支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。

• 应用软件：
  特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。

2. 软件危机

软件危机(Software Crisis)：计算机软件的开发和维护过程所遇到的一系列严重问题。

软件危机的表现：

• 对软件开发成本和进度的估算很不准确，甚至严重拖期和超出预算；
• 无法满足用户需求，导致用户很不满意；
• 质量很不可靠，经常失效；
• 难以更改、调试和增强；
• 没有适当的文档；
• 软件成本比重上升；
• 软件开发生产率跟不上计算机应用迅速深入的趋势。

软件为什么要更新和迭代/strong>

• 软件必须适应新的计算环境或技术的需要。
• 必须增强软件来实现新的业务需求。
• 软件必须扩展到与其他更现代的系统或数据库进行互操作。
• 必须重新构建软件，使其在网络环境中可行。

为什么会产生软件危机/strong>

• 与软件本身的特点有关 (难于维护, 逻辑复杂)
• 与软件开发与维护的方法不正确有关

3. 软件工程定义

1993年IEEE进一步给出了一个更全面更具体的定义：

软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究

《计算机科学技术百科全书》中的定义：

软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等。

软件工程的内容

• 软件工程是一种层次化的技术。任何工程方法必须构建在质量承诺的基础上。
• 软件工程的基础是过程。软件过程将各个技术层次结合在一起，使得合理及时地开发计算机软件成为可能。
• 软件工程方法为构建软件提供技术上的解决方法。
• 软件工程工具为过程和方法提供自动化或半自动化的支持。
  

  4. 软件生命周期

  软件生命周期， 又称为软件生存周期，是软件从产生直到报废的整个时期。

  

  4. 过程流

  
  瀑布模型的变体–V模型
  
  原型开发的优点

  • 快速开发出可以演示的系统，方便了客户沟通。

  • 采用迭代技术能够使开发者逐步弄清客户的需求。

  原型的使用策略：

  • 废弃（throw away）策略
    主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统

  • 追加（add on）策略
    主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统

  原型模型— 适用情况

  • 用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；

  • 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；

  5.3 增量模型

  • 增量模型以迭代的方式运用瀑布模型。

  • 随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

  

  螺旋模型的优点

  • 结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。

  • 采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。

  • 确定一系列里程碑，确保各方都得到可行的系统解决方案。

  • 始终保持可操作性，直到软件生命周期的结束。

  • 风险驱动。

  螺旋模型存在的问题

  • 螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。

  • 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

  5.5 专用过程模型

  • 基于构件的开发 — 能够使软件复用

  • 形式化方法模型 — 注重需求的数学规格说明

  • 面向方面的软件开发 — 为定义、说明、设计和构建方面提供过程和方法

  • 统一过程 — 一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合

  基于构件的开发

  是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段（集成）高效率、高质量地构造应用软件系统的过程。

  

  业务需求

  业务需求(business requirement)反映了组织机构或客户对系统、产品高层次的目标要求

  用户需求

  用户需求(user requirement)描述了用户使用产品必须要完成的任务。

  功能需求

  系统分析员描述 开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
  功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些用户需求（how），其数量往往比用户需求高一个数量级。

  • 功能需求：描述系统预期提供的功能或服务

  • 非功能需求：不直接与系统具体功能相关的需求。

  需求工程

  应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
  它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

  需求工程的基本活动

  获取需求
  细化(需求分析)
  协商
  编写需求规格说明
  确认需求
  需求管理

  需求分析的目的:

  • 说明软件的工作特征
  • 指明软件和其他系统元素的接口
    规定软件必须满足的约束

  需求分析的主要任务：

  • 细化在前期需求工程的基础需求
  • 构建一种或多种模型以描述用户场景、功能活动、类、类之间的关系、系统和类的行为、数据流等

  需求获取技术

  面谈
  调查
  观察实际业务过程
  原型法
  头脑风暴
  场景技术

  五、需求建模

  需求建模的元素

  • 场景模型
    出自各种系统“参与者”观点的需求

  • 数据模型
    描述问题信息域的模型(用于建立数据库)

  • 类模型
    表示面向对象类（属性和操作）的模型

  • 数据流模型
    描述功能元素在系统中运行时怎样进行数据变换

  • 行为模型
    描述系统的外部行为

  需求建模概述

  需求建模的总体目标:

  • 描述客户需要什么；
  • 为软件设计奠定基础；
  • 定义在软件完成后可以被确认的一组需求。

  基于场景的建模

  用例：

  用于表示系统所提供的服务，描述参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话（交互）。

  场景：

  场景是用例的实例化，从一个用例可以实例化出来多个用例场景。用例就是对全部场景的抽象。

  基于数据流的建模

  结构化方法概述

  一种面向数据流的传统软件开发方法，以数据流为中心构建软件的分析模型和设计模型

  分为：

  • 结构化分析(Structured Analysis 简称SA)

  • 结构化设计(Structuresd Design 简称SD)

  • 结构化程序设计(Structured Programmin 简称SP)

  结构化的需求分析模型：

  • 功能模型（数据流模型），用来描述系统中的数据处理过程

  • 行为模型（状态转换模型），用来描述系统如何对事件做出响应

  • 数据模型（实体—关系模型）：用来描述系统中的数据及其之间的关系。

  数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述

  数据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。

  
  数据流图举例

  设一个工厂采购部每天需要一张定货报表。定货的零件数据有：零件编号、名称、数量、价格、供应者等。零件的入库、出库事务由仓库管理员通过计算机终端输入给定货系统。当某零件的库存数少于给定的库存量临界值时，就应该再次定货。
  数据流分析：
  数据源点：仓管员（负责入库或出库事务给定货系统）；
  数据终点：采购员（接收每天的定货报表）；
  数据流：事务，定货报表；
  数据存储：定货信息，库存清单；

  
  考务处理系统1层图

  根据功能需求对功能进行分解：考务处理系统可分解为两部分
  一、考试报名
  1．对考生送来的报名单进行检查
  2．对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站
  （需要增加存储：考生名册）
  二、统计成绩
  3．对阅卷站送来的成绩清单进行检查，并根据考试中心制订的合格标准审定合格者
  4．制作考生通知单送给考生
  5．进行成绩分类统计(按地区、年龄、文化程度、职业、考试级别等分类)和试题难度分析，产生统计分析表

  繁凡的小岛来信 微信公众号 深度学习小菜鸡退役ACMer，希望和你一起成长

  来源：繁凡さん

  声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！