全国计算机软考软件设计师考前练习及答案集锦

软件自动化测试实例分析   　　软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。 一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问就可以得到解决。 　　项目测试管理 1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。 2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。 　　3. 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一　　软件测试是对创造力和智力非常有挑战性的任务。测试一个大型软件需要的智能要超过设计这个程序的智能。软件在它发行之前应当通过彻底的测试，以保证它的可靠性和功能性，不幸的是，测试工程师要覆盖一个大型程序的所有情况会感到太麻烦和太费时。确实，软件的每个部分如能被分别测试到，同时一些指定的路径也能被测试，这对总的软件质量的保障是非常有效的。 一般的说，没有测试覆盖分析工具，软件在发行前仅有50%的源程序被测试过。在差不多有一半源代码没有被测试的情况下，大量的故障（bug）随软件一道被发行出去。在这种情况下，软件的质量、性能和功能不可能得到保障。此外，什么时候测试结束？或是否要对该程序作进一步的测试？对于测试工程师和测试管理人员来说是不知道的，通过引进测试覆盖的概念，问题就可以得到解决。 　　项目测试管理 1.帮助软件管理者准确地测算开发组的效率的，通过提供多层分析,包括系统/文件/类/函数的能力。 2.提供管理人员测算工程开发进度与质量分析的能力，允许在被生成的类继承图和函数调用图上，直接反显所有在规定的日期或一个小组/单个员工完成的模块，在这些图上带有覆盖在每个类/函数框上以条形图方式显示的相关质量信息，比如大小、复杂性、数据性能、代码测试覆盖等。 　　3. 结合软件系统质量分析能力和系统开发管理能力，提供给管理人员的带有质量数据的有关开发效率和工程开发进度信息总是即时的和精确的，因为它们是直接从源代码得来的第一手信息。 　　测试计划 软件系统不仅变得越来越庞大，但是也变得越来越复杂。复杂的代码是很难阅读、理解和修改的；必须化更多的精力去测试、维护和再测试。测试复杂性分析能帮助软件工程师容易并精确地去计划他们的测试活动。 提供系统级复杂性分析和过程级复杂性分析去精确地测量复杂性，帮助工程师更好地计划他们的测试活动。帮助工程师更好估计和使用测试复杂性度量，为满足不同层次的测试覆盖的要求，必需提供：块测试复杂性、分支测试复杂性、段测试复杂性、条件-判定测试复杂性、条件-段测试复杂性。测试复杂性的值取决于用于记录对应的测试覆盖数据的插装点的点数。 手信息。 测试用例管理 　　1. OO-Test提供了在国内外市场上最全面的测试覆盖分析能力，去满足不同的测试覆盖需求： 　　●类的测试覆盖 　　●函数的测试覆盖 　　●块的覆盖 　　 　　●循环边界的覆盖 　　●分支的覆盖 　　●段的覆盖 　　●条件（判定）的覆盖 　　●段--条件的覆盖 　　2．TCA能确定每一个测试用例作用的范围，通过给出的测试用例就能确定被测试的类，或函数，或段。这种功能对于评估测试用例的效率，和对于修改以后指定的类或函数或段的再测试是非常有用的。 　　3．此外，TCA能从初始测试用例中自动地抽取最小测试用例集，并对基于类的、函数的、分支的、块的、段的覆盖等等各自分别进行划分。它可以对系统级的再测试节省大量的时间和费用。 　　训练新成员 　　1. 提供全面的静态和动态系统分析的能力，能抽取各种信息及自动生成系统文档，并且可以使被抽取的信息让新成员联机访问，大大的节省了设计人员和工程师的时间。 　　2.通过提供最新的和精确的各种系统概貌图和流程图(包括数据结构、类继承图、函数调用图和程序树)，全局数据分析的详细报告，详细的程序逻辑图和源代码的控制流程图，帮助他们了解系统和深入地理解代码。 　　3.使用的GUI接口,使开发组的新成员容易自我训练；具有一个从顶层到详细的代码系统动态的和图形化的表达能力；具有链接不同层次的结构图和流程图在一起的能力。 　　4.提供基于函数分析和流程图化的能力与基于类分析和流程图化的能力，使得一个面向对象的系统很容易被透彻地了解。 　　单元测试的考虑单元测试是要检验程序最小单位（模块）有无错误，它是在编码完成后，首先要施行的测试工作。一般由编码人员自己来完成，因而通常把单元测试看成是编码步骤的附属品。单元测试大多从程序的内部结构出发设计测试用例，即采用白盒测试方法，多个程序模块可以并行地独立开展测试工作。 　　单元测试是针对每个程序模块，解决5个方面的问题：模块接口、局部数据结构、边界条件、独立的路径和错误处理。 　　1.模块接口: 　　对模块接口的测试，是检查进出程序单元的数据流是否正确。对模块接口数据流的测试必须在任何其他测试之前进行，因为如果不能确保数据正确地输入和输出的话，所有的测试都是没有意义的。 　　2.局部数据结构: 　　在模块工作过程中，必须测试其内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。 　　3.独立的路径: 　　在单元测试中，最主要的测试是针对路径的测试。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。 　　4.边界条件: 　　软件常常在边界地区发生问题。 　　5. 错误处理: 　　测试出错处理的要点是模块在工作中发生了错误，其中的出错处理设施是否有效。 　　单元测试的过程 　　单元测试常常和代码编写同步进行，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试用例设计。 在对每个模块进行单元测试时，不能完全忽视它们和周围模块的相互联系。为模拟这一联系，在进行单元测试时，需设置若干辅助测试模块。辅助模块有两种，一种是驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在单元测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。另一种是桩模块（stub），用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。 　　驱动器和桩都是额外的开销，这两种模块虽然在单元测试中必须编写，但却不作为最终的软件产品提供用户。如果驱动器和桩很简单的话，那么开销相对较低，然后，使用“简单”的模块是不可能进行足够的单元测试的，模块间接口的全面检验要推迟到集成测试时进行。 软件自动化测试流程 　　件自动化测试工具的软件测试流程，不仅仅包含完整的软件测试流程框架，同时还提供了内嵌软件测试流程的测试管理工具的支持，包括完整的测试评测方法。 　　1.软件自动化测试工具软件测试流程框架 　　软件自动化测试工具标准流程提供了一套完整的测试流程框架，软件测试团队可以以它为基础，根据业务发展的实际要求，定制符合团队使用的软件测试流程。 　　每个测试环节的具体阐述如下： 　　◆制定测试计划的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定一个测试计划。 　　◆设计测试的目的是确定、描述和生成测试过程和测试用例。 　　◆实施测试的目的是实施（记录、生成或编写）设计测试中定义的测试过程。输出工件是测试过程的计算机可读版本，称为测试脚本。 　　◆执行测试的目的是确保整个系统按既定意图运行。系统集成员在各迭代中编译并链接系统。每一迭代都需要测试增加的功能，并重复执行以前版本测试过的所有测试用例（回归测试）。 ◆评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。 　　2.软件自动化测试工具的评测方法 软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。 2.1 覆盖评测 覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。 　　◆基于需求的测试覆盖 　　基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。 测试覆盖通过以下计算： 　　测试覆盖 = T^(p,i,x,s) / RfT 其中：T是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。RfT 是测试需求 (Requirement for Test) 的总数。 　　◆基于代码的测试覆盖 　　基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。基于代码的测试覆盖通过以下公式计算： 　　测试覆盖 = I^e / TIic 其中：I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic (Total number of Items in the code) 是代码中的项目总数。 　　2.2 质量评测 　　测试覆盖的评估提供对测试完全程度的评测，对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。 　　◆缺陷报告 　　一般，可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。 　　◆性能评测 　　评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。 　　主要的性能评测包括： 　　◆动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。 　　◆响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。 　　◆百分位报告 - 数据已收集值的百分位评测/计算。 ◆比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。 软件质量保证阅读(中英文对照)习题及答案 　　 EXERCISES 1．Multiple choices． 　（1）Standard of software engineering project is defined as a             of the developed product．          a．the minimal level of performance          b．the maximum level of performance          c．robustness          d．organization 　（2）Quality assurance of software is            ．          a．an emerging subdiscipline of software engineering          b．a management function          c．as a verification function          d．as a validation function 　（3）Quality criteria suggested by Boehm and other persons include more than           ．            a．19    b．20    c．21    d．22 　（4）A quality assurance team should be             ．          a．associated with any particular development group          b．depended upon any particular development group          c．responsible for reporting directly to management          d．in-depended upon any particular development group 　（5）The main goals of research in software engineering are            ．          a．development of usable software standards          b．development of accepted applicable standards          c．development of generally applicable standards          d．to overcome the major hurdle in the path of software management 　（6）Some software standards developed by IEEE and ANSI describe             ．          a．configuration management plans          b．documentation          c．specification practices          d．software comparison 　（7）The activity of quality assurance involves             ．          a．verification activity          b．program walkthroughs          c．design reviews          d．validation activity 　（8）The process of software development includes             ．          a．verification function          b．management function          c．validation function          d．writing code 2．Fill in the blanks with appropriate words or phrases． 　（1）The development team’s responsibility is to             ． 　（2）Quality assurance must ensure that             ． 　（3）Software quality assurance is now an              of software engineering． 　（4）Assessment of software quality still relies on             ． 　（5）We are not yet capable of quantifying             ． 　（6）At each stage of the software life cycle the activity of software quality assurance is clo-sely related to． 　（7）One of the elusive nature of software quality is             ． 　（8）The activity of quality assurance also involves             ．          a．emerging subdiscipline of software engineering          b．checking the finished product and its associated documentation to be conformed with exist standards          c．most software characteristics          d．validating the system          e．verification and validation activities          f．a product meets or exceeds prespecified standards          g．the judgement of skilled individuals          h．to develop software standards for quality assurance   答案：  1 （1）a，c，d   （2）a，b   （3）a，b   （4）c，d （5）a，b，c，d  （6）a，b，c，d  （7）b，c   （8）a，c，d 2 （1）d    （2）f    （3）a    （4）g （5）c    （6）e    （7）h    （8）b 软件质量保证阅读(中英文对照) SOFTWARE QUALITY ASSURANCE 　　The activity of software quality assurance is closely related to verification and validation activities carried out at each stage of the software life cycle[1]．Indeed，in many organizations there is no distinction made between these activities．However，quality assurance and other verification and validation activities are actually quite separate，with quality assurance being a management function and verification and validation being part of the process of software development[2]． An appropriate definition of software quality assurance is provided by Bersoff（1984）：Quality assurance consists of those procedures，techniques and tools applied by professionals to ensure that a product meets or exceeds prespecified standards during a products development cycle[3]；and without specific prescribed standards，quality assurance entails ensuring that a product meets or exceed a minimal industrial and / or commercially acceptable level of excellence． 　　This definition is，of course[4]，a fairly general one and it suggests that，firstly，software standards can be established and，secondly，the level of excellence of a software product can be estimated． 　　The development of software engineering project standards is an extremely difficult process. A standard is some abstract representation of a product which defines the minimal level of performance，robustness，organization，etc.，which the developed product must attain[5]．At the time of writing，some software standards have been developed by the IEEE，ANSI and military organizations． 　　These standards describe configuration management plans，documentation，specification practices，software comparisons，etc．Other standards which are currently under development include standards for reliability，measurement，the use of Ada as PDL[6]，software testing and others．Bransta d and Powell（1984）describe both existing and planned software standards as well as discussing standardization in more general terms． 　　The problem with national software standards is that they tend to be very general in nature. This is inevitable as，unlike hardware，we are not yet capable of quantifying most software characteristics．Effective quality assurance within an organization thus requires the development of more specific organizational standards． 　　Of course，the problem which arises in developing software standards for quality assurance and which makes the assessment of the level of excellence of a software product difficult to assess is the elusive nature of software quality．Boehm et al．（1978）suggest that quality criteria include but are not limited to： Economy　　　　Correctness　　　Resilience Integrity　　　　　Reliability　　　　Usability Documentation　　Modifiability　　　Clarity Understandability　 Validity　　　　　Maintainability Flexibility　　　　　Generality　　　Portability Interoperability 　　Testability　　　　Efficiency Modularity　　　　Reusability 　　Exactly how some of these criteria may be quantified is not clear．Furthermore，as Buckley and Poston（1984）point out，parts of this definition may have no value for a particular product．It may be possible to transfer a system from a microcomputer to a large mainframe but this is often a nonsensical thing to do．Assessment of software quality thus still relies on the judgement of skilled individuals although this does not mean that it is necessarily inferior to quantitative assessment．After all，we cannot assess a painting or a play quantitatively yet this does not preclude a judgement of its quality． 　　Within an organization，quality assurance should be carried out by an independent software quality assurance team who reports directly to management above the project manager level．The quality assurance team should not be associated with any particular development group but should be responsible for quality assurance across all project groups in an organization． The activity of quality assurance involves sitting in on design reviews[7]，program walkthroughs，etc. ，and reporting on the overall quality of the product as it is developed．It also involves checking that the finished product and its associated documentation conform to those standards which exist．The quality assurance team may also assess if the different representations of a product（requirements，design，code）are consistent and complete． 　　Notice that quality assurance is not the same as system testing．It is the development or testing team’s responsibility to validate the system，with the quality assurance team reporting on both the validation and the adequacy of the validation effort．This naturally involves quality assurance being closely associated with the final integration testing of the system． Software quality assurance is now an emerging subdiscipline of software engineering[8]．As Buckly and Poston point out，effective software quality assurance is likely to lead to an ultimate reduction in software costs．However，the major hurdle in the path of software management in this area is the lack of usable software standards．The development of accepted and generally applicable standards should be one of the principal goals of research in software engineering． NOTES [1] carried out... 分词短语修饰activities。 [2] with quality assurance... development介词with引导的独立分词结构，起补充说明的作用。 [3] 主句谓语是consists of，其宾语为分词短语修饰的procedures，techniques，and tools。 [4] of course：插入语，译为“当然”。 [5] 此句包括两个定语从句：第一个定语从句which defines中which指representation；第二个定语从句which the developed修饰performance，robustness，organization。 [6] Ada语言（一种程序设计语言，以Agusta Ada Byron命名）；PDL：程序设计语言。 [7] sitting in on design reviews：列席设计评审会议。 [8] emerging subdiscipline of... ：……的新兴分支。 KEYWORDS software quality assurance    软件质量保证 software standard     软件标准   :    　　软件质量保证活动与软件生存周期各阶段的验证和有效性确认活动紧密关联。事实上，在许多组织中这些活动没有明显的区别。尽管如此，质量保证实际上与其他验证和有效性确认活动相差甚远，质量保证是一个管理功能，而验证和有效性确认是软件开发过程的一部分。 　　Bersoff（1984）给出了软件质量保证的恰当定义：质量保证由在产品开发周期中专业人员要确保产品达到或超过某些预先设定的标准所要用到的那些过程、技术和工具所组成。如果没有具体的规定性的标准，质量保证则需要保证产品达到或超过工商业可接受的优良性能的最低标准。 　　当然这是一种相当笼统的定义。它首先指出软件标准可以建立；其次软件产品的优良程度可以评测。 　　软件工程项目标准的开发是一个非常困难的过程。一个标准是一个产品的某种抽象表示，它定义了被开发产品必须达到的最低性能、健壮性、结构等。在写此文章时，一些软件产品标准已经由IEEE，ANSI和一些军事机构制定了。 　　这些标准描述了配置管理计划、文档、实施、软件对照等。其他一些处于开发阶段的标准包括可靠性、测量方法、Ada用作为程序设计语言、软件测试和其他方面的标准。Bransta和Powell（1984）描述了已有的和已规划的软件标准，用更概括的语言讨论了标准化问题。 　　软件的国家标准问题在于这些标准过于笼统，这是必然的，因为不像硬件，我们至今尚不能将大多数软件特性进行量化。因此有效的质量保证就要求开发更多特定的组织标准。 　　当然，为质量保证而开发软件标准所带来的问题及软件产品的优良程度难于评估是软件质量难以把握的本质。Boehm等人（1978）提出的质量准则包括但不局限于： 　　经济性　　　　　正确性　　　　　弹性 　　完整性　　　　　可靠性　　　　　可使用性 　　文档　　　　　　可修改性　　　　明晰性 　　易理解性　　　　合法性　　　　　可维护性 　　灵活性　　　　　通用性　　　　　可移植性 　　互操作性　　　　可测试性　　　　效率 　　模块性　　　　　可重用性 　　如何精确量化其中的某些准则尚不清楚。而且，正如Buckley 和 Poston（1984）指出的那样，此定义的某些部分对特定产品也许毫无价值。把一个系统从一台微机移到一台大型机上是可能的，但这样做往往是毫无用处的。因此，软件质量的评估仍然依赖于熟练的个人判断。尽管这并不意味着此方法一定比定量评估差。尽管我们不能定量地评价一幅画或一场演出，但这毕竟不能阻止对其质量的判断。 　　在一个组织内，质量保证应由一个独立的软件质量保证小组来实施，该小组直接向项目经理层之上的管理层报告。质量保证小组不应与任何开发小组有联系，但要对本组织中所有的项目组的质量保证负责。 　　质量保证活动包括旁听设计复审、程序走查等，并报告开发过程中产品的整体质量。质量保证也包括检查已完成产品及其有关的文件说明是否与现有标准一致。质量保证小组也可以评估一件产品的不同表示方式（需求、设计、代码）是否一致和完备。 　　注意，质量保证不同于系统测试。系统有效性确认是开发或测试小组的责任，而质量保证小组要报告确认和确认工作是否充分。这自然意味着质量保证与系统最后阶段的综合测试有着密切的联系。 　　软件质量保证正成为软件工程的一个新兴分支。正如Buckley 和Poston所指出的，有效的软件质量保证很可能导致软件费用的最终降低。然而，在这一领域中软件管理的最主要障碍是缺乏适用的软件标准。为人们所接受和普遍适用的标准的开发应成为软件工程研究的一个主要目标。 软件需求模式之领域和基础架构 　　一些类型的需求依赖于基础架构，就像错误！未找到引用源。错误！未找到引用源。中“错误！未找到引用源。“中讨论的。需求模式使我们有机会确定一种类型的需求所依赖的基础架构，而不必为某一个需求考虑。而且我们可以进一步讨论每一个基础架构——也就是当为系统需要的基础架构定义需求时必须记住的。但是它不可能非常详细，也不可能针对实际的需求，因为每个组织，每个系统的不同要求，会使需求差别极大。为了清楚起见，它们被称作基础架构概述。 　　不能指望让每一个需求模式描述它需要的任何基础架构，这个解释的责任被给予了模式所属的领域。这是因为每个基础架构一般都会被领域中的多个模式使用。为了避免重复，每种基础架构只在一个领域中描述。本书中的每一章的模式中包含一节关于该领域的基础架构。本书讨论了三个基础架构：信息存储（错误！未找到引用源。错误！未找到引用源。），用户界面，以及报表（都在错误！未找到引用源。错误！未找到引用源。）。这几个关键概念的相互关系如图所示。 Domain: 领域 　　Infrastructure: 基础架构 　　Requirement Pattern: 需求模式 　　Depends Upon: 依赖 　　图 3‑2领域，需求模式，以及基础架构之间的关系 　　需求模式可以自由使用其他领域中的基础架构。但是最好避免相互依赖，所以如果一个领域依赖另一个领域，那么后一个领域就不应该依赖前一个领域——如果可以避免的话。一个基础架构也可以依赖另一个基础架构。 　　基础架构概述应该说些什么呢？它的角色是指导和建议如何定义一个特定系统的基础架构的需求，提出需求需要覆盖的主题。最少，它应该陈述系统需要基础架构提供什么：它存在的目的是什么，它的主要功能。有些问题有很明显的替代解决，概述应该避免做判断。 　　每个基础架构概述分成下列小节： 　　1. 目的解释基础架构存在的理由，以及扮演的角色。 　　2. 调用需求关于系统与基础架构如何交互的需求定义的建议——基础架构必须提供这些功能给系统——以及系统期望的其他的能力（比如访问控制）。需要的功能可以被看作是基础架构提供给调用者的接口。 　　3. 实现需求为了使基础架构站得住脚所需要的一些特性的想法（例如，查询，维护和配置功能）。这些是比较简短的，只是在定义基础架构时提醒一些需要考虑的可能的主要功能域。 　　例如，对于报表基础架构，调用需求可能是很简单：只是让系统请求运行一个选定的报表的功能。而另一方面，实现需求则相当多，包括交付报告给用户的各种方式的复杂性，其他请求报告的方式，设计报告，等等。（这些主题在错误！未找到引用源。错误！未找到引用源。进一步讨论。）以建造房屋类推，我们需要的基础架构之一是电力供应。这种情况下，调用需求是每个屋子需要多少插座，实现需求处理的是看不见的部分，像是与电网的连线，遵守建筑质量法。 软件项目开发实践中需要积累哪些知识 我们都知道在实践中学习积累的重要性，那么在应用软件的开发项目中，我们应该注意学习积累哪些知识呢？ 　　常常看到一些程序员对某些软件开发技术和理论的执著，也常常听到一些程序员谈论某某项目的技术含量的话题。软件专业开发技术，作为程序员的立身之本，受到这样的厚爱是无可厚非的。但是软件作为一种多种知识集成的载体，我们不能只把眼光盯在专业的开发技术上，还应该看到其中包含的丰富软件应用领域的业务知识、开发过程中的控制管理知识，以及与客户同事之间的交流方式和手段，这些都应该成为我们在日常的开发过程积累的素材。 　　从项目实践中学习软件专业开发技术，是很容易被开发人员接受并在项目开发过程中加以关注和积累的，但是项目中的业务知识往往被大家所忽略，因为这些东西似乎与开发人员无关，其实大错特错了。考试,大提示就曾经历过这样的一个项目，项目中应用的开发技术大家都很熟悉，但是应用的业务领域都很陌生，在项目开始的初期对项目中的业务知识和术语进行了一些了解，但是由于业务流程和数据关系复杂，着实让我们吃了很多苦头不说，首次提交的成果物根本就满足不了客户的要求。现在回想起来还心有余悸。如果当时我们对业务都很熟悉的话，我们就可以更多的从客户应用的角度去思考问题，设计程序结构，解决客户问题了。少走很多弯路不说，开发过程也不回异常艰苦。 　　在开发实践中，我们在提高专业技能的同时，一定要注意软件中所包含的业务知识的积累，久而久之，我们很自然的就会把软件专业知识和行业业务知识结合到一起，在项目开发过程中不但能够游刃有余，而且还可以减少跟客户的沟通障碍，想客户之所想，为客户提供更好的软件解决多方案。 软件系统与软件系统之间的集成交互问题 可能写得有些乱，希望能谅解，同时我整理的思想，希望能给您带来一些启发或者帮助。 　　我们假设一个国际化的大公司里，有来自多个国家的员工，这些员工又工作在不同的部门里，负责不同的任务。 　　首先： 　　1. 这些人可能是白人，也可能是黑人，也可能是黄皮肤的我们，这就像我们软件开发里的语言一样，有的是.NET体系，有的是JAVA体系的。所以不太可能要求一个公司里的人必须全部是黄皮肤的，或者是某个民族的，那就是歧视种族的问题了，通过这个例子我想说一下，没必要非是.NET或者是JAVA必须是你死我活，我以前在这个问题上犯过严重错误，现在终于想通了。 　　【.NET、JAVA并不是非要你死我活】 　　2. 对于一个规范的公司来讲，每个人的分工是很明确的，例如财务就是干啥的，人力资源有是干啥的，他们分工很明确，不可能是一个人啥事情都干了，很容易干不好，或者干不专业。对我们开发人员来讲，就是意味着我们的某个系统，应该有个明确的功能定位，应该有个明确的分工，不太可能某个系统是万能的，也就不存在多个系统之间的集成问题所在了。 　　【分工就乱，集成就更乱了，甚至是不可能集成了】 　　3. 规范的公司，都应该有些制度，不应该是财务管招聘，人事是管财务报表，应该是哪个部门做什么事情，对什么事情负责，那个部门是哪些数据的权威来源，例如，我们登录系统的帐号，应该是人事部门管理，我们的公司的财务报表应该是从财务部门获取，不应该是每个部门都有独立全套的数据，应该是负责他该负责的部分，说白了，还是跟上面的2有些类似，分工明确，责任明确。 　　【重复的数据，以哪个来源为标准依据】 　　4.部门与部门的沟通，员工与员工的沟通的，我们国家政府部门之间沟通，都用标准的公文形式，这也是个沟通方式，沟通可以是书面的，也可以口头的，这个类似于我们到底用 WebServeric、Remoting、WCF等一样，沟通还可以用英文、中文或日文，只要这两个互相沟通的员工能说清楚就可以了，互相能读懂就可以了，事情能办理好了。 　　【标准接口，有输入输出，例如公文能发出去另一方还需要能接收公文】 　　其次： 　　对现实中的软件系统之间的交互集成的理解，先不谈Biztalk、EAI等，那不是我的思想，那需要花费巨资才能购买。 　　1. 我们经常能实现的系统之间的交互，通过分析底层的数据库结构，然后适当的进行添加触发器等机制，可以完成系统之间的数据交互，这个虽然不是好方法，但是也是迫不得已的方法，不用修改程序代码。 　　2. 我们可以直接利用应用系统的页面，将数据进行导入导出操作，直接导入到另外一个系统，最理想的状态是，这2个系统最起码都有导入导出功能，这样避免了同样的数据在2个系统中重复录入的罪孽。 　　所以，现在开发的系统，都应该有批量导入导出功能，否则，不算是一个开放的系统。但是这个有个不好的地方是，也是严重的缺陷是，都是要人工进行干预，需要在两个系统之间奔波，也是很辛苦的事情。 　　3. 最理想的状态是，在应用程序之间能互相调用，用户只在一个系统里录入，另一个系统将在被后台自动调用。这时就是需要2个系统都有规范的接口定义，可调用的公开方法及手段。现在大部分公司都忽视这部分的要求，以后应该是越来越重视这部分的工作。应该成为软件验收的重要功能指标之一了，现在很多公司里，同样的数据需要重复录入的问题很严重，甚至是电子化没有解放我们，而是越电子化，我们越变成了电脑软件的奴隶，需要将同样的数据，在不同的软件里录入，悲哀啊，最可怜的是那那些最底层的员工，让他们录入数据，他们必须得录入，虽然很反感，没办法啊，领导的命令下来了。 　　大家开发的系统都应该有可编程接口，可进行数据录入、调用核心业务处理流程，这样我们的政府、企业信息化会更顺利，大家也不会排斥上多个IT系统了，现在推IT系统也很难，人家就怕重复录入数据，不是怕花钱。 　　最近在杭州临安做项目，看到银行的电子转账程序，可以将需要转账的数据，类似Excel一样，批量的复制粘贴，若是一个个人必须通过页面输入，那这个软件真的难用得要命了，人家有一个功能，可以批量导入或者批量复制粘贴，可以从另一个系统导入数据或者从另一个系统批量复制数据，然后直接粘贴到这个类似Excel的页面里就可以，用户不会觉得很繁琐，复制粘贴一下就可以，甚至不用导入导出了，感觉很好用的，我们开发的系统也应该多多借鉴。 　　将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情。 软件体系结构与软件架构解析 　　软件体系结构与软件架构的中文翻译都是英文Software Architecture。两者都使用一样的定义，如IEEE的“一个系统的基础组织，包含各个构件、构件互相之间与环境的关系，还有指导其设计和演化的原则。”[IEEE-2000] 为了找到两者的区别，得先从应用的环境入手。 ① http://www-128.ibm.com/developerworks/cn 　　② http://www.miscrosoft.com/china 　　③ google.com 采用精确匹配。“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 　　④ baidu.com 采用精确匹配。“架构师”改为“软件架构师”，“架构设计师”改为“软件架构设计师”减少领域差异 　　⑤ http://www.cnki.net/index.htm采用精确匹配。中国期刊全文数据库（2000-2007） 结果表明，在软件开发者和软件应用者来说，倾向于使用“软件架构”，在一定程度上接受“软件体系结构”。大家对软件架构的设计人员，“架构师”得到广泛的认同。对于学术界，普遍使用“软件体系结构”，对架构师几乎没有关注。Software Architecture是一个实践性非常强的领域，统计表明理论和实践的鸿沟还是存在的。 　　其次，我们从词源探讨“体系”“结构”“架构”的解释[字典-2001]。 　　体系：若干事物互相联系而构成的一个整体。例思想～ | 工业～ 　　结构：①建筑物承受重量和外力的部分及其制造。按材料分有钢结构、木结构、砖石结构、框架结构、砖混结构等。按形式分有悬索结构、拱结构等。②构成整体的各个部分及其结合方式。例经济～│文章～。③文艺作品的内部构造。即作品的各部分（包括内容和形式）之间有机的组织联系。 　　架构：①建造；构筑。②框架；支架。③比喻事物的组织、结构、格局。例市场～│故事～庞大 　　通过以上分析，我们不难看出学术界为什么用“软件体系结构”。首先，体系结构的中文定义完全符合IEEE等的定义。强调整体与部分，部分与部分的关系；研究系统构成的