ulark的专栏

<br />我们都是软件行业是世界所有的行业中，失败率最高的。进度最没有办法度量的，通常会拖，一拖再拖，而且人员都扑上去了，可是还是慢。<br />　　为什么？<br />　　多少年，多少人，更有很多的专业公司都在分析这里面的原因。为什么我们的人员都在加班了，没有人偷懒，都很努力，效率却上不去？<br />　　据我分析和思考，认为可以从下面两个角度看这个问题：业务和技术。究其原因的话，有下面几个常见的原因：业务混乱。业务是软件的基础，软件是为业务服务的，这尤其在应用软件开发中是最常见的。可是很多时候我们太急

<br />软件项目的制作过程中，编码阶段可以认为是体力劳动，但是在设计阶段那绝对是脑力劳动。因此对于具有丰富情感的人来说，情绪不可避免的会影响到软件项目的制作。项目管理如此，企业的管理同样如此。<br />企业对于员工期望的满足度，是影响员工情绪的主要因素。而员工的期望不仅仅是办公环境、薪金福利等物质因素，更多的则是员工在工作中得到来自其他个体的信任与支持，以及送人玫瑰手留香之后的自我感觉。<br />管理者给予员工的信任与支持是建立在对员工工作肯定与帮助之上的。积极的期望管理可以促使员工不断的上进，员工

<br />团队开发与个人开发有着很多不一样的地方，个人开发什么东西都自己做，自己就是标准，不需要考虑自己的设计或者代码其他人看不懂或者别人写做的东西自己看不懂等情况。因此，团队开发需要定一些标准，这样才能方便成员之间的相互交流与配合。另外，资源的共享，编码阶段的代码分工与合并，要求团队之间必须要有一个公共的平台-----团队开发环境。因此，团队开发最重要的是要解决两个问题，一.标准化。二.开发环境。<br />标准化会在其他的地方整理。这里主要解决一下公共开发环境的搭建。<br />　　开发工具主要使用V

<br />在上一家公司做了4年多合作过4个项目经理，各自多有自己的不同风格：<br />　   有的是技术背景非常深厚，靠着这个实力，对项目组成员做着强势的领导，关键时刻总能提出解决方案，往往奏<br />效，项目都能按计划完成。后来他领导了一个公司的关键项目，并成绩斐然，最后获得的那一年的公司优秀项目<br />奖。<br />     有的是技术背景不错，对产品设计的来龙去脉都很清楚，工作经验丰富，为人坦荡，非常负责，但是对项目管理<br />的流程不是很清楚，缺乏这方面的经验。他领导的项目最后也做成

我们的正常工作有一大部分是消耗在日常的各种会议中的，普天之下，各行各业，大小公司、组织、群体，都免不了这样的举动。而且伴随你的权利和身份，相衬着你滞留在那个圆桌的时间也是流逝得长长短短。屁股一坐，茶水一摆，静心冥听，台上滔滔不绝，台下流连妄想。　　我们“软件人”熟知的IT行业，也是如此。大会不断，小会如麻；有三五天的惊世讲坛，也有三五分的简单畅快；公司例会，部门月会，项目周会，小组天会，大大小小，形形色色总是缠绕在你的周围。主持、讨论、建议、记录、聆听、冥想、开溜，一个都少不了。。。。　　前

别人总觉得是在显吧，干脆把这个项目认为是小项目了，不知道把这个项目是小了，别人会不会又觉得又显吧了？说大也不行、说小也不行，也的确没招了。  我想主要把项目里遇到的问题分享给大家一起探讨，也并不是为了什么显吧什么的，希望大家用一个正确的心态阅读此文章，希望有更多的朋友把更大软件项目的经验分享给大家，让大家知道一下，大型软件项目里都会遇到什么问题，如何解决才好，我们平时做些什么准备工作比较好？

CMMI 是英文Capacity Maturity Model Integrated的简称。中文的译意是能力成熟度集成模型。CMMI是CMM模型的最新版本。早期的能力成熟度模型是一种单一的模型其英文缩写为CMM，较多地用于软件工程。随着应用的推广与模型本身的发展，改方法演绎成为一种被广泛应用的综合性模型，因此改名为CMMI模型。早期的CMM是美国国防部出资，委托美国卡内基梅隆大学软件工程研究院开发

