Wang的专栏

目标设置方法——SMART原则，让你可以更好地设定合理目标。SMART原则SMART是五个英文单词的缩写：S: 表示目标必须是具体的M: 表示目标必须是可以衡量的A: 表示目标必须是可以达成的R: 代表目标必须是有关的T: 代表目标必须有明确的截止期限具体性（S）具体性是指要用明确而具体的语言清楚地说明要达成的行为标准，在涉及到次数的时候应该使用明确的数值，而不能泛泛地使...

微服务架构— 笔记整理自 北京理工大学 计算机学院从Dubbo说起 备注：图片托管于github，请确保网络的可访问性 单一架构Dubbo是阿里开源的一款高性能分布式服务框架，致力于提供高性能透明化的RPC远程服务调用方案以及SOA服务治理方案Dubbo可以和Spring系统无缝集成, 最大特点是按照分层的方式来架构，将整个框架分成10层来为服务提供方和消费方提供各自需要关心和扩展的接口,构建整个服务生态系统当一个网站很小的时候只需要一个应用就可以将所有

软件复用实施— 笔记整理自 北京理工大学 计算机学院传统软件开发企业经营方式软件开发过程工程技术缺乏界定复用的机制缺乏制作可复用构件的方法缺乏实施复用的工具组织结构与管理工作企业文化复用的并行过程 备注：图片托管于github，请确保网络的可访问性 开发可复用资产目标：鉴定可复用资产，并为本单位提供可复用资产以满足应用工程师的需要软件开发单位所用的软件构件中有的是买的，有的是自研的(这里重点讨论)清理现有的应用软件资产

软件构件技术— 笔记整理自 北京理工大学 计算机学院构件化开发案例大连路隧道监控系统开发工期9个月，代码29:35.85，效率提高5.2倍大量复用成熟构件XCOM2.0实时通讯中间件MultiLink1.9 PLC通讯中间件ePass1.2授权认证中间件BSMQ2.0消息队列VFC1.2画面框架CTCS1.0城市交通指挥Call Center 2.0呼叫中心复用的成功与失败成功复用的场景在较小的特定领域在理解充分的领域当领域知识变动缓慢时当存在构件互联标准时

软件复用综述— 笔记整理自 北京理工大学 计算机学院重复无处不在代码拷贝是复用还是Bad Smells?代码坏味道排名第一的就是代码拷贝代码拷贝不是良好的复用方法，也足以说明我们对软件复用的需求系统在从头开发的时候一定会存在多多少少重复劳动软件开发活动中存在大量的重复需求获取重复设计重复编码重复测试重复文档重复避免重复劳动的解决方案?面向对象构建技术软件复用的概念1968年的一篇论文“大量生产的软件构件”软件复用:重复使用“为了复用目的而设计的软件

过程改进标准框架— 笔记整理自 北京理工大学 计算机学院双模认证SPCA软件过程及能力成熟度评估SJ/T 11234《软件过程能力评估模型》针对软件企业对自身软件过程能力进行内部改进的需要有22个过程分为4个大类：过程管理类，项目管理类，工程管理类，支持类过程能力从0~5分为6个等级，每个等级包含了通用目标，通用管理，特定目标，特定惯例组成一整套的衡量准则按照这些准则，对于软件过程的评估，就可以确定当前软件工程的能力状态SJ/T 11235《软件能力成熟度模型》也有22个方面，

能力成熟度模型— 笔记整理自 北京理工大学 计算机学院CMM产生的背景急需对软件企业工程能力进行评价CMM的起源1987年SEI研究组发表论文:“承包商软件工程能力的评估方法”包含5级的软件能力成熟度模型承包商至少是3级1991年CMM1.01993年CMM 1.11997年 CMM2.0(并入CMMI)成为企业内外能力衡量的标尺CMM与CMMI出现了多个基于CMM的相关模型CMMI把CMM家族打包集成CMMI家族进一步扩充和发展CMMI目前分为三种模型

软件过程改进— 笔记整理自 北京理工大学 计算机学院软件过程开发不同于软件工程开发过程软件过程也是软件软件有个开发的过程，软件开发产出的是软件产品，是个演进的过程，是软件产品不断升级更新软件过程也有个开发的过程，软件过程开发产出的是过程产品，也是一个演进的过程，是过程的不断升级和更新，成熟度不断提高Leon Osterweil教授在1987年第9届世界软件工程大会上提出: Software Processes are Software Too开发过程产品演进软件过程

