软件工程知识点总结 期末总结 wust

  1. 软件的定义: 指令的集合、数据结构、软件描述信息
  2. 软件工程的定义:1.将系统化的 规范的 可量化的方法应用于软件的开发 运行和维护,即将工程化的方法应用于软件; 2.对1中所述方法的研究
  3. 软件工程层次图: 工具、方法、过程、质量关注点
  4. 软件过程是工作产品创建时所执行的一系列活动、动作和任务的集合
  5. 通用的软件工程过程框架包括5个活动:沟通 策划 建模 构建 部署
    8个普适性活动: 软件项目跟踪和控制、风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用管理、工厂产品的准备和生产
  6. 软件开发神话:
    管理神话:
    1. 一本写满软件开发标准和规程的宝典
    2. 增加程序员人数而赶上进度
    3. 如果将软件外包给第三方公司,那么可以放手不管
    客户神话:
    1. 有了项目目标的大概了解,便足以开始编写程序
    2. 软件可以很容易适应需求的变更
    从业者神话:
    1. 当我们完成程序交付使用后,我们的任务就完成了
    2. 直到程序开始运行,才能评估其质量
    3. 对于一个成功的软件项目,可执行程序是唯一可交付的工作成果
    4. 软件工程导致产生大量无用文档,因此降低工作效率
  7. 过程流:描述在执行顺序和执行时间上如何组织框架中的活动、动作和任务。分为线性过程流、迭代过程流、演化过程流、并行过程流
  8. 瀑布模型:(经典生命周期),提出了一个系统的、顺序的软件开发方法,从用户需求规格说明开始,通过策划 建模 构建 部署的过程,最终提供完整的软件支持
  9. 过程模型分为: 惯用过程模型、专用过程模型、统一过程
    惯用过程模型:瀑布模型、增量过程模型、演化过程模型、并发模型
    专用过程模型(应用面窄且专一):基于构件的开发、形式化方法模型、面向方面的软件开发
  10. 统一过程:用例驱动、以架构为核心,迭代并且增量
    沟通->策划->建模->构建->部署
    阶段:起始、细化、构建、转换、生产
  11. 敏捷开发宣言:
    1. 个人和他们之间的交流胜过了开发过程和工具
    2. 可运行的软件胜过了宽泛的文档
    3. 客户合作胜过了合同谈判
    4. 对变更的良好响应胜过了按部就班地遵循计划
  12. 极限编程过程(XP):使用面向对象方法作为推荐的开发范型,包括策划->设计->编码->测试四个框架活动
  13. 组织模式:封闭模式、随机模式、开发模式、同步模式
  14. 需求工程:起始、获取、细化、协商、规格说明、确认、管理
    质量功能部署(QFD):一种将客户要求转化成软件技术需求的技术。
  15. 软件需求三类:正常需求、期望需求、令人兴奋的需求
  16. 分析模型的元素:基于场景的元素、基于类的元素、行为元素
  17. 需求模型必须实现的三个主要目标:
    1. 描述客户需要什么
    2. 为软件设计奠定基础
    3. 定义在软件完成后可以被确认的一组需求
  18. 需求建模的方法:结构化分析、面向对象的分析
  19. 软件需求: 基于场景的模型、行为模型、类模型、流模型
  20. 类-职责-协作者模型(CRC):CRC模型实际上是标识类的标准索引卡片的集合。卡片分三部分,顶部写类名,卡片主体左侧部分列出类的职责,右侧部分列出类的协作者
  21. 分为:实体类(模型或业务类)、边界类、控制类
  22. 分析建模工具可以使用UML语言开发基于场景的模型、基于类的模型和行为模型,8个工具:ArgoUML、Enterprise Architect、PowerDesigner、Ratinoal Rose、Rational System Architect、UML Studio、Visio、Visual UML
  23. 软件设计的目标:创作出坚固、适用和令人愉悦的模型或表示
  24. 设计模型:构建级设计、接口设计、体系结构设计、数据/类设计
  25. FURPS质量属性体现了所有软件设计的目标: 功能性(functionality)、易用性(usability)、可靠性(reliability)、性能(performance)、可支持性(supportability)
  26. 信息隐蔽:每个模块对其他所有模块都隐蔽自己的设计决策
  27. 设计类:用户接口类、业务域类、过程类、持久类、系统类
  28. 设计类的四个特征:完整性和充分性、原始性、高内聚性、低耦合性
  29. 体系结构模型从三个来源导出:将要构建的软件应用域信息、特定的需求模型元素、可获得的体系结构风格和模式
  30. 接口设计有三个重要的元素:
    1. 用户界面
    2. 和其他系统、设备、网络、信息生成者或使用者的外部接口
    3. 各种设计构件之间的内部接口
  31. 软件体系结构:程序或计算系统的软件体系结构是指系统的一个或者多个结构,它包括软件构件、构件的外部可见属性以及它们之间的相互关系。
  32. 体系结构的风格简单分类:
    1. 以数据为中心的体系结构
    2. 数据流体系结构
    3. 调用和返回体系结构
    4. 面向对象体系结构
    5. 层次体系结构
  33. 构件:系统中模块化的、可部署的和可替换的部件,该部件封装了实现并对外提供一组接口。构件包含一组协作的类。传统的观点:一个构件就是一个程序的一个功能要素,程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。(控制构件、问题域构件、基础设施构件)
  34. 基本设计原则:开闭原则、里氏替换原则、依赖倒置原则、接口分离原则
  35. 三个打包原则(发布复用等价性原则、共同封装原则、共同复用原则)
  36. 构件标准:CCM、MicrosoftCOM和.NET、JavaBeans、OSGI
  37. 界面设计黄金规则:1. 把控制权交给用户 2.减轻用户的记忆负担 3.保持界面一致
  38. 四个用户界面分析和设计模型:工程师建立用户模型、软件工程师创建设计模型、用户的心理模型或系统感觉、系统的实现者创建实现模型
  39. 用户界面分析和设计过程包括四个不同的框架活动:界面分析和建模、界面设计、界面构建、界面确认
  40. 软件质量:在一个程序上应用有效的软件过程,创建有用的产品,为生产者和使用者提供明显的价值
  41. McCall的质量因素:正确性、可靠性、效率、完整性、易用性、可维护性、灵活性、易测试性、可移植性、可复用性、互操作性
  42. 软件质量困境:产品足够好不会被立即抛弃、又不是那么完美,不需花费太多的时间和太多成本
  43. 质量成本:预防成本、评估成本、失效成本
  44. 软件测试策略:描述将要进行的测试步骤,包括这些步骤的计划和执行时机,以及需要的工作量、时间和资源。因此,任何测试策略都必须包含测试计划、测试用例设计、测试执行以及测试结果数据的收集和评估
  45. 软件测试策略:编码、单元测试、集成测试、确认测试、系统测试
  46. 传统软件的测试策略:单元测试、集成测试
  47. 管理设计的范围4P,即人员、产品、过程、和项目
  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

葛济维的博客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值