分类目录归档:软件项目与过程管理

解决SVN 从branch 合并到trunk时出现“Reintegrate can only be used“ 的问题

通常情况下我们会在working copy下通过右键菜单选择Merge,然后选择Merge from连接,将某个branch合并到当前工作目录,然后提交。

但是今天却出现了如下错误:

Reintegrate can only be used if revisions 5265 through 5689 were previously
 merged from
 https://192.168.XXX.XXX:XXX/svn/ProjectAliceVR/AliceOperationAgent/trunk to the
 reintegrate source, but this is not the case:
  AliceOperationAgent/branches/AliceAgent3.1b5264
    Missing ranges:
 /AliceOperationAgent/trunk:5283,5297,5325,5391,5489,5496,5514,5554,5591

原因可能是trunk目录下有几个目录是跟另一个项目共用的,是通过在属性中增加external链接导入到这个项目里的,而那个项目之前已经从分支合并到了trunk,导致这边的这个项目认为这几个目录已经合并过了,所以出现了如上面的错误,当然这也只是猜测。

网上也有一些解决办法,主要参考这个链接:

https://blog.csdn.net/qian_348840260/article/details/61923627?utm_source=blogkpcl8

和这个链接:

https://stackoverflow.com/questions/4737605/reintegrate-can-only-be-used-if-revisions-x-through-y-were-previously-merged-fro

我们的根本目的无非就是从brunch合并brunch中的修改到trunk,所以我想到的解决办法也许更直接一些:

1、通过svn show log,浏览brunch中的修改记录

2、按住Shift或Ctrl,结合鼠标选择要合并到trunk的修改记录

3、在选择的修改上右键单击鼠标,选择“Merge revisions to…”

4、弹出目录对话框“Select merge target”对话框,选择要将变更合并到哪个工作目录

5、合并就开始了

6、合并过程中会出现一些冲突而使合并中断,没关系,点击OK退出合并对话框

7、解决这些冲突,然后继续走上面的1~7步,直到完全合并为止

8、拷贝修改记录、提交变更

合并完成后就可以提交了,但是提交记录最好保留之前在分支中的提交记录。在选择要合并的变更时,对话框中其实已经提供了修订记录,可以直接拷贝过来,这个真的非常重要:

全选后粘贴到提交对话框即可。

总结:指定要合并的某一条或某几条变更,然后合并,这招既直接又可靠,值得推荐!

15道烧糊大脑的苹果面试题

以下15道题是从求职论坛GlassDoor摘选出的真实的苹果面试题目:

1.桌子上放着一部老款iPhone。你所了解的iPhone使用的材料有哪些?

面试职位:产品设计工程师

苹果产品设计工程师的重要任务之一就是控制供应成本,以降低手机的价格。

苹果的手机定价非常具有竞争力,因此面试者必须懂得如何在特定成本区间内设计产品。懂得材料及其性质能够帮助设计师在维持低成本的同时设计出更好的产品。

2.形容一下你平时使用苹果产品的情况。

面试职位:销售

如果你想销售苹果的产品,你最好已经是苹果产品的用户。

不用说,苹果当然不会雇佣一个从来没有使用过iPhone的人做销售。

3.如果有500台洗衣机被测试实验室认定为不合格,你如何找出不合格的原因以及解决办法?

面试职位:产品质量工程师

如果制造过程中出现任何故障,你可能会失去价值数相当于百台iPhone的收入–这个数字也有可能是数万台或数十万台。

如果你想担任产品质量工程师,那么请首先确认,不管出现什么问题,你都能发现故障并找出原因所在。尤其是当问题出现在供应链早期的时候,这一点更加重要。

4.在极其有限的资源环境下,如何在user-space框架下实现处理网络、文件系统、UI系统等的线程模型?

面试职位:软件工程师

编写一组代码并使之运行非常容易,但要让它高效率运行却很难。

尤其是如果你在为一款手机设计软件。你必须使用低功耗的芯片,以维持较长的续航时间。

5.你如何计算出中国供应给美国的苹果的数量?

面试职位:材料项目经理

面试官所指的是苹果。你懂的,一种水果。

但这仍然是一道相当基础的供应链题目。如果你要担任供应链管理职位,你需要清楚地知道供应商有哪些,他们能提供的材料有哪些。

苹果优势的一个重要来源就是,他们买断了制造智能手机所需的所有最好的零部件。如果你对整个供应链都了如指掌,你就能降低成本。

6.使用运算放大器设计一个LED驱动电路。

面试职位:硬件工程师

许多情况下,你设计的产品不会工作在最适宜的环境下。有时会太热,有时会太冷,甚至会掉进水里。

你必须保证你的硬件在这些非最佳环境下仍然能够运行。

7.你如何诊断缓冲区溢出?

面试职位:软件工程师

许多时候,判定一个工程师是否属于最优秀的行列,最好办法就是问他们如何解决一个问题。

如果出现缓冲区溢出,结果可能是灾难性的。因此,如果你想测试手下的工程师面临极端问题时将会如何反应,这个问题很适合。

8.现在有100个标记过的电灯泡。第一个人经过这些灯时,点亮所有的灯,第二个人经过时每隔一盏灯就切换开关一次,第三个人经过时每隔两盏灯切换开关一次。请问,当第100个人经过时,还剩多少盏亮着的灯?

面试职位:高级软件工程师

苹果面试官们并非全部使用原创的面试题,他们有时也会使用可汗学院(Khan Academy)设计的脑筋急转弯。

但是,这道题仍然是一道需要运用巧妙数学原理解决的很复杂的题目,很适合测试工程师解决问题的能力。

9.你平时看科技新闻多不多?

面试职位:Mac天才

如果你想在苹果零售店里工作,你需要知道普通大众对苹果在新闻上的印象如何。

面试官想知道你是否平时经常看TechCrunch、瘾科技或腾讯科技。

10.现在有一个6×6的方格,从左上角的点出发,只能向右或向下移动,请问到达右下角需要多少步?

面试职位:高级软件工程师

这种问题被称为步数计算题。这是最基本的测试思维方式而非要求正确答案的题目之一。

苹果会问高级工程师这种脑筋急转弯,这似乎并不让人觉得惊讶。

11.你如何确定表面曲率的连续性?

面试职位:CAD雕塑师

苹果会制造非常多的设备模型,如iPhone和iPad的原型机等。这些都需要经过严格的测试,因此苹果需要招聘能够快速做出模型的人。

但这些模型仍然需要与苹果的其他设备一样完美。因此,苹果必须确定雕塑师和设计师拥有完美主义特质,即便是玻璃的形状也要精益求精。

12.在一个相互连接的点组成的列表中,找到中间节点。

面试职位:Cocoa camp

苹果希望软件工程师能够给出一个巧妙的解决方案。

例如,可以使用两个“指针”,其中一个指针顺着每一个点依次通过,而另一个指针则每走一步跳过一个点。当第二个指针达到终点,第一个指针刚好达到中间节点。

13.如果你能为远程控制功能新增一项技术,你希望增加什么样的技术?

面试职位:天才吧Specialist专家

这个问题很古怪–或许苹果是在测试面试者是否为iPhone粉丝。

天才吧的Specialist必须是大大的苹果粉丝。

14.想出5种在铁板上打洞的办法。

面试职位:产品设计工程师

苹果希望设计和硬件工程师既对技术无比精通,同时富有创新精神。

因此,即使是在铁板上打一个洞这么简单的事也可能有多种办法。苹果在测试面试者的创意能力。

15.你高中时期最容易进入或最适合的社团是什么?

面试职位:天才吧Specilist专家

如果你需要一眼看出零售店内哪些人更有可能买苹果产品,你必须拥有慧眼识人的能力。

Specialist必须将顾客进行分类,然后尽快弄明白他们是否真的想购买某种产品。想购买产品的那些人往往都有一些共同点。

本文摘自网络

软件开发四大过程

一、 需求分析阶段

任务:建立用户需求和功能模块,确定系统中的角色和使用案例。利用ROSE,生成角色,使用案例和生成用例图

所用到的框图:

1.       Use-Case Diagrams

显示使用案例(表示系统功能)与角色(人或系统)间的交互。如下图:

Use Case(用例):在不展现一个系统或系统内部结构的情况下,对系统或系统的连贯的功能单元的定义和描述。

角色:使用软件的人或外部系统本身。

2. sequence diagram

按时间先后顺序,从上到下分析使用案例,确定案例的处理流程。如下图:

 

3 Collaboration diagram

确定对象之间的关系的处理过程的分析流程。如下图:

 

二、 概要设计阶段

任务:通过分析Use-Case Diagrams ,得到所用到的类,分析这些类的属性、操作和它们之间的关系。

所用到的框图:

1.Class Diagrams.

显示系统中类与类之间的交互。

 

2.包:具有一些共性的类组合在一起的图。

 

三、 详细设计阶段

任务:细化和个性Use-Case 的描述 ,如类的操作和对象之间的消息相对应,填充参数及复杂的类的

设计。

所用到的框图:

1.Class Diagrams

2.State Diagrams:显示一个对象从生成到删除的生命周期。

四、 编码和测试阶段

任务:进行软件的开发和测试,生成组件框图。

组件:表示代码的物理模块。

组件框图:表示系统中的组件及相互依赖性。

Delpoyment Diagrams:显示网络中的物理布局和各种组件的位置。

如何做好需求收集[来自《程序员》第2期]

项目前期需求收集过程的效果好坏,会对软件产品的最终质量产生直接的影响。如何收集好需求,本文作者给出了一条行之有效的实际操作途径。

什么是需求收集?

需求收集,是确定和理解不同类别用户的需要和限制的过程,是需要高度协作的活动,是在问题及其最终解决方案之间架设桥梁的第一步,因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因,是由于忽视了用户需求。

需求收集在需求开发活动中的示意图如图1:


如图1

需求收集为什么会困难?

困扰项目组需求收集活动的原因可能如下:

v 需求收集人员往往只关注用户反映的表面问题,而不能主动深入挖掘用户的真实需求;

v 需求收集人员考虑的问题时习惯干“以产品为中心”,而不是“以客户为中心”;

v 用户往往不清楚自己的真实需求是什么,或者不知道如何准确地描述出自己的需求—“我心里很清楚,但就是说不出来”;

v 没有从所有可能的渠道去收集需求,需求信息来源不完整;

v 收集的需求没有规范记录下来,造成原始信息丢失或失真,且无法回溯;等等。

怎么做好需求收集活动?

首先,需要建立需求收集机制。其次,使用统一的需求收集系统。最后,在需求收集时,采取一定的技术和方法。

建立需求收集机制

(1). 明确每个需求收集活动参与者的岗位职责

根据项目组可能的需求来源(需求来源可能包括:市场调研,竞争对手信息分析,标准和协议等等,视项目组的实际情况而定),指定每个需求来源的收集负责人。同时,对通过各个渠道收集的需求信息,指定专门的接口人进行汇总和审核。

(2). 建立需求预处理流程

对收集到的需求,除了指定专门的接口人进行汇总和审核以外,还要建立相应的预处理流程,在对需求进行预处理时,相关的讨论,决策可以通过“需求CCB会议”完成(需求CCB是指:专门用于需求讨论和决策的Change Control Board)。

一个对收集到的需求信息的预处理流程例子如图2:

如图2

项目组可以参考上例,结合自身实际情况进行适当剪裁,建立适合自己的预处理流程。

(3). 周期性的重复需求收集活动

当产品处于研发过程中,或已经交付给用户使用后,项目组还需要定期从各个来源重新去收集和审视一下产品的所有相关需求,这样就可以及时获知市场和用户对产品的反应,为下一个步工作提供输入和依据。项目组可以依据自身产品的特定,指定周期性的需求收集策略,选择相应的时机。

使用统一的需求收集系统

很多项目组都采取表格的方式记录收集到的需求信息,而不是通过电子流程的方式提交,这样会到来一些问题,如:收集到的需求信息被延迟处理,项目信息无法跟踪,回溯,等等。因此,项目组有必要使用统一的需求收集系统,作为唯一,明确的入口,对需求信息进行填报和跟踪。

企业可以选择自己开发电子的需求收集系统,也可以选择购买市场上现有的产品,如:Telelogic公司的Focal Point等。如果使用自己开发的需求收集系统,就可以让系统流程和企业的业务流程相结合,而且日后维护和扩展也比较方便。

一个需求收集的二维流程图实例如图3:


如图3

在实际工作中,需求收集系统还可以和需求管理系统,变更控制系统等通过一定的接口实现集成,共同构成企业的综合需求管理平台,从而提供“完善的需求管理解决方案”。一个公司级综合需求管理平台搭建的实例如图4:

如图4

采取一定的需求收集技术和方法

在需求收集时,还应采取一定的技术和方法。一些常用的需求收集技术和方法包括:客户访谈,客户交流,市场调研,技术支持,高层拜访,竞争对手分析,查阅媒体信息,需求专题分析讨论会等等。

下面选取几种技术和方法,通过一些案例分析,进行更为详细地阐述。

(1). 客户访谈

案例分析1:某次客户访谈

ü 访谈时间:选择45-60分钟比较合适。

ü 访谈地点:选择比较宽松的非工作环境进行。

ü 访谈问卷:在访谈之前要事先设计访谈问卷,要注意的是问卷只是提供一个思路。

ü 填表方式:不要采取让客户直接填表的方式。

ü 录音:前提不要让客户发现或是事前征求客户的同意。

ü 访谈结束:再次确认,每次访谈后要优化访谈的提纲以备下次使用。

(2). 客户交流

案例分析2

交流前的沟通:充分与客户沟通交流,重点可以以下角度考虑问题:

ü 本次客户关系什么内容?
参与人是谁?
主要决策者有哪些倾向性的观点?

ü 竞争对手可能方案的卖点?主推什么?

ü 我们要住推什么?怎么避免我们的弱点?

ü 客户预计会提那些问题?我们应该怎么回答?

ü 交流会的讲解重点:在交流会上,可以选择以下讲解重点:

ü 客户面临的问题是什么?

ü 针对客户面临的问题,我们的解决方案是什么?

ü 我们的总体方案如何?

ü 今天交流的内容在公司总体方向中的位置?

此外,在交流时还可以自己设计一些问题并加以回答。特别需要注意的是,在交流的时候不要攻击竞争对手,但是可以多讲一些自己的成功案例和优点。

交流后的工作:交流之后,还需要完成以下工作:

ü 分析记录和答疑;

ü 提出项目的应对策略建议;

ü 对交流会上遗留的问题进行跟踪直至关闭;

(3). 需求专题分析讨论会

需求专题分析讨论会的目的,是在较短的时间内鼓励与会者在需求上达成共识,尽快取得统一意见。需求专题分析讨论会通常邀请客户代表参加

案例分析3

会前准备

ü 确定所有相关的干系人,不要有遗落;

ü 事先做好会议后勤保障;

ü 事先准备会议相关材料,需求文档初稿,调查问卷,相关清单;

ü 找合适的主持人:善于控制时间,维持会议“规则”,制定会议目标和议程,能够调动所有人员积极参与。

会议举行:

ü 制定会议纪律并宣布;

ü 支持人要把握好会场气氛,并及时化解矛盾;

ü 记录人要做好会议记录

ü 参与人员使用投票方式确定需求优先级;

ü 发言人的发言时间不得超过一定长度,不能打断;

会后工作

ü 把会上收集到的意见归类;

ü 记录讨论后的需求;

ü 确定下一步工作;

结束语

需求收集在客户问题及最终解决反感之间起着架设桥梁的作用,从某种程度上来讲,需求收集工作的质量决定了产品的成败,因此我们必须加强对其的重视。为了做好这项工作我们需要建立日常的需求收集工作机制,并采用统一的需求收集系统作为信息入口;同时,由于需求收集是统一的讲求技术和方法的活动,选择和的技术和方法有助于获取完整且有效的需求。

软件需求分析文档

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步,是确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

软件需求分析的任务是:深入描述软件的功能和性能,确定软件设计的约束和软件同其他系统元素的接口细节,定义软件的其他有效性需求,借助于当前系统的逻辑模型导出目标系统逻辑模型,解决目标系统“做什么”的问题。

需求分析可分为需求提出、需求描述及需求评审三个阶段。

需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域,并定义一个描述该问题的系统。这样的定义称作系统规格说明,并且它在用户和开发人员之间充当合同。

在问题分析阶段分析人员的主要任务是:对用户的需求进行鉴别、综合和建模,清除用户需求的模糊性、歧义性和不一致性,分析系统的数据要求,为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来,以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求,哪些是用户尚未提出但具有真正价值的潜在需求。

在需求评审阶段,分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核,以确保软件需求的完整、准确、清晰、具体,并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点,必须尽快更正,再行检查。

软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解, 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下:

  1 引言

1.1编写目的

说明编写这份软件需求说明书的目的,指出预期的读者。

1.2背景

说明:

a.待开发的软件系统的名称;

b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;

C.该软件系统同其他系统或其他机构的基本的相互来往关系。

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出用得着的参考资料,如:

a.本项目的经核准的计划任务书或合同、上级机关的批文;

b.属于本项目的其他已发表的文件;

c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

  2 任务概述

2.1目标

叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|

2.2用户的特点

列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束

2.3假定和约束

列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。

  3 需求规定

3.1对功能的规定

用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。

3.2对性能的规定

3.2.1精度

说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。

3.2.2时间特性要求

说明对于该软件的时间特性要求,如对:

a.响应时间;

b.更新处理时间;

c.数据的转换和传送时间;

d.解题时间; 等的要求。

3.2.3灵活性

说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:

a.操作方式上的变化;

b.运行环境的变化;

c.同其他软件的接口的变化;

d.精度和有效时限的变化;

e.计划的变化或改进。

对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。

3.3输人输出要求

解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。

3.4数据管理能力要求

说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。

3.5故障处理要求

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.6其他专门要求

如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。

  4 运行环境规定

4.1设备

列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:

a.处理器型号及内存容量;

b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;

c.输入及输出设备的型号和数量,联机或脱机;

d.数据通信设备的型号和数量;

e.功能键及其他专用硬件

4.2支持软件

列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。

4.3 接口

说明该软件同其他软件之间的接口、数据通信协议等。

4.4控制

说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。

 

讨论一下怎么写需求文档

作者:iFire

先谈谈我的想法。

一、要讨论怎么写需求文档,首先就的搞清楚需求的构成,我是这么分的:
1、功能需求;
2、非功能需求或技术需求;

我一般把功能需求划分为几个部分:
a、业务过程;
b、业务规则;
c、业务数据;

非功能需求(技术需求)我就不多说了,大致就是可用性,可靠性,性能,可支持性等等。

二、弄清楚需求的构成后,我们就得考虑以什么样的文档结构来描述这些需求了,UP的做法是这样的:
1、用例规格说明描述业务过程;
2、业务规则文档描述业务规则;
3、术语表描述业务数据;
4、补充规格说明描述非功能需求(技术需求);

UP的做法还是很有道理的。这体现了两个原则:
1、分离关注点(每个文档描述相对独立的领域);
2、减少重复(很多用例都会引用相同的业务规则及业务数据);

这样便能够尽可能的使文档结构清晰,易阅读,易理解。也便于跟踪和维护。

但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航,你可能需要打开多个文档进行交叉阅读。这是比较麻烦的,特别是对于用户来说。

而且UP中每个用例都单独作为一个文件存在,这可能是为了便于跟踪及管理的缘故吧。但正如上所述,文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中(比如根据子系统划分)。

至于交叉阅读,导航困难的问题是否有什么别的方法解决呢?html文档似乎不错。不过写起来似乎没word方便啊。

三、总结:
无论怎么写需求文档,最终的目的无外乎易阅读,易理解,易沟通,易确认,易跟踪,易测试,易验收。我想我们都应该以这个为目标来进行思考。

如何编写优质的需求文档

作者: Job Vranish  来源: 伯乐在线  发布时间: 2012-03-21

英文原文:How to write good requirements

编写需求文档,在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务,协调大规模的研发计划。对于最终的产品,需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候,便可以发挥巨大的作用。然而,如果你在嵌入式开发领域工作的时间足够长,你就会很快发现,这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时,你又会很快发现,书写正确的需求文档绝非易事。在这里,我们提出一些建议,希望能将书写正确需求文档这件事情变得清晰一些。

从较高的层次来看,书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述,并需要注意以下细节:

  • 工程师可以根据系统所说进行实现
  • 测试人员,在不与开发人员沟通的前提下,可以利用满足硬件要求的设备验证需求。
  • 最终产生的成果满足终端用户的要求。
  • 黑盒测试

书写优质的需求文档:

最基本的原则是:需求文档应当尽量简洁,用最易懂的描述来约束系统的预期行为。如果你遵循这个原则,剩下的那些重要因素(可测试性、避免过度设计等等)都将变得顺理成章。

列举一下更详细的规则,通常会更有帮助。下面是书写优质需求文档需要遵循的步骤:

1. 定义系统的边界。这也是黑盒系统所必要的。

2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。

3. 用最易懂的方式描述系统的预期行为

4. 除了输入和输出之外,你的需求是不是还涉及了系统的其他部分?如果是,那么你的需求就设计过度了。重构需求,让它变得精简。

5. 你的需求是不是过于模棱两可?加入更多的限定规范。注意:有些模棱两可的描述并不是坏事,假设描述所包含的所有情况均可被接受,且测试的时候不需要附加的信息加以说明,那么就没关系。你不需要(也不应该)把系统的行为限制得过头。

6. 你的需求是否可测试?(这里指的是黑盒测试)如果不是,你最好返回到第 4 步。如果这种返工发生很多次,那就说明你的黑盒无法正确描述系统,或者你的测试工具不够优秀。无论是哪种情况,不可测试的需求文档几乎就是一文不值的。

7. 你的需求文档通俗易懂么?如果你的需求文档非常难以读懂,那就说明你写得不好,只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样,回到第 3 步。

8. 你是不是真的做到了第 4 步?你确认么?再检查一下。

例子:下面的例子,让我们描述一个自制的嵌入式设备的需求,这个设备能从弯曲传感器上读取弯曲的频率,并根据不同的频率值让一个 LED 闪烁。

显然,我们已经完成了步骤 2 和步骤 3 了!

· 输入:从弯曲传感器读取数据。

· 输出:LED。

但是我们跳过了步骤1:

· 在这个例子里,我们将把黑盒画到设备的微处理器上。

让我们继续往下进行,

第四步:除了输入和输出以外,我们是否还涉及了其他的系统边界?

· 微处理器并不关心从弯曲传感器读取什么样的数据,从处理器的角度来看,仅需要做的是测量 ADC 脚的电压而已。

· LED 仅由数字输出脚控制。

下面,让我们来修正这个问题:

第 0 版本的需求:

1. 该设备应当根据 ADC 脚的不同频率的电压,来切换数字输出端的状态。

第五步: 需求写模棱两可么?

恩,我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧:

版本0.1

1. 输出端应当由一个自由活动的定时器进行控制

2. 自由运行定时器的频率最高不得高于每秒 10 次,不得低于每秒 1 次.

3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化,并与 ADC 端的输入电压成正比.

4. ADC 端的输入电压应当每 100 毫秒读取一次

5. 当 ADC 端的输入电压端被读入时,控制自由运行定时器周期时间的注册值也应当被更新.

6. ADC 输入端的电压有效范围应当被控制在 0 到 1 伏之间.

第六步: 你的需求是可测试的么?

· 首先,自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试,它既不是输入也不是输出,而且跟这两者也没有什么联系。

让我们用“数字输出端变化的频率应控制在每秒 10 次和每秒 1 次之间”来代替自由运行定时器的测试标准。

· 对于上述的第四条需求,可能需要一些小修改才能作为测试标准。让我们用“ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次”来加以描述,这样的描述能让我们预期的测试行为显得更加通俗易懂。

· 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在 0 到 1 伏之间呢? 总不能给个 2 伏的电压,然后看看元器件有没有被烧毁吧?

那么,说“检验系统在 ADC 端输入电压为 1 到 2 伏之间的时候,工作是否正常”,这样就检验就容易多了。需求描述应当是“正面”的,应当描述设备“应该”的行为,而不是设备“不应该”的行为。否则的话,测试将会无法进行。

版本0.2

1. 数字输出端的切换频率应当控制在每秒 10 次到每秒 1 次之间

2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化,并与 ADC 端的输入电压成正比

3. ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次

4. 检验当 ADC 端的输入电压范围在 0 到 1 伏之间的时候,系统工作是否正常

第七步:你的需求是否通俗易懂?

