软件工程知识点总结(科大)

1、软件工程知识点总结(科大)简介第一篇：软件工程知识点总结(科大)1.计算机软件是一种特殊的逻辑产品，其为在计算机上运行的各种程序、数据及其说明程序的各种文档。 2.软件承担着双重角色，软件是一个产品，同时又是产品交付使用的载体。 3.软件测试目的，就是在系统交付客户之前能够发现（和改正）尽可能多的错误 4.白盒测试又称“玻璃盒测试”，白盒测试注重于程序控制结构。 5.黑盒测试也称为行为测试，黑盒测试注重于确认功能需求。 6.用户界面可以说是基于计算机的系统或产品的最重要的元素。如果界面的设计很糟糕，可能会严重的阻碍用户使用系统的计算处理能力。 7.一个弱的界面可能导致一个很好地设计和可靠实验的

2、应用的失败。 8.三个重要的原则指导有效的用户界面设计：置系统与用户控制之下、减少用户的记忆负担和保持界面一致。 9. 程序流程图 10.结构化程序设计：逻辑构成元素的顺序、条件和重复构成了结构化程序设计的基础。 顺序-实现了算法规约中的核心处理功能。 条件-允许根据逻辑情况选择处理的方式。 重复-提供了循环 11.图形设计符号：流程图和盒状图 12.程序设计语言pdl：结构化的英语或伪代码 13.构件级设计也称为过程设计，它在数据设计、体系结构设计和接口设计之后进行，其意图是将设计模型翻译为可以运行的软件。 14.构件级设计是使用某些能够容易翻译成源代码的中间表示来表示过程设计。 15.构件

3、级设计的目的是要保证不仅能够完成翻译任务而且能够不在开始时引入错误，即在过程设计中避免错误的产生。16.17. 18. 19. 应用cad系统 工程常用数学计算工具软件 体系结构设计 20. 数据字典21. 数据设计 22.软件体系结构提供了待建造软件系统的整体视图，其描述软件构件的结构、组织、性质、以及它们之间的联系 23.软件结构包括模块和程序操作的各种数据表示 24.数据设计是软件体系结构设计的一个有机组成部分 25.体系结构关注与早期设计决策，并提供了可选择的系统结构体制 26.设计概念：抽象 求精 模块化 27.设计原则：（10个原则） 设计过程不应该受“隧道视野”的限制 设计对于分

4、析模型应该是可跟踪的 设计不应该从头做起 设计应该缩短软件和现实世界中问题的“智力距离” 设计应该表现出一致性和集成性 设计的构建应该适合变更 设计的构建，应该使得即使遇到异常的数据、事件或操作条件时也能够平滑、轻巧地降级 设计不是编码，编码也不是设计 创建设计时就应该能够评估质量，而不是在事情完成以后 应该评审设计以减少概念性错误 28.软件设计的内容：数据设计 体系结构设计 接口设计 构件级设计 29.设计过程：设计过程的目标 评价设计质量的指导性原则 设计任务集合 30.设计时将建造的某种事物的有意义的工程表示。软件设计创建软件的表达或模型，提供了软件数据结构、体系结构、接口和软件构件的

5、设计细节-提供了软件系统实现所必须的工作基础。 31.对设计良好的软件而言，坚固是指程序不应含有任何妨碍其功能的缺陷，适用则是程序符合开发目标，赏心悦目意味着适用程序的体验是愉快的 32. 33.数据建模 1.数据对象描述-数据字典（名称别名何处使用如何使用 内容描述 补充信息）2数据建模（数据对象、属性和关系基数数据模型：实体关系图erd） 34. 35.分析建模的原则一.描述和理解问题的信息领域；二.定义软件将实现的功能； 三.作为外部事件的结果，描述软件的行为；四.通过问题的划分，描述信息功能和行为的模型，逐渐以层次的方式揭示细节。 36.分析建模的任务集合（评审需求扩展和细化用户的场景

6、数据建模功能建模） 分析建模使用文本和图表形式的组合，以相对容易理解的方式描绘数据、功能和行为的需求，并直接评审其正确性、完整性、一致性。37. 用户场景与分析建模 一.用户场景（use-case及其参与者开发use-case） 二.构件分析模型（数据建模 功能建模 行为建模）38.需求确认与规约（协商需求 确认需求 规约需求） 3940.软件需求的导出 一.质量功能部署（正常的需求期望的需求 令人兴奋的需求） 二.功能性需求与非功能性需求（功能性需求-描述系统为用户或其他系统提供的服务 非功能性需求-系统开发过程中必须遵守的约束：1.反映了软件的质量属性 2.约束了系统的环境和技术 3.约束

7、了项目计划和开发方法） 41.软件的需求诱导（需求诱导的原则：倾听 有准备的沟通需要有人推动最好当面沟通记录所有决定 ）（软件需求的过程启动）42.软件需求分析 软件需求分析的作用和目的（软件开发人员对软件需求分析认识的误区 缺乏可靠和有效的软件需求分析的后果需求分析是连接软件设计和构造的桥梁） 软件需求分析的工作活动1. 软件需求工程概述 1发现领域过程 理解客户需要业务领域和希望解决的问题 理解客户业务过程 获取业务领域的专业词汇 建模客户业务过程 2.领域分析 领域分析是软件工程师了解背景信息的过程 业务领域与领域专家 领域分析的目标 领域分析信息归档 3识别协作系统4.发现系统需求5.

