FireOfStar的专栏

   传真 Fax QWu 11.5606 Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExpl

   我们把代码审查叫做CR，即Code Review。它是项目进展到编码阶段非常重要的品质保证活动。但是很多时候，我们的CR工作都流于形式，在CR过程中不能发现本质问题，主要有以下四点原因：   一，CR时的目的性不强，缺乏针对性。CR的根本目的是保证品质，但不能把它做为一次CR活动的直接目标，这样的目标太泛泛，让我们在CR活动过程中抓不住重点。   二，CR活动时参与的角色不合理。参与CR活动

 小工程表做为开发过程中的最小计划单位，在实际工作中有着指导工作内容、监督跟踪工作进度的重要作用。不恰当的小工程表不但不能指导相关人员的作业，而且还会给项目的监管者传递一些错误信息，从而导致对项目状况的错误判断。那么在制作小工程表时要注意哪些问题呢？ 一．做为计划单位的任务单元是否进行了完全的分解且可度量。经常看到这样的计划安排：     任务：Button的单击处理     作业期间：xxxx年

  云计算，近段时间很火，IBM、Google、微软等国际IT巨头都在不遗余力的宣传推广，起初以为是什么新技术，于是就找了些资料来看，思考后的结论是：与其说是新技术，不如说是IT行业中一种新的商业经营模式更为贴切。  如果云计算中没有新技术，也是不可能的事。从技术的角度上说，要实现企业计算的异地化和虚拟化，首先需要对现有的IT资源（包括系统软件技术、应用软件技术、硬件技术和设备、网络技术和设备等）

     Asp .Net 网页（官方叫做Web Forms）是Asp .NET应用程序的重要组成部分，它提供了Web应用程序的实际输出---用户在浏览器端请求和观看的网页。     尽管网页不是什么新事物，但是对于ASP .NET Web Forms的概念则是全新的。本质上，Web Form 允许你像创建基于控件接口的Windows应用程序一样创建Web应用程序。要运行一个ASP.NET的W

良好的交流可以有效的降低项目的开发成本，相反不但可能数倍的增加成本，甚至可能导致项目的失败。   怎样在项目执行过程进行有效的交流呢？   1. 识别项目中交流主体。   2. 明确交流主题、内容、目标。   3. 做好交流记录、分析、整理、执行。   4. 交流要客观、包容，不应带有主观情绪。

一.交流的对等性    交流双方要对问题有充分的认识和了解，彼此要对自己的理解进行充分而详细的表述，交流过程中不能因为职位的高低不同而左右对方的客观表述。二.交流的有效性    交流的主题要明确，最终双方要达成共识，没有共识的交流是无效的，不能做到软件实现中。三.交流的时效性    交流的问题要有前瞻性，这样才能对后续开发具备指导意义。四.交流的规范性    交流过程过

什么是软件的用户体验？简单的说就是用户使用软件过程中的内心感受。界面的美观程度、操作的易用性、引导的适当性都会对用户的使用体验形成影响。好的用户体验不是替用户做所有的事情，而是在想要做某件事情时，能够适时的、恰如其分的给予引导和说明，帮助用户简单、高效的完成其要做的事情。

1.HTML5是什么？  HTML5是我们所知道的HTML标签、DOM（Document Object Model）、CSS、Javascript的统称。其实，我们在HTML5之前的版本中，编写网页时，在进行显示的渲染和网页的内部交互时也常用到这些技术，但是它的缺点是只能访问本地资源的能力很弱，几乎是没有。在HTML5中对这些能力进行了增强，增加了一些新的标签（如Canvas，用于2D图形的加

大数据时代的基本表象是数据的智能化，即我们可以通过海量数据的收集和分析，来有效的描述一件事情当前的状态，相对准确的预测其未来的结果。从这个角度来思考大数据，我们就不能简单的用数据的体量来理解大数据，在从数据到信息、从信息到知识、再从知识到智慧的演化过程中，我们需要跨学科、跨领域整合众多人类智慧，我们所面对的计算机世界将再也不是冰冷的键盘、鼠标、显示器加主机了，一个丰富多彩的带有智能感知和情感的计算

用户体验已经成为移动互联网时代的职位新宠。记得刚刚进入软件研发这个行业的时候，一个软件工程师就可以基本搞定一个小的应用软件的开发，用户对交互体验好像没有要求，有的只是好奇、羡慕和赞赏，用户是真的没有体验的要求吗？答案当然是否定的，只不过用户的认知还没有达到谈体验的层次而已。        真正的软件交互体验又是什么样的呢？历经了Dos时代、Widows时代、移动互联网时代，辛苦的IT从未停止过

   缺陷管理作为软件项目开发过程中记录、跟踪项目缺陷的有效工具被广泛使用。为了方便快捷、清晰有效的把握项目中的问题点，在使用过程中，我们会通过不同的状态来描述缺陷的发展轨迹。   我们通常使用的缺陷状态有：登记、发行、调查、对策确认、修正、结果确认。从这六个状态中我们不难看出，一个缺陷从发现到解决的过程中我们需要完成的作业内容。下面就具体说一下缺陷处于不同状态时，相关责任者要完成那些作业。  

   软件项目在开发过程中，拥有一个稳定的核心人员体制是非常重要的，这个核心体制中至少应该包含管理者、技术专家、业务专家三种角色。当然如果条件允许，再配以配置管理员、品质管理员就更加完善了。   做为核心体制中的管理者，通常情况需要肩负以下责任：   1、做为窗口，与客户进行沟通交流，既要保证把项目的状况及时地反映给客户，也要把客户的需要及时准确的反映给开发团队；   2、决策。对于项目中的一些重

        在软件项目的开发过程中，我们必须要面对这样一个现实问题，就是风险无处不在。如果不能正确的识别和控制风险，那么点滴的疏漏就有可能把项目推向崩溃的边缘        首先，软件项目中的风险具有繁殖能力。如果不能识别项目中的初级风险，那么这个风险很可能在项目推进过程中衍生出其他风险。如用户需求定义过程，没有充分理解用户的意图或用户的操作习惯，而是想当然的定义用户的需求，那么就会给系统框架