相比于我们原来的描述:“根据弯曲传感器的输出不同频率来控制 LED 闪烁”,我们上面的那些需求描述显得难以阅读和理解。

我发现,让需求文档变得通俗易懂,最简单办法莫过于,把过于细节的东西抽取出来,然后以条目的形式单独定义。

版本1

1. 弯曲传感器应当保证至少在 100 毫秒内读取一次数据(放到注释单独列出)

2. 切换 LED 的状态,使其与弯曲传感器的读数保持一致

3. 当弯曲传感器的读数为 1 伏特时,LED 状态切换的次数应当保持在平均一秒十次;当传感器的读数为 0 伏特时,LED 的切换次数应保持在一秒 1 次。

定义:

· 弯曲传感器:输入电压位于 ADC 的X端。安全电压范围为 0 到 1 伏特(放到注释单独列出)

· LED 状态:数字状态由Y端输出

这样就好多了(尽管还不完美)。这些需求通俗易懂,不涉及到系统内部实现,且易于测试。对于系统行为的限定也仅仅限于需要做什么,点到为止。(例如,对弯曲传感器的采样频率,在实现上也可以更高,只要不产生非预期行为,一切都可以)。

编写需求就仿佛是在大脑中构建软件的过程。因此要重于实作。

编译:伯乐在线 – 黄小非

一个标准的软件开发流程步骤及文档

一个标准的软件开发流程需要有哪些步骤,写哪些文档?
1、先是需求调研,出《需求文档》;
2、 然后概要设计,出《概要设计文档》;
3、然后详细设计,出《详细设计文档》;
4、然后就是编码,出软件代码,最好能出单元测试文档;
5、然后就是联调,可能有多个部分,需要联合测试;
6、最后就是软件交付了,交付软件、代码、使用说明书

软件开发流程(Software development process)即软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。

第一步:需求调研分析

1相关系统分析员向用户初步了解需求,然后用WORD列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。

2 系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还列出相关的界面和界面功能。

3 系统分析员向用户再次确认需求。

第二步:概要设计

首先,开发者需要对软件系统进行概要设计,即系统设计。概要设计需要对软件系统的设计 进行考虑,包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、 运行设计、数据结构设计和出错处理设计等,为软件的详细设计提供基础。

第三步:详细设计

在概要设计的基础上,开发者需要进行软件系统的详细设计。在详细设计中,描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系,需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细,能够根据详细设计报告进行编码。

第四步:编码

在软件编码阶段,开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求,开始具体的编写程序工作,分别实现各模块的功能,从而实现对目标系统的功能、性能、接口、界面等方面的要求。

第五步:测试

测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能。

第六步:软件交付准备

在软件测试证明软件达到要求后,软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。

《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容,在需要时还应举例说明。

第七步:验收

用户验收。

软件维护

1、软件数据库管理 [1] 2、用户跟踪培训

3、故障分析解决

软件升级

需求调整分析

软件功能拓展

优化系统

报废处理

软件不能适应业务发展

新软件项目立项

企业数据信息备份

举例解析

1 例如某家公司想找人订做一套人事管理软件,从某种渠道上得知某家软件开发公司提供这种服务,所以进行联系。

2 软件开发公司会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给用户用,然后回来做个方案给他们,其中方案的内容包括:开发出来的软件大概的界面是怎样?方便什么人使用?什么人可以使用什么功能?方便到什么程度?大概的硬件要求是怎样等?

3 用户看了方案后,确定他们就是要做一套这样的软件,开发方就开始开发这套软件。

4 开发方把开发出来的软件交给用户使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,开发方会第一时间修改这些功能,直到用户要求的所有功能都能很完美的解决掉。

5 用户如果因为公司发展壮大的需要,需要将软件升级开发方会做功能拓展。

参考资料
软件开发流程

http://edu.newer.com.cn/images/shixun_02.gif

本文参考:http://apps.hi.baidu.com/share/detail/19058495

概要设计的格式模板及相关内容说明

  概要设计的主要任务是把需求分析得到的DFD转换为软件结构和数据结构。

  设计软件结构的具体任务是:将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。

  数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然,概要设计建立的是目标系统的逻辑模型,与计算机无关。

简述

  概要设计有多种方法。在早期有模块化方法、功能分解方法;在60年代后期提出了面向数据流和面向数据结构的设计方法;近年来又提出面向对象的设计方法等。

概要设计的格式

 

概要设计的格式如下:

1引言 2

1.1编写目的 2

1.2背景 2

1.3定义 2

1.4参考资料 2

2总体设计 2

2.1需求规定 2

2.2运行环境 2

2.3基本设计概念和处理流程 3

2.4结构 3

2.5功能需求与程序的关系 3

2.6人工处理过程 3

2.7尚未问决的问题 3

3接口设计 3

3.1用户接口 3

3.2外部接口 3

3.3内部接口 4

4运行设计 4

4.1运行模块组合 4

4.2运行控制 4

4.3运行时间 4

5系统数据结构设计 4

5.1逻辑结构设计要点 4

5.2物理结构设计要点 4

5.3数据结构与程序的关系 4

6系统出错处理设计 5

6.1出错信息 5

6.2补救措施 5

6.3系统维护设计 5

概要设计说明书

1引言

1.1编写目的

说明编写这份概要设计说明书的目的,指出预期的读者。

1.2背景

说明:

a. 待开发软件系统的名称;

b. 列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站(中心)。

1.3定义

列出本文件中用到的专门术语的定义和外文首字母组词的原词组。

1.4参考资料

列出有关的参考文件,如:

a. 本项目的经核准的计划任务书或合同,上级机关的批文;

b. 属于本项目的其他已发表文件;

c. 本文件中各处引用的文件、资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

2.1需求规定

说明对本系统的主要的输入输出项目、处理的功能性能要求,详细的说明可参见附录C。

2.2运行环境

简要地说明对本系统的运行环境(包括硬件环境和支持环境)的规定。

2.3基本设计概念和处理流程

说明本系统的基本设计概念和处理流程,尽量使用图表的形式。

2.4结构

用一览表及框图的形式说明本系统的系统元素(各层模块、子程序、公用程序等)的划分,扼要说明每个系统元素的标识符和功能,分层次地给出各元素之间的控制与被控制关系.

2.5功能需求与程序的关系

本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系:

程序1 程序2 …… 程序n
功能需求1
功能需求2
……
功能需求n

2.6人工处理过程

说明在本软件系统的工作过程中不得不包含的人工处理过程(如果有的话)。

2.7尚未解决的问题

说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。

3.1用户接口

说明将向用户提供的命令和它们的语法结构,以及软件的回答信息。

3.2外部接口

说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

3.3内部接口

说明本系统之内的各个系统元素之间的接口的安排。

4运行设计

运行设计

4.1运行模块组合

说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说明每种运行所历经的内部模块和支持软件。

4.2运行控制

说明每一种外界的运行控制的方式方法和操作步骤。

4.3运行时间

说明每种运行模块组合将占用各种资源的时间。

编辑本段5.1逻辑结构设计要点

给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。

5.2物理结构设计要点

给出本系统内所使用的每个数据结构中的每个数据项的存储要求,访问方法、存取单位、存取的物理关系(索引、设备、存储区域)、设计考虑和保密条件。

5.3数据结构与程序的关系

说明各个数据结构与访问这些数据结构的形式:

6.1出错信息

用一览表的方式说明每种可能的出错或故障情况出现时,系统输出信息的形式、含义及处理方法。

6.2补救措施

说明故障出现后可能采取的变通措施,包括:

a. 后备技术说明准备采用的后备技术,当原始系统数据万一丢失时启用的副本的建立和启动的技术,例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术;

b. 降效技术说明准备采用的后备技术,使用另一个效率稍低的系统或方法来求得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工记录;

c. 恢复及再启动技术说明将使用的恢复再启动技术,使软件从故障点恢复执行或使软件从头开始重新运行的方法。

6.3系统维护设计

说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系,可采用如下的矩阵图的形式;

如何建立自己的知识体系?

前段时间读到这篇文章:《如何建立自己的知识体系?》,特地分享给烟烟。其实这种知识总结的方法,每个人可能各有一套;在这里我想谈谈我个人的看法。

1.知识体系的问题

工作以后,特别是在进入整车企业以后担任产品工程师之后,看到的听到的材料就似乎往各个方向上交叉的内容多了起来。以前,我只需要做硬件设计的东东(电路),附带得对于流程、质量、可制造性、半导体等知识有一定的了解。但是对于一个汽车电子零部件的工程师而言,这些都是足够了。

但对于一个部件的产品工程师,知道这些知识,仅仅是个开始或者说是个有意义的补充。在接触电池和电池系统的时候,我充分的了解了关于这是一门复杂的工程学,涉及到了电化学等一些我从未涉及的概念,对于电池系统设计之中的方方面面,有时候感觉是盲人摸象般。事实上,一个人是无法承担所有的工作了,能够把所有的事情进行划分,选择一个合适的切入点,可能是比较合理的。

因此在这方面而言,切乎贪全求快。我给自己的定义,工作之上,能够搞定所有的充电问题。在工作之外能够把电池涉及电学性能的知识和部分重要的电化学知识整理齐备,搞清楚电池管理和电池系统热设计方面的内容。可能就是一个限度,如果加上机构、振动、冲击设计和相关的内容,这已经不是短时间能够搞清楚摸透的事情。

定时的,写些博文来整理自己的思路,有机会给组里面写些培训材料,锻炼锻炼Presentation的能力。

2.技能体系

其实这个与知识体系还是差得比较多的。如果说勾画一个东西称为设计的话,在某个工具内进行实施就是技能应用。我不知道是不是因为现在的工具都太强大了,往往让工程师忽略了前者,都把工具看得比方法和思考更重要了。我为自己目前设定的技能体系:

a.Office系列:PPT这个目前是汇报的神器了,升职、加薪说到底还是通过PPT汇报出来的,这是排第一的。EXCEL不仅能够计算,也能把自己的事情和进度有效的组织起来。

b.Mathcad:我觉得这个工具,能够把数学运用在工程领域,我现在试图在勾画把一些计算努力使用。

c.UG:基本的结构设计工具,验证装配,目前的起点较低。

d.热分析软件:ANSFOT可能符合公司的策略,可能还是沿用它。

e.可靠性分析软件:虽然只是可能去check,还是得自己进行力所能及的进行温习。

其他林林总总的工具,一时之间比较难所列完全。不过,永远是足够的分析通过工具去验证,知识和技能不能本末倒置。

PS:昨天是烟烟的生日,原本指望着吃大餐+购物一行,但是由于我有些感冒特别是咽喉有些发炎,大餐计划也就变成了在家的自助料理。其实感觉生活过得也挺快的,每天如果不把握一下时间,脑袋里头就是空空荡荡的。

本文来自:http://forum.eet-cn.com/BLOG_yzhu05_118.HTM

对初学者有用的10个Git技巧

新兴技术是一个将开发模式和习惯做法带入主流的催化剂。有人称这是一种”真爱无价”现 象,这是一部80年代的电影名字,讲述一个书呆子想成为时尚人的故事,“租借”他高中暗恋的对象做其女朋友。最近的一个例子似乎就是Git的兴起。Git是一个开源的版本控制系统, 大幅度改善了正规化源代码管理的情况。我曾经用过其他的方式,比如CVS和Subversion就用了很多年,但Git让源代码管理成为了我工作流程中更 加自然而然的一部分——甚至非常有趣。

但跟许多其他的技术一样,Git较浅的学习曲线促进了它的广泛应用,而同时它也提供了许多的功能和选项,很容易让初学者不知所措。现在我也算比较 熟悉这个系统了,因此我维护了一个相关经验技巧的列表,可以很有效地帮助我管理我的Git项目。现在我将重点讲述我认为对新手最有用的那些。


1. 在提交的同时添加文件
Git要求你在提交最近一个变更集之前显式地将新跟踪的文件添加到仓库。 因此提交变更集的典型命令序列通常是这个样子:
%>git add .
%>git commit -m “Latest commit message”

为了节省预备步骤并将添加与提交文件的操作放到一起,可以使用-a标志:
%>git commit -a -m “Latest commit message”

然而,在许多情况下你不应该使用这种快捷方式。稍后在本文中我将演示至少一个例子来说明为什么。

