软件工程总结.doc

1. 软件指计算机系统中的程序及其文档2. “五个面向”理论:面向流程分析、面向数据设计、面向对象实现、面向功能测试、面向过程管理。3. 软件发展阶段:程序设计阶段50至60年代、程序系统阶段60至70年代、软件工程阶段70年代以后4. 软件工程的概念：(1)把系统化的、规范化的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程化应用于软件中；（2）研究、建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法5. 软件开发的工作量估算需要考虑哪些因素：软件产品属性、计算机属性、人员属性、项目属性6. 需求文档有哪些用途：作为系统设计的输入、软件维护的基础、系统测试用例编写的基础7. 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生命周期。8. 软件生命周期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。9. 瀑布模型的主要思想：软件开发过程与软件生命周期是一致的，相邻二阶段之间存在因果关系，需对阶段性产品进行评审；10. 瀑布模型的局限性：缺乏灵活性，如用户需求一开始很难确定；到最后阶段才能得到可运行的软件版本11. 增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。12. 增量模型特点是强调每一个增量都发布一个可运行的产品（第一个增量是核心产品）增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征。13. 增量模型特别适用于：需求经常变化的软件开发、市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发、增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术。14. 原型模型：原型应该包括目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能。原型模型两个阶段（1）原型开发阶段（2）目标软件开发阶段15. 原型的使用策略：废弃（throw away）策略、追加（add on）策略16. 原型模型的优点：有助于获取用户需求，加强对需求的理解、尽早发现软件中的错误、支持需求的动态变化、适合于需求动态变化、事先难以确定的系统。不足之处：不能支持风险分析17. 螺旋模型：螺旋模型是瀑布模型、原型模型的有机结合，同时增加了风险分析。18. 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动：制定计划、风险分析、实施工程、客户评估19. 螺旋模型的优点：有助于获取用户需求，加强对需求的理解，尽早发现软件中的错误，支持需求的动态变化，支持风险分析，可降低或者消除软件开发风险，适合于需求动态变化，事先难以确定并且开发风险较大的系统20. 喷泉模型是一种支持面向对象开发的模型，体现迭代和无间隙特征，该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。21. 喷泉模型的优点：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。22. 缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。23. 形式化方法模型：形式化方法是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成，直至维护等各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。24. 基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的组合25. 组成基于计算机系统的元素26. 可性行分析的任务：开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。27. 软件需求：用户对目标系统在功能、行为、性能等方面的要求28. 需求工程：运用相关技术与方法进行需求分析的过程。细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。29. 需求工程的任务：明确软件到底“做什么”，以及应具备的性能。30. 软件需求规约：通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求31. 软件设计的任务：使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、构件级设计32. 软件设计的两个阶段：概要设计（软件体系结构设计阶段）和详细设计（部件级设计阶段）。33. 软件设计的过程：制定规范、体系结构和接口设计、数据/类设计、构件级（过程）设计、编写设计文档、设计评审34. 常见的软件体系结构:单主机结、C/S（Client/Server）结构、B/S（Browser/Server）结构35. 模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问36. 模块设计的原则：1.在选择模块设计的次序时，必须对一个模块的全部直接下属模块都设计完成之后，才能转向另一个模块的下层模块的设计；2.是按子系统求精。37. 模块的作用域与控制域：1.模块的控制范围包括它本身及其所有的从属模块。2.模块的作用范围是指模块内一个判定的作用范围，凡是受这个判定影响的所有模块都属于这个判定的作用范围。3.如果一个判定的作用范围包含在这个判定所在模块的控制范围之内，则这种结构是简单的，否则，它的结构是不简单的。38. 信息隐藏：每个模块的实现细节对于其它模块来说应该是隐蔽的，块中所包含的信息(包括数据和过程)不允许其它不需要这些信息的模块使用，通过信息隐藏，则可定义和实施对模块的过程细节和局部数据结构的存取限制39. 内聚(cohesion)是一个模块内部各个元素彼此结合的紧密程度的度量；耦合(coupling)是模块之间的相对独立性(互相连接的紧密程度)的度量40. 构件级设计技术的描述方法：程序流程图、N-S图、PAD 41. 结构化分析模型：42. 系统响应时间长会使用户感到不安和沮丧。稳定的响应时间（如1秒）比不定的响应时间（如0.1秒到2.5秒）要好。43. 界面设计的黄金原则：让用户拥有控制权 、减少用户的记忆负担 、保持界面一致44. 标识符的命名规则：1.选择含义明确的名字，使其能正确提示标识符所代表的实体2.名字不要太长，太长会增加打字量，且易出错。必要时可使用缩写3.不用相似的名字，相似的名字容易混淆，不易发现错误4.不用关键字作标识符5.同一个名字不要有多个含义6.名字中避免使用易混淆的字符。45. 程序的注释分为序言性注解和功能性注解序言性注释：通常置于每个程序模块的开头部分，主要描述：模块的功能；模块的接口：包括调用格式、参数的解释、该模块需要调用的其它子模块名；重要的局部变量：包括用途、约束和限制条件；开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述功能性注释：通常嵌在源程序体内，主要描述程序段的功能。书写功能性注解时应注意的问题：注解要正确，错误的注解比没有注解更坏；为程序段作注解，而不是为每一个语句作注解；用缩进和空行，使程序与注释容易区分；注解应提供一些从程序本身难以得到的信息，而不是语句的重复。46. 代码的视觉组织：通过在程序中添加一些空格、空行和缩进等技巧，帮助人们从视觉上看清程序的结构47. 数据说明的规范：数据说明的次序应当规范化、说明语句中变量安排有序化、使用注解说明复杂数据结构48. 语句构造的规则：1. 在一行内只写一条语句2. 程序编写首先应当考虑清晰性3.程序要能直截了当地说明程序员的用意。4.让编译程序做简单的优化5.尽可能使用库函数6.避免不必要的转移。6.尽量只采用三种基本的控制结构来编写程序。49. 测试是一个为了发现错误而执行程序的过程，以下为软件测试的四个阶段：50. 各种逻辑覆盖之间的关系：判定覆盖包含语句覆盖，判定条件覆盖包含判定、条件、语句覆盖，条件组合包含全部，路径覆盖包含判定，跟其他的没什么关系。51. 相关测试的对象：系统工程需求分析设计编码系统测试确认测试集成测试单元测试52. 单元测试的任务：1.模块接口：确保模块的输入/输出参数信息是正确的。2.局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完整性。3.边界条件：确保程序单元在极限或严格的情况下仍能正确地执行。4.所有独立路径：确保模块中的所有语句都至少执行一次。5.所有错误处理路径：单元测试应该对所有的错误处理路径进行测试。53. 集成测试：非增量式集成、增量式集成（增量式集成又可分为自顶向下集成和自底向上集成。）54. 自底向上集成的优点：不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一层次的簇可并行进行测试，可提高效率。自底向上集成的缺点：整体性的错误发现得较晚。55. 回归测试：回归测试就是对已经进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。56. 测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经测试后的软件称为版软件。57. 测试是由软件的最终用户在一个或多个用户场所进行的，与测试不同，开发者通常不在测试现场，因此，测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。58. 测试完成的标准：如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0995的话，那么我们就有95%的信心说，我们已经进行了足够的测试59. 软件维护：是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程 60. 四种软件维护：纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护；适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程；改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护；预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动（改善性维护所占比例最大）61.62. 提高可维护性的方法:确定质量管理目标和优先级、规范化程序设计风格、选择可维护性高的程序设计语言、改进程序文档、保证软件质量审查方法63. 软件质量：与软件产品满足明确或隐含需求的能力有关的特征和特性的总和64. 软件可靠性是指在规定的条件下和规定的时间内软件按规格说明要求不引起系统失效的概率65. 可靠性的度量：MTTF (Mean Time to Failure)平均失效等待时间，理解为平均无故障时间，系统平均能够正常运行多久才发生一次故障；MTBF (Mean Time Between Failures) 平均失效间隔时间，是指两次相继失效之间的平均时间。MTBFMTTFMTTR其中：MTBF(meantimebetweenfailer)是平均故障间隔时间，MTTF(meantimetofailer)是平均故障时间，MTTR(meantimetorepair)是平均修复时间66. 软件配置项(Software Configuration item，SCI)：为配置管理设计的软件的集合，它在配置管理过程中作为单个实体对待67. 软件配置(Soft