第三章 信息系统开发

• 如果项目不再可行就取消它； • 如果项目范围增加了，就重新评价并调整费用和进度； • 如果不能改变项目预算和进度，并且项目预算和进度不足以实现所 有的项目目标，就减少范围。
• 不必害怕取消和返工
3.1.3 系统开发基本原理
• 分而治之：通过不断的将一个大系统分解 成更容易管理的小系统，分析员可以简化 问题解决的过程 • 设计系统时应考虑到增长和变化：企业在 不断的变化，业务需求在变，业务的优先 次序在变。相应的，支持业务的信息系统 也必须不断变化。
3.2 FAST系统开发过程
FAST
3.2.1项目确定 3.2.2项目阶段 3.2.3跨生命周期活动
3.2.1 项目确定
项目的推动力
解决问题 利用机会 执行指示
PIECES框架
性能Performance 信息Information 经济Economics 控制Control 效率Efficiency 服务Service
3.2.2 FAST项目阶段
经典项目阶段： 范围定义阶段 问题分析阶段 需求分析阶段 逻辑设计阶段 决策分析阶段 物理设计和集成阶段 构造和测试阶段 安装和发布阶段
3.2.2 项目阶段
3.2.3 跨生命周期活动
调查研究（信息收集和数据收集）：调查研究 对于一个项目的早期阶段至关重要。 记录文档和演示汇报：这两种沟通技术在系统 开发项目中很常见。
–更快实现系统 –许多企业没有能力提供人力和专业知识开发内部 方案 –将开发费用平摊到客户 –软件供应商负责对软件进行改进和修改 –利用同行业的相似性，减少重复开发
缺点
– 形成对供应商的依赖 –购买系统很少能反映理想方案 –改善业务过程以适应软件会遇到阻力
3.3.4混合策略
• 任何一个项目都可以选择使用多条开发路线的组 合 • 使用什么开发路线总是在范围定义阶段期间进行 选择，并作为工作陈述的一部分进行协商 • 一种常见的混合了模型驱动开发路线和快速应用 开发路线的策略是增量开发策略。
使用全面规格说明，容易正确地构造系统
缺点：
项目持续时间长，需要时间收集实事、绘制和验证模型
模型能达到的需求理解程度最多和用户理解程度一样 降低用户在项目中的主动参与 不够灵活，用户在设计之前必须完全说明需求，设计必须完全记录
下技术说明才能构造
3.3.1模型驱动开发策略
三种流行的模型驱动开发技术：
– CASE工具的一种能力，能够直接从系统模型生成初始 的软件或者数据库代码。
逆向工程 – CASE工具的一种能力，能够直接从软件或者数据库代 码生成初始的系统模型。
3.4.1计算机辅助系统工程
3.4.2 应用开发环境
应用开发环境 Application development environments (ADEs)
3.3.5 系统维护
3.4 自动化工具和技术
3.4.1 计算机辅助系统工程 3.4.2 应用开发环境 3.4.3 过程和项目管理器
3.4.1 CASE
Computer-aided software engineering (CASE) –使用支持系统模型的绘图和分析的自动化工具。有 些CASE 工具提供原型和代码产生能力。 CASE 资料库（CASE repository ） –系统开发人员的数据库，存储系统模型、详细描述和说 明、以及系统其他开发产品的地方。也称字典或者百科 全书。 正向工程
3.4.3 过程和项目管理器
过程管理软件 Process manager application
– 自动化工具，帮助记录文档并管理方法学和路线 及其交付成果和质量管理标准。也称methodware.
项目管理软件 Project manager application
–自动化工具，帮助规划系统开发活动、估计和分派 资源（人力和经费）、调动活动和资源、按照进度和 预算监控进展、控制和修改进度资源、以及报告项目 进展。
– 集成化的软件开发工具，提供了以最快速度和最高 质量开发新系统程序所需要的全部工具。也称集成开发 环境 integrated development environment (IDE) ADE 工具:
•程序语言或者解释器 •界面构造工具 •中间件 •测试工具 •版本控制工具 •帮助文件著作工具 •资料库链接
600 143 80
5.5 1.3 .728
1.8 .96 .518
3.1.2系统生命周期与开发方法
转换 Life cycle stage Life cycle stage 系统生命期
系统开发
运行与维护
使用系统选择的IT
使用系统开发方法学
报废
系统生命周期
3.1.2系统生命周期与开发方法
• 系统开发方法是一个十分正式且精确的系统开发过程，它 为系统开发人员和项目管理者定义了一组活动、方法、最 佳实践、交付成果和自动化工具，用来开发和维护大部分 或所有的信息系统和软件。 • 系统开发方法确保：
3.1.1能力成熟度模型
3.1.1 能力成熟度模型
初始级:
–系统开发项目没有规定的过程可以遵循 –开发成败主要取决于项目团队的经验和技能 –项目开发过程不可预测、不可重复 –项目之间的文档不一致
可重复级:
– 建立项目管理过程和实践跟踪项目成本、进度、功能 –组织采用开发过程，但项目与项目之间的开发过程可能不 同 –开发成败仍主要取决于项目团队的经验和技能. –可以重复早期项目的成功经验
3.1.3 系统开发基本原理
• 将信息系统作为重要的投资看待
– 成本效益分析在整个系统开发过程中都要进行 – 分阶段的系统开发方法提供了几次重新评价成本效益、风险和可 行性的机会 – 大多数系统所有者想从其系统中获得超出投资范围之外的功能
– 建立多个可行性检查点 – 在每个检查点上，所有的费用都被认为是过去的，所以它们同决 策无关 – 在每个检查点上，分析员应考虑
–研究并理解问题、问题的上下文和问题的影响 –定义方案必须满足的需求 –确定满足需求的侯选方案，并选择最佳方案 –设计和/或实现选出的方案 –观察并评估该方案的影响，相应的细化该方案
3.1.3 系统开发基本原理
• 确立开发阶段和开发活动：不同的作者、 专家以及公司对开发阶段和开发活动的数 量和范围的描述都不尽相同。 • 在开发过程中记录文档：为了促进不断变 化的关联人员之间的有效交流，文档必须 随同整个系统开发工作同时展开。
– – – – 提供一个一致且可再生的方法 降低了错误的风险 为各个项目生成完整且一致的文档 由于所有人都使用同样的过程，所以可以在项目之间灵活的分配 系统分析员、设计人员和构造人员 – 后来者可以方便的获得和理解以前的工作成果。
3.1.3 系统开发基本原理
• 让用户参与：系统用户的参与对于成功的系统开 发是必需的。交流不畅和误解仍是系统开发中存 在的主要问题。 • 使用一套问题解决步骤：问题包括真正的问题、 改进的机会、来自管理层的指示
3.1.1 能力成熟度模型
系统开发过程对质量影响
CMM Project Statistics for a Project Resulting in 200,000 Lines of Code
Organizati Project on’s CMM Duratio Level n (month s) 1 2 3 30 18.5 15 Project PersonMonths Number of Defects Shipped 61 12 7 Median Cost ($ millions) Lowest Cost ($ millions) Highest Cost ($ millions) 100+ 1.7 .933
第3章 信息系统开发
本章主要内容
3.1系统开发过程 3.2 FAST开发过程 3.3 开发路线和方法 3.4自动化工具和技术
3.1系统开发过程
坚持使用现代的严格的方法学可以在两年 内使70%的系统开发组织的生产率至少提 高30%。
使用一致的系统开发过程： –提高效率，管理层可以在项目之间调动资源； –产生一致的文档，减少维护系统的生命期费用； –改善质量
–系统遇到不可预期问题时，开发过程仍可以根据对问题的 影响的预测和度量进行调整
3.1.1 能力成熟度模型
优化级:
–根据4级建立的度量和数据分析，对标准化过程 进行持续监督和改进。
–调整开发过程中的技术和最佳实践，包括调整开 发过程本身。
–经验教训在组织内共享，保证质量，并消除低效 率。
–注意，每个等级都是下一等级的先决条件。
3.3.3商用软件包开发策略
• 为了实现业务需求，必须仔细地选择封装 式软件方案 • 封装式软件方案不仅需要花钱购买，而且 也可能更需要花钱实现 • 软件包通常必须定制并集成到企业中 • 软件包很少能实现让用户完全满意的所有 业务需求
3.3.3 商用软件包开发策略
3.3.3商用软件包开发策略
优点
RAD优点： –适用于用户需求不确定不明确的项目 –鼓励用户和管理层主动参与 –项目具有较高可视性和支持程度 –用户和管理层看到可工作的方案更快些 –错误和遗漏更早发现 –测试和培训是原型法的自然副产品 –迭代方法更自然，因为变化是必然的 RAD缺点： –可能增加运行、支持和维护费用 –省略问题分析阶段 –RAD可能不鼓励分析员考虑其他更有价值的技术方案 –对速度的重视可能会破坏质量 –抛弃原型可能被视为产品的时间和精力的损失
3.3.2 快速应用开发策略
3.3.2 快速应用开发策略
时间盒
–在一段不能延长的时间内（通常60-90 天），系 统的某个版本必须在这个时间段内投入运行。
优点：
有规律向用户和管理层发布运行系统，提高和保持 管理者和用户对项目的热情，因为系统工作版本按 照有规律的模式进行发布。
3.3.2快速应用开发策略
3.1.3 系统开发基本原理