8、将结果提交客户 2. 基于计算机的系统工程 1.1.基于计算机的系统 定义：元素的集合或排列，这些元素被组织在一起通过处理信息完成某些预定的目标2目标：支持某些业务功能或开发可以被销售以生产业务收入的产品。 2.系统元素包括软件、硬件、人员、数据库、文档、规程 3. 软件工程实践 1.软件工程实践的精髓 1.理解问题（交流和分析）2.计划解决方案（计划于建模软件设计）3.实施解决方案（构造代码生成）4.检查结果的精确度（构造与部署软件测试、质量保证、用户技术支持） 2.软件工程实践的核心原则包括存在价值、保持简洁、维护视图、生产者要让消费者理解 4. 软件工程过程模型，是指能够覆盖软件工程的过

9、程、方法和工具以及软件工程的一般阶段的开发策略。过程模型的选择待建造软件的特点，所采用的方法与工具、以及需要的控制和交付的产品。 1.瀑布模型2.增量过程模型增量模型、rad模型3.演化过程模型原型模型、螺旋模型4.面向对象软件工程过程模型统一软件开发过程 5. 软件工程过程：是一个为建造高质量软件所需要完成的任务的框架，是建造软件产品的一组活动及其结果。通用过程框架活动：1.交流项目启动、需求获取及其任务集合2.计划项目评估、进度安排、项目跟踪等3.建模分析模型和设计模型4.构造代码生成和软件测试5.部署产品交付、技术支持、用户反馈等及其相应的任务集合 6. 软件工程的定义：建立和使用一套合

10、理的工程原则，以便获得经济的软件，这种软件是可靠地，可以在实际及其上高速的运行。1.定义a：软件工程是：1.将系统化的、严格约束的、可量化的方法用于软件的开发、运行和维护，即将工程化应用与软件。2.在1中所述方法的研究。 2.定义b:软件工程是在成本、时间及其他约束条件下，通过对大型、高质量的软件系统的系统化的开发与演化，从而解决客户问题的过程。 7. 软件工程师由有创造力的,有组织的人在定义好的，成熟的软件过程中进行的，该过程适合于软件开发人员建造的产品和产品的市场需求。 8. 软件工程的定义：建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠地，可以在实际机器上高校地运行。

11、9. 软件开发的工程化:各种形式、各个应用领域的软件开发都需要工程化，即通过采用软件工程技术实现。 10. 由于软件产品的特殊性，软件工程从业人员的职业道德和行为准则显得更加重要。 11. 软件产品的分类方法：由软件产品的角度分类：通用软件产品、定制软件产品、嵌入式软件。由软件的应用领域：系统软件、应用软件、工程科学软件、嵌入式软件、产品线软件、web应用软件、人工智能软件、开放计算、网络资源、开源软件。 12. 计算机软件是一种特殊的逻辑产品，其为计算机上运行的各种程序、数据及其说明程序的各种文档。软件承担着双重的角色，软件是一个产品，同时又是产品交付使用的载体。 13. 软件是逻辑的而不是

12、有形的，软件是基于计算机的系统元素，因此软件具有与硬件完全不同的特征。 14. 软件是被开发或设计的，而不是传统意义上的被制造；软件不会“磨损”；虽然软件产品正在向基于构件的组装方向发展，但是大多数软件仍是定制的 15. 测试原则：a所有的测试都应可以追溯到客户需求。b应该在测试工作真正开始之前较长时间就进行测试计划。 16. 测试目的：a用最少的实践和工作量，系统地揭示不同的错误；b证实软件依据规约所应具有的功能和性能。 17. 测试注意问题：a没有找到错误的测试并不一定是成功的测试；b测试无法证明错误和缺陷不存在，只能表示其已经出现；在软件开发的早、中期，软件开发人员视图由抽象概念到具体实

13、现来创建软件系统；在测试阶段，软件测试人员试图“摧毁”已完成的软件系统；但是测试是为了发现错误，而非真正刻意的通过各种手段将已完成的系统摧毁。 18. 软件测试是软件质量保证的关键元素，并代表了规约、设计和编码的最终评审。通常，软件开发者将30%40%的项目工作量花费在测试上，在一些非常重要的软件项目上所花费的测试时间可能是一般项目的35倍. 19. 措施：a测试试图努力去“破坏”软件；b以严格的方式设计测试案例并评审其完全性。 20. 重要性：a当程序执行时，用户在使用系统的同时实际上也是测试b必须在程序交付用户之前，已消除错误的意图去执行。c为了发现最大可能数量的错误，测试必须被系统的进行

