1.3 信息系统

1.3.1 信息系统定义

• 信息系统是一种以处理信息为目的的专门的系统类型。信息系统可以是手工的，也可以是计算机化的。计算机化的信息系统的组成部件包括硬件、软件、数据库、网络、存储设备、感知设备、外设、人员以及数据处理成信息的规程等。
• 人是信息系统中最重要的因素。信息系统人员中包括所有管理、运行、编写和维护系统的人。
• 从用途类型来划分，信息系统一般包括电子商务系统、事物处理系统（EDPS）、管理信息系统（MIS）、生产制造系统、电子政务系统、决策支持系统（DSS）等。
• 采用现代管理理论（例如，软件工程、项目管理等）作为计划、设计、控制的方法论，将硬件、软件、数据库、网络等部件按照规划的结构和秩序，有机地整合到一个有清晰边界的信息系统中，以到达既定系统的目标，这个过程称为信息系统集成。

1.3.2 信息系统的生命周期

• 软件在信息系统中属于较复杂的部件，可以借用软件的生命周期来表示信息系统的生命周期，软件的生命周期通常包括：可行性分析与项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护等阶段，因此信息系统的生命周期可以简化为系统规划（可行性分析与项目开发计划）、系统分析（需求分析）、系统设计（概要设计、详细设计）、系统实施（编码、测试）、运行维护等阶段。
• 为了便于论述针对信息系统的项目管理，信息系统的生命周期还可以简化为立项（系统规划）、开发（系统分析、系统设计、系统实施）、运维及消亡4个阶段。
  

阶段	主要工作
立项阶段	即概念阶段或需求阶段，这一阶段根据用户业务发展和经营管理的需要，提出建设信息系统的初步构想，然后对企业信息系统的需求进行深入调研和分析，形成《需求规格说明书》并确定立项。
开发阶段	以立项阶段所做的需求分析为基础，进行总体规划。之后，通过系统分析、系统设计、系统实施、系统验收等工作实现并交付系统。
运维阶段	信息系统通过验收，正式移交给用户以后，进入运维阶段。要保障系统正常运行，系统维护是一项必要的工作。系统的运维可分为更正性维护、适应性维护、完善性维护、预防性维护等类型。
消亡阶段	信息系统不可避免地回遇到系统更新改造、功能扩展，甚至废弃重建等情况。对此，在信息系统建设的初期就应该注意系统消亡条件和时机，以及由此而花费的成本。

1.3.3 信息系统常用的开发方法

1. 结构化方法
   结构化方法是应用最为广泛的一种开发方法，把整个系统的开发过程分为若干阶段，然后依次进行，前一阶段是后一阶段的工作依据，按顺序完成。每个阶段和主要步骤都有明确详细的文档编制要求，并对其进行有效控制。

• 优点：理论基础严密，它的指导思想是用户需求在系统建立之前就能被充分了解和理解。由此可见，结构化方法注重开发过程的整体性和全局性。

• 缺点：①开发周期长；②文档、设计说明繁琐，工作效率低；③要求在开发之初全面认识系统的信息需求，充分预料各种可能发生的变化，但这并不现实；④若用户参与系统开发的积极性没有充分调动，造成系统交接过程不平稳，系统运行与维护管理难度加大。
  

2. 原型法
   原型法的基本思想与结构化方法不同，原型法认为在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，现快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求。

• 原型应当具备的特点如下：
  （1）实际可行。
  （2）具有最终系统的基本特征。
  （3）构造方便、快速，造价低。
• 原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。

3. 面向对象方法
   对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。面向对象的信息系统开发，其关键点是能建立一个全面、合理、统一的模型，它既能反映问题域，也能被计算机系统求解域所接受。

• 面向对象方法的基本思想如下：
  （1）客观事物是由对象组成的，对象是在原事物基础上抽象的结果。
  （2）对象是由属性和操作组成的，其属性反映了对象的数据信息特征，而操作则用来定义改变对象属性状态的各种操作方式。
  （3）对象之间的联系通过消息传递机制来实现。
  （4）对象可以按其属性来归类。
  （5）对象具有封装的特性，可达到软件（模块）复用的目的。

4. 敏捷开发
   敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试。具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

• 敏捷开发的原则如下：

原则	解释
快速迭代	相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布2-3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
让测试人员和开发者参与需求讨论	需求讨论以研讨组的形成展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方法也可以利用团队成员间的互补特性。如此确定的需求往往比仅仅由需求工程师开需求讨论大会的形式效率更高。
编写可测试的需求文档	开始就要用“用户故事”的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早提及技术实施方案，会降低对需求的注意力。
多沟通，尽量减少文档	任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的沟通，面对面沟通比邮件强得多。
做好产品原型	建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
及早考虑测试	及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。

• 在系统开发的实际工作中，往往根据需要将多种开发方法进行组合应用，最终完成系统开发的全部任务。