软件工程复习参考资料

软件工程题型复习资料

简答题

代码风格规范

• 总原则 （简明、易懂、无歧义）
  • 缩进：4个字符
  • 行宽：100个字符
  • 括号：恰当运用（ ）
  • 断行与空白的{ }行
  • 分行：一行一条语句
  • 命名：有义、适当
  • 下划线
  • 大小写
  • 注释
• Pascal（大驼峰命名法）：所有单词的第一个字母都大写
• Camel（小驼峰命名法）：第一个单词全部小写，随后单词随Pascal形式
• 通用做法
  • 所有的类型/类/函数名都用Pascal形式
  • 所有的变量都用Camel形式
  • 类/类型/变量用名词或组合名词
  • 所有函数用动词或动宾组合词
• 关于注释
  • 注释是为了解释程序做什么（What），为什么这样做（Why）
  • 不要解释程序是怎么工作的（How）
  • 注释优先原则
    • 编写源代码之前先写好注释
  • 内容要全面
    • 对管理代码有用的注释
    • 对理解代码有用的注释
  • 采用ASCII字符集
    • 不使用中文，提高可移植性
  • 注释的位置
    • 函数头部的注释
    • 函数体内部的注释
  • 注释的更新
    • 一个误导的注释比没有注释更糟糕
  • 注释格式的统一

软件设计

• 模块的概念
  • 构成程序的基本单元
  • 具体形式：类、函数、构件、服务
  • 由边界元素限定的相邻的程序元素的序列
• 什么是模块化
  • 把程序划分成模块（独立命名且可独立访问）
  • 划分的程度：基于目标、应对复杂、考虑变化、折衷权衡
• 耦合（模块之间的复杂程度的度量）
  • 数据耦合
    • 两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据
  • 控制耦合
    • 如果两个模块彼此间传递的信息中有控制信息
  • 特征耦合
    • 当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素
  • 公共环境耦合
    • 当两个或多个模块通过一个公共数据环境相互作用
  • 内容耦合
    • 两个模块的程序元素共用
• 内聚
  • 模块内部的复杂程度的度量
• 信息隐藏
  • 变量的局部化
  • 类的封装
• 分层
  • 设计策略的分离
  • 界面与实现的分离

软件工程

• 软件工程定义
  • 把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程
• 软件工程的规律
  • 时间估计
    • 实际时间总是比预期要长
  • 增加人手
    • 向进度落后的项目中增加人员，会让项目更加落后
• 软件工程基本原理
  • 用分阶段的生命周期计划进行严格管理
  • 坚持进行阶段评审
  • 实行现代程序设计技术
  • 结果应能清楚的审查
  • 开发小组的人员应该少而精
  • 承认不断改进软件工程实践的必要性
• 软件生命周期和开发流程
  • 传统划分
    • 三个时期
      • 软件定义
      • 软件开发
      • 运行维护
    • 八个阶段
      • 问题定义
      • 可行性研究
      • 需求分析
      • 概要设计
      • 详细设计
      • 编码和单元测试
      • 综合测试
      • 软件维护

团队

• 团队（Team）
  • 针对一项目工作，团队成员彼此依赖
• 团队的特点
  • 团队有一致的集体目标，要一起完成这目标
  • 一个团队的成员不一定要同时工作
  • 团队成员有各自的分工，互相依赖合作，共同完成任务
• 团队的形成
  • 谨记：成熟的团队不是一天就形成的
  • 形成初期：一窝蜂模式（Chaos Team）
• 软件团队的模式
  • 主治医师模式
  • 明星模式
  • 社区模式
  • 业余剧团模式
  • 交响乐团模式
  • 爵士乐模式
  • 功能团队模式
  • 官僚模式
  • 秘密团队模式
  • 特工团队模式
• 为什么要选择团队模式
  • 一个合适的团队结构，能更大地改进交流的效率，让团队更能把注意力集中在最主要的目标——解决用户需求
• 如何选择团队模式
  • 独裁
  • 顾问
  • 民主
  • 一致

开发流程

• 写了再改模式
• 瀑布模型
• 生鱼片模型
• 子瀑布模型
• 快速原型模型
• 螺旋模型
• 老板驱动的流程
• 渐进交付的流程

结对编程

• 结对编程 (Pair Programming)
  • 结对编程就是一种卓有成效的开发方法，每时每刻都处在代码复审的状态
• 如何结对编程 （驾驶员/领航员，两人共享一个键盘，电脑，屏幕）
  • 驾驶员：写设计文档，进行编码和单元测试等
  • 领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行等
  • 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟
  • 主动参与：任何一个任务都是两个人的责任
  • 设置好结对编程的环境：座位、显示器、桌面等
• 结对编程的好处
  • 提高设计质量
  • 降低成本
  • 提高解决问题的信心
  • 提高士气
  • 减轻风险
  • 提高效率
• 结对编程不合适的场景
  • 需要深入研究的项目
  • 验证测试需要运行很长时间
  • 团队的人员要在多个项目中工作
• 结对编程中不好的习惯
  • 不拘小节
  • 发号施令
  • 拼写纠错
  • 深藏不露
  • 跳跃很大

需求分析

• 获取和引导需求
  • 需求来自用户
  • 需求来自管理机构
  • 需求来自企业内部
  • 需求来自技术团队
  • 需求来自要“更好地了解用户的行为和需求”
• 需求的分类
  • 对产品功能的需求
  • 服务质量需求
  • 对产品开发过程的需求
• 软件需求
  • 获取和引导需求
  • 分析和定义需求
  • 验证需求
  • 管理需求
• 获取需求方法
  • 用户调研
    • 焦点小组
    • 卡片分类
    • 用户调查问卷

应用分析题

• 流程图或活动图

  
  
  image

• 类图

  
  
  image

构建模型题

• 典型用户的模板

  • 名字（越自然越好）
  • 年龄和收入（不同年龄和收入的用户有不同的需求）
  • 代表的用户在市场上的比例和重要性
  • 使用这个软件的典型场景
  • 使用本产品的环境（在办公室/ 家里/ 沙发/ 床上/ 公共汽车/ 地铁……）
  • 生活/工作情况
  • 知识层次和能力（教育程度，对电脑、互联网的熟悉程度）
  • 用户的动机、目的和困难（困难 = 需要解决的问题）
  • 用户的偏好

• 示例

  
  
  image
  
  
  image