软件工程

起篇

 好的软件

  可接受性

  可依赖性和信息安全性

  效率

  可维护性

 影响因素

  异构性

   存储问题

   交互问题

   安全性

   等等

  企业和社会的变革

  信息安全与信任

  规模

 应用类型

  独立应用

  基于事务的交互性应用

  嵌入式控制系统

  批处理系统

  娱乐系统

  建模和仿真系统

  数据收集和分析系统

  系统之系统

 基本原则

  软件系统开发过程应当受管理并且被开发人员所理解

  可靠性和性能对所有类型的系统都很重要

  理解和管理系统规格说明和需求非常重要(需求工程)

  应当尽可能高效地使用已有的资源(软件复用)

 道德与行为准则

  公众感,与公众利益保持一致

  客户和雇主利益最大化,在保证公众利益的前提下

  产品及相关修改尽可能满足行业最高标准

  具备公正和独立的职业判断力

  维护并倡导合乎道德的有关软件开发和维护的管理办法

  弘扬职业正义感和荣誉感,尊重社会公众利益

  公平地对待与协助同事

  毕生学习专业知识,倡导合乎职业道德的职业活动方式

软件过程

 软件过程的概念

  软件过程是完成软件产品生产的一组相互关联的活动

  一个为建造高质量软件所需要完成的活动、动作和任务的框架

  是工作产品构建时所执行的一系列活动、动作和任务的集合

  软件开发中所遵循的路线图

 过程流*

  线性过程流

  迭代过程流

  演化过程流

  并行过程流

 基本活动

  软件规格说明

   需求抽取与分析

   需求规格说明

   需求确认

  软件开发(设计与实现)

   体系结构设计

   数据库设计

   接口设计

   构件选取和设计

  软件确认(验证与确认)

   测试过程

    构件测试

     单元白盒测试

    系统测试

     整体白盒测试

    客户测试(β测试)

     客户对于β版本的测试

     黑盒测试

  软件演化(维护) 渐渐与开发结合

 过程评估与CMM/CMMI

  能力成熟度方法(Capability Maturity Model)

   级别划分

    不完全级

     过程域或者没有执行,或者已经执行但没有达到CMMI1的要求

    初始级(已执行级)