14、，并且测试案例必须用严格的技术来设计。 21. 步骤：软件的测试通常从两个不同的视角进行；a使用“白盒”测试技术测试内部程序逻辑b使用“黑盒”测试技术测试软件需求。 22. 23. 构件及设计内容a概念:构件级设计建立对数据结构的操纵；确定通过软件构件的接口实现的通信；实现每个构件处理算法所需的算法细节。 24. 步骤：a用户界面的设计从标示用户、任务和环境需求开始；b一旦标示出用户任务，则创建和分析用户场景；c定义一组界面对象和动作，并创建屏幕布局。d屏幕布局描述图形化的设计构思和各种图示位置，定义屏幕描述性文本，窗口命名与规格说明。 25. a用户界面是基于计算机的系统或产品的重要的元素之

15、一。b如果界面的设计很糟糕，可能会严重的阻碍用户使用系统的计算处理能力。c一个弱的界面，可能导致一个设计很好和实现可靠的应用系统的失败。 26. 三个重要的原则指导有效的用户界面设计：a置系统于用户控制之下；b减少用户的记忆负担；c保持界面一致。 27. 界面确认着重于：a界面正确地实现每个用户任务的能力、适应所有任务变更的能力以及达到所有一般用户需求的能力b界面容易使用和学习的程度。c用户接受界面作为他们工作中有用工作的程度。 28. 通常提供如下机制：a 管理输入设备 b确认用户输入 c处理错误和显示出错消息 d提供反馈 f提供帮助和提示 g处理窗口、域和窗口内的滚动 h建立应用软件和界面

16、间的连接 i允许用户定制界面 29. 界面构造 a构建用户界面原型，由用户进行检查，然后根据用户的意见进行修改 b许多高级语言或专用开发工具提供用户界面的开发功能，他们为简化窗口、菜单、设备交互、出错消息、命令以及很多其他交互环境元素的创建提供了各种构件和对象 30. 命令标记-许多高级用户喜欢面向命令的交互方式，提供命令交互时，应考虑：a每一个菜单选项是否都有对应命令 b以何种方式提供命令-控制序列、功能键和输入命令 c学习和记忆命令的难度如何，忘记命令怎么办？ d用户是否可以定制和缩写命令 31. 常见界面设计问题：a系统响应时间-用户从开始执行动作到软件给出预期的响应，其属性包括长度和可

17、变性 b用户帮助设施-集成的帮助设施和附加的帮助设施。帮助设施的构造涉及：1提供全部或部分功能的帮助 2用户采用帮助菜单、特殊功能键或help命令请求帮助 3在另一个窗口、或屏幕待定位置的简单提示表示帮助 4通过返回、功能键或控制序列回到正常的交互状态 5采用平面式、分层式或超文本构造帮助信息 32. 定义界面对象和动作：a界面设计中的一个重要步骤是定义界面对象和作用于它们之上的动作 b当所有的重要对象和动作被定义，开始进行屏幕布局，包括图符的图形设计和放置、描述性屏幕文字的定义、窗口的规约和命令、各种菜单项的定义等 33. 界面设计工程：a建立任务的目标和意图 b为每个目标或意图制定特定的动

18、作序列 c按在界面上执行的方式对动作序列进行规约 d指明系统状态，即执行动作时的界面表现 f定义控制机制，即用户可用的改变系统状态的设备和动作 g指明控制机制如何影响系统状态 h指明用户如何通过界面上的信息解释系统状态 34. 环境分析：a界面将物理地位位于何处 b用户是否将坐着、站着或完成其他与该界面无关的工作 c界面硬件是否适应空间 d光线或噪音约束 e是否存在特殊的有环境因素驱动的人的因素的考虑 35. 任务分析：a必须理解用户当前执行的任务，并将它们映射到类似的在用户界面的语境内实现的任务集上 b研究基于计算机的解决方案的现存规约，并导出能够适应用户模型、设计模型和系统感觉的一组任务

19、36. 设计模型：a设计模型由系统开发人员伴随需求分析和方案设计产生的界面，设计和构思模型 b该模型由最初的基本界面设计要求 37. 界面设计最重要的原则：a了解用户 b了解任务 38. 保持界面一致：用户应该以一致的方式展示和获取信息，即：a按照贯穿所有屏幕显示所保持的设计标准，组织所有可视信息 b将输入机制约束到有限的集合之中，并在整个应用中一致地使用 c从任务到任务的导航机制，应一致地定义和实现 39. 界面的视觉布置应该基于真实的世界的隐喻 40. 减少用户的记忆负担：a用户必须记住的东西越多，和系统交互时出错的可能性也越大 b一个设计良好的用户界面不会加重用户的记忆负担 41. 减少

20、对短期记忆的要求：a当用户陷入复杂的任务时，短期记忆就会要求很大 b界面设计应该设法减少记住过去和结果的要求 42. 允许用户交互可以被中断和撤销 a在一系列交互动作进行过程中，用户应该能够中断动作序列去做某些事情，而不会失去已经做过的工作 b用户能够撤销任何动作 43. 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式 a如在流行的窗口操作系统界面之下，用户可随意创建新的窗口或在各种操作功能之间转换，而不必进行过多操作 44. 用户在使用一个基于计算机的系统时：a用户需要的是一个对其要求做出反应，并帮助其完成必要的工作的系统 b用户希望去控制计算机而不是被计算机控制 45. 设计者

