2017-2018-1 Java小组-1623 第一周作业

时间:2022-01-07 02:49:30

2017-2018-1 Java小组-1623 第一周作业

《构建之法》学习笔记及团队成员介绍

第二章 个人技术和流程

  • 2.1单元测试
    • 好的单元测试的标准
  • 2.2 效能分析工具:抽样和代码注入(不经分析就盲目优化可能会事倍功半)
  • 2.3 个人开发流程:PSP及其特点
  • 2.4 实践:设计有实际意义的软件工程作业、实践最简单的项目WC

第三章 软件工程师的成长

  • 3.1 个人能力的衡量与发展
    • 软件团队是由个人组成的,在团队的大流程中,是每个具体的个人在做工作。
    • 大多数工程师都在团队的环境中工作,怎么样才是一个合格,甚至是优秀的队员?
  • 3.2 软件工程师的思维误区
    • 分析麻痹
    • 不分主次
    • 过早优化
    • 过早扩大化
    • 画扇面
  • 3.3 软件工程师的职业发展
  • 3.4 技能的反面
  • 技能的反面是解决问题。应该通过不断的练习,把那些低层次的问题都解决了,变成不用经过大脑的自动操作,然后才有时间和脑力来解决较高层次的问题。

第四章 两人合作

  • 4.1 代码规范
    • 两个工程师在一起,需要互相看懂对方的代码,所以需要写出好的代码规范和设计规范。
  • 4.2代码风格规范
    • 代码风格的原则是:简明、易读、无二义性
    • 缩进(4个空格)、行宽(100字符)、括号(逻辑逻辑优先级)、断行与空白的{}行、分行、命名、下划线、大小写(Pascal、Camel)、注释
  • 4.3 代码设计规范
    • 函数、goto、错误处理、处理C++中的类
  • 4.4 代码复审
    • 代码复审的原因、步骤、核查表
  • 4.5 结对编程
    • 结对编程的原因及其方式
  • 4.6 两人合作的不同阶段和技巧

第五章 团队和流程

  • 5.1 非团队和团队
  • 团队的特点:有一致的集体目标并且有各自的分工、互相依赖合作
  • 5.2软件团队的模式
  • 一窝蜂模式(存货时间较短)
  • 主治医生模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式
  • 5.3 开发流程
  • 目的是为了提高软件开发、运营和维护的效率,以及提升用户满意度、软件的可靠度和可维护性
  • 写了再改模式、瀑布模型、瀑布模型的各种变形RUP、老板驱动流程、渐进支付的流程、MVP、MBP、TSP的原则

第六章 敏捷流程

  • 6.1 敏捷的流程简介
    • ①找到完成产品需要做的事情 ②决定当前的冲刺需要解决的事情 ③冲刺
  • 6.2 敏捷流程的问题和解法
  • 6.3 敏捷的团队:自主管理、自我组织、多功能性
  • 6.4 敏捷总结
    • 所谓极限编程,就是把一些认为中药和有效的做法发挥到极致。也可称之为“极致编程”
    • 敏捷流程的经验教训
  • 6.5 敏捷的问答
    • 敏捷是一股思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论;这些方法论又是建立在许多行之有效的最佳实践方法之上的。

第七章 实战中的软件工程

  • 7.1 MSF简史
    • 微软公司方法论——微软解决问题框架(Microsoft Solution Framework,MSF)
  • 7.2 MSF基本原则(9条)
    • 推动信息共享与沟通
    • 为共同的远景而工作
    • 充分授权和信任
    • 各司其职,对项目共同负责
    • 重视商业价值,提供渐进的价值
    • 保持敏捷,预期和适应变化
    • 投资质量
    • 学习所有的经验
    • 与顾客合作
  • 7.3 MSF团队模型
    2017-2018-1 Java小组-1623 第一周作业

  • 7.4 MSF过程模型
    2017-2018-1 Java小组-1623 第一周作业

  • 7.5 实战中的软件工程

第八章 需求分析

  • 8.1 软件需求
    • 获取和引导需求
    • 分析和定义需求
    • 验证需求
    • 在软件产品的生命周期中管理需求
  • 8.2 软件产品的利益相关者
  • 8.3 获取用户需求——用户调研
  • 8.4 竞争性需求分析的框架
  • 8.5 功能的定位和优先级
  • 8.6 计划和估计
    • 目标、估计和决心
    • 找出估计后面的假设
    • 提高估计能力的招数
  • 8.7 分而治之(WBS)
    • 从最终的产品开始,一层层往下,把大型交付件分割为小型、具体的交付件。这样的分割可以持续下去,直到WBS的使用者达到共识。