软件生命周期：　　1.萌芽阶段 2.定义阶段 3.具体阶段 4.设计 5.开发 6.测试 7.试运行 8.上线　　1-2：产品概念的明确，有哪些模块？大块功能？特性功能？　　学习的知识：　　s1.学习相关领域知识！！必须地！！　　s2.了解产品客户群，具体产品使用角色，该角色在真是生产中的工作流程，哪些可能需要在产品中哪些？！重要！　　s3.明确项目组可以做到功能范围，包括

需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%,因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原

最近正在做新产品的需求分析，对需求分析阶段的很多问题又有了重新的认识，在此结合以前的经验，就软件需求分析阶段的各个任务，做一下总结，与大家分享。 　　众所周知，软件需求分析是软件生命周期的第二阶段，主要对前期软件定义及计划阶段提到的任务及计划进行概要的补充，需求分析的主要任务不是确定将来的系统怎么完成某项工作，这是设计阶段的事情，而是明确系统将要完成什么功能，对目标系统将要完成的功能提出完整、

对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)—开发者开发

<br />富士康、华为员工跳楼事件，在媒体与舆论的背后，与死者们处于相似境地的我们，需要更多冷静和专业的思考，以及应对。在这篇文章中，我将目光集中在“压力管理”这个现代企业管理的名词上。<br />认知压力<br />消极怠工、负面评论、伤害团队直至放弃工作……这些行为的背后，反应的是一个处于“压力曲线”右侧最低点员工的真实现状。（因作图不便，暂缺图形）。<br />压力曲线是一条纵坐标为产出，横坐标为要求的上抛物线，形似一张弓。抛物线左侧的上升曲线，是“积极压力”的描绘。处于此情况下的人员，要求给予了他

软件开发中文档的编写是一个不可缺少的环节，常见的如《需求分析》、《概要分析》、《数据库设计》等。在“软件人”的阵营里向来存在两种观点，注重文档还是关心代码。一直争论多少年了，好像都没有一个真正的定乱。如果大项目且开发周期相对合理，很多时候项目组一定会安排进行相关开发文档的编写；但对于周期短工作量又多的时候，可能很多项目组就会选择代码编写为第一的原则，相应的文档编写很多时候被安排在项目演示甚至交付后才进行补救式的操作，而且这样的文档很多都是归于应付客户要求的形式罢了。项目周期与质量保证向来是相矛盾的，如果为了

<br />一.为什么要写该系列日志<br />      之前，总是觉得花时间去写博客，是浪费时间，总是去转载别人写的好的文章。后来看了一篇《为什么你应该（从现在开始）写博客》,深受启发，打算认真的开始写一点自己的东西。一来可以锻炼自己的写作能力，二来可以记录一下自己的成长过程，也许，理由不只这些，但是，至少这两点理由已经足够了。虽然之前做过一些项目，但是，总是以完成项目为目的，没有很好的去沉淀一些东西，所以，本系列的日志，以该项目的整个开发过程作为记录的主线，该总结的总结，该从新学习的学习，该记录的记录

<br />一、需求分析<br />    需求分析是对用户的业务活动进行分析，确定系统的目的、范围、定义和功能，明确在用户的业务环境中软件系统应该"做什么"。只有在确定了客户需求后，知道要“做什么”，才能够分析和寻求系统的解决方法，开展后续的工作，所以需求分析是软件工程中的一个关键过程。<br />    这一步骤 要产生用户需求说明书，这个说明书既是给用户看的也是给开发人员看的，可以让用户更加确定自己的需求，让开发人员了解用户的需求。可以在需求说明说中包含业务流程图，来描述项目的业务流程。<br />二

世界上做任何事，都是从计划开始，一件事情的成功也必定拥有一个周全的计划。完成丰功伟绩，我们需要设定不同的里程碑以达到最终目标；做好一件小事，我们同样需要知道什么时间该做什么步骤。计划永远都是绑定在事情上的，它是整件事情实施周期开始的前奏。没有良好的运筹帷幄，就不能有良好的开始，当然圆满的结局就更别想啦。在一个软件项目中也是同样的道理，项目前期我们要制定计划，项目立项，草拟建设方案，分析讨论可行性，投标参与以及如何中标等；项目中标签订合同后，实际上才是项目真正意义上的开始，这时我们需要做的是任命项目经理，建立

