2.可行性研究

2.1问题定义

1.问题定义的内容

  • (1)问题的背景,弄清楚待开发系统现在处于什么状态,为什么要开发它,是否具备开发条件等问题。
  • (2)提出开发系统的问题要求以及总体要求。
  • (3)明确问题的性质、类型和范围。
  • (4)明确待开发系统要实现的目标、功能和规模。
  • (5)提出开发的条件要求和环境要求。

2.问题定义的方法

  • 首先,系统分析员要针对用户的要求做详细的调查研究,认真听取用户对问题的介绍;阅读与问题有关的资料,必要时还要深入现场,亲自操作;调查开发系统的背景;了解用户对开发的要求。
  • 其次,是与用户反复讨论,以使问题进一步确定化。经过用户和系统分析员双方充分协商,确定问题定义的内容。
  • 最后,写出双方均认可的问题定义报告。

2.2可行性研究的目的和任务

1.目的

  • 明确问题是否能够解决
  • 明确问题是否值得去解决

2.实质

  • 可行性研究的实质是在高层次上做一次大大简化了的需求分析和设计。是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

可行性研究应着重考虑的五个方面:

  • (1)技术可行性

    • 主要包括:在给出的限制范围内,能否设计出系统,并实现必要的功能和性能;开发人员、硬件和软件是否存在问题;系统所用到的相关技术是否支持。
  • (2)经济可行性

    • 经济可行性问题包含两方面:一方面是经济实力;另一方面是经济效益。分析经济可行性研究的内容是要进行开发成本的估算,了解项目成功取得效益的评估,确定要开发的项目是否值得投资开发。
  • (3)运行可行性

    • 如果新系统建立在原来已担负其他任务的原系统上,就不能要求它在实时在线状态下运行,以免与原有的任务相矛盾。
  • (4)操作可行性

    • ① 软件能否被有效的使用;
    • ②开发过程中能否得到用户方的必要支持;
    • ③软件使用所带来的影响用户方能否接受。
  • (5)法律可行性

可行性研究最根本的任务是对以后的行动方向提出建议。如果可行性研究的结果是问题没有可行的解,那么系统分析员应该建议停止这项工程的开发;如果可行性研究的结果是问题值得去解决,那么系统分析员应该推荐一个较好的解决方案,并且为工程制定一个初步的开发计划。

2.3可行性研究过程

1.可行性研究工作流程

2. 可行性研究的方法和步骤

  • (1)复查系统规模和目标

    • 分析员访问关键人员,仔细阅读和分析有关的材料,对项目的规模和目标进行定义和确认,描述项目的一切限制和约束,以确保分析员提交的报告书确实是用户要求解决的。
  • (2)研究目前正在使用的系统

    • 现有系统的基本功能是新系统所必须具备的;
    • 现有系统存在的缺点,新系统必须加以改进;
    • 现有系统所不具备的功能,又是用户必须的,则新系统一定要预以增加;
    • 现有系统所需要的费用是新系统的一个重要的投资依据。如果新系统不能增加收入或减少使用费用,那么从经济角度看新系统就不如旧系统。
  • (3)导出新系统的高层逻辑模型

    • 从现有的物理系统出发,导出现有物理系统的逻辑模型;

    • 再以现有物理系统的逻辑模型为基础,设计出新系统的高层逻辑模型;

    • 最后根据高层逻辑模型建造新的物理系统。

    • 3类模型

      • 概念模型

        • 概念模型就是在了解了用户的需求,用户的业务领域工作情况以后,经过分析和总结,提炼出来的用以描述用户业务需求的一些概念的东西。如销售业务中的“客户”和“定单”,还有就是“商品”,“业务员”。一个用例描述就是:“业务员”与“客户”就购买“商品”之事签定下“定单”。
      • 逻辑模型

        • 逻辑模型就是要将概念模型具体化。要实现概念模型所描述的东西,需要哪些具体的功能和处理哪些具体的信息。这就到了需求分析的细化阶段。仍以销售业务为例:“客户”信息基本上要包括:单位名称,联系人,联系电话,地址等属性;“商品”信息基本上要包括:名称,类型,规 格,单价等属性;“定单”信息基本上要包括:日期和时间属性。并且“定单”要与“客户”,“业务员”和“商品”明细关联。  
      • 物理模型

        • 物理模型就是针对上述逻辑模型所说的内容,在具体的物理介质上实现出来。如:数据库使用SQL Server 2000,这样就可以编写具体的SQL脚本在数据库服务器上将数据库建立起来。其中包括业务员信息表,客户信息表,商品信息表,定单表。客户端使用VS开发工具,那么在工作站上用VS建立起功能菜单,包括:业务员信息维护,客户信息维护,商品信息维护,建立销售定单等功能,并用工具将每一个功能编码实现。
  • (4)进一步定义问题

    • 定义系统目标 —> 复查系统目标和规模 —> 研究现有系统 —> 设计新系统 —> 再定义系统目标。
  • (5)导出和评价供选择的方案

    • 从技术角度排除那些不现实的方案;
    • 从操作角度去掉那些操作方式或操作过程是用户不能接受的方案;
    • 从经济角度估算每个可能系统的成本/效益。
  • (6)推荐方案和行动方针

    • 本项目的开发价值;
    • 推荐这个方案的理由;
    • 制订实现项目的进度表。
  • (7)决策

    • 使用部门的负责人根据经济实力及分析员在可行性研究阶段对开发此项工程成本/效益分析情况的分析结论,决定是否继续这项开发工程。
  • (8)草拟开发计划

    • 工程的进度;
    • 人才资源(系统分析员、程序员)的需求及使用;
    • 设备资源的需求及使用(软、硬件工具)、估算生存周期每个阶段的成本;
    • 给出下一阶段(需求分析)的详细进度表和成本估计。
  • (9)书写文档提交审查

