文理学院软件工程要点.doc

第一章 软件工程介绍1.软件的双重作用。作为一个产品，它显示了由计算机硬件体现的计算能力，显示的是一个可由本地硬件设备访问的计算机网络体现的计算潜力。软件扮演者信息转换的角色：产生、管理、查询、修改、显示或传递各种不同的信息。软件又是生产产品的载体，提供了计算机控制、信息通信以及应用程序开发和控制的平台。2.软件工程：一个包含过程、一系列方法和工具的框架。3软件人员面临的问题：为什么软件需要如此长的开发时间，开发成本居高不下，交付前无法找到所有错误，维护需要高昂的时间和人力代价，开发和维护过程难以度量。4.软件和硬件不同的特性：1、软件是设计开发的，而不是传统意义上生产制造的。2、软件不会“磨损”，但存在退化。3、整体向着基于构建的模式发展，但多数仍是按客户需求定制的。5、软件的7大类：1.系统软件。2.应用软件。3、工程科学软件。4、嵌入式软件。5、产品线软件。6、web应用软件。7、人工智能软件。6、软件新的挑战：遍在计算、网络资源、开源软件、新经济。你无法预测未来，但可以准备未来。7、什么是软件：1、指令的集合，2、数据结构、3、可用的文档8、遗留软件发生系统演化的原因：1、软件需要修改其适应性、2、根据新的业务进行升级、3、软件必须扩展以具有和更多现代系统和数据库的协作能力，4、软件必须进行改建以适应多样化的网络环境。9、软件神话：1、管理神话。软件项目经理依赖信条，减轻提高软件进度和质量的压力。如开发宝典、增加人员、软件外包。2、用户神话。开发小组没有和用户进行有效沟通，导致没有达到用户期望。如没有详细了解就开始写程序，认为软件容易适应变更。3、从业者神话：软件开发者深信各种神话，旧的方式根深蒂固。10、软件项目的开始来源于业务需求。程序纠错、适应新环境、扩展功能、开发新产品。11、30年来软件发展的规律：1、持续变化规律，2、复杂性增长规律，3、自我调控规律，4、组织稳定性守恒规律，5、保证通晓性规律，6、持续增长规律，质量衰减规律，7、反馈系统规律。第二章 过程综述1、软件过程：软件开发过程中所遵循的路线图（一系列可预测的步骤）就称为软件过程。2、IEEE软件工程定义：软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在（1）中所述方法的研究。3、软件工程是一种层次化的技术：自顶向下：工具、方法、过程、质量关注点。软件工程的根基在于质量关注点。4、过程框架：沟通、策划、建模、构建、部署。5、软件工程的通用框架的普适性活动：1、软件项目跟踪和控制，2、风险管理，3、软件质量保证，4、正式技术评审，5、测量，6、软件配置管理，7、可复用管理，工作产品的准备和生产。6、敏捷过程模型强调可操作性和可适应性，尤其对Web应用开发很适用。各种软件过程的共同目标，机构建符合用户要求的高质量软件。7、能力成熟度模型。是一个全面的过程元模型，描述了成熟软件过程应该具备的特定目标、实践和能力。当软件开发到不同的过程能力和成熟度水平时，该模型用来预测所开发的系统和软件工程能力。5级：0不完全级、1已执行级、2已管理级、3已定义级、4已定量管理级、5优化级。CMMI定义了每个过程的特定目标，以及为达到特定目标所需的特定实践。特定实践将特定目标细化成一组过程相关的活动。8、过程模式提供了一个模板，即一种描述软件过程中重要特征的一致性方法，通过模式组合，可以定义满足项目需求的开发过程。9、软件过程评估：软件ISO9001:2000,采用“计划-实施-检查-行动”循环，将其应用于软件项目的质量管理环节。10、PSP（个人软件过程）。定义了5个框架活动：策划、高层设计、高层设计评审、开发、后验。遗憾的是，PSP没有被业界广泛采纳，其原因更主要的在于人的本性和软件开发组织的惯性，而非PSP方法本身的好坏。11、TSP（团队软件过程）。目标是建立一个能自我管理的项目团队，团队能自我组织进行高质量的软件开发。定义了6个框架活动：项目启动、高层设计、实现、集成、测试以及后验。第三章 过程模型1、瀑布模型。工作以线性的方式进行，又称为经典生命周期，它提出了一个系统的、顺序的开发方法，从用户需求规格说明开始，通过策划、建模、构建、和部署的过程，最终提供一个完整的软件并提供持续的技术支持。2、增量模型。以迭代的方式运用瀑布模型。随着时间推移，增量模型在每个阶段运用线性序列，每个线性序列生产出一个软件的可交付增量。和原型不同，增量模型每个增量都提交一个可交付的产品。3、RAD模型。快速应用程序开发是一种侧重于短暂的开发周期的增量软甲过程模型。RAD是瀑布模型的高速变体，通过基于构建的方法实现快速开发。沟通来理解软件的特征，策划确保多个团队并行工作，建模包括三个阶段业务建模、数据建模和过程建模。构建运用已有的构件技术并用代码自动生成技术，部署为以后的迭代建立基础。不足：1、大量的人员，2、开发者和客户如果没有为短实践内急速完成做好准备，通常为失败，3、需要合理的模块化，否则构建建立会有很多问题，4、不适合高性能，5、高风险不宜采用RAD。4、原型模型。快速构建一个系统，来挖掘用户需求，然后丢弃。用“口香糖和包装带”搭成，低效的算法仅仅为了证明系统的能力。5、螺旋模型。结合了原型的迭代性质和瀑布模型的系统性和可控性特点。随着演进过程的开始，从圆心开始顺势针方向，执行螺旋上的一圈表示的活动。每次演进都要考虑风险，每个演进过程都要标记里程碑。螺旋模型应用在计算机软件的整个生命周期。是开发大型系统的理想方法，可以有效的应对风险。6、协同开发模型。有时候叫协同工程，可以表示为一系列框架活动、软件工程动作和任务以及相应的状态。协同过程模型定义了一系列事件，这些事件将出发软件工程活动、动作或状态转换。协同过程模型可用于所有类型的软件开发，能提供项目当前的状态图。7、专用过程模型。应用面较窄，只适应于某些特定的软件工程方法。1、基于构建的开发能够做到软件复用，带来极大收益。2、形式化方法模型的主要活动是生成计算机软件的数学规格说明。使用形式化方法，歧义性问题、不完整问题、不一致问题都容易被发现和改正，不是依靠特定的评审，而是应用分析的方法。3、面向方面的软件开发（AOSD）为定义、说明、设计和构建方面提供过程和方法，是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。8、UP。统一过程是一种“用例驱动、以架构为核心，迭代并却增量”的软件过程。尝试着从传统软件过程中挖掘最好的特征和性质，认识到于客户沟通以及从用户的角度描述系统并且保持一致性的重要性，它建立了一个迭代的、增量的过程流，提供了一种演进的特性。起始、细化、构建、转化和生产5个阶段。UP的起始阶段包括沟通和策划，定义软件的需求，提出系统的大致框架，并制定开发计划，以保证开发具有迭代和增量的特性。细化阶段包括沟通和建模活动。细化阶段扩展了起始阶段定义的用例，并扩展体系结构以包括软件的5种视图：用例模型、分析模型、设计模型、实现模型和部署模型。构建阶段于通用软件过程中的构建活动相同，构建采用体系结构模型作为输入，开发系统构建，使最终用户能够操作用例。转化阶段包括通用构建活动的后期活动以及部署活动。软件被提交最终用户进行beta测试，并发布支持信息（手册、问题解决指南及安装步骤）。转换阶段结束时，软件增量称成为可用的发布版本。UP的生产阶段和通用过程的部署活动一致。在该阶段，监控软件持续使用，提供运行环境的支持，提交缺陷报告和变更请求。5个阶段并不是顺序的进行，而是阶段性的并发进行。第四章 敏捷过程1、敏捷软件工程。它是哲学理念和一系列开发指南的综合，这种哲学理念推崇让客户满意和软件尽早增量发布。开发方法强调超越设计和分析的发布及开发人员和客户之间主动和持续的沟通。是类软件工程，保留了基本框架活动，但将其缩小到推动项目组朝着构建和交付发展的最小任务集。2、敏捷开发可以带来多方面好处，但它并不适用于所有的项目、所有的方面、所有的人和所有的情况，它不完全对立于传动软件工程实践，也不能作为超越的哲学理念而应用于所有软件工作。普遍存在的变化是敏捷的基本动力。3、敏捷联盟的12条原则。1、尽早交付有价值的软件来让顾客满意。2、在后期也欢迎变更，利用变更来为客户创造竞争优势。3、交付的时间间隔越短越好。4、业务人员和开发人员必须天天在一起。5、围绕受激励的个人构建项目。6、最有效的信息传递方式是面对面交谈。7、可工作软件是进度的首要度量标准。8、提倡可持续的开发速度。9、关注优秀的技能和好的设计。10、简单是必要的。11、好的架构和设计出自于自组织团队。12、每隔一定时间，反省工作，调整行为。4、解决不可预测的过程（需求、程度、计划）的答案在于过程的自适应性。5、敏捷开发团队的成员必须具备的特点：1、基本能力。2、共同目标、3、精诚合作，4、决策能力，5、模糊问题解决能力，6、相互信任和尊重，7、自我组织。6、XP。XP适用面向对象方法作为推荐的开发范型。XP包括了策划、设计、编码和测试4隔框架活动的规则和实践。策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”，XP团队成员评估每一个故事并给出以开发周数为度量单位的成本。设计严格遵循KIS原则，适用简单而不是复杂的表述。鼓励适用CRC卡来组织相关的对象和类，鼓励重构。编码一个关键概念是结对编程。两个人面对同一台计算机共同为一个故事开发代码。实施中两个人担当的角色略有不同。测试。在编码开始之前建立单元测试是XP的关键因素，所建立的单元测试应当适用一个可以自动实施的框架，易于重复执行，这种方式支持代码修复后的回归测试策略。7、敏捷过程之自适应软件开发。可作为构建复杂软件和系统的一项技术，基本概念着眼于人员协作和团队自我组织。ASD生命周期包含思考、协作、学习。思考过程中，启动项目并完成自适应循环策划。在协作中，受激励的人员以超越器聪明才智和独创的方式共同工作，人员间要相互信任。在学习中完成构建实现和测试。8、敏捷开发过程之动态系统开发方法。是一种提供“通过在可控项目环境中适用增量原型开发模式完全满足对时间有约束的系统的构建和维护的敏捷软件开发方法。DSDM方法的每一个迭代都遵循80%原则，每一个增量只完成能够保证进入下个增量的工作，剩余的细节可在知道更多的需求并提交同意变更之后完成。包括：可行性研究、业务研究、功能模型迭代、设计和构建迭代、实现。9、敏捷建模（AM）认为建模对于所有的系统都是必要的，但是模型的复杂度、类型和规模必须根据所构建的软件来调节。第五章 软件工程实践综述1、实践。实践是软件计划和开发时需要考虑的方方面面，包括概念、原则、方法和工具等。2、实践的精髓。理解问题、计划解决问题、实施计划、检查结果的精确度。3、实践的核心原则：1、存在价值，2、保持简洁，3、维护视图，4、生产者要让消费者理解，5、面向未来，6、计划复用，7、认真思考。4、沟通实践原则：1、倾听，2、有准备的沟通，3、需要有人推动，4、最好当面沟通，5、记录所有决定，6、保持通力协作，7、聚焦并协调话题，8、采用图形表示，9、继续前进原则，10、谈判双赢原则。5、策划活动包括一系列管理和技术实践，可为软件开发团队定义一个便于他们向着战略目标和战术目标前进的路线图。原则1、理解项目范围，2、客户参与策划，3、采用迭代计划，4、给予已知估计，5、计划考虑风险，6、保持脚踏实地，7、调整计划粒度，8、制定计划确保质量，9、描述如何适应变化，10、经常跟踪、校正计划。6建模实践。分析模型通过信息域、功能域、行为域来描述软件，表达客户的需求。设计模型表述了可以帮助开发者高效开发软件的特征：架构、用户界面、及构建细节。分析模型原则：1、描述并理解问题的信息域，2、确定软件的功能，3、描述软件的行为，4、模型必须以能揭示分层细节的方式分解开来，5、分析应从本质信息转向实现细节。设计模型原则：1、可追溯到分析模型，2、关注系统的架构，3、数据设计同功能设计同等重要，4、必须设计接口，5、界面必须符合用户要求，6、功能独立的构建级设计，7、松散耦合，8、模型尽可能易于理解，9、设计应迭代式进行。7、构造活动包括编码和测试。8、部署包括三个动作：交付、支持和反馈。原则：1、客户对软件的期望必须得到管理。2、完整的交付包应该进行过安装和测试，3、技术支持必须在软件交付之前就定下来，4、为最终用户提供说明材料，5、有缺陷的软件应先改正在交付。第六章 系统工程1、计算机的系统：组织在一起通过处理信息来实现预定目标的要素集合或排列。2、计算机系统要素：软件、硬件、人员、数据库、文档、规程。3、系统工程开始于“全局视图”。分析业务领域以建立基本的业务需求，聚焦领域视图，分析每个系统要素。将要素分成多个工程构建，按相应的工程规范来处理。4、业务过程是一种系统工程方法。产品工程是从系统分析开始的系统工程，确认用户需求，确定经济和技术可行性，将功能和性能分配到各工程构建中。第七章 需求工程1、需求工程帮助软件工程师更好的理解他们将要解决的问题。其中所包含的一系列任务有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何与软件交互。通过需求分析可以得到的产品有：用户场景、功能和特征列表、分析模型或功能说明。2、需求工程（RE）是一个软件工程动作，开始于沟通并持续到建模。3、RE为以下工作提供了良好的机制：理解用户需要什么，分析要求，评估可行性，协商合理的方案，无歧义的详细说明方案，确认规格说明。4、需求工程执行的7个活动：起始、导出、精化、协商、规格说明、确认和管理。规格说明是需求工程完成的最终工作产品，它将作为软件工程师后续活动的基础，它描述了一个基于计算机系统的功能和特性，以及那些将影响系统开发的约束。5、QFD。质量功能部署是一种将客户要求转化为软件技术的技术。QFD目的是最大限度的让客户从软件工程中感到满意。它确认三类需求：正常需求、期望需求、令人兴奋的需求。6、需求工程导出的共作产品包括：1、必要性和可行性陈述，2、系统或产品范围的说明，3、客户、用户及共利益者的列表，4、系统技术环境的说明，5、需求列表及每个需求适用的领域限制，6、一系列适用场景，7、任何能够更好定义需求的原型。7、分析模型的元素：基于场景的元素，基于类的元素，行为元素，面向信息流的元素。8、分析模式：在特定领域内表示某些在建模时可以被重复使用的东西（如类、功能、行为）。9、确认需求。当分析模型的每个元素都已创建时，需要检查一致性、是否有遗漏以及歧义性。模型所表现的需求由客户划分优先等级并组合成一个整体，该需求整体将实现为一系列软件增量并交付给客户。第八章 构建分析模型1、分析模型。分析模型使用文字和图表的综合形式以相对容易理解的方式描绘需求的数据、功能和行为，更重要的是，可以更直接的评审它们的正确性、完整性和一致性。2、基于场景的建模从用户的角度表现系统，面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示，基于类的建模定义了对象、属性和关系，行为建模描述了系统状态、类和事件在这些类上的影响。3、分析模型必须实现的三个主要目标：1、描述客户需要什么，2、为软件设计奠定基础，3、定义在软件完成后可以被确认的一组需求。分析模型在系统描述和设计模型之间建立桥梁。4、分析建模的方法。1、一种考虑数据和处理的分析建模方法被称为结构分析。2、第二种方法是面向对象的分析，这种方法关注于定义类和影响客户需求的类之间的协作方式。5、基于场景的建模使用UML分析建模，从开发用例、活动图和泳道图形式的场景开始。6、创建数据流模型，数据流图有助于软件工程师开发信息域的模型，并同时开发功能域的模型。7、CRC建模。CRC提供了一个简单的方法，可以识别和组织与系统或产品需求相关的类。CRC模型实际上师表示类的标准索引卡片的集合。这些卡片被分为三部分，顶部写类名，下面左侧列出类的职责，右侧部分列出类的协作关系。8、生成行为模型。CRC索引卡和其他面向对象模型表现了分析模型中的静态元素，行为模型表示系统或产品的动态行为，有状态图、顺序图。9、分析模型由4种建模元素构成：基于场景的模型、流模型、基于类的模型和行为模型。10、基于场景的模型从用户的角度描述软件需求。用例是主要的建模元素，还可以适用活动图说明场景，泳道图显示了处理流如何分配给不同的用户。流模型关注当数据对象通过处理函数转换时的流动。基于类的建模使用基于场景和面向流的建模元素中提取的信息确定分析类。前面三种分析模型元素提供了软件的静态视图，行为模型描述了动态行为。行为模型使用基于场景、面向流和基于类的元素作为输入，从整体上表现分析系统和类的状态。要做到这一点，要识别状态，定义导致类做出状态转移的事件，以及确认当转移完成时所发生的动作。状态图和顺序图是用于行为建模的UML表达方式。第九章 设计工程1、设计模型与分析模型（关注于必须的数据、功能和行为）不同，设计模型提供了软件数据结构、体系结构、接口和构建的细节。基于场景的元素、基于类的元素、面向流的元素和行为元素所表明的分析模型是设计任务的输入，最后将得到数据/类设计、体系结构设计、接口设计和构建设计。2、数据/类设计将分析模型转化为设计类的实现以及软件实现所要求的数据结构。体系结构设计定义了软件的主要结构元素之间的联系。接口设计描述了软件和协作系统之间、软件和使用人员之间是如何通信的。接口就意味着信息流和特定的行为类型。构建级设计将软件体系结构的结构元素变换为对软件构建的过程性描述。3、5种设计类。用户接口类、业务域类、过程类、持久类、系统类。设计类的4个特征：完整性和充分性，原始性、高内聚性、低耦合性。4、基于模式的设计可以复用那些在过去已经被证明是成功的设计元素。在针对某个特定的应用进行评估时，应将每个体系结构模式、设计模式或习惯用语分类、全面文档化和细致的考虑。框架作为模式的扩展，为某个特定领域内完整的子系统设计提供体系结构骨架。第十章 进行体系结构设计1、体系结构设计描述了建立计算机系统所需的数据结构和程序构建。它需要考虑系统采取的体系结构风格，系统组成构建的结构、性质，以及所有体系结构构建之间的相互关系。2、什么是体系结构。软件体系结构是指系统的一个或多个结构。结构中包括软件的构建，构建的外部可见属性以及他们之间的相互关系。体系结构并非可运行软件，确切的说，它是一种表达，是软件工程师能够（1）分析设计在满足需求方面的有效性，（2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案，（3）降低与软件构造相关联的风险。3、数据设计是在分析模型中定义的数据对象转化成软件构建级的数据结构，并且在必要时转化为应用程序级程度数据库体系结构。4、构建级的数据设计关注于那些被一个或多个软件构件直接访问的数据结构的表示。5、体系结构风格。一种体系风格就是一种加在整个系统设计上面的变换。它的目的就是为系统的所有的构建建立一个结构。对已有体系结构进行再工程时，强制采用一种体系结构风格会导致软件结构的根本性改变，包括对构建功能的再分配。每种风格描述一种系统类别，包括（1）一组构建完成系统需要的某种功能，（2）一组连接器，使构建间实现通信、合作和协调，（3）约束，定义构件成为一个系统，（4）语义模型，使设计者通过分析系统的构成成分的性质来理解系统的整体性质。6、体系结构风格的简单分类：（1）以数据为中心的体系结构，（2）数据流体系结构，（3）调用和返回体系结构，（4）面向对象体系结构，（5）层次体系结构。7、软件的体系结构模式定义了处理系统某些行为特征的方法。体系结构模式域：并发性、持久性、分布性。8、体系结构设计方法。建立软件的环境模型，并描述出软件所有外部软件接口，通过定义和求精实现体系结构的构建来描述系统的结构。这个过程不停的迭代，直到获得一个完整的体系结构。步骤：系统的环境表示，定义原始模型，将系统结构精化为构建，描述系统实例，9、软件体系结构待建造系统的整体视图，它描述软件构建的结构和组织、构建的性质以及构建之间的连接。软件构建包括程序模块和程序操作的各种数据表示，因此数据设计是软件体系结构设计的一个有机部分。体系结构关注与早期设计决策，并提供了考虑多个可选系统结构优点的机制。第十一章 构建级设计建模1、构件级设计定义了数据结构、算法、接口特征和分配给每个软件构件的通信机制。2、什么是构件。通常来讲，构件是计算机软件中的一个模块化的构造块。正式的讲，构件是系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列接口。3、基于类的构件基本设计原则。（1）开关原则，模块对外延具有开放性，对修改具有封闭性。（2）LISKOV替换原则，子类可以替换它们的基类。（3）依赖倒置原则，依赖于抽象，而非具体实现。（4）接口分离原则，多个用户专用接口比一个通用接口要好。（5）发布复用等价性原则，复用的粒度就是发布的粒度。（6）共同封装原则，一同变更的类应该合在一块。（7），共同复用原则，不能一起复用的类不能被分到一组。4、构建级设计指导方针：构建、接口、依赖合继承。5、内聚性。内聚性意味着构建或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。按内聚性的级别排序有：功能、分层、通信、顺序、过程、暂时、实用内聚。6、耦合性。通信和协作是面向对象系统中的基本要素，随着通信和协作数量的增长，系统的复杂性增长，测试和维护的难度加大。耦合是彼此联系程度的定性度量。构建级设计中，一个重要的目标就是保持低耦合。7、耦合分类：共用耦合、控制耦合、印记耦合、数据耦合、例程调用耦合、类型使用耦合、类型使用耦合、包含或者导入耦合、外部耦合。8、实施构件级设计步骤：1、标记出所有与问题域相对应的设计类，2、确定所有与基础设施域相对应的设计类，3、细化所有不能作为复用构件的设计类，在类或构件的写作时说明消息的细节，为每一个构件确定适当的接口，细化属性并且定义相应的数据类型和数据结构，详细描述每个操作中的处理流。4、说明持久数据源并确定管理数据源所需要的类。5、开发并且细化类或构件的行为表示。6、细化部署图以提供额外的实现细节。7、考虑每一个构件级设计表示，并且时刻考虑其他选择。9、根据所开发软件的特点，可以从两个不同的角度进行构件级设计。面向对象的观点注重细化来自于问题域和基础设施域的设计类。传统的观点细化三种不同的构件或模块：控制模块、问题域模块和基础设施模块。在这两种观点中，都需要应用那些导致高质量软件的设计原则和概念10、传统构件级设计需要充分表示出数据结构、接口和程序块的算法以指导编程语言源码的产生。为达到这一要求，设计者采用设计表示方法来表示构件细节，可以使用图形、表格或者文本格式。11、结构化编程是一种过程设计思想，它限制描述算法细节时使用的逻辑构造数量和类型。结构化编程的目的是帮助设计师定义简单的算法，因而易于阅读、测试和维护。第十二章 完成用户界面设计1、接口设计主要包括三个方面：（1）软件构件间的接口设计，（2）软件与除人以外的其他非人类信息生产者和消费者的接口设计，（3）人与计算机间的界面设计。2、设计原则：（1）置用户于控制之下，（2）减少用户的记忆负担，（3）保持界面一致。3、置用户于控制之下原则：（1）以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。（2）提供灵活的交互。（3）允许用户交互被中断或撤销。（4）允许定制交互。（5）使用户与内部技术细节隔离开来。（6）允许用户与出现在界面上的对象直接交互。4、减轻用户的记忆负担。（1）减少对短期记忆的要求。（2）建立有意义的缺省。（3）定义直观的快捷方式。（4）界面的布局应基于真实世界的象征。（5）以不断渐进的方式揭示信息。5、保持界面一致。（1）允许用户将当前任务放入有意义的环境中。（2）在应用系统家族内保持一致性。（3）如果过去的交互模型已经建立期用户期望，除非有不得已的理由，否则不要改变它。6、界面分析设计要考虑四种模型：用户模型，设计模型，心理模型，实现模型。7、用户界面设计迭代的框架活动：用户、任务和环境分析建模，界面设计，界面构造，界面确认。第十三章 软件测试策略1、 软件测试的目的是为了发现软件设计和实现过程中的疏忽所造成的错误。2、软件测试策略将软件测试用例的设计方法集成到一系列经周密计划的步骤中去，从而使软件构造成功的完成。任何测试策略都必须包含测试计划、测试用例设计、测试执行以及测试结果数据的收集与评估。3、测试策略具有一般特征。（1）为完成有效的测试，软件团队应该进行有效的、正式的技术评审。（2）测试开始于构建层，然后向外“延伸”到基于整个系统的集成。（3）不同的测试技术适用于不同的时间点。（4）测试由软件开发人员和独立的测试组执行。（5）测试和调试是不同的活动，任何测试都必须包含调试。4、传统软件体系结构的测试策略。4个步骤的螺旋模型。单元测试起始于中心，侧重于以源代码形式实现的每个单元（构件），向外一圈，就是集成测试，重点在于软件体系结构的设计和构造。向外一圈，就是确认测试，依据已建立的软件，对需求进行确认，最后是系统测试，将软件与系统的其他成分作为一个整体来测试。5、面向对象软件体系结构的测试策略。策略与传统是一致的，但方法不同。由小型测试走向大型测试。小型测试重点由单个模块测试转变为通信与协作的类的测试。6、测试完成的标准。永远在进行。但是经过实践验证的统计模型而言，1000个CPU小时无故障的概率大于0.995，那么就有95%的信心说经过了足够的测试。7、测试的指导原则。（1）量化的方式规定产品需求。（2）显示的陈述测试目标。（3）建立用户轮廓。（4）强调快速周期测试。（5）有效的技术评审。8、回归测试。每当加入一个新的模块作为集成测试的一部分时，软件发生变更，重新执行已经测试的某个子集，确保没有传播不期望的副作用。9、常用的调试方法：蛮力法、回溯法、原因排除法。10、几种有价值的系统测试。恢复测试、安全测试、压力测试、性能测试。第十四章 测试技术1、黑盒测试。了解已设计的产品所完成的指定功能，可以执行测试以显示每个功能是可操作的，同时查找在每个功能中的错误。2、白盒测试。了解产品的内部运行情况，可以执行测试以确保“所有齿轮吻合”，即内部操作依据规格说明执行，而且对所有的内部构件进行了充分测试。3、黑盒测试指在软件接口处进行的测试。黑盒测试检查系统的基本方面，很少关心系统的内部结构。白盒测试是基于过程细节的封闭检查，通过提供检查特定条件集和循环的测试用例，测试贯穿软件的逻辑路径和构件间的协作。4、白盒测试可以：（1）保证每一个模块中的所有独立路径至少被执行一次，（2）对所有的逻辑值均需测试真和假，（3）在上下边界和可操作的范围内执行所有的循环，（4）检验内部数据结构以确保其有效性。5、黑盒测试能发现以下类型的错误：（1）功能不正确或遗漏，（2）接口错误，（3）数据结构或外部数据库访问错误，（4）行为或性能错误，（5）初始化和终止错误。6、白盒在测试的早期执行，黑盒在测试的后期阶段。7、几种黑盒测试方法：基于图的测试方法、等价划分、边界值分析、正交数组测试。8、面向对象的测试与传统测试技术稍有不同。测试视角放宽以包括分析模型和设计模型的评审。另外测试的重点由子程序转向类，类的测试使用多种方法：基于故障测试、随机测试和划分测试。每种方法检查类中封装的操作，通过检查类的状态以确定是否存在错误。第十五章 产品度量1、软件质量是对明确陈述的功能和性能需求、明确记录的开发标准以及对所有专业化软件开发应具备的隐含特征的符合度。2、影响质量的因素：功能性、可靠性、效率、易用性、可维护性、可移植性。3、测度是产品或过程的某些属性的程度、数量、维数、容量或大小提供量化的指示。测量是确定测度的动作。度量是一个系统、构件或过程具有给定属性的量化测量程度。4、产品度量的作用包括（1）辅助分析模型和设计模型的评估，（2）提供过程设计和源代码复杂性的指示，（3）方便更有效测试的设计。5、测量的5个活动：公式化、收集、分析、解释、反馈。6、软件度量应具有的属性：简单的和可计算的、在经验上和直觉上有说服力、一致和客观的、单位与量纲的使用是一致的、编程语言独立性、高质量的反馈机制。7、产品度量全景：分析模型的度量、设计模型的度量、源代码的度量、测试的度量、维护的度量。8、面向对象系统的度量侧重于能应用于类于设计特征的测量：局部化、封装、信息隐藏、继承及对象抽象技术。这些特征使类具有唯一性。第十六章 Web工程1、Web工程是用来创建高质量Web应用的过程。采用“可靠科学的原则，工程化的原则和管理原则，以及规范系统的手段，以期获得高质量的基于Web的系统和应用的成功开发、部署和维护。”2、Web应用的属性：网路密集性、并发性、无法预计的负载量、性能、可得性、数据驱动、内容敏感性、持续演化、即时性、保密性、美学性。3、Web的应用类型：信息型、下载型、可定制型、交互型、用户输入型、面向事务型、面向服务型、门户型、数据库访问型、数据仓库型。4、WebE可以被描述成三层：过程、方法和工具/技术。WebE过程采用了敏捷开发思想，此开发思想强调“瘦”的、可以增量交付所建造系统的工程化方法。通过过程框架（沟通、计划、建模、构造和部署）同样适用于WebE。这些框架活动被精炼为一组适合每个项目要求的Web任务集合。（SQA，SCM,项目管理）也应用于所有的Web项目。5、Web工程的最佳实践。1、即时Webapp的一些细节是模糊的，也需要花时间去理解业务要求和产品目标。2、适用基于场景的方式来描述用户如何同WebApp交互。3、制定一个项目计划，即时这个计划很简短。4、不管将要构造什么，都应该花一些时间建模。5、对模型的一致性和质量进行评审。6、适用那些能够让你尽可能多的适用可服用的构建来构造系统的工具和技术。7、不要依赖早期用户的意见来调试WebApp。第十七章 开始一个WebApp项目1、“表达”用来确定WebApp的根本要求、用户期望的总体特性和功能以及开发的范围。“策划”就是必须明确要定义的事情，以建立工作流、进度表及项目进展中的跟踪工作。2、基于Web的系统和应用的表达描述了一系列Web工程活动，首先标识业务需求，进而描述WebApp的目标，定义主要特性和功能，进行需求收集，并开发分析模型。3、Web工程团队成员必须具备的技能：基于构件的软件工程、网络、体系结构设计和导航设计、internet标准/语言、人机界面设计、图形设计、内容布局及WebApp测试。扮演的角色有：内容开发者、Web出版者、Web工程师、业务领域专家、支持专家、管理者。4、组建团队的原则：应建立一系列的团队准则，必须有坚强的领导层、尊重个人的才能很重要、每个成员都应该负责任、要一直保持动力。5、Web外包。启动项目、挑选外包供应商、评估报价的正确性和估算的可靠性、理解项目管理程度、确定开发进度、管理范围。6、内部Web工程。理解范围、变更的维数和项目的限制，定义增量的项目策略，完成风险分析，进行快速估算，选择任务集（过程描述），制定进度表，建立项目跟踪机制，建立变更管理方法。7、Web工程度量的目的：（1）从技术角度提供了WebApp的质量指标。（2）提供了工作量估算基础，（3）从业务角度提供了WebApp成功的标识。第十八章 WebApp分析1、Web应用分析重点解决三个重要问题：（1）表达或处理的信息或内容是什么，（2）为最终用户提供的功能是什么，（3）当WebApp表达内容和执行功能时，它表现出来的行为是什么2、Web的需求分析包括三个主要任务：表达、需求收集和分析模型。3、Web分析模型是由信息驱动的，这些信息包含在应用系统开发的用例中。有4种分析活动：内容分析、交互分析、功能分析、配置分析。4、交互模型由4种元素组成：用例、顺序图、状态图、用户界面原型。5、功能模型描述2个处理元素：用户观察到的功能，分析类中的操作。6、配置模型详细说明服务器和客户端的硬件和操作系统环境。使用UML部署图。7、关系导航分析确定了分析模型中所定义的内容元素和功能元素之间的关系，并建立在整个系统中定义恰当的导航链接的需求。第十九章 WebApp设计1、WebApp设计主要包含6个步骤：内容设计、结构设计、美学设计、界面设计、导航设计、构件设计。2、WebApp设计的主要属性：安全性、可得性、可伸缩性、面市时间。L3、WebApp的设计目标：简单性、一致性、相符性、健壮性、导航性、视觉吸引、兼容性。4、界面设计描述了用户界面的结构和组成，包括屏幕布局的表示、交互方式的定义和导航机制的描述。5、美学设计也叫美术设计，描述了“外观和感觉”，包含颜色配置、几何布局、文本字号、字体和位置、图形的使用及相关的美学决策。一系列美术设计指导原则为设计方法提供了基础。6、内容设计为所有内容定义了布局、结构和外观轮廓，并建立了内容对象之间的关系。在内容设计时，首先对内容对象、它们之间的关联和关系进行描述。7、结构设计确定了WebApp的总体超媒体结构，并且包含内容结构和WebApp结构。内容的结构风格包括线性结构、网络结构、层次结构和网络结构。WebApp结构描述了使用基于Web的系统或应用达到业务目标的基础结构。8、导航设计描述了内容对象之间的导航流和为所有WebApp功能建立的导航流。通过描述一组导航语义单元来定义导航。每一个单元由导航路径、导航链接和节点组成。导航语法机制用于实现导航，导航也是语义描述的一部分。9、构件设计制定了实现WebApp功能构件所需要的详细处理逻辑。第二十章 WebApp测试1、 测试目标：发现WebApp的内容、功能、可用性、导航性、性能、容量及安全方面存在的错误。2、 WebApp质量维度：内容、功能、结构、可用性、导航性、性能、兼容性、互操作性、安全性。3、WebApp测试策略：1、对内容模型进行评审，以发现错误。2、对接口模型进行评审，保证适合所有的用例。3、评审设计模型，以发现错误。4、测试用户界面，发现表现机制或导航机制中的错误。5、对选择的功能构件进行单元测试。6、对贯穿体系结构的导航进行测试。7、在各种不同的环境配置下，实现WebApp，并测试对每一种配置的兼容性。8、进行安全性测试，试图攻击所处环境的弱点。9、进行性能测试。10、通过可监控的最终用户群对WebApp进行测试，对交互结构进行评估。