01-信息与信息系统
1. 信息的基本概念
1.1 信息的概念
- 维纳(Norbert Wiener):信息就是信息,既不是物质也不是能量,但信息可转换为物质或能量。
- 香农(C.E.Shannon):信息是不确定性的减少。
1.2 信息的特征(11个特性)
(1)客观性(2)普遍性(3)无限性(4)动态性(5)相对性(6)依附性(7)变换性(8)传递性(9)层次性(10)系统性(11)转化性
1.3 信息的功能(5个主要功能)
(1)为认识世界提供依据
(2)为改造世界提供指导
(3)为有序的建立提供保证
(4)为资源开发提供条件
(5)为知识的生产提供材料
1.4 信息的相关的两个概念
(1)信息与数据:信息是经过加工后的数据。
(2)信息与知识:知识是经过加工的信息。
2. 系统及相关理论
2.1 系统的特性(9个特性)
(1)整体性(2)层次性(3)目的性(4)稳定性(5)突变性(6)自组织性(7)相似性(8)相关性(9)环境适应性
2.2 系统论的任务(3个任务)
(1)改变人类的思维方式
(2)提供科学的理论和方法
(3)形成统一的系统科学体系
2.3 系统理论(8个基本原理)
(1)系统的整体性原理
(2)系统的整体突变原理(非加和原理)
(3)系统的层次性原理
(4)系统的开放性原理(开发系统)
(5)系统的目的性原理
(6)系统环境互塑共生原理
(7)系统的秩序原理
(8)系统的生命周期原理(演化原理)
2.4 信息系统
简单的说,信息系统就是输入数据,通过加工处理,产生信息的系统。管理模型、信息处理模型、系统实现条件三者的结合,产生信息系统。
3. 系统工程方法论
3.1 霍尔三维结构(硬系统方法论)
(1)逻辑维(2)时间维(3)知识维
3.2 软系统方法论(5个步骤)
(1)问题现状说明(2)理清问题的关联因素(3)建立概念模型(4)比较(5)实施
4. 信息系统工程
4.1 信息系统的分类
按应用层次分类:
(1)战略级(企业最高管理层)
(2)战术级(企业中层经理及其管理部门)
(3)操作级(服务型企业的业务部门)
(4)事务级(企业的管理业务人员)
按数据环境分类:
(1)数据文件
(2)应用数据库
(3)主题数据库
(4)信息检索系统(对应数据仓库)
4.2 信息系统的生命周期(5个阶段)
(1)系统规划
(2)系统分析
(3)系统设计
(4)系统实现
(5)系统运行与评价
4.3 信息系统建设的原则
(1)高层管理人员介入原则
(2)用户参与开发原则
(3)自顶向下规划原则
(4)工程化原则
02-企业信息化战略与实施
1. 企业信息化概述
1.1. 信息化的概念
信息化就是计算机、通信和网络技术的现代化。
信息化就是从物质生产占主导地位的社会向信息产业占主导地位的社会转变的发展过程。
信息化就是从工业社会向信息社会演进的过程。
1.2. 国家信息化体系(6个要素)
(1)信息资源
(2)信息网络
(3)信息技术应用
(4)信息产业
(5)信息化人才
(6)信息化政策法规和标准规范
1.3. 企业信息化方法(5种常见方法)
(1)业务流程重组方法
(2)核心业务应用方法
(3)信息系统建设方法
(4)主题数据库方法
(5)资源管理方法
2. 企业信息化规划
2.1. 信息化规划的内容
(1)信息化战略体系
(2)信息化规划涉及的主要内容和关系
- 企业战略规划是用机会和威胁评价现在和未来的环境,用优势和劣势评价企业现状,进而选择和确定企业的总体和长远目标,制定和抉择实现目标的行动方案。(确定企业未来发展的大方向)
- 信息系统战略规划关注的是如何通过信息系统来支撑业务流程的运作,进而实现企业的关键业务目标,其重点在于对信息系统远景、组成架构、各部分逻辑关系进行规划。(为企业战略开发支撑系统)
- 信息技术战略规划通常简称为IT战略规划,是在信息系统规划的基础上,对支撑信息系统运行的硬件、软件、支撑环境等进行具体的规划,它更关心技术层面的问题。(为支撑系统运行环境做规划)
- 信息资源规划是在以上规划的基础上,为开展具体的信息化建设项目而进行的数据需求分析、信息资源标准建立、信息资源整合工作。(数据与标准相关的规划)
(3)信息化规划的具体内容
- 1)明确发展目标和实施重点
- 2)成立领导机构
- 3)做好企业业务信息化需求分析
- 4)确定企业信息化不同发展阶段的投资预算
- 5)制定必要的促进企业信息化建设的规章制度
2.2. 信息化规划与企业战略规划
(1)信息化战略与企业战略
(2)信息化规划与企业战略规划
(3)信息化战略与企业战略的集成
3. 信息系统开发方法(4种方法)
(1)结构化法
- 用户至上
- 严格区分用户阶段,每阶段有任务与结果
- 强调系统开发过程的整体性和全局性
- 系统开发过程工程化,文档资料标准化
- 自顶向下,逐步分解(求精)
(2)原型法(需求阶段)
- 适用于需求不明确的开发
- 按功能分:水平原型(界面)、垂直原型(复杂算法)
- 按最终结果分:抛弃式原型、演化式原型
(3)面向对象方法(自底向上)
- 更好的复用性
- 关键在于建立一个全面、合理、统一的模型
- 分析、设计、实现三个阶段,界限不明确
(4)面向服务的方法
- SO方法有三个主要的抽象级别:操作、服务、业务流程(抽象级别最高)。
SOAD分为三个层次:
- 基础设计层(底层服务构件)
- 应用结构层(服务之间的接口和服务级协定)
- 业务组织层(业务流程建模和服务流程编制)
- 服务建模:分为服务发现、服务现约和服务实现三个阶段
4. 信息系统战略规划方法
- 第一阶段(以数据处理为核心,围绕职能部门需求)
(1)企业系统规划法(BSP)
(2)关键成功因素法(CSF)
(3)战略集合转化法(SST)
- 第二阶段(以企业内部MIS为核心,围绕企业整体需求)
(1)战略数据规划法(SDP)
(2)信息工程方法(IE)
(3)战略栅格法(SG)
- 第三阶段(以集成为核心,围绕企业战略需求)
(1)价值链分析法(VCA)
(2)战略一致性模型(SAM)
5. 信息资源管理(Information Resource Management,IRM)
5.1. 信息资源管理概述
5.1.1. IRM的内容(3个主题)
(1)资源管理的方向和控制,要从整个企业管理的层面来分析资源的管理。
(2)建立企业信息资源指导委员会,负责制订方针政策,控制和监督信息资源功能的实施。
(3)建立信息资源的组织机构,从事数据的计划和控制、数据获取以及数据的经营管理,并包括企业应用系统的开发。
5.1.2. 信息资源的分类
- 从管理维度分类
- 从信息来源维度分类
- 从应用主题维度分类
5.2. 规范与标准
5.2.1. IRM基础标准
- 数据元素标准
- 信息分类编码标准
- 用户视图标准
- 概念数据库标准
- 逻辑数据库标准
5.2.2. 制定和实施的原则
(1)不要把例外当成正规
(2)管理部门必须支持并乐于帮助执行标准
(3)标准必须从实际出发、有生命力的、切实可行的
(4)标准不是绝对的,必须有某种灵活的余地
(5)标准不应该迁就落后
(6)标准必须是容易执行的
(7)标准必须加以宣传推广,而不是靠强迫命令
(8)关于标准的细节本身并不重要,重要的是制订了某些标准
(9)标准应该逐渐的制订出来,不要企图把所有的数据管理标准一次搞定
(10)数据管理的最重要的标准是一致性标准,也就是数据命名、数据属性、数据设计和数据使用的一致性
5.3. 信息资源规划(Information Resource Planning,IRP)
信息资源规划是信息化建设的基础工程,是指对企业生产经营活动所需要的信息。对产生、获取、处理、存储、传输和利用等方面进行全面的规划。
IRP强调将需求分析与系统建模紧密结合起来,需求分析是系统建模的准备,系统建模是用户需求的定型和规划化表达。IRP的主要过程如下图所示。
- IRP的过程
IRP的过程大致可分为7个步骤,分别是定义职能域、各职能域业务分析、各职能域数据分析、建立整个企业的IRP基础标准、建立信息系统功能模型、建立信息系统数据模型和建立关联矩阵。IRP是按照业务和数据两条主线进行开展的。
6. 企业信息系统
6.1. 企业资源计划(Enterprise Resource Planning,ERP)
6.1.1. ERP的概念(3个角度)
- 管理思想:他是管理思想的变革。
- 软件产品:二但不是直接买来就用,需要个性化的开发与部署。
- 管理系统:存在众多的子系统,这些子系统有统一的规划,是互联互通的,便于事前事中监控。
6.1.2. ERP的主要功能
- 财会管理:包括会计核算和财务管理等模块。
- 物流管理:包括分销管理、库存控制和采购管理等模块。
- 生产控制管理:包括主生产计划、物料需求计划、能力需求计划、车间控制和制造标准等模块。
- 人力资源管理:包括人力资源规划、招聘管理、工资核算、工时管理和差旅费核算等模块。
6.1.3. ERP的发展阶段
6.1.4. ERP生产管理的流程
(1)第一层:经营计划
经营计划是企业总目标的具体体现,企业的高层决策者根据市场调查和需求分析、国家有关政策、企业资源能力和历史状况、同行竞争对手的情况等有关信息,制定经营计划。
(2)第二层:生产计划大纲
生产计划大纲是根据经营计划的生产目标制定的,是对企业经营计划的细化用以描述企业在可用资源的条件下,在一定时期中的产量计划。生产计划大纲在企业决策层的三个计划中有承上启下的作用,一方面它是企业经营计划和战略规划的细化,另一方面它又用于指导企业编制主生产计划指导企业有计划地进行生产。
(3)第三层:主生产计划
主生产计划是对企业生产计划大纲的细化,说明在一定时期内的如下计划:生产什么,生产多少和什么时候交货。
(4)第四层:物料需求计划和能力需求计划
物料需求计划是对主生产计划的各个项目所需的全部制造件和全部采购件的网络支持计划和时间进度计划。它根据主生产计划对最终产品的需求数量和交货期,推导出构成产品的零部件及材料的需求数量和需求时期,再导出自制零部件的制作订单下达日期和采购件的采购订单发送日期,并进行需求资源和可用能力之间的进一步平衡。
能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法。旨在通过分析比较MRP的需求和企业现有生产能力,及早发现能力的瓶颈所在,为实现企业的生产任务而提供能力方面的保障。
(5)第五层:车间生产控制
车间作业计划在MRP所产生的加工制造订单的基础上,按照交货期的前后和生产优先级选择原则以及车间的生产资源情况(如设备、人员、物料的可用性、加工能力的大小等)将零部件的生产计划以订单的形式下达给适当的车间。
6.1.5. ERP的实施
(1)前期准备阶段
动员大会
基础数据的准备
系统的安装
程序演示和功能确认
期初数据的导入
(2)试运行阶段
确定用户清单,划分用户权限
加强培训
业务流程重组
系统使用问题的记录
(3)交付收尾阶段
工作成果审查
查核各项工作或活动是否已经完成
6.2. 客户关系管理(Customer Relationship Management,CRM)
6.2.1. CRM的理念
CRM理念是将客户看作资产,客户关怀是中心。目的是与客户建立长期和有效的业务关系。最大限度地增加利润。核心是客户价值管理,提高客户忠诚度和保有率。
6.2.2. CRM的功能(4个功能)
(1)客户服务:CRM的关键内容。
(2)市场营销:包括商机产生、商机获取和管理、商业活动管理和电话营销等。
(3)共享的客户资料库:它把市场营销和客户服务连接起来。
(4)分析能力:CRM的一个重要方面在于它具有使客户价值最大化的分析能力。
6.2.3. CRM的解决方案
一个有效的CRM解决方案应该具备以下要素:
(1)畅通有效的客户交流渠道(触发中心)。
(2)对所获信息进行有效分析(挖掘中心)。
(3)CRM必须能与ERP很好地集成。
6.2.4. CRM的实现过程
CRM实现过程包含三方面的工作:
(1)客户服务与支持:通过控制服务品质以赢得顾客的忠诚度,例如,对客户快速准确的技术支持、对客户投诉的快速反应、对客户提供产品查询等;
(2)客户群维系:通过与顾客的交流实现新的销售,例如,通过交流赢得失去的客户等;
(3)商机管理:利用数据库开展销售,例如,利用现有客户数据库做新产品推广测试,通过电话或电子邮件促销调查,确定目标客户群等。
6.3. 供应链管理(Supply Chain Management,SCM)
6.3.1. SCM的理念
SCM理念:强强联合,整合与优化“三流”,打通企业间“信息孤岛”,严格的数据交换标准。
6.3.2. SCM的内容
(1)计划(策略性)
(2)采购
(3)制造
(4)配送
(5)退货
6.3.3. 信息化的三流
(1)信息流 (核心)
需求信息流:如客户订单、生产计划、采购合同等;
供应信息流:如入库单、完工报告单、库存记录、可供销售量、提货发运单等;
(2)资金流
(3)物流
6.3.4. SCM实施的关键问题
- 配送网络的重构
- 配送战略问题
- 供应链集成与战略伙伴
- 库存控制问题
- 产品设计
- 信息技术和决策支持系统
- 顾客价值的衡量
6.4. 产品数据管理(Product Data Management,PDM)
6.4.1. PDM的理念
PDM理念:用来管理所有与产品相关信息和与产品相关的过程。
- 产品数据
- 开发过程集成
6.4.2. PDM的发展过程
PDM的发展过程
6.4.3. PDM的核心功能
(1)数据库和文档管理
(2)产品结构与配置管理
(3)生命周期管理和流程管理
(4)集成开发接口
6.5. 产品生命周期管理(Product Life-Cycle Management,PLM)
6.5.1. 产品生命周期
产品的生命周期包括5个阶段:
(1)培育期(概念期)
(2)成长期
(3)成熟期
(4)衰退期
(5)结束期(报废期)
6.5.2. PLM的功能
(1)总体功能
(2)核心制造、协作和控制功能
(3)细化功能
6.6. 知识管理
6.6.1. 知识的分类
(1)显性知识:规范,系统,结构化,明确。(组织过程资产)
(2)隐性知识:未规范,零星,非正式,未编码,不易保存和传递。(个人经验)
6.6.2. 知识管理工具
(1)知识生成工具:知识获取、知识合成、知识创新。
(2)知识编码工具:通过标准形式表现知识。
(3)知识转移工具:使知识能在企业内传播和分享。
6.7. 业务流程重组(Business Process Reengineering,BPR)
6.7.1. BPR的概念
BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计,从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。
6.7.2. BPR的实施
BPR遵循的原则(3个原则)、实施的流程(8个步骤)和系统的规划(5个规划)如下图所示:
6.8. 业务流程管理(Business Process Management,BPM)
6.8.1. BPM的概念
BPM是一种以规范化的构造端到端的卓越业务流程为中心,以持续的提高组织业务绩效为目的的系统化方法。
6.8.2. PDCA闭环的管理过程(戴明环)
(1)明确业务流程所欲获取的成果
(2)开发和计划系统的方法实现以上成果
(3)系统地部署方法确保全面实施
(4)根据对业务的检查和分析以及持续的学习活动,评估和审查所执行的方法。并进一步提出计划和实施改进措施。
6.8.3. BPM的管理思想
BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造,而是根据现有流程的具体情况,对流程进行规范化的设计。
流程管理包含三个层面:规范流程、优化流程和再造流程。
6.9. 决策支持系统(Decision Support System,DSS)
6.9.1. DSS的分类
结构化决策
非结构化决策
半结构化决策
6.9.2. DSS的基本结构
DSS基本结构由4个部分组成:数据库子系统、模型子系统、推理部分和用户接口子系统,如下图所示。
6.10. 商业智能(Business Intelligence,BI)
6.10.1. BI基本概念
商业智能用于决策分析,数据仓库、联机分析处理(OLAP)和数据挖掘技术是BI的三大组成部分。
BI系统主要包括数据预处理、建立数据仓库、数据分析和数据展现4个主要阶段,如下图所示。
- 数据预处理包括数据的抽取、转换和加载三个过程(ETL过程)。
- 建立数据仓库是处理海量数据的基础。
- 数据分析是体现系统智能的关键,一般采用OLAP和数据挖掘两大技术。
- 数据展现主要保障系统分析结果的可视化展示。
6.10.2. BI的实施步骤
(1)需求分析
(2)数据仓库建模
(3)数据抽取
(4)建立BI分析报表
(5)用于培训和数据模拟测试
(6)系统改进和完善
6.10.3. 数据仓库的特点
- 面向主题:数据按主题组织。
- 集成的: 消除了源数据中的不一致性,提供整个企业的一致性全局信息。
- 相对稳定的(非易失的): 主要进行查询操作,只有少量的修改和删除操作(或是不删除)。
- 反映历史变化(随着时间变化): 记录了企业从过去某一时刻到当前各个阶段的信息,可对发展历程和未来趋势做定量分析和预测。
6.11. 数据挖掘
6.11.1. 数据挖掘方法
- 决策树(构建树结构进行分析)
- 神经网络(类似统计学中的判别、回归、聚类等功能)
- 遗传算法(三个基本过程:繁殖(选择)、交叉(重组)、变异(突变))
- 关联规则挖掘算法(关联规则是描述数据之间存在关系的规则)
6.11.2. 数据挖掘分类
- 关联分析:挖掘出隐藏在数据间的相互关系。
- 序列模式分析:侧重点是分析数据间的前后关系(因果关系)。
- 分类分析:为每一个记录赋予一个标记再按标记分类。
- 聚类分析:分类分析法的逆过程。
6.12. 企业门户(Enterprise Portal,EP)
6.12.1. EP的分类
- 企业网站:注重单向信息传递,缺互动。
- 企业信息门户(EIP):把各种应用系统、数据资源和互联网资源统一集成到企业门户之下。
- 企业知识门户(EKP):企业网站的基础上增加知识性内容。
- 企业应用门户(EAP):实际上是对企业业务流程的集成。它以业务流程和企业应用为核心,把业务流程中功能不同的应用模块通过门户技术集成在一起。
企业通用门户:集以上四者于一身。
6.12.2. EP实施的关键问题
单点登录
业务流程整合
个性化配置
与企业应用系统的集成
知识转化
6.13. 电子政务和电子商务
- 电子政务的四种模式:
政府对政府(G2G)(Government To Government)
政府对企业(G2B)或B2G(Government To Business)
政府对公民(G2C)或C2G(Government To Citizen)
政府对公务员(G2E)(Government To Employee)
- 电子商务的四种形式:
企业对消费者(B2C)
企业对企业(B2B)
消费者对消费者(C2C)
线上对线下(O2O)
7. 企业应用集成(EI)
(1)表示集成
表示集成(界面集成),把各应用系统的界面集成起来,统一入口,产生“整体”感觉。
(2)数据集成
数据集成是应用集成和业务过程集成的基础。把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中,从而为企业提供全面的数据共享。ETL、数据仓库、联邦数据库都可视为数据集成。
(3)控制集成
控制集成(功能集成、应用集成)是业务逻辑层次集成,可以借助于远程过程调用或远程方法调用、面向消息的中间件等技术。
(4)业务流程集成
业务流程集成(过程集成)是进行业务流程集成时,企业必须对各种业务信息的交换进行定义、授权和管理,以便改进操作、减少成本、提高响应速度。
还有其他会用到的集成方式,如下:
消息集成:适用于数据量小、但要求频繁地、立即地、异步地数据交换场合。
共享数据库:实时性强、可以频繁交互,数据的交换属于同步方式。
文件传输:适用于数据量大、交换频度小、即时性要求低的情况
03-系统规划
1. 系统规划的主要步骤
根据系统规划的主要任务,可以按照以下步骤开展系统规划的工作:
(1)初步调查:根据企业战略目标,分析企业现状以及系统运行状况。
(2)确定系统目标:确定系统的服务范围质量等。
(3)分析子系统的组成:做系统划分并指定子系统功能。
(4)拟定系统的实施方案:分析子系统优先级,确定开发顺序。
(5)进行可行性研究:编写可行性研究报告,召开可行性论证会。
(6)制订系统建设方案:对可研报告提出的各项技术指标进行分析、比较,落实各项假设的前提条件,制订系统建设方案,形成系统设计任务书作为系统建设的依据。
2. 项目的提出与选择
项目的提出和选择包括项目立项目标和动机、立项价值判断、项目选择和确定、初步调查和可行性分析等过程。具体如下图所示:
3. 可行性研究
可行性研究也称为可行性分析,是所有项目投资、工程建设或重大改革在开始阶段必须进行的一项工作。
3.1. 可行性评价准则
(1)经济可行性
成本收益分析,包括建设成本、运行成本和项目建设后可能的经济收益。
(2)技术可行性
技术风险分析,现有的技术能否支持系统目标的实现,现有资源(员工,技术积累,构件库,软硬件条件)是否足以支持项目的实施。
(3)法律可行性(社会可行性)
不能与国家法律或政策相抵触。
(4)用户使用可行性
执行可行性,从信息系统用户的角度评估系统的可行性。
管理可行性:系统与现有管理机制的一致性,改革的可能性。
运行可行性: 用户方便使用的程度。
3.2. 可行性研究的步骤
可行性研究工作可以分为以下8个步骤:
(1)复查系统目标和规模
(2)分析现有系统
(3)导出新系统的高层逻辑模型
(4)用户复核
(5)提出并评价解决方案
(6)确定最终推荐的解决方案
(7)草拟开发计划
(8)编制和提交可行性研究报告
3.3. 可行性研究报告
在国家标准GB/T 8567-2006中,提供了一个可行性研究报告的文档模板和编写指南,其中规定了在可行性研究报告中应该包括如下内容:
(1)引言
(2)引用文件
(3)可行性研究的前提
(4)可选的方案
(5)所建议的系统
(6)经济可行性
(7)技术可行性
(8)法律可行性
(9)用户使用可行性
4. 成本效益分析
4.1 成本
- 按照投资时间分类:
(1)基础建设成本:如房屋和设施、办公设备、平台软件、必须的工具软件等。
(2)其他一次性投资:如研究咨询成本、调研费、培训费、差旅费以及其他一次性杂费。
(3)其他非一次性投资:主要是指系统的运行和维护成本,如设备租金和定期维护成本、定期消耗品支出、房屋租金、公共设施维护等。
- 按照成本性态分类:
(1)固定成本:管理人员的工资、办公费、固定资产折旧费、员工培训费、广告费、技术开发经费等。
(2)变动成本:直接材料费、产品包装费、外包费用、开发奖金等。
(3)混合成本:水电费、电话费、质量保证人员的工资、设备动力费等。
同时,还可按照直接和间接分类:
(1)直接成本:项目组人员工资,材料费用。
(2)间接成本:水电费,员工培训费。
4.2. 收益
收益可以分为有形收益和无形收益。
(1)有形收益:也称为经济收益,可以用货币的时间价值、投资回收期、投资回收率等指标进行度量。有形收益又可分为一次性经济收益和非一次性经济收益。
(2)无形收益:也称为不可定量的收益,主要是从性质上、心理上进行衡量,很难直接进行量上的比较。如服务的改进、由操作失误引起的风险的减少、企业形象的改善等。
4.3. 盈亏临界分析
盈亏临界分析又称为损益平衡分析,它主要研究如何确定盈亏临界点、有关因素变化对盈亏临界点的影响等问题。
盈亏临界点也称为盈亏平衡点或保本点,是指项目收入和成本相等的经营状态,也就是既不盈利也不亏损的状态。
有关计算公式如下:
销售额=固定成本+可变成本+利润(正常情况下)
销售额=固定成本+可变成本(盈亏平衡时)
盈亏平衡点销售量=总固定成本/(销售单价-单位变动成本)
盈亏平衡点销售额=总固定成本/(1-总变动成本/销售收入)
4.4. 净现值分析
货币的时间价值与银行利率和利息的计算方式有关。根据这一概念可以得到现值(n年后的价值折现成现在的价值)的公式为:
其中P为本金,n为年期,i为利率,F为P元钱在n年后的价值。
净现值是指项目在生命周期内各年的净现金流量按照一定的、相同的折现率折现到初时的现值之和,公式为:
其中 为第t年的净现金流量,CI为现金流入,CO为现金流出,i为折现率。
净现值表示在规定的折现率i的情况下,方案在不同时间点发生的净现金流量,折现到期初时,整个生命周期内所能得到的收益。
净现值率的公式为:
其中 为第t年的投资额。因为P>0,对于单一方案评价而言,若NPV≥0,则NPVR≥0;若NPV<0,则NPVR<0。因此,净现值与净现值率是等效的评价指标。
4.5. 投资回收期与投资回报率
(1)静态投资回收期
实用公式为:T=累计净现金流量开始出现正值的年份数-1+|上年累计净现金流量|/当年净现金流量
(2)动态投资回收期
实用公式为: =累计折现值开始出现正值的年份数-1+|上年累计折现值|/当年折现值
(3)投资收益率
投资收益率又称为投资利润率,是指投资收益占投资成本的比率。投资收益率反映投资的收益能力。其公式为:
投资收益率=投资收益/投资成本×100%
其他相关公式:
投资收益率=100%+净现值率
投资回收率=1/投资回收期×100%
投资收益率=投资回报率
总投资收益率=投资收益/投资总额×100%
(Lifetime Return of Investment)
年均投资收益率=运营期年均净收益/投资总额×100%
(Annual Return of Investment)
04-软件工程
软件工程是指应用计算机科学、数学及管理科学等原理,以工程化的原则和方法来解决软件问题的工程。其目的是提高软件生产率、提高软件质量、降低软件成本。IEEE对软件工程的定义是:将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。
1. 软件生命周期
1.1. 信息系统生命周期
信息系统的生命周期包括立项阶段、开发阶段、运维阶段和消亡阶段。其中在单个系统开发中,开发阶段又可细分为总体规划、系统分析、系统设计、系统实施和系统验收等步骤。具体如下图所示。
单个系统的各个阶段需要开展的工作和输出的文档如下图所示。
1.2. 软件的生命周期
软件产品从形成概念开始,经过开发、使用和维护,直到最后退役的全过程称为软件生命周期或生存周期。
根据国家标准GB/T 8566-2007,软件生命周期可以划分为可行性研究、需求分析、概要设计、详细设计、实现、组装测试、确认测试、使用、维护、退役十个阶段,各自分别对应于软件生存周期的基本过程,具体如下图所示。
软件生命周期与5个基本过程的对应关系
2. 软件开发方法
2.1. 形式化方法
(1)形式化方法概述
提高软件可靠性的一种重要技术是使用形式化方法。形式化方法是建立在严格数学基础上、具有精确数学语义的开发方法。广义的形式化方法是指软件开发过程中分析、设计和实现的系统工程方法,狭义的形式化方法是指软件规格和验证的方法。
(2)净室软件工程
净室软件工程(Cleanroom Software Engineering,CSE)是软件开发的一种形式化方法,可以开发较高质量的软件。净室软件工程的特点如下:
净室即无尘室、洁净室。也就是一个受控污染级别的环境。
使用盒结构规约(或形式化方法)进行分析和设计建模,并且强调将正确性验证,而不是测试,作为发现和消除错误的主要机制。
使用统计的测试来获取认证被交付的软件的可靠性所必需的出错率信息。
2.2 逆向工程
逆向工程(reverse engineering)术语源于硬件制造业相互竞争的公司为了了解对方设计和制造工艺的机密,在得不到设计和制造说明书的情况下,通过拆卸实物获得信息,软件的逆向工程也基本类似,不过,通常“解剖”的不仅是竞争对手的程序,而且还包括本公司多年前的产品。软件的逆向工程是分析程序,力图在比源代码更高抽象层次上建立程序的表示过程,逆向工程是设计的恢复过程。
一般认为,凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述。逆向工程过程能够导出多个级别的内容,随着抽象层次增高,完备性就会降低。具体包括:
实现级(底层的抽象):包括程序的抽象语法树、符号表、过程的设计表示。
结构级(稍高层次的抽象):包括反映程序分量之间相互依赖关系的信息例如调用图、结构图、程序和数据结构。
功能级(相对高层的抽象):包括反映程序段功能及程序段之间关系的信息,例如数据和控制流模型。
领域级(高层抽象):包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息,例如实体关系摸型。
3. 软件开发模型
软件开发模型大体上可分为三种类型。
第一种是以软件需求完全确定为前提的瀑布模型;第二种是在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式开发模型,例如,喷泉模型、螺旋模型、统一开发过程和敏捷方法等;第三种是以形式化开发方法为基础的变换模型。
3.1. 瀑布模型
瀑布模型是一种严格定义方法,它将软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段,形如瀑布流水,最终得到软件产品,如下图所示。
3.2. 演化模型
演化模型主要针对事先不能完整定义需求的软件开发,是在快速开发一个原型的基础上,根据用户在调用原型的过程中提出的反馈意见和建议,对原型进行改进,获得原型的新版本,重复这一过程,直到演化成最终的软件产品。
主要优点:任何功能一经开发就能进入测试,以便验证是否符合产品需求,可以帮助导引出高质量的产品要求。
主要缺点:如果不加控制地让用户接触开发中尚未稳定的功能,可能对开发人员及用户都会产生负面的影响。
3.3. 增量模型
增量模型是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。
3.4. 螺旋模型
螺旋模型是瀑布模型与演化模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。螺旋模型是一种演化软件过程模型,它将原型实现的迭代特征与线性顺序模型中控制的和系统化的方面结合起来,使软件的增量版本的决速开发成为可能。在螺旋模型中,软件开发是一系列的增量发布。
3.5. V模型
V模型是在快速应用开发模型基础上演变而来,由于将整个开发过程构造成一个V字形而得名。V模型应用在软件测试方面的开发过程和测试行为,和瀑布模型有着一些共同的特征。V模型中的过程从左到右,描述了基本其价值在于它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系,如下图所示。
3.6. 喷泉模型
喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的,就像水喷上去又可以落下来,类似一个喷泉。各个开发阶段没有特定的次序要求,并且可以交互进行,可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
3.7. 构件组装模型
构件组装模型融合了螺旋模型的许多特征。它本质上是演化的支持软件开发的迭代方法。但是,构件组装模型是利用预先包装好的软件构件(有时称为“类”)来构造应用程序的。构建组装模型的过程如下图所示。
3.8. 统一过程
-
统一过程(Unified Process,UP)是一个通用过程框架,可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的,在为软件系统建模时,UP使用的是UML。与其他软件过程相比,UP具有三个显着的特点,即用例驱动、以架构为中心、迭代和增量。
-
统一过程包括四个阶段:初始阶段、细化阶段、构建阶段和交付阶段。各个阶段对应的工作内容如下图所示。
3.9. 敏捷方法
- 敏捷方法强调,让客户满意和软件尽早增量发布;小而高度自主的项目团队;非正式的方法;最小化软件工程工作产品以及整体精简开发。
目前主要的敏捷方法有极限编程(eXtreme Programming,XP )、自适应软件开发(Adaptive Software Development,ASD)、水晶方法(Crystal)、特胜驱动开发(Feature Driven Development,FDD)、动态系统开发方法(Dynamic Systems Development Method,DSDM)、测试驱动开发(Test-Driven Development,TDD)、敏捷数据库技术(Agile Database Techniques,AD)和精益软件开发(Lean Software Development)等。虽然这些过程模型在实践上有差异,但都是遵循了敏捷宣言或者是敏捷联盟所定义的基本原则。这些原则包括客户参与、增量式移交、简单性、接受变更、强调开发人员的作用和及时反馈等。
敏捷开发的4大价值观、5大原则和12大最佳实践如下图所示。
以下介绍几种常见的敏捷方法:
- XP (Extreme Programming,极限编程)。
- Cockburn的水晶系列方法,水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样,都有以人为中心的理念,但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度纪律性不同,Alistair探索了用的最少纪律约束而仍能成功方法,从而在产出效率与易于运作上达到一种平衡。也就是说,虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。
- 开放式源码,这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处,就是程序开发人员在地域上分布很广,这使得它和其他敏捷方法不同,因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障(debug)的高度并行性,任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。
- SCRUM。 SCRUM己经出现很久了,像前面所论及的方法一样,该方法强调这样一个事实,即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中,为明确定义了的可重复的人员所用,去解决明确定义了的可重复的问题。
- Coad的功用驱动开发方法(FDD-Feature Driven Development) FDD是由Jeff De Luca和大师Peter Coad提出来的。像其他方法一样,它致力于短时的迭代阶段和可见可用的功能。在FDD中,一个迭代周期一般是两周。在FDD中,编程开发人员分成两类:首席程序员和“类”程序员((class owner)。首席程序员是最富有经验的开发人员。他们是项目的协调者、设计者和指导者,而“类”程序员则主要做源码编写。
- ASD方法,ASD (Adaptive Software Development)方法由Jim Highsmith提出,其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。
4. 软件过程管理
4.1. 软件能力成熟度模型
(1)CMM的等级(5个等级)
- 初始级
- 可重复级
- 已定义级
- 以管理级
- 优化级
(2)关键过程域
(3)能力成熟度模型集成
4.2. 软件过程评估
软件过程能力评估是根据过程模型或其他模型对组织的软件过程所进行的规范的评估。主要参考的方法有以下几种:
(1)CMM模型
(2)Trillum模型
(3)Bootstrap方法
(4)ISO/IEC 15504标准
(5)SJ/T 11234-2001标准
05-软件需求工程
1. 软件需求工程概述
1.1 概述
软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程,可分为需求开发和需求管理两大工作。
需求开发包括需求获取、需求分析、编写需求规格说明书(需求定义)和需求验证四个阶段。需求管理通常包括定义需求基线、处理需求变更和需求跟踪等方面的工作。这两个方面是相辅相成的需求开发是主线是目标;需求管理是支持是保障。如下图所示:
软件需求概念:
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需的条件或能力,是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力,以及反映这些条件或能力的文档说明。
1.2. 需求的分类
需求可以从技术维度(需求的层次)和管理维度(质量功能部署QFD)两方面进行分类,具体如下图所示:
PIECES框架:
PIECES框架是系统非功能性需求分类的技术。主要内容如下:
性能(Preformance):性能用于描述企业当前的运行效率,可以分析当前业务的处理速度。
信息(Information):信息和数据指标用于描述业务数据的输入、输出以及处理方面存在跳各种问题。
经济(Economics):经济指标主要是从成本和收益的角度分析企业当前存在的问题。
控制(Control):提高信息系统的安全和控制水平。
效率(Efficiency):提高企业的人、财、物等的使用效率。
服务((Service):提高企业对客户、供应商、合作伙伴、顾客等的服务质量。
2. 需求获取
需求获取的方法:
- 用户访谈:1对1-3,有代表性的用户。
- 问卷调查:用户多,无法一一访谈。
- 现场观摩:针对较为复杂的流程和操作。
- 联合需求计划(JRP):高度组织的群体会议,各方参与,成本较高。
- 情节串联板:一系列图片,通过这些图片来讲故事。
- 收集资料:把与系统有关的、对系统开发有益的信息收集起来。
- 参加业务实践:有效地发现问题的本质和寻找解决问题的办法。
- 阅读历史文档:对收集数据性的信息较为有用。
- 抽样调查:降低成本。样本大小=α*(可信度系数/可接受的错误)²
- 注:α一般取0.25。
可信度系数表如下所示:
例如,如果希望订单样本集包含所有情况具有90%的可信度,那么样本大小计算如下:
样本大小=0.25×(1.65/(1-0.90))²=68.0625
3. 需求分析
在软件工程实践过程中,人们提出了许多种需求分析的方法,其中主要有结构化(SA)方法、面向对象分析(OOA)方法和面向问题域的分析(Problem Domain Oriented Analysis,PDOA)方法。另外还有一些形式化方法例如VDM ( Vienna Design Method)和Z等。
3.1. 结构化分析方法(SA)
SA方法的基本思想是自顶向下,逐层分解,把一个大问题分解成若干个小问题,每个小问题再分解成若干个更小的问题。经过逐层分解,每个最低层的问题都是足够简单、容易解决的,于是复杂的问题也就迎刃而解了。在SA方法中导出的分析模型如下图所示。
SA方法分析模型的核心是数据字典,围绕这个核心,有三个层次的模型,分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中,一般使用E-R图表示数据模型,用数据流图(DFD)表示功能模型用状态转换图(State Transform Diagram,STD)表示行为模型。这三个模型有着密切的关系,它们的建立不具有严格的时序性,而是一个迭代的过程。
3.1.1. 数据字典
数据字典中一般有六类条目,分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。不同类型的条目有不同的属性需要描述。
(1)数据元素。数据元素也称为数据项,是数据的最小组成单位,例如,课程号、课程名等。对数据元素的描述,应该包括数据元素的名称、编号、别名、类型、长度、取值范围和取值的含义等。
(2)数据结构。数据结构用于描述某些数据元素之间的关系,它是一个递归的概念,一个数据结构可以包括若干个数据元素或(和)数据结构。数据结构的描述重点是数据元素之间的组合关系,即说明数据结构包括哪些成分。这些成分中有三种特殊清况,分别是任选项、必选项和重复项。
(3)数据流。数据流由一个或一组数据元素组成,对数据流的描述应包括数据流的名称、编号、简要说明、来源、去处、组成和流通量(含高峰时期的流通量)。
(4)数据存储。数据存储的条目主要描写该数据存储的结构,以及有关的数据流和查询要求。
(5)加工逻辑。需要描述加工的编号、名称、功能的简要说明、有关的输入数据流和输出数据流。对加工进行描述,目的在于使相关人员能有一个较明确的概念,了解加工的主要功能。
(6)外部实体。外部实体是数据的来源和去向,对外部实体的描述应包括外部实体的名称、编号、简要说明、外部实体产生的数据流和系统传给该外部实体的数据流,以及该外部实体的数量。
3.1.2. 数据流图(DFD)
(1)数据流图(DFD)基本概念
(2)数据流图(DFD)的层次
SA方法的思路是依赖于DFD进行自顶而下的分析。这也是因为系统通常比较复杂,很难在一张图上就将所有的数据流和加工描述清楚。因此,DFD提供一种表现系统高层和低层概念的机制。也就是先绘制一张较高层次的DFD,然后在此基础上,对其中的加工进行分解,分解成为若干个独立的、低层次的、详细的DFD,而且可以这样逐一的分解下去,直至系统被清晰地描述出来。如下图所示。
(3)数据流图的平衡原则
数据流图的平衡原则如下图所示。
3.1.3. 状态转换图(STD)
大多数业务系统是数据驱动的,所以适合使用DFD。但是,实时控制系统却主要是事件驱动的,因此,行为模型是最有效的描述方式。STD通过描述系统的状态和引起系统状态转换的事件,来表示系统的行为。此外,STD还指出了作为特定事件的结果将执行哪些动作(例如,处理数据等)。
在STD中从一个状态到另一个状态的转换用箭头线表示,箭头表明转换方向,箭头线上标上事件名。必要时可在事件名后面加一个方括号,括号内写上状态转换的条件。也就是说,仅当方括号内所列出的条件为真时,该事件的发生才引起箭头所示的状态转换。如下图为一个在线课程学习的STD示例。
3.1.4. 实体联系图(E-R图)
E-R图提供了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型。构成E-R图的3个基本要素是实体型、属性和联系。具体如下图所示。
3.2. 面向对象分析方法(OOA)
面向对象分析的基本任务是运用面向方法对问题域进行分析和理解,正确认识其中的事物及它们之间的关系,找出描述问题域和系统功能所需的类和对象,定义它们的属性和职责,以及它们之间所形成的各种联系。最终产生一个符合用户需求,并能直接反映问题域和系统功能的面向对象分析模型及其详细说明。
3.2.1. 相关概念
(1)对象:属性(数据)+方法(操作)+对象ID
(2)类:(实体类/控制类/边界类)
- 实体类映射需求中的每个实体,实体类保存需要存储在永久存储体中的信息,例如在线教育平台系统可以提取出学员类和课程类它们都属于实体类。
- 控制类是用于控制用例工作的类一般是由动宾结构的短语(“动词+名词”或‘名词+动词”)转化来的名词,例如用例“身份验证”可以对应于一个控制类“身份验证器”它提供了与身份验证相关的所有操作。
- 边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处,包括所有窗体、报表、打印机和扫描仪等硬件的接口以及与其他系统的接口。
(3)继承与泛化:复用机制
(4)封装:隐藏对象的属性和实现细节,仅对外公开接口
(5)多态:不同对象收到同样的消息产生不同的结果
(6)接口:一种特殊的类,他只有方法定义没有实现
(7)重载:一个类可以有多个同名而参数类型不同的方法
3.2.2. 统一建模语言(UML)
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言,它融入了软件工程领域的新思想、新方法和新技术,它的作用域不限于支持OOA和OOD,还支持从需求分析开始的软件开发的全过程。
(1)UML的结构
从总体上来看,UML的结构包括构造块、规则和公共机制三个部分。
- 构造块。UML有三种基本的构造块分别是事物(thing )、关系( relationship)和图( diagram )。事物是UML的重要组成部分关系把事物紧密联系在一起图是多个相互关联的事物的集合。
- 公共机制。公共机制是指达到特定目标的公共UML方法,主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制四种。
- 规则。规则是构造块如何放在一起的规定,包括范围、可见性、完整性和执行四个方面。
具体关系如下图所示:
(2)UML事物
UML中的事物也称为建模元素包括结构事物(structural things )、行为事物(behavioral things动作事物)、分组事物(grouping things)和注释事物(annotational things注解事物)。这些事物是UML模型中最基本的OO构造块。
(3)UML关系
UML用关系把事物结合在一起,主要有下列四种关系:
- 依赖(dependency)。依赖是两个事物之间的语义关系其中一个事物发生变化会影响另一个事物的语义。
- 关联(association)。关联描述一组对象之间连接的结构关系。
- 泛化(generalization)。泛化是一般化和特殊化的关系描述特殊元素的对象可替换一般元素的对象。
- 实现(realization )。实现是类之间的语义关系,其中的一个类指定了由另一个类保证执行的契约。
(4)UML图
UML2.0包括14种图,分别如下图所示:
3.2.2.1. UML-4+1视图
UML的4+1视图是指用例视图和逻辑视图、实现视图、进程视图和部署视图。
- 用户侧重于逻辑视图
- 系统工程师侧重于部署视图
3.2.2.2. 用例图
用例图是描述一组用例、参与者及它们之间的关系。主要包括参与者、用例和通信关联三种元素。
用例图的特点如下:
用户角度描述系统功能;
- 参与者是外部触发因素;
(包括用户、组织、外部系统,时间); - 用例是功能单元。
- 用例图的关系包括:包含关系、扩展关系和泛化关系。
包含关系: 其中这个提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用例系:当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。图例如下所示:
扩展关系: 如果一个用例明显地混合了两种或两种以上的不同场景,即根据情况可能发生多种分支,则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰。图例如下所示:
泛化关系:当多个用例共同拥有一种类似的结构和行为的时候,可以将它们的共性抽象成为父用例,其他的用例作为泛化关系中的子用例。在用例的泛化关系中,子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。图例如下所示:
三种关系的示例如下所示:
用例建模的流程如下:
- 识别参与者(必须);
- 合并需求获得用例(必须);
- 细化用例描述(必须);
- 调整用例模型(可选)
3.2.2.3. 类图与对象图
类图(class diagram):类图描述一组类、接口、协作和它们之间的关系。
对象图(object diagram):对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。
四种关系及图例如下所示:
3.2.2.4. 顺序图
顺序图(sequence diagram,序列图)。顺序图是一种交互图(interaction diagram),它强调对象之间消息发送的顺序,同时显示对象之间的交互。如下图所示。
3.2.2.5. 通信图(协作图)
通信图(communication diagram)。通信图也是一种交互图,它强调对象之间存在的消息收发关系,而不专门突出这些消息发送的时间顺序。如下图所示。
3.2.2.6. 定时图
定时图也叫计时图,也是一种交互图,用于展示交互过程中的真实时间信息,具体描述对象状态变化的时间点以及维持特定状态的时间段。如下图所示。
3.2.2.7. 状态图
状态图(state diagram)是对类描述的补充。用于展现此类对象所具有的可能状态,以及某些事件发生时其状态转移情况。如下图所示。
3.2.2.8. 活动图
活动图(activity diagram)是一种特殊的状态图。活动图描述一个操作中要进行的各项活动的执行流程。同时,也常被用来描述一个用例的处理流程或者某种交互流程。
活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。它强调对象间的控制流程。如下图所示。
3.2.2.9. 构件图
构件图(component diagram)。构件图描述一个封装的类和它的接口、端口,以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说,构件图是很重要的。构件图是类图的变体。如下图所示。
3.2.2.10. 部署图
部署图(deployment diagram)。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图,通常一个节点包含一个或多个部署图。如下图所示。
3.2.3 需求建模
需求建模包括用例模型和分析模型,具体内容如下图所示。
4. 需求定义
需求定义的过程也就是形成需求规格说明书的过程,通常有两种需求定义的方法,分别是严格定义方法和原型方法。具体如下图所示:
5. 需求验证
需求验证的流程如下图所示。
6. 需求管理
6.1. 定义需求基线
基线是一个软件配置管理的概念,它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义,基线是指已经通过正式评审和批准的规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变更控制系统进行变化。在软件工程范围内,基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且已经经过正式技术评审而获得认可。
需求状态的变化如下图所示:
6.2. 需求跟踪
根据国家标准GB/T 8567-2006,软件需求规格说明书(SRS)中的每个软件配置项的需求到其涉及的系统(或子系统)需求都要具有双向可追踪胜。所谓双向跟踪,包括正向跟踪和反向跟踪,正向跟踪是指检查SRS中的每个需求是否都能在后继工作成果中找到对应点;反向跟踪也称为逆向跟踪,是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。具体来说,需求跟踪涉及五种类型,如下图所示。
6.3. 需求风险管理
以下为带有风险的做法:
- 无足够用户参与
- 忽略了用户分类
- 用户需求的不断增加
- 模棱两可的需求
- 不必要的特性
- 过于精简的软件需求规格说明书(SRS)
- 不准确的估算
06-软件架构设计
1. 软件架构的概念
架构设计就是需求分配,即将满足需求的职责分配到组件上。如下图所示。
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包合一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件架构是项目干系人进行交流的手段j明确了对系统实现的约束条件,决定了开发和维护组织的组织结构,制约着系统的质量属性。
软件架构使推理和控制的更改更加简单,有助于循序渐进的原型设计,可以作为培训的基础。
软件架构是可传递和可复用的模型通过研究软件架构可能预测软件的质量。
2. 软件架构风格
(1)架构设计的一个核心问题是能否达到架构级的软件复用。
(2)架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个构件有效地组织成一个完整的系统。
(3)架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
2.1. 经典架构风格
经典架构风格包括以下几种:
- 数据流风格:批处理序列、管道-过滤器
- 调用/返回风格:主程序/子程序、面向对象、层次结构
- 独立构件风格:进程通信、事件驱动系统(隐式调用)
- 虚拟机风格:解释器、基于规则的系统
- 仓库风格:数据库系统、超文本系统、黑板系统
2.2. 层次架构风格
层次架构风格包括以下几种:
二层架构
三层C/S架构(包括表示层、功能层和数据层)
B/S架构