软件平台设计技术方案.docx

上传人:lao****ou 文档编号:17813 上传时间:2022-10-08 格式:DOCX 页数:49 大小:1.31MB
下载 相关 举报
软件平台设计技术方案.docx_第1页
第1页 / 共49页
软件平台设计技术方案.docx_第2页
第2页 / 共49页
软件平台设计技术方案.docx_第3页
第3页 / 共49页
软件平台设计技术方案.docx_第4页
第4页 / 共49页
软件平台设计技术方案.docx_第5页
第5页 / 共49页
亲,该文档总共49页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《软件平台设计技术方案.docx》由会员分享,可在线阅读,更多相关《软件平台设计技术方案.docx(49页珍藏版)》请在第一文库网上搜索。

1、软件平台设计技术方案目录定义问题与归结模型1.1问题分析31.2问题定义62需求分析与软件设计81.1 需求分析的任务与过程81.2 如何进行系统设计111.3 软件设计的任务与活动123结构化分析与设计133. 1结构化分析133.1 结构化设计183.2 模块设计204面向对象的分析与设计224. 1面向对象的基本概念224. 2面向对象分析254.3统一建模语言275用户界面设计415. 1用户界面设计的原则415.2用户界面设计过程426工作流设计436. 1工作流设计概述436.2工作流管理系统457简单分布式计算机应用系统的设计468系统运行环境的集成与设计489系统过渡计划491

2、定义问题与归结模型软件系统的目的是为了解决问题,因此在建模之初最重要的步骤是对问题的分析与定义,并在此基础上归结模型,这样才能够获得切实有效的模型。定义问题的过程包括:理解真实世界中的问题和用户的需要,并提出满足这些需要的解决方案的过程。1.1 问题分析问题分析的目标就是在开发之前对要解决的问题有一个更透彻的理解。为了达到这一目标,通常需要经过在问题定义上达成共识,理解问题的本质,确定项目干系人和用户,定义系统的边界和确定系统实现的约束这五个步骤。1 .在问题定义上达成共识要检验大家是否在问题的定义上达成了共识,最简单的方法就是把问题写出来,看看是否能够获得大家的认可。而要使得这个过程更加有效

3、,应该将问题用标准化的格式写出来,根据UP的建议,应该包括以下几个方面的要素。问题概述:用简短的几句话,将所理解的问题本质描述出来;影响:说明该问题将会对哪些项目干系人(Stakeholder,风险承担者)产生影响;结果:确定问题对项目干系人和商业活动会产生什么样的影响;优点:概要性地提出解决方案,并列举出该解决方案的主要优点。在问题定义上达成共识,就能够有效地将开发团队的理解与用户的需求达成一致,这样就能够使得整个系统的开发沿着合理的方向发展。2 .理解问题的本质每一句描述都会夹杂着叙述者的个人理解和判断,因此透过表面深入本质,理解问题背后的问题,是问题分析阶段一个十分关键的任务。其中一种技

4、术是“根本原因”分析,这是一种提示问题或其表象的根本原因的系统化方法。在实际的应用中,常使用因果鱼骨图和帕累托图两种方法。(1)因果鱼骨图。因果鱼骨图是一种有效的探寻问题根源的技术,它通过直观的图形找出问题或现象的所有潜在原因,从而追踪出问题的根源。它能够帮助人们将问题的原因而放在首位,提供了一种运用集体智慧解决问题的方法。在使用时,通常按照以下步骤进行。将问题简明扼要地写在右边的方框里;确定问题潜在原因的主要类别,将它们连到鱼的脊骨上;8-1是鱼骨图的一个示例。图8-1鱼骨图示例用头脑风暴法寻找原因并归类。图(2)帕累托图。帕累托图是采用直方图的形式,根据问题的相对频率或大小从高往低降序排列

5、,帮助设计师将精力集中在重要的问题上。它为80%的问题找到关键的2096的原因,它可以一目了然地显示出各个问题的相对重要程度,有助于预防在解决了一些问题后,却使另外一些问题变得更糟的现象发生。在使用时,通常按照以下步骤进行。明确问题:也就是前面达成共识的问题定义;找出问题的各种可能原因:通常可以利用头脑风暴来收集意见,并通过参考以往积累的资料和运营的数据来综合分析;选择评价标准和考察期限:最常用的评价标准包括频率(占总原因的百分比)和费用(产生的影响),而考察的期限则应具有相应问题的代表性,并不是越长越好;收集各种原因发生的频率及费用数据;将原因按照发生的频率或费用从大到小排列起来;将原因排在