21、在界面设计中施加的多数界面约束和限制：目的是试图简化交互模式 b其结果可能是界面易于构建，但会阻碍使用。 46. 用户界面设计遵循的3条黄金规则：a置系统于用户控制之下(将用户置于管理和控制系统的地位) b减少用户的记忆负担 c保持界面一致 47. 界面设计涉及3个方面：a设计软件构件之间的接口 b设计模块和其他非人的系统元素的接口 c设计人和基于计算机的系统之间的接口 .界面设计-涉及三个方面（设计软件之间的接口设计模块和其他非人的系统元素的借口设计人和基于计算机的系统之间的接口）2.界面（接口）的定义界面-通常意义上是指两个功能部件之间的共享界面。在一定的条件下，应根据功能的特性，公共的物

22、理连接特性，信号特性以及其他特性来定义在软件系统中，接口任务是系统内部之间或内外之间信息交流的一种共享逻辑界面，即信息交流的一种约定或一种标准。 重要性（外界影响用户对软件的感受 不管软件展示了什么计算机能力和功能，如果软件难以使用，则用户是不会喜欢这样的软件） 步骤（用户界面的设计从标识用户，任务和环境需求开始 一但标识出用户任务，则创建和分析用户场景定义一组界面对象和动作，并创建屏幕布局；屏幕布局描述图形化的设计构思和各种图标位置。定义屏幕描述性文本，窗口命名与规格说明，主、子菜单项规格说明） 概念（用户界面设计是在人和计算机之间创建一个有次奥的通信媒介一组界面设计原则 定义界面对象和动作

23、，创建屏幕布局，形成用户界面原型）人员（软件工程师通过应用一个选代的设计过程，设计开发用户界面）3. 4.构件级设计内容结构化程序设计：逻辑构成元素的顺序、条件和重复构成了结构化程序设计的基础（顺序实现了算法规约中的核心处理功能条件允许根据设计情况选择处理的方法 重复-提供了循环） 图形设计符号（流程图和盒状图）程序设计语言pdl（结构化的英语或伪代码） 5.结构设计也叫过程设计，他在数据设计、体系结构设计和接口设计之后进行，其意图是将设计模型翻译为可运行的软件。结构级设计是使用某些能够容易翻译成源代码的中间表示（如，图形的、表格的或基于文本的）来表示设计过程设计。 结构级设计的目标是保证不仅

24、能完成翻译任务，而且能不再开始的时候引入错误，即在过程设计中避免错误的产生。 6. 7.软件体系结构提供了待建造软件系统的整体视图，其描述软件构件的结构、组织、性质以及它们之间的联系。8.软件构件包括程序模块和程序操作的各种数据表示。9.数据设计是软件体系结构设计的一个有机组成部分。10.体系结构关注于早期设计决策，并提供了可选择的系统结构体制。软件测试技术 1.软件测试的目的，就是在系统交付客户之前能够发现极可能多的错误。 白盒测试又称：玻璃盒测试。白盒测试重视宇程序控制结构 白盒测试页称为行为测试。黑盒测试注重于确认功能需求。 用户界面设计：1 用户界面可以说是基于计算机的系统或产品的最重

25、要的元素。，如果界面的设计很糟糕，可能会严重地阻碍用户使用系统的计算机处理能力。2 一个弱的界面可能导致一个很好地设计和可考实现的应用的失败。3 三个重要的原则导致有效的用户界面设计：置系统于用户控制之下，减少用户的记忆负担和保持界面一置。11 12.构件级设计内容：1 ：结构化程序设计：逻辑构成元素的顺序、条件和重复构成了结构化程序的苇基础：a:顺序实现了算法规约中核心处理功能。b_-条件-_允许根据逻辑情况选择处理的方式。c_-重复提供了循环。2 图形设计符号：流程图和盒装图。3程序设计语言pdl:结构化的英语或伪代码。12构件级的合计：1构件级设计也称为过程设计，他在数据设计、体系结构设

26、计和接口设计之后运行，意图是将设计模型翻译为可以运行 的软件。2 结构设计是使用某些能够容易翻译成源代码的中间表示来表示过程设计。3.构件记设计的目标是要保证不仅能够完成翻译任务，而且能够不再开始时引入错误，即在过程设计中避免错误的产生。 软件体系结构设计 1.软件体系结构提供了待建造软件系统的整体视图，其描述软件构件的结构、组织、性质以及它们之间的联系。2.软件构件包括程序模块和程序操作的各种数据表示。3.数据设计是软件体系结构设计的一个有机组成部分。4.体系结构关注与早期设计决策，并提供了可选择的系统结构体制。设计的概念与原则 1.概念 包括 抽象、求精、模块化 2.软件设计内容包括数据设

27、计、体系结构设计、接口设计、构件级设计 3.设计过程包括设计过程的目标、评价设计质量的指导性原则、设计任务集合 3.设计是将要建造的某种事物的有意义的工程表示。软件设计创建软件的表达或模型，提供了软件数据结构、体系结构、接口和软件构件的设计细节提供了软件系统实现所必须的工作基础。4.对设计良好的软件而言，坚固是指程序不应含有任何妨碍其功能的缺陷;适应则是程序符合开发目标；赏心悦目以为者使用程序的体验是愉快的。分析建模 数据建模1.数据对象描述数据字典包括名称、别名、何处使用如何使用、内容描述、补充信息2.数据建模包括数据对象和属性关系、基数、数据模型：实体关系图（erd） 分析建模 原则 1.