2.4系统流程图

1基本内容

  • (1)用图形符号以黑盒子形式描述系统内的每一个成分(例如:程序、文件、数据库、表格、硬件设备、人工过程等)。
  • (2)用“→”表示信息在系统各个成分之间的流动情况,不要误认为“ ”表示信息的加工和控制过程。因此尽管系统流程图的某些符号和程序流程图的符号形式相同,但是它却是物理数据流图而不是程序流程图。

2符号

3例子(见书本)

4分层

  • 面对复杂的系统时,一个比较好的方法是分层次地描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌,表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度,画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。

2.5数据流图

1.基本内容

  • 数据流图(DFD)是描述数据处理过程的工具。它从数据传递和加工的角度,以图形的方式描述数据流从输入到输出的传输变换过程。

    • 一种图形化技术,一种描述“分解”的图示工具
    • 表示信息和数据从输入到输出所经受的变换
    • 描述数据在系统中流动和被处理的逻辑过程
    • 没有任何具体的物理部件

2.符号

  • (1)“→”表示数据和数据流。箭头表示数据的流动方向。数据流图中应在线旁标注数据流名。
  • (2)“○”表示对数据的加工,即对数据的某种操作或变换。数据流图中应在圆圈内写上加工名。
  • (3)“ ”表示按照某种规则生成,且长度不限的数据文件(也称数据存储)。数据流图中应在双线旁标注文件名。
  • (4)“□”表示数据流的源头和终端。

3.例子(见书本)

4.命名

  • 数据流(或数据存储)

    • (1)名字应代表整个数据流(或数据存储)的内容,而不是仅仅反映它的某些成分。
    • (2) 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。
    • (3) 如果在为某个数据流(或数据存储)起名字时遇到了困难,则很可能是因为对数据流图分解不恰当造成的,应该试试重新分解,看是否能克服这个困难。
    • (4)两个加工之间可以有多个数据流,这些数据流之间没有任何联系。在加工之间传输的数据流必须有一个合适的名词,而在文件和加工之间传输的数据流可以不命名,因为可以从“加工”和“文件”的名字,弄清数据流的含义
  • 处理

    • (1) 通常先为数据流命名,然后再为与之相关联的处理命名。
    • (2) 名字应该反映整个处理的功能,而不是它的一部分功能。 不要使用含糊不具体的动词,如“处理”、“加工”等。
    • (3) 名字最好由一个具体的及物动词加上一个具体的宾语组成。
    • (4) 通常名字中仅包括一个动词,如果必须用两个动词才能描述整个处理的功能,则把这个处理再分解成两个处理可能更恰当些。
    • (5) 如果在为某个处理命名时遇到困难,则很可能是发现了分解不当的迹象,应考虑重新分解。
  • 数据源头和终点

    • 数据源头和终点是数据的始发点和终止点,是表示系统和环境的接口。在实际问题中,它可以是人员、计算机外部设备或其他装置,不需要对它进行软件设计和实现。因此,在命名时应符合环境的真实状况.

5.优点

  • DFD用一种直接而又直观的方法来描述数据的流动和信息系统中的操作。首先,它使用客观图像描述了用户的需求,不带有任何个人或组织的说法或观点。其次,数据流图形象真实,便于用户理解和接受,同时也便于系统分析员之间交流信息。最后,数据流图采用自顶向下分解的多层次图形具有一定的抽象性,而且数据流图不强调控制流,突出数据流,便于找到主要矛盾,省略次要细节,从而减少系统的复杂性。

6.缺点

  • DFD图形符号也存在着一定的缺点。首先,数据流图对时间、界面等方面的内容无法表达。其次,DFD只能做出粗略的模型,而如果需要更精确、更详细的说明时,DFD无法做到。

