软件开发建模软件为什么要使用软件开发模型

一、有助于按照现实或者实际情况进行直观的描述。

二、能够规定软件或者模型的结构，行为，属性。

三、能够指导软件构造的模板。

四、对决策进行文档化

当然建模并不只适用于大的系统，甚至像非常小的一个应用，我们都可以建模，在建模中受益，然而越大的软件，功能越杂，业务越不清晰，从而阻挠软件开发者的思路和效率。在这种情况下，我们使用建模的重要性就越大，一个很简单的原因是：因为不能理解一个很复杂而庞大的软件工程，所以要对他建模。

而且人们对复杂的事物或者问题的理解是有局限的，人们总是习惯去理解简单易懂的东西。所以通过建模可以缩小研究范围，只着重研究其很小的一部分功能，这就要求了一个复杂的软件系统“分而治之”，从而通过建模简单化。从而你会发现其实很复杂的系统软件或者工程总是变得很简单，解决了这小部分的简单问题，就形成了复杂而庞大的软件或者工程。

建模能帮助开发组更好地进行系统规划，并帮助他们进行架构软件，使用开发效率提高。如果不建模，项目越复杂，就越会失败或者出现错误的东西。

在软件建模与设计中，软件开发的方法有几种

1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

　　（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

　在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。

建模用什么软件好

不是什么软件，而是什么方法。

材质展开方面maya比max体贴，但是max也可以用deeppaint3d这样的外挂。关键是建模。

常用的建模方法包括surface,polygen,metaball,nurbs都可以做出漂亮的有机生物体。

surface只要你能在空间中构造出准确的物体外形就可以迅速得到生物体。这种方法类似于扎灯笼，你扎出骨架，软件为你蒙上纸。但是结构线绘制准确并不容易，后期添加细节也比较困难。现在比较少用。这种方法max,maya都有

polygen好处在于可以随意的控制多边形的多边形数量，加速角色的绘制，渲染过程。所以被广泛应用于对多边形数量限制苛刻的情况，比如——游戏。lightwave,max在多边形方面比较强，maya一般。

metaball这是变形球技术，新兴的建模方式。高效，自然，就像用橡皮泥。但是容易形成数目巨大的多边形数量。只适合于真正的CG艺术家......

nurbs可以建立绝对平滑的外表。而且贴图定位十分完美。所以被广泛应用于工业建模。由于业界顶级渲染器renderman支持对nurbs的动态划分(根据距离远近决定多边形细分数量。离镜头越近细节越多)所以电影中也广泛使用这种技术。三维扫描仪也可以通过对黏土雕塑的扫描得到这种格式的模型。maya十分擅长这方面的建模而犀牛是一个专门针对nurbs的建模软件。max在这方面做得比较差。

选择你用得顺手的就好。比如魔兽片头动画使用了maya，而变形金刚片头使用了max。

软件开发为什么要使用UML建模

一、有助于按照现实或者实际情况进行直观的描述。

二、能够规定软件或者模型的结构，行为，属性。

三、能够指导软件构造的模板。

四、对决策进行文档化

建模能帮助开发组更好地进行系统规划，并帮助他们进行架构软件，使用开发效率提高。如果不建模，项目越复杂，就越会失败或者出现错误的东西。

从事软件开发的软件公司用的模型有什么区别

最早出现的软件开发模型最早出现的软件开发模型是1970年W•Royce提出的瀑布模型。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。但计算拓广到统计分析、商业事务等领域时，大多数程序采用高级语言(如FORTRAN、COBOL等)编写。瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。常见的软件开发模型还有演化模型、螺旋模型、喷泉模型、智能模型等。编辑本段典型的开发模型典型的开发模型有：

1.边做边改模型（Build-and-Fix Model）；

2.瀑布模型（Waterfall Model）；

3.快速原型模型（Rapid Prototype Model）；

4.增量模型(演化模型)（Incremental Model）；

5.螺旋模型（Spiral Model）；

6.喷泉模型(fountain model)；

7.智能模型(四代技术（4GL）)；

8.混合模型（hybrid model）；

