信息系统开发内容

1.按照用于质量管理的能力成熟度模型（CMM）描述系统开发过程的动机。

2.区分系统生命周期和系统开发方法

3.描述系统开发的10个基本原理

4.定义问题、机会和指示——系统开发项目的能力

5.描述用于把问题、机会和指示进行分类的PIECES框架

6.描述系统开发基本阶段。对于每个阶段，描述它的目的、输出和项目

7.描述覆盖了多个系统开发阶段的跨生命周期活动

8.描述贯穿系统开发基本阶段的集中典型“开发路线”。描述不同的项目应该如何或者制定开发路线

9.描述用于系统开发的各种自动化工具

关键术语

能力成熟度模型（Capability Maturity Model，CMM）：用来评估组织的信息系统开发以及管理过程的产品的成熟度等级的框架，它由5个开发成熟度等级构成。

系统生命周期：分为两个阶段，①系统开发阶段；②系统运行和支持阶段，首先构造系统；然后使用系统，运行系统并支持系统；最后，从运行和支持阶段再回到开发阶段。

系统开发方法：为系统开发人员和项目管理者定义了一组活动、方法、最佳实践、交付成果和自动化工具，用来开发和维护大部分或所有信息系统和软件。

成本效益：在开发、维护和运行信息系统的成本与从系统中获得的效益之间取得平衡。成本效益使用一种称为成本效益分析的技术。

信息系统战略规划：一个正式的战略规划（一般3~5年），用于构造和改进信息技术架构以及使用该框架的信息系统。

企业战略规划：是整个企业的战略规划（一般3~5年），定义企业的任务、愿景、目标、战略、基准和 评价准则。

逐步投入：在整个项目过程中都持续地重新评价可行性和风险，并相应地调整项目预算和最后期限。

风险管理：及早发现项目中可能出现的错误，防止它真正威胁信息系统的实现，对它们进行评估和控制。风险管理由风险分析和风险评估所驱动。

约束条件：是可能制约解决方案或问题解决过程的因素、限制条件或约束。

范围蔓延：是一种常见现象，其中项目的需求和预期经常不顾对预算和进度的影响而缓慢增加。

系统模型：一幅系统的图示，表示现实情况或者希望的情况。系统模型促进系统用户、系统分析员、系统设计人员和系统构造人员之间的交流。

逻辑设计：将业务用户需求转换成系统模型，该模型仅仅描述了业务需求，而没有描述这些需求的任何可能的技术设计和实现。

分析瘫痪症：描述一种常见的项目状态，这时过多的系统建模极大地减缓了实现系统方案的进度。

物理设计：将业务用户需求转换成系统模型，描述用户的业务需求的技术实现。

系统支持：对系统用户的不断技术支持，以及处理可能出现的错误，失误或新的需求所需的维护工作。

跨生命周期活动：存在于系统开发方法中多个阶段或者所有阶段的活动。例如：调查研究、记录文档、演示汇报、估计和度量、可行性分析、项目和过程管理、变化管理以及质量管理。

瀑布开发方法：一种系统分析和设计方法，要求每个阶段必须在另一个阶段之后“完成”。

迭代开发方法：在一系列连续的迭代中完成整个信息系统。每个迭代要进行足够的分析、设计和构造。

模型驱动开发：强调绘制模型以可视化地分析问题、定义业务需求以及设计信息系统。

过程建模：以过程为中心的技术，其最流行的形式是结构化分析和设计方法，使用描述业务过程需求的模型推导出有效的软件设计。

数据建模：以数据为中心的技术，用来建模业务数据需求，以及实现这些需求的数据库系统。最常见的数据建模是实体关系图。

对象建模：试图在被称为对象的单一结构中融合数据和过程要素。对象模型从对象和对象之间的角度文档化系统。对象建模技术是面向对象分析和设计方法的基础。

快速应用开发：一种系统开发策略，强调用户深入地参与到一系列工作模型的快速进化和构造过程中，以加速系统的开发过程，系统工作原型最终将成为目标系统

原型：一个小规模的、有代表性的或者可工作的模型，反映了信息系统的用户需求或建议设计。任何原型都可能忽略某些功能或特征，直到原型最终完全进化成需求的一个可接受的实现系统为止。

时间盒：一段不能延长的时间段（通常为60~90天），系统的第一个版本必须在这个时间段内投入运行。

建议申报书：一种与软件供应商交流应用软件包的业务、技术和支持需求的正式文档，这些软件供应商希望竞争销售应用软件包或服务。

报价申报书：一种与单个软件供应商交流应用软件包的业务、技术和支持需求的正式文档，该软件供应商已经被选中提供应用软件包或服务。

差距分析：将对商用软件包的业务和技术需求与特定商用软件包的功能和特征进行比较，以定义不能满足的需求。

计算机辅助软件工程：使用支持系统模型的绘制和分析的自动化工具，有些CASE工具也提供原型设计和代码生成能力。