2. 用Git别名来节省击键次数
跟许多流行的命令行工具一样,Git允许你将自己的用户设置保存到一个叫.gitconfig的配置文件。在这个文件中,典型的用法是定义你自己的名 字和e-mail地址,因为它们是你跟仓库交互有关的。但你也可以在这里定义别名以节省时间。比如, 我的.gitconfig文件就包含了这样一些常用命令的别名:

[alias]
st = status
co = checkout
cm = commit
pom = push origin master

如果你碰巧忘记了自己定义的别名,可以通过下面这个命令来快速查阅你的配置文件:
%>git config -l

3. 选择性暂存文件
有时候你可能同时在多个文件说做了改动,但只想在即将进行的一次提交中选择性地添加一部分。为了达到这个目的你可以使用交互式添加功能。比如,假设我创建了两个新文件:ShopController.php和ForumController.php,但我只想添加前面那个。这时候我可以通过给git add传递-i选项来启动交互式添加器:
%>git add -i

这里你将会碰到询问菜单,其中提供了几种选择:
*** Commands ***
1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp

通过选择 4,你可以交互式地选择你想要添加的文件:
What now> 4
1: application/controllers/ForumController.php
2: application/controllers/ShopController.php
Add untracked>>

4. 用.gitignore忽略文件和目录
初始化一个新的Git仓库以后,最先要做的就是创建一个.gitignore文件。该文件的作用是过滤那些你Git仓库中不想被跟踪的文件和目录。 比如,当我在一个新的Zend框架项目上工作的时候,典型的做法是丢弃那些项目文档,网站图片,和来自仓库的notes.txt文件,也就意味着我 的.gitignore文件看起来是这么一副模样:

docs
public/images
notes.txt

5. 在提交列表中删除新添加的文件
在开发最热火朝天的时候,你可能忘记将一个新创建而不想包含到仓库的文件添加到.gitignore文件。你可以用rm命令从即将提交的变更列表 中删除这些文件(被称为未暂存文件):
%>git rm –cached schema-notes.txt

成为未暂存状态的时候,你就可以将该文件添加到.gitignore了,然后再重新做一次提交。

6. 查阅一个已提交文件的提交前内容
在当前版本中对一个文件作过修改以后,我常常需要检查一个文件早期版本的内容,但又不想真正恢复这个文件。你可以用show命令带上一个指向该文件 的参数来轻松完成这个事情:
%>git show HEAD^:application/controllers/AboutController.php

插入符号(^)代表查看时需要回退的修订版的数目。因此上面这个例子会显示AboutController.php的上 一个修订版。如果你要查看3次修订之前的版本,就要使用3个插入符号,像这样:
%>git show HEAD^^^:application/controllers/AboutController.php

另外,你也可以使用提交的哈希值来引用文件。比如,如果你想查看5个修订版之前的AboutController.php文件的内容,你必须先执行 git log来查看提交的哈希值,然后使用哈希值的前5个字符来获取文件内容:

%>git show 23aa985:application/controllers/AboutController.php

7. 编辑最近一次提交的日志消息
我是一个对拼写一丝不苟的人,但是在比较匆忙地提交最新变更集的时候消息中偶尔会多出一两个不想要的字母。你可以很容易地用amend命令编辑最近 一次提交的消息:
%>git commit –amend

执行这个命令会讲最近的提交消息加载到编辑器中,你可以编辑并保存这些消息。

8. 存储未提交的变更
编程工作的偶然中断是不可避免的,这常常会导致你处于这么样一个位置:尚不到可以提交变更的状态,而又必须立即修复并提交一个跟当前工作无关的问题。你可以用stash命令一股脑地保存下当前的所有变更,同时将你的基础逆转到之前的那个提交点,这时候你就可以修改并进行新的提交。一旦完成,你可以回到你存储的状态。比如,假设我正在一个项目的README文件的一个新区段上工作,突然发现了一个很严重的拼写错误。我可以这样来存储我的当前变更:
%>git stash save

重新打开README,我将会发现那个新的区段消失了,因为我已经回到了上一个提交点。这时候我可以修复那个拼写错误并 提交变更。然后再执行下面这个命令回到我的原始状态:
%>git stash pop

9. 浏览你的仓库
有很少的几种基于Web的界面可以用来浏览Git仓库,但是你知不知道一个叫instaweb的东东已经集成到了本地发布里面?要在浏览器里面阅读你的代码仓库,执行下面这个命令即可:
%>git instaweb –httpd apache2

将apache2传递给–httpd开关会告诉Git使用运行在本机的Apache作为Web服务器。虽然也支持几种其他的服务器,但默认使用的是lighthttpd。

10. 责备其他人
偶尔可能发生一个团队成员(当然不是你自己)引入一些未经测试的代码到仓库里而破坏构建的事情。自然,你想要将该问题归咎到某个人。但是谁引入了这个错误呢?可以用blame命令来查找:
%>git blame application/controllers/AboutController.php

23aa9852 (Jason Gilmore 2010-06-03 12:34:04 -0400 11) public function indexAction()
23aa9852 (Jason Gilmore 2010-06-03 12:34:04 -0400 12) { 0e9e9f49 (Jason Gilmore 2010-06-03 13:32:47 -0400 13)
echo “Missing semicolon” 23aa9852 (Jason Gilmore 2010-06-03 12:34:04 -0400 14) }

哇靠,好强大!

结论
Git的确是一个有着丰富功能的珍贵宝物,它让源代码管理变成了一件轻而易举的事。你有没有发现什么Git的有用功能、技巧和窍门?请在评论中告诉我们!

关于作者
Jason Gilmore是EasyPHPWebsites.com的创始人。 他还是好些畅销书的作者,包括”Easy PHP Websites with the Zend Framework”, “Easy PayPal with PHP”和”Beginning PHP and MySQL, Third Edition”等。

来源:http://www.developer.com/features/article.php/3886146/10-Git-Tips-and-Tricks-for-Beginners.htm

BugZilla在Win7下安装与配置-IIS7+mysql秘籍

不加“秘籍”不表我倒腾了一天的辛苦啊!

本来想说说BugZilla或者bug管理的重要性,但是想想,你懂的,否则咋会来这里?但我还是想说,真的很有必要,有3个人以上的项目,无论项目多小,bug管理就很必须了。

下面说说本文的重要性,但是想想,你懂的,Win7+IIS7,现在资料很少很少,配置起来很不顺利,所以,你懂的。

关键点:

1、iis7的配置

windows7旗舰版默认是没有安装iis的,所以需要你自己添加。这个吗,推荐你看看这篇文章:

http://www.360doc.com/content/10/0624/19/1872066_35018211.shtml

但是有一点必须注意!BugZilla是cgi写的,后台解释器是Perl,大神啊,我安装IIS7的时候没注意这点,后面的失败全拜此所赐啊!所以,在安装IIS7的时候,一定要勾选CGI模块解释器!

另外,最好在安装ActivePerl之前配置好IIS7.

2、安装和配置ActivePerl

这里又可以参照一个帖子:

http://www.roboby.com/install_bugzilla_in_windows.html

其中有些地方不可照搬,因为你用的是win7,而他的是xp

3、“-T”的问题

如果你碰到提示cgi文件的-T问题,那么恭喜你,你基本成功了!最有一个-T的问题,就是个参数问题。

我们在配置perl.exe作为cgi解释器时,给perl.exe传递的参数是 “perl.exe ‘%s’ %s”,正确的应该是:“perl.exe  -T ‘%s’ %s”!

 

 

BugZilla在Windows下的安装