9.RUP模型；

10.IPD模型

1. 边做边改模型（Build-and-Fix Model）

遗憾的是，许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：　　

（1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2）忽略需求环节，给软件开发带来很大的风险；

（3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2. 瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型中，如图所示，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；

（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子。

3. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

4. 增量模型（Incremental Model）

又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。

增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：　　

（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。　　

例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。

5.螺旋模型（Spiral Model）

1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：　　

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；　　

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；　　

（3）实施工程：实施软件开发和验证；　　

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。　　

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：　　

（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。　　

（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。　　

（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

6.喷泉模型（fountain model）(也称面向对象的生存期模型, OO模型)

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

7.智能模型(四代技术（4GL）)

智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。　　

这种方法需要四代语言（4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如Foxpro等）都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。

8.混合模型（hybrid model）

过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。各种模型的比较每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点。

9.RUP模型

RUP（Rational Unified Process）模型是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。RUP具有两个轴，一个轴是时间轴，这是动态的。另一个轴是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。

它具有如下特点：

（1）增量迭代，每次迭代都遵循瀑布模型能够在前期控制好和解决风险；

（2）模型的复杂化，需要项目管理者具有较强的管理能力。

10.IPD模型

IPD（Integrated Product Development）流程是由IBM提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。

IPD从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。

在IPD流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点。

IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。

软件开发过程中为什么要建模

UML建模分为需求建模和设计建模，需求建模的目的是确定系统边界并明确系统需要实现的功能。而设计建模主要目的是用于开发团队中的设计思想交流；以及后续程序设计的依据；后续测试和验收程序的依据。

UML的特点是可视化的图形建模，表达能力强；支持面向对象开发；对各个开发阶段统一设计规范和标准；易学易用。

游戏开发商一般用什么软件建模

说到3D，就必须先说说游戏引擎，因为二者是密不可分！我们可以把游戏的引擎比作赛车的引擎，大家知道，引擎是赛车的心脏，决定着赛车的性能和稳定性，赛车的速度、操纵感这些直接与车手相关的指标都是建立在引擎的基础上的。游戏也是如此。

软件建模

可行性研究报告

可行性研究报告的编写目的是：说明该软件开发项目的实现在技术、经济和社会

条件方面的可行性；评述为了合理地达到开发目标而可能选择的各种方案；说明并论

证所选定的方案。

可行性研究报告的编写内容要求如下：

1 引言

1．1编写目的

说明编写本可行性研究报告的目的，指出预期的读者。

1．2背景

说明：

a．所建议开发的软件系统的名称；

b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；

C．该软件系统同其他系统或其他机构的基本的相互来往关系。

1．3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1．4参考资料

列出用得着的参考资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文；

b．属于本项目的其他已发表的文件；

C．本文件中各处引用的文件、资料，包括所需用到的软件开发标准。|

列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些

文件资料的来源。

2 可行性研究的前提

说明对所建议的开发项目进行可行性研究的前提，如要求、目标、假定、限制等。

2．1要求

说明对所建议开发的软件的基本要求，如：

a．功能；

b．性能；

C．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接

口以及分发对象；

d．输入说明系统的输入，包括数据的来源、类型、数量、数据的组织以及提供的

频度；

e．处理流程和数据流程用图表的方式表示出最基本的数据流程和处理流程，并辅

之以叙述；

f．在安全与保密方面的要求；

g．同本系统相连接的其他系统；

h．完成期限。

2．2目标

说明所建议系统的主要开发目标，如：

a．人力与设备费用的减少；

b．处理速度的提高；

C．控制精度或生产能力的提高；

d．管理信息服务的改进；

e．自动决策系统的改进；

f．人员利用率的改进。

2．3条件、假定和限制

说明对这项开发中给出的条件、假定和所受到的限制，如：

a．所建议系统的运行寿命的最小值；

b．进行系统方案选择比较的时间；

c．经费、投资方面的来源和限制；

d．法律和政策方面的限制；

e．硬件、软件、运行环境和开发环境方面的条件和限制；

f．可利用的信息和资源；

g．系统投入使用的最晚时间。

