管理信息系统（二）

一、软件危机

MIS项目规模

研制软件系统需要投入大量的人力、物力和资金，但是系统的质量却无法保证。开发软件所需的高成本与软件产品的低质量之间存在尖锐的矛盾。软件开发陷入恶性循环。这种现象被称为“软件危机(Software Crisis)”。

软件危机表现形式

软件开发进度难以预测。据统计：只有15%的项目是按计划完成的。
软件开发成本难以控制。据统计：仅有10%的项目是按费用计划完成的。
用户对软件功能难以满足。（开发人员和用户之间很难沟通、矛盾很难统—）
软件产品质量无法保证。
软件产品难以维护。（版本迭代，开发者和维护者沟通不足）
软件通常缺少适当的文档资料。（用户的操作说明书等）
生产率提高的速度不能满足社会需要。

软件危机产生的原因

内在因素：与软件本身的特点有关，客观的存在，只能因势利导加以解决。
• 软件在写出程序并在机器上运行之前，进展清况难以掌握，开发质量也无法评估。这些都给管理和控制带来不便。
• 软件是特定问题在计算机上的运行描述。实际问题的复杂性决定了一个实用软件系统规模往往十分庞大。大有大的难处。程序规模越大，控制、管理难度也就越大。
外在因素：与软件开发和维护的技术方法有关，可以完善、提高。
• 开发人员和用户之间没有充分沟通了解。
• 软件开发各阶段任务不明确，方法不科学。
• 重编程，轻分析；重开发，轻维护，重程序，轻文档。

如何解决软件危机

统计分析表明：用户需求不稳定、不清晰、不完整是项目失败的主要原因，应引起足够的重视。为了解决软件危机就要研究MIS开发模式，总结和实践好的开发方法学，提高软件开发效率，降低软件开发和维护的成本。

关于MIS开发方法学，有三个领域要重点关注：

软件工程：软件工程(software engineering, SE)
• 你所写的程序，从来没有超过—干行，那是完全不需要《软件工程》的。
• 程序大了，不用软件工程，项目就会失控。
项目管理：项目管理(project management , PM)
• 如果你总是—个人写程序，那也根本不需要《项目管理》
• 人多了，不管理，就没办法—起写程序。
系统分析：系统分析(systems analysis , SA)
• 如果你的问题，一看就知道怎么写程序解决，那连《系统分析》都可以省了
• 问题复杂了，不分析，就不知道该怎么写。

二、ISDM(information system development methodology)

研究人员希望能从实践中出现的各种技术和方法中找出有序、系统的框架，以建立能广泛使用的—般化的IS开发方法和模型。随着IS日益复杂，企业需要具备更好的组织结构，以适应能易于定义，控制、集成系统所有组件的各种开发工具。
另外，系统开发不仅受系统开发目标影响，而且也受组织特质影响，导致信息系统开发模型的多样性。实际上，没有哪—种开发模型能通用千所有企业。
这里简要讨论现有的主要 ISDM 以及各类方法学中的主要模型，了解如何为特定类型的信息系统开发项目选择适用的方法学和开发模型。

ISDM发展

早期方法学时代——系统开发生命周期 (Systems Development Life Cycle , SDLC) , 也叫瀑布模型(waterfall model)
- SDLC通常包括必须顺序执行的—些开发阶段，实际上这个阶段的定义并没有统—标准，通常在5-20个阶段。—个阶段必须在下—个阶段开始之前完成（所以叫瀑布模型），完成的标准是生成该阶段预定义的—套文档或可交付成果。
- SDLC各特定阶段会使用特定技术（如流程图等）。当遇到问题或需要改变时，也有阶段间迭代(iteration around the phases) 的提法，但实际上不会真正去做，通常是忽略掉。
- 早期瀑布型SDLC有严重的局限性，包括：
  • 不能满足企业的实际需求（强调组织运营层面的技术效率改进）；
  • 过度保守的系统设计（强调以现有系统为基础开发新系统）；
  • 不稳定性（强调流程建模，而流程会因不断变化的企业和市场而变化，不稳定）；
  • 不灵活性（由于设计过程是基于输出驱动的，因此很难修改设计，修改成本也很高）；
  • 用户不满意（用户只有在系统投入使用后才能看到效果）；
  • 文档问题（文档基本是计算机学科视角的，而非用户导向）；
