软件工程笔记

 前面的话

        此博客为本人个人软件工程学习笔记。

        很认同老师说的博客很锻炼个人，希望我能借此机会一点点积累自己的博客。

---

第一章 初识软件工程

1.1软件无处不在

软件是软件工程的研究对象,也是软件工程的产品形态与客观存在。
工程是将理论和知识应用于实践的科学,其目的是经济有效地解决实际问题。

• 软件具有哪些本质的特性？
• 软件开发面临哪些主要的问题？
• 如何理解软件工程的基本概念和内涵？
• 软件开发应该遵循哪些工程化原则？
• 业内人士如何看待软件工程？
   

1.2软件的本质特征

1.2.1软件的定义

软件 = 程序 + 数据 + 文档

程序：计算机可以接受的一系列指令，运行时可以提供所要求的功能和性能。

数据：是的程序能够适当地操作信息的数据结构。

文档：描述程序的研制过程、方法和使用的图文资料。

软件具有负责性、一致性、可变性和不可见性等固有的内在特性

这是造成软件开发的根本原因

1.2.2 一致性

• 软件不能独立存在，需要依附于一定的环境（硬件、网络以及其他软件）
• 软件必须遵从人为的惯例并适应已有的技术和系统
• 软件需要随接口不同而改变，随时间推移而变化，而这些变化是不同人设计的结构

1.2.3 可变性

1.2.4不可见性：

• 软件是一种“看不见、摸不着”的逻辑实体，不具有空间的形体特征
• 开发人员可以直接看到程序代码，但是源代码并不是软件本身
• 软件是以机器代码的形式运行，但是开发人员无法看到源代码是如何执行的

 1.3软件工程的产生与发展

软件开发面临的挑战

软件工程致力于探索软件开发问题的解决之道

1.4软件工程的基本概念

工程：将理论和只是应用于实践的科学，以便经济有效地解决问题。

• 大规模的设计与制造
• 复杂问题与目标分解
• 院队协作与过程控制

 软件工程是

1. 将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上
2. 对1中方法的研究

• 较低的开发成本
• 按时完成开发任务并及时交付
• 实现客户要求的功能
• 具有良好性能、可靠性、可扩展性、可移植性...
• 软件维护费用低

 软件工程方法：

 软件工程工具

软件开发的基本策略 

 软件复用：

软件复用是利用将已有的软件制品，直接组装或者合理修改形成新的软件系统，从而提高开发效率和产品质量，降低维护成本。

 软件复用不仅仅是代码复用

• 库函数、类库
• 模板（文档、网页等）
• 设计模式
• 组件

分而治之

 软件工程师一项解决问题的工程活动，通过对问题进行研究分析，将一个复杂问题分解可以理解并能够处理的若干小问题，然后再逐个解决。

逐步演进

软件更像一个活着的植物，其生长是一个逐步有序的过程。软件开发应该遵循软件的客观规律，不断进行迭代式增量开发，最终交付符合客户价值的产品。 

优化折中 

软件工程师应当把优化当成一种责任，不断改进和提升软件质量；但是优化是一个多目标的最优决策，在不可能使所有目标都得到优化时，需要进行折中实现整体最优。 

1.6业内人士谈软件工程

标准的设计模式

         统一思想

        科学的管理方法

基本素质：

1.极强的代码阅读、理解和书写代码的能力

2.极强的责任心和敬畏心

3.有职业道德，对代码品质和秘密的保证

4.与他人的协同能力

第四章 软件开发过程

4.1软件开放过程

过程的定义

过程是一组将输入转化为输出的相互关联或相互作用的活动

 

过程方法 

软件开发活动 

 

 

 4.2软件过程模型

软件过程模型：对软件过程的抽象描述

软件开发的迭代性 

 瀑布模型

 原型化模型

 

 迭代式开发

 

 可转换模型

 

 

第八章 需求获取

8.1需求工程师

软件工程师：做出尽可能简化问题复杂度的假设

计算机科学家：找住不失一般性的解决方法

当代需求工程师应该具备的能力

1. 分析问题和解决问题的能力
2. 人际沟通及交流能力
3. 软件工程知识和技能
4. 应用领域有关知识
5. 书面语言组织和表达能力

