系统分析师【系统规划案例分析汇总】

系统规划

项目选择和确定

（1）选择有核心价值的项目

（2）评估所选择的项目

（3）项目优先级排序

（4）评估项目的多种实施方式

（5）平衡地选择合适的方案

可行性研究步骤

（1）复查系统目标和规模

（2）分析现有系统

（3）导出新系统的高层逻辑模型

（4）用户复核

（5）提出并评价解决方案

（6）确定最终推荐的解决方案

（7）草拟开发计划

（8）编制和提交可行性研究报告

可行性研究报告的内容

引言、引用文件、可行性研究的前提、可选的方案、所建议的系统、经济技术法律用户使用可行性、其他与项目有关的问题、注解、附录。

可行性包括两个方面：必要性和可能性

软件系统的可行性分析包括四个方面

（1）经济可行性>收益、成本

（2）技术可行性>企业现有技术能力能否完成

（3）法律可行性>是否符合国家法律法规

（4）用户使用可行性>管理可行性、运行可行性

        经济可行性也称为投资收益分析或成本效益分析,主要评估项目的建设成本、运行成本和项目建成后可能的经济收益。

        技术可行性也称为技术风险分析,研究的对象是信息系统需要实现的功能和性能,以及技术能力约束。

        法律可行性也称为社会可行性,具有比较广泛的内容,它需要从政策、法律、道德、制度等社会因素来论证信息系统建设的现实性。

        用户使用可行性也称为执行可行性,是从信息系统用户的角度来评估系统的可行性,包括企业的行政管理和工作制度、使用人员的素质和培训要求等,可以细分为管理可行性和运行可行性。

系统规划步骤，各个子步骤具体含义

1、对现有系统进行初步调查

2、分析和确定系统目标

3、分析子系统的组成和基本功能

4、拟定系统的实施方案

5、进行系统的可行性研究，编写可行性研究报告，召开可行性论证会

6、制定系统建设方案

项目机会选择步骤

1、立项目标和动机

2、立项价值判断

3、项目选择和确定

4、初步调查

5、可行性分析

项目立项的目标和动机

1、进行基础研究

2、进行应用研究

3、提供技术服务

4、产品的使用者

项目的选择和确定

(1)选择有核心价值的项目

(2)评估所选择的项目

(3)项目优先级排序

(4)评估项目的多种实施方式

(5)平衡地选择合适的方案

初步调查

目标:掌握用户的概况,从整体上了解企业信息系统建设的现状,对用户提出的各种问题和初始需求进行识别,明确系统的初步目标,为可行性研究提供工作基础。

方式:最佳方式是与企业高层管理人员座谈,通过座谈了解企业高层对信息系统所设定的目标和系统边界,计划的资金投入和对工期的要求。

内容:初步需求分析,企业基本状况,管理方式和基础数据管理状况,现有系统状况。

成本效益分析技术

（1）固定成本：是指其总额在一定期间和一定业务量范围内，不受业务量变动的影响而保持固定不变的成本。例如，管理人员的工资、办公费、固定资产折旧费、员工培训费等。

（2）变动成本：也称为可变成本，是指在一定时期和一定业务量范围内其总额随着业务量的变动而成正比例变动的成本。例如，直接材料费、产品包装费、外包费用、开发奖金等。

（3）混合成本：就是混合了固定成本和变动成本的性质的成本。例如，水电费、电话费等。这些成本通常有一个基数，超过这个基数就会随业务量的增大而增大。

（4）直接成本：直接投入在项目上。

（5）间接成本：分摊到项目上。

（6）沉没成本：已经投入到项目中，无法挽回的成本，不需要再去考虑。

净现值计算

静态收益计算方式：不考虑金钱的时间价值,只看项目周期内投入和产出的绝对数字。

动态收益计算方式：考虑金钱具有时间价值,现在的钱比未来值钱,有以下相关概念和公式：

现值:设每年折现率为i,原价值为F的东西,在n年后的价值为：

净现值NPV是考虑了金钱的时间价值计算出来的净利润,公式为：

其中,CI是第t年的收入利益,CO是第t年的支出成本,i是折现率。项目周期内每一年都这样计算再累加,得出总的NPV,就是考虑了时间价值的净利润, NPV有助于公司判断项目是否盈利。

净现值率NPVR是项目净现值与原始投资总额的比率,公式为下图所示，分子是NPV,分母是原始投资总额，NPVR有助于公司选择投入小,产出高的项目。

静态投资回收期：不用折现值。

---

系统分析和需求工程

需求获取的方法，特点，优点，缺点

(1)用户访谈:1对1-3,有代表性的用户。其形式包括结构化和非结构化两种。

(2)问卷调查:用户多,无法--访谈。

(3)采样:从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)^2。

(4)情节串联板:一系列图片,通过这些图片来讲故事。

(5)联合需求计划(JRP) :通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。 

(6)需求记录技术:任务卡片、场景说明、用户故事、Volere白卡。

联合需求计划是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程,它是联合应用开发的一部分。JRP是一种相对来说成本较高的需求获取方法,但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起,通过有组织的会议来讨论需求。JRP将会起到群策群力的效果,对于一些问题最有歧义的时候、对需求最不清晰的领域都是十分有用的一种方法。 优势: 1、发挥用户和管理人员参与系统开发过程的积极性,提高系统开发效率; 2、降低系统需求获取的时间成本,加速系统开发周期; 3、采用原型确认系统需求并获取设计审批,具有原型化开发方法的优点。