2．4进行可行性研究的方法

说明这项可行性研究将是如何进行的，所建议的系统将是如何评价的。摘要说明所

使用的基本方法和策略，如调查、加权、确定模型、建立基准点或仿真等。

2．5评价尺度

说明对系统进行评价时所使用的主要尺度，如费用的多少、各项功能的优先次序、

开发时间的长短及使用中的难易程度。

3 对现有系统的分析

这里的现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是

一个机械系统甚至是一个人工系统。

分析现有系统的目的是为了进一步阐明建议中的开发新系统或修改现有系统的必要

性。

3．1处理流程和数据流程

说明现有系统的基本的处理流程和数据流程。此流程可用图表即流程图的形式表

示，并加以叙述。

3．2工作负荷

列出现有系统所承担的工作及工作量。

3．3费用开支

列出由于运行现有系统所引起的费用开支，如人力、设备、空间、支持性服务、

材料等项开支以及开支总额。

3．4人员

列出为了现有系统的运行和维护所需要的人员的专业技术类别和数量。

3．5设备

列出现有系统所使用的各种设备。

3．6局限性

列出本系统的主要的局限性，例如处理时间赶不上需要，响应不及时，数据存储

能力不足，处理功能不够等。并且要说明，为什么对现有系统的改进性维护已经不能

解决问题。

Top

3 楼tj_dns（愉快的登山者）回复于 2004-02-02 15:56:13 得分 0 4 所建议的系统

本章将用来说明所建议系统的目标和要求将如何被满足。

4．1对所建议系统的说明

概括地说明所建议系统，并说明在第A．2章中列出的那些要求将如何得到满足，

说明所使用的基本方法及理论根据。

4．2处理流程和数据流程

给出所建议系统的处理流程和数据流程。

4．3改进之处

按2．2条中列出的目标，逐项说明所建议系统相对于现存系统具有的改进。

4．4影响

说明在建立所建议系统时，预期将带来的影响，包括：

4．4．1对设备的影响

说明新提出的设备要求及对现存系统中尚可使用的设备须作出的修改。

4．4．2对软件的影响

说明为了使现存的应用软件和支持软件能够同所建议系统相适应。而需要对这些

软件所进行的修改和补充。

4．4．3对用户单位机构的影响

说明为了建立和运行所建议系统，对用户单位机构、人员的数量和技术水平等方

面的全部要求。

4．4．4对系统运行过程的影响

说明所建议系统对运行过程的影响，如：

a．用户的操作规程；

b．运行中心的操作规程；

C．运行中心与用户之间的关系；

d．源数据的处理；

e．数据进入系统的过程；

f．对数据保存的要求，对数据存储、恢复的处理；

g．输出报告的处理过程、存储媒体和调度方法；

h．系统失效的后果及恢复的处理办法。

4．4．5对开发的影响

说明对开发的影响，如：

a．为了支持所建议系统的开发，用户需进行的工作；

b．为了建立一个数据库所要求的数据资源；

C．为了开发和测验所建议系统而需要的计算机资源；

d．所涉及的保密与安全问题。

4．4．6对地点和设施的影响

说明对建筑物改造的要求及对环境设施的要求。

4．4．7对经费开支的影响

扼要说明为了所建议系统的开发，设计和维持运行而需要的各项经费开支。

4．5局限性

说明所建议系统尚存在的局限性以．及这些问题未能消除的原因。

4．6技术条件方面的可行性

本节应说明技术条件方面的可行性，如：

a．在当前的限制条件下，该系统的功能目标能否达到；

b．利用现有的技术，该系统的功能能否实现；

C．对开发人员的数量和质量的要求并说明这些要求能否满足；

d．在规定的期限内，本系统的开发能否完成。

5 可选择的其他系统方案

扼要说明曾考虑过的每一种可选择的系统方案，包括需开发的和可从国内国外直

接购买的，如果没有供选择的系统方案可考虑，则说明这一点。

5．1可选择的系统方案1

参照第4章的提纲，说明可选择的系统方案1，并说明它未被选中的理由。

5．2可选择的系统方案2

