软件开发最佳方案.docx
《软件开发最佳方案.docx》由会员分享，可在线阅读，更多相关《软件开发最佳方案.docx（18页珍藏版）》请在冰豆网上搜索。
软件开发最佳方案
关于软件开发人力计划的最佳研究方案
张观多
摘要：
信息化是我们当今这个社会的主流，而是促进信息化的工具主要是软件，所以如何寻找软件开发人力计划最佳方案就成为我们生活中必须要面对的问题。
人在信息系统项目中既是成本，又是资本。
一般来说，人力成本占信息系统项目成本构成的主要部分，这就要求我们从成本角度去衡量人力资源，尽量使人力资源的投入最小、产出最大。
在项目开发中，人越多越好吗？
当项目进度延迟时，是否应该增加人力投入？
效果如何？
会不会越帮越忙？
这些问题是人力计划要解决的。
对于这些问题，我提出了3个解决方案：
1赫夫型开发；2人员——进度权衡；3Brooks定律；
1赫夫型开发：
是通过寻找最优二叉树的方式把软件开发中的任务与人力进行分配从而确定最佳的人力安排。
2人员——进度权衡定律：
从估算软件开发工作量角度出发，得出公式：
E=L3（C3Rt4d）进行研究。
（公式后面有解析）
3Brooks定律：
这个定律是指软件开发中“时间与人员不能线性互换”在软件开发中追加人力时要考虑的问题。
关键字：
软件开发人力资源管理策略研究
1.软件开发的发展历程
2.1传统的软件生产模式
2.2软件工厂的两种生产模式
3.软件项目开发的流程
3.1项目立项
3.2项目计划
3.3需求获取与分析
3.4系统概要设计
3.5系统详细设计
3.6编码实现
3.7测试
3.8产品发布
3.9周期性活动
4．软件开发人力计划安排所存在的主要问题
4．1项目经理缺乏宣讲能力，程序员缺乏沟通能力
4．2软件质量的价值观念模糊
4．3开发流程意识缺乏
4．4时间管理能力比较低
4．5缺少必要的信心和激情
4．6相互的合作并不协调
4．7无效的内耗占据了开发过程的主体
4．8模糊不清的角色职责定义
5．软件开发存在主要问题的分析
6，软件开发人力计划最佳方案探讨
6．1团队开发的人员分配和薪水界定
6．2营造高效软件开发团队
6.2.1具有明确且有挑战性的共同目标
6.2.2团队具有很强的凝聚力
6.2.3具有融洽的交流环境
6.2.4具有共同的工作规范和框架
6.2.5采用合理的开发过程
6.3项目时间管理
6.3.1项目计划
6.3.2安排进度表
6.3.3进度控制
6.3.4项目进度计划的表示方法
7具体解决方案
7.1赫夫曼树型开发
7．2人员——进度权衡定律
7．3Brooks定律
7.4用做人力计划的Rayleigh-Norden曲线
8.总结
1软件开发的发展历程
传统的软件生产模式主要是指自1946年有了数字计算机以后到20世纪70年代中期以前这段时间软件生产所采用的主要模式,大致经历了程序设计模式、软件作坊模式和软件工程模式。
程序设计模式:
是20世纪60年代中期以前的这段时期软件生成所采用的主要模式。
在这个阶段,软件的生产就是程序设计,软件的规模很小,通常由程序设计人员即软件使用者根据特定的要求,通过当时的编程语言提供的算法来编写相应的专用软件。
软件作坊模式:
软件作坊模式主要是从20世纪60年代中期开始到70年代中期这段时间。
软件作坊一般是由少数几个或几十个人组成的软件生产团体,他们是专门应别人的要求而编写软件的。
没有什么软件生产的理论和方法,软件生产仍然是少数几个人头脑风暴的结果,除了源代码以外往往没有软件的说明书等文档。
软件工程模式:
软件工程模式是从20世纪70年代中期之后开始的这段时间。
它提供了一种新的系统化、规范化、数量化的工程原则和方法进行软件的开发和维护。
按照工程化的原则和方法来组织管理软件的开发与维护工作;是摆脱软件危机的一个主要出路。
2.2软件工厂的两种生产模式
1）基于软件开发的软件工厂
这种形式的软件工厂是以软件工程和软件的生命周期作为软件公司的管理和开发的指导思想,着重软件的开发和管理。
其最主要的体现在三个方面,其一是在公司的组织划分和项目及人员管理上深入贯彻落实软件工程思想,强调软件开发的“工程”性,把软件的设计、开发、测试、维护和管理当作一项系统工程来抓,表明软件不仅仅是编写代码的工作,而需要各个学科的综合应用和各部门团队之间的通力合作,才能得以实现。
其二是严格项目管理和改进软件过程。
承认软件开发是具有相当风险的工作,为了降低风险,使项目能够按照预定的成本、进度和质量顺利完成,而对软件开发的成本、人员、进度、质量和风险等进行科学地分析和管理,同时结合先进的管理软件和工具软件,如引进先进的国际管理标准IS09000和CMM等,对公司的工作流程进行分析、整理、改进和完善,形成适合自己公司发展的软件过程和相关文档,并指导软件项目的开发。
其三是广泛地使用软件复用技术。
在公司级别上建立软件复用类库,对各知识领域的可复用构件进行分类和提炼,并在全公司上下和各个项目之间广泛推行和落实,从而提升各个团队乃至整个公司的软件生产质量和生产力。
2）基于软件集成的软件工厂
以软件集成为核心的软件工厂,强调的是软件“集成”。
就像传统行业的产品生产线一样,软件工厂拿到软件需求,通过软件的需求分析和设计,确定要达到相关功能和性能所需要的各种软件构件,在软件工厂的集成平台上通过集成而生产出符合用户要求的软件,它是一个高度自动化的软件生产模式。
基于集成的软件工厂,它的主要工作大致可以分为两个阶段。
第一个阶段是软件的需求分析和设计。
在这一阶段,软件公司针对不同的软件需求,集中公司的信息技术专家、管理专家、行业专家和项目开发人员组成项目组,对软件的需求进行分析,设计出生产工艺方案,然后按方案对所需要的软件构件（中间件、模块等）进行选型和配置。
第二个阶段是在软件集成平台上对各种软件构件进行组装、集成和客户化,以最终生产出符合客户要求的软件产品。
由此可见,以集成为核心的软件工厂,它不强调软件的开发,或者说它不怎么关心软件的开发,而是通过使用各种软件集成工具来搭建软件集成平台,依照领域标准和支持这些标准的领域中间件和构件为原料来实现软件生产自动化的。
总之,软件的生产模式是随着软件需求、软件的复杂度及软件理论和软件技术的不断变化而发展变化的。
虽然说在同一时期,可能有几种不同的软件生产模式同时存在,但却只有一种模式是占主导地位的;就像近几十年来软件工程模式一直都是主流模式一样,但在未来甚至是未来相当长一段时间之内,软件工厂的模式将会成为我们软件生产的主要模式.
3.软件项目开发的流程
一个基本的软件开发流程，通常包括项目立项、计划、需求获取与分系、概要设计、详细设计、编码、测试、软件发布和软件维护阶段，如图所示。
3.1项目立项
此阶段工作以项目经理为主，技术经理为辅。
项目经理：
全面规划项目工作的内容，确定目标市场、技术指标和应用要求，划定项目工作范围和交付成果，明确项目实现的总体设想和实施方案；明确项目需要用到的各种资源，与技术经理共同预估项目的工作量和成本；提交《项目任务书》，报公司上级领导审批，进行立项评审。
技术经理：
负责确定项目中的新技术的可行性；协助项目经理明确项目需要用到的各种资源，协助预估项目的工作量和成本。
3.2项目计划
立项通过的项目才能进入正式的开发工作，此阶段工作同样以项目经理为主，技术经理为辅。
项目经理：
召集关键技术人员（可以是其他项目组的成员），详细估算项目的工作量和成本；明确各阶段的活动内容，以及各阶段需要完成的软件工作产品，制定《工作拆分表（WBS）》，作为项目开展工作和详细计划的基础；对项目进行一系列的风险评估，进行详细进度计划安排，落实时间进度、资源（人员、设备）、技术、资金等，完成《软件开发计划》及进度表；组织项目组成员和高层对此阶段完成的文档进行评审。
技术经理：
参与详细估算项目的工作量和成本；协助项目经理完成《软件开发计划》及《进度表》；参与评审本阶段提交的文档。
3.3需求获取与分析
从这一阶段开始，项目开发管理的重心开始转移，一直到测试任务完成以前，项目开发的工作都是以技术经理为主导，项目经理只是辅助监督技术经理按照流程的标准和要求完成任务。
需求的获取是一个不断反复、不断深化的过程，可能需要多次，并一直到软件开发活动结束为止。
为使需求调研更有效果、针对性更强，此阶段开始前，建议由项目经理和技术经理共同准备一份《需求调研问卷》，将需要调研的问题详细罗列在问卷中，并根据问卷展开调研。
问卷中的问题最初以客户的高层需求为主，随着设计与开发的深入，问题逐渐细化为系统实现的技术细节。
技术经理：
与项目经理共同准备《需求调研问卷》，审核问卷中的问题；参与需求调研；调研结束后，根据项目需求报告界定的工作范围和应用方案的设计思路，进一步深入细化应用方案，描述将要开发的系统中包含的业务流程、约定、数据源、报表格式等，整理成《软件需求规格说明书》或《软件用例说明书》；指导测试组完成《系统测试用例》；参与评审本阶段提交的需求文档。
项目经理：
参与准备《需求调研问卷》，审核问卷中的问题；参与需求调研；协助技术经理整理《软件需求规格说明书》；指导测试组完成《软件测试计划》；组织项目组成员对完成的需求文档进行评审。
3.4系统概要设计
此阶段主要是根据项目需求分析，对将要建立的满足用户需求的计算机系统进行分析。
技术经理：
在系统分析过程中，指导设计人员（共同参与）划分需求的功能模块或包（Package），对每一个模块进行分析和抽象，找出描述模块及系统责任所需的类及对象，最终产生一个符合用户需求，能够直接反映模块和系统职责的分析模型；完成提交《系统概要设计说明书》；指导测试组完成《软件集成测试用例》；参与评审本阶段提交的概要设计文档。
项目经理：
组织项目组成员或其他项目组的设计人员对完成的设计文档进行评审。
3.5系统详细设计
技术经理：
根据项目需求分析和概要设计，针对具体实现中的人机界面、数据存储、任务管理等内容，指导设计人员（共同参与）进一步分析和细化，详细定义各个模块或包（Package）中的类和对象的属性与方法，以及它们之间的联系，完成包括UI设计、对象设计和数据库表设计；提交《系统详细设计说明书》、《数据库设计说明书》；参与评审本阶段提交的设计文档及模型。
项目经理：
组织项目组成员对本阶段完成的详细设计文档及模型进行评审。
3.6编码实现
这一阶段的任务基本上由技术经理指导完成，只有在非常关键的代码模块或必要时（如外购软件等），才由项目经理组织代码的评审。
技术经理：
根据系统详细设计的结果，通过具体的程序语言、数据库或者硬件设备指导程序员（共同参与）实现设计中的数据结构和算法；核查程序员完成的代码模块；指导开发人员（共同参与）集成各模块或子系统。
项目经理：
组织项目组成员对本阶段提交的工作产品进行评审（可选）。
3.7测试
测试阶段的任务虽然主要由测试组完成，但测试工作的开展离不开技术经理的指导，而且更需要项目经理协调软件开发小组与测试组之间的关系。
目前，对于测试的管理和跟踪多数采用回归测试的方式。
技术经理：
当软件的各个子系统或整个系统完成后，指导测试组完成集成测试和系统测试任务；评审和核实测试组提交的《集成测试报告》和《系统测试报告》；根据测试结果分派任务给开发人员，指导（或共同参与）对软件产品进行修改。
项目经理：
协调软件开发组与测试组之间的关系，指派测试任务给测试组；组织项目组成员对本阶段提交的工作产品进行评审。
3.8产品发布
本阶段的任务主要是完成产品的包装，这是软件开发的收尾工作，项目组的管理重任移交到项目经理。
项目经理：
组织人员整理项目组内部的开发文档，如需求、设计、编码、测试以及各种开发管理文档资料；分派完成用户文档的任务，包括安装指南，使用手册，技术手册，培训教材等；指派撰写产品宣传资料的工作，例如产品介绍资料，演示光盘等；组织用户对完工的项目（提交的软件产品）按照验收步骤进行验收，完成《用户验收报告》。
技术经理：
协助整理项目组内部的开发文档，如需求、设计、编码、测试以及各种开发管理文档资料；开发软件产品的安装程序；参与评审本阶段提交的工作产品。
3.9周期性活动
在项目开发过程中，有一些活动是贯穿整个软件开发过程的，我们将这些活动称之为周期性活动，包括项目计划调整、项目活动的跟踪与监控、风险再评估、配置管理、质量保证等，活动的结果主要由项目经理或指定人员定期或在事件驱动下更新（评审或审阅）《软件开发计划》、《项目问题日志》、《项目报告》、《项目风险日志》、《会议纪要》、《工作任务单》、《项目度量数据收集》等文档。
在项目中同时设立项目经理和技术经理，可以有效实现项目技术和管理上的分工合作。
项目经理擅长管理，与客户交流时可以加强说服力，可以更直接地了解客户的要求，对客户提出变更请求管理更加合理，也更有助于文档的管理与评审活动的开展。
技术经理是技术权威，可以专注于技术研发工作，有助于提高软件开发的效率和产品质量。
当然，这种模式下的项目经理不仅要有丰富的软件开发和管理经验，不只是做计划、总结汇报、安排工作，同样也需要具备软件开发的技术背景。
只有这样，才可以在开发过程中发现技术问题，并有助于更深入地了解项目技术架构和细节，保持项目中有关概念的一致性。
技术经理也不能只顾埋头苦干，也要兼顾项目的管理，要激发技术人员的创造性和积极性。
项目经理与技术经理之间也要经常沟通，项目经理和技术经理在完成各自工作的同时，都要及时通知对方，避免形成项目组内部的帮派
4．软件开发人力计划安排所存在的主要问题
4．1项目经理缺乏宣讲能力，程序员缺乏沟通能力
项目经理是头头，所以，兵熊熊一个，将熊熊一窝。
项目经理有时候心里很清楚一个事情该怎么做，但是他手下的兵却不是很清楚，有些能力强的兵，就会多做一些事情，结果却导致了更大的浪费。
项目经理经常说：
我心里有数，我认为我能控制局面。
而事实往往不是这样。
项目团队5～6个人，经常会对任务、分工、质量等理解不一样，这很成问题。
最后导致项目效率很低。
程序员很多人都没有自信，也许是因为他们对自己的知识和技术没有自信，也许是他们对这个行业和职业不熟悉，所以，他们害怕在团队中表现，害怕与别人交流。
程序员经常腼腆的一天都不说一句话，这简直是对软件工厂和软件开发的一个诬蔑，试想一个足球队中的队员相互之间不配合和传球，是不是对足球这个运动的一个诬蔑。
我真有想法，拿鞭子抽打这些不说话的程序员，直到他们学会与其它人沟通，直到他们与其他人配合默契。
4．2软件质量的价值观念模糊
质量意识，应该是这样一个意识，1/3时间来做东西，2/3时间来做检查。
现在是商品社会，技术不再是一个问题，而质量确实很难满足，所以，我们要求程序员改变开发软件的思想，1/3时间编码，2/3做检验，我们管理者，要以成功率来考核程序员，而不要以完成时间来考核，我们管理者要安排足够的时间来做检验，而不要以项目必须交付为理由，逼迫程序员仅仅交付代码而忽视质量。
4．3开发流程意识缺乏
开发流程，似乎对于很多程序员来说比较陌生，尤其是没有经过专业教育和训练的人来说，转行做程序员，很难理解开发流程是个什么东西，为什么要有它。
4．4时间管理能力比较低
程序员的效率很难衡量，时间是程序员的资源，每天8小时，是有限的，要想知道程序员的效率，就要知道他们每刻都在干什么？
4．5缺少必要的信心和激情
也许你会发现周围的一些同事仅仅是为了薪水而工作，在执行工作的时候即使发现了上层领导忽略的问题依然照糊涂画瓢也不反馈问题所在，即便他是个天才，但成功不会属于他的，因为成功垂青于有激情的人才，其实这些同事并不是一开始就缺少激情的，原因也许是失去了信心，而暂时做"糊涂人"而已，无论如何，缺少信心和激情的团队，只会是一盘散沙。
4．6相互的合作并不协调
在一个开发团队中偶尔有部分人不愿意与整个团队合作，也许是这些人性格比较保守，也许是有某些不平衡的心态，也许是他们还没有明白目标是什么，也许他们并没有体验到团队开发成功的快乐。
。
。
不管怎样，这种情况的出现必然影响融洽的交流环境。
4．7无效的内耗占据了开发过程的主体
也许是一些良的传统观念和思想的沿袭，一些软件开发团队出现了排挤其它有异议的成员、推卸责任、相互指责、贪功等，这种情况是最坏的，但却事实存在。
没有凝聚力的团队是不可能做得很好的。
4．8模糊不清的角色职责定义
软件开发是由不同角色的成员共同协作完成的，但目前国内的一些开发团队却没有对各种角色成员的职责做出明确的定义，成员就无法明确知道自己的目标，很简单的道理，都不知道要做的是什么，能按时准确的完成吗？
如果每人都按自己想象中的职责去工作，那么有多少工作冲突、多少遗漏，谁能给出正确的估计？
没有明确的职责定义人力资源的安排可能合理吗？
结果可能是找了个资格较老的程序员做了项目经理，找了个没有理会对象概念的人去做面向对象的系统分析，找个不顾网络安全、网络流量、事务特性、运行费用的人去设计一个分布式系统.有才华的人也许只能跺在被窝里激呼怀才不遇或许能做个美梦安慰自己。
5．软件开发存在主要问题的分析
做为项目经理，要经常组织大家开会，让大家充分沟通，项目经理设法要让团队成员对某一个问题的认识，高度一致，记得老董培训我时，要求的是每个项目组成员，在描述某个问题时，说出来的话，应该一字不差，那是何等的严格的要求，我现在的团队在素质上比当时的团队要低一些，但是，我觉得也应该高要求，严格要求，尤其对项目经理要严格要求。
应该保持团队成员之间，对项目计划、进度、分工、质量，有高度的认识统一，必须，描述非常一致，不能有不同的理解。
项目经理还有一个职责，就是要宣讲团队的开发流程以及团队文化，项目组的成员，在具体工作中，经常会迷失在细节工作中，而不会关注开发流程，也会疏忽团队问题，项目经理应该象中国军队的指导员一样，确保团队成员，对开发流程的信心以及严格的遵守，潜意识中的遵守，对团队文化高度的认同，这就要求项目经理非常善于演讲，或者非常具有个人魅力。
国内的项目经理很多都是技术出身，以不善言辞为自豪，或者挡箭牌，其实，他们会很有损于团队的高效率以及团队的文化。
程序员很多人都没有自信，也许是因为他们对自己的知识和技术没有自信，也许是他们对这个行业和职业不熟悉，所以，他们害怕在团队中表现，害怕与别人交流。
程序员经常腼腆的一天都不说一句话，这简直是对软件工厂和软件开发的一个诬蔑，试想一个足球队中的队员相互之间不配合和传球，是不是对足球这个运动的一个诬蔑。
我真有想法，拿鞭子抽打这些不说话的程序员，直到他们学会与其它人沟通，直到他们与其他人配合默契。
程序员经验很重要，但是，工作方式的掌握更重要。
程序员首先要对工作做好分析工作，不要急着开工，要预估一下可能出现的问题，根据经验，提出问题，很多程序员，这点就很差，接到任务后很少分析，认为领导给的任务，一定没问题，即便有问题也得按照要求完成，所以，没必要提问题，提了也没用，而且会得到的是批评和置疑，还不如不问。
程序员对于工作中遇到的问题，经常是自己假想一种解决方案，经常会说：
我想、我以为、我觉得，这些话简直让项目经理觉得他是不是没有脑子，怎么可以“我以为”、“我想”、“我觉得”呢？
耽误自己的时间，换耽误大家的时间，以及企业的资产。
很多程序员做程序经常是个人英雄主义，光想着自己怎么完成，而不想团队或者项目，这点意识，要扭转过来，太难了，不过不转变，项目开发迟早都会失败。
所以只能沟通讲解，告诉为什么不能每个人分一个模块做，怎样降低人员流失的风险，怎样防止一个人做一个模块，由于个人能力的不足或缺陷，导致该模块的失败，从而导致整个项目的失败。
只能通过讲解，让每个程序员知道，开发流程是如何帮助我们整个项目保证进度和质量的，开发流程是怎样保证我们的工作没有疏漏，开发流程是怎样让我们的工作井然有序，开发流程怎样让一个复杂的软件一步步实现，开发流程怎样实现几十个人系统工作，而不出漏洞。
6，软件开发人力计划最佳方案探讨
6．1团队开发的人员分配和薪水界定
首先，每个项目小组的人数不能太多，否则组员之间彼此通信将占用大量的时间。
此外，通常我们不能把一个子系统划分成大量独立的单元模块，如果项目小组人数太多，则每个组员所负责实现的单元模块与其他成员的接口将更复杂，不仅出现接口错误的可能性增加，而且系统测试也会变得既困难又费时。
一般说来，每个项目小组的规模应该比较小，以2～9名成员为宜。
如果项目属于中小型规模且建设时间在一年以内，那么项目小组可以采用工作包负责人制。
工作包负责人既负责该工作包的日常管理工作，同时又是该工作包的技术负责人，在其他成员中再挑选一位为助理，协助工作包负责人做好各方面的工作。
如果项目属于大中型规模，建设时间在一年以上，那么就必须考虑项目建设人员因各种原因发生变动的情况。
这时，项目小组具体构成最好如图1所示。
这里的系统开发人员既可以是程序员，也可以是测试员。
采用这种按技术水平分层的构成模式主要基于两点考虑：
第一，信息系统建设中既有创造性很强的事务，也有经验性很强的事务和照葫芦画瓢的简单性事务，如果所有活动都让高级人员去完成，则导致成本上升，造成人力资源的浪费，还会引起高级人员的不满；第二，由于项目建设时间太长，容易发生人员更替，并且由于信息系统开发技术主要靠“干中学”，中级和初级开发人员在系统建设过程中会成长起来，如果一旦发生上一层次人员变动，下层人员由于一直参与项目的研发，基本上可以“无缝”地接手工作。
如果项目小组成员不发生人员更替，则项目小组的整体素质将随时间的推移而提高，从而使项目的进度加快。
一般来说，初、中、高级人员最初的薪水可以按类似3∶7∶10的比例定位。
当然，随着初中级人员技术水平的提高，他们的薪水也应该不断提高，因为他们在同样时间内可以完成更多、更复杂的工作。
6．2营造高效软件开发团队
高效软件开发团队的特征
高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作的基础之上的，成员共同的迎接挑战、有效的计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征：
6.2.1具有明确且有挑战性的共同目标
一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多，通常技术人员往往会因为完成了某个明确的任务，而且这个任务的完成具有挑战性的意义而感到自豪，反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率，如作为系统设计人员很清楚的知道在什么时候要做到什么，什么时候开始做，什么时候必须完成，为了完成工作必须面临哪些挑战，怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证，而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的，而且会为此付出高昂代价，因此高效的软件开发团队具有挑战性的共同目标。
6.2.2团队具有很强的凝聚力
在一个高效的软件开发团队中，成员们凝聚为一个整体共同进行工作，他们是相互支持、互相交流、互相尊重的，而不是相互推卸责任、保守、相互指责的，在一些散乱的开发团队中往往存在这样的问题，一些程序员是比较保守的，明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码，他也不愿拿出来给其它程序员共享，不愿与系统设计人员交流，这样给项目的进度造成了些不可度量的因素。
6.2.3具有融洽的交流环境
在一个开发团队中，每个人行使自己的职责，如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等，但每个人的工作不可能做到完美的，如系统概要设计的文档可能有个别地方词不达意，做详细设计的时候就可能会造成误解，项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于
升级会员 