抽样份数 = 0.25 * （可信因子/(1-可信度百分比)）^2

需求分析的任务

（1）绘制系统上下文范围关系图

（2）创建用户界面原型

（3）分析需求的可行性

（4）确定需求的优先级

（5）为需求建立模型

（6）创建数据字典

（7）使用QFD（质量功能部署）

需求分析方法-PDOA方法

面向问题域的分析,更多的强调描述,而少强调建模,包括:

(1)关注问题域。用一个文档对含有的问题域进行相关的描述,并列出需要在该域中求解的问题列表,也就是需求列表。只有这个文档是在分析时产生的。

(2)关注解系统(即系统实现)的待求行为。用一个文档对了解系统的待求行为进行描述。该文档将在需求定义阶段完成。

在PDOA方法中,对整个过程有着一个清晰的定义：(1)收集基本的信息并开发问题框架,以建立问题域的类型。(2)在问题框架类型的指导下,进一步收集详细信息,并给出一个问题域相关特性的描述。 (3)基于以上两点,收集并用文档说明新系统的需求。

从上面的描述中可以看出,问题框架是PDOA的核心元素,是将问题域分为一系列相互关联的子域,而一个子域可以是那些可能算是精选出来的问题域的一部分。

结构化需求分析

结构化特点：自顶向下，逐步分解，面向数据

三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典

数据字典：数据字典是在DFD（）的基础上，对DFD中出现的所有命名元素都加以定义，使得每个图形元素的名字都有一个确切的解释。DFD和数据字典等工具相配合，就可以从图形和文字两个方面对系统的逻辑模型进行完整的描述。

数据字典中一般有6类条目，分别是数据元素、数据结构、数据流、数据存储、逻辑加工和外部实体。不同类型的条目有不同的属性需要描述。

面向对象的分析方法

UML关系：依赖、关联、泛化、实现、组合、聚合

UML图：尤其以用例图、类图、活动图、状态图最为重要

面向对象分析模型

用例模型>【识别参与者、合并需求获得用例、细化用例描述（用例名称、简要说明、事件流、非功能需求、前置条件、后置条件、扩展点、优先级）、调整用例模型（包含关系、扩展 关系、泛化关系）】

分析模型 >【定义概念类、识别类之间的关系（依赖关系、关联关系、聚合关系、组合关系、泛化关系、实现关系）、为类添加职责、建立交互图】

需求分析方法的对比

SA【结构化分析】方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到问题可解决 的自然思考方式。SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。

OOA【面向对象】方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法首先对问题域的事物“外在表象”进行观测，然后再逻辑世界中模拟出一个对象的逻辑对象。“断定”该对象和现实事物是一致的。随后，观测到 的对象被记录入对象集合，观测到的行为和表象被记录入对象关系模型和对象行为模型。

PDOA【面向问题域的分析，更多的强调描述，而少强调建模】的特点是重新将重点定位在问题域和需求上，通过对问题域的分类，向系统分析师提供具体问题的相关指南，并且它将规格说明作为另外的任务处理，他的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了SA和OOA方法。

需求定义方法

（1）严格定义也成为了预先定，需求的严格定义建立在一下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰的交流。采用图形（或者文字）可以充分体现最终系统。

（2）原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确的说明。项目干系人之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。特点：需要实际的、可供用户参与的系统模型，有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

需求规格说明书（内容、作用）

内容：范围；引用文件；需求；合格性规定；需求可追踪性；尚未解决的问题；注解；附录。

通俗答法：系统应该提供的功能和服务；非功能需求，包括系统的特征，特点和属性；限制系统开发或者系统运行必须遵守的约束条件；系统必须连接的其他系统的信息。

作用：系统所有者和用户使用需求定义文档来确认需求以及任何可能产生的变化，并作为验收的依据；系统分析人员、设计人员和构造人员使用它来理解需要什么以及处理需求变更，开发用于验证系统的测试用例；项目经理使用它来制定项目计划、处理变更以及验收的依据。

需求管理：需求基线、需求变更、需求跟踪

软件产品线

软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。软件产品线是一个十分适合专业的开发组织的软件开发方法，能有效地提高软件生产率和质量，缩短开发时间，降低总开发成本。

核心资源：包括所有产品所公用的软件架构，通用的构件、文档等。

产品集合：产品线中的各种产品。

产品线的建立方式

	演化方式	革命方式
基于现有产品	基于现有产品 机构设计产品线的架构，经过演化现有 构件，开发产品线构件	核心资源的开发基于现有产品集的需求和可预测的、将来需求的超集
全新产品线	产品线核心资源随产品新成员的需求而演化	开发满足所有预期产品线成员的需求核心资源

        软件复用是将已有软件的各种有关知识用于建立新的软件，以缩短软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

逆向工程

        软件的你向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。逆向工程的四个级别：

实现级：包括程序的抽象语法树、符号表、过程的设计标识。

结构级：包括反应程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。

功能级：包括反应程序段功能及程序 段之间关系的信息，例如数据和控制流模型。

领域级：包括反应程序分量或者程序诸实体与应用领域概念之间的对应关系的信息，例如E-R模型。

其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。

与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。

（1）重构是指在同一抽象级别上转换系统描述形式。

（2）设计恢复时指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。

（3）再工程是指在逆向工程所获得信息的基础上，修改或者重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。他不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进他的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。

（4）正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变和重构现有系统，以改善其整体质量。