概述

软件 程序+数据+文档
软件危机的表现 1. 对软件的开发成本和进度的估计不准确 2. 用户对已完成的系统不满意 3. 软件质量不可靠 4. 软件可维护性差 5. 缺乏文档资料 6. 软件成本上升 7. 生产速率跟不上计算机应用普及的趋势
软件危机的原因 1. 软件自身特点使得开发和维护困难 2. 软件开发维护方法不正确 1. 没有科学的工程化思想来阻止和指导开发 2. 没有完善的质量保证体系 3. 软件文档没有得到重视 4. 从业人员缺乏经验
软件工程的定义 软件工程是知道计算机软件开发和维护的一门学科,采用工程的概念原理技术和方法来开发与维护软件,把进过时间考验而证明正确的管理技术和当前能够的到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它。
软件工程的本质特征 1. 关注于大型程序的构造 2. 中心课题是控制复杂性 3. 软件经常变化 4. 开发效率非常重要 5. 和谐开发是关键 6. 必须有效地支持用户 7. 开发者与用户的文化背景不同
软件工程的目标 1. 控制成本 2. 使软件满足用户需求 3. 提高质量 4. 提高可靠性 5. 便于维护、移植、使用 6. 控制开发周期
软件工程的基本原理 1. 用分阶段的生命周期计划严格管理 2. 坚持阶段评审 3. 实行严格的产品控制 4. 采用现代程序设计技术 5. 结果应能清楚地进行审查 6. 开发小组应少而精 7. 承认不断改进软件工程实践的必要性
软件工程要素 1. 方法:软件开发如何做? 2. 工具:为软件工程方法提供的软件支撑工具 3. 标准:软件工程实施过程中一系列统一的约束和规定 4. 过程:用于开发、管理、维护软件的一系列活动,是将软件工程的标准、方法、工具综合起来以达到合理及时进行软件开发管理维护活动的序列
软件开发三个阶段 1. 定义阶段 2. 开发阶段 3. 维护阶段
软件生命周期 6步 1. 可行性研究 2. 需求分析 3. 软件设计 4. 编码 5. 软件测试 6. 软件维护

软件开发模型

瀑布模型

各阶段间的组织方式就如同瀑布流水一样,逐级下落,完成前一阶段任务后才可开始下一阶段工作

特点:

  1. 回溯性差,修复错误成本高
  2. 基于里程碑的阶段过程,开发人员为每个阶段设立里程碑,并做好评审
  3. 强调阶段性,每个阶段完成特定任务

优点:

  • 过程模型简单

缺点:

  • 无法适应变更

快速原型模型

快速建立起能反映用户需求的程序,让用户试用,以了解目标系统概貌,并按照客户要求快速修改原型系统,不断重复。

优点:

  • 简单快速

缺点:

  • 需要花费额外成本构造原型
  • 不利于创新

增量模型

增量模型是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。是一个递增的过程,分批次交付软件

优点:

  • 模块化可分批次交付,便于客户了解进展
  • 模块化降低开发风险,一个周期内的错误不会影响整个系统
  • 开发顺序灵活

螺旋模型

用于风险较大的大型软件项目开发过程,可以看成是增加了风险分析过程的快速原型模型

喷泉模型

一种过程模型,支持面向对象,由于面向对象经常需要迭代,喷泉模型可随时回到底层

敏捷模型

敏捷方法是一种轻量级的软件工程方法,相对于传统的软件工程方法,它更强调软件开发过程中各种变化的必然性,通过团队成员间充分的交流和沟通以及合理的机制来有效地响应变化。

敏捷软件开发宣言:

  1. 个体和交互胜过过程和工具
  2. 可以工作的软件胜过面面俱到的文档
  3. 客户合作胜过合同谈判
  4. 响应变化胜过遵循计划

习题

可行性研究

可行性研究的目的 用最小的代价在尽可能短的时间内确定问题是否能够并且值得解决
可行性研究的根本任务 对以后的行动方针提出建议

可行性研究的三个组成:

  1. 技术可行性 现有技术能否实现
  2. 经济可行性 经济效益能否超过开发成本
  3. 操作可行性 系统的操作方式在用户组织内行的通吗
    此外还应在法律、社会、管理等其他方面分析

可行性研究的过程

  1. 复查系统规模和目标
  2. 研究目前正在使用的系统
  3. 导出新系统的高层逻辑模型
  4. 进一步定义问题
  5. 导出评价共选择的方案
  6. 推荐行动方针
  7. 草拟开发计划
  8. 书写文档提交审查

系统流程图

是概括描述物理系统的传统工具,表达数据在系统各部件之间流动的情况

用于分析现有系统!!!

复杂系统时应该分层画

数据流图

数据流图描绘系统的逻辑模型,无具体的物理元素,值描绘信息在系统中流动处理的情况

成本效益分析

成本估计

代码行技术

根据经验和历史数据,估算实现一个功能需要多少源程序行数,用每行代码的平均成本乘以行数。

任务分解技术

将软件开发工程分解成若干个相对独立的任务,分别估算,累加得到总成本

开发成本估计技术

需要软件和数据的支撑

习题

需求分析

