本文主要是介绍[架构之路-157]-《软考-系统分析师》- 9-信息系统规划-2-少量人力进行项目初步调研(系统分析师的首要任务)与可行性研究报告,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
9 . 3 初步调查
1. 初步调查的目标
9.4可行性研究
9.4.1可行性评价准则
1 . 经济可行性(钱的可行性)
2 . 技术可行性(能力可行性)
3 . 法律可行性(社会)
4 . 用户使用可行性(用户)
5. 进度可行性
9.4.2 可行性研究的步骤
1 . 复查系统目标和规模:目标或背景?
2 . 分析现有系统:能做什么?=》高层系统活动流程图
3 . 导出新系统的五种高层逻辑模型:这是技术可行性分析最重要的输出
4. 用户复核
5. 提出并评价解决方案
6. 确定最终推荐的解决方案
7. 草拟开发计划
8. 编制和提交可行性研究报告
9 . 4 . 3 可行性研究报告
1.可行性研究报告的正文格式
2.可行性论证会
9 . 5 成本效益分析技术
9.5.1成本和收益
1.成本
2.收益
3. 盈亏临界分析
9.5.2净现值分析
9.5.3投资回收期与投资回报率
9 . 6 建议方案的解决方案
9.6.1 建议方案的可行性评价
1. 候选系统方案矩阵
编辑
2 . 可行性分析矩阵
9 . 6 . 2 系统建议方案报告
( 1 ) 前置部分。
( 2 ) 系统概述。
( 3 ) 系统研究方法。
( 4 ) 候选系统方案及其可行性分析。
( 5 ) 建议方案:重点内容
( 6 ) 结论。
( 7 ) 附录。
9 . 3 初步调查
信息系统建设•一般都是由用户/客户提出要求幵始的,而用户的要求通常只是一个简单的初始需求,而且常常是罗列一些需要解决的问题。因此,摆在系统分析师面前的是首要任务,就是对用户提出的要求做出一个准确的认识和估计。为此,必须在开展初步调查的基础上,明确问题,并对项目进行可行性研究。
信息系统是解决客户所需要的问题或痛点,初步调查的目的就是弄清楚可以客户要解决的问题与痛点。
1. 初步调查的目标
为了使系统开发工作更加有效地展开,通常将系统调査分为两步,
第一步是初步调 查,即先投入少量人力对系统进行大致的了解,然后再看有无开发的可行性;
第二步是 详细调査,即在系统幵发具有可行性并己经正式立项后,再投入大量人力展开大规模、 全面的系统业务调杳。有关这方面的知识,将 在 10.2节中介绍。
幵发新系统的要求往往来自用户对现有系统的不满,但在正式立项之前必须进行可行性研究,而可行性研究的基础是对系统的初步调查。
由于存在的问题可能充斥各个方 面,内容分散,甚至含糊不清,所以初步调査的目标就是掌握用户的概况,从整体上了 解企业信息系统建设的现状,对用户提出的各种问题和初始需求进行识别,明确系统的 初步目标,为可行性研究提供工作基础。
2 . 初步调查的方式
初步调査的最佳方式是与企业高层管理人员座谈(业务需求),通过座谈了解企业髙层对信息系 统所设定的目标和系统边界,计划的资金投入和对工期的要求。
还应与企业I T 部门的负 责人座谈(系统系统现状),了解企业现有系统、取得的效果和存在的问题,以及系统需要更新的原因。
最好能访问企业主要业务部门的领导,征求他们对新的信息系统建设的意见以及对新系 统功能的要求。
初步调杳主要围绕着系统规划工作进行,收集有关宏观信息,并了解企业不同位置和不同部门的人对新系统建设的态度。应立足于宏观和全面,不需要过于具体和细致。
不同管理层的态度非常重要!!!
总之,要获得公司各个部门的领导对新的信息系统的诉求和态度!!!
3 . 初步调查的内容
初步调査主要由两部分组成,分别是一般调查和信息需求初步调査。
前者包括了解企业当前的信息流程,明确企业改造的需求,确定系统目标和主要功能,使系统分析师对企业有一个初步轮廓。
后者是整个初步调查的主要内容,调査企业的组织结构、职责 和活动,即了解企业的业务模式,了解各职能机构所要处理的数据,还应调査环境信息,包括内部环境和外部环。
具体来说,初步调查的主要内容包括以下4 个方面:
(1) 初步需求分析(为什么? 背景?目的?)
初步调査的第一步就要从用户提出新系统建设的缘由,以及从用户对新系统的要求入手,考查用户对新系统的需求,预期新系统要达到的目标。
因为信息系统将会涉及企业管理工作的各个方面,所以此处所说的“用户”是指企业各级管理人员。他们对新系统开发的需求状况、新系统的期望目标、是否愿意下大力气参与和配合系统开发;
在新系统改革涉及用户业务范围和习惯做法时,他们是否有根据系统分析和整体优化的要求调整自己职权范围和工作习惯的心理准备;
高层管理人员有无参与幵发工作、协调下级管理部门业务和职能关系的愿望等,都是首先要着手了解的内容。
(2) 企业基本状况。=》了解企业,就是了解信息系统的相关的业务。
包括企业的性质、规模、历史,所在行业的性质、管理目标与模式,人力、物力、技术、设备和组织结构等。这些都是与系统可行性研究、系统建设方案和下一步的详细调査直接相关,因此,应该在初步调查中弄淸楚。除这些基本情况外,还必须调杳淸楚企业近期预计发生变化的可能性,包括企业兼并、产品转向、厂址迁移、周围环境的变化等。
(3) 管理方式和基础数据管理状况。
这是整个初步调查的重点,它与将要建设的系统密切相关。但是,在初步调查阶段,系统分析师只需要对这些做大致的了解,定性了解对新系统建设能否支持即可。进一步深入的了解留待详细调查去解决。对管理方式的调查包括企业整体管理状况的评估、组织职能机构与管理功能、電点职能部门(例如,计划、生产、财务、销售等)的大致管理方式,以及这些管理方式用信息系统来辅助实
现的可行性,可以预见的将要更改的管理方法和这些新方法将会对新系统以及实现管理问题所带来影响和新的要求等。另外,还必须调查企业基础数据管理状况,例如,基础数据工作是否完善,相应的管理指标体系是否健全,统计手段、方法和程序是否合理,用户对于系统的期望值有无实际的数据支持等。如果没有的话,让企业增设这些管理数据指标和统计方法是否具有可行性。
(4) 现有系统状况。
包括现有系统的运行状况、特点、所存在的问题、可利用的信息资源、可利用的技术力量,以及可利用的信息处理设备等。这部分调査是提出新系统建议方案及其在技术上是否具有可行性的原始资料。
9.4可行性研究
可行性研究也称为可行性分析,是所有项目投资、工程建设或重人改革在开始阶段必须进行的一项工作。它是经济活动中经常使用的一种决策程序和手段,也是投资前的必要环节。
可行性研究必须从系统总体出发,对技术、经济、执行等多个方面进行分析和论证,以确定信息系统建设项目是否可行,为正确进行投资决策提供科学依据。
项目的可行性研究是对多因素、多目标系统进行的分析、评价和决策的过程,它需要有各方面知识的专业人才通力合作才能完成,例如,系统分析师、资深系统幵发人员、客户代表、法律顾问和市场顾问等。
在许多 I T 企业中,并不重视甚至从未幵展过可行性研究工作,因为很多项目都是因客户的订单而产生的,或者是投标性的项目, 只要按照招标书的要求去应答就行。结果往往是拿到客户的订单或者中标后,在系统建设或开发的过程中,发现诸多问题,例如,合同规定的费用根本就抵不上投入的成本,项目时间根本就不够用。于是,通常以降低系统的质量为代价,来 “满足”合同的要求。这样,客户自然就不会满意,建设方和承建方之间的“拉锯战”由此展开。所 谓 “做一个单,丢一个客户”就是这种现象的真实写照。因此,对于一个追求成功的 I T 企业来说,可行性研究工作是不应该省略的,一个不可行的项目,不管团队花费多大的努力,终究难逃失败的宿命。
9.4.1可行性评价准则
可行性是指在企业当前的条件下,是否有必要建设新系统,以及建设新系统的工作是否具备必要的条件。也就是说,可行性包括必要性和可能性。参考国家标准《计算机软件文档编制规范》( G B / T 8567—2006),在信息系统建设项目中,可行性研究通常从经济可行性、技术可行性、法律可行性和用户使用可行性4 个方面来进行分析,其中经济可行性通常被认为是项目的底线。
1 . 经济可行性(钱的可行性)
经济可行性也称为投资收益分析或成本效益分析,主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。
多数项目只有建设成本能控制在企业可接受的预算内的时候,项目才有可能被批准执行。
而经济收益的考虑则非常广泛,可以分为直接收益和间接收益、有形收益和无形收益,还可以分为一次性收益和非一次性收益、可定量的收益和不可定最的收益等。有关成本效益分析的详细知识,将在9.5节中 介绍。
要注意的是,在系统开发初期,由于用户需求和候选系统方案还没有确定,成本不可能得到准确的估算。因此,此时的经济可行性分析只能大致估算系统的成本和收益,判断信息系统的建设是否值得。
2 . 技术可行性(能力可行性)
技术可行性也称为技术风险分析,研究的对象是信息系统需要实现的功能和性能,以及技术能力约束。
技术可行性主要通过考虑以下问题来进行论证:
(1) 技术:
现有的业务技术能力和计算机信息技术的发展现状是否足以支持系统目标的实现。
( 2 ) 资源:
现有的资源(例如,掌握技术的员工、企业的技术积累、构件库、软硬件条件等)是否足以支持项目的实施。
( 3 ) 目标:
由于在可行性研究阶段,项目的目标是比较模糊的,因此技术可行性最好与项目功能、性能和约束的定义同时进行。
在可行性研究阶段,调整项目目标和选择可行的技术体系都是可以的,而一旦项目进入开发阶段,任何调整都意味着更多的开销。
需要特别指出的是,技术可行性绝不仅仅是论证在技术手段上是否可实现,实际上 包含了在当前资源条件下的技术可行性。例如,开发一个计算机操作系统对f 美国微软 公司来说,这是可行的,但对其他绝大多数企业来说,这都是不可行的。
投资不足、时间不足、预设的开发目标技术难度过大、没有足够的技术积累、没有熟练的员工可用、 没有足够的合作企业和没有足够外包资源积累等都是技术可行性的约束。
实践证明,如果只考虑 技术实现手段而忽视企业当前的资源条件和环境,从而对技术可行性分析得出过于乐观 的结果,将会对后期的项目实施导致灾难性后果。
对于技术的选择,有的企业钟情于新技术,有的则喜欢使用成熟的技术。具体要根 据项目的实际情况(例如,开发环境、开发人员的素质、系统的性能要求等)进行决策, 但通常的建议是尽可能采用成熟的技术,慎重引入先进技术。
I T 业界流行的诙谐语“领 先一步是先进,领先两步是先烈”讲的就是对技术的选择原则。
3 . 法律可行性(社会)
法律可行性也称为社会可行性,具有比较广泛的内容,它需要从政策、法律、道德、 制度等社会因素来论证信息系统建设的现实性。
例如,所开发的系统与国家法律或政策 等相抵触,在政府信息化的领域中使用了未被认可的加密算法,未经许可在产品中使用 了其他企业的被保护的技术或构件等,这样的项目在法律可行性上就是行不通的。
4 . 用户使用可行性(用户)
用户使用可行性也称为执行可行性,是从信息系统用户的角度来评估系统的可行性,包括目标企业的行政管理和工作制度、使用人员的素质和培训要求等,可以细分为管理可行性和运行可行性。
( 1 ) 管理可行性。
管理可行性是指从企业管理上分析系统建设可行性。
主管领导不支持的项目一般会失败,中高层管理人员的抵触情绪很大,就有必要等一等,先积极做 好思想工作,创造条件。
另外,还要考虑管理方法是否科学,相应的管理制度改革的时 机是否成熟,规章制度是否齐全等。
( 2 ) 运行可行性。
运行可行性也称为操作可行性,是指分析和测定信息系统在确定 环境中能够有效工作,并被用户方便使用的程度和能力。例如,E R P 系统建成后的数据采集和数据质量问题,企业工作人员没有足够的I T 技能等。这些问题虽然与系统本身无 关,但如果不经评估,很可能会导致投入巨资建成的信息系统却毫无用处。
运行可行性还需要评估系统的各种影响,包括对现有I T 设施的影响、对用户组织机构的影响、对现 有业务流程的影响、对地点的影响、对经费幵支的影响等。如果某项影响会过多改变用 户的现状,需要将这些因素作进一步的讨论并和用户沟通,提出建议的解决方法。否则, 系统一旦建成甚至在建设过程中,就会受到用户的竭力反对,他们会抵制使用系统。
5. 进度可行性
除国家标准规定外,还需要对目项的进度进行可行性分析。进度可行性主要是指对 项目的最后期限的合理性进行评估。有些项目的最后期限是强制的,有些项目则是期望 的,这需要区别对待。在进行可行性分析时,系统分析师需要凭借自己的经验,参考类似的系统,评估在已有资源约束的条件下,能否按最后期限完成整个项目。
9.4.2 可行性研究的步骤
可行性研究是一个特定的过程,用来识别项目可能存在的问题、机会或要求,确定项目目标,描述现有状况和成功后的成果,对问题的不同解决方案根据可行性准则进行 评价和比较,选择最合适的方案,编写和提交可行性研究报告。
具体来说,可行性研究 工作可以分为以下8 个步骤:
1 . 复查系统目标和规模:目标或背景?
系统分析师应访问关键人员,认專阅读和分析有关材料,以便进一步复查、确认系 统的目标和规模,改正含糊或不确切的叙述,清晰地描述对系统的一切限制和约束。这 个步骤的关键是对系统目标、规模、相关约束和限制条件作出更加细致的定义,使之更 加淸晰、明确、没有歧义性,确保系统分析师正在解决的问题确实是要求他们解决的 问题。
2 . 分析现有系统:能做什么?=》高层系统活动流程图
系统分析师应该认真阅读、分析现有系统的文档资料和使用手册,也要实地考察现有系统,注意了解它做了什么。还要了解使用现有系统的代价和其存在的缺点。
要注意 的是,这个步骤的目的是了解:现有系统能做什么,而不是了解它怎么做这些工作,所以不必花费太多时间去了解系统实现的细节。
在这个步骤中,系统分析师应该画出描述现有系统的高层系统流程图,记录现有系统和其他系统之间的接口情况,并请有经验的人员检验其是否正确。
3 . 导出新系统的五种高层逻辑模型:这是技术可行性分析最重要的输出
在系统目标和规模、现有系统研究的基础上,就可以从现有系统的物理模型出发, 导出现有系统的逻辑模型,描述数据在系统中的流动和处理情况,从而概括地表达出对 新系统的设想,即对新系统进行建模。
建模的目的是为了获得一个对新系统的框架认识和概念性认识。
通常可以采用以下五种技术:
( 1 ) 系统上下文关系范围图: 结构化分析方法之数据流图
其实也就是D F D 的 0层图,将系统与外界实体(可 能是用户,也可能是外部系统)的 关 系 (主要是数据流和控制流)体现出来,从而淸晰地界定出系统的范围,实现共识。
它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
(2) I P O (Input/Process/Output,输入/处理/输出)图。
这是采用传统的结构化思想.从输入、处理、输出的角度对系统进行的描述。
有关 I P O 图的详细知识,将 在 13.2.3节中介绍。
IPO是指结构化设计中变换型结构的输入(Input)、加工(Processing)、输出(Output)。
IPO图是对每个模块进行详细设计的工具,它是输入加工输出(INPUT PROCESS OUTPUT)图的简称,它是由美国IBM公司发起并完善起来的一种工具。在系统的模块结构图形成过程中,产生了大量的模块,在进行详细设计时开发者应为每一个模块写一份说明。IPO图就是用来说明每个模块的输入、输出数据和数据加工的重要工具。
(3) 面向对象分析方法之E - R 图。
这是系统的数据模型,这个阶段并不需要生成完整的E - R 图,而是找到主要的实体及其关系即可。
(4) 面向对象分析方法之用例模型 =》 功能图
这是采用面向对象思想,描述一组用例、参与者及它们之间的关系。有 关用例模型的详细知识,将 在 11.5.2节中介绍。
( 5) 面向对象分析方法之领域模型 =》 类图
这也是采用0 0 思想,找到系统中主要的实体类,并说明实体类的主要特征和它们之间的关系。
有关领域模型的详细知识,将 在 11.5.3节中介绍。
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。
4. 用户复核
新系统的逻辑模型只是代表系统分析师对新系统必须做什么的看法,而不是代表用户。因此,系统模型建立之后,一项十分重要的工作就是与客户一起进行复核。在这个过程中,如果发现模型与用户的目标有不一致的地方,就应该再次通过访谈、现场观摩、对现有系统分析等手段进行了解,然后在此基础上修改模型。因此,可行性研究的前4个步骤是一个循环,周而复始,直至用户确认了新的系统模型为止。
5. 提出并评价解决方案
系统分析师从系统的逻辑模型出发,导出若干较高层次的(较抽象的)解决方案供比较和选择。应该尽量列举出各种可行的解决方案,并且对这些解决方案的优点、缺点作一个综合性的评价,以便于下一步决策。在这个步骤中,可以使用候选系统方案矩阵和可行性分析矩阵,前者是用来记录候选方案之间的相同和不同的工具,后者是用来评定候选>案的工具。有关这方面的详细知识,将在9.6节中介绍。对于那些明显不可行的,如技术上还没有相应的办法、经济角度明显不可行的、违
背企业或行业实际情况的解决方案应该直接过滤掉。
6. 确定最终推荐的解决方案
根据可行性评价准则,对系统的各种解决方案进行分析和比较后,如果系统分析师认为值得继续进行项目建设工作,则就应该确定最终的推荐方案,并说明选择这个方案的理由。
对被推荐的解决方案还要进行更加完善的成本效益分析,才能让企业决策人员根据经济上是否划算来决定是否正式立项。
7. 草拟开发计划
系统分析师需要进一步制订一个粗略的开发计划,说明系统建设所需的资源、人员和时间进度安排情况,这将作为立项后制订项目开发计划的基础。有关项目开发计划的详细知识,将在20.1节中介绍。
8. 编制和提交可行性研究报告
将可行性研究各步骤的结果整理成文,形成清晰的文档,即可行性研究报告。
将可行性研究报告提交给用户和管理层,进行审查通过。有关可行性研究报告的格式和内容,将在9.4.3节中介绍。
9 . 4 . 3 可行性研究报告
可行性研究报告是项目初期策划的结果,它分析了项目的要求、目标和环境,提出了几种可供选择的方案,并从技术、经济、法律等各方面进行了可行性分析。
可行性研究报告是项目决策的依据,也可作为系统建设方案或投标书等文件的基础。
1.可行性研究报告的正文格式
在国家标准 G B / T 8567—2006中,提供了一个可行性研究报告的文档模板和编写指南,其中规定了在可行性研究报告中应该包括如下内容:
( 1 ) 引言。
主要对项目及可行性研究报告做一个概要性的描述,说明可行性研究报告适用的系统和完整标识:为阅读者提供一些项目相关的背景资料,说明项目在什么条件下提出,提出者的要求、目标、实现环境和限制条件;简述可行性研究报告适用的项目和系统的用途,描述项目和系统的一般特性,标识项目的投资方、需方、用户、承建方和支持机构,标识当前和计划的运行现场;概述可行性研究报告的用途和内容,并描述与其使用有关的保密性和私密性的要求。
( 2 ) 引用文件。
列出可行性研究报告中引用的所有文档的编号、标题、修订版本和曰期,还应标识不能通过正常的供货渠道获得的所有文档的来源。
(3) 可行性研究的前提。
包括项目的要求、目标、环境、条件、假定和限制等,还应该说明将采用的可行性研究方法(例如,调査、加权平均、系统模型或仿真等),以及评价系统所使用的主要尺度(例如,费用的多少、各项功能的优先次序、项目周期、使用的难易程度等)。
(4) 可选的方案。
说明现有系统的优点和缺点、局限性和存在的问题,是否有可复用的系统,以及它们与要求之间的差距。
然后再逐一列举所有的可选择的系统解决方案,最后再给出选择最终方案的准则/原则。
(5) 所建议的系统。
针对系统的目标和要求,提出一个可行的解决方案,并且针对这些因素,论证系统是如何满足的。具体包括对所建议的系统的说明、处理流程和数据流程、与现有系统的比较、影响或要求(包括设备、系统、运行、开发、环境、经费等)和新系统的局限性。
(6) 经济可行性。
从经济角度来说明解决方案的可行性,主要包括:
投资(基本建设投资、其他一次性投资和非一次性投资)、
预期的经济收益(一次性收益、非一次性收益、不可定量的收益)、
收益/投资比、投资回收周期和市场预测。
(7) 技术可行性:包括组织现有资源的约束
从技术角度来说明解决方案的可行性,包括企业现有资源(例如,人员、环境、设备和技术条件等)能否满足项目实施要求,若不满足,应考虑补救措施(例如,需要增加人员、投资和设备等),涉及经济问题应进行投资、成本和效益可行性分析,最后确定项目是否具备技术可行性。
(8) 法律可行性。
从社会角度来说明解决方案的可行性,主要包括系统的建设是否符合法律、法规的要求,系统开发可能导致的侵权、违法和责任。
(9) 用户使用可行性。
从用户角度来说明解决方案的可行性,主要包括用户单位的行政管理和工作制度,使用人员的素质和培训要求等。
(10) 其他与项目有关的问题。
列举其他与项目有关的重要问题,主要是预测未来可能的变化。
(11) 注解。
包含有助于理解可行性研究报告的一般信息,例如,背景信息、词汇表、原理等。这一部分应包含为理解可行性研究报告需要的术语和定义,所有缩略语和它们在可行性研究报告中的含义的字母序列表。
(12) 附录。
提供那些为便于维护可行性研究报告而单独编排的信息(例如,图表、分类数据等)。为便于处理,附录可以单独装订成册,按字母顺序编排。
2.可行性论证会
可行性研究报告提交给上级主管部门(或领导)以后,按规定应召开由主管部门(或领导)主持,各相关部门(单位)的代表参加的可行性论证会,也可以邀请业内专家参加会议。在会上,
首先, 让系统分析师或可行性研究小组代表进行较详细的介绍和说明,
然后,让各方面的专家和代表进行广泛而深入的讨论和研究。
特别,应引导与会者对各种方案进行比较分析,要充分估计各种可能出现的问题讨论的结果有两种可能,
一种是:同意或基本同意可行性研究报告中的结论,或立即执行,或修改目标、追加资源和等待条件,或取消项目;
另一种是:对可行性研究报告持不同意见,对某些问题的判断有不同看法。如果不影响整个问题的结论,那么可以把问题留待需求获取和分析时解决,项目可以照常进行;
如果影响整个问题的结论,则就要返工,重新进行调查分析,
形成新的可行性研究报告,再重新召开可行性论证会。
9 . 5 成本效益分析技术
成本效益分析技术是可行性研究报告中,经济可行性研究中最重要的输出。
成本效益分析是通过比较信息系统建设的全部成本和效益来评估项目价值的一种方法,它作为一种经济可行性分析的方法,将项目的所有成本和收益一一列出,并进行量化。成本效益分析的目的是要从经济角度分析建设一个特定的新系统是否划算,首先要估算待建设系统的成本,然后与可能取得的收益进行比较与权衡,从而帮助决策人员正确地作出是否立项的决定。
9.5.1成本和收益
成本是信息系统生命周期内各阶段的所有投入之和,而收益是信息系统建成后的所有产出之和。
无论是企业运作还是项目实施,都应该努力以尽可能少的成本付出,创造尽可能多的使用价值,为企业获取更多的经济效益。
1.成本
信息系统建设项目的成本有多种分类方法,其中常见的两种分类方法是按照投资时间分类和按照成本性态分类。
按照投资时间分类,可以分为基础建设投资、其他一次性投资和非一次性投资三大类。
(1)基础建设投资。
例如,房屋和设施、办公设备、平台软件、必须的工具软件等购置成本。基础建设投资既可以是一次性投资,也可以是分期付款。
(2) 其他一次性投资。
例如,研究咨询成本、调研费、管理成本、培训费、差旅费等,以及其他一次性杂费。
(3) 其他非一次性投资。
主要是指系统的运行与维护成本。例如,设备租金和定期维护成本、定期消耗品支出、通信费、人员工资与奖金、房屋租金、公共设施维护等,以及其他经常性的支出项目。
按照成本性态分类,可以分为固定成本、变动成本和混合成本。
( 1 ) 固定成本。
固定成本是指其总额在一定期间和一定业务量范围内,不受业务量变动的影响而保持固定不变的成本。例如,管理人员的工资、办公费、固定资产折旧费、员工培训费等。
固定成本又可分为酌量性固定成本和约束性固定成本。酌量性固定成本是指管理层的决策可以影响其数额的固定成本,例如,广告费、员工培训费、技术幵发经费等:约束性固定成本是指管理层无法决定其数额的固定成本,即必须开支的成本,例如,办公场地及机器设备的折旧费、房屋及设备租金、管理人员的工资等。
(2) 变动成本。
变动成本也称为可变成本,是指在一定时期和一定业务量范围内其总额随着业务量的变动而成正比例变动的成本。例如,直接材料费、产品包装费、外包费用、开发奖金等。
变动成本也可以分为酌量性变动成本和约束性变动成本。
开发奖金、外包费用等可看作是酌量性变动成本;
约束性变动成本通常表现为系统建设的直接物耗成本,以直接材料成本最为典型。
(3) 混合成本。
混合成本就是混合了固定成本和变动成本的性质的成本。例如,水电费、电话费等。这些成本通常有一个基数,超过这个基数就会随业务量的增大而增大。例如,质量保证人员的工资、设备动力费等成本在一定业务量内是不变的,超过了这个量便会随业务量的增加而增加。有时,员工的工资也可以归结为混合成本,因为员工平常的工资一般是固定的,但如果需要加班,则加班工资与时间的长短便存在着正比例关系。
2.收益
系统的收益可以分为有形收益和无形收益。
有形收益也称为经济收益,可以用货币的时间价值、投资回收期、投资回收率等指标进行度量。
有形收益又可分为一次性经济收益和非一次性经济收益。
(1) 一次性经济收益。
一次性经济收益主要体现在开支的缩减和价值的提升。幵支的缩减是指改进了的系统的运行所引起的开支缩减。例如,资源要求的减少,运行效率的改进,数据进入、存储和恢复技术的改进等•,价值的提升是指由于应用系统的使用价值的提升所引起的收益。例如,资源利用的改进,管理和运行效率的改进和出错率的减少等。另外,信息系统建设的一次性收益可能还包括其他方面的收入,例如,从多余设备出售回收的收入等。
(2) 非一次性经济收益。
在信息系统整个生命周期内,由于运行系统而导致的按月的、按年的能用货币数目表示的收益,包括开支的减少和避免。例如,由于信息系统的使用,提高了工作效率,每个月节约的人员工资等。
无形收益也称为不可定量的收益,主要是从性质上、心理上进行衡景,很难直接进行量上的比较。例如,服务的改进,由操作失误引起的风险的减少,信息掌握情况的改进,企业形象的改善等。有些无形收益可以用定性估算的方法或极值分析(最大、最小、乐观、悲观)方式归结到有形收益上;有些无形收益即使进行估算也非常困难,但常常涉及企业的长期利益。例如,技术积累、对公司业务和产品线的完善和支持、开辟新市场和利润增长点、进入预期能带来较高收益的新市场、提高客户满意度和忠诚度、打击竞争对手抢夺市场份额、获得新的信息化能力从而改善经营或管理格局等。这些无形收益有特殊的潜在价值, R 在某些情况下会转化成有形收益。
3. 盈亏临界分析
是指项目收入和成本相等的经营状态。
可以用销售量来表示,即盈亏临界点的销售量;
也可以用销售额来表示,即盈亏临界点的销售额。
9.5.2净现值分析
9.5.3投资回收期与投资回报率
9 . 6 建议方案的解决方案
根 据 9.4.2节的介绍,在可行性研究的第5 个步骤中,系统分析师应该从系统的逻辑模型出发,提出若干个系统解决方案,对每个候选方案进行分析,描述每个方案的成本和效益、优点和缺点。
9.6.1 建议方案的可行性评价
1. 候选系统方案矩阵
2 . 可行性分析矩阵
在 表 9-5中,矩阵的行主要对应可行性评价准则,但也增加了候选系统方案的一般 描述和等级评定;矩阵的列主要对应候选系统方案,同时也增加了每类可行性评价准则 所占的权重系数,因为不是所有的准则都是同等重要的。
每个准则的具体权重系数,需要根据项目的实际情况而定。当对每个候选系统方案在每个可行性评价准则上评分(或 分级)后,最终的评分(或分级)记录在最后一行。
根据最终的评分(或分级),系统分 析师可以选择一个整体最优的方案作为推荐方案。
9 . 6 . 2 系统建议方案报告
根据项目规模的大小,推荐系统方案既可以单独形成文档(系统建议方案报告、系统方 案说明书),也可以合并到可行性研究报告中。
如果单独形成文档,其内容和格式与可行性研究报告也是类似的。
作为一个正式文档,系统建议方案报告至少应该包含以下内容:
( 1 ) 前置部分。
包括标题、目录和摘要。摘要部分以1〜 2 页的篇幅总结整个系统 建议方案报告,提供系统方案中的重要时间、地点、人物、原因,以及系统方案是如何 实现的等信息。因为多数高层管理人员没有时间读完整个报告,他们可能只阅读摘要。 因此,摘要部分显得特别重要。
( 2 ) 系统概述。
包括系统建议方案报告的目的、对问题的陈述、项目范围和报告内容的叙述性解释。
( 3 ) 系统研究方法。
简要地解释系统建议方案报告中包含的信息是如何得到的,研 究工作是如何进行的。例如,通过各种调查技术获取用户初步需求,通过座谈和观察获 取现有系统的资料等。 ’
( 4 ) 候选系统方案及其可行性分析。
系统阐述每个候选系统方案,并 采 用 9.6.1节 中介绍的方法进行可行性评价。
( 5 ) 建议方案:重点内容
在对各个候选系统方案进行可行性评价之后,通常会推荐一个解决方案,并且要给出推荐该解决方案的理由。
( 6 ) 结论。
简要地描述摘要的内容,再次指出系统开发的目标和所建议的系统方案。 同时,需要再次强调项目的必要性和可行性,以及系统建议方案报告的价值。
( 7 ) 附录。
系统分析师认为阅读者可能会感兴趣的所有信息,但这些信息对于理解 系统建议方案报告的内容来说不是必要的。
这篇关于[架构之路-157]-《软考-系统分析师》- 9-信息系统规划-2-少量人力进行项目初步调研(系统分析师的首要任务)与可行性研究报告的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!