您好,欢迎访问三七文档
第2章可行性研究2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.7小结2.1可行性研究的任务可行性研究的目的不是解决问题,而是确定问题是否值得去解决。怎样达到这个目的呢?当然不能靠主观猜想而只能靠客观分析。必须分析几种主要的可能解法的利弊,从而判断原定的系统规模和目标是否现实,系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。因此,可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。首先需要进一步分析和澄清问题定义。在问题定义阶段初步确定的规模和目标,如果是正确的就进一步加以肯定,如果有错误就应该及时改正,如果对目标系统有任何约束和限制,也必须把它们清楚地列举出来。在澄清了问题定义之后,分析员应该导出系统的逻辑模型。然后从系统逻辑模型出发,探索若干种可供选择的主要解法(即系统实现方案)。对每种解法都应该仔细研究它的可行性,一般说来,至少应该从下述三方面研究每种解法的可行性:(1)技术可行性:使用现有的技术能实现这个系统吗?(2)经济可行性:这个系统的经济效益能超过它的开发成本吗?(3)操作可行性:系统的操作方式在这个用户组织内行得通吗?必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。可行性研究可行性研究需要的时间长短取决于工程的规模。一般说来,可行性研究的成本只是预期的工程总成本的5%~10%。2.2可行性研究过程典型的可行性研究过程有下述一些步骤。1.复查系统规模和目标分析员访问关键人员,仔细阅读和分析有关的材料,以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认,改正含糊或不确切的叙述,清晰地描述对目标系统的一切限制和约束。这个步骤的工作,实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。2.研究目前正在使用的系统现有的系统是信息的重要来源。新的目标系统必须也能完成它的基本功能;另一方面,如果现有的系统是完美无缺的,用户自然不会提出开发新系统的要求,因此,现有的系统必然有某些缺点,新系统必须能解决旧系统中存在的问题。此外,运行使用旧系统所需要的费用是一个重要的经济指标,如果新系统不能增加收入或减少使用费用,那么从经济角度看新系统就不如旧系统。应该仔细阅读分析现有系统的文档资料和使用手册,也要实地考察现有的系统。应该注意了解这个系统可以做什么,为什么这样做,还要了解使用这个系统的代价。但注意:这个步骤的目的是了解现有系统能做什么,而不是了解它怎样做这些工作。分析员应该画出描绘现有系统的高层系统流程图,并请有关人员检验他对现有系统的认识是否正确。千万不要花费太多时间去了解和描绘现有系统的实现细节。没有一个系统是在“真空”中运行的,绝大多数系统都和其他系统有联系。应该注意了解并记录现有系统和其他系统之间的接口情况,这是设计新系统时的重要约束条件。3.导出新系统的高层逻辑模型优秀的设计过程通常总是从现有的物理系统出发,导出现有系统的逻辑模型,再参考现有系统的逻辑模型,设想目标系统的逻辑模型,最后根据目标系统的逻辑模型建造新的物理系统。通过前一步的工作,分析员对目标系统应该具有的基本功能和所受的约束已有一定了解,能够使用数据流图,描绘数据在系统中流动和处理的情况,从而概括地表达出他对新系统的设想。通常为了把新系统描绘得更清晰准确,还应该有一个初步的数据字典,定义系统中使用的数据。数据流图和数据字典共同定义了新系统的逻辑模型,以后可以从这个逻辑模型出发设计新系统。4.进一步定义问题新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标,这次复查应该把数据流图和数据字典作为讨论的基础。如果分析员对问题有误解或者用户曾经遗漏了某些要求,那么现在是发现和改正这些错误的时候了。可行性研究的前4个步骤实质上构成一个循环。分析员定义问题,分析这个问题,导出一个试探性的解;在此基础上再次定义问题,再一次分析这个问题,修改这个解;继续这个循环过程,直到提出的逻辑模型完全符合系统目标。5.导出和评价供选择的解法分析员应该从他建议的系统逻辑模型出发,导出若干个较高层次的(较抽象的)物理解法供比较和选择。导出供选择的解法的最简单的途径,是从技术角度出发考虑解决问题的不同方案。还可以使用组合的方法导出若干种可能的物理系统。当从技术角度提出了一些可能的物理系统之后,应该根据技术可行性的考虑初步排除一些不现实的系统。把技术上行不通的解法去掉之后,就剩下了一组技术上可行的方案。其次可以考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案,去掉其中从操作方式或操作过程的角度看用户不能接受的方案。接下来应该考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用,并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。在这些估计数字的基础上,对每个可能的系统进行成本/效益分析。一般说来,只有投资预计能带来利润的系统才值得进一步考虑。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表,这个进度表不需要(也不可能)制定得很详细,通常只需要估计生命周期每个阶段的工作量。5.导出和评价供选择的解法6.推荐行动方针根据可行性研究结果应该做出的一个关键性决定是,是否继续进行这项开发工程。分析员必须清楚地表明他对这个关键性决定的建议。如果分析员认为值得继续进行这项开发工程,那么他应该选择一种最好的解法,并且说明选择这个解决方案的理由。通常使用部门的负责人主要根据经济上是否划算决定是否投资于一项开发工程,因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。7.草拟开发计划分析员应该为所推荐的方案草拟一份开发计划,除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况,应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估计。8.书写文档提交审查应该把上述可行性研究各个步骤的工作结果写成清晰的文档,请用户、客户组织的负责人及评审组审查,以决定是否继续这项工程及是否接受分析员推荐的方案。2.3系统流程图系统流程图是概括地描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序,文档,数据库,人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程,因此尽管系统流程图的某些符号和程序流程图的符号形式相同,但是它却是物理数据流图而不是程序流程图。2.3.1符号当以概括的方式抽象地描绘一个实际系统时,仅仅使用图2.1中列出的基本符号就足够了。当需要更具体地描绘一个物理系统时还需要使用图2.2(见书29页)中列出的系统符号,利用这些符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件(或数据库),把抽象处理具体化为特定的程序或手工操作等。图2.1基本符号2.3.2例子介绍系统流程图的最好方法可能是通过一个具体例子说明它的用法。下面是一个简单的例子。例:某装配厂有一座存放零件的仓库,仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时,应该及时修改库存清单主文件,如果哪种零件的库存量少于它的库存量临界值,则应该报告给采购部门以便定货,规定每天向采购部门送一次定货报告。该装配厂使用一台小型计算机处理更新库存清单主文件和产生定货报告的任务:●零件库存量的每一次变化称为一个事务,由放在仓库中的CRT终端输入到计算机中;●系统中的库存清单程序对事务进行处理,更新存储在磁盘上的库存清单主文件,并且把必要的定货信息写在磁带上;●每天由报告生成程序读一次磁带,并且打印出定货报告。下图的系统流程图描绘了上述系统的概貌。2.3.2例子(续)图2.3库存清单系统的系统流程图注:系统流程图的习惯画法是使信息在图中从顶向下或从左向右流动。图中每个符号用黑盒子形式定义了组成系统的一个部件,然而并没有指明每个部件的具体工作过程;图中的箭头确定了信息通过系统的逻辑路径。课堂练习——请画出系统流程图机票预订系统:•把预订机票的旅客信息输入到系统中,系统为旅客安排航班;•客户支付定金,系统打印出取票通知和帐单给旅客;•旅客在飞机起飞前一天凭取票通知和帐单交余款,取票系统核对无误后打印出机票给旅客。2223①预订机票信息输入到系统中②系统为旅客安排航班③旅客交付预订金④系统打印取票通知和帐单给旅客⑤旅客凭取票通知和帐单,交余款⑥系统核对订单信息无误后打印出机票给旅客24航班安排程序航班安排取票通知、账单生成程序交纳订金订金信息核对程序交款信息交余款旅客信息取票通知、账单机票机票打印程序2.3.3分层面对复杂的系统时,一个比较好的方法是分层次地描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌,表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度,画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。2.4数据流图数据流图(DFD)是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件,它只是描绘数据在软件中流动和被处理的逻辑过程。数据流图是系统逻辑功能的图形表示,即使不是专业的计算机技术人员也容易理解它,因此是分析员与用户之间极好的通信工具。此外,设计数据流图时只需考虑系统必须完成的基本逻辑功能,完全不需要考虑怎样具体地实现这些功能,所以它也是今后进行软件设计的很好的出发点。2.4.1符号数据流图有四种基本符号:正方形(或立方体)表示数据的源点或终点;圆角矩形(或圆形)代表变换数据的处理;开口矩形(或两条平行横线)代表数据存储;箭头表示数据流,即特定数据的流动方向。处理并不一定是一个程序。一个处理框可以代表一系列程序、单个程序或者程序的一个模块;它甚至可以代表用穿孔机穿孔或目视检查数据正确性等人工处理过程。一个数据存储也并不等同于一个文件,它可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等;数据可以存储在磁盘、磁带、磁鼓、主存、微缩胶片、穿孔卡片及其他任何介质上(包括人脑)。2.4.1符号数据存储和数据流都是数据,仅仅所处的状态不同。数据存储是处于静止状态的数据,数据流是处于运动中的数据。通常在数据流图中忽略出错处理,也不包括诸如打开或关闭文件之类的内务处理。数据流图的基本要点是描绘“做什么”而不考虑“怎样做”。2.4.1符号除了上述4种基本符号之外,有时也使用几种附加符号。下图给出了这些附加符号的含义。2.4.1符号2.4.2例子假设一家工厂的采购部每天需要一张定货报表,报表按零件编号排序,表中列出所有需要再次定货的零件。对于每个需要再次定货的零件应该列出下述数据:零件编号,零件名称,定货数量,目前价格,主要供应者,次要供应者。零件入库或出库称为事务,通过放在仓库中的CRT终端把事务报告给定货系统。当某种零件的库存数量少于库存量临界值时就应该再次定货。数据流图有4种成分:源点或终点,处理,数据存储和数据流。第一步,可以从问题描述中提取数据流图的4种成分:首先考虑数据的源点和终点,从上面对系统的描述可以知道“采购部每天需要一张定货报表”,“通过放在仓库中的CRT终端把事务报告给定货系统”,所以采购员是数据终点,而仓库管理员是数据源点。接下来,考虑处理,再一次阅读问题描述,“采购部需要报表”,显然他们还没有这种报表,因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量,然而任何改变数据的操作都是处理,因此对事务进行的加工是另一个处理。(注意,在问题描述中并没有明显地提到需要对事务进行处理,但是通过分析可以看出这种需要。)2.4.2例子——分析(基本系统模型)最后,考虑数据流和数据存储:系统把定货报表送给采购部,因此
本文标题:第2章-可行性分析
链接地址:https://www.777doc.com/doc-4939569 .html