<! /* Style Definitions */ table.MsoNormalTable {mso-style-name:標準の表; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-al

   软件测试作为保证软件项目产品的品质的关键环节，已经逐步的在软件开发领域发展成为一个独立的专业，并且越来越受到业内的关注和认可。测试用例作为检验项目品质的标准，需要在测试测试环境、测试数据、测试方法、测试结果等方面进严谨科学的分析和设计，以保证测试的覆盖率、有效率等指标。测试不是开发人员简单的Dubeg过程，也不应该是简单画面点击确认过程，它是在测试用例的指导下，独立于编码思维之外的缺陷查找过

  在进入正题之前，我们有必要简单的比较一下传统的制造业与软件业在生产方式的差异。  1，传统制造业是机械化作业，软件业是人的思维转化作业；  2，传统制造业的生产过程具有流水性，软件业的生产过程复杂多样，有貌似流水性的瀑布型，有螺旋攀升型，快捷原型法等  接下来我们可以看一下传统制造业提高生产率大多采用的方式和手段  1，提高作业人员的熟练度；  2，提高作业的机械化程度；  3，改善生产工艺等

   我们都知道在实践中学习积累的重要性，那么在应用软件的开发项目中，我们应该注意学习积累哪些知识呢？  常常看到一些程序员对某些软件开发技术和理论的执著，也常常听到一些程序员谈论某某项目的技术含量的话题。软件专业开发技术，作为程序员的立身之本，受到这样的厚爱是无可厚非的。但是软件作为一种多种知识集成的载体，我们不能只把眼光盯在专业的开发技术上，还应该看到其中包含的丰富软件应用领域的业

  两个命题，一个是对客户的态度，另一个是对项目品质的态度。仔细想一想，这两个命题其实是有密切关系的，于是就合到一起，谈谈自己的看法。  先说客户和项目品质的关系，个人认为他们是互为因果的，因为没有客户我们就不会有项目，反过来没有好的项目品质，我们又会失去客户。  对待客户的态度，归结到文字上其实很简单，八个字“勤于交流、尊重互信”，但是如何做好这八个字却很难。就交流来说，

  尾随着金融风暴，经济危机悄然而至，这对于刚刚走出襁褓的中国软件外包业，无疑有些生不逢时的感觉。  首先是市场需求萎缩，订单的减少。由于危机的爆发，各行各业都在精打细算，压缩开支，很多IT实施计划将会取消和放置，我们以往每年30%以上的增长率将不复存在，有些企业甚至有可能出现负增长。  其次是提价空间有限，甚至没有。长期以来，我们所接受的订单大都是二包、三包，甚至是四包、五包，中间截流环节太多，

  很多同行都在抱怨对日外包项目的技术含量低，从项目中学不到东西，得不到提高。其实这是一种不成熟的表现，无论是外包项目或其他的什么项目，单纯的依靠学项目中技术点来提高自己，那进步的速度就可以和蜗牛相比，试想软件中的开发技术千千万万，这样的学法，我们要做多少个项目,才会成为"牛人"啊！  其实每个项目，不论大小，只要用心都会发现能够让自己提高的东西。一个成熟程序员的表现是思考问题、解决问题的独立性和

   在应对项目风险时，常用的对策有两种，一是加班；二是加人。这两种对策是否能够有效的解决项目风险呢？其实是很值得商榷的。   很多软件项目从一开始就加班，本以为做到后期可以轻松些，可还是加班，为什么？究其原因：   一，项目组的角色分工不合理，缺乏层次感。很多项目组成员是从前期设计一直做到系统交付，在这样的作业方式中，有的人是会被大材小用，也有的人会被拔苗助长。一个项目组在作业过程中加班是正常的

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 <!-- /* Font

  我们经常会采取一奖励措施，来激发大家工作的积极性，从而达到提高工作效率的目的。那么我们应该对项目组中的那些类型的人实施激励呢？项目的实践过程中，笔者认为有两类人需要给予正面的奖励。  一，能够主动思考，准确高效的完成作业的人，即孙悟空类型的的人。对于这中人的奖励不是单纯的对其技术能力的认可，更不能因为其作业高效而分配给他大量的额外的作业。我们要通过奖励措施，鼓励他发挥核心作用，使其在完成自身任

在项目管理中，最常被提及的就是QCD，即品质、成本和交付，但是在执行过程中往往是事与愿违，常常是摁下了葫芦起了瓢，所以辛苦的IT人总是不停的在探究相关的项目管理办法，瀑布、迭代、敏捷等等方法层出不穷，可我们的QCD却好像总是在跟我们的项目管理者做对，延期、超预算、本质低下会毫不留情的砸向项目的每个参与者，这是为什么？       项目管理方法中最常提及的过程管理和过程改善，通常我们的项目管理者