28、描述和理解问题的信息领域2.定义软件将实现的功能3.作为外部事件的结果，描述软件的行为4.通过问题的划分，描述信息、功能和行为的模型，逐渐以层次的方式揭示细节5.分析过程应从要素信息移向实现细节。分析建模的任务合集包括评审需求、扩展和细化用户场景、数据建模、功能建模1.分析建模使用文本和图表形式的组合，以相对容易理解的方式描绘数据、功能和行为的需求，并直接评审其正确性、完整性、一致性。需求工程1.用户场景包括use-case及其参与者、开发use-case 2.构件分析建模包括数据模型、功能模型、行为模型 3.需求确认与规约包括协商需求、确认需求、规约需求 4.软件需求的导出包括1.质量功能部

29、署包括正常的需求、期望的需求、令人兴奋的需求2.功能性需求和非功能性需求包括1.功能性需求描述系统为用户或其他系统提供的服务2.非功能性需求系统开发过程中必须遵守的约束（一 反映了软件的质量属性 二.约束了系统的环境和技术 三.约束了项目计划和开发方法）软件产品有着特有的产品分类方法软件产品的角度分类（通用软件产品 定制软件产品 嵌入软件 ）软件应用领域分类（系统软件、应用软件、工程科学软件、嵌入式软件、产品线软件、web应用软件、人工智能软件、开发计算、网络资源、开源软件） 计算机软件是一种特殊的逻辑产品，其为在计算机上运行的各种程序、数据及其说明程序的各种文档。软件承担着双重角色，软件是一

30、个产品，同时又是产品交付使用的载体。 软件是逻辑而不是有形的，软件是基于计算机的系统元素，一次软件具有与硬件完全不同的特征。（软件是被开发或设计的，而不是传统意义上的被制造软件不会磨损虽然软件产业正在向基于结构的组装方向发展，但大多数软件仍是被定制的 第二篇：软件工程知识点总结软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。是一门指导软件系统开发的工程学科，它以计算机理论及其他学科为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经实践证明的学科的管理措施与最先进的技术方法结合起来，目标是以较少的投资获取高质量的软件。 内容：方法与技术、工具与环境

31、、管理技术、标准与规范。 领域：软件需求分析、软件设计、软件构造、测试和维护。 难题 1.复杂性 2.不可见性 3.易变性 4.服从性 5.非连续性 计算机科学中与实践相关的部分，都和数据以及其他学科发生关系。软件工程和人的行为、现实社会的需求息息相关。 发展史：1.生产作坊方式2.面向对象的方法3.软件过程工程4.软件复用和基于构件的开发 学生做到：1.研发出符合客户需求的软件 2.通过一定的软件流程，在预计的时间内发布足够好的软件 3.通过数据和其他方式展现所开发的软件是可以维护和继续发展。 单元测试（好标准）：1.在最基本的功能/参数上验证程序正确性；2.由最熟悉代码的人写；3.测试后，

32、机器状态保持不变；4.要快；5.产生可重复、一致的结果；6.独立性；7.覆盖所有代码路径；8.集成到自动测试的框架中；9.和产品代码一起保存和维护。 回归测试：模块出现退步，从正常退化到不正常状态，为了验证新改进的代码的正确性。 个人开发：计划：估计时间（开发）：.需求分析.生成设计文档.设计复审.代码规范.具体设计.具体编码.代码复审.测试；记录用时；测试报告；计算工作量；事后总结；提出改进计划 个人在团队中：1.通过交流实验等方法理解问题、需求或任务2.提出多种解决办法3.与相关角色交流解决问题的提案，决定一个可行方案4.执行5.和其他角色合作，测试实现方案，修复缺陷6.对结果负责 代码规

33、范：代码风格规范：1.缩进2.行宽3.括号4.断行与空白行5.分行6.命名7.下划线8.大小写9.注释代码设计规范：1.函数2.goto3.错误处理4.处理c+中的类 代码复审目的：1.找出错误代码2.发现逻辑错误3.发现算法错误4.发现潜在错误5.发现可能需要改进的地方6.传授经验 代码复审步骤：1.代码成功编译2.程序员必须测试过代码3.程序与提出新的代码，差异分析4.可选择面对面复审，独立复审5.面对面复审中，开发者控制流程，讲述修改的前因后果，复审者有权打断叙述提出自己意见7.开发者负责所有问题得到满意解答8.达成一致意见 复审后：1.改正明显的错误2.对无法解决的错误，记录下来3.把

34、所有错误记在“我常犯的错误”表中，作为以后自我复审的第一步 结对编程好处：1.在开发层次，提供更好的设计质量和代码质量，解决问题能力强2.对开发人员，结对更有信心3.在企业管理层上，更有效的交流相互学习传递经验，高投入产出比 如何结对编程：1.驾驶员：写设计文档，进行编码和单元测试2.领航员：审阅文档、编码；考虑单元测试的覆盖率；思考是否需要重构；帮解决技术问题3.不断轮换角色，不连续一小时，领航员控制时间4.主动参与5.只有水平差距，没有级别差距6.设置好结对编程环境 团队模式：1.主治医师2.明星3.社区4.业余剧团5.秘密团队6.特工7.交响乐团8.爵士乐 开发方法： 统一流程（rup）