这里是有歧义的,显然它们指代不同,但是在发展的过程中确实出于近似的阶段

     对于所有过程,将要进行的工作范围得到了明确定义并与团队成员进行了沟通

     或者说生产已规定工作产品所需的工作任务都已经执行

    受管理级

     文档化的项目计划来定义项目目标,资源管理和过程监控在整个机构中到位

    已定义级

     收集过程资产和过程度量,并用于未来的过程改进

    定量管理级

     通过统计或其他定量方法来控制子过程

    优化级

     使用过程和产品度量来驱动过程改进,对趋势分析,根据业务对过程调整

  五步

   启动

   诊断

   建立

   执行

   学习

 经典软件过程模型的特点

  瀑布模型

   概念

    经典生命周期

    系统的、顺序的软件开发方法

    步骤

     需求分析和定义

     系统和软件设计

     实现和单元测试

     集成和系统测试

     运行和维护

   特点

    线性模型

    变种V模型

     加入有效的验证机制

      单独一侧的多测试穿插

     其实和瀑布模型大体上没有区别

     验证多为交叉的验证,即覆盖面广的各种测试穿插在开发之中

   缺点

    项目推进容易变得混乱

    需要客户在开始需求明确,但事实上很难做到

    客户只有接近尾声才有可用版本

    线性

     可能会有堵塞的情况

  增量模型

   概念

    先开发出一个初始的实现,然后从用户那里获取反馈逐步演化到满足需求的系统

   优势

    降低了实现需求变更的成本

    开发过程中更容易得到客户对于已完成工作的反馈

    可以更早的交付一个可用的版本

   缺点

    和一些办事规程(比如法律法规)相冲突

    过程不可见

    随着新的增量,不断修改使得系统结构会逐步退化

  演化模型

   概念

    需求未明,用户给出核心需求,实现后提出有效反馈,最终形成可交付完整产品的迭代开发过程模型

   分类

    原型开发模型

     对于临时开发出的模型,开发者和利益相关者的分歧

     可能为了快速开发选取了不好的方法

    螺旋开发模型

     结合了原型的迭代和瀑布的可控

     但是难以说服客户

    协同模型

     各个状态综合控制的

   优势

    功能被开发就可以知道可不可以用

    帮助引导出高质量产品需求

    早期获得风险管理的数据

    早期建立起产品开发的配置管理,产品构建,自动化测试,缺陷跟踪,文档管理,均衡整个开发过程的负荷

    开发中的经验教训能反馈于本产品的下一个回圈过程,提高质量和效率

    开发人员容易受到雏形产品的鼓舞

    新功能更容易受到反馈

    方便销售工作的提前进行,产品原型会在产品开发中后期就确定下来

   缺点

    需求不明确容易给总体设计带来困难,从而影响产品性能的优化及产品的可维护性

    缺乏严格的过程管理的话,该生命周期模型可能退化为“试--错--改”的原始模式

    心理上,可能产生一种尽力的想法,认为虽然不能全部完成,但还是造出了一个有部分功能的产品

    如果不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面影响

  统一过程模型(Rational Unified Process)

   起始阶段

    用户沟通

    计划活动

   细化阶段(主要创建分析和设计模型,定义类和体系结构)

    用户沟通

    建模活动

    体系结构

     用例模型

     需求模型

     设计模型

     实现模型

     部署模型

   构建阶段

    设计转化为实现

    集成和测试

   转换阶段(transition phase)(移交阶段)

    产品发布用户测试评价

    收集用户意见

    迭代修改完善产品

   生产阶段

    持续使用监控软件

    提供运行环境支持

    提交并评估缺陷报告和变更请求

   特点

    用例驱动,以架构为核心,迭代并且增量

  专用过程模型

   基于构件的开发

   形式化方法开发

   面向方面的软件开发

  Others

   个人软件过程(Personal Software Process)

    策划

     分离需求活动

     识别开发任务

     建立项目进度计划

    高层设计

     所有问题跟踪记录

    高层设计评审

     使用正式的验证方法来发现设计中的错误

    开发

     细化和评审构件级设计

     完成编码

     代码评审

     编译测试

     对所有重要任务和工作结果进行度量

    后验

     根据度量和测量结果确定过程的有效性

     度量和测量结果为提高过程的有效性提供指导

    强调的点

     强调尽早发现错误

     分析易犯的错误的种类

   团队软件过程(Team Software Process)

    过程

     项目启动

     高层设计

     实现

     集成

     测试

     后验

    目标

     建立自我管理团队来计划和跟踪其工作、确定目标、建立团队自己的过程和计划

     指示管理人员如何指导和激励其团队,并保持团队的最佳表现

     使CMM第5级行为常规化*

     协助大学传授工业级团队技能*

  集成与配置

   集成与配置过程

    需求规格说明

    软件发现和评估

    需求精化

    应用系统配置

    构件适配和集成

   优势

    降低软件开发量

    降低成本和风险

    更快的软件交付

   缺点

    需要需求权衡,未必可以完全满足用户的真实需求

    失去一部分的系统演化控制(可复用控件的新版本不在控制之下)

  通用过程模型

   沟通

   策划

   建模

   构建

   部署

 应对变化

  原理

   变化预测

    在大量返工之前预见或预测可能的变化活动

   变化容忍

    通过过程和软件设计使得对系统的修改很容易进行

  应用

   系统原型

    阶段

     建立原型目标

     定义原型功能

     开发原型

     评估原型

    辅助变化预测

     需求工程中帮助对系统需求进行抽取和确认

     系统设计中可以用于探索软件解决方案并用于系统用户界面的开发

   增量交付

    定义概要需求

    将需求分配到各个增量中

    设计系统体系结构

    开发系统增量

    确认增量

    集成增量

    确认系统

    部署增量(系统是否完整-->最终系统)

 过程改进

  过程

   过程度量

    对软件过程或产品的一个或多个属性进行度量

   过程分析

    对当前过程进行评价,识别过程中的弱点和瓶颈

   过程改变

    提出对当前过程的改变方法以应对一些已识别出的过程弱点

  敏捷开发

   敏捷宣言

    个体与交互胜过过程和工具

    可工作的软件胜过全面的文档

    客户协作胜过合同谈判

    响应变化胜过遵循计划

   敏捷过程的特点

    规格说明、设计和实现过程混合

    增量开发(迭代化开发)支持持续变化

    使用广泛的工具来支持开发过程

     自动化测试工具

     支持配置管理和系统集成工具

     用户界面自动化构造工具

    概括性的原则

    客户参与

    拥抱变化

    增量交付

    保持简洁

    注重人而不是过程

   极限编程实践

    共同拥有权

    持续集成

    增量规划

    现场客户

    结对编程

    重构

    简单设计

    小的发布

    可持续的步调

    测试先行的开发

   极限编程用的最广泛

    其他方法也有

    估计考只会考这个

    大体上思想都是差不多的

   敏捷方法的伸缩

    敏捷方法的实践问题

     敏捷开发的非正式性与大型企业常用合同定义不符合

     敏捷方法适用于新的软件开发而不是软件维护

      缺少产品文档

      保持客户参与

      开发团队的延续性

     敏捷开发适用于小的、同处一地的团队,不适合全球化的团队

    敏捷和计划驱动的方法

     为了更加适用于开发场景同时保留敏捷开发的一些特性

    面向大型系统的敏捷方法

     核心敏捷开发

     敏捷规模化

     规范化的敏捷交付

     方法实例(多团队的Scrum)

    面向整个组织的敏捷方法存在的问题

     接受敏捷可能带来的风险

     质量规程和标准与敏捷不适应

     保持团队成员水平都较高才比较适合敏捷

     敏捷方法可能存在文化上的抵制(长期使用传统系统工程)