一. 安装MySQL数据库
下载 MySql 4.x: http://www.mysql.com/ ,我用的版本是mysql4.1.22 for win32
安装请看如何在Windows平台下安装MySQL(http://www.websina.com/bugzero/faq/database-mysql-win.html)。
二.安装activeperl
下载activeperl最新版本:http://downloads.activestate.com/ActivePerl/Windows/,可以安装需要选择所要的版本,我选用的是5.8.822,现在最新的版本是5.10.1002,一开始是我用的是5.10.1002这个版本,发现PPM中包含的模块反而没有5.8.822这个版本来的全,所以最终还是使用了5.8.822这个版本.但是要注意的是bugzilla3.0.3及以上版本要求activeperl版本在5.8.1以上.
安装activeperl,这个没什么可说的,默认安装即可.
三.安装bugzilla
bugzilla并不需要安装,下载完后解压到本地某个目录下即可.
http://www.bugzilla.org/download/现在最新的版本是3.1.3,我装的就是这个版本.
安装完后,在dos下执行checksetup.pl,看缺少哪几个perl module,具体命令如下:
C:\Perl\bin>perl C:\bugzilla-3.1.3\checksetup.pl
可以看出,我的perl 和bugzilla都放在C盘根目录下,执行后,发现有很多模块需要安装:
Checking perl modules…
Checking for CGI (v2.93) ok: found v3.29
Checking for TimeDate (v2.21) not found
Checking for PathTools (v0.84) ok: found v3.25
Checking for DBI (v1.41) ok: found v1.58
Checking for Template-Toolkit (v2.15) not found
Checking for Email-Send (v2.16) not found
Checking for Email-MIME-Modifier (any) not found
Checking available perl DBD modules…
Checking for DBD-Pg (v1.45) not found
Checking for DBD-mysql (v4.00) not found
Checking for DBD-Oracle (v1.19) not found
The following Perl modules are optional:
Checking for GD (v1.20) not found
Checking for Chart (v1.0) not found
Checking for Template-GD (any) not found
Checking for GDTextUtil (any) not found
Checking for GDGraph (any) not found
Checking for XML-Twig (any) not found
Checking for MIME-tools (v5.406) not found
Checking for libwww-perl (any) ok: found v2.036
Checking for PatchReader (v0.9.4) not found
Checking for PerlMagick (any) not found
Checking for perl-ldap (any) not found
Checking for RadiusPerl (any) not found
Checking for SOAP-Lite (any) ok: found v0.55
Checking for HTML-Parser (v3.40) ok: found v3.56
Checking for HTML-Scrubber (any) not found
Checking for Email-MIME-Attachment-Stripper (any) not found
Checking for Email-Reply (any) not found
Checking for mod_perl (v1.999022) not found
Checking for CGI (v3.11) ok: found v3.29
上面是执行的一部分结果,可以看到必须安装的模块有7个,其中CGI,DBI,PATHTOOL三个已经安装;可选的安装有三个,就是数据库的三个,根据选择数据库的不同,分别安装.因为我用的是mysql,所以一会就选择dbd-mysql进行安装;还有后面的一堆是可装可不装的,到时等需要用时再安装不迟.
接下来,我们就来安装这些模块.
四.安装perl modules
可以通过activeperl的PPM进行模块的安装.
打开 开始->程序->activeperl 5.8.8 bulid822->perl package manager(PPM),打开如下图所示窗口:
[img=256 border=0,120 src=]http://bbs.51testing.com/[/img]
对应(三)我们可以知道需要另外安装TimeDate (v2.21) ,Template-Toolkit (v2.15) ,Email-Send (v2.16),Email-MIME-Modifier (any),DBD-mysql (v4.00) 这五个模块.
Template-Toolkit (v2.15)的安装
我们在PPM中查找,发现了Template-Toolkit (v2.15),选中它,点右键,点”install Template-Toolkit 2.15″,然后点击窗口第二栏的绿色箭头图标,也可以使用快捷键ctrl+enter,弹出一个对话框,点确定即可.
TimeDate (v2.21)的安装
TimeDate比较奇怪,在PPM上找到的TimeDate版本是1.16,但是直接在ppm上安装完了后,执行checksetup.pl,发现TimeDate安装成功,并且版本升级到了2.22,后来也没发现问题及原因.
Email-Send (v2.16)的安装
PPM上Email-Send的版本是2.05,无法支持bugzilla 3.1.3,需要通过其他网站下载包安装.
在dos下输入以下语句:
C:\Perl\bin>ppm install http://theoryx5.uwinnipeg.ca/ppms/Email-Send.ppd
点击enter ,PPM自动从http://theoryx5.uwinnipeg.ca/ppms上下载最新的Email-Send.ppd进行安装
此时执行结果提示:
ppm install failed: Installing Module-Pluggable-3.01 for Email-Send would downgr
ade Devel::InnerPackage from version 0.3 to 0.2, Module::Pluggable from version
3.6 to 3.01, and Module::Pluggable::Object from version 3.6 to 0; use –force to
install regardless
按照提示将命令改成C:\Perl\bin>ppm install http://theoryx5.uwinnipeg.ca/ppms/Email-Send.ppd –force,重新执行即可.

DBD-mysql (v4.00)的安装
在dos下输入以下语句:
C:\Perl\bin>ppm install http://theoryx5.uwinnipeg.ca/ppms/DBD-mysql.ppd
点击enter ,PPM自动从http://theoryx5.uwinnipeg.ca/ppms上下载最新的DBD-mysql.ppd进行安装
注:关于各个module的详细信息可以在下面的网站上进行搜索查看,如emailsend:
http://cpan.uwinnipeg.ca/dist/Email-Send
Email-MIME-Modifier的安装
在dos下输入以下语句:
C:\Perl\bin>ppm install http://theoryx5.uwinnipeg.ca/ppms/Email-MIME-Modifier.ppd
点击enter ,PPM自动从http://theoryx5.uwinnipeg.ca/ppms上下载最新的Email-MIME-Modifier.ppd进行安装
这样五个必须安装的module都已经安装完毕,重新执行checksetup.pl.
在bugzilla目录下生成localconfig文件.修改localconfig:
$db_driver = ‘mysql’;
# The DNS name of the host that the database server runs on.
$db_host = ‘localhost’;
# The name of the database
$db_name = ‘bugs’;
# Who we connect to the database as.
$db_user = ‘bugs’;
# Enter your database password here. It’s normally advisable to specify
# a password for your bugzilla database user.
# If you use apostrophe (‘) or a backslash (\) in your password, you’ll
# need to escape it by preceding it with a ‘\’ character. (\’) or (\)
# (Far simpler just not to use those characters.)
$db_pass = ”;
# Sometimes the database server is running on a non-standard port. If that’s
# the case for your database server, set this to the port number that your
# database server is running on. Setting this to 0 means “use the default
# port for my database server.”
$db_port = 0;
将$db_host改成mysql server端的服务器,我装在本机,所以不用修改;
将$db_name = ‘bugs’;改成$db_name = ‘bugzilla’; —-bugzilla是我新建的BUG数据库的名称;
$db_user = ‘bugs’;改成$db_user = ‘bug’; —-bug是我登录bugzilla数据库的用户名;
$db_pass = ”;改成$db_pass = ‘bug’; —-bug是我登录bugzilla数据库的用户bug的密码;
$db_port = 0;改成$db_port = 3306; —-mysql安装默认端口是3306;
修改完成后,保存.重新执行checksetup.pl.
在dos窗口中可以看到在往数据库中创建相应的表结构.表结构创建完后,提示要求输入管理帐号的邮件,real name和密码,输入后,继续执行,知道提示”Now that you have installed Bugzilla……”.
接下来我们要将bugzilla部署到iis上,以便项目成员可以通过URL进行访问.
五.部署bugzill到IIS上
首先安装IIS.
打开 控制面板->管理工具->Internet 服务管理器,在默认 Web 站点, 点按右键选择属性->主目录->配置…,在应用程序映射中点击添加,增加如下资料: Executable: C:\Perl\bin\perl.exe “%s” %sExtension: .plLimited to: GET,HEAD,POSTExecutable: C:\Perl\bin\perl.exe -T “%s” %sExtension: .cgiLimited to: GET,HEAD,POST
默认 Web 站点->新建->虚拟目录:
别名:Bugzilla,访问目录:C:\Bugzilla,访问权限中增加写入,执行权限。 选择刚建立的虚拟目录Bugzilla,右键选择属性->文档。默认文档中增加index.cgi。
在web服务扩展中,将perl CGI extension 设置为允许.
修改bugzilla目录下所有的cgi文件,将#!/usr/bin/perl -wT替换为#!/usr/bin/perl -w 打开浏览器,键入 http://localhost/bugzilla/ 既可进入登录界面。
至此,bugzilla终于安装完毕.
当然,bugzilla还提供了其他的一些功能,如邮件发送,报表统计等,都不错,需要做另外的配置,下次再总结.
PS:我的操作系统是:win2003 R2 enterprise edition sp2

六.BUGZILLA相关参考网站
Bugzilla官方网站http://www.bugzilla.org
Bugzilla汉化项目http://sourceforge.net/projects/bugzilla-cn
http://cosoft.org.cn/projects/bugzillchinese/
Perl官方网站http://www.perl.com
ActivePerl官方网站http://www.activestate.com/Products/ActivePerl
MySQL官方网站http://www.mysql.com
Fake Sendmait for Windows http://www.glob.com.au/sendmail/
Installing Bugzilla on Microsoft Windows
http://www.bugzilla.org/docs/win32install.html
The Bugzilla Guidehttp://www.bugzilla.org/docs/2.20/html
Bugzilla windows安装红宝书http://blog.fz0132.com/trackback.asp?tbID=654

 

软件外包工作规程指引(适用发包方)

 

来源:  作者:  日期:10-01-24

  电子化时代的许多经营活动需要借助信息系统管理,因此软件外包现象越来越普遍。在软件外包过程中,发包方似乎处于主动位置,可以决定是否和如何外包,哪些内容需要外包,并可以自主选择合适的承包方。但是,企业经营活动高度复杂,风险无处不在。软件外包作为软件生产的新方式同样存在各种风险,现实中有不少发包企业在实施外包项目后发现问题丛生,最终导致外包项目流产。存在风险并不可怕,可怕的是缺少风险意识和规避风险的手段。其实,通过仔细分析风险的来源和特征,在软件外包的全过程实行动态和连续跟踪和控制,可以防患于未然,有效规避软件外包风险。

  一、项目前期准备阶段

  (一)前期调研阶段。本阶段主要从事三方面工作

  (1)审视自身的履约能力根据公司的发展目标,判断该项目外包是否符合公司发展的主要方向,公司有否必要为此项目增加新投资、添置新设备、招聘新员工,如果有此必要,公司有没有足够的能力和充裕的时间去实现这些新的投入。

  (2)审核承包方的缔约资格,判断其是否有缔约权利能力和履约行为能力。寻找合适的外包合作伙伴,验证和调查公司的实际资质和开发团队的实力,有必要进行实地考察。具体包括承包方办公场所(自有/租赁)以及周围办公环境、办公环境的装修、营业面积大小、管理是否规范、人员精神风貌、开发人员数量、技术水平、男女性别比例等。尤其注意了解开发方是否设置专门的测试员岗位。此外,要注意掌握承包方的开发实例。如有必要,还需要对承包方开展信用调查,包括查看营业执照复印件,企业经营历史,企业涉讼情况,违法记录,业内口碑,主要负责人以及股东的情况。

  (3)制定资信考察报告书。

  (二)制作项目需求。

  在项目立项初期,发包方首先要做好内部的时间进度设计和规划以及一套完整的软件系统规格说明。其中,项目进度的估算尤为重要,要避免项目发生延误,计划中要预留足够的双方沟通和确认的时间。

  二、与承包方谈判、磋商阶段(与前一阶段可合二为一)

  此阶段的全过程中始终不能忘记对于双方利益共同点和利益冲突线要具备清晰的认识和全面的了解;准确预测双方可能的妥协程度;对于法律法规的相关规定和本合同可能涉及的第三人利益界限有熟练的掌握和冷静的恪守。

  1.发包方发出邀约邀请,将项目的时间进度设计和规划以及功能需求提交给承包方,承包方据此提交投标书,包括详细规划方案。

  2.发包方收到承包方提交的项目计划后,要详细地跟本企业的计划进行比对和审核,从而了解承包方对整个项目的流程、内容、估计的工作量和资源的安排是否与项目本身的要求吻合。明显的差异需要及时澄清并建立共识。双方要将其记录入书面文档。

  3.确定合作意向后,要求承包方出具详细的进度实施方案和系统整体评估方案,并对此方案进行评审和确认,旨在双方都能明确地了解项目的整体任务量和难度,做好人力物力的合理安排,避免不必要的麻烦,此过程的文档应留存备查。

  4.承包方的核心参与人要书面提交对发包项目的说明报告,由发包方判断承包方是否理解发包项目的意图,了解外包项目开发人员的思路是否和设计相符。

  5.项目开始前,须做足够的分析和风险评估,对可能出现的风险设计避免的方法,预先设计好替代方案,甚至外包团队都应有替代人选。

  三、合同签约阶段

  外包合同应明确如下内容

  1.明确双方项目组沟通成员名单及其联系方式,承包方须提供所有参与人的名单及联系方式、邮件地址等。

  2.明确约定开发方必须遵照发包方的需求设计文档进行开发,在开发过程中,如果出现发包方设计不周或是不合理的地方,开发方须提出问题及修改方案,必须经发包方确认后才能进行修改,并且这些修改需要记录入文档。

  3、明确约定承包方项目负责人首先需要做出一个详细的、完整的项目计划,并在计划中详细地列清楚每一项工作需要哪方面人力共同执行。

  4.明确约定每一个项目进度都需要发包方确认后才能继续进行。如果发包方认为有问题并提出修改意见,承包方须根据发包方意见提出书面解决方案,经过发包方确认后进行修改,如果推后时间再修改,须征得发包方同意。例如承包方在完成系统分析后,需要把分析的结果让发包方理解,确认承包方对整个系统的理解和分析与企业本身对项目的需求和分析达成一致,这样才能让承包方进行其后的模块设计。

  5.明确约定项目过程中的进度汇报方式,有必要时时监控源代码,了解项目的进展情况,分阶段提交项目成果,有必要让承包方进行阶段性成果演示。如果承包方不能按时提交项目成果,须提前向发包方提出申请,且须取得发包方同意。

  6.承包方每日将开发的源代码及设计说明书上传至CVS服务器上,承包方项目工作人员需每日将工作情况以日报形式上传至该CVS服务器。由发包方于第二天上午进行检查,并向承包方提出书面反馈意见。

  7.每一个程序模块完成后,承包方须提交测试方案与测试结果。承包方应把有关程序的源代码列出,并把有关测试的结果打印出来,让发包方核对结果,确认承包方所说的工作已经完成。如果承包方没有列出源代码,发包方有权不予项目验收。

  8.建立几个大的项目里程碑。约定在大的里程碑内发生的项目延误由承包方自我消化,大的里程碑点发生的项目延误将由双方商讨处理。

  9.明确约定项目验收期限、验收内容(项目不同阶段开发方须提交的详细文档列表、提交日期、负责人及质量要求、验收成果中必须包含测试报告及测试结果)、验收方法以及双方验收小组成员(必要时需要承包方参与验收)。

  10.验收报告须双方签字确认才能生效。

  11.明确约定项目完成提交时需要提交的完整的交付物,其中源码作为重要,而且源码须符合规范。

  12.明确约定试运行时间段以及承包方在试运行期间应尽的责任,如果发生的错误是需求内的,承包方须无条件修正,并重新验收。

  13.对于发包方合理的需求调整,在工作量的一定百分比之内,承包方应当同意。如果超过此百分比,双方协商一致解决。未能协商一致的,按照原方案执行。

  14.明确约定承包方负责本项目的关键人物不能临时更换。应争取让承包方项目主要负责人要做出承诺,坚持到最后。

  15.如果发包方处于优势谈判地位,应约定较低的首付款,可以采取低首付,多次数的支付方式。

  16.明确约定违约(预期违约、一般违约、严重违约)的责任承担和赔偿以及不可抗力或情势变更的风险承担方式和原则。

  17.明确约定合同自承包方提供经双方确认后的详细需求文档时生效。

  18.明确约定合同的变更、权利义务转让以及终止(对方主动终止和发包方主动终止合同)条款。

  19.明确约定合同争议处理条款。

  四、项目实施阶段

  1.项目开发过程中应开展有效的沟通,以便及时解决开发过程中发现的结构或设计方面存在的问题。必要时安排一对一的沟通方式,即承包方的开发人员直接和发包方的具体负责人联系沟通,减少中间的传递环节,减少传递出错的几率。每项重要的沟通须记录入文档并经过双方确认。

  2.有效地跟踪掌控开发情况。发包方需掌握承包方每个开发人员的开发状态和进度,及时发现和应对任何突发状况。项目中发现的任何和设计不符的地方或其他问题要及时沟通和解决,避免将问题推到项目结束后。在开发的过程中,验收也同时进行,而不应等待开发完成后才进行验收,即要分段进行阶段性验收。

  3.项目第一次延期就应该介入解决。开发过程中要作严格控制,避免承包方散漫和懈怠。如果是发包方的原因导致项目延误,发包方要补足承包方时间并形成书面的确认文件。

  4.验收时应严格按验收报告内容进行。按照合同约定时间进行密集型测试和验收,出现验收不合格的情况,要及时进行协商和处理,时间要尽量控制到最小范围。

  5.发包方付款事项须与对方配对,在不存在对方履行义务在先的情况下,发包方须按时付款。

  6.发包方须根据对方提出的项目进度表,制定发包方项目管理进度表。由项目组组长负责定期对工作计划跟踪并督促执行。完成项目工作日志,对工作进展定期汇总,汇报。

  项目组成员须妥善保管来往记录、邮件、变更确认单等。

  成功的软件外包是发包方和承包方互相信任、高度协作的结果。发包方软件企业需要合理外包决策,细化和筛选可以外包的内容,确定具体的外包实现方式,选择合适的承包方,规范外包的实施流程,积极地进行外包项目管理,实现全方位、全过程地监控外包过程,才能将软件外包风险降到最低。

 

【转】首次敏捷项目开发实践

首次采用敏捷方式进行开发,我想把我们的做法与大家分享下,同时希望大家指出我们的不足和需要改进的地方,让我们的项目进行的更顺利,目前项目已过三分之一,客户比较满意,还算顺利。
 
项目简介:一个DMS小项目,预计时间14人月.客户需求不是很明确,想一边做一边提,适合引入敏捷开发(实际上用户的需求也一直在变,当他们看到每次的small release时都会有新的想法)。
 
Team主要成员:一个team leader(兼BA职责),两个工程师,一个UI设计师。
成员主要职责:team leader主要负责召开会议,明确每天的开发任务以及项目的总体大概进程,保持团队成员清楚的知道项目目前的状态,保持团队沟通顺畅让团队保持高昂的士气。还有个作用是敢于对项目的成败负责(当然团队每个成员都有责任)。工程师的主要职责是开发,设计师主要职责是UI设计。
 
开发环境配备:硬件:两个PC机两个显示器两套鼠标键盘(工作的时候切换到一个PC机上pair编程,共享一个主机,用转换器使一个主机上面接两个显示器,两套鼠标键盘,这样就不用挤在一个显示器前抢一套鼠标键盘pair了),一个测试服务器,上装svn服务器和cruisecontrol来管理代码和实现定时自动化测试(测试一定要自动化,这样可以让机器来干它喜欢并擅长干的事情,让工程师专注自己的业务;我们使用yahoo的一个模拟熔岩灯来监视测试结果。),一个发布服务器,客户可以远程及时试用后给出反馈意见和建议。
 
开发简介:
一、迭代(Iteration)和发布(release)计划
由于项目开发人员比较少,我们决定采用最短的迭代周期(一周),每个迭代前由BA评估story需求风险,开发人员评估story技术风险和cost,选出能在本轮迭代周期中完成的任务;每个迭代结束来一次small release
 
二、我们对实现XP价值观所做的努力
1、  沟通(communication)
再怎么强调沟通的重要性都不为过,尤其是在软件行业。所以在XP中communication被放在首位也不为奇。
我们项目组每天早上开一次Standup Meeting,通报彼此昨天做了哪些工作,以便让开发小组所有人了解各自的工作情况,然后确定今天要做的task,目前公司地牌儿还不够辽阔,我们小组还没有足够的地儿挂白板,就把story和task写在Excel表里面;每个星期一的早上(迭代开始前)会有一个IPM(迭代计划会议),主要内容是大概确定本次迭代周期开发需开发的story,工程师评估每个story完成所需的时间开;每个周五下午(迭代结束前)会有一个Retrospective(迭代结束前会议),会议主要内容是对本次迭代做的好的方面以及待改进的地方进行总结;工程师pari编程。
2、  简单(simplicity)
保持代码和设计尽可能简单是系统可扩展性和可维护性的重要保障。关于Simple Design的讨论可见徐X的Agile 101: Pair Programming & Simple Design  。kent beck用四个条件定义了简单的系统代码:运行所有的测试获得通过、意图明确、没有重复、使用尽可能少的类和方法。我和accompanier也一直在向这个目标努力。
3、  反馈(feedback)
没有持续的反馈,敏捷将无从谈起。customer、accompanier、team以及test result的反馈给我们向用户交付真正需要的系统提供了保证。我们的BA每天和客户沟通,掌握用户真正、迫切需要的功能和需求。由于我们的系统是一周发布一次,所以客户也能在很短的时间内知道完成的新功能,并及时提出改进意见和建议(其实客户的需求也是一直不停地在变的)。
4、  勇气(courage)
为了使代码更加清晰、质量更好,对工作代码进行大范围的修改和重构需要勇气,把某些代码彻底抛弃需要勇气,告诉客户无法再添加新功能需要勇气。我和accompanier目前都还有这样的勇气,希望系统越来越大、代码越来越多的时候还有这样的勇气。
 
三、测试驱动开发(TDD)
关于TDD我们一直在尝试寻找更爽的方法,目前采用的是webwork、spring、hibernate的组合框架,在大脑里无意识的已经存在了三层结构,我觉得采用TDD,这三层结构应该是最后被驱动出来产生的,而不是一开始就定好三层,然后再TDD编码。
我们目前是分别对每层进行TDD,还是觉得service层驱动最有成就感,看到green bar 就令人兴奋,action层老是mock来mock去的走流程实在属没啥意思。
最近又看到了使用Selenium和Castle进行测试驱动开发 ,本想采纳,但是使用Selenium进行至顶向下的驱动的话通过一个测试所需的时间太长了,我是对green bar有点上瘾了的人,不能忍受那么长时间的red bar,怀疑它会对偶的身心健康造成影响,所以就作罢,还是由底至上的方法使测试通过的实践最短,不知道各位对这样的三层结构是怎么TDD的?
 
Robert C. Martin大叔的TDD三条军规如下:
1.除非这能让失败的单元测试通过,否则不允许去编写任何的产品代码。
2.只允许编写刚好能够导致失败的单元测试。 (编译失败也属于一种失败)
3.只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
对于任何功能,一定要从编写它的单元测试开始;但是到了原则2,你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败,或是断言失败,你就必须停下来开始编写产品代码;但是到了原则3,你就只能编写产品代码,直到让测试编译成功或通过断言为准。
 
这三条军规我觉得太经典了,完全做到了才算TDD做到位了。
 
前几个迭代周期我们没有采用TDD,功能代码写了然后写测试,两个月后对系统进行了一次比较大的重构时,所有的测试都通过了,但是发布上去了还是由bug,所以这种干法是不行的,测试不能达到令人满意的覆盖度。TDD完全可以使测试达到令人满意的覆盖度。基本上只要测试通过了,就能确定重构没有对系统造成影响。
 
四、验收测试(acceptance test)/客户测试(customer test)
    验收测试我们是放在最后做的,由BA代客户写验收测试,工程师使用selenium 进行验收测试的实现,我们发现selenium对frame支持的不是很好,有这儿我想到采用至顶向下如:使用Selenium和Castle进行测试驱动开发 进行TDD的话是最合理的,不知道大家是不是这么做的?
 
五、pair 编程
    pair的好处我就不说了,试过了就知道了。

 

 

本文来自:http://www.javaeye.com/topic/68499

 

 

【转】常见的敏捷开发流程比较

       速度是企业竞争致胜的关键因素,软体专案的最大挑战在于一方面要应付变动中的需求,一方面要在紧缩的时程内完成专案,所以软体团队除了在技术上必须日益精进,更需要运用有效的开发流程,以确保团队能够发挥综效。 这正是Agile Process (敏捷的软体开发流程)于近年来兴起的主要原因,本文将介绍数种广为接受的软体开发流程,及其在运用上的建议。

1  Agile Process -敏捷的开发流程

 

       几乎所有的软体专案都会在起始阶段面临选择开发流程的困难,一种是完备的开发流程,另一种是简易轻便的流程。 虽然我们了解采用完备的开发流程可以提高软体的品质,但是因为欠缺人力、工具与时间,我们常会被迫采用简化的流程,但事与愿违,大部分的情况我们仍然难以在预算内及时完成专案。 

 

       Agile Process (敏捷的开发流程)是一种软体开发流程的泛称,Agile Process具有下列几项共通的特性: 

1. 客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软体。 
2. 专案最终的目标是可执行的程式,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品。 
3. 采用Iterative与Incremental方式分阶段进行,密集review是否符合需求。 
4. 流程可以简单,但规划与执行必须严谨。 
5. 强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整。

 

 

2  RUP开发流程- Rational Unify Process

 

       RUP为IBM Rational公司经过多年的研发与经验所提出的软体开发流程,其内容含盖Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment等软体开发生命周期的直接工作,与Project Management, Change & Configuration Management,Environment support等支援性工作。  RUP的内容非常丰富,不同的专案需要不同调整,IBM Rational提供RUP workbench工具,方便调整RUP,并公布于Web,方便专案成员遵循统一的流程规范进行工作。 

       RUP的主要精神为:1.专案进行采用Iterative程序分阶段渐进地完成专案功能;2.广泛使用Visual Modeling于商业需求分析、系统分析与系统设计;3.强调架构设计;4.对每项工作所需要的技术、工具、做法、范本、检查项目均有详细的定义,架构完备且具有可调整的弹性。 
因为RUP的流程规范与相关技术较复杂,所以导入时必须注意几个因素:1.主管的支持以确保足够的资源投入;2.分阶段导入;3.适当的训练与密切的顾问咨询;4 .使用Modeling技术时需要考量Coding的实作环境;5.良好团队的管理,以沟通、耐心与坚持解决变革的人性阻力。

 

 

3  XP开发流程- eXtreme Programming

       XP亦称为终极流程,是最轻量级的开发流程,其最主要的精神是『在客户有系统需求时,给予及时满意的可执行程式』,所以最适合需求快速变动的专案。  XP经过6年的实作与修改,已演化为精致的开发流程,但仍不失其精简的特性,它强调客户所要的是workable的执行码,所以把与撰写程式无关的工作降至最低,并要求客户与开发人员最好以side-by-side的方式一起工作。 
       XP开发流程的基本步骤为:1.开发人员随时可以和客户进行有效沟通,撰写user stories以确认需求。

  2.简易快速的系统设计,撰写独立的验证程式以解决特殊困难的问题,找出演算法即可丢弃验证程式。

  3.规划多次小型阶段的专案计划,以最快速度完成每一阶段的程式交付客户,客户负责Acceptance tests;

  4. Coding前必须完成Unit Test与Acceptance tests程序,所有模组整合前都须经过Unit Tests;

  5.开发人员必须快速回应Bug与需求变更;

  6.要求二人一组使用一台电脑设计程式,当一人coding时,另一人负责思考与设计; 

  7.程式必须符合程式规范,并常做程式的重整(Refactoring)。  

  XP属于较精简的流程,于导入应注意几件事情:

  1.最好有顾问给予协助;

  2.持续的Review;

  3.可适当调整流程,但不可失去其基本精神。

 

4  SCRUM开发流程

 

      SCRUM开发流程是Agile Process的一种,以英式橄榄球争球队形(Scrum)为名,基本假设是『开发软体就像开发新产品,无法一开始就能定义Final Product的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功』。

      Scrum将软体开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,碓保每天、每个阶段都朝向目标有明确的推进,因此SCRUM非常适用于产品开发专案。  SCRUM开发流程通常以30天为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部份,开发团队必须尽力于30天后交付成果,团队每天用15分钟开会检视每个成员的进度与计画,了解所遭遇的困难并设法排除。               SCRUM与传统开发流程及专案管理差异较大,于导入时最好有顾问协助。

 

5 总结

 

     Agile Process的精神已经成为共识,但是没有一种固定的流程可以重复使用在不同的专案上。 而且不管是RUP、XP、SCRUM、或其他的开发流程都允许相当大的弹性,我们必须按专案性质的不同,调整或混合出适合的开发流程,并允许团队于进行中做必要的弹性修改,方能达成目标。

 

6 参考资料

 

RUP: www.rational.com 
XP: www.extremeprogramming.org 
SCRUM: www.controlchaos.com 
AGILE: www.agilealliance.org

 

本文转自:http://topinking.javaeye.com/blog/343826

 

 

 
 
 

 

 

 

 

【转】你是个软件架构师吗?

=========================================================

本文为转载,转载必须确保本文完整并完整保留原作者信息和本文链接

E-mail: khler@163.com

QQ:     23381103

MSN:   pragmac@hotmail.com

原文:http://www.infoq.com/cn/articles/brown-are-you-a-software-architect

申明:转载只为传播知识,让更多人享受作者智慧的结晶!

如原作者有异议,请立即联系本人,本人将在第一时间删除,并深表歉意!

=========================================================


编者按: 本文作者 Simon Brown ,在三月的QCon London上发表了同样主题的演讲《Software Architecture for Developers》。

经常被用来区分软件架构和软件设计开发的关键几点包括 伸缩性和抽象程度的增加以及作出正确设计决策意义的增强。软件架构是通过一个全局的观点,宏观的视角来理解软件系统作为一个整体如何工作。开发和架构的界限难以捉摸。有些人告诉你它根本不存在,架构只是开发者们所做的设计过程的简单扩展。 另外一些人认为这是一个鸿沟,它只能由那些做到高度抽象,而且不会陷入实现细节的开发者才能跨越。通常,在这两个极端的观点中间某处有个可操作的平衡点;不论如何,怎么从开发转换为架构师都是个有趣的问题。

即使这能够帮助区分软件开发和架构,它并不能帮助理解某人如何从开发提升到架构。 并且,它也不能帮助识别谁能够成为一个好的软件架构师,如果你想雇人的话你如何去寻找他们以及你是否是一个软件架构师。

经验可以判定但你需要更深入地了解

要成为一个软件架构师并不是一夜之间或者一个职位的提升就能简单达到的。 这是个职责,而不是头衔。这是个进化的过程,你将会逐步得到担当这个职责所需的经验和信心。

当你寻找架构师时,需要考虑各方面的素质,他们过去的经验往往是他们有能力担当这个职责很好的判断。由于软件架构师的职责是多种多样的,所以你需要再深入了解他们在不同领域的参与度,影响力,领导力和责任感。一般来说,在大多数项目中软件架构可分为两个阶段,架构的定义,然后是它的交付。

软件架构的定义

架构的定义过程看起来非常简单明了。 你需要做的是理解需求并设计一个系统来满足需求。 但实际上并没有那么简单,根据你不同的做法,软件架构的职责之间差距很大,以及如何认真看待自己的职责而定。如下图所示,这个职责的架构定义部分,可以进一步细分成不同的元素。

The role of a hands-on software architect from a definition perspective

  1. 管理非功能性需求:软件项目经常陷入问用户要求是什么,什么是他们想要的功能,但很少问他们需要什么非功能性需求(或系统质量)有时候,干系人会告诉我们,“这个系统必须很快”,但是这太主观了。非功能性需求如果要满足的话需要明确,可度量,可获得以及可测试。大多数非功能性需求本质上是技术层面的而且经常对软件架构有很大的影响。理解非功能性要求是架构师职责非常重要的一个部分,但假设这些需求是什么并不一定是对他们的挑战。你见过多少系统真正需要24×7的运行呢?
    Management of non-functional requirements
  2. 架构定义:捕捉到了非功能性需求后,下一步是开始思考你打算如何去解决干系人提出的这些问题并定义它的架构。 公平的说每个软件系统都有一个架构,但并不是每个软件系统都有一个定义好的架构。这正是问题的关键。架构定义过程让你想清楚你打算怎么在兼顾需求和限制的情况下把问题解决好。架构定义是将结构,方针,原则和领导力引入软件项目的技术层面。定义架构是作为软件架构师的工作,但是从头开始设计一个软件系统和对已存在的系统扩展是相当不同的。
    Architecture definition
  3. 技术选型:技术选型通常是一个有趣的练习,但它也有公平的挑战,因为你需要综合考虑成本、许可、供应商关系、技术策略、兼容性、协作性、支持、部署、升级的政策以及最终用户环境等各方面。综合这些因素,通常会导致简单选择类似富客户端技术而进入了完全的噩梦。接下来的问题就是这些技术是否能真正有用。技术选型是彻头彻尾的风险管理;复杂性或不确定性太高的时候要减轻风险,当有机会或利益的时候要引入风险。技术决策需要考虑多种因素,而且所有的技术决策需要被检查和评估。这包含软件项目的主要组成部分乃至开发中引入的类库和框架。如果定义一个架构,你还需要有信心认为选择这项技术是正确的。同样在技术评估中也还是存在开发新系统和向现有的系统增加新技术的不同点。
    Technology selection
  4. 架构评估:如果你设计软件,你需要问问自己你的架构是否有用。 对我来说,一个架构是成功的,如果它满足非功能性需求,而且为其他部分的代码提供必要的基础,并为解决和存在的业务问题提供足够的平台。软件的一个最大的问题就是它复杂而抽象,导致很难从UML图或代码本身去设想出运行时的特性。在软件开发周期中我们进行了很多不同类型的测试,这样我们能够有信心我们发布的系统在推出时能够正常运行。我们为什么不对架构也这样做呢? 如果能够测试你的架构,那你就可以证明它是有效的。如果你能尽早做到这一点,你就能减少项目失败的风险,而不是简单地希望一切都好。
    Architecture evaluation
  5. 架构协作:任何一个软件都不是与世隔绝的,需要很多人理解它。 包括从需要理解和切入架构的直接开发团队到其他对安全性、数据库、运营、维护、支持等有兴趣的干系人。要想让一个软件项目成功,你需要和所有的系统干系人紧密协作来保证架构和所在的环境很好的集成。不幸的是,现状是与开发团队的架构协作很少发生,更不要说外部干系人了。
    Architecture collaboration

软件架构的发布

对于架构的发布也是同样,对于成功的软件项目参与程度的不同,也决定了软件架构职责的不同。

The role of a hands-on software architect from a delivery perspective

  1. 拥有全局的视角:为了把一个架构成功地实现,我们需要具有全局的视角并把贯穿软件开发生命周期的愿景加以宣传与推广,必要的话在整个项目中展开和完善,并对成功发布负责。如果如果你定义了一个架构,参与并保持不断发展的架构才是有意义的,而不是选择把它传递给一个“执行小组”。
    Ownership of the bigger picture
  2. 领导力:拥有全局的视角是技术领导的一个方面,但是还有其他事情在软件项目发布阶段需要做。 这包括承担责任、提供技术指导、作出技术决策以及具有权力作出这些决定。作为架构师,你需要进行技术领导来确保每件事都被考虑到,而且团队在朝着正确的方向持续前进。软件架构师职位是需要内在领导力的,虽然这听起来很明显,但很多项目团队并没有获得他们所需要的技术领导,因为架构师认为一个成功的发布并不一定是他们所关注的问题。
    Leadership
  3. 教练和指导:在大多数软件开发项目中,教练和指导经常不被重视,团队成员得不到他们需要的支持。 虽然技术领导是引导整个项目,但个人也经常需要帮助。除此以外,教练和指导提供了一个强化技能的方式,并帮助提升职业生涯。这应该是软件架构师份内的事,而且指导团队架构和设计与帮他们解决代码问题是截然不同的。
    Architecture delivery
  4. 质量保证:即使是世界上最好的架构和领导,很糟糕的交付也足以让一个具备其他成功条件的项目失败。质量保证在架构师职责中占很大一部分,但这并不只是简单做代码检查。 比如,你需要一个基线来确保,这意味着引入新的标准和工作实践。从一个软件开发的角度来说,这可能包括代码标准、设计原则和源码分析工具甚至于使用持续集成,自动化单元测试以及代码覆盖工具。可以说大多数项目质量保证做的并不够,所以你需要搞清楚什么是重要的并给予它足够的保证。对于我来说,一个项目的重要部分包括架构上的重点,关键、复杂或高度可见的业务。你要关注实效并认识到你并不能保证一切,要知道做总比不做好。
    Quality assurance
  5. 设计、开发和测试:软件架构师的职责范围的最后一件事是设计、开发和测试。作为一个实际动手的架构师并不是需要你每天都要写代码,但是它的确意味着你一直在参与项目,而且积极帮助打造和交付它。说了这么多,为什么每天写代码不应该成为一个架构师职责的一部分呢?大多数架构师都有写代码的经验,因此让这些技能保鲜是有意义的。而且,架构师能体会到团队里其他人的痛苦和感受,这样能让他们更好地理解他们的架构从开发角度看是什么样的。很多公司有政策阻止软件架构师从事写代码,因为架构师“去做那些廉价的工作太贵了” ,这显然是个错误的态度…如果架构师已经花了那么多时间精力为项目做架构,何必从政策上不允许他们多走一步来帮助项目达到最终的成功呢?当然,有些情况下卷入代码级别并不现实。比如,一个大的项目通常意味有一个更大的“全局观” 来考虑它,而且可能有时候你就是没有时间。但一般来说,一个写代码的架构师比只在旁边观望要更高效和快乐。
    Design, development and testing

你是一个软件架构师吗?

不管你认为软件开发和架构之间的界限只是一个幻觉还是个巨大的鸿沟,以上强调了人们对整个软件架构中的经验水平往往有很大的差别,而这取决于他们怎么样工作以及他们如何认真地看待他们的职责。大多数开发人员不是在某一个星期一的早晨醒来就宣布自己成为一个软件架构师的。我当然也不是,我成为软件架构师的路线是一个渐进的过程。话虽如此,但很可能同样那些开发者已经做了一部分架构的工作,不论他们的职位名称是什么。

为软件系统的架构作出贡献和自己负责定义它有很大的区别,拥有持续的、跨不同领域的技能、知识和经验构成了软件架构的职责。跨越软件开发者和架构师的界限取决于你自己,但是首先你要明白你的经验水平,才能开始架构师之旅的第一站。

关于作者

你可以认为Simon Brown是一个写代码的软件架构师或者理解架构的软件开发者。当他没有用.NET或Java开发软件的时候,Simon通常在做咨询,指导或者培训。 Simon还写过关于Java的书,在行业活动做过演讲,并且整合了一个叫Software Architecture for Developers的培训课程, 该课程基于他在Coding the Architecture描 述的软件架构。你可以通过e-mail 或Twitter 找到他。

查看英文原文Are You a Software Architect?

 

 

CruiseControl.rb初体验

版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://bigwhite.blogbus.com/logs/27940065.html

我所在的项目一直以C语言作为主要开发语言,与做Java以及其他新兴语言的人不同,组内的同事似乎对新鲜的东西不是那么感兴趣,也没有主 动去研究新鲜事物的意愿和意识。我深为此闹心,看到外面世界中那么多美妙的工具,再也不能坐以待毙了。我一直都是有很多想法的,但是迫于自身精力有限,自 己无法全身投入,以前都是交予别人去做的,但是收到的效果都不是很好。认识到这点后,我决定自己动手,丰衣足食。

从心底一直对公司的 CMMI流程有所抵触,眼看着外面世界中的Agile Development等轻量级开发过程日益壮大,但自己每天还不得不按照各种繁复的流程去做,真有一种”身在曹营心在汉”的感觉。但是在一个CMMI流 程”森严”的公司,又如何才能让大家接受Agile的思想呢?我想让大家看到新实践的与以往不同的成效,大家自然也就能够接受了。在Infoq上,有人也给出了建议:“切莫开口提大名词(例如SCRUM或者XP)。建议以CMMI x级的”自我改进”做旗帜,找到组织中存在浪费的环节,引入最佳实践来消除浪费,没有必要把敏捷挂在嘴边 ”。而持续集成也是文章中建议的首选实践,与我的想法不谋而合。

持 续集成,以前不是没有做过,在部门的一个项目组中曾经尝试过,自己编写脚本,完成定时更新代码、构建的任务,后因项目紧张,似乎没有收到良好效果。我也曾 经在项目组内推进过做Java的同事进行持续集成的实践,并安排一个同事搭建了CruiseControl的服务器,但后来似乎不了了之,也怪我没有在后 期给予充分的重视和压力。有过这些教训后,我时常也在想?推进一个持续集成的实践就这么难么?这回我亲自来做,从C开发人员入手。

持续集成是需要良好的工具支持的,业内最知名的持续集成工具莫过于CruiseControl了,CruiseControl 在Java开发领域占据着No.1的地位,而且其设计思想也影响着后续的持续集成工具的开发。但是一想到Java,我第一感觉就是复 杂,CruiseControl会不会也像配置一个Web服务器一样那样复杂呢?另外CruiseControl使用Maven + Ant + cvs/subversion的组合,我曾经研究过Ant, Maven,大量的xml配置让我感到很头疼,另外是否与C/C++良好配合也是疑问。这样一来,我就没有继续走CruiseControl这条路,我尝 试寻找一种配置简单能快速上手,核心功能也不逊于CruiseControl的工具,Thoughtworks的CruiseControl.rb走入我的视野。

一直关注Thoughtworks,因为以前部门的两位大牛级别的同事都在那任职,另外Thoughtworks推出的产品也的确让我很感兴趣,以前就曾研究过Mingle, 只不过Mingle是收费的,而且目前性能还有待提高。CruiseControl.rb(以下称为CC.rb)是Thoughtworks的一款开源作 品,其主页上的一小段话很是对我的胃口:”continuous integration isn’t rocket science. we keep it simple.”。简单,正是我所期望的。

目前CC.rb的最新版本是1.3.0, 下载后就是一个压缩包:cruisecontrolrb-1.3.0.tgz。解压后,在你的当前目录下会出现一个cruisecontrolrb- 1.3.0的目录。CC.rb的依赖非常之少,你只需要在你的集成服务器上安装上ruby和svn客户端即可,注意:ruby和svn的可执行程序的路径 需要添加到你的环境变量的PATH中,否则CC.rb将无法找到ruby和svn。目前CC.rb只是支持Svn,其他版本管理工具尚未得到支持,毕竟 CC.rb还年轻,开发时间较少,情有可原。

现在CC.rb已经安装完毕了,没错!CC.rb是用ruby实现的,ruby是脚本类语言, 无需编译。你现在就可以进入cruisecontrolrb-1.3.0目录下,执行”cruise –version”(在Unix主机上,你需要先将cruise文件chmod一次,否则cruise将无可执行权限),你会看到:
CruiseControl.rb, version 1.3.0
Copyright (C) 2007 ThoughtWorks

现 在你可以添加和配置你的project了。这里要先说一下,CC.rb默认将用户的project数据放在$(HOME)/.cruise/下面,如果你 是在Windows平台上,project数据会被默认放在C:\Documents and Settings\USER_NAME\.cruise下面。添加一个proj很简单,你只要提供足够的信息即可:进入到 cruisecontrolrb-1.3.0目录下,执行命令:
cruise add PROJ_NAME –url SVN_URL –username USER_NAME –password PASS_WORD,如果你的svn库有权限管理,你需要提供user和passwd。举例: cruise add test_proj –url svn://192.168.0.2:3999/trunk/test_proj –username tony –password tony

这 样你就在$(HOME)/.cruise/projects的下面建立了一个test_proj的工程,如果你提供的信息是正确的,CC.rb会在初始建 立工程的时候,将你的svn库中的代码checkout出来一份最新的,放在$(HOME)/.cruise/projects/test_proj /work下面。

完成上一步后,$(HOME)/.cruise目录下面有几个配置文件是我们需要重点关注的:
$(HOME)/.cruise
 – config/site_config.rb
 – projects/test_proj/cruise_config.rb

$(HOME)/.cruise/config下的site_config.rb文件是一个全局性的配置文件,无论你在一份CC.rb下建立几个proj,这些proj都会共享该配置,该配置每次修改后都需要重启CC.rb才能生效;该文件中有两个最主要的配置:
1) 邮件服务器配置
如果你想将每次build的结果通过mail的形式发送给相关干系人的话,你就需要配置你的mail server相关信息。
ActionMailer::Base.smtp_settings = {
   :address =>        “xx.xx.xx.xx”,
   :port =>           25,   #一般服务器默认smtp端口都是25
   :domain =>         “YOUR_DOMAIN.com”,
   :authentication => :plain,
   :user_name =>      “YOUR_USER_NAME”,
   :password =>       “YOUR_PASSWD”
 }