35、业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境. 敏捷开发原则：1.尽早并持续交付有价值的软件满足需求2.欢迎需求的变化3.经常发布可用软件，间隔较短4.业务员与开发人员共同工作5.以有进取心的人为核心6.面对面交流7.可用软件是衡量项目进展的主要指标8.可持续发展9.不断关注技术和设计10.保持简明 敏捷流程：1.找出完成产品所需要做的事2.决定当前冲刺需要解决的事3.冲刺 软件需求：1.获取和引导需求2.分析和定义需求3.验证需求4.在软件产品的生命周期中管理需求（功能性需求.开发过程需求.非功能性需求.综合需求） 需求获取方法：用户调查1.焦点小组2.深入面

36、谈3.卡片分类4.调查问卷5.用户日志研究6.人类学调查7.眼动跟踪研究8.快速原型调研9.a/b测试 利益相关者：用户：直接使用软件的人；客户：购买软件的人；市场分析师：代表典型用户的需求；监管机构：符合行业和政策规定；软件工程师：需求阶段重要角色 项目经理pm：对项目流程负责，正确的协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目按计划结项。管事也管人，不一定做具体工作。 应对风险：1.进一步研究2.接受3.规避4.转移5.降低6.制定应急计划 pm能力：1.观察、理解和快速学习2.分析管理能力3.专业能力4.自省能力 典型用户：名字.年龄.收入.代表的用户在市场上的

37、比例和重要性.典型场景.环境.生活情况.知识层次/能力.偏好 功能说明书 1.定义好相关概念2.规范好一些假设3.避免误解，界定边界条件4.描述主流用户5.一些好的功能会有副作用6.服务质量说明 功能驱动设计：1.构造总体模型2.构造功能列表3.制定开发计划4.功能设计阶段5.实现具体功能 用户体验：1.用户第一印象2.从用户角度考虑问题3.软件服务始终要记住用户的选择4.短期刺激和长期影响5.不让用户犯简单错误6.用户体验和质量7.情感设计 评价标准：1.尽快提供可感触的反馈2.系统界面符合用户的现实惯例3.用户有控制权4.一致性和标准化5.适合各种类型的用户6.帮助用户识别、诊断并修复错误

38、7.有提示和帮助文档 测试方法：1.单元测试2.代码覆盖率测试3.构建验证测试4.验收测试5.探索式测试6.回归测试7.场景/集成/系统测试8.伙伴测试9.效能测试10.压力测试11.内/外部公开测试 黑箱：把软件系统当作一个黑箱，无法了解或使用系统的内部结构及知识。从软件的行为而不是从内部结构出发来设计测试。 白箱：设计者可以看到软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。 软件质量：1.程序的质量2.软件工程的质量（开发过程可见性、风险控制、软件内部模块、开发成本控制、内部质量指标完成情况） 如何衡量：cmmi理论：一级初始级（企业项目目标实现），二级管理

39、级（对项目流程审查，保证成功），三明确级（对管理体系制度化保障完成），四量化管理级（数字化管理，流程的稳定性），五级优化级（充分利用信息资料，主动改善流程） 如何衡量：1.软件cc后dcr的数量2.用户的好评3.在cc后发现bug的数量4.文档完整性和准确性5.修复bug平均时间6.单位开发量出现最大bug数量7.测试用例的覆盖率8.模块的复杂程度9.代码的行数10.文档的数量和复杂程度11.有多少代码重复12.平均每天构建失败的次数13.实现了多少功能点14.软件能运行多久，平均初次错误时间，无故障时间 会诊：1.开发者提交参加会诊的bug和修改方案2.会议决定是否同意修改方案3.执行 it

40、创新：1.灵光一闪，创新及随其后2.大家都喜欢创新3.好的想法会赢4.创新者都是一马当先5.要成为领域的专家6.技术是创新的关键7.成功的团队更能创新 团队合作阶段：1.萌芽阶段2.磨合阶段3.规范阶段4.创造阶段5.团队的效能曲线和假团队 职业道德：1.行为与公众利益一致2.以客户和雇主利益最大化的方式做事3.确保自己的产品以及修改满足专业标准4.具备完整独立的专业判断5.软件项目的经理和领导人应提倡并亲自采用复合道德规范的方法来管理软件的开发和维护6.保证职业的诚信和荣誉7.公平对待同侪，并予以支持和帮助。 需求分析：四方面：对问题的识别、分析与综合、制定规格说明书、评审；三原则：必须能够

41、表达和理解问题的数据域和功能域；必须按自顶向下、逐步分解的方式对问题进行分解和不断细化；要给出系统的逻辑视图和物理视图。 第三篇：软件工程知识点总结软件工程知识点总结软件工程知识点总结1.软件危机：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。2.软件危机产生的原因：1.软件本身的复杂性、难衡量的特点；2.软件开发与维护的方法不正确。3.软件的定义：计算机程序、方法、规则、相关文档资料以及在计算机上运行程序时所必需的数据4.软件不是程序，软件是程序、数据以及相关文档的完整集合。5.程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使