7.用途

  • 1、作为信息交流的工具分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来,供有关人员审查确认。
  • 2、作为分析和设计的工具
  • 3、数据流图可以辅助物理系统的设计(图)根据不同要求,能够在数据流图上画出许多组自动化边界,每组自动化边界可能意味着一个不同的物理系统,因此可以根据系统的逻辑模型考虑系统的物理实现。
  • 4、数据流图对详细设计也有帮助。

2.6数据字典

1.定义

  • 数据字典是关于数据信息的集合。数据字典定义数据流图中所有元素(包括数据流、数据流的组成、文件及其它应进入数据字典的一切数据)。

2.与数据流图的联系

  • 数据字典中所有名字的定义就够成了一本字典与数据流图共同构成系统的逻辑模型

3. 数据字典的内容

分别对DFD中元素的定义:

  • 数据流

  • 数据流分量(即数据元素)

    • 名字、别名、描述、数据类型、长度、结构、值的范围、使用方式、控制信息、分组信息等
  • 数据存储

  • 处理 (结合IPO图或PDL )

4.定义数据的方法

  • 组成数据的方式

    • 1)顺序 —— 以确定次序连接两个或多个分量
    • 2)选择 —— 从两个或多个可能的元素中选取一个
    • 3)重复 —— 把指定的分量重复零次或多次
    • 4)可选 —— 一个分量是可有可无的

5. 用途

  • 作为分析阶段的工具
  • 能单独处理描述每个数据元素的信息
  • 是开发数据库的第一步(基础 关键)

6.数据字典的实现

2.7成本/效益分析

1.成本估计:

  • (1)代码行技术(LOC技术)

    • 1)确定功能:把项目功能反复分解到足够细,直到可以对为实现该功能所需要的源代码行数作出可靠的估算为止。
    • 2)算出各子功能代码行数的平均值:首先根据经验和历史数据对每个子功能估计其程序规模的大小,即最小规模a,最大规模b和最可能的规模m,然后用下式计算该子功能的源代码行数的平均值Le:
    • 3) 确定各子功能的代码行成本和生产率:
    • 4) 计算各子功能的成本和人力(工作量)
    • 5)计算该项目的总代码行数、总成本和总工作量。
  • (2)任务分解技术

    • 工程分解为若干个相对独立的任务 - 按阶段划分 - 按子系统划分
    • 分别估计每个单独的开发任务的成本 - 每个任务的成本 = 耗费人力(人月)*人月平均工资
    • 累加得到工程的总成本
  • (3)自动估计成本技术

    • 采用自动估计成本的软件工具
    • 长期搜集的大量历史数据为基础
    • 有良好的数据库系统支持

2.成本/效益分析方法

  • 基本内容

    • 估计开发成本、运行费用和新系统将带来的经济效益
    • 运行费用取决于系统的操作费用(人员数、工作时间、损耗等)和维护费用
    • 系统的经济效益等于因使用新系统而增加的收入加上使用新系统可以节省的运行费用。
    • 总的效益和估计的软件寿命有关。
  • 四个重要的概念:

    • 货币的时间价值

      • 比较新系统的开发成本(当前)和经济效益(未来)
      • 用利率的形式表示货币的时间价值。
    • 纯收入

      • 在整个生命周期之内系统的累计经济效益(折合成现在值)与投资之差。
    • 投资回收期

      • 用来衡量一项开发工程的价值
      • 是使累计的经济效益等于最初投资所需要的时间
      • 投资回收期越短就能越快获得利润,也就越值得投资。
      • 是一项经济指标
    • 投资回收率

      • 衡量投资效益的大小
      • 通常和年利率相比较,衡量经济效益

2.8可行性研究报告

  • 1)引言:说明可行性研究的目的,项目的名称、背景,本文档用到的术语和参考资料。

  • 2)可行性研究的前提:说明待开发项目的功能、性能和基本要求,要达到的目标,各种约束条件,可行性研究的方法和决定可行性的主要因素。

  • 3)对现行系统的分析:如果有现行系统,说明现行系统的处理流程和数据流程,系统状态,费用支出,所需专业人员的种类和数量,所需设备,存在的问题等。

  • 4)方案选择:所选择方案的系统配置,选择方案的标准。

  • 5)技术可行性分析:对所选择的较好的方案的风险分析、资源分析和技术分析;对子系统的技术分析。

  • 6)经济可行性分析:说明所建议系统的成本-效益分析结果。

  • 7)运行、操作可行性分析。

  • 8)法律可行性分析。

  • 9)其他可供选择方案:分别说明每一个可供选择的方 案,并应说明未被推荐的理由。

  • 10)结论意见:说明项目是否能开发,还需要什么条件才能开发以及对项目目标有何变动等。