软件需求指用户对所开发的软件在功能、性能、环境、可靠性等各方面的要求。

需求分析的任务

  1. 确定对系统的综合要求
  2. 分析系统的数据要求
  3. 导出系统的逻辑模型
  4. 修正系统开发计划

确定对系统的综合要求

  1. 功能需求
  2. 性能需求
  3. 可靠性和可用性需求,定量
  4. 出错处理需求
  5. 接口需求
  6. 约束 如精度、工具、语言、设计、标准、硬件平台
  7. 逆向需求:系统不应该怎么样
  8. 未来可能的要求

分析系统的数据要求

ER图

三大范式
  1. 第一范式是指每个属性值都是原子性的,不可再分
  2. 非码属性必须完全依赖于全部的主码属性 消除部分函数依赖
  3. 一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述,即非主码属性不依赖于其他非主属性,消除传递以来

范式低,冗余大,范式高,分解得细,冗余小,但处理过程复杂。

参考文章:数据库设计的三大范式怎么通俗理解?

导出系统的逻辑模型

工具:

  1. 数据流图
  2. 实体联系图
  3. 状态转换图
  4. 数据字典
  5. 主要的处理算法

状态转换图(STD)

状态转换图是一种常用的动态分析方法。是描述系统的状态如何响应外部信号,而进行转换的一种图形表示。

状态

指任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式。

  1. 初态,只有一个 实心圆表示
  2. 中间态 圆角矩阵
  3. 终态 可多个 同心圆(内圆为实心)
事件

某个特定时刻发生的事情,它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事情的抽象。

例图

图书状态图

客房状态图

IPO图

验证软件需求

  1. 一致性,需求间不能存在冲突
    1. 自然语言书写的只能人工验证
    2. 形式化语言定义的可以借助工具完成
  2. 完整性:需求是完整的,需要用户参与合作,可以借助快速原型方法完成
  3. 现实性:参考类似系统,分析现有条件实现的可能性,必要时可借助仿真模拟等技术
  4. 有效性:需要合作

与用户沟通方式

  1. 访谈
  2. 面向数据流自顶向下求精
    • 详细的数据流图
    • 数据字典
    • ER图
    • IPO图
  3. 简易的应用规格说明技术 (实现用户看得见的功能,省略目标系统“隐含”功能)
  4. 快速建立软件原型

习题

总体设计

软件设计的任务

以软件需求规格说明书为依据,着手实现软件的需求,并将设计的结果反应在“设计规格说明书”的文档中

总体设计(概要设计)

根据软件需求,设计软件系统结构和数据结构确定程序的组成模块之间的关系,从抽象的层次上分析对比多种可能的系统实现方案和软件结构,从中选取最佳方案和最合理的软件结构,从而用较低成本开发出高质量的软件系统

详细设计(过程设计)

确定模块内部的算法和数据结构,选定某种过程的表达形式来描述算法,生成详细文档

设计过程

  1. 提供选择方案
    1. 从需求阶段的数据流图出发
  2. 选取合理方案
    1. 系统流程图
    2. 组成系统的物理元素清单
    3. 成本效益分析
    4. 实现系统的进度计划
  3. 推荐最佳方案
  4. 功能分解
  5. 设计软件结构
  6. 设计数据库
  7. 制定测试计划
  8. 书写文档
    1. 系统说明
    2. 用户手册
    3. 测试计划
    4. 详细的实现计划
    5. 数据库设计结果
  9. 审查和复审

设计原理

模块化

什么是模块?

模块是数据说明和可执行语句等程序对象的集合,每个模块单独命名并且可以通过名字对模块进行访问

模块化思想

采用自顶向下的方式,逐层把软件系统划分成若干个可单独命名和可编址的模块,每个模块完成一个特定的子功能,所有模块按照某种方法组成一个整体,完成整个系统所要求的的功能。

模块化的优点
  1. 降低软件复杂性
  2. 减少开发工作量
  3. 降低成本
  4. 提高软件生产率
模块化与软件成本的关系

并非模块越多越好!

抽象

什么是抽象?

认识复杂事物和现象时,抽出事物本质的共同特性而暂不考虑他们的细节

逐步求精

为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。可以看做把一个时期内必须解决的问题按照优先级排序的技术,是一种自顶向下的设计策略

miller原则

一个人在任何时候都只能把注意力集中在5-9个知识块上

信息隐藏和局部化

在设计和确定模块时,使得一个模块内包含的信息(过程或数据),不允许其它不需要这些信息的模块访问,独立的模块间仅仅交换为完成系统功能而必项交换的信息。

局部化:将一些关系密切的软件元素物理地彼此靠近:如局部变量

模块独立(低耦合,高内聚)

模块只完成系统要求的相对独立的功能,符合信息隐蔽原则,模块间关联和依赖程度尽量小

优点

容易开发测试和维护

两个原则

低耦合、高内聚

详见另一篇博客:耦合与内聚

启发规则

  1. 改进软件结构提高模块独立性
  2. 模块规模应该适中
  3. 深度、宽度、扇出、扇入应适当
  4. 模块的作用域应在控制域之内
  5. 力争降低模块接口的复杂程度
  6. 设计单入口单出口的模块
  7. 模块功能应该可以预测