2) Dashboard URL
Configuration.dashboard_url = ‘http://ip : port’; Dashboard URL将被加入到发给干系人的mail中,这样相关干系人收到mail后可以直接点击该url登录到CC.rb的Dashboard查看相关内容。 CC.rb的配置文件也同样适用ruby语言编写的,ruby语言语法较为简单,相信大家都看得懂。

$(HOME)/.cruise /projects/test_proj下的cruise_config.rb文件则是一个Project-specific的local配置文件,它是 动态更新的,你的更新在下一次build时是即时生效的。该配置文件中的内容都很重要和实用:
1) project.email_notifier.emails = [’email1@your.site’] 该配置用于添加干系人邮件,这样每次build后,CC.rb都会读取该配置,发送mail给该email list的人;
2) project.email_notifier.from = ’email2@your.site’,该配置将指定notify mail中的发件人,你可以因项目的不同而配置不同的mail。
3)  project.rake_task = ‘custom’,似乎该配置只有当你使用rake这个工具时才需要配置,如果你使用诸如ant,make等工具的话,该配置还需保留原先的被注释状态;
4) project.build_command = ‘build_my_app.sh’,该配置给予你自定义build脚本的机会,也正是这样,你才可以将CC.rb与Ant, Make等工具集成在一起使用。如:project.build_command = ‘make’。注意CC.rb执行build_command的working dir是$(HOME)/.cruise/projects/test_proj/work下面,如果你的build_my_app.sh没有放在 work下面,而是在$(HOME)/.cruise/projects/test_proj下面的话,你这块就要配置 成:project.build_command = ‘../build_my_app.sh’; project.build_command与 project.rake_task不能一起使用。
5) project.scheduler.polling_interval = 5.minutes ,CC.rb定期去检测svn是否有new revision,这个配置就是用来指定检测周期的,如果你不配置,那默认是30s。

