《构建执法》要点总结

第一章 概论

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

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

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

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

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

 

第二章 个人技术和交流

单元测试:模块质量稳定、量化的保证。保证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。

团队合作阶段:萌芽阶段(依赖于领导)->磨合阶段(疑惑&冲突)->规范阶段(一致意见)->创造阶段(高度自治,职责转换)。

软件工程师的职业道德:与公众利益一致;客户和雇主利益最大化;产品满足最高专业标准;完整独立的专业判断;领导采用复合道德规范的管理;软件工程师保证职业诚信和利益;对同事提供支持和帮助;不断提高专业水平。

 

欢迎读者进行补充,或在评论中交流想法。

转载于:https://www.cnblogs.com/-OwO-/p/4822970.html

你可能感兴趣的:(人工智能,c/c++,测试)