按类似5．1条的方式说明第2个乃至第。个可选择的系统方案。

．．．．．．

6 投资及效益分析

6．1支出

对于所选择的方案，说明所需的费用。如果已有一个现存系统，则包括该系统继

续运行期间所需的费用。

6．1．1基本建设投资

包括采购、开发和安装下列各项所需的费用，如：

a．房屋和设施；

b．A DP设备；

C．数据通讯设备；

d．环境保护设备；

e．安全与保密设备；

f．ADP操作系统的和应用的软件；

g．数据库管理软件。

6．1．2其他一次性支出

包括下列各项所需的费用，如：

a．研究（需求的研究和设计的研究）；

b．开发计划与测量基准的研究；

C．数据库的建立；

d．ADP软件的转换；

e．检查费用和技术管理性费用；

f．培训费、旅差费以及开发安装人员所需要的一次性支出；

g．人员的退休及调动费用等。

6．1．3非一次性支出

列出在该系统生命期内按月或按季或按年支出的用于运行和维护的费用，包括：

a．设备的租金和维护费用；

b软件的租金和维护费用；

C．数据通讯方面的租金和维护费用；

d．人员的工资、奖金；

e．房屋、空间的使用开支；

f．公用设施方面的开支；

g．保密安全方面的开支；

h．其他经常性的支出等。

6．2收益

对于所选择的方案，说明能够带来的收益，这里所说的收益，表现为开支费用的

减少或避免、差错的减少、灵活性的增加、动作速度的提高和管理计划方面的改进

等，包括；

6．2．1一次性收益

说明能够用人民币数目表示的一次性收益，可按数据处理、用户、管理和支持等

项分类叙述，如：

a．开支的缩减包括改进了的系统的运行所引起的开支缩减，如资源要求的减少，

运行效率的改进，数据进入、存贮和恢复技术的改进，系统性能的可监控，软件的转

换和优化，数据压缩技术的采用，处理的集中化／分布化等；

b．价值的增升包括由于一个应用系统的使用价值的增升所引起的收益，如资源

利用的改进，管理和运行效率的改进以及出错率的减少等；

C．其他如从多余设备出售回收的收入等。

6．2．2非一次性收益

说明在整个系统生命期内由于运行所建议系统而导致的按月的、按年的能用人民

币数目表示的收益，包括开支的减少和避免。

6．2．3不可定量的收益

逐项列出无法直接用人民币表示的收益，如服务的改进，由操作失误引起的风险

的减少，信息掌握情况的改进，组织机构给外界形象的改善等。有些不可捉摸的收益

只能大概估计或进行极值估计（按最好和最差情况估计）。

6．3收益／投资比

求出整个系统生命期的收益／投资比值。

6．4投资回收周期

求出收益的累计数开始超过支出的累计数的时间。

6．5敏感性分析

所谓敏感性分析是指一些关键性因素如系统生命期长度、系统的工作负荷量、工

作负荷的类型与这些不同类型之间的合理搭配、处理速度要求、设备和软件的配置等

变化时，对开支和收益的影响最灵敏的范围的估计。在敏感性分析的基础上做出的选

择当然会比单一选择的结果要好一些。

7 社会因素方面的可行性

本章用来说明对社会因素方面的可行性分析的结果，包括：

7．1法律方面的可行性

法律方面的可行性问题很多，如合同责任、侵犯专利权、侵犯版权等方面的陷井，

软件人员通常是不熟悉的，有可能陷入，务必要注意研究。

7．2使用方面的可行性

例如从用户单位的行政管理、工作制度等方面来看，是否能够使用该软件系统；

从用户单位的工作人员的素质来看，是否能满足使用该软件系统的要求等等，都是要

考虑的。

8 结论

在进行可行性研究报告的编制时，必须有一个研究的结论。结论可以是：

a．可以立即开始进行；

b．需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行；

c．需要对开发目标进行某些修改之后才能开始进行；

d．不能进行或不必进行（例如因技术不成熟、经济上不合算等）

转载请注明出处51数据库 » 软件开发建模软件为什么要使用软件开发模型