软件工程
文章平均质量分 76
zhangmike
这个作者很懒,什么都没留下…
展开
-
说说鸡蛋估算法
鸡蛋估算法原理鸡蛋估算法,或者称鸡蛋计数法,在包括软件开发的智慧工作领域,是指对所处理对象进行简单分解后计量个数,直接作为规模。比如在敏捷软件开发中,对于迭代工作的范围大小,直接以用户故事个数为规模,不再细分故事点数,不再识别子任务,也不再估算理想工时数量。之所以用鸡蛋估算法(也称鸡蛋计数法)来命名这个方法,是因为鸡蛋的大小范围在同一个数量级上,容忍在这个范围变化,不再做更精细的估算。其实T...原创 2018-11-24 20:47:21 · 1159 阅读 · 0 评论 -
需求文档可以不签字吗? 之一
在软件开发中,需求分析和需求管理一直被认为是软件开发成功与否的关键。在CMMI中,需求管理是CMMI2级的过程域,需求开发是CMMI3级的过程域。在瀑布型生命周期当中,安排了需求分析阶段,一般也安排需求分析里程碑评审。瀑布型生命周期存在了很多年,曾经几度写入到软件开发的国际标准、国家标准当中。由于瀑布型生命周期如瀑布般顺流而下,在设计阶段开始后,根据需求文档的结果来开展工作,要求需求文档的结果比较原创 2015-01-12 21:15:38 · 2780 阅读 · 0 评论 -
过程质量保证PQA的几个关键方面
过程质量保证的范围是什么?过程质量保证是指不同于测试的、主要针对过程和中间工作产物的质量保证,一般而言,早年间的过程质量保证根据最早的CMM,也称为软件质量保证,缩写为SQA。现在最新的CMMI将其对应的过程域称为产品和过程质量保证,缩写是PPQA,这里面的一个P产品包括了最终产物,但其焦点是中间工作产物,所以这个P放在这里反而是带来一些混淆,与测试存在一些重叠。所以过程质量保证(PQA)这个提法原创 2015-01-11 16:12:33 · 4857 阅读 · 0 评论 -
软件配置管理七重境界
软件开发热点词汇不断推陈出新,cmmi,agile,精益,持续交付,持续集成,灰度……但有一个词其实一直在那里,支持着各种各样的新热点,它是#软件配置管理#。 它也是影响团队软件开发效率的重大因素。英文缩写SCMSCM从软件工程诞生时,甚至诞生前就在那里,因为程序代码文档总是要存放的.SCM发展历经了许多阶段,试做七重境界分级七重境界之第一重共享目录,复制来处理多人合作,每天或每周备份下。每部分只原创 2014-12-21 10:16:44 · 4642 阅读 · 5 评论 -
SonarQube4.4+Jenkins进行代码检查实例之三-单元测试分析
作者:张克强 作者微博:张克强-敏捷307在 《SonarQube4.4+Jenkins进行代码检查实例之一》 中介绍了不编译只检查的方式。在《SonarQube4.4+Jenkins进行代码检查实例之二》中介绍了编译并检查编译结果的方式。本文来介绍如何利用SonarQube来分析单元测试。最新推荐在分析插件是Jacoco。当然要进行单元测试,首先单元测试得到了书写,能够本地执行得到结果原创 2014-09-19 06:57:35 · 18340 阅读 · 0 评论 -
SonarQube4.4+Jenkins进行代码检查实例之一
在最新的《关于代码审查的几点建议》中再次提到了代码分析:6、尽量使用静态代码分析工具以提高审查效率。笔者之前也谈到过多次代码分析、代码检查,见:关于代码评审的微博讨论汇集 #敏捷有效实践# 每日代码自动检查 英文是daily code inspection。对代码质量关注时,安排人工检查code review是需要的,但100% code review需要很多工作量,不是所有的组织值得这样做,而工原创 2014-09-09 08:52:39 · 24440 阅读 · 4 评论 -
高效组织的配置管理计划
根据IEEE 828和CMM/CMMI,配置管理计划常常被认为是一份文档,确实的,对于一个大项目而言,往往需要制定项目自身的配置管理计划。但不是所有的组织都是软件外包组织,不是每个项目针对的是不同的客户。在非软件外包的高效软件开发组织中,推荐的配置管理计划应有三个层面。首先是组织层面,一般,提供统一的配置管理服务,不会允许每个团队自己搭建配置管理服务器。所以对于组织级的配置管理服务要有所约定,约定原创 2014-08-19 06:53:19 · 3905 阅读 · 0 评论 -
SonarQube4.4+Jenkins进行代码检查实例之二
在 《SonarQube4.4+Jenkins进行代码检查实例之一》 中介绍了不编译只检查的方式。但是有些代码检查需要使用字节码,比如Findbugs的检查依赖于字节码,实例一中只提取源代码,就不能进行Findbugs的检查。要进行Findbugs检查就需要编译。以下实例操作来演示如何搭建1,首先当然是要下载最新的Findbugs http://docs.codehaus.org/displ原创 2014-09-09 11:30:03 · 12220 阅读 · 5 评论 -
Don't Waste Time on Code Reviews
Less than half of development teams do code reviews and the other half are probably not getting as much out of code reviews as they should.Here’s how to not waste time on code reviews.Keep it SimpleMa转载 2014-09-09 06:56:05 · 4483 阅读 · 0 评论 -
源代码主干分支开发四大模式
主干分支开发四大模式:1,先锋主干多稳定分支;2,守护主干多先锋分支;3,主干无分支;4,守护主干单分支。原创 2014-08-16 16:09:33 · 25300 阅读 · 0 评论 -
谈谈产品开发团队的配置管理规则
作者:张克强 作者微博:张克强-敏捷307在《源代码管理的新15条建议 》中的第7条建议提到:每个团队应当对代码配置项和非配置项有所说明,不要假设每个团队新人都是代码配置管理达人,小心自以为是的新手加入一些自以为是的垃圾。虽然可以删除,但发现再删除,其本身就是成本。在《高效组织的配置管理计划》也提到了产品线层面的配置管理,那么产品开发团队的配置管理到底应该是什么样呢?本文试图来探讨下。首先说原创 2014-08-23 18:05:10 · 4710 阅读 · 0 评论 -
源代码管理的新15条建议
建议之1:使用好的配置管理工具,也称为版本控制工具(Version Control), 比如Git,SVN。 建议之2:抛弃古老的配置管理三库做法,常说的三库是指开发库(动态库)、受控库和产品库(静态库);做法是开发库->受控库->产品库。 在当年没有强大版本控制工具的“古代”,三库做法是不得不的选择,而在现代版本控制工具(比如CVS,SVN,Git等)的支持下,三库做法变得落伍了。建议之3:纳入配置管理的文件的名称里不要含有版本号。原创 2014-08-12 06:41:33 · 21547 阅读 · 1 评论 -
代码夹带是洪水猛兽吗?
什么是代码夹带代码夹带是一个并不陌生的词组。一般的理解是在正常的代码中夹带入别有用心的其它代码。通过网上搜索,得到如下:其通常在计算机正常的程序传播当中将额外的一段代码夹带着,对计算机的网络安全造成破坏。从表面上看来,其不会对计算机进行主动攻击,但是只要安装了正常程序,而该程序...知道任何保密条款也无法阻止员工夹带代码出去。您必须保证您是诚实的,稳定的;由于我们的程序非常复杂(仅PHP文本就3G原创 2015-02-01 11:08:48 · 2133 阅读 · 0 评论 -
关于软件项目工作量估算的若干问题
作者:张克强软件项目工作量估算从估算依据上看可以分成如下两类:1,基于规模估算2,基于工作量估算基于规模估算的情况下,需要估算软件项目的规模。本文首先来看规模方面的问题。问题1:如何表达规模?软件产品或项目的功能规模是涉及软件开发和交易的成本、项目资源投入的预测、项目维护成本的预算、项目质量管理的要求以及产品上市的时间等方面的关键指标。因此,进行软件产品的功能规模测量显得尤其重要。如何测量软件规模原创 2015-01-01 10:40:38 · 13251 阅读 · 0 评论 -
大敏捷之我见
写在前面-大敏捷的缘起2017年4月我有幸受李建昊老师邀请在光环敏捷2017春季峰会上做一个演讲,事先我准备了话题。由于我一直偏向把scaled/scaling Agile 翻译成大规模敏捷,所以之前提交的演讲标题是xxxx大银行大规模敏捷xxxxxxxxxx。这个标题太长了,建昊老师在交待光环印刷作业时把规模两字去掉了,话题改为“跨国大银行大敏捷和DevOps实例分享”。4月14日是峰会前一天晚上原创 2017-05-08 19:00:16 · 926 阅读 · 0 评论 -
新一代软件工程的标配:持续集成
敏捷软件开发从提出到现在有16年了,经过16年的考验和沉淀,有些实践也许已经不再使用,或者仍然存在争议,而持续集成这个实践愈发显示出其突出的位置,可以预见其将成为新一代软件工程的标准配置。持续集成最典型场景在代码提交后5分钟之内,代码被编译并测试通过,程序员进入到后续工作,或者代码被编译并测试不通过,程序员在约定的15分钟内修复了,持续集成通过,程序员转入后续工作;或者15分钟没有修复,回滚到上个持原创 2017-05-15 10:47:00 · 846 阅读 · 0 评论 -
敏捷和DevOps词汇表
本词汇表是旨在说明敏捷与DevOps中各种术语。 由于敏捷与DevOps存在紧密的联系,在讲述DevOps时需要引用到大量的来自敏捷的词汇,因此本文试图做些整理 词汇名称 对应英文 说明 重构 Refactor 指保持某个对象的外在行为不变,优化其内部结构。代码重构是重构的一种。 代码重构 Code refactor 保持程序代码的外在行为不变,优化代码。在面向对原创 2016-11-23 22:39:10 · 4203 阅读 · 0 评论 -
团队章程---促进团队合作
团队章程是提供指导原则、规则并管理团队成员行为的方针政策。[1]章程应由团队成员共同完成,并为所有成员服务。在团队章程中团队成员可以约定相互权力和义务,制定团队行事的基本原则,并设计面临突发事件时的应对措施。在实践中,一些质量团队的章程可以将质量目标和组织绩效目标联系起来。现代组织中很多团队中存在不同程度的人际信任、相互依存和共同责任问题,团队在动态发展中的内在”摩擦”是现实存在的。团队章程可以最大原创 2016-08-24 08:23:55 · 4803 阅读 · 0 评论 -
苍狼敏捷软件开发团队建设指南-1-团队模型
前言目的本团队建设指南的目的是帮助项目来定义和控制项目团队如何建立、如何运作来达成项目目标。范围适用于项目团队人数少于等于25人的项目。概要1.苍狼敏捷团队模型得到了描述,为项目团队组建提供了框架性的指导; 2.根据项目目标、实际情况和团队模型,组建项目团队; 3.指导团队下一步工作的团队章程由所有团队成员一起来制定; 4.推荐采纳合适的团队建设活动来使得团队工作作更有效、高效;原创 2016-06-14 15:29:18 · 7274 阅读 · 0 评论 -
需求评审五个维度框架分析及其带来的启示-3-典型需求评审
典型情境是指软件开发的常见情境,本文选择如下来进行分析: 1. 传统瀑布模型开发下的需求评审 2. 使用IEEE Std. 1028的需求评审 3. 敏捷开发下的需求评审传统瀑布模型下的需求评审对传统瀑布模型现有需求评审的分析传统瀑布模型在需求阶段末期安排有关键的需求里程碑评审,其特征参见2.8节情况1。在业界实际操作中,往往出现如下情况: 1,召集包括领导在内的各方代表,历经1~2小原创 2016-06-09 10:21:08 · 14617 阅读 · 0 评论 -
需求评审五个维度框架分析及其带来的启示-2-框架原理
本文试图归纳分析近年来出现的需求评审方式方法,全面涵盖系统性评审和非系统性评审,提出五维需求评审框架。首先确定对于需求评审的定义,结合传统需求阶段评审和敏捷迭代开发中相关需求实践,得如下定义。 定义1(需求评审). 需求评审是指基于需求文档阅读或者观察软件运行并且对当期工作有时效性的人工检查。根据以上定义,需求评审的范畴不包括机器自动检查,不包括需求审计;包括了需求上线后的校对,包括了系统性需求评原创 2016-06-09 10:07:38 · 5833 阅读 · 1 评论 -
需求评审五个维度框架分析及其带来的启示-总起
摘要 近年来随着CMMI、敏捷软件开发的推进,出现了多种多样的需求评审类型,这些类型超出了标准评审类型的范围。根据这些情况进行分析,得到了一个新的软件需求评审框架,这个新框架由5个维度组成: 1,组织形式;2,时机;3,侧重;4,评审者;5,对象 分析了分别在传统开发和敏捷开发下的典型需求评审情境,显示新框架能够适用于所有系统性的和非系统性的评审类型上。从分析中得到了15个有价值的启示。新需求评原创 2016-06-09 09:42:51 · 6699 阅读 · 0 评论 -
#软件配置管理#之坏味道搜集
软件开发热点词汇不断推陈出新,cmmi,agile,精益,持续交付,持续集成,灰度……但有一个词其实一直在那里,支持着各种各样的新热点,它是#软件配置管理#。 它也是影响团队软件开发效率的重大因素。下面来把我微博提到的坏味道归纳下#软件配置管理#之坏味道1:版本控制之下文件名里带版本号#软件配置管理#之坏味道2:通过评审或者发布的文件移到另外一个目录下,而不使用基线/lable/tag版本等等控制原创 2016-01-10 20:08:45 · 1898 阅读 · 2 评论 -
在“软件工程:研究与实践”研讨会上关于UML Use-Case的开放空间讨论
2014年12月20日我有幸参加了复旦大学承办的“软件工程:研究与实践”研讨会。在下午的开放空间活动中,我推荐了UML Use-Case作为6个话题之一,成为了这个话题的主持人。就这个话题与多位老师和业界专家进行了探讨。最后我作为此话题的代表向大家汇报了话题讨论。本文试图来整理记录下当时的讨论。1,在产业界UML和Use Case并没有得到很广泛的使用,能够用Use Case表达出原来SRS表达的原创 2015-01-02 10:56:49 · 2072 阅读 · 1 评论 -
软件设计最近发展趋势对话录
QA美美 15:16 概设和详设,模版究竟涵盖哪些比较合适,更加有效?目前我所接触到的概设,有的主要涵盖的是模块的集成方案,但是现在又遇到的不是以模块间数据流为模版,而是类与类之间的交互,而详设也是对类进行描述 张克强 22:20 概设详设是以前的分法,还有HighLevelDesign和LowLevelDesign的分法。概设往上走,就是现在的架构设计,那么这样的概设到组件或者模块。 概设也可原创 2015-01-01 10:28:22 · 1810 阅读 · 0 评论 -
一个软件项目的总纲性的测试计划叫什么?
一个软件项目的总纲性的测试计划叫什么名字?项目测试计划?测试策略?测试方案? 是不是要包括测试点分析?是不是要包括测试用例?@张克强-敏捷307: 每家公司可能有不同说法,征集大家习惯的说法-你们是如何说反映项目整体测试的这份文档? 包括英文的。 邰晓梅-ChinaTest:这个说法我喜欢“每家公司可能有不同说法”,叫什么名字并不是很重要,只要使用环境内,大家能达成一致理解就行原创 2014-08-08 07:51:52 · 2171 阅读 · 0 评论 -
程序员开发利器:源代码管理的十条建议
英文原版 http://java.dzone.com/articles/10-commandments-good-source转载 2014-08-06 07:34:32 · 8004 阅读 · 0 评论 -
组织敏捷之路上的七点体会
1,专门的机构或专人来推进组织级敏捷,可能的机构名称有:敏捷中心、卓越中心、过程改进部、SEPG、质量部、运营改善部、PMO、Delivery Excellence;可能的专人有:过程总监、质量总监、项目管理总监、Chief Agile Coach。 2,敏捷开发涉及到各项方方面面,就算是采用书本上的某些实践,比如用户故事,各个团队各个组织都有些定制化或改造过的做法,比如新加tech story,原创 2014-06-20 07:46:40 · 4122 阅读 · 3 评论 -
需求用例分析之四:业务规则
在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有“业务规则”的属性,在科伯恩方法中有个相近的属性是约束条件。但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢?从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书。在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物。受到传统需求规格说明书的原创 2014-05-24 21:01:05 · 19827 阅读 · 0 评论 -
需求用例分析之五:业务用例之Rational系
业务用例的定义:"业务用例从一个外部的,增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值,业务用例是超越组织边界的业务过程,很可能包括合作伙伴和供应商。" 围绕着业务用例的使用起源于RUP,后续虽然有演化,仍然有明显的RUP痕迹,后续配套手段需要UML工具支撑,后续可以关联到了类和类图。相关于业务用例的术语在RUP中有:业务用例,业务用例实例,业务用例实现,业务角色,业务实体,具体业务用例,抽象业务用例,业务流程,业务参与者和业务执行者等等。除了搞需求方法论研究的人(比如笔者),谁还能分辨其中原创 2014-06-02 21:35:14 · 4098 阅读 · 0 评论 -
“码农”刍议
作者:张克强 作者微博:张克强-敏捷307昨天在微博闲逛,发现一则转发有奖ScrumGathering门票的微博,是@developerWorks 发的,顺手转了一个问道:是ibm的吗?后来定睛一看,发现其推广的是《码农周刊》。对于曾经试图搞”程序员工会“的我而言,看到后真是有点不舒服,又回了如下微博。能不能把码农周刊换个名字啊?比如代码之语,码上周刊,源码动力周刊,码动周刊原创 2014-06-03 05:18:25 · 3023 阅读 · 5 评论 -
需求用例分析之三:补充规约
补充规约在RUP中是记录那些在用例模型的用例中不容易体现出来的系统需求。这些需求包括: § 法律法规方面的需求和应用标准。§ 要建立的系统质量属性,包括可用性需求、可靠性需求、性能需求和可支持性需求。§ 其他需求,诸如操作系统和操作环境、兼容性需求以及设计约束。补充规约是对用例模型的重要补充。补充规约和用例模型应该一起获取对系统的一整套需求。通过以上文字可以知道,补充规约是原创 2014-05-18 20:26:02 · 6497 阅读 · 0 评论 -
说说软件需求说明
软件需求说明,也称软件需求说明书,或者软件需求规格说明,或者软件需求规格说明书, 对应的英文是Software requirements specification, 缩写是SRS。软件需求说明是软件系统需求的规格化说明,是对将要开发系统的行为的说明。它包括功能性需求,也包括非功能性需求。传统软件需求说明书章节示例根据中国大陆GB8567-88 计算机软件产品开发文件编原创 2014-04-29 07:12:49 · 2711 阅读 · 0 评论 -
基于用例点来度量软件规模并管理进度 之一
本文针对软件项目的规模度量和进度管理,提出了一种新的以用例点的方式来表达和跟踪的方法。本文详细介绍了经过调整过的用例点度量方法,舍弃了角色对应的用例点数,对用例分类给出了更严格的要求,采用了更细致的步骤定义,并限制了复杂用例的最多步骤。用例的状态完成度得到区分,在此基础上建立了过程中用例的进度跟踪方法。最后并阐述了在需求可复用情况下的使用方式。原创 2014-04-27 16:59:44 · 3100 阅读 · 0 评论 -
基于用例点来度量软件规模并管理进度 之二
用例点表达进度识别用例的状态根据生命周期要求,识别用例的状态及转移。典型的如瀑布型,一般依次有如下状态:用例识别,用例确认,用例已设计,用例已编码,用例已测试。 采用测试驱动开发(TDD)的一个例子,依次状态:用例识别,已写测试用例,用例已编码,用例已集成,用例已测试。最简化用例状态,依次状态:用例识别,用例已集成。从以上例子可以看到,传统生命周期和敏捷方法都可以原创 2014-04-27 17:07:19 · 1497 阅读 · 0 评论 -
基于用例点来度量软件规模并管理进度 之结束语
这篇文章是我在2009年到2010年写完成的。原创 2014-04-27 17:33:59 · 1316 阅读 · 0 评论 -
基于用例点来度量软件规模并管理进度 之三
复用后的规模估算需求复用在需求可复用的情况下,识别可复用的用例所占的完成度,求和可得初始折算已完成用例点数,规模数据为全部用例点数减去初始折算已完成用例点数,以折算已完成用例点数来跟踪进度时,注意起点不为0;如果是绘制燃尽图,起点也不是全部用例点数。例如:某小版本的任务是开发实现100个用例点,用例分析已经由另一个异地团队完成了,根据两个团队的历史数据和协定,用例分析所占完成度原创 2014-04-27 17:19:58 · 1574 阅读 · 0 评论 -
需求用例分析之备选流
#用例分析#之备选流 alternative flow-这是用例方法中最混淆之处,无论中文还是英文,都出现许多不同的理解和不同的做法。问题在于备选流字面意思模糊,可以是可选的不同做法,也可以说异常,也可以是导致失败的情况。可叹的是,其原定义是清楚的:无法达成用例目标的情况。但它起了个不恰当的名字也许是因为这个混乱,导致出现了“主成功场景”替代基本流,“扩展场景”来替代备选流的做法。这与用例的优原创 2014-04-24 06:56:59 · 6752 阅读 · 0 评论 -
需求用例分析之六:业务用例之科伯恩系
业务用例与系统用例具有相同的特征,因此编写和评审用例的方法对两者都适用。在业务用例中说明的东西,也会在系统用例中说明。这形成了系统用例和用户用例之间的合作。但这样带来了两个坏消息。第一:编写者和读者经常把二者弄混,可能把系统行为放入业务用例中,也可能把业务操作归于系统用例。如果能够商量着去做将会有所帮助。但通常编写者和读者不会认识到这样做的重要性。使用系统用例的读者批评业务用例所处层次太高,但却没有认识到提供系统详细的行为细节不是业务用例应该做的;业务用例编写者偶尔把系统行为细节写入其中,结果导致业务主原创 2014-06-06 05:32:53 · 2902 阅读 · 0 评论 -
需求用例分析之九:序列图
作者:张克强 作者微博:张克强-敏捷307序列图,也称时序图、顺序图,英文名Sequence Diagram。在雅各布森用例分析方法中鼓励使用各类图形来表达,但恰恰没有明确提到序列图。而科伯恩用例分析方法以结构化/半结构化文本用例为中心,强调基于目标的文本格式,对UML各类图所提甚少。在RUP和OOAD中,UML序列图的最基本定位是用于识别类与类之间的信息传递,是识别类的方法的最佳场合。它是原创 2014-06-25 21:00:20 · 5415 阅读 · 0 评论