软件需求

几个图的画法之后好好学习一波

 软件需求的概念

  用户需求

   自然语言和图形的描述

   对系统的期望的大概陈述

  系统需求(功能规格说明文档)

   功能性需求

    系统该做什么,将用户需求展开给系统开发者

   非功能性需求

    交互性

    扩展性

    性能要求等

   约束

    时间性约束

    标准规范中施加的约束(安全,代码规范啥的)

    开发过程中的约束等

 需求工程的基本过程(RE)

  需求抽取

   需求发现和理解

    和系统利益相关者进行交互

   需求分类和组织

    处理收集的未整理的需求,组织为内聚的聚类

   需求优先级排序和协商

    发生各方的需求冲突时,需要协商解决,进行优先级排序

   需求文档化

    产生一个早期的文档草稿提供给下一轮螺旋

   Tips

    需求抽取技术

     访谈

     人种学调查

      人们的实际工作方式

      从与他人的合作以及对其他人的活动的了解中得出的需求

     文化背景,生活习惯,宗教,社会风俗等

    故事和场景

     便于描述,也可以从这些描述中抽取可能的需求

  需求规格说明

   自然语言规格说明

    以一种标准格式定义各种需求

    用一致的方式使用语言,必须满足和期望满足分开

    强调性的文本(粗体、斜体或颜色)来突出需求中的关键部分

    不要假设读者理解技术性的软件工程语言,尽量避免使用专业术语、缩写

    尽量将需求与原理关联(为啥有这个需求,是谁提出来的,方便问询,显而易见的应该就不用了)

   结构化规格说明

    自然语言规格的特性

    标准的格式

    简言之,给自然语言规格说明加了更多限制~~,更具规范统一的说明文档

   用况

    图形化模型和结构化文本描述用户与系统间交互,,详细可与之后的用况图结合看

   数学规格说明

    基于有限状态机或集合等数学概念,无二义的规格说明,但是不容易被客户理解2333

  需求确认

   检查方面

    正确性检查

     需求是否是系统用户的真实需要

    一致性检查

     文档的需求不应该起冲突

    完整性检查

     应当定义系统用户想要的所有功能以及约束

    现实性检查

     系统预算范围内

    可验证性检查

     为了减少客户和承包商可能的争议,所描述的系统需求应当是可验证的

   需求确认技术

    需求评审

     评审团队系统性地分析需求,检查错误和不一致性

    原型化

     开发一个可执行的系统模型

     利益相关者对系统进行试验是否满足期望

     向开发团队反馈需求变更

    测试用例生成

     需求应该是可测试的

     设计针对性的测试揭示需求中的问题

  需求变更(管理)

   原因

    系统的业务和技术环境总是会在系统安装后发生变化

    为系统付钱的人和系统的用户经常是不同的人

    大型系统通常有各种各样的利益相关者群体

   需求管理计划

    需求标识

    变更管理过程

    追踪关系策略

    工具支持

     需求存储

     变更管理

     追踪关系管理

   需求变更管理

    问题分析和变更规格说明

     分析检查其是否合理,反馈给变更请求者

    变更分析和成本考虑

     依据系统需求的基本知识评估,对成本评估,判定是否变更需求

    变更实施

     必要时,对需求文档,系统设计和实现进行修改

 分层数据流模型

  多层数据流图

   顶层数据流图

   中层数据流图

   底层数据流图

  可以对某一个部分下钻画图作为细分的新层数据流图

  英文 Data Flow Diagram

  逐层分解

 用例和场景建模

  用例图(用况图)

   用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图

   

  活动图

   图形化的迭代流图

   

  泳道图

   活动图的一种变形

   按功能主体分区

   

  顺序图

   顺序图是将交互关系表示为一个二维图

   纵向是时间轴,时间沿竖线向下延伸

   

 UML系列图仅作了解

  重要的不是图

  重要的是图表达的东西

 数据模型建模

  类图

   显示类和类之间关联

   

 行为模型建模

  状态机图

   描述系统状态以及导致状态间转换的事件

   

