1、21第1章 系统计划第1章 系 统 计 划“预则立，不预则废”，任何成功的始点就是计划。在信息系统建设中，系统计划主要描述从项目提出、选择到确立的过程，包括系统项目的提出与可行性分析，系统方案的制订、评价和改进，遗留系统的评价和处理策略，以及现有软件、硬件和数据资源的有效利用等问题。1.1 项目的提出与选择企事业单位和政府机构（以下统称为“企业”）在信息化的过程中，可能基于各种动机提出信息系统项目（包括软件项目、网络项目和系统集成项目等各类信息化项目，以下统称为“项目”或“软件项目”）的建设，有关人员要根据这些动机，确定系统的工作范围，提出系统选择方案，给出选择结果。1.1.1 项目的立项目标
2、和动机企业在其自身的运营、管理过程中，对于信息系统项目的建设可能具有多种动机，通常可归结4种模式，分别是进行基础研究、进行应用研发、提供技术服务、产品的使用者。1进行基础研究此类项目通常由大学、科研院所、企业集团从事基础研究的部门提出和实施。小规模的研究团队可能仅仅是企业中的一个从事研发工作的部门，中等规模的研究团队可以是研究所或研究院等类似的独立建制的单位，大规模的研究团队可以是国家“863”计划这样跨行业、跨地域协作的国家级研究项目组织。此类项目的目标通常不仅仅包含对某种产品实现机制、核心技术支撑理论或理论体系的深入钻研，而且也代表着对前沿技术的追踪和对技术发展趋势的早期研判。因此，通常也
3、称为“基础研究”。此类研究通常都被看作一种长期的战略性投资，目标不是为了短期的市场收益和支持当前的市场或行业应用，而是为了开拓未来的市场，创造全新概念的产品、产业或生活方式，建立企业、行业甚至国家的竞争优势。基础研究更多体现为一种探索性研究，成果多体现为某种理论体系和技术成果。基础研究的工作方式通常是：研究者设想未来的技术趋势、社会环境和人的习惯变迁，大胆构思一种超前的需求，并为满足这种需求而预研某种前沿技术。这样的研究通常没有具体的产品发布目标，也没有苛刻的时间限制，甚至连阶段性目标和长期目标也是由研究人员自己来设定的。在研究过程中需要研究人员充分发挥想象力和创造力，突破现有理论或技术模型的
4、框架，提出全新的理论体系和技术或产品。2进行应用研发此类项目通常由企业进行立项和开发，企业立项的基本动机是得到应用产品，并向目标客户群进行销售，从而占有市场份额并获取利润。产品一般会基于某类特定客户群体的需求进行设计，有明确和具体的研发目标需求，有严格的时间限制、资源预算，大多以项目方式进行组织，可归入“应用研发”型产品。“应用研发”型的产品具有一定的通用性客户，通常可能是面向个人消费者的工具软件（例如，办公软件、杀毒软件、游戏软件、共享软件或自由软件等均属于这个范畴）、面向特定领域的工具软件（例如，SQL Server数据库、AutoCAD工程绘图软件、Rose建模工具软件等），也可能是面向
5、特定行业中具有一定普遍适用性的业务、可作为产品进行销售的企业级软件系统（例如，企业资源计划系统、客户关系管理系统、新闻发布系统、人力资源管理系统等）。3提供技术服务对此类项目进行立项的企业通常能向目标客户群提供比较全面的技术服务，而不是单一的软件产品。企业的服务范围可能包含：提供技术和解决方案的咨询，利用现有产品进行系统集成和服务，面向特定客户的软件项目定制开发，对现有的软件系统进行升级和改造，提供软件应用相关的技术支持、服务和培训等。一个企业可以提供上述服务中的一个或多个内容。这些企业通常可能以系统集成商、软件项目定制开发商、咨询商、整体解决方案提供商等各种角色出现。总的来说，此类企业通常会
6、面向一个特定行业，具有相对稳定的客户群体，具有系列化的软件产品和基于这些产品的技术解决方案，企业对自己所处的应用领域有比较深刻的理解，能够整合技术、产品、方案和应用，通过提供一种综合性的技术服务，而不是单一软件产品，来占有市场份额和获取比提供软件产品更高的利润。此类企业可以看作“技术服务”导向的机构。4产品的使用者产品的使用者是最终客户。对他们来说，项目的立项动机既不是得到软件产品进行销售，也不是为了提供技术服务，而是通过采购产品或技术服务来得到使用价值。例如，个人消费者购买绘图软件是为了存储和处理个人数码相机中的照片，而一个企业通过实施企业资源计划（Enterprise Resource P
7、lanning，ERP）系统可能是为了达到控制生产能力、科学计划生产、提高管理水平、获取新的决策能力、降低库存成本、提高资金周转率、建立面向市场订单生产方式等目标，并期望通过这些目标的实现来增强企业竞争力，获取更大的市场份额。对信息技术的使用者来说，信息技术是一种手段，同时也是一种成本。如何用最小的成本和风险获得满意的效果是用户最关心的问题。产品的使用者可能采用各种方式来进行项目立项，可能是直接采购现有市场上的软件进行使用，也可能是寻求内部或外部能够提供技术服务的企业进行定制开发。1.1.2 项目立项的价值判断不同的信息系统项目，立项动机和获益目标也是不同的，并不存在一个统一的项目提出模式。但
8、是，能否达成一个成功的立项，总是取决于人们对项目收益预期的价值 判断。1对技术的态度不同类型的信息系统项目立项，具有截然不同的价值观和侧重点，如图1-1所示。通常以基础研究为目标的项目是高度技术研究导向的，以应用产品开发为目标的项目重点关注的是技术在具体领域中的应用和推广，而以技术服务为目标的项目则是高度客户业务导向或客户满意导向的，产品的最终客户则主要关注软件的使用、影响和代价等应用性问题。图1-1 不同软件项目立项对IT技术运用的层次这些价值观彼此之间并不矛盾，只是使用IT（Information Technology，信息技术）技术的程度不同，对于信息系统项目预期价值的视角不同。但这些对
9、项目基本的价值判断，决定了系统分析师在项目从立项到完成的全过程中，需要长期重点关注的问题侧重点所在，以及需要运用技术手段的程度问题。2企业对项目的视角从企业的角度来看待信息系统项目立项，项目并不是一个简单的、通过技术开发来得到软件产品和完成项目的过程。企业对项目的视角如图1-2所示。图1-2 企业对项目或产品的视角通常，企业总是通过开发产品、提供技术解决方案、整合外部资源、提供咨询和技术服务、销售或运营、进入买方价值链或开创新的领域这6个层面来获得价值和利润，图1-2中楷体字的部分是对企业最有价值的部分，也是软件所重点针对的领域。技术、产品、解决方案、技术咨询和服务、资源整合、销售和运营、对业
10、务的理解、业务扩张之间是具有层次关系的，通常，企业得到前者作为基础才能去谋求后者，而企业拥有上述产品层面的要素越多，产品就越有竞争力。根据企业定位不同，或企业所处的时期不同，可能扮演不同的角色。从企业发展历程来看，企业总是以研发技术、开发软件和销售软件为基础（软件开发商），然后发展出某方面的技术解决方案（技术解决方案提供商），再然后深入到客户的业务中去解决一些具体的应用（例如，定制项目、系统集成等），最终由于对具体业务的理解和应用能力超越了其所服务的客户，从而能够引领该行业信息化建设（咨询商），或将业务扩张到原用户所经营的范围，成为后来的竞争者（业务扩张），甚至开创出全新的应用领域（运营商）。
11、企业并不把软件立项和软件产品开发完成看做获取价值的终点，而仅仅是一个起点。不同的自身定位或者不同的时期，企业看待软件产品的价值和作用也截然不同。企业最终的目标可能是获取利润、占有市场份额、加强影响力、广泛的社会效益等这些潜在的商业价值目标，软件则常被作为支持性手段来支撑这些目标的实现。以提供软件产品为目标的企业，规划的范围一般局限在软件的功能/性能本身，而以运营为目标的企业，规划的范围需涵盖产品、技术方案、业务和运营等各方面。在很多情况下，系统分析师需要超越技术开发的范畴去考察IT建设后的目标问题，以便确定软件项目的工作范围、开发边界、项目的阶段性目标，以及未来软件需求变更的根源。3系统分析师
12、在项目中的个人角色和工作范围图1-3列举了系统分析师在软件项目中的个人角色和工作范围。图1-3 系统分析师的工作范畴从图1-3中可以看到，处于执行层的软件系统分析师，一般仅工作在项目可行性论证、软件架构、软件设计、项目管理和组织等层面上，基本的技术手段是各类软件工程的技术方法和项目管理方法。而处理产品定义、规划、技术路线、业务和赢利模式等的中高层技术人员或管理人员，还必须在更广泛的层面上，对软件项目立项的效益、价值、业务模式、影响、企业战略或策略等进行研究，并将这些作为软件立项的初始需求、发展的需求、未来的需求贯彻到软件立项的目标之中。希赛教育专家提示：全国计算机技术与软件专业技术资格（水平）
13、考试中的“系统分析师”不仅仅局限于“软件系统分析师”的范畴，而是整个信息系统的系统分析师，即包括软件系统、信息网络系统和系统集成。不过，从考试大纲来看，以软件系统为主。4位于战略和执行边界上的系统计划从软件工程的定义上看，软件工程是一门研究如何使用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科，其主要研究内容是软件开发技术（包括软件开发方法学、软件工具、软件工程环境）和软件项目管理（包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等）。如果把人们分析问题和解决问题的过程看做4个和一个H，即hat、hy、hen、ho、How的过程，则软件工程解决的主要是执行问题
14、（When、Who和How，即什么时候、由谁来做和怎么做的问题），而产品和项目定义阶段主要关注于要解决的目标问题（What和Why，即做什么和为什么要这么做）。系统分析师经常感到困惑的问题是，企业中高层经理指出了一个具体的企业策略（例如，在本年度内要通过信息化手段改善管理水平，降低管理成本），但并没有告知企业将如何去执行这个策略。同时，业务人员、管理人员和从事软件开发的IT人员彼此之间对对方的工作、工作的意义所在并不能完全理解。不管怎么样，事情总是需要从沟通开始。因此，系统分析师通常准备了一系列的问题询问业务人员。例如，谁提出了软件项目、最终用户是谁、想象中的操作方式如何等；而业务人员通常不会
15、详细介绍项目背景以及项目背景之后的企业策略问题，往往会直接提出一些很抽象的要求。例如，软件应该界面友好、简洁方便、性能好等。这种通过调研直接进入需求获取或原型化开发的工程手段局限性，可能导致项目需求偏离预期目标，软件需求模糊不清，或未来的软件项目目标不断发生变更。由于软件工程研究的领域是How的问题，而涉及目标的What与Why的问题无法由软件工程领域的技术手段予以解决。项目提出这个问题域所覆盖的内容，实际上超出了多数软件系统分析师的工作范畴，也部分超出了软件工程本身的范畴，位于战略和执行的边界上。5系统计划中的软件规划为了保证软件项目目标的正确性，在系统计划的阶段，企业经营管理层、系统分析师
16、、客户，以及其他的软件项目建设者需要充分沟通和协调，通过软件项目/产品规划的手段来保证软件的商业价值目标和软件需求的功能或性能相一致。通过将产品规划的手段与软件工程手段相结合，软件项目开发就能够实现从“面向需求驱动的软件开发过程”向“面向商业价值的软件规划和开发过程”升级。保证企业能够以最小的代价开发最有价值的系统。因此，担任技术负责人的系统分析师必须积极参与到软件立项背后的产品规划、技术战略、项目远景目标和价值判断的确认过程中。从获取用户需求更进一步去观察项目价值、项目目标，以及项目背后的企业策略问题，辅助企业的经营管理层勾画项目远景目标和项目实施的路线蓝图，完成项目计划到实施的最终决策过程
17、，并最终通过合理确定软件项目的开发边界，规避那些因开发目标错误导致的根源性失败。在这个过程中，项目需求的初期调研结果，产品或项目未来的商务模式和赢利模式，用户业务描述和想象，用户群体和组织变更，行业或技术的发展趋势，软件针对的用户业务规划，项目资源的投入计划和变更，软件企业自身的产品战略和技术路线，客户和企业所在的行业价值链，来自社会、政策、经济发展等各方面的影响因素均在考察的范围之中。通过这些多角度的分析和考察，总是可以寻找到很多新产品的立项方向和新业务的发展机会，评估已经确立的软件项目是否合理，解释软件项目立项的根本性价值问题。同时，也有助于系统分析师最终定义软件产品或项目的开发边界时，理
18、解和把握软件产品中对最终项目或产品成功具有至关重要影响的功能需求。1.1.3 项目的选择和确定信息系统项目的选择和确定，是项目投资方看待项目的视角。具体的项目选择至少包含两种方式。一种是在软件开发企业在诸多的产品方向中选择适当的方向进行研究和开发，另一种是客户从诸多的软件产品和方案中进行选择采购。与项目提出的问题一样，并不存在一个统一模式进行项目的选择和取舍，但存在一些进行项目取舍和评估的基本原则，通过使用这些原则，可以逐步排除那些不符合需求的项目定义，选择和确定满意的项目或产品。项目选择和确定的原则与系统计划所使用的软件规划原则是一致的，核心问题都是软件项目的目标规划问题。1选择有核心价值的
19、产品/项目或开发方向这个策略的关键在于确定什么样的项目是有价值的。通常，由于立项单位所处的行业、在行业中的位置、立项目标等因素不同，对软件项目的价值判断也不同。但是，一般来说，有核心价值的软件项目通常总是和企业或客户的核心业务相关。美国哈佛商学院的著名教授Michael Porter曾经在他的竞争优势（Competitive Advantage）一书中提出了价值链的概念，价值链把企业运作的各种活动划分为产品设计、生产、营销和应用等独立领域，企业的价值链也可以进一步和上游供货商与下游买主的价值链相连，从而构成一个产业的价值链。如果以价值链的观点来看待软件产品或项目，软件是作为一种技术服务手段被作
20、用到企业业务的价值链上的。软件手段通过实现业务价值链中关键业务的信息化，用改善甚至重建的方式提升这些业务的运行质量或效率。在企业经营活动中，对价值链增值最大的部分就是企业的核心业务。针对核心业务的信息化产品或项目，通常都是具有高价值的，也可以说，信息化的关键就是这些核心业务的信息化。举例如下： （1）对生产制造业的企业来说，管理和调度企业资源、生产计划、库存控制、实现面向订单（面向市场）的生产和销售等方面就是核心业务，无论实施ERP这种大规模的软件项目，还是小规模的MIS（Management Information System，管理信息系统），针对这些部分的软件功能总是被客户认为是最有价值
21、的。（2）对于金融保险行业来说，由于保险公司的基本职责是分摊风险和补偿损失，所以，管理保单和保险人信息的业务系统、单证系统、评估风险的定损系统等就是非常有价值的软件系统。（3）对于教育培训行业来说，因为学校的核心职能是教书育人，因此，与教研、教学、考试、评价等业务相关的软件系统，以及支持上述业务开展的教育资源库软件、课件制作工具、电子图书馆软件、教学科研支撑系统等就是高价值的软件系统。（4）对于互联网的网民来说，面向信息交换和传递的电子邮件系统、面向查找信息的搜索引擎、保证系统安全的防火墙和杀毒软件、面向网络沟通和交流的即时通信工具（例如，MSN Messenager、QQ）等就是高价值的软件
22、系统。总之，选择和确定软件项目，必须首先考察软件应用的行业、业务和目标，以便判明要建设的软件项目价值。2评估项目约束、风险、收益和代价在判断出一个具有潜在价值的软件项目后，还应评估项目实施的约束、风险、收益和代价。通常这部分内容可以在项目的可行性分析阶段完成。所谓项目约束，是指在产品开发过程中，不能做什么的原则。这些约束有些来自客户，有些来自企业本身，有些来自外部环境。可能包括：（1）企业约束。例如，项目是否符合企业定位、商业价值观、经营方式，是否是企业需要优先实施的项目等。（2）资源约束。例如，时间、人力、资金、设备等各种资源是否能承担并满足投入计划等。（3）能力约束。例如，项目技术难度、企
23、业技术能力、人员素质和水平、项目开发周期等。（4）环境约束。例如，项目是否符合行业标准、是否符合国家政策规定、是否符合当前的社会环境、是否符合行业发展水平等。（5）用户约束。例如，使用软件的用户素质和认识水平、用户业务的限制、用户的工作方式和行为习惯等。一些明显的约束条件可以在立项阶段明确评估出来，隐性的约束则容易被软件开发者忽视（例如，企业资源投入的变化、国家政策变化等），从而导致各种项目执行中的风险。项目约束通常是开发者不可控制的因素，对于这些约束，必须时刻关注方能尽可能规避风险，如果明显违背这些约束条件，就会导致软件项目不可避免的失败。对于购买产品或技术服务的客户来说，除了考察上述项目约
24、束外，还应该评估项目实施后的影响。例如，对自身业务变更的影响、组织机构和人员职责的影响、相关的系统维护、运行规约和规章制度等，以及项目的效益、当前成本、未来的总持有成本（Total Owner Cost，TOC）是否能接受等。评估项目约束、风险、预期收益和代价后，即可筛选掉多数不符合企业要求的建议项目。3评估项目的多种实施方式对于已经确认有价值，并且有能力开发的软件项目，则可以进一步参照企业现状考察项目的实施方式。这种实施方式通常既包括前面对项目风险、预期收益和资源开销的评估，也包含企业对现阶段经营目标和现有资源如何合理运用的考虑。这个过程通常由项目的负责人和企业中高层经理进行决策，决策结果决
25、定项目的实施优先级和具体的实施方式。企业完成软件项目的具体方式并不单纯限制于自己组建开发团队进行项目开发的策略。根据具体情况不同，还可能使用诸如转包开发业务给外部公司，直接OEM（Original Equipment Manufacture，原始设备制造商）软件产品并进行系统集成，购买关键技术并进行软件集成方式的开发，或者企业自己完成技术方案和设计，然后，寻求外部公司进行代工等方式。对这些项目实施方式的取舍，其主要依据依然是对项目风险、收益和资源开销的平衡的考虑，其根本目标是为了优化和合理运用投入项目的资源。由于企业实施软件项目，除技术、管理、应用的角度外，隐含有企业经营和加强竞争力目标的判断
26、，例如，成本领先策略（通过合理选择实施方式缩减成本等、差异化策略（建立和加强与合作伙伴的关系）、专注化策略（提高效率和降低项目风险并专注在自己擅长的领域），因此，评估项目的多种实施方式就显得特别重要，如图1-2所示。4平衡地选择适合的方案人们在选择可行的方案时，总是希望能尽量得到一种高质量、低成本的产品和方案。软件开发人员通常也很愿意在产品开发中，向产品中加入激动人心的“创造性”的内容。另一方面，客户单位在面对诸多的投标方案时，会听到各种各样关于技术先进性、快速开发、产品质量稳定可靠、价格如何低廉、推荐的方案有多少成功应用等宣传。这些内容本身存在很多矛盾，简要列举案例如下： （1）技术风险。采
27、用成熟的技术则可能享受不到新技术带来的好处，但流行的新技术可能是易变化的，从而导致风险。新技术也意味着技术开发者需要更多的学习时间，从而导致开发成本的增加。（2）用户锁定性。不基于某种快速开发技术或平台构造的产品可能会提高项目开发时间而导致更多的开销和成本，但基于某种平台的产品又可能使得用户未来“绑定”在某种平台之上，减少了自由选择能力，甚至未来被迫接收厂商的定价和服务。（3）扩展性。不考虑系统的扩展性，将导致业务变更时受阻于已经建成的IT设施，重新改造这些IT设施既增加成本又导致大的影响，几乎是一种灾难。另一方面，如果过多考虑系统的扩展性，用户常常可能在当前的采购中购买了一些自己并不需要的特
28、性，从而支付了更多的成本，由于IT技术发展迅速，当用户期望进行系统升级的时候，常常会发现原来的开发平台早已被淘汰和抛弃。（4）目标偏离。出于希望达成交易的需要，供应商更愿意宣传技术先进、价格低廉、快速提交、软件的新特色和新性能等因素。在用户对IT技术、作用和代价不甚明确的时候，容易受到宣传的影响从而偏离对原有目标的关注。事实上，对软件功能和性能的要求常常是充满矛盾的，任何时候都从不存在一个完美无缺的方案，只存在一个对当前的项目目标相对比较适合的方案。选择项目的基本立场，应该是“适合”，而不是尽可能的“好”。实际上，任何超出预期设定目标的“好”性能，通常都意味着某方面更多的成本或者潜在的风险。因
29、此，平衡地选择适当的项目，是系统项目选择非常重要的原则之一。希赛教育专家提示：所谓适合的方案，就是平衡考虑开发单位利益和客户满意度的方案。图1-4是Noriaki Kano博士创造的顾客满意度的质量模型图。图1-4 顾客满意度的质量模型（1）要求质量：客户认为产品应该做到的功能或性能，实现越多客户会越满意。（2）假想质量：客户想当然认为产品应具备的功能或性能，客户并不能正确描述自己想要得到的这些功能或性能需求。软件工程手段的需求获取、需求管理和原型化方法并不能有效获取涉及假想质量的软件需求。（3）兴奋质量：客户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予产品的技术特性），实现这些性能
30、客户会更高兴，但不实现也不影响其购买的决策。兴奋质量是控制在开发人员手中的，开发人员可以选择实现更多的兴奋质量，以便得到高满意、高忠诚度的客户；也可以（出于成本或项目周期的考虑）选择不实现任何兴奋质量的功能（例如，为MIS软件制作漂亮的界面）。显然，项目开发方更多考虑的是项目风险和回报，而客户更多关心的是成本和购买后的满意度，一个好的方案必须平衡考虑这些因素。系统分析师应尽可能用技术手段来平衡这些彼此对立的要求，保证在项目预期投入资源可接受的范围内，尽量实现客户要求质量对应的功能和性能，发掘客户假想质量对应的功能要求并进行沟通、确认，但按自身所服务企业的经营目标平衡考虑客户兴奋质量的实现策略（
31、是努力提供兴奋质量的功能，争取忠诚的客户获得远期潜在的收益，还是削减这些功能以便最小化项目的成本）。系统分析师常犯的一个错误，就是用自己对技术的兴趣产生的兴奋质量，来替换客户最基本的要求质量和假想质量；而企业经营者常犯的错误，则可能是对客户提出的合理要求质量内容麻木不仁，或者走向另一个极端，不加区分地把一切未经评估的假想要求质量不断指派给软件开发团队。这些都是错误的做法。1.1.4 项目提出和选择的结果信息系统项目提出和选择的结果，最终会以产品/项目建议书的方式来体现。典型的应用场景是：（1）在投标项目中，产品/项目建议书通常是乙方提交给甲方竞标方案的一部分。（2）企业在确立了要开发某类型产品
32、后，对该产品进行多角度的评估，最终项目立项人向上级提交供决策的建议报告的主要内容就是产品/项目建议书。产品/项目建议书是一个包含多种综合内容的报告，涉及的范围通常要比GB/T 85672006标准中规定的项目可行性研究报告（请参考第10.2节）的内容要更全面。在项目建议书中，可能包括以下内容：（1）用户单位、项目或产品的立项背景、需求来源和目标性的介绍。（2）用户的内外部环境、组织机构、现有的IT设施情况等。（3）用户的业务模型和业务规划。（4）预期要建设的技术系统在用户业务中的位置和作用。（5）信息化后的用户业务模型、软件应用方式、部署环境、运行规则、管理规范等。（6）为实现信息化业务模型，
33、技术系统的产品需求定义（功能、性能、约束）和部署方式。（7）产品或项目的技术框架。（8）项目的要点、技术难点、主要实施障碍等。（9）项目或产品的可行性研究结果。（10）项目可选择的实施方式、组织方式、沟通和协调机制等。（11）项目的资源范围和预算（包括人、财、物、时间等，请参考第11章）。（12）项目的成本/收益分析。其他项目建议书可能包含的内容，或以单独文档列举的内容可能包括以下内容：（1）项目风险及影响评估。（2）项目进度计划。（3）项目质量计划。（4）项目过渡期资金的获得方式、财务计划。（5）产品或项目的商务模式、盈利模式论述。（6）同类产品或公司的市场调查结果，以及竞争性比较。（7）企
34、业成功案例、资质等。（8）商务条款或供应商/客户合同。项目建议书标志着项目立项和选择阶段性工作的完成，一旦项目建议书被批准通过，项目即可进入正式的开发准备和实施阶段。1.2 定义问题与归结模型对于经过系统计划、选择并确定要实施的项目，定义问题与归结模型过程的主要目的是得到系统开发清晰的目标、功能清单、性能要求（包括约束），以便确定系统目标，为后续的工作进行准备。这个阶段不解答的问题是软件系统架构、功能划分、实现算法这样的设计问题。1.2.1 方法论模型图1-5描述了问题定义与归结模型的方法论模型。问题定义和归结模型位于系统项目立项和确立之后的阶段。1自下而上的软件工程技术进展传统软件工程方法的
35、工作范围，在定义了软件概念模型后即进入软件的概要设计阶段。软件设计的重点被放在数据结构和算法的选择上，对于大规模的复杂软件系统来说，对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择明显重要得多。传统软件工程方法显得力不从心。在系统分析和设计层面上，现代软件系统设计方法将软件架构设计独立出来。软件架构的 “4+1”视图从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图的角度对软件系统作了高阶抽象，揭示了系统需求和构成系统的元素之间的对应关系，并提供了进一步设计决策的基本规则，试图架设从软件分析设计手段到软件需求的桥梁，如图1-6所示。图1-5 系统设计的归结模型关
36、于软件架构的详细知识，请参考本套丛书中的系统分析师技术指南（2009版）的第11章。2自上而下的需求分析技术进展 软件概念模型分析出的软件需求，实际上包含了软件功能需求和软件性能需求（软件约束是从“不能做什么”的角度来定义软件需求，因此，也可归并到性能需求中）。在需求分析方面，人们进一步扩展了用于描述软件需求的其他模型。通常包括：图1-6 软件架构的“4+1”视图模型（1）组织结构和人员模型。研究用户组织结构和人员模型，以及软件功能在用户组织结构上的分配和权限、软件对用户组织和人员的影响等。（2）信息模型。研究软件系统涉及到的数据、信息、文件以及未来的存储、加工等需求。E-R（Entity-R
37、elationship，实体-联系）图、DFD（Data Flow Diagram，数据流图）、数据字典等均可用于信息模型的建模。（3）业务模型。研究项目或产品应用后，信息化的业务模型、信息化后的业务处理方式和业务流程、人机之间的接口和协作关系等。从业务模型出发，不仅可以得到工作流程，而且还可以得到大多数未来软件系统的调度规约、运行规约和相关的维护、管理制度。高阶的业务模型图可以是很简单的业务流程概念图，而细化的业务模型图可详细分析具体业务的工序甚至工步。（4）环境模型。描述系统的部署方式、安装方式、环境要求等。这些模型解释了系统概念模型（系统应该做什么）之外更广泛的问题，严格的项目可使用UM
38、L（Unified Modeling Language，统一建模语言）进行描述，实际工作也常使用Visio图、Word绘图进行描述。1.2.2 实现步骤虽然并不存在一个可套用的问题定义和归结模型的模式，但通常下列工作总需要在问题定义阶段完成：（1）用户需求细节的获取、采集、整理、确认、分析和管理，可能会用到调研、需求工程、原型化方法、需求管理等手段。（2）就原有的用户业务建模，包括企业级、系统级和关键业务的业务模型。并依据模型分析的结果，参照已经获取到用户软件需求进行匹配和确认，确认业务模型中的关键域和需要解决的重点问题。（3）假想信息化后的业务模型图，建立分层的、高阶的其他扩展项目视图（组织
39、模型、信息模型、业务模型、环境模型），包括这些模型的优化和改进。在这些模型中比较、分配和确认用户需求。这些模型的总和，形成了用户的需求概念模型。（4）根据需求概念模型使用系统分析、建模手段建立概念模型，并将其进一步细化为系统的全部目标，包括功能清单、性能清单、约束条件。（5）将功能、性能等重新分配到需求概念模型，可以得到未来项目或产品构成与实施的基本要素和原则。（6）依据概念模型和功能点清单、性能清单进一步展开后续的架构设计和软件设计工作。在这个过程中，用户描述的需求经过了两步映射被转换到可进行系统设计的需求。第一步是试图将模糊的用户需求逐步确认并建立需求的概念模型，然后以这个模型为依据，得到
40、各种细致的需求与规划模型；第二步是确立系统概念模型，并从概念模型出发，确定系统需要实现的所有功能、性能要求和约束条件。这些需求才是开发人员能够具体去设计和实现细节的基础。例如，需求概念模型中定义的要求“应该尽量降低用户的操作和使用难度”，可能被细化为概念模型中的“使用简洁的菜单和窗口”、“采用助输入手段”、“实现在线帮助和提示”等具体的功能要求。系统需求最终被归结为一系列清晰的系统功能描述清单和系统性能清单。功能描述了系统必须完成的任务，性能描述了为了实现主体功能正常使用必须达到的性能指标，约束描述了主体在具体的环境和场景下的不能作什么的限制条件，多数也可以归结到对系统性能的需求。对于分析出的
41、系统功能要求，可根据重要性、优先级、难度和对客户的价值度进行再次评估和排列。它们是未来被管理的系统需求和开发边界的基本依据。对于分析出的性能要求，同样需要进行重要性和优先级的排列。其中性能的选择，可以参照一定的指标选取原则，根据项目质量评估的标准化体系进行取舍。1.2.3 典型方法定义问题和归结模型阶段使用到的典型方法主要有需求工程、领域建模和业务过程建模。1需求工程需求工程用于获取、整理、加工、确认和管理需求。需求工程的目的是通过与用户广泛地交流，确定应用系统的目标。以工程化的方法来提出、分析、验证、组织和管理需求的过程，同时它也鼓励用户以一种积极的方式参与到需求分析活动中，通过在整个系统生
42、命周期中，用户参与和领域专家的指导作用，促使目标系统最大地满足用户需求。需求工程是一个不断反复的需求定义、记录和演化的过程，并在最终达到需求的稳定。大致可以分为5个阶段：（1）需求形成。这个阶段主要是处在一个开发者和用户不断的交流和讨论，使得要开发的系统逐渐清晰。通过这个过程，最终使得整体想法完全成型。这一阶段的需求形态是比较模糊的和破碎的，大多数需求还只存在于客户和开发组织的人员的头脑里面。（2）需求获取。通过积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合问题解决领域的用户需求。将这些明确的需求使用标准的方式，无矛盾和歧义地记录下来，从而成为系统蓝图完整描述的一部分。需求
43、的记录可以通过需求管理软件进行管理，也可以是一个简单、有层次的结构化描述文本。这一阶段的需求形态已经独立于客户或者开发组织内部的个人而存在，成为可以交换和存档的文件。因此，遵循必要的规范和采用标准描述方式是很重要的。（3）需求建模和规格说明。根据需求分析，对已获取的需求进行抽象描述，为目标系统建立一个概念模型。同时对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。（4）需求验证。以需求规格说明书为依据，使用系统功能和项目约束进行需求验证、保证这些需求和约束都能得到满足，同时也可以使用模拟或快速原型方法，验证需求规格说明的正确性和可行性。（5）需求管理。跟踪和管理需求变化，支持系统
44、的需求演化，实现需求的双向跟踪。希赛教育专家提示：需求工程可分为需求开发和需求管理两大工作，其中需求开发分为需求获取、需求分析、编写规格说明书（需求定义）和需求验证4个阶段，需求管理包括定义需求基线、处理需求变更及需求跟踪等方面的工作。这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。有关这方面的详细知识，请阅读本套丛书中的系统分析师考试全程指导（2009版）的第9.6节。2领域建模和业务过程建模传统软件工程在采集需求和分析需求时，通常并不考虑需求根源和变化的由来，也没有对研究系统功能在用户的整个业务执行中的作用和协作关系。这样，系统需求的质量以及这些需求在多大程度上能与
45、用户的最终目标相匹配，就比较依赖于系统分析师、用户代表和领域专家的个人水平和沟通能力。对于很多对自身业务理解或IT技术不充分的用户来说，即使开发公司具有充分的技术积累，不能得到充分准确的需求也会严重影响后期的系统质量和大大增加项目风险。这些问题需要依赖对领域和对业务过程进行建模来解决，图1-7是一个业务过程建模的例子。用于领域建模和业务过程建模的工具和方法学，与系统分析设计使用的工具和方法学是一致的（例如，使用UML对高阶的商业过程进行建模），只是针对的领域不同而已。目前，在领域建模和业务过程建模领域，尚没有统一的标准，但已经存在一些共识和有益的探索。图1-7 业务过程建模的示例由于需求工程的
46、输入是初步的需求定义，输出是文档化的需求定义；软件工程的输入是文档化的需求定义，输出是软件。领域工程、需求工程、软件工程三者之间本身存在衔接和配合关系。对于质量、效率和目标的共同需求，导致对领域建模、需求建模和软件设计建模进行一体化建模的呼声不断出现，而软件工程领域的激进实践者，已经在试验模型驱动的方法，包括模型驱动编程（Model Driven Programming，MDP）、模型驱动架构（Model Driven Architecture，MDA），以及模型驱动需求定义（Model Driven Requirements，MDR）等。就某一个系统的开发而言，是否使用这些流行的方法并无定论
47、，但总的原则在于，需要高度重视业务和需求。希赛教育专家提示：不管使用哪一种方法进行分析与设计，越接近问题的本质，就越有助于问题的解决。1.3 可行性研究可行性研究的主要目的就是回答一个问题，即所提出的项目是否可以完成。这就要求系统分析师能够进行一次压缩和简化的系统分析与设计，也就是在较高的抽象层面上进行分析和设计。不过，需要注意的是，可行性研究毕竟不是解决问题，而是研究问题的范围，探索这个问题是不是值得去解决，根据现有的情况是否有能力，是否有可能找到较好的、成本效益合算的解决方案。1.3.1 可行性研究的意义在项目计划和选择的过程中，需要完成的首要事情是对项目进行估算。项目估算的范围涉及方方面
48、面，例如，项目或产品开发的范围、投入和回报、项目风险、作用和意义等。在传统的信息系统建设方法中，是以可行性研究的方式来组织对项目的主要估算内容的。在企业实际的业务过程中，可行性研究通常作为一个重要的环节，被包含在整个项目立项、或项目选择和确认的过程中。可行性研究的范围可能覆盖很广泛的技术、经济、执行、环境等各种需要评估的因素，但它并不是最后的精细计划（例如，项目的时间进度以及人员安排）。通常，在进行可行性研究的阶段，甚至项目的目标或产品的最终方向也是高度易变化的。但可行性研究的意义在于，虽然可行性研究不能指出项目最终的精细计划和方向，但可行性研究可以在项目定义阶段用较小的代价识别出错误构思的系统，从而规避未来更多的资源投入的损失（时间、资金、人力、机会），或者因遭遇到无法逾越的技术障碍或环境障碍导致的不可避免的失败。对于那些可行性研究表明可执行的项目来说，可行性研究的结果也不承诺系统的收益一定很巨大，或技术风险和资源投入就一定很低，但可行性研究的结果设立了一个“底线”，即“如何做，则风险和收益是什么这样”的控制范围。这些评估结果给了未来的项目评估、项目风险控制甚至在资源