42、用和维护程序所需要的图文资料。6.软件生命周期：一个软件从定义、开发、使用和维护，直到最终被废弃所经历的一个漫长时期。7.软件开发的过程：问题定义：确定要求解决的问题是什么可行性研究：决定该问题是否存在一个可行的解决办法需求分析：深入了解用户的要求，在要开发的目标系统必须做什么问题和用户取得完全一致的看法。 概要设计：概括回答怎样实现目标系统。概要设计又叫逻辑设计、总体设计、高层设计。详细设计：把解法具体化，设计出程序的详细规格说明。详细设计也叫模块设计、底层设计。 编码和单元测试：编写程序的工作量只占软件开发全部工作量的10%20。综合测试：软件测试的工作量通常占软件开发全部工作量的40%5

43、0。软件维护：软件维护的费用通常占软件总费用的5570%。为软件定义时期，为软件开发阶段。为系统设计，为系统实现。中国国家标准计算机软件开发规范将软件生命周期分为：可行性研究与计划，需求分析，概要设计，详细设计，实现，组装测试，确认测试，使用和维护8个阶段。8.软件工程：是指导计算机软件开发和维护的工程学科。软件工程采用工程的概念、原理、技术和方法来开发和维护软件，结合正确的管理技术和先进可靠的技术方法，经济地开发出高质量的软件，并有效地维护它。9.软件工程方法学：方法、工具和过程。普遍使用的是传统方法学和面向对象方法学。10.瀑布模型：唯一被广泛采用的模型，各阶段间具有顺序性和依赖性：前阶段

44、完成才能进行下一阶段。文档驱动。原型模型：快速建立一个能反映用户主要需求的原型系统让用户试用，并根据用户意见修改原型。原型的用途是获知用户真正需求，一旦需求确定，原型将被抛弃。当用户对系统的目标不是很清楚，难以定义需求，可用此法。增量模型：也叫渐增模型。整个软件被分解成许多各增量构件，设计人员分批地逐步向用户提交产品，每次用户都得到一个满足部分需求的可运行产品。优点：能在短时间内向用户提交可完成部分工作的有用产品，易于维护。螺旋模型：使用原型及其他方法来尽量降低风险。它类似于原型法，不过在每个阶段之前都增加了风险分析过程。螺旋模型适用于内部开发的大规模软件项目。螺旋模型的优势在于它是风险驱动的

45、。v型模型：从需求分析就开始编写测试计划一直到系统交付。需求分析对应于验收测试，概要设计对应于系统测试，详细设计对应于集成测试，编码对应于单元测试，这样先产生计划再执行测试,在测试的每个阶段都进行审查.喷泉模型：是一种典型的适合于面向对象范型的过程模型，支持开发过程中的迭代。瀑布模型注重冻结需求的理念、up模型注重增量迭代/用例驱动、v型模型讲究质量保证理念、xp模型讲究沟通。11.实体关系图（er图），用于建立数据模型，其中包含了实体、关系、属性。12.数据流图（dfd）：描绘信息流和数据输入输出的移动过程。是结构化分析过程中使用的主要建模工具。功能建模。13.状态转换图：通过描述系统的状态

46、及引起系统状态转换的事件，表示系统的行为，提供了行为建模的机制。3/29/2013 1软件工程知识点总结14.数据字典：描述在数据模型、功能模型和行为模型中出现的数据对象和控制信息的特征，给出这些对象的精确定义。数据字典是分析模型的核心，通常使用case工具来创建和维护数据字典。15.结构化设计的几个阶段：数据设计、体系结构设计、接口设计、过程设计（是详细设计阶段的主要任务）。结构设计属于概要设计阶段。接口设计（包括i/o设计）和过程设计属于详细设计阶段。人机界面设计属接口设计。16.基本设计原理：模块化、抽象、逐步求精、信息隐藏、模块独立（功能独立，和其它模块没有过多相互作用）。模块独立的好

47、处：易开发、易测试、易维护。模块独立程度的衡量标准：内聚和耦合。17.内聚衡量模块内各元素之间结合的紧密程度。耦合衡量不同模块之间连接的紧密程度。数据耦合控制耦合公共环境耦合内容耦合（高）（低内聚）偶然内聚逻辑内聚时间内聚（中内聚）过程内聚通信内聚（高内聚）顺序内聚功能内聚模块独立性设计原则：提高内聚，降低耦合18.表示软件结构：层次图、hipo图、结构图。过程设计：程序流程图、盒图（ns图）、pad图、判定表、判定树。19.软件测试分：单元测试和综合测试。软件项目管理从项目计划开始，第一项计划活动是估算。白盒测试：也称结构测试，逻辑驱动测试，基于代码的测试，测试程序内部的逻辑结构和过程性细节

48、，前期使用。黑盒测试：即功能测试，在程序接口进行测试，测试后期使用。具体办法：等价划分、边界值分析、错误推测。20.ieee 1058.1给出软件项目管理计划的框架；iso90003标准适用于软件的开发、供应、维护；iso/iec12207是指导软件过程实施的标准；iso/iec tr 15504是软件过程评估标准。软件质量保证sqa。21.软件重用是降低软件整体成本、提高软件质量和开发生产率的合理有效途径。可重用的软件成分：软件的技术表示（结构模型、设计和代码）、文档、测试数据、与过程相关的任务（如审查）。22.软件可移植性：指软件从某一环境移植到另一环境下的难易程度。为方便移植，要尽量采用