软件设计和构造

 软件体系结构及体系结构风格概念

感觉不会是重点,两本书表述不是很一致,之后以实践者为准吧

  ADL体系结构描述语言

  体系结构设计关注理解一个软件如何组织以及设计该系统的整体结构

   小体系结构

   大体系结构

   好处

    利益相关者交流

     体系结构可作为不同利益相关者讨论焦点

    系统分析

     在系统开发的早期阶段明确系统的体系结构要求进行一些分析

    大范围复用

     具有相似需求的系统经常具有相同的系统体系结构

   使用方式

    作为一种“鼓励对系统设计进行讨论”的方式

    作为一种“文档化已经设计好的的体系结构”的方式

  风格和决策的选择依据

   性能

   信息安全

   可用性

   可维护性

  描述视图

   逻辑视图

    系统中的关键抽象显示为对象或对象类

   进程视图

    显示系统运行时如何通过相互交互的进程来进行

   开发视图

    显示软件如何面向开发任务进行分解

   物理视图

    显示系统硬件以及软件构件如何分布在系统中的处理器中

  几种体系结构

   分层体系结构

    分离和独立的思想(MVC就是个栗子)

    支持系统的增量开发

    使用场景

     已有系统上构建新设施

     开发涉及多个团队,一个团队负责一层的功能

     存在多个层次上的信息安全需求

    优势

     接口不变,可以对整个层大动干戈

     可在每一层提供冗余设施以增加系统的可依赖性~

    缺点

     难以干净的分离

     多层解析容易造成性能问题~

   知识库体系结构

    围绕一个共享数据库或知识库组成的

    栗子

    使用场景

     指挥控制系统

     管理信息系统

     计算机辅助设计系统

     交互式软件开发环境

    优势

     构件可以保持独立

     一个构件的修改可以被传播到所有构件

     所有数据都可以一致地进行管理

    缺点

     知识库的单点失效问题可能会影响整个系统

     通过知识库组织所有通信效率可能不高

     将知识库分布到多台电脑可能比较困难

   客户-服务器体系结构

    一种分布式系统运行时的组织方式

    主要构件

     向其他构件提供服务的服务器

     调用服务器提供的服务的客户端

     供客户端访问这些服务的网络

    使用场景

     共享数据库的中的数据必须从一系列不同的位置进行访问

     一个系统的负载是多变的时候(服务器可以复制)

    优势

     服务器可以分布在网络上

     通用功能可以开发给所有客户端~

    缺点

     每个服务都可能单点失效,容易受到拒绝服务攻击或服务器失效的影响

     受网络以及系统影响,性能可能不可预测

     如果服务器属于不同组织,还可能会出现管理问题

   管道和过滤器体系结构

    功能性的变换处理输入产生输出

    使用场景

     数据处理应用

     用户交互很少的嵌入式系统和批处理系统

    优势

     容易理解并支持变换的复用

     工作流风格与许多业务过程的结构相匹配

     通过增加变换来进行演化非常直观

     可以被实现为一个顺序系统或一个并发系统

    缺点

     针对数据转换的格式必须在相互通信的多个变换之间达成一致

     每个变换必须解析它的输入,并将输出转换成约定的形式,增加了系统负担

     由于特定的输入输出格式,可能无法复用使用不兼容的数据结构的体系结构构件

 设计模式概念

  一种对于逐渐积累的智慧和经验的描述,对某个共性问题的经过成功尝试的解决方案

  可以形成模式的那种解决方案

  

 模块化设计的基本思想及概念

  抽象

   过程抽象

    指出功能,隐藏细节

   数据抽象

    描述数据对象的具名数据集合而非数据本身

  分解

   分而治之

  模块化

   软件被划分为独立、可处理的构件

   将构件集成到一起满足需求

  封装

   包装起来~

  信息隐藏

   每个模块对其他所有模块都隐藏自己的设计决策

   信息都包含在模块内而其他模块无需对这些信息访问

  功能独立

   关注点分离、模块化、抽象和信息隐蔽的直接产物

   每个模块功能专一,减少涟漪效应

 软件重构

  不改变代码设计的外部行为而是改进其内部结构

  减少耦合,增加内聚,提高性能

 软件体系结构建模

  包图

   功能上有紧密联系的、垂直或水平的切片打包

   将一族接口打包

   将一组不稳定的类打包

   提取独立的类型

   利用工厂方法(Factory)来降低实体包之间的依赖

   不要在包中出现回路

  类图

  构件图

   又称组件图,用于描述系统中某一模块

   

  顺序图

  部署图

   物理层次上做整体的系统规划,同时有一些细化的设计

   

 接口

  硬件类

   同一计算机不同功能层之间的通信规则称为接口

  软件类

   对协定进行定义的引用类型

 面向对象设计原则

  (S 单一职责原则)

   一个类有且只有一个职责

  O 开闭原则

   软件实体应该对扩展开放而关闭修改

    即在不修改源代码的情况下可以修改内容

  L Liskov替换原则

