《基于任务驱动模式的软件工程与UML建模技术》课件项目二

项目二问题定义及可行性研究任务一问题定义

任务二可行性研究

任务一问题定义

操作一问题定义概述

软件开发的第一个阶段是对软件项目进行问题定义，该阶段要回答的关键问题是：“软件要解决的问题是什么?”

如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最常被忽视的一个步骤。这里所说的问题，就是指用户的基本要求。说得通俗些，问题定义实际上就是了解用户到底要建立什么系统，并确定分析员下一步应该做什么。因此，问题定义的来源是用户。通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。这一阶段的分析员应尽可能站在较高的角度去抽象、概括所要干的事情，不要拘泥于问题实现的细节。尽管用户可能总是习惯于探究问题的细节，但分析员在这一阶段必须超脱出来，居高临下鸟瞰系统的全貌。通过对系统的实际用户和使用部门负责人的访问调查，分析员应该扼要地写出对问题的理解，并在使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不清的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。当用户的要求不是很多并且不太复杂时，一两个分析员用上一两天就可以完成这一工作。但当系统比较大且复杂时，则可能需要组织一个问题定义小组，花上一两个星期，甚至数月来定义用户的问题。

如果分析员和用户及使用部门的负责人对所要解决的问题取得了完全一致的看法，而且使用部门的负责人同意开发工程继续进行下去，那么开发工程将转入生命周期的下一个阶段——可行性研究。

操作二教务管理信息系统概述

以下通过希望中学教务管理信息系统概况(见表2-1)分析案例，将具体阐述教务管理信息系统要解决的问题是什么。系统分析员将与用户就教务管理信息系统要解决的问题在理解上达成一致。此过程中，应该形成初步的系统方案，包括项目组织机构概况、项目开发背景、项目开发意义、初步的软件计划等内容。

表2-1希望中学教务管理信息系统概况

任务二可 行 性 研 究

操作一可行性研究概述

在问题定义阶段，分析员和用户将确定待开发软件所能够解决的问题。然而，在现实中，这些问题并不一定可以在预定的系统规模之内解决。如果问题受到当前条件的约束，没有可行的解，那么花费在这个项目上的时间、资源、人力和经费都将被浪费。因此，从软件项目的多个角度全面地分析问题是否有可行的解，对软件项目进行可行性研究是非常必要的。

1.可行性研究的任务

可行性研究的目的不是解决待开发软件系统的问题，而是要确定这些问题在现有的条件下是否值得去解决。同时，应该用最小的代价确定在问题定义阶段所制定的系统的目标和规模是否符合实际，所确定的问题是否有可行的解决方案，论证系统方案在经济、技术和操作等方面是否可行。可行性研究主要论证以下三个方面的内容：

(1)经济可行性。估算项目的开发费用以及新系统可能为用户组织带来的收益，将两者进行权衡，看结果是否可以接受。

(2)技术可行性。分析项目要求的功能、性能以及限制条件，以现有的技术是否能够实现预期的软件系统。所考虑的因素通常还应包括开发的风险、所需的软硬件资源、有力的开发团队等。

(3)操作可行性。判断系统的操作方式在该用户组织内是否有可行性。

除以上三种可行性，必要时还应从法律、社会效益等方面进一步研究分析。可行性研究的过程为：首先分析设计人员进一步分析和澄清问题定义，确定系统目标、约束和限制条件，并一一列举出来；其次分析员使用系统分析方法和工具导出系统的逻辑模型；然后根据逻辑模型，提供一种以上的系统实现方案，对每种方案都应该从技术可行性、经济可行性、操作可行性等方面进行研究比较；最后，分析人员必须明确给出可行性研究的结果。如果问题没有可行的解，分析员应该建议停止开发项目，以避免时间、资源、人力和经费的浪费；如果问题值得解决，分析员应该推荐一个最佳的解决方案，并且为项目制订一个初步的计划。

注意：可行性研究需要的时间长短取决于工程的规模。一般来说，可行性研究的成本只是预期的工程总成本的5%～10%。

2.可行性研究的步骤

