《构建执法》要点总结
第一章 概论
《构建执法》中对软件工程的定义是：把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。包括：软件 需求分析、软件设计、软件构建、软件测试和软件维护。软件工程与计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、 工业设计和用户界面设计等学科相关。
对软件的定义是：可以运行在计算机及电子设备中的指令和数据的有序集合。
由于软件开发有复杂性、不可见性、易变性、服从性、非连续性的特点，软件的开发并没有像硬件一样得到飞速的发展。
计算机科学可以分为偏学术的领域和偏理论的领域，前者与数学、逻辑学等关系密切，而后者的侧重点则是人。
软件工程的目标：创造“足够好”的软件，其中要考虑的因素有：用户满意度、可靠性、软件流程的质量和可维护性。
第二章 个人技术和交流
单元测试：模块质量稳定、量化的保证。保证100%覆盖代码。保证程序正确性、测试不产生后作用、速度快、可复现、自动测试。
效能分析：抽样->代码注入。分析找到问题后优化。
个人开发流程：注重需求分析和测试，而不是花费大量时间写代码。
第三章 软件工程师的成长
软件开发流程：包括开发、运营、维护。
IC：Individual Contributor，个人开发者。理解问题、需求和任务；提出多种解决办法并估计工作量；交流并决定可行的方案；执行，编写代码；合作测试实现方案，修复bug；对结果负责。
工程师的成长过程：积累知识、提升技能；积累问题相关领域知识和经验；理解通用软件设计思想和软件工程思想；提升职业技能；实际成果。
技能的反面：解决问题。解决问题是能力，要求随机应变。
第四章 两人合作
代码规范：代码风格规范、代码设计规范
代码风格规范：缩进、行宽、括号、断行与{}行、分行、命名、下划线、大小写、注释
代码设计规范：函数、goto、错误处理（参数处理、断言）。对C++中的类还有其他要求
代码复审：看代码是否在“代码规范”的框架内正确的解决了问题。自我复审+同伴复审+团队复审。发现代码错误、逻辑错误、算法错误、潜在错误和回归性错误、需要改进的地方、传授经验。
结对编程：互补，互换，随时的复审和交流。经常交换，不可连续工作，平等的决策权。萌芽阶段->磨合阶段->规范阶段->创造阶段（解体阶段）。
评价人的层次：行为和后果->习惯和动机->本质和固有属性。
说服人的方法：三明治=面包+肉+面包。
第五章 团队和流程
团队的特点：有一致的集体目标；各有分工，相互依赖合作。
软件团队模式：窝蜂模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。
开 发流程：CODE & FIX；瀑布模式及各种变形=模拟版本+最终版本；统一流程（RUP）=业务建模+需求+分析设计+实现+调试+部署+配置变更管理+项目管理+环境；老 板驱动流程；渐进交付流程，MVP（最小可行产品） & MBP（最强最美产品）。
第六章 敏捷流程
敏捷开发原则：尽早持续交付；需求变化提高竞争优势；经常发布；每天共同工作；项目核心进取并充分信任；保持有效沟通；用可用软件衡量项目进展；可持续发展；关注技术和设计；保持简明；自我管理；总结如何提高效率，并付诸行动。
敏捷流程 = Product Backlog + Sprint Backlog + Sprint。决定要解决什么问题；决定每个人要做什么；每天报告完成度和计划。时间驱动。
敏捷团队：自主管理、自我组织、多功能型。
第七章 MSF
MSF：Microsoft Solution Framework，支持Scrum和Agile。
MSF基本原则：推动信息共享与沟通；为共同的远景而工作；充分授权和信任；各司其职，对项目共同负责；交付增量的价值；保持敏捷，预期和适应变化；投资质量；学习所有经验；与顾客合作。
MSF团队：产品管理、项目管理、开发、发布管理、测试、用户体验。
MSF过程模型：构思->计划->开发->稳定->部署。
MSF敏捷开发模型：注重于用户交流；防止缺陷；重视实战条件下的质量；精简过程，直奔主题。
第八章 需求分析
软件需求：获取和引导需求->分析和定义需求->验证需求->在软件的生命周期中管理需求。
软件需求划分：功能性需求；开发过程的需求；非功能性需求；综合需求。
软件利益相关者：用户（直接使用者）；顾客（接收软件的人）；市场分析师；监管机构；软件工程师。
获取用户需求（用户调查）：焦点小组（找到目标用户代表）；深入面谈；卡片分类（把需求写成卡片进行分类）；用户调查问卷；用户日志研究；人类学调查（深入了解用户习惯）；眼动跟踪研究；快速原型调研（纸上模型）；A/B测试。
竞争性需求分析框架：NABCD模型。Need + Approach + Benefit + Competitors + Delivery。
功能定位和优先级：杀手功能（核心）·外围功能（UI）；必要需求·辅助需求。
第九章 项目经理
PM：Program Manager
PM解决的问题：交流成本问题；需求转化；功能设计；领域化。
PM风险管理：代码签入、技术风险、自然风险、法律风险。
风险管理层次：危机管理；缓和并防止问题；预计；把问题变为机会。
PM能力要求和任务：观察、理解和快速学习能力；分析管理能力；一定的专业能力；自省能力。
PM任务：带领团队形成目标、远景；管理软件生命周期；创建并维护规格说明书；分析带领成员对缺陷、变更达成一致意见并实施；带领成员维持平衡，跟踪项目进度，确保发布满意软件；收集数据，分析优缺点，提振士气。
第十章 典型用户和场景
典型用户：不同特点、不同需求、不同属性（年龄、收入、环境、能力、偏好等），深入理解用户需求。
场景：背景（用户信息）；场景（用户使用时会发生的事情）。根据需求设计场景。
用例：标题、角色、主要成功场景、扩展场景；
规格说明书：软件功能说明（概念、假设、边界条件、交互、副作用、服务质量） + 软件技术说明（原则P218）。
功能驱动设计：FDD。构造总体模型->构造功能列表->制定开发计划->功能设计阶段->具体实现功能。
第十一章 软件设计与实现
分析和设计方法：需求分析（实体，抽象出属性，了解需求）->设计与实现阶段（如何解决需求）->测试和发布阶段（是否解决需求）
图形建模和分析方法：表达实体和实体之间关系（思维导图、实体关系图、用例图UCD）；表达数据流动（划分层次）；表达控制流；统一的表达方式（UML图）。
其他设计方法：形式化方法、文学化编程。
从Spec（设计文档）到实现：控制代码签入，遵循标准开发工作流程，完成代码。
开发阶段日常管理：闭门造车（免打扰），每日构建、构建大师（发生错误的人，负责下一次构建）、宽严皆误（规则和流程控制）、Bug Hell（控制每个人可以出bug的总数量，超过则优先修复bug）。
第十二章 用户体验
用 户体验要素：用户第一印象（目标用户，仅保留最重要的功能？），从用户的角度考虑问题（需求、情况、用户能力）、记住用户选择（在相同系统中保持相同条 件，优化选择）、短期刺激和长期影响（长期使用需要喝多变化和更好的适应性）、不让用户犯简单错误（增大简单错误的触发难度）、用户体验和质量、情感设计 （本能、行为、反思）。
用户体验设计步骤和目标：认知阻力、交互方式、行为。
评价标准：尽快提供可感触的反馈，系统界面符合用户现实惯例，用户有控制权，一致性和标准化，适合各种类型用户，帮助用户识别、诊断和修复错误，有必要的提示和帮助文档。
第十三章 软件测试
基本名词：BUG, TEST CASE, TEST SUITE。症状、程序错误、根本原因。
分 类：设计方法（黑箱、白箱），测试目的（功能测试=单元测试+功能测试+集成测试+场景测试+系统测试+外界使用测试、非功能测试=压力测试+效能测试+ 可访问性测试+本地全球化测试+兼容性测试+配置测试+易用性测试+安全性测试），测试时机&作用（冒烟测试、构建验证测试、验收测试）。
测试方法：单元测试，代码覆盖率测试，构建验证测试，验收测试，探索式测试（Ad hoc Test），回归测试，场景/集成/系统测试，伙伴测试（代码签入前构建测试），效能测试，压力测试，内部/外部公开测试，易用性测试，Bug Bash。
实际测试：测试设计说明书+测试用例+错误报告+关闭缺陷报告+测试报告。
测试工具：手工测试+自动测试。
第十四章 质量保证
软件的质量 = 程序质量+ 软件工程质量（开发过程可见性，风险控制，中间阶段交付质量、管理工具因素，成本控制，质量指标完成情况）。衡量标准：CMMI
软件质量保证（QA）：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。
第十五章 稳定和发布阶段
版本：Aapha（内侧）、Beta（公测）、ZBB（0 bug build）RC（发布候选版本）、RTM（最终发布版本）、RTW（网络发布版本）。
会诊：对于每个bug，修复/设计本来如此/不修复/推迟修复。
渐进发布：对于不同用户组，采用不同频率的发布。
总结会议：发布之后，探索出现问题的根源。
第十六章 IT行业的创新
创新：灵感顿悟VS日常积累和思考；改良式创新VS颠覆式创新；好的想法VS先入为主的优势；最早提出VS做得最好；领域知识VS实现想法；最强的技术VS满足用户需求；团队成功VS创新能力。
创新时机：先行一步，带动趋势发展；技术成熟度曲线指导。
创新的方法：SWOT分析框架（强项+弱项+机会+威胁）；平衡动量&加速度控制产品的生命周期…
第十七章 人，绩效和职业道德
参与者：全身心投入（重大决定）、参与、围观。
RASIC：承担责任，负有责任，提供支持，咨询，知会者。
绩效管理：评估（技术能力、劳动生产力、对团队贡献、对产品贡献），区别对待（2:7:1）。
矛盾：高效率多bug VS 低效率少bug。
团队合作阶段：萌芽阶段（依赖于领导）->磨合阶段（疑惑&冲突）->规范阶段（一致意见）->创造阶段（高度自治，职责转换）。
软件工程师的职业道德：与公众利益一致；客户和雇主利益最大化；产品满足最高专业标准；完整独立的专业判断；领导采用复合道德规范的管理；软件工程师保证职业诚信和利益；对同事提供支持和帮助；不断提高专业水平。
欢迎读者进行补充，或在评论中交流想法。