方法学时代
方法学就是用于系统开发的阶段，程序，规则，技术，工具，文献工作，管理和培
训的推荐组合体
- 方法学时代开发方法的发展有7个重要主题脉络：
  1、结构化(structured) : 结构化编程的概念被应用于系统分析和设计；能支持复杂过程自上而下分析和表示的开发技术（如数据流图）。
  2、面向数据(data-oriented) : 将数据视为系统开发的关键要素，核心技术是实体联系建模(entity-relationship Modeling) 。
  3、原型(Prototyping) : 重点是在物理实现系统前建立近似模拟品，以允许用户评估并反馈。
  4、面向对象(OO , object-oriented) : 核心是对象、属性和类的识别，强调继承和重用。
  5、参与性(Participative) : 强调用户和其他信息系统利益相关者的参与。
  6、战略(Strategic) : 强调信息系统规划和信息系统战略制定，强调信息系统开发要支持和实现企业急体业务目标。如，在信息系统开发过程中同时进行业务流程再造(business process reengineering , BPR) 。
  7、多系统(systems) : 不局限于系统的单个应用边界内，强调超边界的整体观，来解释人类活动系统的复杂性。
后方法学时代
- —些组织在实践中发现很难采用方法学，会面对开发人员和用户的双重阻力。—些组织则完全拒绝使用方法学，返回到较不正式的，更灵活的方法。
- 不怎么使用方法学的—个领域是开发基于Web的系统，，它们通常以ad hoc方式，试错的方式开发，依靠组织中几个关键人物的技能和经验。
- 不再寻求统—的更好的方法学！而是寻求替代方案：
  • 用工具开发：—些组织追求开发工具的演进。包括自动代码生成，以自动化开发过程。无方法学指导下的工具使用可认为是—种ad hoc开发。
  • OO方法：尽管方法学时代就大行其道了, OO方法仍在不断演进, 新的方法和技术不断出现。基于组件的开发技术将系统开发视为现有组件（通常为OO) 的组合和重组。
  • 外包(outsourcing) : 有些企业组织面对系统开发方面持续存在的问题以及方法学效果的不足，将系统开发外包给第三方。从此不再关心系统如何开发和方法学的选择问题，而是关注系统的有效性问题。当然，这些企业必须能选择合适的第三方，详细规定系统要求，撰写和谈判合同。
  • 增量开发(Incremental development) 。增量开发强调在早期版本的基础上建立和改进系统。旨在减少开发系统所需的时间，特别是以RAD (Rapid Application Development) 形式。它解决了系统开发过程中需求变化的问题。例如，动态系统开发方法(Dynamic Systems Development Method) 是自20世纪90年代中期以来许多公司已经采用的增星开发方法。
  • 外部开发(External development) 。—些企业通过购买商业方法学来尝试满足他们的系统需求。这些企业故意不进行内部系统开发活动，而是购买封装好的系统来满足其要求。实际上，很多企业组织认为这是更快速的，更具成本效益的系统实现方式。只有那些具备战略意义的系统或市场没有适合的封装包时，才会考虑内部开发。
  目前，软件市场能提供越来越复杂的产品和功能，并包含越来越多的可裁剪封包。企业资源计划包在大型企业中特别受欢迎，客户关系管理软件包也是如此。
  不足之处：企业被局限在特定系统厂商，企业无法控制／指定软件包的功能特性，只能厂商卖什么用什么。
  • 权变(Contingency) : 大多数方法学都是针对符合某些理想规范的情境而设计的。然而，—些研究人员和实践者认为没有相同的情景，而且现实世界中也没有所谓的理想规范，从而提出一种权变开发方法，依赖企业具体情境（如，项目类型及其目标，组织及其环境，用户和开发人员），来使用、调整、忽略开发工具和技术。如Multiview方法。