01 - 系统开发项目环境
整体描述,包括1) 系统参与者;2) 信息系统构件;及 3) 项目管理和过程管理办法。
1-1 系统分析和设计方法的环境
关注点: 1) 信息系统类型,2) 系统参与者,3) 系统的驱动力及 4) 系统的开发过程。
系统的定义 :由许多可以交互的构件组成,构件一起工作实现系统参与者所要求的结果。
常见信息系统(Information System, IS)分类 :
- 事务处理系统 - 处理企业事务,如订单、即使卡片、支付和预定。 | 数据 -> 事务
- 管理信息系统 - 使用事务数据产生管理者管理企业所需的信息。 | 数据 -> 管理信息
- 决策支持系统 - 辅助决策人员决策。 | 数据 -> 决策信息
- 主管信息系统 - 专门按照主管特殊信息需求进行裁剪,为企业指定规划、评估效益。 | 数据 -> 规划评估
- 专家系统 - 捕捉并加工专家/决策者的知识,并模拟那些专家的“思想”。 | 知识 -> 思想
- 通信和协作系统 - 提高人与人之间的通信协作水平。 | 数据流动
- 办公自动化系统 - OA 改进人与工作流之间的关系。 | 工作流
1-1-1 系统关联人员
- 系统所有者 - 为构造和运营的系统付费。视角: 开销和收益
- 系统用户 - 确定系统业务需求和预期。视角: 系统功能
- 系统内部(占大多数)- 办事员/服务人员、技术人员/专业人员、主管、经理。
- 系统外部 - 顾客、供应商、合作伙伴、雇员。
- 设计人员 - 将业务需求转换为可行的技术方案。视角:实现的**可行性**。
- 数据库管理员、Web架构师、图形艺术师、安全专家、技术专家。
- 构造人员 - 构建、部署、维护和运营。视角:实际软硬件,**技术逻辑**。
- 系统程序员、应用程序员、数据库程序员、网络管理员、安全管理员、Web站点管理员、软件集成员。
- 系统分析员 - 既懂业务又懂计算机技术,将**业务知识转换成 IS 的规格说明**。
- 可以分散于各个职能部门和主管部门;也可成为专门的小型部门。
- 外部服务提供者 - 任何一个关联人员的角色都可以由内部工作人员/外部工作人员充当。
- 咨询顾问、技术工程师、销售工程师、系统顾问、签约程序员和系统集成人员等。
- 项目经理 - 团队领导,整体把控。
1-1-2 现代信息系统的驱动力
1-1-2-1 业务驱动
业务驱动关系企业发展趋势。
Ex. 经济全球化;电子商务和电子业务;安全和隐私;协作与合作经营;知识产权管理;持续改进(业务升级);全面质量管理;业务过程重构。
1-1-2-2 技术驱动
信息技术的进步也助力于IS的发展。
Ex. 网络和因特网(5G, Wifi6);对象技术;协作技术;企业应用软件等
1-1-3 系统开发过程
即项目管理和过程管理。
- 系统启动 - 确定问题/问题陈述 和 项目计划。
- 确定问题 及 技术方案
- 确定范围、目标、进度和预算
- 系统分析 - 业务问题方案的需求、预期和优先级。
- 交付需求规格说明书
- 系统设计 - 实现业务需求的方案的技术蓝图和规格说明
- 实现系统所需的技术和环境
- 系统的架构/体系结构
- 系统实现 - 按照技术体系结构和规格说明,实现方案
- 编码、测试、部署、运维……
1-2 信息系统构件
关注点:从架构角度看待信息系统;信息系统的三个目标——知识、过程、通信。
注:构件间相互链接;不同类型构件中,底层(技术)构件支撑上层(业务)构件,业务为技术提供方向。
1-2-1 “知识”构件
目标:提高业务知识。 数据 -> 信息 -> 知识 -> 公司实现任务目标。
- 信息范围和构想 | 系统所有者 - 【粗线条的蓝图轮廓】
- 关心整体,忽略细节。只关心业务知识,有助于决策、实现组织的任务、目的和目标,提高竞争力。
- 业务知识:业务实体 - 业务规则
- 业务数据需求 | 系统用户 - 【蓝图的效用】
- 数据属性
- 维护数据的精确业务规则
- 数据库设计 | 设计人员 - 【资源布局和规划】
- 使用数据库存储业务数据及分析计算得到的业务知识
- 数据需求转换为数据库设计
- 数据库方案 | 构造人员 - 【绘制细节、技术】
- 离DBMS最近
1-2-2 “过程”构件
目标:改进提升业务和服务过程。业务过程保证信息系统预期的实现,即系统的工作。
- 功能范围和构想 | 系统所有者
- 整体业务功能
- 业务过程需求 | 系统用户
- 策略:执行某个业务过程时必须遵守的规则
- 规程:执行业务过程遵守的精确步骤
- 业务过程设计/软件设计 | 设计人员
- 输出:软件规格说明书
- 实现系统用户的业务过程需求
- 提供用于同构造人员交流软件设计的足够细节和一致性
- 商用软件包/定制应用程序 | 构造人员
- 使用编程语言、软件开发环境 描述 业务过程
1-2-3 “通信”构件
目标:改进雇员与其他部门之间的企业内部通信和协作。提供给系统用户的有效通信接口 + 提供同其他信息系统的有效接口。
- 通信范围和构想 | 系统所有者
- 新系统为哪些部门、用户/客户/外企提供接口?
- 新系统与其他信息系统接口?
- 用户/系统在企业内外部分布情况?
- 业务接口需求 | 系统用户
- 信息系统的输入和输出
- 数据录入或表示方式、风格、操作
- 接口设计 | 设计人员
- 交互方式
- 一致性、兼容性、容错性、完整性
- 接口方案 | 构造人员
- 构造、安装、测试
- *中间件
1-3 信息系统开发
关注点:系统的生命周期(转换和报废),系统开发方法以及系统的质量管理和评估(CMM标准)。
使用一致的系统开发过程能够 1) 提高效率,管理层可在项目间调动资源;2) 产生一致性文档,便于维护,减少了维护系统的生命周期费用;3) 形成相对统一可量化的质量评估标准。
1-3-1 能力成熟度模型 CMM
能力成熟度模型(Capability Maturity Model, CMM)用来评估组织的信息系统开发以及管理过程和产品的成熟度等级的框架,共五个等级。其中每个等级都是下一等级的先决条件。
- 第一级——初始级(混乱状态)
- 系统开发项目无规定过程可遵循
- 每个开发团队都使用自己的工具和方法
- 项目成败主要取决于项目团队的技能和经验
- 第二级——可重复级
- 已建立项目管理过程和实践来跟踪项目费用、进度和功能
- 总使用某个固定系统开发过程,但项目与项目间可能不同
- 项目成败仍取决于项目团队的技能和经验
- 第三级——已定义级
- 组织开发/购买了标准的系统开发过程,集成到组织的信息系统/服务部门中
- 所有项目都会产生一致且高质量的文档和交付成果
- 开发过程稳定、可预测、可重复
- 第四级——已管理级
- 组织建立了可度量的质量和生产率目标
- 收集度量数据,分析并提高项目管理水平
- 管理层更加主动应对系统开发问题
- 第五级——优化级
- 标准化的系统开发过程被连续地监督和改进
- 吸取经验教训及时调整优化
1-3-2 系统的生命周期
开发阶段 | 运维阶段 | |
---|---|---|
生命周期阶段 | — 转换 —> | 生命周期阶段 |
系统开发 | 系统运行和维护 | |
使用系统开发方法 | <— 报废 — | 使用系统选择的信息技术 |
1-3-3 系统的开发方法
一些例子:结构化快速应用开发(Architected RAD)、动态系统开发方法(DSDM)、联合应用开发(JAD)、信息工程(IE)、快速应用开发(RAD)、Rational 统一开放过程(RUP)、结构化分析和设计、极限编程(XP)等
1-3-3-1 基本原理
- 让系统用户参与
- 使用一套问题解决步骤
- 确立开发阶段和开发活动
- 在开发过程中记录文档
- 建立标准
- 管理开发过程和项目
- 将信息系统作为重要的投资看待
- 不怕项目撤销和返工
- 分而治之
- 设计系统考虑扩展和变化
1-3-3-2 系统开发过程
① 项目确定 - PIECES问题解决框架
- P - Performance 改进性能的需要
- I - Information 改进信息和数据的需要
- E - Economics 改进经济、控制成本和增加收益的需要
- C - Control 改进控制或安全的需要
- E - Efficiency 改进人与过程的效率需要
- S - Service 改进对客户、供应商、合作伙伴、雇员的服务的需要
② 项目阶段
- 项目启动
- 范围定义 - 确定问题 及 问题/项目的约束条件【发布 工作任务说明(开发合约/协议)】
- 问题分析 - 对问题的全面理解,项目的复杂程度 项目进度【发布 系统改进目标】
- 系统分析
- 需求分析 - 确定业务需求及其优先级【发布 业务需求说明】
- 逻辑设计 - 将需求转化为系统模型,验证需求一致性、完整性【发布 逻辑设计模型和规格说明】
- 逻辑数据模型;逻辑过程模型;逻辑接口模型
- 决策分析 - 确定候选方案、分析可行性并推荐合适方案【发布 应用架构】
- 系统设计
- 物理设计和集成 - 类比数据库设计中的物理设计【发布 物理设计模型和规格说明、设计原型、重新设计的业务流程】
- 数据库的物理设计指 数据库存储结构和存储路径的设计
- 构建和测试 - 以上述设计为蓝本构建并测试系统组件【发布 系统功能 + 最终文档】
- 帮助系统、培训手册、帮助中心支持、生产控制指令
- 物理设计和集成 - 类比数据库设计中的物理设计【发布 物理设计模型和规格说明、设计原型、重新设计的业务流程】
- 系统实现
- – (同上) 构建和测试
- 安装和发布 - 将系统从开发环境安装到运行环境中【发布 系统 + 培训手册 + 生产控制手册】
- 运行和维护 -
③ 跨生命周期活动
- 调查研究 - 贯穿于 决策分析、设计、构建和测试及安装发布等各个阶段
- 记录文档和演示汇报 - 复用 及 项目返工
- 可行性分析 - 技术可行性、运行可行性、经济可行性、进度可行性和风险可行性等
- 项目管理和过程管理
④ 顺序开发和迭代开发 - 【软件工程】中详述
- 顺序开发 - 瀑布开发方法(瀑布模型)
- 迭代开发 - 增量开发过程
1-4 项目管理
项目管理技能在信息技术界有很大需求,是系统开发的自然拓展。
关注点:区别项目管理和过程管理;项目管理基本功能及项目经理基本能力;项目管理基本工具(PERT图和甘特图)。
1-4-1 项目管理 vs 过程管理
项目(Project)是一个(临时的)唯一的、复杂的和关联的具有统一目标或目的并且必须在特定时间里、预算内、按照规格说明要求完成的活动序列。
项目管理(Project Management)是在指定时间内用最少的费用开发可接受的系统的管理过程,内容包括确定范围、计划、人员安排、组织、指导和控制。
过程管理(Process Management)是持续记录、管理和改进系统开发过程的活动。
1-4-2 项目管理知识体系
项目管理学会发表了项目管理知识体系(Project Management Body of Knowledge, PMBOK),用于职业项目经理的教育和认证。
1-4-2-1 项目经理能力
- 业务能力:熟悉业务,保持同业务伙伴的关系,保证质量 | 业务经验
- 问题解决能力:主动性,信息收集,分析思维,理论思维 | 业务经验
- 影响能力:了解人际关系、组织,预测结果的能力,充分利用影响力 | 业务经验
- 管理者能力:激励他人,交流技能,促进他人发展 | 业务经验 + 项目经验
- 自我管理能力:自信,管理压力,关心信誉,灵活性 | 业务经验
1-4-2-2 项目管理职能
- 确定范围 - 确定项目的边界
- 计划 - 计划项目所需的任务
- 估算 - 时间(重叠?)、人力、物力、财力
- 调度 - 项目进度表
- 组织 - 分配合适的角色、职责,汇报工作
- 指导 - 人员管理能力,协调、协商、激励、忠告、赞赏和奖励
- 控制 - 监督和报告项目进展,目标、进度、费用,及时调整
- 项目总结 - 总结经验教训
1-4-2-3 工具技术 - PERT&Gantt图
PERT(项目评估于评审技术,Project Evaluation and Review Technique)图是一种图形化的网络模型,描述一个项目中任务之间的关系。用来在任务被调度前弄清项目任务之间的依赖关系。
Gantt图是一种简单的水平条形图,以一个日历为基准描述项目任务。可以清楚显示重叠任务,即可以同时执行的任务。简洁——容易学习、阅读、制作和使用。
1-4-3 项目管理生命周期
1-4-3-1 协商范围
定义项目的边界——明确业务边界,需要研究、分析、设计、构造、实现并最终得到改进。
协商——产品、质量、时间、费用、资源。
1-4-3-2 确定任务
工作分解结构(Work Breakdown Structure, WBS)将项目层次化地分解成开发阶段、开发活动和开发任务。在WBS中包含特殊任务——里程碑,用来标识项目开发期间主要交付成果地完成或结束的时间。
1-4-3-3 估计任务工期
给定详细程度合适的工作分解结构,PM必须估计每个开发任务的工期。
1-4-3-4 说明任务之间的依赖关系
里程碑几乎总有几个前导任务。项目的调度——正向调度、反向调度。
- 正向调度建立项目开始日期,然后从这个日期开始向前安排进度。
- 反向进度建立项目最后期限,然后从这个日期开始向后安排进度。
1-4-3-5 分配资源
资源分配——人、服务、工具和设备、供应和材料、经费。
1-4-3-6 指导团队工作
呃(⊙﹏⊙),给项目领导的十条提示:
- 保持一致;2) 提供支持;3) 不要给出你做不到的承诺;4) 公开表扬,私下批评;5) 掌握士气;6) 设置现实的最后期限;7) 设定可见的目标;8) 解释并说明,而不仅仅是做;9) 不要依赖差不多的[状态报告];10) 鼓励良好的团队精神。
1-4-3-7 监督和控制进展
监督进展是否符合范围、进度和预算。必须汇报进展情况,需要时调整范围、进度和资源。
变更管理——保护项目经理和团队不因范围变化而导致进度延后和预算超支困扰。
预期管理——预期管理矩阵
成果度量 \ 优先权 最大或最小 受限 可接受 费用 进度 范围 or/and 质量
进度调整——关键路径分析。
1-4-3-8 评估项目结果和经验
- 最终产品是否满足用户·预期or超过用户预期
- 项目是否符合进度要求
- 项目是否在预算范围内
02 - 系统分析方法
系统分析(System Analysis)是一种问题解决技术,将一个系统分解成各个组成部分,研究各个部分如何工作、交互,以实现其系统目标。
系统分析阶段是一个项目中的关键阶段,需要分析现有业务系统,理解其中的问题,定义改进目标,并确定后续技术方案必须实现的详细业务需求。
分析过程:分析业务 —> 确定问题 —> 定目标/业务需求。
分析方法:结构化分析、信息工程、获取原型 和 面向对象分析。
参与人员:系统所有者;系统用户;PM;系统分析员。
涵盖内容:范围定义;问题分析;需求分析;【系统分析】(逻辑设计;)决策分析【系统分析向系统设计转换】。
- 范围定义阶段(2-3天)
- 列出问题和机会
- 协商初步范围
- 评估项目价值
- 计划项目进度表和预算
- 汇报项目计划
- 交付成果:项目章程(定义了项目范围、计划、方法学、标准等内容) - 项目的第一个里程碑
- 问题分析阶段
- 研究问题领域
- 分析问题和机会
- 分析业务过程
- 制定系统改进目标
- 修改项目计划
- 汇报调查结果和建议
2-1 需求获取
系统分析员确定、分析和理解系统需求的过程和技术。
主要内容:(⊙﹏⊙) 功能需求(必须实现的功能) + 非功能(性能)需求(具备的质量/属性)。
联合需求计划(Joint Requirements Planning, JRP)是一个过程,其中高度结构化的小组会议被用来分析问题并定义需求。
2-1-1 获取过程
- 发现和分析问题
- 获取需求
- 归档和分析需求
- 需求管理
2-2 模型驱动分析
结构化分析、信息工程、面向对象分析
2-2-0 基于用例建模
用例建模(Use-Case Modeling)描述系统与外部其他系统以及用户之间交互的图像。即描述了谁使用系统,以何种方式与系统交互。
促进了以用户为中心的开发办法。
示例:
2-2-1 数据建模和分析
数据建模是一种为数据库定义业务需求的技术。或称数据库建模。
目标:为数据库实现提供基础。
具体操作为实体关系图(Entity Relationship Diagram, ERD),按照数据描述的实体和关系来刻画数据。
示例:
2-2-1-1 数据模型标准
- 简单
- 无冗余
- 可扩展
数据分析是用来改进一个数据模型的技术。
2-2-1-2 第一二三范式
① 1NF - 每个字段都是单一属性
② 2NF - 非主键字段都依赖主键
③ 3NF - 非主键字段不相互依赖
2-2-2 过程建模
关注点:定义系统建模;区分逻辑系统模型和物理系统模型;绘制数据流图。
逻辑模型(Logical Model)描述了系统是什么/做什么的非技术的图形化表示。
物理模型(Physical Model)展示系统是什么和做什么及如何实现的图形化表示。
2-2-2-1 数据流图
数据流图(Data Flow Diagram, DFD)用来描述通过系统的数据流及系统实施的工作或处理过程的工具。
示例:
2-2-3 基于UML面向对象分析和建模
统一建模语言(Unified Modeling Language, UML)是一套使用对象说明描述软件系统的建模规则/语言。
面写对象分析(Object-Oriented Analysis, OOA)用于 1) 研究现有对象;2) 定义各种新对象和修改的对象。
*【软件工程】中详述。
2-3 决策分析
确定候选方案并分析 —> 推荐最佳方案
交付成果和里程碑:能够实现各阶段确定业务需求的系统方案建议。
- 确定候选方案
- 分析候选方案
- 修改项目计划
- 推荐最佳方案
2-3-1 可行性分析和系统方案建议
可行性是组织将要开发的信息系统的价值或实用性的度量。
关注点:可行性评价准则,包括运行可行性、技术可行性、进度可行性和经济可行性。
可行性的六个准则:
- 运行可行性
- 文化/政治可行性
- 技术可行性
- 进度可行性
- 经济可行性
- 法律可行性
03 - 系统设计方法
系统设计包括准备基于计算机的详细规格说明,该规格说明实现了系统分析和系统原型构造期间说明的需求。
系统设计包括配置、获取和设计与集成阶段。
★ 系统分析关注业务问题,系统设计专注于系统的技术性/实现方面。
系统设计方法:
模型驱动设计强调通过绘制图形化系统模型描述新系统的技术或实现。
- 结构化设计 - 面向过程
- 自顶向下;模块 高内聚低耦合。
- 信息工程 - 数据为中心
- 模型驱动,数据为主,过程敏感
- 原型化 - 用户参与
- 设计出一个只有界面的系统原型
- 面向对象设计
- 尽可能消除“数据”和“过程”内容的分离
3-1 应用架构和建模
应用架构按照数据、过程、接口和网络组件定义了一个、多个或者多有信息系统使用/用于系统构造的技术。
关注点:物理过程模型;包括各种将知识、过程和通信分布到一个分布式计算环境中的技术;物理数据流图。
物理DFD vs 逻辑DFD
3-1-1 信息技术架构
信息系统框架为理解IT架构提供了一个合适的框架。
- 分布式系统
- 集中式(少用)(通常是大型主机)
架构策略
- 企业应用架构策略
- 战术应用策略
建模信息系统应用架构
- 绘制物理数据流图
- 概要计划
- 根据逻辑数据模型/逻辑过程模型以创建一个概要计划
- 网络架构
- 数据分布和技术确定
- 过程分布和技术确定
- 人/机边界
3-2 数据库设计
目标:数据的有效存储、修改和访问;数据可靠性;数据库可适应性和可扩展性;满足业务需求。
- 数据库模式 - 数据库的物理模型/蓝图
- 每个基本实体、关联实体 和 弱实体 都被实现成一个表
- 超类/子类实体表示统一(非必要填默认)
- 评价并说明访问完整性约束
- 数据完整性和访问完整性
- 键完整性
- 域完整性(合适控制每个字段有合法值)
- 访问完整性
- 角色 - 外键
- 数据库分布和复制
- 集中 部署在单个服务器上
- 水平分布 每个表(或表中的整个行)分配到不同的数据库服务器和地点。
- 需要综合多个站点数据的管理分析
- 将数据重新整合不易
- 垂直分布 在多个地点物理重复整个表
- 协调对复制表和记录的修改,维护完整性
- 高性能、可访问性好
- 增加数据完整性的复杂度
- 数据库原型
- 规划数据库容量
- 数据库结构生成
3-3 接口设计
关注点:设计计算机输入 / 输出及用户界面。
3-3-1 输入/输出设计
信息系统 <—-> 人
信息系统 <—-> 信息系统
3-3-1-1 数据收集、录入和处理
- 数据收集 新数据的标识和获取
- 数据录入 把源数据和文档翻译成计算机可读格式
- 数据处理
- 批处理 - 对某对象进行批量的处理
- 联机处理 - 信息从产生地输入系统,处理结果送到需要信息的地点
- 远程批处理 - 数据成批次收集不立即处理
- 输入方法和实现
- 键盘;鼠标;触摸屏;声音;光标;电磁;生物识别
3-3-1-2 输出分类及受众
- 内部输出 | 面向内部系统所有者和组织内的系统用户
- 详细报告 - 基本不过滤的信息
- 总结报告 - 管理人员
- 例外报告 - 作为信息显示给管理人员之前过滤数据
- 外部输出 | 面向客户、供应商、合作伙伴和政府部门
- 总结 / 报告业务事务
- 回转输出 | 最终重新进入系统作为输入的外部输出
输出方法:打印输出;屏幕输出;销售点(Point-Of-Sale, POS)终端;多媒体;电子邮件;超链接;微缩胶片。
3-3-2 用户界面设计
将输入设计与输出设计集成为一个完整的用户界面。
用户界面为用户提供友好的使用方式,用户通过用户界面同应用程序打交道,处理输入、获得输出。
3-3-2-1 涉及内容
- 计算机用户类型
- 专家用户
- 初学者用户
- 人的因素
- 理解用户及其任务
- 用户参与
- 在实际用户中测试
- 迭代设计
- 人类工程学
- 系统总明确下一步内容
- 屏幕应被规格化显示
- 提示设计及时间
- 默认值
- 容错性/提示错误
- 对话语气和词汇
3-3-2-2 涉及技术
- 操作系统和Web浏览器
- 显示器
- 键盘和触屏设备
3-3-2-3 风格
- 窗口和框
- 基于菜单的界面
- 基于指令的界面
- QA对话
- 特殊考虑
3-3-3 原型化
使用原型化工具设计输入输出的形式和方法,例如 Access,Axure Axure RP。
3-4 面向对象设计和建模
关注点:区分实体类、接口类、控制类、持续类和系统类;理解依赖关系和导航关系;理解对象;时序图、状态图;设计模式。
3-4-1 面向对象设计
面向对象设计(Object-Oriented Design, OOD)用协作的对象、对象的属性和方法说明软件解决方案的一种方式,其目标是说明系统的对象和消息。
类和对象
- 实体类 | 通常对应现实生活中的实体
- 描述不同实体不同实例的信息(属性)
- 封装维护其信息或属性的行为(方法)
- 接口类 | 描述用户直接同系统交互的用例功能
- 控制类 | 与实体类通信,并处理消息
- ★ 持续类 | 将读写数据库功能独立到持续类(数据访问类)
- 实体类中立;复用性高
- ★ 系统类 | 将其他对象从操作系统相关功能独立分开
*总结:高内聚、低耦合
设计关系
关联关系、聚合关系、泛化/特化关系
- 依赖关系
- 一个类中的变化会影响另一个类
- 支持一持久类和临时类之间的关系
- 导航能力
- 一个类向另一个类发送消息
属性和方法的可见性
- 公开 public
- 保护 protect | 自己和其子类
- 私有 private
3-4-2 设计过程
- 对用例模型交易精炼反映实现环境
- 建模支持用例情境的对象交互、行为和状态
- 修改对象模型以反映现实环境
3-4-3 设计模式
面向对象开发人员通过使用设计模式寻求复用机会。
创建型 | 结构型 | 行为型 |
---|---|---|
抽象工厂(Abstract Factor) | 适配器(Adapter) | 责任链(Chain of Responsibility) |
构造器(Builder) | 桥接(Bridge) | 命令(Command) |
工厂方法(Factory Method) | 组合(Composite) | 轻量(Flyweight) |
原型(Prototype) | 装饰(Decorator) | 解释器(Interpreter) |
单例(Singleton) | 外观(Facade) | 迭代(Iterator) |
代理(Proxy) | 中介(Mediator) | |
纪念(Memento) | ||
观察者(Observe) | ||
状态(State) | ||
策略(Strategy) | ||
模板方法(Template Method) | ||
访问者(Visitor) |
04 - 系统实现和运维
系统开发的最后阶段,系统运行后的后续支持活动。
- 从物理设计说明构造系统以及构造后的系统投入实现的过程
- 对应用系统的四类系统支持
4-1 系统构造和实现
关注点:
系统构造是系统组件开发、安装和测试。系统实现是交付系统投入运行。
4-1-1 构造阶段
- 构建和测试网络
- 构建和测试数据库
- 安装和测试新软件包
- 编写和测试新程序
- 设计系统分析员、设计人员、构造人员
- 备份主程序员、程序资料员、程序员和专家
- 测试
- 模块测试
- 单元测试
- 系统测试
4-1-2 实现阶段
- 进行系统测试
- 软件包、定制程序 任何包含新系统的现有程序都必须测试确保能够一起工作
- 准备转换计划
- 突然切入
- 并行转换
- 位置转换
- 分阶段转换
- 安装数据库
- 培训用户
- 转换新系统
4-2 系统运行和支持
系统运行是个持续性的活动,在这个过程中系统运行直至被替换。
4-2-1 系统运行和支持的上下文
所有的系统知识和系统的工作组件对于其不断地运行和支持都很重要。
4-2-1-1 三类数据存储
- 资料库 - 存储积累的系统知识——系统模型、详细说明和其他任何系统开发期间积累的文档
- 程序库 - 存储所有应用程序,源代码在系统生命周期中维护
- 业务数据 - 由生产应用系统创建和维护的所有实际业务数据(常规文件、关系数据库、数据仓库和对象数据库)
4-2-1-2 四类支持活动
- 程序维护 - 测试期间未发现的软件缺陷/错误
- 系统恢复 - 系统失效可能导致程序崩溃或数据损失
- 任务错误、硬件错误、软件错误
- 技术支持 - 培训手册/说明文档 以外的额外帮助
- 系统改进 - 新的业务问题、业务需求、技术问题、技术需求
【完】