6、横轴上,频率或费用排列在纵轴上,形成如图8-2所示的结果。这样就能够将造成问题的关键原因捕获出来,以便指导设计出更符合需要、更能够解决问题的解决方案。4C图8-2帕累托图示例3 .确定项目干系人和用户要想有效地解决问题,必须了解用户和其他相关的项目干系人(任何将从新系统或应用的实现中受到实质性影响的人)的需要。不同的项目干系人通常对问题有不同的看法和不同的需要,这些在解决问题时必须加以考虑。事实上,许多项目干系人就是系统的用户,这一部分通常是易于识别的;但还有一部分项目干系人是系统的间接用户,甚至只是受系统影响的商业结果,这一部分不易识别,但十分重要。在寻找项目干系人时,可以思考:系统的用户是

7、谁?系统的客户(购买者)是谁?还有哪些人会受到系统输出的影响?系统完成并投入使用后,有谁会对它进行评估?还有没有其他系统内部或外部的客户,他们的需要有没有必要去考虑?系统将来由谁来维护?4 .定义系统的边界系统的边界是指解决方案系统和现实世界之间的边界。在系统边界中,信息以输入和输出的形式流入系统并由系统流向系统外的用户,所有和系统的交互都是通过系统和外界的接口进行的。在定义系统的边界时,将世界分为两个部分:系统及与系统进行交互的事物。要描述系统的边界有两种方法:一种是结构化分析中的“上下文范围图”,另一种则是面向对象分析中的“用例模型二(1)上下文范围图。也就是数据流图中的顶层图,它是一个反

8、映领域信息的模型,能够清晰地显示出系统的工作职责和相邻系统的职责起止之处,从而让读者能够从宏观的层面去了解系统。图8-3就是一个描述“证券经纪人系统”的上下文范围图。(2)用例模型。用例模型则通过引入参与者来描述“和系统进行交互的事物”,只要识别了参与者,自然而然系统的界限就确定下来了。在寻找参与者时,可以思考以下问题:谁会对系统提供信息?谁会在系统中使用信息?谁会从系统中删除信息?谁将操作系统?系统将会在哪里被使用?系统从哪里得到信息?哪些外部系统要和系统进行交互?然后,再根据每个参与者的功能需求,识别出代表系统功能的用例,从而界定系统的边界。而关于用例模型的更多细节,请参考4.3节。券商柜

9、台系统行情资讯数据库用户基本资料用户持仓信息股市行情信息资讯信息*接收短消息发送短消息I于机住纪人系统:个性化需求信息个性化资讯信息经纪人个性化资讯信息个性化得求信息用户图8-3上下文范围图示例5 .确定系统实现的约束由于各种因素的存在,会对解决方案的选择造成一定的限制,称这种限制为约束。每条约束都将影响到最后的解决方案的形成,甚至会影响是否能够提出解决方案。在考虑约束时,首先应该考察到不同的约束源,其中包括进度、投资收益、人员、设备预算、环境、操作系统、数据库、主机和客户机系统、技术问题、行政问题、已有软件、公司总体战略和程序、工具和语言的选择、人员及其他资源限制等。1.2 问题定义通过对问

10、题进行细致周密的分析,就可以对其进行综合的定义。对于一个问题的完整定义,通常应包括目标、功能需求和非功能需求三个方面。1 .目标目标是指构建系统的原因,它是最高层次的用户需求,是业务上的需要,而功能、性能需求则必须是以某种形式对该目标做出贡献。在描述目标时,应该注意以下几个方面。优势:目标应该不仅仅是解决问题,还要提供业务上的优势;度量:不仅要说明业务的优势,而且还必须提供度量这种优势的标准;合理性:要确保完成解决方案所需的工作量少于所获得的业务优势,这才是合理的解决方案;可行性:要探寻能够满足度量标准的解决方案;可达成性:对于组织而言,是否具备获取该系统的技能,构建完成后是否能够操作它。例如

