下载
加入VIP
  • 专属下载券
  • 上传内容扩展
  • 资料优先审核
  • 免费资料无限下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 软件架构设计的思想与模式

软件架构设计的思想与模式.pdf

软件架构设计的思想与模式

qujg
2009-03-04 0人阅读 举报 0 0 0 暂无简介

简介:本文档为《软件架构设计的思想与模式pdf》,可适用于IT/计算机领域

◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn软件架构设计的思想与模式中科院计算所培训中心谢新华第一章软件架构设计思想与体系创建在软件组织中架构师的作用是举足轻重的。本课程针对企业开发最关注的问题深入研讨抓住投入产出比这个企业的核心价值讨论架构设计如何使这个核心价值得以实现。我们认为一个设计如果必须高手云集才能生产出符合质量要求的产品并不一定是好的架构。架构设计的目标是力争使用总体上能力一般的队伍通过组织和设计的力量生产出符合质量要求的产品从投资回报的角度两者效果是完全不一样的。另一方面由于需求变更不可避免而需求的变更必然造成设计调整进而造成总体投入的增加这会极大的影响到投资回报所以我们必须研究架构设计如何更好的适应变更通过设计确保变更、维护与升级的成本下降。对这一系列问题的深入思考成为现代软件架构设计的核心思维。软件企业必须认真研究如何培养高水平的架构人员但仅仅把架构设计作为一个孤立的节点来讨论或者仅仅就架构谈架构的在一个很窄的思维空间中研究问题是没有意义的。任何设计都来自于目的我们应该把架构设计放在整个项目过程的大环境下来研究针对每个关键节点对设计的影响特点进行研讨这样才可能真正理解架构设计真正精髓的东西使未来的设计工作就会变得极有主动性和想象力。随着经济全球化进程的不断推进知识经济的时代已经到来。要增加软件产品的国际竞争力软件质量作为企业发展的战略问题变得越来越重要软件质量正被视为软件企业的生命。软件质量管理开始在软件组织内全面开展强烈的质量意识正慢慢扎根于软件技术和管理人员的心灵深处直至整个组织质量文化的形成所以如何设计高质量的软件产品也成为软件架构设计的重要主题。统计表明软件质量问题是由需求分析和架构设计两个环节造成的因此在需求分析的时候我们必须研究如何充分理解用户需求给各方面提供充分而有效的信息在架构设计上研究如何尽可能利用已有信息合理组织技术方案把人和任务作为一个重要因素进行考虑在达到质量需求的基础上使高的投资回报率成为可能在项目过程管理上如何与架构设计匹配协调使技术方案的高质量实现成为可能同时对于产品线架构和核心资产库构建的理论、方法、组织和技术给于足够的重视这都需要项目经理、分析师、架构师具有很高的水平。架构设计绝不是某个神秘人物冥思苦想然后又自鸣得意的产物架构设计应该是集体智慧的成果软件设计与开发也应该是集体共通劳动的结果重要的是各种相互矛盾的要求的合理平衡这都需要有非常良好的方法把团队的智慧集中起来如何充分激发集体的智慧也是一个架构设计师必须具备的能力。影响这个课程主体的主要思想是世纪是软件规模经济的时代下图表达了工具、构件和过程的三个基本技术的进步图中表达了在假定要求的质量和人员等级不变的情况下投资回报(ROI)的关系纵坐标表达了实现软件的单位成本(代码行、功能点)横坐标表达了软件规模这里表示了随着时代的进步同样规模的软件成本在大幅下降投资回报在大幅上升。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn伴随着非常大型的项目比如由系统组成的系统长生命力的产品以及多个相似项目的产品线软件组织将达到更好的经济规模。这种规模软件经济的理念对我的设计方法和思路提出了和过去完全不同的要求重用、复用和变更促成为重要的主题。架构设计应该从方法论的角度、从质量属性对架构设计影响的角度、从建立可度量的架构质量保证体系以及安全性和可扩展性的角度在理论和实践两方面全方位研究问题。软件架构师的角色和应掌握的知识体系一、软件架构的定义与问题软件架构(softwarearchiecture)是一组有关如下要素的重要决策:软件系统的组织构成系统的结构化元素接口和它们相互协作的行为的选择结构化元素和行为元素组合成粒度更大的子系统的方式的选择以及指导这一组织(元素及其接口、协作和组合方式)的架构风格的选择。软件架构是对系统整体结构设计的刻划包括全局组织与控制结构构件间通讯、同步和数据访问的协议设计元素间的功能分配物理分布设计元素集成伸缩性和性能设计选择等。但是所谓架构其实并不仅仅指的是软件产品体系结构设计它还包括管理架构、过程架构以及质量保证架构等一系列问题的研究因为高质量软件并不能只靠一个节点解决问题而是需要有一个全面的解决方案。重要的是要知道一个软件系统的质量很大程度上是由架构设计的质量决定的所以◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn研究架构设计的思想和方法成为软件设计领域中一个十分引人注目的问题。但是很长时间以来人们大都把目光关注在流程、方法、结构原理甚至编码的本身而不太注意架构设计最本质的东西思考的深度也欠深入结果很多产品即使设计出来后期运行中也是问题百出。这就给我们提出了一个问题架构设计的核心思维到底是什么?什么是好的架构设计呢?首先任何软件系统都是以满足需求作为目的所以好的架构设计必须以深入全面的需求分析作为基础事实上架构设计是没有统一的模式的任何模式只有针对问题才有意义。作为架构设计来说必须对需求分析有足够的理解这样才能有针对性地解决问题才可能设计出真正优秀的产品来。但是如果需求分析本身问题的信息就不足那怎么可能设计出解决问题到位的架构来呢?另一方面任何架构思想的实现都依赖于好的项目管理。项目管理必须与架构思想相匹配才能发挥作用。一个好的架构设计必须关注成本也必须关注时间以期在约定的时间内、不超过规定的成本、生产出符合质量要求的软件产品来。因此系统架构师应该仔细研究现代项目管理的思想和方法吃透其中的精髓根据自己的设计思想提出项目管理的解决方案。谈到项目管理人们往往想到的是某种规范某种文档模版甚至某种流程。当然这些是重要的不过无论多么美好的规范如果不能和自己的实际情况结合起来尤其是和自己的架构特点结合起来有的放矢的改进自己的过程从而达到降低成本提高质量的目的那什么样的规范都是没有意义的。作为一个架构师来说上述的讨论引发了三个核心思维一个是架构设计的源泉来自于需求分析第二个是架构设计重心和特点来自于质量需求(非功能性需求)第三个观点是架构的实现依赖于好的项目管理。因此软件架构设计是一个系统工程它需要系统构架师有很宽的知识面从需求分析、架构设计到类设计甚至代码实现一直到项目管理都需要有透彻的理解这之间的关系是你中有我我中有你是不可能截然分开的。必须说明软件系统设计的方法不是一个僵化的规则关键是在实践中实事求是的摸索规律从而找出符合实际达到要求的设计来。二、软件复用和系统架构现代软件架构设计的原则来自于软件复用软件复用是指重复使用“为了复用目的而设计的软件”的过程。在过去的开发实践中我们也可能会重复使用“并非为了复用目的而设计的软件”的过程或者在一个应用系统的不同版本间重复使用代码的过程这两类行为都不属于严格意义上的软件复用。通过软件复用在应用系统开发中可以充分地利用已有的开发成果消除了包括分析、设计、编码、测试等在内的许多重复劳动从而提高了软件开发的效率同时通过复用高质量的已有开发成果避免了重新开发可能引入的错误从而提高了软件的质量。良好的软件架构提供了构件组装的基础和上下文。一个典型的软件架构是由系统中的构件、连接和约束构成的配置格局。从这个观点看架构决不是概要设计架构设计本身就可以看成一个项目架构的结果应该是一个可执行、可验证的产品也必须通过评审为最终产品的复用与可持续发展打下框架上的基础。研究软件构架有利于发现不同系统的高层共性、保证灵活和正确的系统设计、对系统的整体结构和全局属性进行规范约束、分析、验证和管理。将构架作为系统构造和演化的基础可以实现大规模、系统化的软件复用。研究软件架构对于进行高效的软件工程具有非常重要的意义:◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcnz通过对软件架构的研究有利于发现不同系统在较高级别上的共同特性z获得正确的架构对于进行正确的系统设计非常关键z对各种软件架构的深入了解使得软件工程师可以根据一些原则在不同的软件架构之间作出选择。从架构的层次上表示系统有利于系统较高级别性质的描述和分析。特别重要的是在基于复用的软件开发中为复用而开发的软件架构本身就可以作为一种大粒度的、抽象级别较高的软件构件进行复用而且软件架构还为构件的组装提供了基础和上下文对于成功的复用具有非常重要的意义。软件架构研究如何快速、可靠地用可复用构件构造系统的方式着眼于软件系统自身的整体结构和构件间的互联。其中主要包括:软件架构原理和风格软件架构的描述和规范特定领域软件架构构件如何向软件构架的集成机制等。软件开发实际上是从问题域向最终解决方案逐步映射和转换的过程而特定领域软件架构(DSSA)和软件架构风格(ArchitecturalStyle)分别从问题域和软件解决方案两个方向提供了若干经过考验的候选转换路径。特定领域软件架构(DSSA):这是一个领域中的所有应用系统所共有的体系结构是针对领域模型中的领域需求给出的解决方案也是识别、开发和组织特定领域可复用构件的基础。在国内外的金融、MIS、通讯和军事等领域中都开始注意到开发特定领域的软件架构和集成框架的重要性。架构风格(AS):这是根据系统结构的组织模式确定了一组可以用于某种风格实例中的构件和连接方案以及它们的拓扑结构、组装规则以及局部和全局约束从而定义了一个面向系统结构的架构家族。软件架构风格与面向对象的设计模式或框架一样为设计经验的复用提供了技术支持。三、软件架构师的角色尽管对软件架构师的角色有这样或那样的定义但大体上下面几个职责是必需的:、技术负责解决方案的提供者、与项目经理合作制定计划决定成员组织团队、保证项目按计划和走向完成由于设计是由需求驱动的所以掌握需求分析的技巧是一个好的架构师必备的能力。事实上现代迭代开发所有的驱动力都在于需求变更如果架构师不关注需求不关注和用户的讨论和沟通那是很难设计出真正有用的东西来的。另一方面架构设计的结果主要依赖于对质量属性的理解不同的质量需求往往可能得到一个完全不同架构设计所以架构师对质量问题需要有一个透彻的理解。软件架构设计是一个非常严肃、细致、敏感而且困难的工作所以我们必须摒弃那些华而不实的名词堆砌一点一滴认真做起扎扎实实的努力实实在在的积累经验尤其是在失败中积累经验这是一个软件架构师成功的必由之路。在信息技术战略规划(ITSP)中的软件架构好的架构设计必须在信息系统战略规划(ITSP)的大环境下进行设计才可能设计出真正优秀而且有价值的系统来那么什么是信息系统战略规划呢?信息技术战略规划(ITSP)的核心思想简述如下:在信息时代知识经济的背景下正确的结合IT规划整合企业的核心竞争力在新一◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn轮的产生、发展中取得更大的市场竞争力是必要的。信息化的问题首先是企业管理层概念的问题。企业管理层的重视和对信息化的高度认同是企业信息化的关键所在。当前国内很多企业管理层很关心资本运作的问题而对很多国企业而言管理层最关心的是扭亏增盈。信息化建设投入大、周期长、见效慢、风险高往往不是企业需要优先解决的问题导致管理层对信息化的重视程度不够无法就信息化建设形成共识企业管理信息化必然带来管理模式的变化如果对这种变化不适应有抵触心态或者仅是为了形象问题赶潮流搞信息化。或者由于国家提出信息化带动工业化信息化成为一种时髦信息化工程往往成为企业的形象工程。结果软件架构的设计仅仅是企业目前业务流程的复制并不可能给企业带来实实在在的好处。有些公司缺乏统一完整的IT方向希望上短平快的项目立竿见影跳过系统的一些必要发展阶段导致系统后继无力不了了之。由于方向不明确企业内部充斥着各种各样满足于战术内容的小体系并不能给企业带来大的好处。有些公司对信息化建设的出发点不明确在各个方案厂商铺天盖地的宣传下不能很好的把握业务主线仅是为了跟随潮流既浪费了资源同时也对后继的信息化造成了不良的影响甚至直接导致“领导不重视”这样的后果。如今国家正在大力推广企业信息化。然而人们大多从技术角度来谈论信息化和评价解决方案他们往往脱离了企业的实际需要以技术为本是不能根治企业疾病的。企业依然必须明确自己的核心竞争力。明确一切的活动和流程都是围绕让核心竞争力升值的过程。IT规划意识如此必须以企业核心、业务为本。再结合公司的实际情况。开发自己需要的系统。信息化的建设难以对投入产出进行量化难以进行绩效评估CIO们无法让企业管理切实感受到信息化带来的直接效益经济效益、社会效益。战略规划是一套方法论用于企业的业务和IT的融合以及IT自身的规划。必须满足如下要求:先进性:采用前瞻性、先进成熟的模型、方法、设备、标准、技术方案使建议的企业信息方案既能反映当前世界先进水平满足企业中长期发展规划又能符合企业当前的发展步调保持企业IT战略和企业战略的一致性。开放性:为保证不同产品的协同运行、数据交换、信息共享建议的系统必须具有良好的开放性支持相应的国际标准和协议。可靠性:建议的系统必须具有较强的容错能力和冗余设备份整体可靠性高保证不会因局部故障而引起整个系统瘫痪。安全性:建议规划中必须考虑到系统必须具有高度的安全性和保密性保证系统安全和数据安全防止对系统各种形式的非法入侵。实用性:规划中建议的系统相关必须提供友好的中文界面的规范的行业用语并具有易管理、易维护等特点便于业务人员进行业务处理便于管理人员维护管理便于领导层可及时了解各类统计分析信息。可扩充性:规划不仅要满足现有的业务需要而且还应满足未来的业务发展必须在应用、结构、容量、通信能力、处理能力等方面具有较强的扩充性及进行产品升级换代的可能性。为了实现这样的规划我们必须注意到软件设计既是面对程序的技术又是聚焦于人的艺术成功的软件产品来自于合理的设计而什么是合理的设计呢?一个软件架构师最重要的问题就是他所设计的产品必须是满足企业战略规划的需求能够帮助企业解决实际问题的因此一个合理的设计首先要想的是:Who:为谁设计?◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcnWhat:要解决用户的什么问题?Why:为什么要解决这些用户问题?这是一个被称之为W的架构师核心思维如果这个问题没搞清楚就很快的投入程序编写那这样的软件在市场上是不可能获得成功的。WhoWhatWhy这三个问题看似简单但实际上落实起来是非常困难的。我们经常会看到一些产品看似想的面面俱到功能强大甚至和企业目前的业务吻合得非常好但为什么最终没有给企业带来实实在在的好处相反带来麻烦呢?一个专家感觉非常得意、技术上非常先进的系统企业的使用者未见得感觉满意这些情况在我的实践中屡见不鲜即使一些知名的公司在设计的产品往往都不能很好地把握这足以证明我们必须下功夫来面对它。那么我们该怎么来做呢?为谁设计表达的是我们必须认真研究企业的业务领域研究企业本身的工作特点通过虚心请教和深入研究使我们对于企业本身的业务有深刻的理解最后形成针对这个企业的实事求是的解决方案。要解决用户的什么问题表达的是我们必须把企业存在的问题提取出来分析研究哪些问题是可以用信息化技术来解决的采用信息化技术以后企业的业务流程需要做什么样的更改以及这些更改会带给企业什么样的正面和负面的影响。仅仅用计算机来复制企业现有业务流程是不可取的关键是要做到因为信息系统的使用使企业业务方式发生革命性的变化使信息系统成为企业业务不可分割的一部分而不仅仅是辅助工具。为什么要解决这些用户问题表达的是如何帮助企业产生可度量的价值而这些价值是在研究企业目前存在的问题的基础上产生的没有这些价值的产生软件系统的投资是没有意义的。价值不可度量企业领导者是不可能积极的支持信息化的。还要注意我们的设计必须便于用户使用减少维护和培训的资源消耗而且制作生产工艺尽可能简单这就是设计之本。任何项目都是由项目的陈述开始的在陈述的过程中比较难解决的问题是表达可度量的价值所谓可度量价值实际上是一个预估只是说由于加入了信息系统解决了过去存在的问题从预估的角度业务水平可能提升的一个度量数据。但并不等于说我管理依然是混乱的只要有了这个信息系统什么事情都不要做就可以达到这个水平了这实际上是不切实际的幻想。所谓信息系统战略规划的本质并不是说信息系统可以包打天下而是说在整体规划下的信息系统提升了我们的组织管理水平减少了不必要的环节提高了效率通过全方位的努力在可预测的未来确实可以提升整体的经济效益而且这个预测经过努力是可以达到的。经典软件开发生命周期与过程软件开发过程描述的是软件构造、部署还有维护的一种方法成功的软件设计过程更多的是研究用户和市场而不是技术本身。经典的瀑布式过程大致的情况是这样的:)收集市场数据做市场分析。)确定用户与用户交流理解用户理解用户的工作并与用户建立良好的关系以便将来的设计和开发过程中经常得到他们的反馈意见。)建立典型用户群通过对用户工作的了解发现和自己设计工作有关的典型用户群。这些典型用户群应该能够描述用户工作中的一个或者几个重要环节。)与用户交流进一步细化典型用户群并写出场景脚本。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn)确定软件的主要功能。)确定这些功能的主次并确定优先级。)确定需求并写出说明书。)由用户群检查需求说明书看需求说明能不能满足用户的需要。)进行软件架构设计。可以看出来在这个过程中软件分析占了软件设计很大一部分工作量用户、市场、分析、设计是整个软件设计中密不可分的几个部分这样一个过程也称之为“瀑布式”过程可以用图形描述如下:一、经典项目阶段范围定义阶段范围定义主要考虑两个问题:首先是项目值不值得考虑。如果项目值得考虑则确定项目的范围、目标、约束和限制条件所需的参与者、预算和进度。这里主要由问题、机会和指示作为分析的根本。包括:问题陈述:对问题、机会和指示的分类性描述这是一个开发的合约。约束条件:对约束条件的分类性描述。在项目进行过程中范围通常会变化通过记录初始范围我们就为(预算和进度)范围蔓延建立了一个基线。问题分析阶段问题分析阶段是研究现有系统分析发现的问题促使项目团队更深入的研究和理解引发该项目的问题。分析员应该经常发现新问题并回答这样一个问题:“解决这些问题的收益是不是超过了构造项目的开销?”比如我们定义了如下的改进准则:把订单处理和交货之间的时间减少三天。这时系统增加的复杂度带来的成本增加是不是超过了我们能够认可的极限?◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn我们也可以把改进目标考虑成一种升级准则新系统的升级准则可以向管理者口头汇报也可以进行正式的书面报告。需求分析阶段需求分析的目的是回答下面这样一些问题:系统给用户提供什么功能?必须收集什么数据?存储什么数据?期望达到什么样的性能等级?也就是系统需要做什么而不是怎么做。需求分析阶段需要定义业务需求并且为它排序。需求分析也可能是开发阶段中最重要的阶段。只有当设计人员完全理解了需求之后才可以开始设计工作。不过要注意避免分析瘫痪也就是过多的系统建模极大的延缓了实现系统方案的进度。在这就要求需求分析阶段必须把握重点解决最主要的问题。把大问题切分为可以理解的小问题是需求分析方法论的关键。架构设计阶段在这个阶段主要需要建立系统模型这个模型又称之为逻辑设计模型。关于这个阶段需要注意的问题将在后面详述。这个阶段主要是建立高层模型系统和子系统的框架以及基于服务的层等。决策分析阶段当获得业务需求和架构系统模型以后通常就具备了大量可选方案供我们决策分析这里提出一些有关问题:系统应该多大程度上应用计算机处理技术。我们是购买组件还是自己编制。是使用局域网还是使用Web。什么样的信息系统技术会对这个系统有用。这两个模型对于决策分析都是必要的输入特别是架构多个备选方案需要从项目团队不同的人那里把不同的想法记录下来最后确定选定方案。要把决策的原因记录下来其中包括:技术可行性运行可行性经济可行性进度可行性风险可行性等。物理设计和集成阶段这个阶段也称之为详细设计可以精细的把业务需求转换为系统模型。设计的过程包括:按规格说明设计:这是一种最经典的方法通过研究需求生成设计的蓝图。按原设计:通过构造不完整但可以工作的程序或者子系统由用户和其他人员的反馈不断地细化模型。实际上通常是这两种极端方法的组合。构造和测试阶段构造和测试事实上就开始编码在基于构件的设计和并行开发中需要研究合理的测试用例和技术标准。开发人员在编码和测试中反映过来的问题是十分重要的设计人员必须关注这些问题用于部分的合理化系统。安装和发布阶段新系统往往与企业目前的行为方式相背离所以分析员需要提供从老系统到新系统的的平稳转换方案需要准备一个转换方案一般有一个平行使用期在规定的时间突然切换到新系统。应该准备好用户手册和培训手册必要的时候对用户进行培训。事实上新系统会影响到原来的业务流程分析员需要关注这种业务流程的变化对业务的◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn影响以不断调整的姿态保证新系统的正常接入。运行和维护阶段一旦系统投入运行就需要给运行提供不断地系统支持在项目预算的时候一定要把这笔费用计算进去。在运行阶段收集用户反馈、表现出的问题以及业务需求的变化是十分重要的这对早期研发升级版本提供了支持。系统一旦到了退役期就可以迅速启碇一个新的系统开发过程来建立新项目。这个时候在这个阶段收集到的信息对新系统的设计及其有意义。尽管现在有各种各样推荐的过程但是这个基本的框架对于构造一个大型系统还是完全有必要的我们的思维还是需要在稳定性和灵活性之间寻求平衡包括开发过程也是如此。二、软件开发生命周期增量模型上述线性的或者瀑布的模型往往带来了很多问题早期的模型要求在项目的第一阶段在任何设计和实现工作之前尽可能的推敲把需求完全定义清楚并把它稳定下来并且实际开发前冻结需求但历史证明这种方式是失败的在项目很大的时候冻结需求几乎没有可能。对瀑布模型的一个关键性的改进是所谓增量模型的出现。增量模型是指首先构建部分系统再逐渐增加功能或者性能的过程。它降低了取得初始功能之前的成本强调采用构建方法来帮助控制更改需求的影响也提高了创建可操作系统的速度。增量模型是综合了瀑布模型和原型化的产物提倡以功能渐增方式开发软件经验表明这种增量模型在特大型项目和小型项目中同样适用。增量模型描述了为系统需求排定优先级然后分组实现的过程每个后续版本都为先前版本增加了新功能。在生命周期的早期阶段(计划、分析、设计)需要建立一个考虑了整个系统的架构这个架构应该是具有强的可集成性的后续的构件方式开发都是建立在这个架构之上。剩下的生命周期阶段(编码、测试、交付)来实现每一个增量。首先创建的应该是一组核心的功能或者对于项目至关重要的最高优先级的系统或者是能够降低风险的系统。随后基于核心功能反复扩展逐步增加功能以提高性能。这个过程也可以和其它模型结合(V型或者螺旋型)以降低风险和成本。增量模型的优点:◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcnz整个项目的资金不会被提前消耗因为首先开发和交付了主要功能和高风险功能。z每个增量交付一个可操作的产品。z每次增量交付过程中获取的经验有利于后面的改进客户也有机会对建立好的模型作出反应。z采用连续增量的方式可把用户经验融入到细化的产品这比完全重新开发要便宜得多。z“分而治之”的策略使问题分解成可管理的小部分避免开发团队由于长时间的需求任务而感到泪丧。z通过同一个团队的工作来交付每个增量保持所有团队处于工作状态减少了员工的工作量工作分布曲线通过项目中的时间阶段被拉平。z每次增量交付的结为可以重新修订成本和进度的风险。z便于根据市场作出反应。z降低了失败和更改需求的风险。z更易于控制用户需求因为每次曾两开发的时间很短。z由于不是一步跳到未来所以用户能逐步适应新技术。z切实的项目进展有利于进度控制。z风险分布到几个更小的增量中而不是集中于一个大型开发中。z由于用户能够从早期的增量中了解系统所以更加理解后面增量中的需求。增量开发必须注意的问题:z良好的可扩展性架构设计是增量开发成功的基础。z由于一些模块必须在另一个模块之前完成所以必须定义良好的接口。z与完整的系统相比增量方式正式的回顾和评审更难于实现所以必须定义可行的过程。z要避免把难题往后推首先完成的应该是高风险和重要的部分。z客户必须认识到总体成本不会更低。z分析阶段采用总体目标而不是完整的需求定义可能不适应管理。z需要更加良好的计划和设计管理必须注意动态分配工作技术人员必须注意相关因素的变化。二、现代软件开发管理原理对架构驱动的应用实践的总结就形成一系列现代软件开发管理原则这些现代原则与经典原则有很大的不同:把过程建立在构架优先的基础之上:这要求在交付资源进行全面展开之前就在需求、构架等重大设计决策和生命周期计划之间做出权衡。建立一个能尽早面对风险的迭代式生命周期过程:对于今天高度复杂的软件系统要按照顺序定义着那个个问题设计整个解决方案、构造软件和测试最终产品几乎是不可能的。这就需要使用一个迭代过程这个过程的方法很多关键是定义好关键的里程碑以及最终的目标必须及早提出可能遇到的风险以提高可预见性避免昂贵的下游返工。设计方法向强调基于构件的开发转变:从代码行至上转为基于构件开发的思想可以大幅度减少开发的成本构件是一个已经存在的代码行内聚集和可以由原代码、也可以由可执行文件的格式提供并且有定义好的接口和行为。建立一个变更管理环境:迭代开发的动态特性需要很好的变更控制环境包括在共享产品上工作的不同团队之间并发的工作流、客观需要的控制基线等。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn通过支持双向工程的工具增强变更的自由度:双向工程指的是位在不同格式(例如需求规格说明、设计模型、源代码、可执行代码、测试用例等)自动转化并同步工作信息所需要的一个环境支持如果没有这种实质性的自动化支持很难把迭代周期减少到可以管理的时间内。例如:我们已经很清楚迭代开发中并非所有的场景都在第一次迭代中实现一个复杂的场景往往要花个月采用多次为期两周的迭代来完成。每次迭代都处理新的场景或者场景的某些部分。在这样的情况下必然出现了一个需求跟踪的问题人们如何记录用例的哪些部分已经完成哪些部分正在进行中哪些部分还没有涉及呢?这就需要用到需求工具。像RequisitePro这些工具可以使我们可以在迭代之间跟踪用例的部分完成情况。这个工具的使用很简单也很有效。用严格的、基于模型的符号标记系统:具有严格语义的模型符号系统极其有意义它可以减少人之上的歧义UML就是一种很好的符号语言。为过程配备工具进行客观的质量控制以及进展评估:必须对所有的中间产品进行质量评估这些评估必须在度量的基础上进行这些评估是在整体工程制品质量的基础上派生出来的。使用基于演示的方法评估中间制品:把产品的当前状态(不论是前期原型、基线架构或者是一个bate能力)转换为一个可以在相关场景下运行的演示促使人们把注意力更早的集中在集成上获得对设计折衷的更加切实的理解并且尽早消除构架上的缺陷。计划在大量的使用场景中使用细节的进化等级进行中间发布:必须尽早的启动软件管理过程项目增量迭代的进化必须与现有的对需求和构架的理解水平一致因而采用内聚的使用场景(该场景是针对某些相互关联的问题设置)就成为组织需求、定义迭代内容、评估实现和组织验收测试的主要方法。建立一个经济上具有伸缩性的可配置的过程:没有一个过程是对所有软件开发都是合适的。一个实用的过程框架必须可以配置以及支持更广泛的应用这个过程必须应用共同的过程精神、广泛的过程自动化以及共同的构架模式和构件来确保规模经济和投资回报。现代软件开发过程已经远离了传统的瀑布模型尽管有一些变种瀑布模型都要求开发过程依赖于前一阶段完成情况。而现代方法一般都要求在开发过程的前期迅速构造起一个初始版本在这个版本中强调的是高风险的领域、稳定基本架构、完善获取的需求。接着开发就以迭代序列进行下去构建核心的构架直到达到期望的功能、性能和稳健性的等级。这种方法是通过不断的集成和完善需求、构架和计划减少了风险而不是到了系统快要交付的时候才惊讶的发现出现的错误。这种过程大大提高了管理上的难度也需要管理者对问题理解的更加深刻。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn第二章需求抽取与业务建模事实上架构设计是不可能独立存在的架构设计提供的是用户需求的解决方案所以一个架构师对需求分析的要点和关注点需要有深刻的理解否则是不可能有好的架构设计的。什么是需求呢?产品为用户在特定的背景中所必须满足的约束就是产品的需求需求的表达一般是抽象的而且与技术无关的这样主要是避免对技术方案产生影响但架构设计的源泉来自于需求过程也就是说合理而且正确的需求分析过程是架构设计过程的一个有机的组成部分所以我们首先必须讨论需求分析的领域建模的有关问题我们必须搞清楚什么样的需求过程才会给架构设计提供足够的信息呢?需求工程包括需求抽取、需求分析和需求管理整个过程必须给用户方、管理方和设计方提供足够的而且是清晰的信息对于分析方而言各方面的要求主要集中在如下几个方面:系统分析一、从软件缺陷的产生看需求的重要性软件的质量问题往往表现为缺陷(bug)软件缺陷的产生主要有两个原因:软件产品的特点和开发过程。例如:需求不够明确开发人员不太了解需求不知道应该“做什么”和“不做什么”常常做不合需求的事情这方面的问题最多。由于竞争激烈过早使用新技术也容易产生问题。有的企业为了在时间上取胜认为实现很新、很酷的功能比质量更重要因此时间上安排很紧分析和设计的投入远远不够测试也不到位这是产生软件错误的主要原因之一。除此以外设计文档不清楚文档本身就存在错误沟通上存在问题项目管理水平差都可能导致问题。概括起来可以有七项原因:z项目期限的压力。z产品的复杂度。z开发人员的疲劳、压力或者受到干扰。z缺乏足够的知识、技能和经验。z不可解客户的需求。z缺乏动力。从软件自身特点、团队工作和项目管理等多个方面进一步分析就比较容易确定造成软件缺陷的一些原因细节归纳如下:软件自身特点造成的问题◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcnz需求不清楚导致设计目标偏离客户要求从而引起功能或者产品特性上的缺陷。z系统结构非常复杂而又无法设计成一个良好的层次结构或者组件结构结果导致意想不到的问题或者维护、扩充上的困难。即使设计成良好的面向对象的系统由于对象、类太多很难完成多个对象相互作用的组合测试而隐蔽着一些参数传递、方法调用、对象状态变化方面的问题。z新技术的采用可能涉及实现没有考虑到的技术与系统兼容性问题。z对程序的逻辑路径或者数据范围的边界考虑不周容易在边界条件下出错。z系统运行环境复杂包括用户的各种操作方式及各种输入数据容易引起一些特定用户环境下的问题大用户量或者大数据量也可能引发负载问题。z对于一些实时系统如果时间同步设计不精确也可能带来不协调、不一致的问题。z没有考虑系统崩溃后系统的自我恢复或者数据的异地备份等问题从而存在系统安全性和可靠性的隐患。z由于通信端口多、存取加密手段的矛盾等会造成系统安全性或适用性上的问题。软件项目管理的问题z缺乏质量文化不重视质量计划对质量、资源、任务、成本等的平衡把握不好容易挤掉需求分析、评审、测试等时间。z系统分析对客户的需求不是太清楚或者与用户的沟通存在一些困难。z开发周期短需求分析、设计、编码与测试不能按照已经定义好的过程进行工作不够充分效果也就不完善、不准确错误也就比较多。开发周期短还给各类开发人员造成太大压力引起一些人为的错误。z开发过程不够完善存在太多的随意性缺乏严谨的复审和评审机制容易产生问题。z文档不完善风险估计不足等。团队工作的问题z不同阶段的开发人员相互理解不一致软件设计人员对需求分析结果的理解有偏差编程人员对系统设计规格说明书中的某些内容重视不够存在着误解。z设计或者编程上的一些假定或者依赖性事先没有得到充分的沟通。z项目组成员技术水平参差不齐新员工比较多或者培训不足也容易造成问题。软件缺陷虽然是由很多原因造成的但从整个开发周期的统计结果来看我们会意外的发现规格说明书是软件缺陷出现最多的地方如下图所示。换句话说需求分析的不到位是产生软件缺陷的最大原因。产生这种情况的原因如下:z用户一般是非计算机专业人员软件开发人员与用户沟通存在着比较大的困难对要开发的产品功能理解也不一致。z由于软件产品还没有设计、开发完全靠想象去描述系统的实现结果所以有些特◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn性还不够清晰。z用户的需求总是在不断的变化容易引起前后文、上下文的矛盾和需求描述的不一致。z需求分析没有得到足够的重视在规格说明书的设计和写作上投入的人力、时间都不足。z没有在整个开发队伍中进行充分的沟通有时只有架构师和项目经理得到比较多的信息。因此需求分析就显得非常重要因为如果事情说不清楚就没有办法做好。按出现问题的排位看第二位是设计第三位是编码。如果从软件开发各个阶段造成缺陷的分布来看编码以后阶段的错误也要比前两个阶段少。正是对这个问题的理解作为架构设计人员来说有必要对需求分析的思想和方法有透彻的理解。需求并不是加在项目上的额外负担实际上可以使项目的进行更加顺利如果还不太清楚要构建什么产品就开始构建了那项目出现问题几乎是确定无疑的事情但是这并不等于需要完全理解需求以后才可以构建也不意味着所有的需求都要写成书面的形式而是意味着只有注意需求才可能向用户提交有用和可用的产品。需求的表达常常是抽象的以一种与技术无关的方式表达这样做的母的是为了避免解决方案对技术产生影响需求是对业务方面的说明而不能有任何技术实现上的偏好产品设计的角色是把需求翻译成一个计划按这个计划就可以构建出一个实体。还有一点需要注意好的需求意味着需求、设计和实现可以通过一系列的迭代循环来实现每次迭代都会得到一些有用的功能如下图所示。所以在产品构建好以后需求不会冻结下面我们对几个最重要的过程问题加以讨论。二、需求的主要内容需求是产品必须完成的事以及必须具备的品质它主要包括如下几部分:功能性需求功能性需求是为了向风险承担者提供的产品必须执行的动作。功能性需求源自于风险承担者需要完成的工作几乎所有的动作包括计算、检察、发布或者其它动作都可以是一项功能需求。功能性需求是用户给定业务背景下必须要做的事情。非功能性需求◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn非功能性需求描述了产品必需具备的属性和品质在某些情况下非功能性需求描绘了诸如观感、可用性、安全性和法律限制等需求这些对于产品的成功是至关重要的。例如产品必需在秒之内便认出是朋友还是敌人。非功能性需求通常在产品功能确定以后(但并非总是如此)也就是说一旦知道产品要做的事(功能性需求)就可以确定它的行为方式它需要具备什么品质以及它的响应速度、可用性、可读性和安全性等。限制条件限制条件是全局性的需求又称之为“约束条件”它可以是项目本身的限制或者是对产品最终设计的限制比如:产品必需在新的税务年度开始之前准备好。这个约束的效果是分析师必须对需求分析进行限制只包括那些在最后期限能够提供最大价值的需求。又比如限制条件时针对产品最终设计和构造的:产品运行在G手机上。结果不满足这样限制的解决方案是不可接受的。所以限制条件是另一种类型的需求。三、需求演进在项目开始的时候需求分析师关注的是产品将要支持的业务(或者称之为工作)在这个阶段分析时研究场景及其它模型帮助他们与风险承担者讨论在业务上应该在什么在这个问题上达成一致意见这时候的需求可以称之为“业务需求”。随着对业务理解的加深风险承担者对有助于自己工作的最佳产品做出了决定现在需求分析师开始确定产品的详细功能并且编写“产品需求”。非功能性需求几乎是在同一个时间导出来的与限制条件一起被记录了下来。此时需求使用一种与技术无关的方式写下来它规定了产品应该为工作做些什么但没有规定工作应该用什么技术来实现。当对他们的理解有足够的程度地时候这些需求就可以交给设计者他们添加产品的“技术需求”然后为构建着提供最终的设计规格说明书。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn需求的过程定义任何重要的工作都需要某种有序的过程而且参与这项工作的人必须知道为什么这个过程中有些步骤是重要的知道哪些部分对他们的项目具有特定的重要意义这就需要对需求过程进行定义。应当说明这里我们定义的过程是为了得到提交产品的一个指南而不是一个一成不变的程序更不是一个必须的“做事情的方式”我们可以从中理解很多有用的事情从而更有效、更准确地收集需求。需求过程在软件开发过程中是一个关键过程域它建立了一套需求收集、建模、分析、和描述的循序、方法和模版使需求可以以一种有序而深入的方式进行。但是没有什么过程是放之四海而皆准的我们必须根据我们自己的实际情况来定义个改进我们的需求过程我们不希望拿着课程中的过程就直接使用而是仔细分析创建一个构建相关产品的最佳方式根据需要调用这个过程使它符合您的项目和组织机构。定义过程实际上就是定义软件分析的业务这是一个成熟的软件组织必须要做的事情在这个总体过程的基础之上我们可以把每个过程在分解为相应的子过程这样就可以使我们的思维活动变的可操作。事实上定义需求过程的本身也是也是进行业务建模的一个训练可以使用数据流图(DFD)表达箭头表示数据的流动(或者过程的流动)DFD只用了个符号如下图所示。和所有高层图一样图中并不需要表示面面俱到的内容而只是把最重要的关系表达出来细节可以通过过程的分解来达到。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn后面我们会围绕这个过程中的重要的子过程仔细分析分析这些过程的细节(将要表达的过程都编了号)这样就可以把问题越来越深、越来越透彻的研究和分析清楚所以这个课程本身就是一个需求分析的训练从而得到需求分析的正规、详尽而全面的知识。需求过程是没有终点的当项目和产品的一部分已经交付用户开始使用它的时候演进过程就开始了人们会发现一些新的要求和用途希望产品得到扩展这就提出了新的需求。正因为产品自身有一个演进的过程就可以决定先构建一个包含较少功能的早期版本然后通过所计划的一系列发行版本来支持它。同时也要注意围绕这个过程的人这些人为这个过程提供信息或者从过程接收信息这些人有一部分是风险承担者也可以是对项目感兴趣的团队他们具有收集产品须求所需要的知识。需求过程不仅仅适用于从头开发产品的情况对于迭代或者升级的产品也同样适用本节的说们旨在对过程的各部分如何配合有个概貌的了解但并不准备讨论若干细节。下面我们对主要子过程加以说明。项目启动项目启动主要要确定三件事情:z产品实现的目标以及确定范围。z发现和确定主要风险承担者。◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcnz限制条件以及项目的可行性。启动会议对项目进行准备并且在开始详细的需求工作之前确保项目的可行性。它的特点是主要风险承担者(客户、主要用户)、首席分析师、技术业务专家以及其他对项目的成功有关键作用的人聚在一起对关键的项目问题达成一致意见。由首席分析师协调整个小组在启动会议上首先需要确定业务问题的范围参与者在白板上画出系统上向文模型以及系统如何与外界联系。在业务问题差不多达成一致以后小组开始确定风险承担者(项目中的利益相关人)。项目启动也确认了项目的目标小组也必须对项目是否值得开发以及组织机构的能力等问题达成一致意见。一、调查研究技术调查研究事实上是一个需求获取过程在这个过程中一定要注意的是不要把症状当成问题我们必须关注真正的问题到底在哪里以期找到业务上的问题症结所在。在分析和讨论的过程中可以使用一种称之为鱼骨图的方式这是日本人首创的方法它是一种确定、探索、何描述问题及其原因和结果的图形工具。例如对于客户拒绝履行合同的问题可能有五个方面的原因以及若干具体问题。在讨论会上在白板上书写这样的图可以加深对问题的理解(请用数码相机拍下来)。利用这样的图可以清楚地描述可能出现的问题和应对措施。所谓调查研究是通过研究、面谈、调查表、抽样以及其它技术来收集关于问题、需求、偏好等问题的正式过程。在分析阶段系统分析员应该了解一个企业和系统的术语、问题、机会、约束条件以及优先级。一般来说不管项目如何都会有一个框架帮组我们在早期阶段收集事实。我们可以对现有的文档、表和文件进行抽样来收集事实。也可以通过观察工作环境甚至观察工作中的人来收集事实。或者通过精心制定的调查表来收集事实。也可以通过和客户面谈来收集事实。面谈是一种重要的收集事实的方法我们必须选择被接见者制订问题方案在面谈中学会聆听对方的表达并且能够迅速抓住问题的本质。需求必须通过一种形式化的方法记录和表达以便于和客户沟通。二、范围定义◆中科院计算所培训中心高级软件系统架构师培训http:wwwTCICTcn高级系统分析员和项目经理通常领导这个阶段在范围定义阶段我们需要做的事情是:列出问题和机会:需要关注以下几个方面的问题:紧急程度(什么时间实现?)可见性(系统在多大程度上对客户或执行管理层是可见的?)收益(新方案会增加或者减少多少支出?)优先权(那些问题是最重要的?如果预算出了问题需要减掉哪些问题?)可能方案(用简单的方式表述:如不改变令人满意的事物、快速修复、对现有系统改进、重新设计现有系统、设计一个新系统等等)协商项目的初步范围:包括什么类型数据描述了正被研究的系统

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

评分:

/43

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利