<br />项目经理这个角色说大不大，说小也不小。在大公司，项目经理这样的角色可能存在不计其数，他们很多都是寄托于项目的存在而生，项目的完成而终；但对于一些小作坊的软件公司，项目经理一职很多时候是一个长期持有的过程，拥有这一角色的人，很多时候就是主要研发群体甚至全部团队的核心领导人，这些人很多时候属于公司的顶梁柱、火线人员或突击队长。在我们看来项目经理就开会、陪客、吃饭、吹牛B，一天正常的8个小时工作时间，没几个点能看见他的身影，整天来无点去无踪，“那谁谁谁，你这今天的任务是什么什么，你你你，那东西怎么样啦

<br />从一个项目管理培训小游戏谈起<br />      5个人分别代号为A、B、C、D、E，5个人按如图顺序坐好：<br /><br /><br />        <br />     培训老师分给每个人一张考卷，B、C、D、E的考卷上只有5个形状各异的图形，A的考卷上除了自己的5个图形，还被告知小组的任务是：总共有六种图形，在每个人的考卷上有其中的5个，要求找出5个人都有的那个图形。<br />      <br /><br /> 游戏规则为：<br />1)       各自的考卷是互相保密的

<br />团队开发中，核心灵魂是什么? <br />　　大家异口同声的说是凝聚力，或是团结，从小老师就教导我们“团结是铁，团结是钢，团结是不可摧毁的力量，众人划桨开大船“，我们回答这个问题，想都不想，就像回答 1 + 1 = ？一样简单。<br /> <br />现在我假设一个简单的场景： <br />开发人员：项目经理，程序员A，程序员B, 程序员C。<br />项目模块：一个投票模块（发布投票，投票，查看投票三个功能页面）<br />开发时间：3 天<br /> <br />开发方式A:<br />S

<br />一、需求分析<br />    需求分析是对用户的业务活动进行分析，确定系统的目的、范围、定义和功能，明确在用户的业务环境中软件系统应该"做什么"。只有在确定了客户需求后，知道要“做什么”，才能够分析和寻求系统的解决方法，开展后续的工作，所以需求分析是软件工程中的一个关键过程。<br />    这一步骤 要产生用户需求说明书，这个说明书既是给用户看的也是给开发人员看的，可以让用户更加确定自己的需求，让开发人员了解用户的需求。可以在需求说明说中包含业务流程图，来描述项目的业务流程。<br />二

<br />一个项目中需求调研的充分与否是项目日后成败的关键要素之一，这一点我想没有哪位项目经理不认同吧？不过咱说的需求调研可不只是拿张纸记记客户说什么就完了，调研顾名思义就是调查和研究客户的想法，我感觉应从以下几个步骤入手：<br />　　1、客户想要什么？<br />　　2、要这干什么？<br />　　3、为什么这么想？<br />　　4、会不会有别的想法？<br />　　这里也说一个最最最最基本的，只谈项目别谈钱，我们可以说，价钱嘛需要我们回去详细的分析过您的需求后再给您提供一个整体的解决方案，您放心

<br />在上一节中，我们就需求分析过程中IT部门与业务部门的分工、沟通等方面，与聚冠因尚的咨询顾问杨春波进行了交流。接下来我们继续就以下三个问题，与专家探讨“如何跟业务部门谈需求”。<br />1、在需求分析阶段，您觉得获取IT“需求”的途径有哪些？<br />聚冠因尚杨春波：<br />至少有三个途径。一个是“拿来主义”，一个是“直接调研”，一个是“混合式”。<br />首先说“拿来主义”。现在是“知识爆炸”的时代，在互联网上很容易找到可供参考的需求文件。即使没有同行业的资料，找到同业务领域的应该说不

