第二章-可行性研究

第二章-可行性研究

  • 掌握可行性研究的任务、内容及具体步骤。
  • 掌握成本估计方法(功能点FP方法、代码行技术估算法、任务分解技术、COCOMO估算模型、Putnam估算模型)。
  • 掌握效益分析方法中投资回收率、回收期、纯收入等基本概念。

1、可行性研究的任务

可行性研究的目的不是解决问题,而是确定问题是否值得去解决。

可行性研究的实质:一次大大压缩简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

  • 首先需要进一步分析和澄清问题定义。
  • 分析员应该导出系统的逻辑模型。并从系统逻辑模型出发,探索若干种可供选择的主要解法(即系统实现方案)。

对每种解法都应该仔细研究它的可行性。在分析供选择的解法是否可行时,要从三方面考虑:技术、操作、经济。

2、可行性研究内容

  • 技术可行性
  • 操作可行性
  • 经济可行性 ← 低成本、中成本、高成本系统

3、可行性研究过程

  1. 复查系统规模和目标。
  2. 研究目前正在使用的系统。
  3. 导出新系统的高层逻辑模型。
  4. 进一步定义问题。 ← 把数据流图和数据字典作为讨论的基础。
  5. 导出和评价供选择的解法。
  6. 推荐行动方针。 ← 成本/效益分析
  7. 草拟开发计划。 ← 工程进度表 + 对各类开发人员和资源的需要情况
  8. 书写文档提交审查。

4、系统流程图

系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程,因此尽管系统流程图的某些符号和程序流程图的符号形式相同,但是它却是物理数据流图而不是程序流图。

分层:
首先用一张高层次的系统流程图描绘系统总体概貌,表明系统的关键功能。
然后分别把每个关键功能扩展到适当的详细程度,画在单独的一页纸上。

第二章-可行性研究_第1张图片

5、数据流图

数据流图(DFD)是一种图形化技术,它描绘信息流数据从输入移动到输出的过程中所经受的变换。

在DFD中没有任何具体的物理部件,它只是描绘数据在软件中流动和被处理的逻辑过程

第二章-可行性研究_第2张图片

6、数据字典

数据字典是关于数据的信息的集合,也就是对数据流图中包含的所有元素的定义的集合。

数据字典的内容:

  • 数据流
  • 数据流分量(即数据元素)
  • 数据存储
  • 处理

定义数据的方法: 对数据自顶向下的分解,一般说来,当分解到不需要进一步定义,每个和工程有关的人也都清楚其含义的元素时,这种分解过程就完成了。

数据字典的用途:

  • 作为分析阶段的工具(最重要)。
  • 在数据字典中建立的一组严密一致的定义很有助于改进分析员和用户之间的通信,因此将消除许多可能的误解。
  • 对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。

7、成本估计

软件开发成本主要表现为人力消耗(乘以平均工资则得到开发费用)

(1)代码行技术

  • 代码行技术把开发每个软件功能的成本和实现这个功能所需要用的源代码行数联系起来。
  • 通常根据经验和历史数据估计实现一个功能需要的源程序行数。
  • 估计出源代码行数以后,用每行代码的平均成本乘以行数就可以确定软件的成本。
  • 每行代码的平均成本主要取决于软件的复杂程度和工资水平。

(2)任务分解技术

  • 首先把软件开发工程分解为若干个相对独立的任务。
  • 再分别估计出每个单独的开发任务的成本,最后累加起来得出软件开发工程的总成本。
  • 估计每个任务的成本时,通常先估计完成该项任务需要用的人力(以人月为单位),再乘以每人每月的平均工资而得出每个任务的成本。

(3)自动估计成本技术

  • 采用自动估计成本技术的软件工具可以减轻人的劳动,并且使得估计的结果更客观。
  • 采用这种技术必须有长期搜集的大量历史数据为基础,并且需要有良好的数据库系统支持。

(4)功能点FP方法

  • 功能点估算法常用在项目开始或项目需求基本明确时使用,这时进行估算其结果的准确性比较高。假如这个时候使用LOC代码行估算法,则误差会比较大。
  • 使用功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法则与软件开发技术密切相关。
  • 功能点估算法是以用户为角度进行估算,LOC代码行估算法则是以技术为角度进行估算。
  • 通过一些行业标准或企业自身度量的分析,功能点估算法是可以转换为LOC代码行的。