8.2需求的定义

定义

• 需求是对外可见的系统特征
• 需求管理有三项任务：

1. 学习——需求获取
2. 剪枝——需求优选
3. 文档——撰写需求规格说明书

• 需求将作为系统开发，测试，验收，提交的正式文档依据
• 每一个“人造物”都是一个内部环境与外部环境的“接口”，对接口的描述即是需求

 需求的内容

•  为什么要设计该系统
• 系统由谁使用
• 系统要做什么
• 系统涉及哪些信息
• 对解决方案有何额外限制
• 如何使用该系统
• 质量需达到何种程度

将问题与解决方案分开

 什么是需求？

 存在问题的需求描述

 需求规约

 8.7撰写需求文档

8.7.1软件需求的规格说明

• 是具有一定法律效力地合同文档
• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
• 以输入/输出、输入到输出之间的转换方式来描述功能性需求
• 描述经过干系人磋商达成共识的非功能性需求
• 一般参考需求定义模板，覆盖标准模板中定义的所有条目
• 作为后续的软件评估依据和变更的基准

8.7.2 需求文档SRS的组织形式

 8.7.3软件需求规格说明SRS的风格

• 描述性的自然语言文本
• 从用例模型产生
• 从需求数据库中生成
• 从混合模型产生

 生成不同风格SRS的方法总览

 用户手册作为SRS

 用户手册大纲

• 介绍（总览、基本原理...）
• 开始
• 操作模式
• 高级特性
• 命令语法和系统选项

 8.7.4需求规格说明的用户

 8.7.5高质量SRS及评价标准

高质量的需求规格说明

• 是所有需求的集合
• 描述产品要提供的所有功能
• 是软件系统解决方案的商业合同的基础
• 是测试计划的基础
• 定义产品需求的度量标准
• 是产品需求的跟踪的先决条件
• 影响开发产品的项目计划

 高质量需求规格说明的评价标准

 应当是简洁的

 

8.7.6 需求规格说明模板

 

 SRS模板的优缺点

8.7.7总结

• 尽快开始写需求
• 确定哪些属性将被用于分类和细化需求
• 产生一个初始版本来刺激反馈
• 询问用户往往比咨询专家更有用
• 撰写需求是需要遵从的法则：

1.    使用简单、直接的语言
2. 撰写可测试的需求
3. 使用定义好的并打成共识的属于
4. 一次只写一项需求

第九章 用例建模

9.1 用例建模概念

9.1.1用例在需求管理过程中的作用

9.1.2为什么需要用例建模？——描述系统的功能性需求

1. 关联干系人需要以及软件需求
2. 确认与系统交互的人或对象（参与者）
3. 定义系统的边界
4. 捕捉和传达系统的理想行为（用例）

9.1.3用例模型的表示

用例模型的表示——文本描述

 用例模型的表示——用例图

用例图的主要元素： 

什么是用例？

用例包含软件系用需求 

 参与者的定义：关注角色

• 与系统交互的人
• 与系统交互的硬件组件
• 或者其他都外部系统
• 关注的重点是所承担的“角色”
• 参与者的名要明确定义其角色

例：参与者定义与角色划分

 交互——关联

 箭头的使用习惯

每一个交互——关联待料一个完整的对话

场景是用例的实例

9.2 用例建模过程

构建用例模型的步骤

 寻找参与者

识别参与者——是谁与系统进行交互？

参与者的描述 

 参与者建模的检查项

寻找用例

识别用例

用例的描述（动宾结构） 

 

用例是命名

用例建模过程中的检查项 

 

 

 

用例的全生命周期

用例简述的例子 

 

详细用例规约的例子 

用例文档模板 

总结：Use Case模型的建立步骤 

9.3用例建模精讲

一、设定系统边界

一

 二

 三

二、不要吧用例定义成功能分解

功能分解的一个例子

 

正确的

如何避免功能性分解？ 

三、合适使用包含关系？ 

四、何时使用扩展关系？ 

五、用例图中的主要图标

9.4建模工具介绍

系统建模工具的主要功能

 常用系统建模工具

9.5微信抢票应用案例