一提跟业务人员做“需求分析”，许多IT人员立刻就头大了，要么不在同一个“频道”讲话，要么“变来变去，定不下来”。如何跟业务部门谈需求分析呢，我们带着这个问题，与聚冠因尚的咨询顾问杨春波展开了讨论。1、 有的IT主管抱怨业务部门提出的需求，IT人员看不懂甚至根本不能称之为需求，您觉得为什么会出现这种情况？ 聚冠因尚杨春波：这是比较常见的现象，“语言不通”是造成这种情况的主要原因之一。在企业信息化程度不高的情况下，业务人员的系统使用经验较少，他们提出的需求往往用的是“业务语言”，比如说，

<br />前言："企业级项目"，这个我们到处看到的词语，每天被我们挂在嘴边，可是到底什么项目才算是"企业级"？自己一直以来开的项目到底算得上企业级吗？本篇和大家交流，探讨下！<br /> <br />　　本篇的议题如下：<br />　　1 . 项目开发的现状<br />　　2. 什么是企业级项目<br /> <br />　1 . 项目开发的现状<br />　　一直以来，我们都在不停得做项目，赶项目。相信从大家开始做项目到现在，做过了很多大大小小的项目，或多或少也有让自己很引以为豪的成功了的项目。大家回头想

1、人比技术重要； 2、理解要实现的东西； 3、要谦虚； 4、理解用户需求； 5、需求很少改变，改变的是对需求的理解； 6、保持阅读的好习惯； 7、降低软件耦合度； 8、提高软件内聚性； 9、考虑软件可移植性； 10、接受变化，**不变的是变化； 11、不要低估对软件规模的需求，要假定软件的用户在几百万以上； 12、设计软件应考虑性能、可靠性、可用性、便携性以及可扩展性，而不 仅仅考虑性能； 13

尽管我们努力使每个软件开发项目获得成功，但有些项目刚刚开始就已埋下祸根。这里是企业软件开发项目走向死亡征程的26个早期预警信号--呜呼，全来自现实世界的经验。　　　　1、项目名称在过去的几个月里发生了第三次变化。　　2、开发经理决定最好给英国用户写一个完全不同的版本，而不是一个独立的国际化版本。　　3、需求定义在开发活动开始后的几个月才开始进行。　　4、新雇来的研发总监自豪的通知董事会项目将会提前