典型的可行性研究过程的具体步骤如下：

1)复查系统规模和目标

分析员对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。

2)研究目前正在使用的系统

如果目前有系统在运行，则必须对现有的系统进行分析，不但要阅读现有系统的文档资料和使用手册，也要实地考察，找出其缺陷，使新系统能解决旧系统中存在的问题。

常见的错误做法是花费过多时间去分析现有的系统。

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

从现有的物理系统出发，根据现有系统的逻辑模型，导出新系统的逻辑模型，最后构造出新的物理系统。为了把新系统描绘得更加清晰准确，分析员通常利用数据流图和数据字典等工具，对系统中的数据进行描述和定义。

4)进一步定义问题

新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。

5)导出和评价供选择的解法

分析员应该从其建议的系统逻辑模型出发，导出若干个较高层次的(较抽象的)物理解法供比较和选择。

首先考虑技术方面的可行性。分析员应该根据技术可行性的考虑初步排除一些不现实的系统。把技术上行不通的解法去掉之后，就剩下了一组技术上可行的方案。

其次考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。

再次考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且与现有的系统进行比较。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要(也不可能)制定得很详细，通常只需要估计生命周期每个阶段的工作量。

6)推荐行动方针

根据可行性研究结果，分析员应该做出是否进行这项工程的开发决定。如可行，分析员还应该选择一种最好的解法，并且说明选择这个解决方案的理由，对于所推荐的系统进行比较仔细的成本/效益分析。

7)草拟开发计划

分析员应为所推荐的方案草拟一份开发计划，除了制定工程进度表之外，还应该估计对各类开发人员和各种资源的需要情况，此外还应该估计系统生命周期每个阶段的成本。

8)书写文档提交审查

分析员应该把可行性研究结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。

操作二系统流程图

系统流程图(SystemFlowchart)是描绘软件系统物理模型的图形工具。系统分析员绘制该图的过程有助于全面了解系统业务处理的概况，同时，也有助于系统分析员与用户更好地相互交流。

系统流程图的基本思想是用图形符号描绘组成系统的每个部件(程序、文档、数据库、人工过程等)，它所表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但它们是完全不同的。

1.系统流程图的符号

系统流程图被用来描述系统的工作流程，以系统中的物理组件为单元说明系统的基本构造，并由此说明系统对数据的加工步骤。表2-2所列是系统流程图中常用的图形符号。显然，系统流程图中的符号是一些可以从系统中分离出来的物理元素，例如，设备、程序模块、报表等。表2-2系统流程图的常用符号

2.实例

图2-1所示系统流程图表明了该学校系统内外之间、内部各部门之间、人员之间的业务关系以及作业顺序、管理信息流动的流程。

以下是对该系统流程图的文字说明：

该校实行的是校长负责制。校长根据教育局的教学要求，并且结合本校实际情况和特色，制定出该学校的年度总计划及需实现的教学目标等，由秘书编写成相应的文件经校长批阅后，传达给各部门执行。教导处根据校长的年度总计划及教学目标进行各个年级的课程设置和安排(包括课程安排、采用哪些教材、课时安排等)，形成本校教学计划，经校长审批通过后，将教学安排通知总务处及各个年级组。各个年级组根据教学安排来安排和组织教研工作，安排每个任课教师的教学工作，由各年级组编写教学工作计划，经校长审批通过后，形成教学工作实施计划，并在此基础上，进行课程安排，然后，将确定好的课程表发放给各个任课教师及学生。

另外，学校每年新招的学生在收到入学通知后，应按照规定时间到校报到、注册，并应认真填写相应的学生登记表，交到教导处，同时将学生人数统计后交付到总务处。图2-1希望中学教务管理信息系统流程图教导处根据学生登记的学生登记表建立学生学籍库(该档案可以包括学生姓名、性别、家庭地址、备注等)。该档案可以根据实际要求，随时进行查询、增加、删除、修改、更新等，这样就能持续跟踪每个学生的实际情况。