在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延,计算出来的结果会与当初估计的不同。因此,在项目结束时还需要对项目的范围情况重新进行估算,这个时候估算的结果才能最准确反映项目的规模。

(5)COCOMO估算模型

  • 是一种精确的,易于使用的,基于模型的静态成本估算模型。
  • constructive cost model(构造性成本模型)
  • 从本质上说是一种参数化的项目估算方法,参数建模是把项目的某些特征作为参数,通过建立一个数字模型预测项目成本(类似于居住面积作为参数计算的整体的住房成本)。

COCOMO用3个不同层次的模型来反映不同程度的复杂性,他们分别为

  • 基本模型 (Basic Model). 是一个静态单变量模型,它用一个以已估算出来的源代码行数 (LOC) 为自变量的函数来计算软件开发工作量。
  • 中间模型 (Intermediate Model). 则在用 LOC 为自变量的函数计算软件开发工作量的基础上,再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
  • 详细模型 (Detailed Model) 包括中间 COCOMO 模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中分析、设计等各步骤的影响。

同时根据不同应用软件的不同应用领域,COCOMO模型划分为如下3种软件应用开发模式:

  • 组织模式(Organic Mode).这种应用开发模式的主要特点是在一个熟悉稳定的环境种进行项目开发,盖项目与最近开发的其他项目有很多相似点,项目相对较小,而且并不需要许多创新.
  • 嵌入式应用开发模式 (Embedded Mode).在这种应用开发模式种,项目受到接口要求的限制.接口对整个应用的开发要求非常搞,而且要求项目有很大的创新,例如开发一种全新的游戏.
  • 中间应用开发模式 (Semidetached Mode).这时介于组织模式和嵌入式应用开发模式之间的类型.

COCOMO 模型具有估算精确、易于使用的特点。在该模型中使用的基本量有以下几个:
(1)DSI( 源指令条数 ) ,定义为代码行数,包括除注释行以外的全部代码。若一行有两个语句,则算做一条指令。
(2)MM( 度量单位为人月 ) 表示开发工作量。
(3)TDEV( 度量单位为月 ) 表示开发进度,由工作量决定。
(4)COCOMO 模型重点考虑 15 种影响软件工作量的因素,并通过定义乘法因子,从而准确、合理地估算软件的工作量。

但是COCOMO也存在一些很严重的缺陷,例如分析时的输入时优先的,不能处理意外的环境变换,得到的数据往往不能直接使用,需要校准,只能得到过去的情况总结,对于将来的情况无法进行校准等。

(6)Putnam估算模型

  • 是一种动态多变量的模型,假设在软件开发的整个生存周期中工作量有特定的分布。
  • 根据一些大型软件项目的工作量分布情况,推导出软件项目在软件生存周期各阶段的工作量分布。

根据该曲线给出代码行数、工作量和开发时间之间的关系:
在这里插入图片描述

  • L表示源程序代码行数(LOC);
  • td表示开发持续时间(年);
  • E是包括软件开发和维护在整个生存期所花费的工作量(人年);
  • Ck表示技术状态常数,其值依赖于开发环境。
    在这里插入图片描述

8、成本效益分析

效益分析的目的:
从经济角度分析开发一个特定的新系统是否划算,从而帮助正确地做出是否投资于这项开发工程的决定。

经济效益通常表现为减少运行费用或增加收入。

成本/效益分析的第一步是估计开发成本运行费用新系统将带来的经济效益

  • 运行费用取决于系统的操作费用(操作员人数、工作时间和消耗的物资等等)和维护费用。
  • 系统的经济效益 = 因使用新系统而增加的收入 + 使用新系统可以节省的运行费用。

货币的时间价值
通常用利率的形式表示货币的时间价值。

投资回收期
使累计的经济效益等于最初投资所需要的时间。

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

投资回收率
衡量投资效益的大小,并且可以把它和年利率相比较。

附录

数据流图和数据字典共同构成系统的逻辑模型

系统流程图例子
第二章-可行性研究_第3张图片

数据流图例子
第二章-可行性研究_第4张图片
第二章-可行性研究_第5张图片
第二章-可行性研究_第6张图片

你可能感兴趣的:(软件工程,恰饭,经验分享,面试)