软件过程综述— 笔记整理自 北京理工大学 计算机学院混沌的开发过程 备注：图片托管于github，请确保网络的可访问性 开发过程像是个黑盒，没有可视性，无从得知开发人员是否按照标准的开发过程进行软件开发活动无法保证软件产品质量的稳定过程思维过程思维 vs 任务思维过程思维注重过程思维的意识总体目标各部分工作的协调性和一致性面向任务的思维注重传统思维模式注重任务和作业注重人员和组织结构忽略了当各个局部之间矛盾出现冲突的时候,再

全面软件质量管理— 笔记整理自 北京理工大学 计算机学院质量保证能保证质量吗?质量保证是保证质量的必要手段，而非充分手段质量保证:检查软件项目的工作过程和工作成果是否符合既定的规范过程质量与产品质量存在因果关系好的过程产生好的产品差的过程产生差的产品影响产品质量的不只有过程全面软件质量管理借鉴于传统生产行业的全面质量管理提高软件质量提高技术水平提高规范化水平谁对软件质量负责?任何软件开发与管理的工作人员都会对产品的质量产生影响，都应该对产品质量负责不要把质

SQA组织与职责— 笔记整理自 北京理工大学 计算机学院SQA组织结构组织结构决定岗位的职责决定资源配置分类职能结构矩阵结构柔性结构(混杂了职能和矩阵)职能结构各部门自设QA岗位QA位于高级经理之下, 独立于项目组, 直接对高级经理负责，但在业务上需要向项目经理汇报，属于项目成员QA和项目组工作在一起优点QA易融入项目组易发现实质性问题易解决问题缺点缺乏交流(各职能部门相互独立)重复投资QA被忽视(高级经理专注于业务的发展，往往会忽略Q

软件质量模型— 笔记整理自 北京理工大学 计算机学院常见软件质量模型软件产品的质量标准通过度量质量属性来评估软件质量常见质量模型McCall 模型(1977)Boehm 模型(1978)ISO9126(1993) 世界上最畅销的模型ISO25010(2011) 备注：图片托管于github，请确保网络的可访问性 McCall质量模型软件特性是软件质量的反映特性分组根据质量目标对特性进行取舍将11个产品特性分成了3组：产品修正、产

质量与质量保证— 笔记整理自 北京理工大学 计算机学院从饭店说起车站饭店 vs 闹区饭店车站饭店管人吃饱闹区饭店注重口味软件质量越高越好么?对大多数企业来说, 提高质量是为了盈利而非创造完美无缺的产品将提高质量的努力控制在预算之内质量太高或太低都不利于企业获取利润商业目标决定质量目标数学家陈省身:不要考100分从95分~100分会耗费几倍的精力为什么不把这些精力拿来做更有意义的事情呢什么是软件质量质量不是孤立的，与上下文和观察的角度密切相关软件产品质量

DevOps— 笔记整理自 北京理工大学 计算机学院故事开发部门最新最炫的技术没日没夜的加班如期完成任务开始了自己的庆功会为公司又挣到了一大笔钱运维部门( ⊙ o ⊙ )啊！从接到产品的那一刻，运维部充满了恐惧运维的生产环境太老了，无法支撑新技术运维的体系结构和环境模型不匹配运维压根搞不懂这款新的技术抱怨中，运维部门把这款产品安装好了，由于做了很多不合理的修改和强迫运行用户体验贼差，客户拒绝接受这款产品运维部门把责任推到了开发部门的头上开发部门回应非常理直

持续交付和部署— 笔记整理自 北京理工大学 计算机学院Hello World! 备注：图片托管于github，请确保网络的可访问性 这是一个jsp小程序发布到云端，用户可以直接访问这是软件发布的第一个版本，假设现在需求发生了变化程序员修改了代码，提交到版本控制库, 经过后台的持续集成和持续部署如果没有错误发生，第二个版本就直接可以给用户发布使用了持续部署极大缩短了从开发到部署的过程, 减轻了手工部署的工作量，提高了开发和部署的可靠性示例架

持续集成— 笔记整理自 北京理工大学 计算机学院从版本号说起 备注：图片托管于github，请确保网络的可访问性 14是主版本号0是次版本号4760是编译版本号1000是修正版本号一般来说前面的数字变化表示软件改动很大，后面的数字变动说明软件的变化很小从上面数字可见，至少发生了几千次的小版本变化可见, PPT的软件开发自动化程度很高!构建与集成手工构建:编译，单元测试，集成，除虫(修正bug)自动化构建:编写构建脚本(Daily

测试自动化— 笔记整理自 北京理工大学 计算机学院什么是测试自动化测试自动化的本质是:用程序A测试程序B联想与扩展编写程序B的叫程序员为了确保软件质量，程序B必需测试手工测试程序B的人，叫STE(Software test enginer)编写程序A进行自动测试的人叫SDET(Software Development Engineer in Test)开发程序A要按照一般的软件开发过程管理借助工具和框架，程序A可以更快，更好，更复杂…测试自动化策略提取适合自动化的测试

文档自动化— 笔记整理自 北京理工大学 计算机学院文档自动化文档很重要!软件开发人员不爱写文档软件的使用和维护必需文档多余的文档对客户和开发人员都是一种负担不爱写文档 -> 没人读 -> 文档过时文档自动化的优势简化项目文档生成过程维持精确性、一致性和时效性减轻开发人员负担设计文档在早期的软件开发过程中，设计和编码是分开的不同的人员使用不同开发工具，程序员编码时很容易偏离设计现在很多IDE厂商如：vs 在其中植入了多工种平台，架构师，设计师，程序员可以在同一个

典型自动化方法和工具— 笔记整理自 北京理工大学 计算机学院自动重构:重命名经常做的事情，比如：命名的讲究，审核借助编辑器快速实现重构自动重构:重排参数对现有函数进行参数重排智能工具感知那些调用add方法的代码提出修改方案开发者只需要选择并回车即可自动重构:方法重载修改代码并且给开发者带来开发上的方便鼠标定位到方法上，然后在智能感知菜单上选择方法重载即可生成一个新的重名方法然后用键盘修改它的参数即可自动重构:封装字段我们经常封装字段使用private,然后使用get

软件自动化概述— 笔记整理自 北京理工大学 计算机学院自动编程的传说OlivaNova : 这是来自芝加哥的报道，据说一家软件公司向外界公布了一项最新的研究成果，这款OlivaNova的软件，可以把应用程序的开发速度提高47倍，减少编程错误，错误只有手工编程的7%，支持windows,Unix,Linux等平台，可自动生成VB6, Java, Ejb, Jsp, .Net等，还可用于开发Webservice等各类程序Genux ERP：Genux 将软件开发的开发过程通过自己的平台重新定义为

Pos系统的分析与设计案例— 笔记整理自 北京理工大学 计算机学院分析设计Pos系统在生活中随处可见，如超时中的收银系统，建议参阅《对象模型——策略 模式 应用》的第一章：康妮的便利店。运用策略和模式可以快速提高OO设计水平策略是可以用来实现特定目标的一些具体建议模式是关于相互作用的对象的模板,可以通过模板反复使用建立对象模型的四种活动确定系统的目标和特性，后面的分析设计都是为了目标和特性服务的选择对象(识别对象)为对象确定职责，这个对象在系统中干什么，和其他对象是否有关联

主要UML模型图绘制技巧— 笔记整理自 北京理工大学 计算机学院用例图与用例分析用例分析技术是Ivar Jacobson于1986年总结发布的一项源于实 践的需求分析技术用例图对系统、子系统或类与外部参与者的交互行为进行了可视化为软件需求规格化提供了一个可验证可度量的基本元素是项目计划、进度控制、测试等环节的基础用例图可以使开发团队与客户之间的交流更加顺畅用例分析技术的核心是用例描述而不是用例用例图元素参与者(actor):代表系统用户，驱动系统运转系统边界(system sco

使用UML设计面向对象系统— 笔记整理自 北京理工大学 计算机学院UML的设计目标运用面向对象概念来构造系统模型建立起从概念模型直至可执行体之间明显的对应关系着眼于那些有重大影响的问题创建一种对人和机器都适用的建模语言UML为软件系统建立一个供项目组全体成员共享的模型，成为软件开发人员沟通与交流的工具不是软件开发过程和开发方法提供一种标准表达方式UML版本1997年被OMG接收为标准建模语言1.0—1.5(2003)2.0(2004)—2.5(2013)1999年的U

从重构到模式— 笔记整理自 北京理工大学 计算机学院什么是模式模式记录了专家的经验，并且让非专家也能理解，其核心是对真实世界的抽象和组织模式是发展的，是经过验证的专家经验的重用模式的名称构成了一份词汇表，帮助开发者更好的交流，更快的理解一个系统，更容易的重组一个系统模式的构成语境问题解决方案模式分类代码模式——特定编程语言相关分析模式——透过需求表面了解本质问题设计模式——局部强化架构模式——软件系统的基础结构组织模型建议学习顺序代码模式(忽略)设计模式(重点

通用职责分配模式(grasp)— 笔记整理自 北京理工大学 计算机学院什么是GRASP?General Responsibility Assignment Software Patterns(通用职责分配软件模式)GRASP包括4个基本模式和5个扩展模式，描述了对象设计和职责分配的基本原则职责是一个类的契约或义务“做”型职责是通过类的方法来实现的“知道”型职责是通过类内部封装的属性以及类间关系来 体现GRASP是如何设计一个面向对象系统的基础GRASP的9个模式专家 :应该将职责分

面向对象设计基本原则— 笔记整理自 北京理工大学 计算机学院面向对象设计基本原则 备注：图片托管于github，请确保网络的可访问性基本原则之SRPSingle Responsibility Principle(单一职责)每一个类应该专注于做一件事情SRP是低耦合高内聚在面向对象原则上的引申职责过多，可能引起它变化的原因就越多，将会导致职责依赖，相互之间就会产生影响，从而影响内聚性和耦合度OOD的实质就是合理分配类的职责基本原则之OCPOpen-Close Princ

面向对象核心概念和基本特性— 笔记整理自 北京理工大学 计算机学院问题导入如何设计一个五子棋游戏?1 ) 面向过程分析出解决问题所需要的步骤 ，然后用函数把这些步骤一步一步实现，使用的时候依次调用。面向过程设计 备注：图片托管于github，请确保网络的可访问性2 ) 面向对象把构成问题的事务分解成各个对象。建立对象的目的不是为了完成一个 步骤，而是为了描叙某个事务在 整个解决问题的步骤中的行为。面向对象设计对象的初步识别黑白棋对象:接受用户输入规则对象:判定诸如

敏捷不是万能药— 笔记整理自 北京理工大学 计算机学院对敏捷的误解对人的要求很高自组织，自管理，全职能敏捷没有文档，也不做设计不是没有文档，强调高效，灵活的交流敏捷好，其他方法不好争论没有实际意义敏捷就是XP，就是SCRUM敏捷方法成千上万, 追求的符合敏捷宣言所倡导的就是敏捷每个项目都要遵循敏捷标准世界上没有同一片树叶，要做到无招胜有招有诸多因素会影响我们选择和实施项目宣言真的能落地么?每次迭代后无法交付需求不清开发流程过长代码质

典型的敏捷开发方法:SCRUM和XP— 笔记整理自 北京理工大学 计算机学院典型敏捷方法之SCRUM来源于橄榄球比赛的英语， scrum vi.参加并列争球 vt.抛(球)开始并列争球 n.扭打, 混乱, 并列争球团队成员像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成同一个目标通过以下三点来展开：SCRUM开发模型SCRUM的三种角色SCRUM的3个实践开发模型 备注：图片托管于github，请确保网络的可访问性product backlog 对应整理后的用

敏捷是什么— 笔记整理自 北京理工大学 计算机学院典型瀑布模型开发计划、过程管理、团队管理需求 -》 设计 -》 编码 -》测试 -》部署活动之间存在隔阂分工明确是优点还是缺点? 备注：图片托管于github，请确保网络的可访问性从瀑布到车轮 备注：图片托管于github，请确保网络的可访问性敏捷宣言(对重型方法的宣战)个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划宣言落地不同的敏捷方法采用的实践

方法论来源于恐惧— 笔记整理自 北京理工大学 计算机学院软件开发的方法论方法论一系列需要照着做的方法一系列约束开发人员的规则软件工程是非常实践、非常工程、非常灵活的一套方法某些方法在某些情况下会比另一些方法好，反之亦然最终目的是：学习方法 -> 实践方法 -> 忘掉方法方法论源于恐惧Alistair Cockburn:方法论源于恐惧—— 出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定出了一些控制、监测项目的方法、技巧比如老板或项目管理

亡羊补牢为时不晚— 笔记整理自 北京理工大学 计算机学院不容忽视的测试亡羊补牢测试不简单, 工作量很大，很累，很复杂测试自动化是必由之路软件产品质量不能只靠测试软件测试基本原则程序员应避免测试自己编写的程序; (这样是测不出来什么的)测试用例的设计必须包括预期的输出结果;测试用例应包括有效的和期望的输入情况，也要包括无效的和不期望的输入情况;只检查程序是否做了它应该做的事这仅完成了测试工作的一半，另一半则是要检查程序是否做了它不该做的事;(后门)彻底检查每个测试结果;避免不可

唯一不变的是变化— 笔记整理自 北京理工大学 计算机学院软件开发中的一则小故事 备注：图片托管于github，请确保网络的可访问性上图表示在沟通过程中的信息误解很多时候都是这样，用户原始需求和实际交付不是一回事儿，钱也花了，时间也到了, 质量上勉强修修补补, 附带一些说明书来各种限制来勉强交付。很少一部分客户，对结果非常满意需求分析的困难性有几种原因使需求分析变得困难客户说不清楚需求;需求自身经常变动;分析人员或客户理解有误。“据历史记载，没有一个软件的需求改动少于

万变不离其宗— 笔记整理自 北京理工大学 计算机学院软件开发中的一则小故事程序员写出自认为没有Bug的代码。软件测试，发现了20个Bug。程序员修改了10个Bug，并告诉测试组另外10个不是Bug。测试组发现其中5个改动根本无法工作，同时又发现了15个新 Bug。重复n次步骤3和步骤4。鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表， 产品终于上市了。用户发现了137个新Bug。已经领了项目奖金的程序员不知跑到哪里去了。新组建的项目组修正了全部137个Bug，但又发现了4

软件工程前生今世— 笔记整理自 北京理工大学 计算机学院软件工程的历史软件开发50-60年代：手工作坊60-70年代：合作生产70年代以后：工程化1968年"软件危机"概念出现之后出现了软件工程的概念也就是把软件开发活动工程化三角模型：质量、进度、成本软件质量满足不了我们的需求软件规模大了之后，难以控制，总是出现延期，进度失控预算不够用，就像一个黑洞把客户的钱大量吸进去这三个要素出现了严重的问题人们被迫研究软件生产中的技术手段和管理方法关于软件

关于项目管理职能部门越卖力，企业越像官僚？ 赔钱的项目也要，老板是不是疯了？ 日报，周报，月报…然并卵，项目照旧失控，都是惹不起的“爷”，先招呼谁？项目到底有完没完？做项目累？那是你“姿势”不对！“做得更聪明”的一个方法就是建立透明的制度。德鲁克说，管理是一套关于价值观和信念的文化和制度。其实绝大多数管理问题都可以通过公开透明的制度来实现，这可以大量地减少人为干预的资源浪费，还能发挥员工的自主...

营销 既是一种组织职能，也是为了组织自身及利益相关者的利益而创造、传播、传递顾客价值，管理顾客关系的一系列过程。营销管理 营销管理是选择目标市场，并通过创造、传播和传递更高的顾客价值来获得、保持和增加顾客的一门艺术和科学营销与销售的区别销售只是营销的一个环节。销售把产品卖给客户，把钱赚到手。营销是一个闭环, 要做宏观环境的分析, 分析目标客户市场和客户需求分析, 去设计我们的产品。我们

战略，是一种从全局考虑谋划实现全局目标的规划，战术只为实现战略的手段之一。实现战略胜利，往往有时候要牺牲部分利益，去获得战略胜利。战略是一种长远的规划，是远大的目标，往往规划战略、制定战略、用于实现战略的目标的时间是比较长的。争一时之长短，用战术就可以达到！如果是“争一世之雌雄”，就需要从全局出发去规划，这就是战略！战略竞争分析之SWOT模型SWOT 即 Strengths(优势)Weakne

现代管理学大师 - 彼得 · 德鲁克 在1954年首次提出了管理学概念。美国当地时间2005年11月11日上午，95岁高龄的现代管理学教父彼得·德鲁克“因自然原因”在洛杉矶附近的家中辞世。出生于1909年11月19日的德鲁克最终没能等来自己96岁的生日，却在人们不经意间撒手人寰。彼得 · 德鲁克 wiki彼得 · 德鲁克 (Peter F．Drucker) 生平Drucker 在国内另一译名为“

绩效绩效，从管理学的角度看，是组织期望的结果，是组织为实现其目标而展现在不同层面上的有效输出，它包括个人绩效和组织绩效两个方面。组织绩效实现应在个人绩效实现的基础上，但是个人绩效的实现并不一定保证组织是有绩效的。如果组织的绩效按一定的逻辑关系被层层分解到每一个工作岗位以及每一个人的时候，只要每一个人达成了组织的要求，组织的绩效就实现了。绩效performance：简单说是为了帮助战略落地的考评机制。