教师根据教导处的工作安排展开任教工作，对每个学生的学习情况及在校表现进行跟踪，并如实地、及时地向教导处及学生家长汇报。每次考试或测验后，由各科任课教师批阅学生考卷，汇总并分析学生分数，交于教导处，

教导处根据各科任课教师的教学情况，并结合该教师各方面的综合素质进行年度考核评定，经过校长审批合格后，送至校办。然后，校办根据审核意见，并考虑该教师的学历、职称等各方面因素，重新评估并确定该名教师的聘用情况。

操作三成本效益分析

经济可行性研究是对项目实施成本和所能带来的经济效益的分析，以确定等待实施的项目是否值得投资。

1．成本估算

在项目初期，无论是进行可行性分析，还是制定项目预算，或是向客户提供软件报价，都需要针对软件项目进行成本的初步估算。下面将要介绍的是一些常用的软件项目成本估算方法。

1)基于软件规模的成本估算

传统的软件规模是通过代码行数计算的，也就是说，通过估算软件代码总行数，可以计算出创建软件的总工作量和软件总成本。基于软件代码行数的人力成本估算公式是：

计算公式中的WC是软件工作成本，TCL是软件总代码行数，MPACL是以参加项目所有人员为基数计算的每月人均完成的代码行数，MPAP是以参加项目所有人员为基数计算的每月人均工资。其中，参加项目所有人员既包括技术人员，也包括管理人员。

在对软件代码行数进行估算时，往往需要先将软件按功能进行分解。例如，可以将软件系统按照功能分解为许多子系统，子系统又可以继续分解为许多功能模块，这种对软件系统的分解工作可以一直进行到基本模块。应该说，基本模块的代码行数是比较容易估算的，而通过对基本模块代码行数进行估算与累计，可以估算出整个系统的总代码行数。

2)基于任务分解的成本估算

这是一种以项目任务的人力消耗为依据的成本估算方法。可以把项目任务分解成诸多活动，例如，按照工程过程将项目任务分解成需求分析、概要设计、详细设计等若干个阶段，然后根据每个阶段的人员配备、周期长短和阶段任务参加人员平均工资情况，而估算出每个阶段的人力成本，由此累计出项目总成本。示例如表2-3所示。表2-3开发“企业资源综合管理系统”时的人力成本情况

2．效益分析

无论是开发机构或是用户，都会关心项目效益，但值得注意的是，开发机构的效益直接来源于软件产品，而用户的效益则来自于对软件的应用，并且不同的软件产品会有不同的效益来源。例如，软件机构自主开发的通用软件和用户委托开发的定制软件，它们在效益来源上就分别有各自不同的途径。通用软件由软件机构自主开发，然后投放到软件市场上销售。开发机构的最低期望可能是，软件在销售中所获取的直接经济利益至少能超过软件的开发成本，以保证收回投资。对于通用软件，开发机构大都需要在开发软件之前进行深入的市场分析，看软件市场是否已有了同类型的产品，假如已有同类型产品，则要看开发的产品在功能、性能、价格等方面是否具有市场优势等。而对于由用户委托开发的软件项目，开发机构的效益则取决于用户对项目的资金投入与软件实际成本的差额值，其计算看起来是简单的。但是，这些项目由于完全由用户进行巨额投资，其效益也就必然受到用户的特别关注，所以计算起来非常复杂。用户的期望可能是，花费巨额资金开发出来的软件在其使用过程中能够提高工作效率、改善工作质量、节约工作成本、拓宽业务领域等，由此带来的间接经济效益至少能够超过软件的开发成本。

在计算项目的经济效益时，还不得不注意到，软件的经济效益是在软件投入使用之后的若干年里逐渐产生出来的，而资金投入则是当前之事。为了更加合理地计算资金效益，未来效益中产生的资金需要折算为现值进行计算。资金折现公式是：

其中，k是银行利率；n是年份。

可以使用一些经济指标来衡量项目的经济效益，其主要经济指标有：

(1)纯收入：指软件在估算的正常使用期内产生的资金收益被折算为现值之后，再减去项目的成本投入。

(2)投资回收期：指软件