搜索
2019年8月30日11时52分王少华武汉大学国际软件学院空间信息与数字工程研究中心huazimail@126.com2006年9月28日6时52分结构化分析设计过程阶段关键问题结束标准问题定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高层逻辑模型数据流图成本/效益分析需求分析系统必须做什么？系统的逻辑模型数据流图数据字典算法描述2006年9月28日6时52分结构分析设计过程阶段关键问题结束标准总体设计概括地说，应该如何解决这个问题？可能的解法：系统流程图成本/效益分析推荐的系统结构；层次图或结构图详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码和单元测试正确的程序模块源程序清单；单元测试方案和结果综合测试符合要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录2006年9月28日6时52分本质上是功能分解，以实现功能的过程为中心，而用户的需求变化主要是针对功能的。这就使基于过程的设计不易被理解；且功能变化往往引起结构变化较大，稳定性不好。系统有明确的边界定义，且系统结构依赖于系统边界的定义，这样的系统不易扩充和修改。数据与操作分开处理，可能造成软构件对具体应用环境的依赖，可重用性(reusability)较差.结构化技术的缺点2006年9月28日6时52分管理的范围有效的项目管理集中于三个P上：人员(people)、问题(problem)和过程(process)。其顺序不是任意的。任何管理者如果忘记了软件工程是人的智力密集的劳动，他就永远不可能在项目管理上得到成功；任何管理者如果在项目开发早期没有支持有效的用户通信，他有可能为错误的问题建造一个不错的解决方案。最后，对过程不在意的管理者可能冒把有效的技术方法和工具插入到真空中的风险。2006年9月28日6时52分一、工程立项建议1、立项原因2、立项基础3、国内外研究现状4、工程意义与目标5、用户调查6、投资条件7、投资周期8、技术力量与基础9、软件硬件价格与性能10、数据源状况11、应用前景12、效益评估13、可运行性评价2006年9月28日6时52分问题定义问题定义阶段必须回答的关键问题是：“要解决的问题是什么？”问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。问题定义阶段是生命周期中最简短的阶段，一般只需要一天甚至更少的时间。2006年9月28日6时52分二、可行性研究这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有可行的解决办法或值得做吗？可行性研究比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。做还是不做？联想集团领导人柳传志曾说：“没钱赚的事我们不干；有钱赚但投不起钱的事不干；有钱赚也投得起钱但没有可靠的人选，这样的事也不干。”柳传志为决策立了上述准则，同时也为可以行性分析指明了重点。2006年9月28日6时52分2.1可行性研究的任务可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决，可行性研究的目的不是解决问题，而是确定问题是否值得去解，以及关键技术、难点、能否解决。必须分析几种主要的可能解法的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程度。一般说来，可行性研究的成本只是预期的工程总成本的5%-10%。软件领域的可行性分析主要考虑四个要素：经济、技术、社会环境和人。项目的意义（社会的意义）技术可行性经济可行性操作可行性2006年9月28日6时52分3.1.1可行性研究的任务继续项目可行性分析的四个任务经济可行性经济实力经济效益社会可行性是否存在侵犯、妨碍行为技术可行性技术资源有效性开发风险操作可行性项目的运行方式在用户组织内是否行的通现有管理制度、人员素质和操作方式是否可行2006年9月28日6时52分2.2可行性研究的步骤1系统定义，复查系统规模和目标、性质、范围、约束和限制2研究目前正在使用的系统。研究现行系统（人工/旧软件)，描绘系统流程图，审核。现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。3.导出新系统的逻辑模型。分析员应该画出描绘现有系统的高层系统流程图，并请有关人员检验他对现有系统认识是否正确。千万不要花费太多时间去了解和描绘现有系统的实现细节，例如，除非是为了阐明一个特别关键的算法，否则不需要根据程序代码画出程序流程图。2006年9月28日6时52分2.3导出新系统的高层逻辑模型4.设计方案.优秀的设计过程通常总是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统，并进行可行性评价（4方面）分析员能够使用数据流图描绘数据在系统中流动和处理的情况，从中概括地表达出他对新系统的设想。通常为了把新系统描绘得更清晰准确，还应该有一个初步的数据字典，定义系统中使用的数据。数据流图和数据字典共同定义了新系统的逻辑模型，以后可以从这个逻辑模型出发设计新系统。2006年9月28日6时52分2.4重新定义问题分析员应该和用户一起再次复查问题定义、工程规模和目标，这次复查应该把数据流图和数据字典作为讨论的基础。可行性研究的前四个步骤实质上构成一个循环。分析定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。2006年9月28日6时52分2.5导出和评价供选择的解法5.推荐可行的方案。分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的（较抽象的）物理解法供比较和选择。其次可以考虑操作方面的可行性。考虑经济方面的可行性，对每个可能的系统进行成本/效益分析。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，不需要（也不可能）制定得很详细，通常中需要估计生命周期每个阶段的工作量。2006年9月28日6时52分2.5.1经济可行性经济经济可行性分析主要包括：“成本——收益”分析和“短期——长远利益”分析。成本-收益分析最容易理解，如果成本高于收益则表明亏损了，如果成本大大高于收益那就亏大了。2006年9月28日6时52分2.6成本/效益分析直接效益服务节省开支提高工作效率间接效益科学决策快速决策社会效益2006年9月28日6时52分2.6.1成本考虑的方面（1）办公室房租。（2）办公用品，如桌、椅、书柜、照明电器、空调等。（3）计算机、打印机、网络等硬件设备。（4）电话、传真等通讯设备以及通讯费用。（5）资料费。（6）办公消耗，如水电费、打印复印费等。（7）软件开发人员与行政人员的工资。（8）购买系统软件的费用，如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件，却按市场价算成本，可从美国佬那里赚一笔。（9）做市场调查、可行性分析、需求分析的交际费用。（10）公司人员培训费用。（11）产品宣传费用。如果用Internet作宣传，则要考虑建设Web站点的费用。（12）如果客户是政府部门，还要充分考虑用于吃喝玩乐、行贿的费用。（13）如果公司的风水不好，会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。2006年9月28日6时52分2.6.2短期——长远利益分析人们喜欢吃着碗里的、看着锅里的，还想着别人家里的。短期利益和长远利益兼得是人们梦寐以求的事。开发策略2006年9月28日6时52分2.6.3成本估计-系统规模1、代码行技术--面向规模的估计（代码行KLOC）·每千行代码(KLOC)的错误数。·每千行代码(KLOC)的缺陷数。·每行代码(LOC)的成本。·每千行代码(KLOC)的文档页数。·每人月错误数。·每人月代码行(LOC)。·每页文档的成本。2、任务分解技术—面向功能的估计（功能点）用户输入数：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。用户输出数：计算每个用户输出，它们向用户提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。文件数：计算每个逻辑的主文件(如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件)。外部接口数：计算所有机器可读的接口(如磁带或磁盘上的数据文件)，利用这些接口可以将信息从一个系统传送到另一个系统。2006年9月28日6时52分2.6.3问题分解及过程分解首先把软件开发工程分解为若干个相对独立的任务，估计每个任务的成本时，通常先估计完成该任务需要用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。最常用的办法是按开发阶段划分任务。如果软件系统很复杂，由若干个子系统组成，则可以把每个子系统再按开发阶段进一步划分成更小的任务。典型环境下各个开发阶段需要使用的人力的百分比大致如表所示。2006年9月28日6时52分2006年9月28日6时52分软件规模的例子2006年9月28日6时52分3、自动估计成本技术采用这种技术必须有长期搜集的大量历史数据为基础，并且需要有良好的数据库支持。2006年9月28日6时52分参考书籍软件成本估算：COCOMOII模型方法出版社：机械工业出版社作者：[美]勃姆(Boehm,B.W)等/译者：李师贤/杜云梅/李卫华等/功能点分析—成功软件项目的测量实践作者：（美）DavidGarmus&DavidHerron/出版社：清华大学出版社2006年9月28日6时52分功能点分析法功能点分析法(FPA：functionpointanalysis)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。2006年9月28日6时52分功能点分析法的步骤2006年9月28日6时52分功能点分析法FP=总计数值×［0.65＋0.01×ΣFi］其中，“总计数值”是所有功能点条目的总和。Fi(i=1到14)是基于对图4-6中问题的回答而得到的“复杂度调整值”(0到5)。等式中的常数和信息域值的加权因子是根据经验确定的。Fi：1.系统需要可靠的备份和复原吗？2.需要数据通信吗？3.有分布处理功能吗？4.性能很关键吗？5.系统是否在一个已有的、很实用的操作环境中运行？6.系统需要联机数据项吗？7.联机数据项是否需要在多屏幕或多操作之间切换以完成输入？8.需要联机更新主文件吗？9.输入、输出、文件或查询很复杂吗？10.内部处理复杂吗？11.代码需要被设计成是可复用的吗？12.设计中需要包括转换及安装吗？13.系统的设计支持不同组织的多次安装吗？14.应用的设计方便用户修改和使用吗？2006年9月28日6时52分总计数值信息域值乐观值可能值悲观值估算数权值记数值输入数20243024496输出数12152216580查询数16222822488主控文件数44541040外部接口数2232714总计数值3182006年9月28日6时52分因子值因子值备份和还原4信息域值复杂度5数据通讯2内部处理复杂度5分布式处理0设计成可复用的代码4关键性能4设计中的转换及安装3先有的操作环境3多次安装5联机数据登录4方便修改的应用设计5多屏幕输入切换5复杂度调整因子1.17估算14个复杂度加权因子（Fi,根据问题对项目的影响取值范围是0～5），表3给出了因子值。FP=总计数值×[0.65+0.01×ΣFi]=3662006年9月28日6时52分工