关于父类和子类

   父类方法属性子类必须有效,用子类代替父类执行来检测继承关系是否合理

   即子类可以在程序中替代父类

  I 接口隔离原则

   不能强迫用户去依赖那些他们不使用的接口

  D 依赖转置原则(针对接口编程)

关于抽象和细节

   高层模块不应该依赖低层模块,两者都应该依赖其抽象

   抽象不应该依赖细节,细节应该依赖抽象

  其他

   迪米特法则

    类间解耦

 内聚与耦合的概念

  内聚

   每个模块尽可能独立完成自己的功能,不依赖于模块外部的代码

  耦合

   模块与模块之间接口的复杂程度,模块之间联系越复杂耦合度越高

 常见内聚和耦合类型

  内聚

   偶然内聚

    模块内的各处理元素没有任何联系,只是偶然凑到一起,内聚程度最低

   逻辑内聚

    几种相关的功能组合在一个模块里

   时间内聚

    需要同时执行的动作组合在一起

   过程内聚

    模块内处理元素相关,必须以特定次序执行

   通信内聚

    模块内各个组成部分都使用相同的数据或产生相同的数据结构

   顺序内聚

    模块中各个处理元素和同一个功能密切相关且处理必须顺序执行

   功能内聚

    模块内所有元素的各个组成部分全部都为完成同一个功能存在

   在模块划分时,尽量保证高内聚低耦合,多聚合,少继承~~

  耦合

   内容耦合

    一个模块直接访问另一个模块的内容

   公共耦合

    一组模块都访问同一个全局数据结构

   外部耦合

    一组模块都访问同一全局变量而不通过参数表传递该全局变量的信息

   控制耦合

    模块之间传递的不是数据信息而是控制信息

   标记耦合

    模块之间传递的是特殊数据结构而不是简单数据信息

   数据耦合

    模块之间只传递简单的数据项参数

   非直接耦合

    模块之间没有直接关系,联系完全通过主模块的控制和调用来实现,耦合度最弱,模块独立性最强

   若模块间必须存在耦合,尽量使用数据耦合,少用控制耦合,慎用公共耦合,尽量避免内容耦合

软件测试

 软件测试及测试用例

 测试方法

  单元测试

  集成测试

  确认测试

  系统测试

  回归测试

 调试的概念、调试与测试的关系

 测试覆盖度

 黑白盒测试

  黑盒测试

   概念

   等价类划分

  白盒测试

   概念

   基本路径测试

 代码圈复杂度的计算方法

关于作图,作图规范啥的之后另起一稿,还有相关的一些东西,参照另一本书或需稍作修改,你懂我意思吧~

Todo 一些加了重要性标注的东西,名词解释,然后没有了

都可以套的路数

 沟通

 策划

 建模

 构建

 部署

软件兼具过程和产品两个属性