《构建执法》要点总结

最新推荐文章于 2024-11-11 23:20:39 发布

weixin_34248487

最新推荐文章于 2024-11-11 23:20:39 发布

阅读量76

点赞数

文章标签：人工智能 c/c++ 测试

原文链接：http://www.cnblogs.com/-OwO-/p/4822970.html

版权

第一章概论

《构建执法》中对软件工程的定义是：把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。包括：软件需求分析、软件设计、软件构建、软件测试和软件维护。软件工程与计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、工业设计和用户界面设计等学科相关。

对软件的定义是：可以运行在计算机及电子设备中的指令和数据的有序集合。

由于软件开发有复杂性、不可见性、易变性、服从性、非连续性的特点，软件的开发并没有像硬件一样得到飞速的发展。

计算机科学可以分为偏学术的领域和偏理论的领域，前者与数学、逻辑学等关系密切，而后者的侧重点则是人。

软件工程的目标：创造“足够好”的软件，其中要考虑的因素有：用户满意度、可靠性、软件流程的质量和可维护性。

第二章个人技术和交流

单元测试：模块质量稳定、量化的保证。保证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）：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作。

第十五章稳定和发布阶段