49、通用的程序设计语言。3/29/2013 2第四篇：软件工程知识点总结7.1软件的定义及特点 软件（ software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（program） ，数据（data）及其相关文档（ document）的完整集合。 三个特点： （1）软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性； （2）软件的生产与硬件不同，在它的开发过程中没有明显的制造过程； （3）在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。 7.2软件危机及其表现 软件危机（softward crisis）是指在计算机软件的开发和维护中所遇到的一系列严重问题。这些问题绝不

50、仅仅是“不能正常运行的”软件才具有，实际上几乎所有软件都不同程度地存在这些问题。 具体地说，软件危机主要有下述一些表现。 （1）对软件开发成本和进度的估计常常很不准确。 （2）用户对“已完成的”软件系统不满意的现象经常发生。 （3）软件产品的质量往往靠不住。（4）软件常常是不可维护的。 （5）软件通常没有适当的文档资料。 （6）软件成本在计算机系统总成本中所占的比例逐年上升。 7.3软件工程及三要素 软件工程：软件工程是采用工程的概念、原理、技术和方法来指导软件开发和维护的工程学科，以工程化的原理和方法来解决软件问题。 软件工程的特性： （1） 软件工程关注于大型程序的构造 （2） 软件工程的

51、中心课题是控制复杂性 （3） 软件经常变化 （4） 开发软件的效率非常重要 （5） 和谐地合作是开发软件的关键 （6） 软件必须有效地支持它的用户 （7） 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人 软件工程方法学包含3个要素：方法、工具和过程。 7.4软件生命周期 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和 测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审 查、形成文档以供交流

52、或备查，以提高软件的质量。每个阶段的任务如下 问题定义阶段：该阶段的关键任务是要明确：要解决的问题是什么？ 可性行研究阶段：该阶段的关键任务是要明确：做不做？ 需求分析阶段：该阶段的关键任务是要明确：做什么？ 概要设计(总体设计)阶段：该阶段的关键任务是要明确：怎么做？ 详细设计阶段：该阶段的关键任务是要明确：具体做法。 编码和单元测试阶段：该阶段的关键任务是：编码和单元测试。 综合测试阶段：该阶段的关键任务是通过各种类型的测试（及调试）使软件达到预定的要求。 软件维护阶段：该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的要求。 7.4.1瀑布模型 瀑布模型有以下优点 1）为项目

53、提供了按阶段划分的检查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在迭代模型中应用瀑布模型。 4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。 瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。 瀑布模型有以下缺点 1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。 2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。 3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4）瀑布模型的突出缺点

54、是不适应用户需求的变化。 “瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行，用户常常难以清楚地给出所有需求，用户必须有耐心，等到系统开发完成。 7.4.2 原型模型快速原型模型 在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。 优点： （1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对

55、用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 （2）缩短了开发周期，加快了工程进度。 （3）降低成本。 尽早发现需求，揭示风险 缺点： 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。 开发过程不便于管理。 7.4.3螺旋模型 螺旋模型的优点： （1）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标 （2）减少了过多测试或测试不足 （3）维护和开发之间并没有本质区别 螺旋模型的缺点： （1）风险驱动，需要相当丰富的风险评估

56、经验和专门知识，否则风险更大 （2）主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险 （3）随着迭代次数的增加，工作量加大，软件开发成本增加 7.4.4增量模型 增量模型优点： （1）在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。 （2）整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。 （3）逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。 （4）采用增量模型比采用瀑布模

57、型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。 增量模型的缺点： （1）在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。 （2）开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。 （3）多个构件并行开发，具有无法集成的风险。 7.4.5喷泉模型 主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征。 喷泉模型的优点 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始

58、设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 喷泉模型的缺点 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。 其特点如下： （1）开发过程有分析、系统设计、软件设计和实现4个阶段。 （2）各阶段相互重叠，它反映了软件过程并行性的特点。 （3）以分析为基础，资源消耗成塔型。 （4）反映了软件过程迭代性的自然特性，从高层返

59、回低层无资源消耗。 （5）强调增量开发，整个过程是一个迭代的逐步提炼的过程。 7.4.6构件组装模型 构件组装模型导致软件复用，而可复用性给软件工程师提供了大量的可见的益处。软件开发不用一切从零开始，开发过程就是一个组装构件的过程，维护的过程就是对构件升级、替换和扩充的过程，大大提高了软件的开发效率。构件模型允许多个项目同时开发，降低了费用，提高了可维护性。 构件模型也存在一些缺点，如：由于存在多种构件标准，缺乏通用的构件组装结构标准，如果自行定义会引入较大的风险；构件可重用性和软件系统高效性之间不易协调；如果过分依赖构件，构件质量会影响最终的产品质量。 7.4.7 rup rup是由rational公司的booch、jacobson、rumbaugh提出的软件过程模型，也称rup（ra