如何描述和评价软件

如何描述和评估软件架构质量议题󰂄󰂄󰂄󰂄󰂄软件的质量建模评估软件架构质量的价值怎样改变软件架构的质量如何评价软件架构评估软件构架师的能力软件的质量建模󰂄软件架构质量模型技术架构󰂄管理架构󰂄支撑架构󰂄业务架构󰂄软件架构质量模型隐喻󰂄󰂄软件质量的重要性是不言而喻的，但是当所有人都意识到它的重要性的时候，却很少有人能够清晰的描述出如何才能够提高软件质量。软件质量框架的目的就在于提出一个评价的原型，帮助我们分析一种方法和技术是否能够提高软件质量。什么才是一个高质量的软件？󰂄满足用户的需求。这是最重要的一点，一个软件如果不能够满足用户的需要，设计的再好，采用的技术再先进，也没有任何的意义。所以这一点非常的朴实，但却是软件质量的第一个评判标准。󰂄合理进度、成本、功能关系。软件开发中所有的管理都是围绕着这几个要素在做文章的，如何在特定的时间内，以特定的成本，开发出特定功能的软件。三者之间存在一种微妙的平衡。在Planning一个高质量的软件的开发过程中，项目成员一定能够客观的对待这三个因素，并通过有效的计划、管理、控制，使得三者之间达成一种平衡，保证产出的最大化。󰂄󰂄具备扩展性和灵活性，能够适应一定程度的需求变化。当今的社会已经变成一种变化速度极快的设计了。变化就会对软件产生冲击，所以一个质量优秀的软件，应该能够在一定程度上适应这种变化，并保持软件的稳定。󰂄能够有效的处理例外的情况。写过软件的人都知道，实现主体功能的工作量其实不大，真正的工作量都在处理各种例外。所以，一个软件如果能够足够的强壮、足够的鲁棒，能够承受各种的非法情况的冲击，这个软件就是高质量的。󰂄保持成本和性能的平衡。性能往往来源于客户的非功能需求，是软件质量的一个重要的评价因素。但是性能问题在任何地方都存在，所以需要客观的看待它。例如，一段性能不错的代码可能可读性很差，这就需要进行平衡，如果这段代码的性能是整个软件的关键，那么取高性能而舍弃可读性，反之则取可读性而舍弃高性能。一个优秀的软件能够保持成本和性能之间的平衡。󰂄能够可持续的发展。很少有软件组织只开发一个软件的，所以，一个优秀的软件在开发完成后，可以形成知识沉淀，为软件组织的长期发展贡献力量。这是一个优秀的软件应该要能够做到的。软件质量框架的组成󰂄󰂄󰂄󰂄第一部分是前提，说明了软件框架的适用范围，以及适合的环境，和方法学一样，没有泛之四海皆准的方法学，所以软件质量框架也需要一个上下文环境。第二部分是价值观，价值观说明了软件质量框架中强调的价值，在软件框架的结构和实践中，都将充分的的表现出一开始我们定义的价值。第三部分是结构。结构定义了软件质量框架的组成部分，以及软件质量框架和开发过程之间的关系。第四部分是文章中着墨最多的部分，即优秀实践。优秀实践通过具体、实际的分析、举例，深入阐述了软件质量框架的价值观和结构。软件质量框架的前提󰂄󰂄󰂄平台前提：由于软件质量框架的实践将会涉及具体的技术和代码，所以我们首先为软件质量框架定义了平台。软件质量框架将会运行在J2EE平台上，使用对象分析技术（并不一定是面向对象技术，我们可以采用以数据为中心的技术）。组织前提：执行软件质量框架需要投入，需要付出，软件质量框架最难的地方不是学习，而是执行。在一个组织中，需要评估应用软件质量框架需要多少的投入，对目前的开发过程有多大的助益。一般来说，组织的规模越大、其开发过程和产品越复杂，就越适合采用软件质量框架。方法学前提：在敏捷方法学中，对规则和秩序有两种不同的观点，一种是强调规则和秩序，以XP为代表，它对代码都有要求；另一种则不那么强调，以自适应软件开发为代表，它不要求程序员的具体行为。软件质量框架采用第一种观点，要求组织中存在严谨的规则和秩序。软件质量框架的价值观󰂄󰂄明确具体：对软件的管理必须是明确具体的。软件开发是工程、也是艺术，需要紧密的协作和沟通，任何一个含糊的指令都可能导致软件开发中出现错误，所以，在软件开发中，任何一个指令都应该是相对明确的。为什么说是相对呢？是和成本相对，指令越明确，成本就越高。例如，你可以把需求文档写的非常的具体，但是你需要付出制作和维护的代价。所以我们的明确性是一个考虑成本前提下的特性。明确具体要从综合上考量。怎么理解呢？例如，XP中的用户故事是非常不精确的，按道理说它是不明确，也是不具体的。但是在整个开发周期中，将会有迭代、测试、现场用户等多种手段使得用户故事明确具体起来，所以从整体上看，它并不违反我们的价值观。产品质量是一个系统工程，决不仅仅是QA部门的工作，。这个道理适用于制造业，也适用于软件开发业。󰂄容错：软件开发是人的工作，人是无法避免错误的。所以，软件质量框架中允许犯错。因为不犯错是天方夜谭。你就算做了这方面的强制规定也无法避免它的出现，反而会引发其它的问题，例如隐瞒错误，或为了隐瞒错误而导致的额外成本。所以正确的态度是允许发生错误，并建立一套监测、管理、反馈、修改错误的体制。󰂄规范：在前提中，我们已经提到了，规范是软件质量框架的基本态度。所以，软件质量框架中强调规范，并使用规范来推动框架的运作。󰂄测试：软件质量框架非常强调测试，测试是保证质量的必由之路。测试要尽可能的多，尽可能的频繁、测试结果要尽可能快的反馈。这是软件质量框架对测试的基本态度。测试是综合性的，软件开发过程中的所有工件，都需要伴随着相应的测试工件。这是基于一个简单的理念，如果你不能够为你的工作制定一个完成的标准，你又该如何开展你的工作呢？软件质量框架的结构󰂄󰂄处于结构核心的是技术架构和管理架构。软件质量框架既不是方法学，也不是一个软件，更像是两者的结合体。技术架构和管理架构的融合体现了这一特性。软件质量框架并不关心单个开发人员的效率，它关注的是开发团队整体的效率。因此，管理架构在框架中的意义在于它定义了一套软件管理的方法，能够对开发人员及其他们的工作进行管理。从这一点来看，它的作用和软件工程方法学是一样的。但是，在现实中我们发现软件组织在迈向软件过程的途中往往因为现实的困难而止步不前。其中一个主要的原因是在引入方法学的过程中生产效率降低了，而引起组织成员对变革的怀疑和不满。󰂄软件质量框架还提供了一个技术架构，其目的是明确的定义如何应用组织中涉及的软件技术，以及管理软件技术的方法。技术架构是具体的代码，相比起方法学来说，它更加的具体，更容易为开发人员所理解。而技术架构存在的目的，一方面是进行技术积累，另一方面也是为管理架构服务。󰂄技术架构和管理架构的下一层是支撑框架。支撑框架包括代码、组件、文档，目的是为技术架构和管理架构提供底层的支持。󰂄处于结构最顶层的是业务架构。这个部分对于任何一个软件组织来说都是不同的，因为不同的软件组织的业务不同。业务架构的目的是对业务进行建模和抽象，提取出可重用的部分，以提高软件组织的生产率。本文中不涉及该部分的内容。软件质量框架的优秀实践󰂄󰂄一个开发团队要提高效率，就需要思考目前的管理活动中有哪些要素是可以改进的：如何把一些事务性的操作变得自动化，从而节约人力；如何找到更好的方法，让开发过程更为合理，更注重软件的质量；如何在团队中传播优秀的思想，让团队成员不断的学习和进取，自发的改进过程。这些美好的愿望几乎是所有方法论和各种认证的共同心声，但要完全做到可就太难了。优秀实践均是来源于软件开发界中的一些新思路和新理论，它们能够为以上愿望的达成起到正面的作用。在组织中引入用这些实践决不是一个容易的过程，但它们确实非常的有效。不论是在成本控制上，还是在质量的改进上。󰂄日创建：一个组织应当拥有一个有效的工作流程，这个工作流程能够指导软件开发的进行。这个流程应当是具体的、可操作的。随意的计划和从来不遵循的进度决不是一个有效的工作流程。日创建实践提出了一种对开发过程进行精细管理的方法，它是量化软件管理的基础。有了日创建，你会发现计划的制定和进度的监控是非常容易的一件事情。󰂄测试驱动开发：软件质量的根源来源于测试，测试做好了，软件质量就会好。这是毫无疑问的。问题的关键在于怎么做测试，才能保证测试的投入能够带来软件质量的有效提升。测试驱动开发正是为了解决这个问题而出现的。它不是一个完整的方法论，可以和任何一种开发流程进行融合。测试驱动开发不但能够改善测试效果，还能够改进软件的设计。󰂄建立核心框架：框架是一种具有高度重用性的软件，这个特性决定了它非常适合成为软件组织积累知识的一种有效手段。传统的知识积累的方法是文档，但是文档容易产生歧异，开发人员往往也不愿意去阅读和理解文档。框架提供的是一种综合的手段，包括文档、模型和代码。更容易理解，更重要的是，开发人员必须在日常的工作中使用框架，这使得他们对框架中的知识非常的熟悉，并根据工作的需要来改进框架。󰂄面向组件编程：有效的组织在于有效的分工。体力活动容易进行分工，脑力劳动则比较难，而软件开发似乎就更难了。所以，长久以来我们都习惯采用以功能块为单位的粗粒度划分方式。面向组件编程采用更加细密的划分方式，并以服务作为组件之间相互依赖的契约，不但定义了组件和组件之间的关系，也规定了组件开发者、组件使用者、组件测试者的权利和义务。从而能够进行软件开发工作的分配、管理、QA等工作。󰂄󰂄从软件结构的角度来看，日创建和测试驱动开发似乎偏向于管理架构，而建立核心框架和面向组件编程则偏向于技术架构。事实上，他们既包含了技术架构，也包含管理架构，彼此之间也有相互关联。例如，面向组件编程在合理划分组件之后，就需要一个有效的核心框架来集成组件，通过每个组件都需要采用测试驱动开发方法来保证质量，同时，日创建将会以组件为单位来进行每日的创建，从而为进度估算提供有效数据。󰂄未来的一种可能性是UML2.0和MDA技术的普及，以上的几个实践从以代码为核心转变为以设计为核心，而另一种可能性是随着以AspectJ为代表的AOP技术的普及和J2SE1.5中引入的元数据机制，面向组件编程将把Aspect作为组件的一种，而测试驱动开发也会加入测试Aspect的相关内容，在日创建中也会增加相应的处理AOP的步骤。软件架构评估高质量架构设计的障碍󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄1、对软件开发过程中架构设计的重要性没有认识。2、对软件架构师的角色缺乏理解。3、宽泛地认为设计是艺术形式的活动，而不是技术活动。4、对设计的过程缺少理解。5、在开发组织中缺少设计经验。6、缺少软件架构设计的方法学和相应工具。7、不知道如何评估设计。8、在‘利益相关者’之间缺乏有效的沟通。典型的评估方法󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄󰂄1、Scenario-based Architecture Analysis Method (SAAM).基于场景的架构分析方法。2、Architecture Trade-off Analysis Method (ATAM)架构权衡分析评估方法3、SAAM Founded on Complex Scenarios (SAAMCS).4、Extending SAAM by Integration in the Domain (ESAAMI).5、Software Architecture Analysis Method for Evolution andReusability (SAAMER).6、Scenario-Based Architecture Reengineering (SBAR).7、Architecture Level Prediction of Software Maintenance (ALPSM).8、Software Architecture Evaluation Model (SAEM).9、Cost Benefit Analysis Method (CBAM)Architecture Trade-off Analysis Method (ATAM)󰂄󰂄架构权衡分析评估方法1、评估参与者1) 评估组独立于项目组，3-5人，中立，每个人都有能力进行架构设计。󰂄2) 项目决策者项目负责人，架构师，客户代表等构成󰂄3) 构架利益相关者开发人员，测试人员，维护人员，用户等构成12人-15人。󰂄Architecture Trade-off Analysis Method (ATAM)󰂄2、角色表角色项目组长评估组长[主持]场景记录员会议记录员计时员观察员执行者提问者职责构建评估组，协调，监督评估的报告的生成和交付。执行评估，推动基于场景的评估。选择并控制不同的评估场景。推动评估分析活动。协助绘画，书写场景，捕捉场景的结论。会议本身的记录，整理并分发会议记录。协助评估组按既定的时间进行各个场景，步骤地评估。记录并建议评估组如何改进评估。协助评估组长执行评估的步骤，方法。要提出架构利益相关者没有想到的问题。序号12345678󰂄3、步骤及输出Cost Benefit Analysis Method (CBAM)󰂄1) 消耗和效益的上下文󰂄2) 步骤评估软件构架师的能力角色和分工󰂄参与应用建模的人员主要分成两类角色：系统构架师和设计师。系统架构师职责（1）󰂄󰂄󰂄󰂄系统构架师负责领导和协调整个项目中的技术活动。在个人综合素养方面，系统构架师应该具有领导才能，能够在压力下作出关键性的决策并善始善终；能够赢得项目经理、客户、用户群体以及管理团队的认同和尊敬，尤其要善于和项目经理紧密协作；在各个方面都能展现出面向目标的实干作风。在专业技能方面，与其他角色相比，系统构架师通常具有全方位的技能，其见解重在广度，而不是深度。系统架构师职责（2）󰂄󰂄系统构架师不仅需要具备设计师的各项技能，而且应该具有问题领域和软件工程领域的实践经验，从而有能力在无法获得完整信息的情况下迅速领会问题并根据经验作出审慎的判断。如果项目较大，系统构架师将是一个团队，上述的关键素质要求可由团队成员来分担，但其中要有一名系统构架师具有足够的权威。设计师职责󰂄设计师的工作对象通常是系统的局部或者细节。设计师应该掌握的技能包括：󰂄󰂄󰂄理解以Use Case建模技术捕获和描述的软件需求；在系统构架师的统一协调下，应用UML进行局部的面向对象分析和设计；了解主流的实施技术(程序设计语言和开发环境)。