软件需求工程过程(SREP)，本文简要地列举并说明了在整个软件需求工程的过程中的工作职责要点。　　一、 开始　　1. 项目经理根据项目特点，指定对过程表格的具体要求；　　2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类型)、TRS(需求类型)等，在过程表格中按标准引用.　　二、 计划　　1. 计划经理估算需求开发时间；　　2. 计划经理完成：SPT(进度计划)、TPT(任务计

前言：软件产业发展到今天，分工越来越细。程序员做为一个通用的称谓已经无法确切定义各种工作的特点和分类。正因为软件开发中各种职责区分不清，无论是刚刚写代码的新手还是具有多年经验的老手，一概被扣上程序员的通用名称，这也使得很多进入这个领域的软件开发人员无法制定自己未来的技术职业发展之路。实际上，软件公司也逐渐认识到了对程序员分类的重要性，开始将各种职位定义的更加准确。对于从事软件开发的程序员来说，更需

现在很多新手都问，做测试工程师怎么入手啊，需要哪些技术啊。。。那么我么现在就说说要做个软件测试工程师，需要了解的方方面面，也可以说是一个职业要求汇总吧。一、基本常识类1． 计算机基础知识 　2． 计算机网络基础知识 　3． 软件测试基本知识（软件质量，软件质量管理基础知识，软件测试概念，软件测试标准，软件测试技术及方法，软件测试项目管理） 　　4． 软件开发基本知识（软件工程知识，理解软件开发方法

软件产品的组成客户的需求 产品的说明书 进度表 软件的设计文档及测试文档设计文档：构架，数据流示意图，状态示意图、UML图、注释代码测试文档：测试计划，测试用例，缺陷报告，测试总结 其它（帮助文件，用户手册，安装手册，错误信息等等） 项目成员公司老板 项目经理、测试经理 设计师、系统工程师 程序员、开发人员、美工 测试人员、QA

软件开发模型(Software Development Model) [编辑]什么是软件开发模型 　　软件开发模型是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 　　软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。 [编辑]软件开发模型简介 　

对近几年来软件开发模式的思考，欢迎各位高手多提宝贵意见。    按照软件的应用层次，底层为通用平台（包括用户、权限、日志、工作流等），此平台在任何行业都适用，然后在此平台的基础上可针对不同的行业开发出特定性的组件，打包形成各种应用产品，然后提供相应的配置工具及二次开发工具，可供实施人员不用编程就可快速对客户的个性化需求进行开发，提高客户响应度及满意度，同时在此过程中进一步收集客户的建议，对行业组件

一、软件测试简述什么是软件测试软件测试：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成过程的文档、数据以及程序进行测试。 软件测试的目的测试是程序的执行过程，目的在于发现软件的缺陷。 什么是软件缺陷符合软件缺陷有5个规则：软件未达到产品说明书表明的功能例如计算器，输入两个数，按下（+）键，结果毫无反应，这就是第一条规则。 软件出现了产品说明书指

观看本文的讨论的开发流程的时候，有两点需要注意：　　首先，流程不是狭义的流程，也就是说不是单只写代码这个过程，包括了软件工程整个流程。 　　其次，我所讲的这个流程不见得正确，准确的说是肯定不能适用于全部软件开发项目，也就是说不是银弹，其实说起来连大部分都涵盖不了，顶多就是一部分吧。　　　　可行性分析　　这个一般都是做战略的专家来做的，他们更加有市场的前瞻性，俗话说就是看

http://www.cnblogs.com/Pegasus_cc/category/173851.html 项目初始1. 项目那点儿事(一) ---个案分析是个啥?2. 项目那点儿事(二) ---早朝的决定 需求分析过程与需求变更控制1. 项目那点儿事(三) ---胜负在此一举[需求分析]之角斗开始 2. 项目那点儿事(四) ---胜负在此一举[需求分析]之看破对

一个软件项目从开始到结束，由于资源、人员、管理、方法学等等各方面的因素，往往不可避免的会存在一些问题，如需求不明确、项目管理失败、沟通问题等等，今天无意中看到老外写的关于这方面的一篇文章，总结的比较全面，翻译过来结合自己的一些经验做了点补充和修改，存档以备时常可以告诫一下自己。1.不能很好的理解用户的需求，缺少与用户之间的沟通。2.错误的预估项目的大小和难易度。3.没有计划就匆匆开始编码。4.

说到 PPT ，其实更是一门学问；运用起来说简单也简单，说复杂也是很复杂。工作了很多年了，也先后在不少小型 IT 企业 、大型 IT 企业、跨国 IT 企业中呆过，每个公司的 ppt 的制作的细致程度、优劣， IT 发展水平甚至企业文化都可以在 ppt 中隐隐体现出来，当然不一定完全是正确的。 总体来说外企的 ppt 制作的更为精美、细致，排版布局甚至对 ppt 模板的要求都是规范化的，尤其是

于一个软件工程师来说，我们不单单只是做技术，更应该综合发展自己。 这篇文章大家可以参考一下。平时多注意积累其他方面的知识，这样在自己不做技术的时候还可以做别的。机会总是留给有准备的人!　　好好规划自己的路，不要跟着感觉走!根据个人的理想决策安排，绝大部分人并不指望成为什么院士或教授，而是希望活得滋润一些，爽一些。那么，就需要慎重安排自己的轨迹。从哪个行业入手，逐渐对该行业深入了解，不要频繁跳槽，特

项目需求分析，看了听棠的“客户需求何时休”，深有感触，何曾自己不是被这个问题整天困扰：客户需求，为什么总在变阿？做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？ 　　听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。 　　需求分析，不仅仅是拿到客户的需求，更重要的

　软件项目需求分析是一个项目的开端，也是一个项目建设的基石。在失败的开发项目中，80%是由于需求分析的不明确而造成的。因此，一个软件开发项目想要成功的关键就是要做好需求分析。这是我经过在上个月不堪回首的痛苦折腾后，才深深领悟到的真意。在这里我想把在这个项目得到的教训和经验与大家分享。　　在上个月，公司委派我负责一个小型的软件开发项目。在接手这个项目时，我看到该项目的需求比较简单，于是想当然的就