如 果你以上都配置完毕了,你现在就可以启动CC.rb了。启动方法:进入到cruisecontrolrb-1.3.0目录下,执行”cruise start -p port”。CC.rb会启动自带一个轻量级web server – WEBrick ,对于我这个对web server不熟悉的人还是很方便的,我只需要告诉CC.rb端口即可。CC.rb启动后,你可以在浏览器输入http://ip:port,CC.rb 的简洁的页面就会显示出来,你会在页面上看到你刚才建立的工程test_proj,点击右上方的”build now”按钮,你就开始了一次build的过程。无论成功还是失败,你都应该收到一封mail,关于此次build的详情可以点击mail中的链接。如果 失败了,你可以在页面上的”build log”中看到此次build的详细日志,以帮助你分析失败原因。

CC.rb是如何判断build 过程成功还是失败了呢?我们以project.build_command = ‘xx’的配置为例,其实CC.rb是通过判断xx这个builder的返回值来决定build过程是否成功的。当xx这个builder返回0,说明 build成功;否则build失败;我们不妨测试一下:在$(HOME)/.cruise/projects/test_proj/work下面写一个 小程序:
/* test.c */
int main() {
 exit(0);
}
gcc -o test test.c

配置project.build_command = ‘test’,点击”build now”,收到mail,提示build success;如果你将exit(0)改成exit(1),那么一封failed的mail就会发到你的邮箱里。