CASE资料库：一个系统开发人员的数据库。是开发人员存储系统模型、详细描述和说明以及系统开发的其他商品的地方。资料库的同义词包括字典和百科全书。

正向工程：CASE工具的一种能力，能够直接从系统模型生成初始软件或数据库代码。

逆向工程：CASE工具的一种能力，能够直接从软件或数据库代码生成初始的系统模型。

应用开发环境：集成的软件开发工具、它提供了以最快的速度和最高质量开发新应用程序所需的全部工具。常用的同义词有集成开发环境（IDE）

过程管理软件：一个 自动化工具，帮助记录文档与管理一套方法学和开发路线、交付成果以及质量管理标准。

项目管理软件：一个自动化工具，帮助规划系统开发活动、估计和分配资源、调度活动和资源、按照进度和预算监督进展、控制和修改进度和资源，以及报告项目进展。

系统开发基本原理

1. 让系统用户参与
2. 使用一套问题解决步骤
3. 确立开发阶段和开发活动
4. 在开发过程中记录文档
5. 建立标准（数据库技术、软件技术、接口技术）
6. 管理过程和项目
7. 将信息系统作为重要的投资看待
8. 不必害怕取消和返工
9. 分而治之
10. 设计系统时应考虑到增长和变化

能力成熟度模型

1. 初级级（不一致的方法）
2. 可重复级（一致的项目管理）
3. 已定义级（使用一致的过程）
4. 已管理级（已管理和测量的过程）
5. 优化级（持续过程改进）

系统生命周期和系统开发方法

1. 范围定义阶段——项目启动
2. 问题分析阶段——项目启动和系统分析
3. 需求分析阶段——系统分析
4. 逻辑设计阶段——系统分析
5. 决策分析阶段——（系统分析到设计的转换阶段）
6. 物理设计和集成阶段——系统设计
7. 构造和测试阶段——系统设计继续和系统实现
8. 安装和发布阶段——系统实现
9. 运行和维护阶段

选择开发路线和策略

模型驱动开发策略

优点：

1. 需求说明往往更加全面而且被更好地文档化
2. 使用图形比使用语言更容易验证业务需求和系统设计
3. 更容易确定、概念化和分析多种技术方案
4. 设计说明更合理、更稳定、更具适应性、更灵活，因为它们是基于模型的，并且在构建前被全面地分析过。
5. 当使用全面而且清楚的基于模型的规格说明构造系统时，更容易首次就正确地构造出来。

缺点：

1. 项目持续时间很长，需要时间收集事实、绘制模型、验证模型。如果用户需求不确定或者不明确，这种情况就更明显。
2. 模型所能达到的需求理解程度最多只能与用户的理解程度一样。
3. 图形不是软件，所以有人认为这种方法降低了用户在项目中的主动参与成分。
4. 模型驱动方法被认为不够灵活——用户在设计之前必须完全说明需求，设计必须完全记录技术说明才能构造。

快速应用开发策略

优点：

1. 它适合于用户需求不确定或者不明确的项目
2. 它鼓励用户和管理层主动地参与，这增加了最终用户对项目的热情
3. 项目具有较高的可视性和支持程度，因为用户深入参与到整个开发过程中
4. 用户和管理层看到可工作的基于软件的方案比模型驱动开发要快得多
5. 在原型中错误和遗漏往往比在系统模型中更早地被发现
6. 测试和培训是基本原型方法的一个自然副产品
7. 迭代方法显得更“自然”，因为开发过程中变化时必然的

缺点：

1. 增加了运行、支持和维护系统所需的费用
2. 因为省略了问题分析阶段，所有RAD原型一个易犯的错误是解决了错误的问题
3. RAD原型可能不会鼓励分析员考虑其他更有价值的技术方案
4. 有时最佳方案是抛弃原型，但关联人员经常不愿意这样做，因为他们把这看做是当前产品的时间和精力的损失
5. RAD对速度的重视会对质量造成影响，因为这种方法中充斥着大量不明智的捷径

商用应用软件包实现策略

优点：

1. 可以更快地实现新系统，因为不再需要大量的编程工作
2. 许多企业没有能力提供人力和专业知识开发内部方案
3. 应用软件供应商将它们的开发费用平摊到购买软件的所有用户身上。这样，他们可以不断地投资以改进软件的特点，功能和可用性，这往往是单个企业无法做到的
4. 应用软件供应商对重大的系统改进和错误修改承担责任
5. 在一个行业内部，许多企业的动能相似性多于差异性。

缺点：

1. 成功的COTS实现依赖软件供应商的长期成功和生存能力——如果供应商不干了，你就会失去技术支持和未来的改进
2. 购买的系统很少能反映理想方案，而企业可以通过内部开发实现理想方案。内部开发可以按照管理层和用户的精确期望进行定制
3. 改变业务过程以适应软件几乎总是会遇到一些阻力，一些用户将不得不放弃或者分配新工作；而有些人或抵制变化，他们认为这些变化是技术驱动的，而非业务驱动的