第九章 项目经理

  • 9.1 PM是啥
    • 项目经理——Program Manager
  • 9.2 微软PM的来历
  • 9.3 PM做开发和测试之外的所有事情
  • 9.4 领导力——高效的团队讨论
  • 9.5 PM和风险管理:PM要在整个项目的生命周期管理风险。

第十章 典型用户和场景

  • 10.1 典型用户和典型场景
    • “典型用户”可以强迫开发者考虑问题时从用户的角度出发
    • 定义不同的的典型用户:受欢迎和不受欢迎的。
  • 10.2 用例
    • 基本元素:标题、角色、主要成功背景、扩展场景
  • 10.3 规定说明书:软件功能说明书和软件技术说明书
  • 10.4 功能驱动的设计
    • 构造总体模型
    • 构造功能列表
    • 指定开发计划
    • 功能设计阶段
    • 实现具体功能

第十一章 软件设计与实现

  • 11.1 分析和设计方法
    • 以文字为主
    • 用图形为主构造
    • 用数学语言描述
    • 用类自然语言+代码构造的描述
    • 源代码加注释
  • 11.2 图形建模和分析方法
  • 11.3 其他设计方法
    • 形式化分方法
    • 文学化编程
  • 11.4 从Spec到实现
  • 11.5 开发阶段的日常管理
  • 11.6 实战中的源代码管理
    • 软件=程序+软件工程
    • 软件的质量= 程序的质量+软件工程的质量
  • 11.7 代码完成

第十二章 用户体验

  • 12.1 用户体验的要素
    • 用户的第一印象
    • 从用户的角度考虑问题
    • 如阿健服务始终都要记住用户的选择
    • 短期刺激和长期影响
    • 不让用户犯错误
    • 用户体验和质量
    • 情感设计
  • 12.2 用户体验设计的步骤和目标
  • 12.3 评价标准
    • 尽快提供可感触的反馈
    • 系统界面符合用户的现实惯例
    • 用户有控制权
    • 一致性和标准化
    • 适合各种类型的用户
    • 帮助用户识别、诊断并修复错误
  • 12.4 贯穿多种设备的用户体验

第十三章 软件测试

  • 13.1 基本名词解释及分析
    • 按测试设计的方法分类:黑箱和白箱
    • 按测试的目的:功能测试和非功能测试
    • 按测试的时机和作用分类
  • 13.2 各种测试方法
    • 单元测试和代码覆盖率测试
    • 构造验证测试
    • 验收测试
    • “探索式”的测试
    • 回归测试
    • 场景/集成/系统测试
    • 压力测试
    • 内部/外部公开测试
    • 易用性测试
  • 13.3 实战中的测试
  • 13.4 运用测试工具
    • 运用工具记录手工测试
    • 运用工具记录自动测试
    • 测试效能

第十四章 质量保障

  • 14.1 软件的质量
    • 衡量软件工程的质量:CMMI
  • 14.2 软件的质量保障工作

第十五章 稳定和发布阶段

  • 15.1 从代码完成到发布
    • 会诊小组
    • 复杂项目的会诊
    • 招数:设计变更
    • 招数ZBB=Zero Bug Build
    • 招数:最后回归测试
    • 招数:砍掉功能
    • 招数:修复Bug的门槛逐渐提高
    • 招数:逐渐冻结
  • 15.2 不同频率和不同覆盖范围的渐进发布
  • 15.3 发布之后——事后诸葛亮会议

第十六章 IT行业的创新

  • 16.1 创新的迷思
  • 16.2 创新的时机
  • 16.3 创新的招数
  • 16.4 魔方的创新

第十七章 人,绩效和职业道德

  • 领导力
    • 设定目标
    • 知人善任
    • 带领团队成长
    • 绩效管理
  • 绩效管理
  • 萝卜与白菜
  • 软件工程师的职业道德

遇到的问题:

  • 由于在本组开始轮替看书的时候并没有准备提出问题,所以导致小组没有将每个人的问题整理完毕。十一假期过去后小组成员会将各自的问题讨论商议后补上该部分内容。

小组分工

成员姓名 学号 分工
张师瑜 20162301 小组组长、博客编写、监督学习进程
李昱兴 20162305 软件测试
陈是奇 20162306 材料搜集与整理
马平川 20162308 代码设计与实现
林臻 20162310 软件界面设计以及意见反馈
王译潇 20162314 市场推广与营销、问题反馈