C/C++没有很好的单元测试工具,一般C/C++单元测试工具都 会将单元测试用例编译链接成为一个可执行文件,然后执行,以判断是否通过。到这里你是否想到了如何将C/C++的单元测试与CC.rb集成到一起的方法 呢?对,我们通过脚本也好,或者干脆自己编写一个单元测试框架,通过程序返回值告知CC.rb新提交的代码是否通过了单元测试的考验。

以上是第一次使用体验CC.rb时记录下的内容,其实CC.rb就是这么简单!

ScrumMaster项目面谈诀窍

 

作者 Shane Hastie 译者 金明 发布于 2009年7月16日 上午9时58分

ScrumMaster或者迭代经理在敏捷团队里面是一个关键角色,而且,对于ScrumMaster,选择与哪个组织合作或者与哪个团队共事是非常重要的——在考虑是否接受一个新项目的时候,很重要的是创造一个取得成功的环境。

敏捷宣言强调个体胜过流程,而ScrumMaster的很大一部分职责就是创建团队氛围,让人们互相合作,有效地交付可工作的软件。

Scrum官方网站把ScrumMaster的职责定义为

ScrumMaster负责在团队中正确、完整地贯彻Scrum流程。虽然在实施开始的时候必须做一些折衷,而且因为实施环境的限制不得不放弃某些实践,但是ScrumMaster在脑海中始终要铭记实施完整的Scrum所带来的好处和价值,渐进地推动团队和组织走向完美状态。

ScrumMaster特别要对以下工作负责:

  • 清除挡在客户和开发工作之间的拦路虎,客户从而可以直接驱动开发。
  • 教导客户如何最大化ROI,以及通过Scrum实现他们的目标。
  • 通过激发创造性与推动授权来提升开发团队的成员
  • 以任何可能的方式提升开发团队的开发效率
  • 改进工程实践和工具,使得每次功能性上的改进都能得以交付

因为角色的关键性,所以有两点很重要:首先,确保在团队里面担任ScrumMaser角色的人必须名至实归;其次、确保团队的环境氛围有助于取得成功。博客Scrumology的作者David J Bland为有可能成为ScrumMaster的人提供了一个列表,包含10个问题,供他们在考虑换个团队或者项目的时候参考:

1. 你们的迭代周期是多长?——理想状况下应该是2周,但如果有理由显示这个周期太短了,这是个积极的信号。但是,如果答案是长达几个月,你就要小心了,因为这绝对不可能敏捷。

2. 你们的团队有多少人,怎么构成?——小型的、跨功能的团队非常重要。如果对方倾向于使用大量开发人员,而且各自职能严格划分,你就要小心了。此外,团队是分布式开发,还是坐在一起,这你也应该弄清楚。

3. 你们的Product Owner能及时回答问题吗?——找不着人的Product Owner会严重破坏敏捷团队。这可能就是为什么ScrumMaster职位空缺的原因了!

4. 你们引入了持续集成吗?——如果部署程序还是依赖于繁琐的批处理流程,是很难坚持敏捷原则的。努力限止他们对现有工具的继续使用,不要让他们逃避这个问题。

5. 你们使用测试驱动开发或者测试驱动设计吗?——理由跟上面的CI(持续集成)一样,TDD是敏捷与否的另一项指标。再一次,努力找出他们在现有流程下选用的工具集,在不同的技术栈下这会有所区别。

6. 你们怎样记录用户故事?——这个问题没有最佳答案,但对方应该就任务板或者项目管理软件中记录的功能简单讲一下。如果碰见过长的软件需求规范或者功能规范,就应该亮起一盏红灯了。

7. 你们使用哪些衡量指标来跟踪进度?——故事点数或者小时数应该就足够了。我会注意他们(估计故事点数)的斐波那契数范围是否已经到了极致。比较实际和预估的故事点数可以把会谈带向有趣的方面。试着判断团队成员是否使用了实际故事点数。

8. 你们的团队多长时间碰面?——如果ScrumMaster的工作做好了,答案应该是每天!对于分布在不同时区的分布式团队,这可能颇具挑战。

9. 你们的敏捷实施有上层支持吗?——我曾在没有上层支持的情况下实践过草根式的敏捷,得到的经验就是:在不知道全局的情况下,我绝对不会贸然开工。如果老板宣称甚至CxO们[译注1:指CEO/CTO/CFO…等以C开头的职务]也接受过CSM/CPO培训,这对我来说是一个很大的有利因素。

10. ScrumMaster还有什么其他职责?——根据组织不同,这会有所差别,但这个问题还是有必要问的,特别是如果那些职责丝毫不能引起你的兴趣。最好是现在就弄清楚它们。

Johanna RothmanSteve SmithGeorge Dinwiddie,以及Aye Conference的其他主办者给面谈双方提供了一个清单,就面谈和评估提供了一些很有益的提示

面谈提示:

  • 尽可能使用开放性问题
  • 尽可能使用描述行为的问题来得到真实的例子
  • 使用元问题提问“然后呢”,从针对技术人员的战术问题转向询问单独的、与管理相关的战略性问题

面谈陷阱:

  • 不要问领导的问题,比如“你的经理是个蠢材吗?”你永远不可能得到一个诚实的回答,而且问题本身也暴露出你的忠心度、诚实度和可信度。一个问题就会让你减分不少。
  • 避免询问对方的主观观点,比如“你喜欢你现在做的事情吗?”相反,把问题改成“这里什么对你是有效的?”以及“哪些东西妨碍了你完成自己的工作?”

除此之外,试图弄清底细的ScrumMaster还会遇上什么陷阱,又该如何避免呢?在这里留下你的经验分享吧。

查看英文原文:ScrumMaster Interview Tips