11、,表8-1就是一个很好的目标描述的例子。表8-1目标描述的例子目标:在冬季道路养护支出上节省费用优势:减少除冰和道路养护的费用一标准:除冰费用将在目前道路处理费用的基础上降低25%.冰对道路造成的损伤将降低50%2 .功能需求功能需求是用来指明系统必须做的事情,只有这些行为的存在,才有系统存在的价值。功能需求应该源于业务需求,它只与问题域相关,与解决方案域无关。也就是说,功能需求是在与用户或某个业务人员交谈时,他们所描述的内容是为了完成他们某部分的工作而必须做的事情。而在设计解决方案时,会遇到一些限制条件,这些东西也是“系统需求”的一部分,不过应该是设计约束或非功能需求形式指定。在规定功能需求

12、时要注意其详细程度。由于这些需求是业务需求,因此应该由业务人员来验证。也就是说,用户应该能够指明系统要达到有用的程度,功能是否已经足够;考虑到工作的成果,它的功能是否正确。另外,在描述功能需求时,应该注意需求的二义性。而二义性主要体现在以下几个方面。(1)同名异义的词:在自然语言中存在许多同名但异义的词语,应该谨慎地排除它们带来的影响。(2)代词:在需求描述中,代词经常会产生指代不明的现象,应该尽量避免使用,而是换成主语及宾语。希赛教育专家提示:在检查功能需求的二义性时,一种有效的方法是大声地朗读出来,大家一起边听边进行讨论,这样可以不断地优化。3 .非功能需求非功能需求是系统必须具备的属性,

13、这些属性可以看作是一些使产品具有吸引力、易用、快速或可靠的特征或属性。非功能需求并不改变产品的功能,它是为工作赋予特征的。在识别功能需求和非功能需求时,有一种十分有用的思维模式:功能需求是以动词为特征的,而非功能性需求则是以副词为特征的。非功能需求主要包括以下几种。(1)观感需求:即产品外观的精神实质,也就是与用户界面的观感相关的一组属性;(2)易用性需求:也就是产品的易用性程度,以及特殊的可用性考虑,通常包括用户的接受率、因为引入该产品而提高的生产效率、错误率、特殊人群的可用性等指标;(3)性能需求:也就是关于功能实现要求有多快、多可靠、多少处理量及多精确的约束。例如:速度、精度、安全性、容

14、量、值范围、吞吐量、资源使用效率、可靠性(平均无故障时间)、可用性(不停机时间)、可扩展性等;(4)可操作性需求:衡量产品的操作环境,以及对该操作环境必须考虑的问题;(5)可维护性和可移植性需求:期望的改变,以及完成改变允许的时间;(6)安全性需求:产品的安全保密性,通常体现为保密性、完整性和可获得性;(7)文化和政策需求:由产品的开发者和使用者所带来的特别需求;(8)法律需求:哪些法律和标准适用于本产品。2需求分析与软件设计需求分析是软件生命周期中相当重要的一个阶段。根据StandishGroup对23000个项目进行的研究结果表明,28%的项目彻底失败,46%的项目超出经费预算或者超出工期

15、,只有约26%的项目获得成功。需求分析工作在整个软件开发生命周期中有着十分重要的意义。而在这些高达74%的不成功项目中,有约60%的失败是源于需求问题,也就是差不多有一半的项目都遇到了这个问题,这一可怕的现象引起人们对需求分析的高度重视。需求分析阶段的主要任务是通过开发人员与用户之间的广泛交流,不断澄清一些模糊的概念,最终形成一个完整的、清晰的、一致的需求说明。而当明确了用户的需求之后,下一步的任务就是对未来的软件系统进行设计,它是确定系统实现的关键工作。需求分析和设计的方法对软件开发过程而言是十分重要的,因此必须扎实地掌握它。需求分析与软件设计是软件生存期中最重要的两个步臊,需求分析解决的是“做什么”的问题,系统设计则是解决“怎么做”的问题。2.1需求分析的任务与过程需求分析所要做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 技术资料 > 技术总结

copyright@ 2008-2022 001doc.com网站版权所有   

经营许可证编号:宁ICP备2022001085号

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有,必要时第一文库网拥有上传用户文档的转载和下载权。第一文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第一文库网,我们立即给予删除!



客服