敏捷的项目管理范文
时间：2023-09-20 16:57:36
导语：如何才能写好一篇敏捷的项目管理，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
【关键词】敏捷开发 瀑布模型 产品开发项目
在日益激烈的全球竞争中，知识创新能力是影响企业核心竞争力的关键因素之一，而作为知识创新的公司通常都以产品开发作为主营业务，其中大型公司毕竟是少数，绝大多数都是中小型公司，必须有一种可以严格质量把关，并且高效率的开发管理方法，才能适应市场的变化。
针对产品开发项目管理方法的问题，众多公司及学者提出了诸多解决方法如：IBM公司的IPD产品集成开发流程[1]，国际流行的CMM管理体系[2]，新型的敏捷开发模型[3]等都被一些公司采用为基本的产品项目开发方法。
目前，IPD及CMM这种瀑布开发及管理模型要求公司资金充足，职能明确，市场定位超前，并引领并控制市场。这些方法在大型公司，或国外成熟的市场环境下运行的十分完善。但在我国不具备这种良好的市场环境，绝大多数中小公司不具备充足的资金及良好的市场定位，处于一种不断应付市场需求变化的情况下。因此，需要一种能够快速适应需求的项目管理方法。敏捷开发的出现完成了以软件开发为基础公司的项目运作方式，它们快速的跟踪需求。但是产品开发往往面临着软件与硬件的结合，产品的硬件及架构的变动带来了巨大的成本消耗。所以即要能够应付过多的变化带来的成本问题，又要快速的响应市场需求是产品开发项目管理的根本问题。
本文借鉴了瀑布的严谨质量控制的方法可敏捷开发快速适应需求变化的理论，总结了较为实用的中小型企业产品开发项目管理方法。
1 瀑布模型和敏捷开发模型
2.1 瀑布模型原理
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。瀑布模型要求每个阶段都要为下一阶段提供依据，否则将不得向下进行。这也是瀑布模型的优点，也是它的缺点。
2.2 敏捷开发
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。主要的实现方法有XP（极限编程）、Scrum模型等。
3 产品开发瀑布与敏捷结合方法
3.1 问题的提出
即然中小型公司的产品开发过程单纯的执行某种特定的模型都会带来一定的问题，那么是否可以将二者结合呢？经过研究和实际应用发现，结论就可行的。
3.2 结合方法的计划制作
计划的制作是任何项目最重要的开端，从计划制作开始就将体现结合方法的与众不同及其可操作性。
首先计划中要把概念阶段和规划阶段列入（在某些时候可以被称作需求阶段和概要设计阶段），对于产品开发面临的硬件设备迭代周期长，无法在后期快速响应需求变化，这两个阶段是一定要开展的。这两部分结束后所达成的目标只有一个，那就是确定下方案，特别就硬件方案。为后期的敏捷打好坚实的基础。（注：上图在实际运行时需求根据情况进行分解和修改）
3.3 概念阶段和规划阶段的瀑布模型
概念阶段和规划阶段与IPD几乎没有什么变化，对于中小型公司可以严格的执行各个阶段，也可以简化每一步的完善程度（注：每一步都要执行），每一步都向着硬件电路方案的确定而努力，软件固件进行配合方案设计，这两个阶段结束后，与硬件设计方案有关的需求都最终确定。例如：某些产品需要用串口通信，对于此时只需要把要用几个串口，速度要求多少即可，对于通信协议暂时可以忽略不计。
3.4 设计验证阶段
在设计验证阶段就可以主要发挥敏捷开发的优势，由于在上两个阶段中硬件方案已经确定，所以硬件还是需要一步一步的按照瀑布进行，设计，制版，焊接，调试。此时软件和固件按瀑布方式进行平台的搭建，为敏捷的迭代过程做准备。当硬件人员由相关软件及固件人员配合将硬件设备调试通过之后，交由软件及固件人员（固件包括了FPGA等硬件逻辑代码工作）联合开发，此时以每一个星期或两个星期为一次迭代，每次迭代重新讨论需求变更及本迭代期内所要完成的功能需求。从现在开始的调试，测试及需求变换完全可以以敏捷开发方式进行。此时需要产品经理或项目经理根据最终的时间来迭代调整需求及优先级直到项目结束。
4 结论
本文在介绍了在瀑布模型及敏捷开发模型的基础上，综合分析了目前中小型企业产品项目开发中中遇到的问题，就建立完善、可操作、动态灵活的项目开发管理方法提出了建议，并采用实际的操作方法及实例充分表明本文设计方法的正确可行。
参考文献
[1]朱瑞萍.IPD―一种集成的产品开发模式[J].市场研究，2003（12）.
[2]高琰，李建华等.基于CMM的软件项目管理系统的设计与实现[J].计算机工程，2002（9）.
[3]俞定国.敏捷方法在企业应用系统开发中的应用与改进[J].微计算机应用，2005（26）.
篇2
关键词 民航石油库 项目管理 消防工程
机场油库是机场建设的重要配套工程，是构建航油供应网络的重点项目，民航油库的设计及项目管理应遵循《石油库设计规范》、《民航机场供油工程规范》等国家标准进行设计及施工，其中的消防安全设计和管理要达到《石油化工企业设计防火规范》的有关规定。同其他建筑工程施工一样，油库工程也是一项多工种、多专业的系统工程，要使施工全过程顺利进行，以期达到预定的目标，就必须用科学的方法进行实施管理。施工中加强现场项目的管理尤其重要，本文以消防工程为重点谈谈对此的看法。
1项目管理的一般步骤和实施过程
油库工程油库而言，其直接控制的目标有三个：投资、进度、质量。即在保证安全的前提下，按计划的投资、进度、质量完成项目目标。这三个目标彼此之间是对立统一的关系，难以同时达到最优，其实施应以项目整体最优为目标。优化工程现场管理是指运用系统的观点、理论和方法，对工程现场的计划、组织、控制、协调等进行全面管理的过程。优化现场管理的主要内容可分为施工作业管理、施工质量管理和现场整体管理。具体表现为： 1）把好设计审查关，及早解决设计中错漏问题和施工中可能遇到的困难，尽可能避免或减少工程变更。如储罐之间安全间距、消防通道的设计都要仔细审查合格，方可施工。2）严格把好材料、设备质量关。杜绝劣质材料或不合格材料在施工中使用，确保工程的内在质量。3）严格监督检查施工工序质量。严格监控施工过程，不符合要求的及时督促施工方整改。控制好工序质量，确保工程质量。特别是管道施工质量问题因比较隐蔽需要严格加以控制，对管道施工人员除持证外应有一定的经验和熟练程度，以免为日后留下安全隐患。4）组织好工程例会。定期召开工程例会，交流施工情况，检查工程质量、进度、投资控制情况，处理存在问题，安排下期工作。5）把好工程费用关。作好工程计量，防止高估算和重复计量。与审计机构密切合作，做好工程预算和实施阶段的内部审计，严格审核预结算，争取最大程度的核减工程费用，为工程节约资金。
其中作为重中之中的工作有二：一是施工过程中的安全管理，如施工单位的资质审查，施工合同中的安全条款和签定。对施工过程中的用火、高空作业的安全管理等不能有丝毫放松。二是对系统调试、验收阶段发现的问题应加以重视，切不可因为工程将要完工要加以忽略。下面以消防工程的项目管理加以说明。
2消防工程的项目管理
2.1消防工程的项目管理内容
2.1。1 范围管理
消防工程是建设项目中的一个分部工程，与其他分部工程如主体结构、给水排水、采暖、建筑电气、电梯等又有有机联系。主要包括：火灾自动报警系统（装置）、自动喷水灭火系统、防排烟系统、消火栓系统、、气体灭火系统（装置）、消防联动系统、消防电梯、应急照明和疏散系统等。
2.1。2 时间管理
消防工程大部分是在主体工程土建完工后进场，需要在与其他工种的协调配合下，通过高效率的计划、组织、指导和控制的手段，在时间上达到预定目标。
2.1。3 费用管理
在满足设计要求的前提下，通过项目管理，运用经济的方法在费用控制上达到预定目标。
2.1。4 质量管理
消防工程是构成建设工程的基本单元，因其专业要求严和技术含量大而直接关系到整个建筑物体的消防安全，关系到防火灭火的成败。因此质量管理非同寻常、至关重要，必须给予极大的关注。
2.2、消防工程项目的生命周期和建设程序
按照建筑阶段一般划分方法，消防工程项目与所有建设工程项目一样，有5个阶段，即决策阶段、设计阶段、招投标阶段、施工阶段、竣工验收阶段。
按照我国建设程序，消防工程的生命周期包括项目建议书、可行性研究、设计工作、建设准备、建设实施、竣工验收交付使用6个阶段。在以上阶段中应注意以下要求：
1）消防工程的设计与总体工程一起设计，设计单位应具有相应的资质；
2）在初设和施工图设计等过程中均须按照国家工程建设消防技术标准强制性要求进行设计工作，施工图设计要在取得《建设工程消防设计审核意见书》同意或建设工程消防设计备案合格后才能施工；
3）消防工程的施工单位须取得省级建设主管部门发给的消防工程施工资质证书；
4）消防工程施工单位的主要技术人员除要有相应职称外，所有施工人员须持证上岗；
5）施工中如需变动消防设计，须取得原先审核的消防机构书面同意或重新备案；
6）在工程竣工后，消防工程要有具有资质的检测单位进行检测，出具合格报告后，交消防机构备案；
7）消防工程要在该建设工程取得《建设工程消防验收意见书》合格或建设工程消防验收备案合格后才能投入使用；
8）消防工程在交付使用后，对管理人员和操作人员要进行培训，通过有效管理才能正常运行。
2.3、浅谈消防工程项目的质量控制
2.3.1设计阶段的质量控制
设计单位应具有相应设计资质，设计人员要求具有较高的理论水平，充分理解和掌握国家有关消防技术规范，特别是要严格执行国家工程建设消防技术标准强制性要求。设计单位和设计人员不能为了迎合业主要求，擅自降低设计标准，从而降低消防施工质量。
2.3.2 施工准备阶段的质量控制
在这个阶段施工单位应做好图纸自审工作， 找出图纸设计中存在的影响今后施工、验收和使用的隐患。在建设单位组织的图纸会审中， 将自审中发现的问题提出， 经各方商讨后形成书面纪要， 作为施工与验收的依据。
2。3.3 施工过程质量控制
主要从人、机、料、法、环五个要素进行控制， 通过完善的质量管理体系对消防工程产品质量进行测量、分析、改进。
1）参与消防工程施工的人员。工程项目参与各方员工素质是工程质量的基本保证。消防工程专业施工企业的施工人员必须掌握国家有关施工验收规范和质量标准， 主要技术负责人不仅要具备相应技术职称，还应对消防设计、消防设备及整个工程防灾系统掌握了解，具备整合协调能力。应选择具有消防工程施工经验的施工人员， 对其进行岗前培训， 主要包括消防工程施工技术培训以及安全生产知识培训。并且在各分项工程开始前应对施工班组进行技术交底， 使其领会设计意图、设计变更的要求， 执行和满足施工规范、规程、工艺标准、质量评定标准和建设单位的合理要求。
2）施工机械和检测仪器。包括施工机械、测量仪器、检测仪器等。常用施工机械应定期进行维护保养， 使其保持完好状态。配备经检验合格的仪器， 对所敷设线缆的绝缘电阻、火灾探测器的性能等进行测试。
3）工程材料、设备。消防工程使用的所有材料与设备必须符合设计要求并应从具备良好的信用和质量管理体系的厂家中选取， 并应具备材料证明书或合格证， 消防专用产品应为公安部消防产品信息网上网产品， 并严格按物资进场验收程序进行验收， 严防不合格物资进入施工现场。
4）施工质量管理制度和施工组织设计。（1） 施工质量管理制度。建立完善的施工质量检验制度， 隐蔽工程检查验收制度， 施工技术复核制度， 质量责任制， 并在实施中得到有效落实， 实物质量符合设计、合同和强制标准要求。工程施工中发生了质量问题（事故）要按程序及时进行处理，不留隐患，且质量责任明确，项目质量技术管理人员均应持证上岗。现场质量管理应处于受控状态。（2） 施工组织设计。应根据工程特点编制有针对性、可操作性强的施工组织设计， 工程的重要部位及专项应有施工方案， 施工方案中应明确有关的施工工艺与技术要求、工程成品、半成品的防护措施， 工程项目按照施工组织设计方案的要求组织实施。（3） 文件和资料管理。应做好消防工程项目有关文件和过程施工记录的管理工作， 确保施工中所使用的图纸与规范的有效性，并收集保管好消防工程从建审开始形成的有关文件和记录， 如建设工程消防设计审核意见书或消防设计备案资料、图纸自（会）审记录、施工组织设计（方案）、主要材料或设备质量合格证明文件、隐蔽工程检查记录、水压试验记录、绝缘电阻测试记录、施工技术复核记录，技术质量问题（事故） 论证处理记录， 建筑材料、构配件、设备进场检查验收记录， 报告， 分部、分项工程质量验收资料等。
5）施工内外环境。在施工组织设计中编制可操作性强的确保安全生产和文明施工的技术保证措施并严加落实， 与土建总承包单位、其他专业承包单位共同缔造一个整洁有序、安全有序的施工现场。
2。3.4 验收阶段的质量控制
为确保消防工程一次性通过消防部门的验收， 消防工程报验前， 应做好验收前的各项准备工作，主要如下：
（1） 落实土建专业与消防相关的作业是否已竣工，如防烟楼梯间或封闭楼梯间、管道井分隔、防火卷帘门等的施工是否已经完毕；
（2） 做好消防系统各子系统的调试与整体联动调试工作， 检查水泵接合器、室外消火栓的有关阀门是否安装正确， 均已开启。
（3） 各消防设备的电源是否已到位。
（4） 各消防联动设备的联动关系是否已按设计及规范要求设置， 并经自检正常。
（5） 有关的标志是否已完备， 如水泵接合器、水泵属何系统的标志。
（6） 工程竣工图、竣工资料是否已完备。
3调试阶段的项目质量管理
3.1油罐的试漏试压
在油罐试漏试压时应注意以下几点：1）严格按照有关施工验收规范进行各种试验。2）充水试验时，注意正确选择水质、水温和进水速度。3）在固定顶油罐强度及严密性试验中，罐内水位在最高设计淤下1。0米时，应进行缓慢充水升压。4）固定项油罐的稳定性试验时，应充水到设计最高液位用放水方法进行。试验时应缓慢降压，防止引发油罐吸瘪事故，达到试验负压时停止，观察有无变形。
3.2输油管路试压试漏和吹扫
输油管在试压试漏和吹扫时，极易引发事故，爆裂等。因此，应划定，清理闲杂无关人员。试验中若发现泄漏，不得带压处理。试验宜采用空气为介质，应在试验合格后进行，其试验压力为设计压力。
篇3
传统的开发是瀑布型，从设计到构建、测试、，就像瀑布从上到下的过程，而这过程通常需要半年或一年，甚至更长时间，构建的东西等到对于市场也已经没有意义了。因此，敏捷营运而生。
敏捷一词对于我们来讲已经不再陌生，在业界已经成为一种软件开发活动的推荐模式。但是，到底具备什么特质的软件开发活动可以称之为“敏捷”？
Rally Software亚洲区副总裁陈彩伦将敏捷精炼为“企业能感应市场变更，并能自信迅速做出反应的能力。”他认为目前各行各业都发展迅速，伴随着互联网带来的冲击，云计算、大数据的需求增多，企业就需要更快的迭代开发、测试，需要更快的响应、修复。企业随时面临被淘汰出局，只有真正敏捷的企业才能对市场的各种变化做出迅速反应。
敏捷开发可以使软件项目的构建被切分成多个子项目，同时进行并经过测试，具备集成和可运行的特征。这样的做法大大缩短了开发周期，促进了团队间沟通，可以使团队的开发效率大大提升。
敏捷的核心在于“快”，通过硬件和软件开发融合发力，实现软件开发过程“快”，以快来取得“准”，以“准”来破“变”，实现软件产品价值成功交付。
Rally是一家提供企业级敏捷开发管理平台和敏捷转型咨询服务的公司，去年正式进入中国。在中国目前拥有销售、售前和实施顾问、咨询顾问和技术顾问。Rally的解决方案不仅包括培训指导和咨询，提供敏捷转型方案，同时也提供Rally ALM 平台，帮助客户进行敏捷管理。Rally提供一个端到端的，从客户诉求、项目管理、需求管理，到质量管理，贯穿整个过程的管理平台。
“虽然是一个端到端的平台，可是我们不排除跟第三方工具的结合。我们提供的是一个开放的平台，有120多个接口，可以融合多家公司的平台和工具，我们的目的不是取代，而是融合与共存。” Rally亚洲区技术客户经理钟顺发表示，“目前Rally在中国的用户包括思科、BMC、EMC、福特、爱立信、华为等。”
篇4
关键词 敏捷开发；敏捷项目交付模型；敏捷测试
中图分类号TP31 文献标识码A 文章编号 1674-6708（2013）83-0197-02
从上世纪50年代软件出现开始至今，软件开发方法先后经历了无规则的编码和测试、结构化方法、面向对象的方法、能力成熟度模型CMM和轻量级开发方法等各个阶段。纵观软件开发的发展史，软件开发方法的演变是有规律可循的，遵循着一条从“计划和预测”到“反馈和适应”的历程。造成这一演变过程的原因如下：
1）软件使用者的主体从大型尖端领域逐渐向广泛的企业应用领域转变；
2）人们对软件系统需求的认识提高；
3）市场经济的发展，以及市场需求的频繁变化；
4）面向对象技术的应用和普及。
而今，企业面对的是快速变化的市场，在这样的市场环境下，收集用户完整的、稳定不变的系统需求是不可能的。面对无法预知和不断变化的需求，传统的软件开发流程明显已无法适应，而敏捷过程将程序代码和系统需求紧密的联系在一起，将系统需求视作流动和变化的需求的思想，则正符合现今软件开发的现状。
1 敏捷开发的兴起
敏捷方法诞生于2001年，由J.Highsmith和R.C.Martin发起，由一批业界专家参与成立了敏捷联盟，并概括出了一系列让软件开发团队具有快速工作、相应变化能力的价值观和原则。
在敏捷联盟的官方网站上，可看到敏捷宣言的完整内容：
1）个人与沟通胜过过程与工具；
2）可工作的软件胜过面面俱到的文档；
3）客户协作胜过合同谈判；
4）相应变化胜过遵循计划。
具体来说，传统的顺序开发模型（瀑布模型、V模型、W模型）的一个重要的特点就是所有的活动都是有顺序的。顺序开发模型成功使用的一个前提是软件系统具备完善和明确的需求。如果在项目开始阶段无法进行完善的需求分析和设计，则顺序开发模型就很难被成功的使用。为了解决顺序模型的不足，出现了增量迭代模型。从本质上说，敏捷开发就是一种迭代的增量的开发模型。这种模型的优点如下：能很好的适应需求的变化；早期的迭代可以降低风险；集成是持续的而不是在项目后期进行的“大动作”；在每次迭代中发现和更正缺陷并能不断反馈并改进开发过程[1]。
如果要用一句话来描述敏捷开发，那么敏捷开发应该是：以人为本、轻载、基于时间、just Enough、并行并基于构件的迭代和增量的软件开发过程。
2 敏捷开发的原则
敏捷联盟成立后，又陆续形成了敏捷的十二项原则（本文不在详细展开，详细描述见敏捷联盟官方网站），其主旨思想大体如下：敏捷开发中需求是逐渐展开的，在项目初期不提倡过渡的需求分析，对需求变化的响应是动态的；敏捷项目应该分成从几周到几个月间隔的迭代周期，每一个迭代周期尽量产出潜在可交付的软件产品，用户的反馈作为下次迭代的基础；可工作的软件是衡量项目进展的主要依据；敏捷开发整个过程是持续的，带有反馈的和自我完善的轻量级的过程。
基于敏捷指导思想，形成了不少敏捷软件开发方法(例如XP、scrum等)，它们大都强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注。以XP（extreme programming）方法为例，它消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。并且它作为一种面向客户的开发模型，开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。XP开发模型与传统模型最大的不同是其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）[2]。这种开发模型的主要优点如下：
1）采用简单计划策略，不需要长期计划和复杂模型，开发周期短；
2）在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证；
3）能够适应用户经常变化的需求，提供用户满意的高质量软件。
纵观所有敏捷开发方法，其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点，而且具有类似的敏捷项目交付模型。
3 敏捷项目交付模型
敏捷项目交付模型是一种敏捷软件项目管理的生命周期模型，它是基于敏捷开发迭代和增量特点的过程模型[3]。该模型把敏捷软件项目的生命周期大体可分成项目规划、项目启动、迭代开发与三个阶段。各个阶段分别介绍如下：
1）项目规划阶段
敏捷开发中的项目规划阶段类似于传统开发过程中的项目可行性分析和早期的需求收集阶段，该阶段的主要工作如下：
（1）就要开发系统的战略目标、业务愿景和初始项目需求等与关键涉众达成共识；
（2）根据收集到的资料，设计与决策系统开发的关键技术架构问题；
（3）评估项目的工作量与成本，辅助客户决策项目的可行性；
（4）进行项目的初始计划制定。
2）项目启动阶段
该阶段是一过度阶段，处于项目规划后正式开发前，主要工作是为项目开启准备各种所需资源，包括开发场地布置、软硬件环境的准备和项目团队的组建等。另外，通常为了使此后的迭代开发阶段能够顺利进行，还有为第一次迭代进行详细的需求分析工作。
3）迭代开发与阶段
该阶段是敏捷项目交付模型的核心部分，基本上所有的开发工作都在该阶段展开与实现。在迭代开发与阶段，项目组会根据目标系统的正式版本将该阶段分解成多个重复的过程，并且每次过程基本上都是一次目标系统的增量在开发环境中实现，并从开发环境到生产环境的迁移。每次迭代开发与又可细分为迭代开发、用户验收测试（UAT）和三个小阶段。各阶段的介绍如下：
（1）迭代开发是一个有固定时间周期的、在开发和测试环境上完成系统增量的过程，增量流程大体由需求分析活动、设计实现活动、集成测试活动、客户测试活动组成。每次迭代都会产生潜在可交付的产品；
（2）多次迭代开发对应一次，多次迭代后每次前，会根据项目需要进行用户验收测试。目标是让客户代表从系统最终运营的角度测试系统行为，另外，该阶段也可作为项目团队完成目标的缓冲区；
（3）过程在敏捷开发中有里程碑的作用，其业务意义大于技术意义。使用敏捷软件交付模型，第一次会在较早的时间发生，这对于提升客户投资收益，根据市场反馈调整项目走向都有帮助。
4 敏捷开发中的测试
对于敏捷的理解，一般认为最为关键的是需要注意两个方面，即“高速迭代”和“持续不断的客户反馈”[4]。而要达到这样的要求，传统的注重流程的规范，文档的齐备，走完整的bug处理流程的测试过程，明显已不符合敏捷的初衷。
那么敏捷开发中测试有何特点？，简要来说，如下所述：
首先，就测试的阶段来说，敏捷开发中的测试贯穿于整个软件开发生命周期中（传统软件开发模型中，测试只是作为编码后的一个独立阶段出现）。其次，敏捷开发是迭代和增量的过程，这就意味着测试人员在每个代码增量完成时，都要测试它，测试工作也是迭代的展开，并且时间更紧，压力更大。开发和测试是并行进行的，程序员从来不超前于测试人员（在传统软件开发模型中，编码和测试过程是串行的，先编码后测试）。再次，敏捷开发中，测试人员需要紧密的与客户合作来定义每一个需求的接收标准；而且测试过程还可以向项目组随时反馈开发中遇到的问题。而不像传统测试中，测试由详细的需求驱动，并且发生在编码之后。最后，敏捷测试中，提倡持续集成和构建，集成的频率较高，并且可为开发提供持续的反馈。
5 结论
其实，不管正在使用的是哪种开发模式，都会经历几乎同样的软件开发生命周期元素。敏捷的不同之处在于时间段明显变短，而且活动同步进行。因此，参与者、测试和工具都需要适应这一变化。同时，也应该看到没有哪种开发模式可以放之四海而皆准，只有不断的被实践和验证才能持续完善[5]。目前，敏捷还在不断发展，更多的项目在实践敏捷，应用的普及和成功的案例正在不断扩大。
参考文献
[1]郑文强，马均飞.软件测试管理[M].电子工业出版社，2010.
[2]张友生，李雄.常用软件开发模型比较分析.中国系统分析员，2005(1).
[3]桑大勇，王英，吴丽华.敏捷软件开发方法与实践[M].西安：西安电子科技大学出版社，2010，5.
篇5
1.1敏捷方法介绍
敏捷方法诞生于2001年初，当时，由于看到开发团队陷入越来越沉重的软件过程当中。业界专家们总结出了一套使团队具有快速工作、响应变化能力的价值观和原则。基于这一套价值观和原则的软件开发方法，被称为敏捷软件开发方法（AgileSoftwareDevelop-ment），而这类方法也发展出相应的敏捷项目管理体系（AgileProjectManagement）。敏捷开发方法及项目管理体系统称为敏捷方法（Agile）。
1.2敏捷方法的优点
敏捷方法是一种以人为核心、迭代、循序渐进的开发及项目管理方法。该方法使用了迭代、增量等方法来优化可预见性并控制风险。它灵活、高效、可持续，可以帮助软件开发团队有效地应对复杂的适应性问题。
该方法受到拥护和流行是因为采用了该方法后，团队得到的收益：据统计，敏捷方法可以让团队的效率提升3～10倍；软件的质量也更有保障；团队成员有良好的发展机会；技术能力和团队协作也得到了提高。
2敏捷项目的快速启动
2.1什么是快速启动？
敏捷软件开发项目通常会通过1～4周的快速启动（QuickStart）工作，制定出迭代开发计划，然后在开发过程中逐渐完善需求。QuickStart是一种高效的项目启动方式，主要用以在项目开始之前识别关键的驱动因素，这种方式能够让关键干系人认可并理解即将交付的产品。如图1所示。
3QuickStart的前期准备
3.1邀请相关参与人员
QuickStart过程中需要邀请参与的人员包括：核心团队、领域专家及用户代表、关键干系人（受益人、高层领导等）。核心团队一般包括产品负责人、需求分析人员、项目负责人及核心团队成员。这些人需要全程参与整个QuickStart，他们是成果的主要贡献者。领域专家及用户代表主要在用户建模、场景建模等环节为团队提供专业的意见和建议。他们可以在某些阶段时参与到QuickStart中来。关键干系人主要参与QuickStart的启动和展示汇报的环节，并对产出成果进行确认，特别是需要对产品目标和计划进行确认和授权。
3.2拟定QuickStart的计划
在QuickStart正式开始之前，项目负责人和产品负责人需要拟定QuickStart的整体计划。以一个2周的QuickStart为例，整个QuickStart计划可以这样安排：
QuickStart启动及业务目标识别（0.5～1天）
参与人员包括：核心团队、领域专家及用户代表、项目领导
产出物：产品目标
识别主要角色及场景（3～5天）
参与人员包括：核心团队、领域专家及用户代表、项目领导
产出物：主要用户角色列表、核心场景及流程、页面设计及原型
需求列表梳理（1～2天）
参与人员包括：核心团队、领域专家及用户代表
产出物：用户故事清单
规模及成本估算（0.5～1天）
参与人员包括：核心团队
产出物：估算结果
迭代/计划制定（0.5～1天）
参与人员包括：核心团队
产出物：迭代/计划
QuickStart的成果汇报（0.5天）
参与人员包括：全体团队成员
产出物：成果汇报材料
4引入的各种流程建模及分析技术
4.1识别业务目标及愿景
业务目标的识别和确定需要符合SMART原则；需要了解问题的背景及上下文信息；需要定义验证问题成功的标准；需要界定问题的范围，例如规模指的是数量还是金额，或者单品规模；需要明确并逐步完善关键干系人信息；需要明确关键资源，例如领域专家或者关键信息等等；还需要明确该问题的各种约束条件。
4.2识别角色及主要场景
用户识别从头脑风暴的形式开始，尽可能识别出更多的用户，然后挑选出主要的用户和角色，并且为用户进行用户画像，并建立用户模型。通过理解用户的目标需求和痛点，梳理出更多的细分用户场景，之后对用户场景进行优先级排序、分析，以发现其中的问题或隐含的机会。
对问题和机会进行结构化的分析可以通过这几个方面来进行：
（1）进行问题/机会的原始描述；
（2）通过事例来说明问题/机会的现象；
（3）对问题/机会进行定量的分析；
（4）对问题/机会进行定义并明确对于问题解决的期望；
（5）将问题和机会的相关分析及描述标识在用户场景描述的周围。
业务流程梳理的过程中可以将之前识别出来的用户场景在进行串联。较高层级的业务流程将各个场景串联起来之后，就可以在场景中进行场景流程的细化和展开，分析出流程步骤和各个步骤的细节。业务流程场景中的步骤细节需要包含这些信息：场景名称、场景入口的背景说明，本场景中需要跟进解决的问题，场景中事件步骤，某个步骤的细节说明，还需要有场景的出口目标。
4.3產出Productbacklog
根据上一环节中梳理出来的用户模型、场景模型、业务流程以及场景细节，开始进行用户故事的梳理，并建立用户故事列表。用户故事是为了方便与用户沟通而记录的信息，它不是需求文档，它需要以用户能理解的方式来进行描述。它的目的是要将用户的关注点从“写”转移到“交流”上，让开发团队做用户真正需要的东西，而不是用户写的东西。
一个用户故事的描述样例是：“作为一个<角色>，我想要<活动>，以便于<商业价值>”。一个用户故事是否成功可以从以下几点（INVEST）来判断：是不是独立的（Independent），是不是可协商的（Negotiable），是不是有价值的（Valuable），是不是可以估算的（Estimable），是不是大小合适、粒度相似的（Sizedappropriately），是不是测试能够测试、业务能够验收的（Testable）。
4.4梳理依赖、估算及优先级排序
核心开发人员对已经梳理出来的用户故事进行初步的技术解决方案分析，确定用户故事的技术实现可行性和一些可能的实现方案。然后从逻辑层面和技术实现层面，对用户故事列表中的故事进行一次检视，对于一些无法避免的用户故事之间的相互依赖，需要在故事卡片上标识出来。对已经梳理出来的用户故事进行估算，估算内容包括故事规模估算、工作量估算等。
估算完成后可以根据用户故事的价值、重要程度、依赖等信息进行用户故事优先级排序。排序的原则是优先考虑那些最有价值的故事、最关键的故事、被其他关键故事依赖最多的故事。
4.5制定交付计划
经过以上各个环节，团队已经得到了了一份标识了优先级、依赖关系、工作量估算等信息的用户故事列表，此时可以开始来制定交付/计划了。根据已经排序的优先级选择并整理每个迭代/版本需要完成的用户故事，使用每个故事上之前已经完成的规模或工作量估算，加上功能联调和集成可能增加投入量的buffer值，整理并安排出整个交付计划。
对于最近的一个交付周期的安排是团队应该投入最多时间进去分析和做进一步估算的。确保第一个交付周期的所有用户故事清晰且被团队理解，并且该周期中的所有用户故事都已经有较明确的技术实现方案，可以在QuickStart结束之后马上进入开发实现。如图2所示。
4.6汇报QuickStart的成果
QuickStart的最后一个环节是召开QuickStart成果汇报的会议，该会议的邀请人员包括项目团队全体成员、项目领导、相关干系人。会议上向项目相关人员汇报QuickStart的成果产出，包括确定项目产品目标及愿景、需求列表及交付计划。在展示项目团队QuickStart成果的同时也获取相关领导及干系人对成果的认可和支持，统一项目团队人员的认识，为汇报结束后立刻投入到需求的開发实现奠定基石。
5结束语
篇6
【关键词】代建模式；工程建设监理；管理水平
近年来随着我国国民经济的高速增长，基础设施和城市公用事业建设的发展迅速，但在政府投资的绝大多数项目中，我国一般仍旧采用的是建设单位自建自管的传统管理模式，这种模式普遍存在这样的问题:职责不清、政府管理与投资主体、建设单位和使用单位没有协调一致。国家希望通过建立代建制系统，解决投资项目的马拉松式工期问题。但是如何在代建制下更好地发挥监理作用的探讨也是十分必要的。
一、代建制实施过程中存在的问题
由于代建行业门槛低，代建单位的项目管理水平及从业人员素质有待提高，代建范围尚需进一步拓宽。首先，从代建公司内部看，一是大部分代建公司人员配备不足；二是即使是配足了人员，其组织结构也不尽合理，人员的素质和能力不能满足要求，项目管理人员的专业水平都很高，现场实践经验较多，但是从业人员明显知识和能力不足，缺少复合型人才。其次政府指定专业代建公司模式下的代建制企业中，综合型的能承担各种行业的综合代建工程管理的公司比较少，服务范围比较狭窄，在一定程度上制约了代建制在我国的发展。
业主的观念没有完全转变，“建设”和“运营”没有真正分离。实行代建制的目标之一就是要解决“建设、监管、使用”多位一体的矛盾，但在代建制的实施过程当中，有些使用单位为了部门的利益，对于代建工作存在一定的抵触情绪，不是自觉自愿接受项目代建，而是在代建过程中或是不积极主动配合，不履行应承担的责任；或是不愿放弃自己的权力，利用甲方身份超越权限干涉代建单位的正常工作。这样做不仅影响了代建单位对项目的管理，也影响了代建单位的积极性和主动性，进而影响到项目的顺利实施。
因此，代建制下的监理的作用不应弱化，反而应该在适应新情况的前提下，与时俱进，适当加强。
二、代建制下各方应明确的职责
首先必须让使用单位真正了解代建制在项目管理中的巨大作用，改变他们落后的思想观念，以此来推动代建制的健康发展。同时，还应明确对代建工作实施监管的具体主管部门，对代建项目的招投标、合同签订及执行进行必要的监理；对于代建单位应该不断提高代建单位项目管理水平，进一步拓宽服务范围。扩大代建企业规模，增加人员配备，并保持其组织机构的合理性；监理单位应该切实发挥好监察，管理作用，建立从业人员培训机构，制定相应的人员聘用、考核激励、培训计划，加大监理人员素质培养的力度，在增强企业核心竞争力的同时，拓宽为代建工程服务的范围，赢得更多市场。但是监理并不能在现场进度，资料和验收以及造价控制完全按照使用单位的意愿进行，所产生的矛盾亟待解决，监理单位要充分发挥监理作用以保证代建制度能够健康，稳定的发展。施工单位应该准确的按照使用单位的要求切实保质保量的完成任务，以促进企业能够健康发展。参建各方切实保证自己的职责，才能保证代建项目的顺利实施。
三、代建制下发挥监理作用的对策
代建制下的工程监理新的体制的实质,就是树立监理工程师在工程施工管理过程中的核心地位,作为建设单位,代建单位以外独立的第三方,监理工程师运用建设单位及代建单位委托的权力,对工程质量、工程进度、工程费用实行全面监理。
1.完善代建制下监理单位的组织方式，建立公正、科学的监理单位选择机制。首先，要打破行业垄断，扫除一切人为设置的监理进入壁垒。其次，要尽快建立和完善全面市场化的代建制下监理单位选择机制，具备条件的项目应采用公开招标机制来选择监理单位，让真正合格的监理单位主体来监理政府投资项目。
2.监理单位要积极加强和使用单位、代建、施工单位四方的沟通，发挥“油”的作用，监理单位及时准确的把施工情况反映给代建单位，代建单位按照使用单位的要求把信息转述给施工单位和监理单位，并督促监理加强对施工的管理，避免各参建方之间扯皮、纠纷、责任推卸等情况。
3. 加快培育专业化监理队伍。代建制下监理企业要求从业人员有较高的综合素质,不仅要具备较高的专业技术水平,而且还要通晓法律、经济、财务、施工、预算、管理等相关知识,有较强的语言表达能力、敏捷的思维反应能力和综合协调能力等。监理是代建管理体制改革的重要内容,充分发挥监理的作用是强化质量管理,控制工程造价、提高投资效益及施工管理水平的有效方法。实践证明,一项代建工程实行了有效的监理,不但减少了不合理的支出,保证了工程质量和工期,还避免了许多合同纠纷,并能确保国家建设计划和工程合同顺利实施。
四、结语
代建制在我国还处于起步阶段，在推行过程中难免会存在许多问题和困难。代建单位的角色是代行业主职能，是国家推行的方式，只是政府工程建设方式的可选项，而监理是国家制度，是强制性的。项目是否需要监理，与是否实行代建没有关系，而与该项目的性质有关，若是符合“建设工程监理范围和规模标准规定”的项目，必须监理。但只要转变观念，提高认识，进一步完善制度，健全市场，积极努力寻求解决问题的方法，充分发挥监理的作用，就一定能使代建制朝着健康的方向发展。
参考资料
[1]宫孟飞;冯婧;王永军;;国际工程项目管理模式的比较及发展趋势预测[J];建筑设计管理;2008年05期
[2]马世骁;牟瑞;高春山;;工程项目管理中的并行工程理念分析与应用[J];沈阳建筑大学学报(社会科学版);2007年03期
[3]汤峰;石远路;;浅议国际工程项目管理模式[J];企业技术开发;2007年07期
[4]谭恒;;工程项目管理新型模式探索研究[J];科协论坛(下半月);2009年07期
篇7
和信息服务业
杰出贡献企业奖
十多年的信息技术服务历程中，明基逐鹿服务了大量的各行业的领导企业，在机械制造、汽车制造、快速消费品、零售连锁、酒店服务、金融服务、高新技术、房地产、公用事业、传媒及网络等数十个行业及领域能够提供针对性的解决方案和知识分享体系。
明基逐鹿成立于1998年，前身为明基全球信息技术服务与研发中心，在全球100个以上国家和地区有营运据点，提供IT服务的软件系统开发和支持团队。明基逐鹿拥有近20年软件系统研发营运经验，将明基集团20年以上全球营运管理经验与数百家知名企业客户累积的导入经验，透过HCM、BPM、SRM、MES规划导入及IT Service、ITO业务分享给追求卓越的企业客户，提供横跨两岸领先的企业信息化管理整体解决方案。
以BenQ国际品牌营运经验为基础，提供企业信息化整体解决方案：明基逐鹿是明基友达集团旗下公司。明基友达集团由十余家独立公司组成，横跨信息科技、消费电子与医疗电子等领域。各集团公司分别深入产业布局，不仅是各行业内的创新领导者，同时也形成了高度整合的价值链。
跨越的业务布局：明基逐鹿的业务区域覆盖中国华东、华南、华北及台湾地区，公司总部位于苏州。布局于北京、上海、广州、南京、杭州、深圳、台北等各大城市的分支机构， 持续为企业提供包括IT管理咨询服务、管理软件在内的一站式服务，力争以最快的速度为客户提供及时优秀的全方位管理及信息化服务。
专业的顾问团队，拥有国际化管理理念与实战经验：明基逐鹿是由明基集团企业e化服务团队和具有多年HCM、BPM、SCM、MES等经验的专家所组成，在十几年的信息系统建设过程中，成功地完成了明基集团全球营运的信息系统规划、建置及维护，累积了众多跨国、跨领域的信息化项目实施成功经验。公司成立至今，技术、服务队伍不断发展壮大，现已有四百多位各领域的专业咨询顾问及软件研发工程师。
专业源自实践，最值得信赖的信息服务专家：十多年的信息技术服务历程中，明基逐鹿服务了大量的各行业的领导企业，在机械制造、汽车制造、快速消费品、零售连锁、酒店服务、金融服务、高新技术、房地产、公用事业、传媒及网络等数十个行业及领域能够提供针对性的解决方案和知识分享体系。
篇8
产品介绍
AgilePoint BPMS产品项中包含AgilePoint Envision（流程规划与设计工具）、AgilePoint Developer（开发图像式IT服务组件的环境）、AgilePoint Server（流程部署与运行服务器）、AgilePoint Enterprise Manager（整体流程管理接口）四个组件。
图像式组件是AgilePoint企业流程整合平台中最基本的组成要素，它是由Visual Studio环境开发而成的API，经由封装技巧以图形组件的方式使用于AgilePoint Envision中。
因为将IT资产与应用通过抽象的方式萃取出来，所以企业流程规划者、商业决策人士可以在信息技术工作者的协助下，以直观的组装取代向信息技术工作者开立系统或流程需求，组成具有可视性的流程模型，再根据业务环境的变化弹性调整，顺应外在变化。
全球IT权威研究机构高德纳（Gartner）2007年评选Ascentn AgilePoint为BPM领域最酷伙伴，其最新一期的研究报告中更指出，AgilePoint BPMS是.NET平台上惟一具备EPMs架构的流程管理平台，最主要的原因是AgilePoint企业流程整合平台不论是在流程设计、开发、部署、运行上都采用单一的模型，Model-Driven（以模型来驱动流程）的概念贯穿流程平台中所有的组件，且可弹性调整，快速响应动态的商业需求。
通过在AgilePoint Envision中组装流程的过程，商务决策人士与IT工作者将可协同合作，规划出适合业务需求的商业流程模型，并且不需要经过转译程序代码的作业即可将流程实际部署至AgilePoint Server。正因为这种不同以往的操作方法，后续运作流程时如果产生需求变化的状况，也仅需要改动流程模型配置即可完成调整，模型驱动让流程模型有了明确的可视性与一致性。
AgilePoint流程模型带有可解析的XML标记，藉由开放式的标记语言，可将分散且各自为政的应用系统与信息来源互相连接，让异质系统以松散耦合的连结方式执行沟通，不仅可整合日常商务所需提供服务，也可大幅降低IT维护成本。
在模型驱动的基础上，流程设计、开发、部署、运行都采用单一的模型，因此开发完成后的流程模型，透过XML直译的方式，不仅可直接、运行，更能够透过AgilePoint Enterprise Manager中的可视化接口直接监督流程的运行状况，充分掌握流程进度。
AgilePoint BPMS除了整合Visio中所有的功能特性，让有相关使用经验的使用者可以立即上手外，企业过去以Visio绘制的流程图也可以汇入到AgilePoint中，透过重复使用形成BPM应用，充分为企业整合了既有的Visio资产与员工使用技能，不但节省流程开发的时间与成本，更加速使用者对工具的接受度，简化且降低导入风险。
AgilePoint BPMS平台强大的整合特性还具有支持多前端表单格式、整合SharePoint、整合Visual Studio、整合Biztalk Server等优势。此外，通过Web Service与AgilePart开发，将可藉由简单的点击与拖曳和其他IT资产产生连接性和互操作性，整合点对点流程。目前AgilePoint大中华区团队已经有整合SAP、Oracle ERP、JD Edwards、Lotus Notes、Siebel、PLM等丰富的实施经验。
产品特色
弹性组装，随需应变 与一般可预先定义的业务系统不同，流程整合平台所串接的是对企业有高度影响性的点对点作业，这些介于各系统间的流程，常会有许多无法事先定义的行为，因此不能遵循传统的代码编写作业促使流程自动化。AgilePoint流程整合平台可根据不同的业务需求，弹性、动态地组装流程。
可视性将有效促成协同合作对于企业而言，所有的商业逻辑几乎都集中在商务决策人士的经验中，但他们不见得非常了解企业的IT资产及其操作，信息工作者如能将相关应用抽象出来，以商业决策人士能够理解的方式萃取包装，则商业决策人士即可透过鼠标拖曳的方式快速组装流程模型、生成应用。
流程采用一致化模型除了图形化的流程与逻辑组装接口外，确保流程在建置、开发、部署、执行均具有可视性的一致化模型，才能确保业务需求从建置流程模型与开发部署的过程中不会因为编写代码等工程开发周期而丧失了当初弹性组装的精神，这在建立企业流程整合平台时，是非常值得考虑的重点。
满足动态 (dynamic)需求企业对流程的动态需求主要体现在两方面，分别为节点动态与流程动态两者。节点动态是指在单一组件中，藉由属性设定可在实际运作时让流程达到动态判断的能力。流程动态则是指流程实际后，仍可根据业务表现动态调整，让流程具备回退（return）/取回（rollback）、跳跃、停止、迁移至新流程、重新启动的能力，AgilePoint在节点动态与流程动态的双重实现能力十分出色。
提供管理性 过去许多的业务流程，例如新产品开发过程、动态审批等步骤，都仰赖电子邮件、会议、电话等方式，简单地进行协同合作，但管理机制始终无法确切落实，因为当中隐含了许多不确定性，如邮件遗漏或者是人为疏失等，所以管理者常有无法明确掌握流程进度的疑虑，透过AgilePoint流程管理平台，所有信息将根据逻辑及流程规划自动地传递与运行，可大幅提升信息的可视性与管理性。
建立介于人与人、人与系统、系统与系统间的整合 AgilePoint做为企业流程整合平台，将可串连起介于人和系统之间的各式沟通，整合介于员工、顾客、供货商之间的流程（people-to-people），让企业员工可以以企业入口或其它网页应用形式连结内部信息资产（people-to-system），并且让异质系统间突破语言限制，执行顺畅的数据交换（system-to-system）。
用户应用体会
Ascentn所开发的新一代模型驱动BPMS在2005年时才正式对市场发表，但领导开发团队过去20多年来厚植于J2EE BPMS领域的顾问经验及海外实绩，让进入中国市场不久的AgilePoint随即获得许多客户的肯定。
国土资源部将AgilePoint应用于全国资源项目大调查中，整合旧有系统，实现项目管理与流程监控需求，因其流程中需结合许多次级单位，实现动态分派任务与流程之需求，AgilePoint的节点动态性与流程动态性可充分吻合需求，因而采用AgilePoint BPMS做为流程整合平台，采用后历史资源共4047个项目及时入库，后续应用于调查共计7000多个项目，使用单位共计523个。
广州市政府服务中心共有210多个服务窗口，776项政府服务，透过AgilePoint有效整合多个异质系统，服务中心工作人员将可透过单一窗体直接连结查询多个数据库，以事件驱动导向（Event-Driven）有效地提升公务流程处理效率，充分实现面向服务之精神。
远东金士顿科技（Kingston）作为全球内存条制造大厂，工厂与配销横跨世界各地，因此有效整合制程、业务支持系统、人事管理系统、客户关系管理系统等，成为远东金士顿科技实现面向服务架构的第一要务，目前该公司已在中国优先导入AgilePoint流程管理平台，期能有效统合多异质系统，创造流畅的业务流程。
篇9
随着互联网的触角深入到生产生活中的各个层面，软件已经不像以前那样只是支持办公和家庭娱乐这两大主题了，而是成为现代商业的灵魂。软件安全问题主要围绕着软件漏洞和易被攻击脆弱点，它们都来自于软件的设计和实现。Internet催生了电子商务，移动互联网使得APP变得如火如荼，未来物联网也许可以将生活中的一切元素都纳入到通信网络中去。因此软件安全问题将成为计算机安全的核心，而非防火墙等网络硬件，或是诸如加密等手段。软件安全是一切计算机安全性问题的根源，如果软件行为出现异常，与之相关的可靠性、可用性等方面问题就会随之暴露。软件安全问题并不是互联网出现后才有的，只不过互联网是目前最容易攻击软件的途径罢了。
2软件安全的现状
2.1人们的认知
随着黑客攻击的新闻时常见诸媒体，人们对计算机安全问题有了一定认识。但不幸很多计算机安全人员和计算机教育培训人员都忽视了软件安全的问题。一味地推崇某种软件平台是安全的，单纯大力增加对网络安全硬件和软件的投入，这些做法是盲目甚至荒谬的。一切安全性都不是静态特性，也没有任何软件是绝对安全的。软件安全问题的关键节点是软件的设计。
2.2软件安全设计的先天不足
世界上知名的软件厂商并不是不了解软件安全设计安全性的重要性，而是商业模式让软件安全方面存在着先天不足。稍纵即逝的商业机会、敏捷的软件开发过程和短暂的软件开发周期使得安全性方面的设计在很多时候都是被舍弃的。随之而来的处理方式则是常见的penetrate-and-pach方法，即不停地补丁。这种做法从长远来看，其成本与作用远不及一开始就做好安全性的设计和审计。
3软件安全设计应引入风险管理
从项目管理的角度看，风险指损失或损害的可能性。软件项目涉及到的是：项目中可能发生的潜在问题和它们如何妨碍项目成功。风险管理则是对应软件项目生命周期内的风险的科学和艺术。软件安全性的设计与软件设计的其他一些质量性能是互相抵触的，例如冗余性、高效性。而软件开发过程中的风险管理与软件开发的诸如时间、范围、成本等因素也是相互抵触的。但是绝不能因为这些可能发生的抵触行为而放弃对安全性和风险管理的考虑，反而应该将软件安全性设计纳入到风险管理的范畴中去。事实表明，93%的失控项目都忽视了风险管理。
4软件安全设计风险管理的实施
目前国际上对软件安全方面的风险管理存在着一个共同的认知，那就是采用高质量的软件工程的方法论可以在一定程度上解决这方面的问题，欧美一些国家也在试图制定或修订相关的一些“通用准则”来指导软件安全性设计的实践。但是这只是从科学技术方面做出努力，我们可以学习借鉴。而在管理技术和艺术方面需要做出的努力则应该尝试本地化做法。完整的风险管理的过程应该包括以下几个环节：风险管理计划的编制、风险识别、风险定性分析、风险定量分析、风险应对计划编制和风险监督控制。将整个流程都走完的项目和企业都不多，一般来自于所谓的学院派。而时下大多数国内外企业的做法是将这个7个流程简化为谁来识别风险、谁来对风险负责这两个环节。原因则是上文所提到的先天不足所致。从技术上讲，风险管理的效益来自于潜在风险最小化和潜在回报的最大化。而这个技术的应用则一定需要经历风险定量分析的过程。在这个过程中，可以使用的主要技术是决策树分析、蒙特卡罗分析、PERT分析等等。这些技术都是建立在一定的数学和会计基础之上。而令人遗憾的是，很多决策者本身对这些技术的认知或理解欠缺，以至于会抵触这种方法。大多数做法是采用小团队开发小软件的做法，即采用访谈和敏感性分析来帮助风险定量分析。然而我们并不是要反对这种简化做法，只是一定不能在简化的做法之上再次简化或敷衍了事。首先要做的工作是做好需求管理，在建立一组需求输入的时候，一定要将安全性作为一个重要需求考虑进去。有一个比较好的方法是，在软件设计时采用螺旋模型，需求的输入可以在螺旋模型的各个生命周期中进行，而有关安全性的需求输入则最好是在最初的一个螺旋中进行。之后要做的工作是确定最大风险。不可避免的要使用风险定性和风险定量分析的各种技术和方法。这个工作一定要有软件设计师、项目决策者和用户的参与，采用头脑风暴和专家访谈是不错的选择。而这个工作恰恰是现实生活中中小企业乃至客户最容易忽略的。企业要考虑成本问题，而客户的参与往往难以落实，认为软件的设计和开发应该由软件公司负责，客户付款只关心最后软件是否可以使用。而一旦由于软件安全性问题造成了一定后果后将演变成各种纠缠不清的官司，这是企业和客户都不想看到的结果。
5结语
篇10
【关键词】建设单位；作用；素质；项目管理
目前在我国建设领域，专业分化越来越细，各类专业业务主体和专业执业资格有几十种。惟独对建设单位的工程管理机构和相关从业的相关人员没有作出具体的、强制的要求，似乎建设单位不需要符合要求的、高素质的管理人才、技术人才和经济人才，必要的设备和仪器也是可有可无，只要有资金、有项目就是合格的建设单位，就是合格的项目业主。其实恰恰相反，要打造一项优秀的、合格的工程，没有一支高素质的建设单位管理团队几乎是不可能的。一项建设工程，它的投资人是建设单位，收益人也是建设单位，工程要达到的使用功能、规模、标准只有建设单位才能给出准确的定义，工程项目在经济上是否合理，技术上是否可行，运行使用成本是否低廉且安全可靠，功能是否齐全，是否具有前瞻性，是否符合国家的方针政策，对于这些问题的回答直接关系到工程项目的成功与失败，这是建设单位必须回答的首要问题，要回答好这些问题，必须具备一定的策划决策能力，经济实力和严谨的科学方法。规划和设计是实施工程的龙头，规划设计的好坏直接关系到项目决策的目标能否实现，建设单位要有智慧敏锐的眼光在从众多的方案中寻找最佳的规划和设计方案，将各方案的优点提炼、归纳、综合，最后形成一个最完善的规划设计，要做到这一点必须具备规划师和建筑师的素质。常有优秀的设计师抱怨，自己的高水平设计没有被采纳，而平庸的设计却被采用，其实不是建设单位不想要高水准的方案，而是实在看不出孰高孰低，即使高水准的方案就放在眼前，也没有能力识别。没有一个高水准的规划设计方案，那么无论今后的工作做的多么好，这项工程都是低水平低效益的。
根据现行工程建设相关法律法规和建设程序，一项建设工程从立项到竣工验收交付使用，要经过一系列的阶段，过程和程序，相关政府部门对各阶段、过程程序都要进行严格的审查、监督和管理，先后要办理立项审批、环境评价、土地规划许可等数 10 项申报和批复，每道程序都要经过申报、批复和验收，每到程序又是环环相扣，哪道环节出了问题，下面的程序将很难继续下去，每道程序的完成都要付出大量的人力物力和财力，这大量的、细致的、繁琐的工作只能由建设单位自己完成，其他人是无法替代的。有人叹曰：盖房子容易，完善手续难！ 以至于有的房子已盖好，要办完所有的合法手续，不知等到那年那月！ 有的项目因此成了烂尾楼，而无法收拾。如江苏某项目，因为没有合法的环境影响评价报告而全面下马，前期巨大投入化为乌有。由此可见要使项目获得成功，建设单位必须精通相关工程建设法律法规，制订周密的计划，组织高素质的、知识结构全面的团队，按照合法的程序尽善尽美的完成每一项计划工作，才能够推进工程顺利进行。
当前建设工程市场竞争激烈，无论是设计单位、监理单位、工程咨询单位还是施工承包单位无一列外的卷入这场竞争，建设单位的工程项目成了竞争的终极目标，建设项目是建设工程市场的发动机，如果没有建设项目，那么设计、监理、施工承包等专业业务单位将难以生存。因此建设单位的各级管理人员成了竞争单位拉拢腐蚀的对象，工程上马，干部下马的事件常有发生，，这就需要施工单位的各级管理人员要具备高度的社会责任心，兢兢业业的敬业精神，清正廉洁的风范，公平公正的对待每一个竞争者，建立廉政监督制度，防止腐败发生，杜绝豆腐渣工程，因此建设单位的各级工程管理人员必须抵抗各种利诱，廉洁奉公的风范、公平公正公开的原则、科学的方法是工程顺利完成的重要保证。工程建设是伟大而又艰苦的事业，基本上所有的作业都暴露在大自然中，夏天在烈日当头下挥汗如雨，冬天在刺骨寒风中辛勤工作，工作环境异常艰苦，工程现场危险因素多多，高空坠落、物体打击、机械伤害和触电等伤亡事故时有发生，千防万防安全事故还是不能完全杜绝。工程建设规模庞大，工程建设又是一个完整的复杂的系统，具有很高的技术含量，每个部位、每道工序检查一遍，就要付出很大的精力和体力，作为建设单位的工程管理人员必须有强健的体魄、敏捷的身手、敏锐的观察力和吃苦耐劳的敬业的精神，才能胜任这种环境下的工作。
对于一项建设工程，涉及的政府行政管理监督部门有项目审批、规划、土地、环保、人防、消防、标办等众多机构，参与的合同关系的单位有工程咨询、规划设计、地质勘探、工程造价审计、材料供应商等业务单位，在这么多的管理部门和业务单位中，起协调作用和主导管理作用的是建设单位，也只有建设单位才能承担这个作用，这么多的单位和部门在工程建设项目中发挥各自的不同作用，有审批的，有监管的，有承建的，有咨询服务的，有材料供应的，可谓千头万绪，关系复杂，矛盾重重，一个问题解决不好、一个关系没有理顺都会对工程的进度、质量和造价，造成负面影响，问题的焦点最后都会集中在建设单位。要使建设工程顺利进行，保质保量按时完成，把工程造价控制在预算内，必须理顺协调各种关系，解决各方矛盾，制订周密工作计划和精确进度计划，筹措充足资金，这就要求建设单位工程管理团队具有强有力的管理能力，协调能力，沟通能力和经济实力.要求这个团队要具有全面的专业知识结构，如果这个团队缺乏设计监理造价知识，就无法和设计，监理，造价等专业单位沟通，达成理解，如果缺乏招投标和施工知识，就无法将工程发包给有实力的承建单位.不具备全面的专业知识，就无法在工程建设过程中发现问题，解决问题。协调矛盾，实践证明，一个优秀的工程项目背后一定有一支强有力的管理团队，而一个烂尾楼是如何管理的就可想而知了。
综上所述，尽管国家对建设单位的工程管理部门没有提出具体的资质等级要求，对其从业的工程管理人员、技术人员也没有提出专业技术职称等级、执业资格等方面的具体要求，但是要打造一项合格的建设项目，建设单位必须组建一支高素质工程管理团队，这个团队要精通工程建设相关法律法规和技术规范，掌握全面的专业知识，要具备一定的管理能力、协调能力、沟通能力和经济实力，才能胜任艰苦的、细致的、繁杂的工程管理工作。
但是要组建这样一个专业化的高素质的知识结构全面的建设单位工程管理机构是不现实的，长期以来，我国的建设单位工程管理结构通常是工程指挥部的形式，它随工程项目的立项而诞生，随工程项目的竣工而结束，工程管理中的经验和教训不能够得到系统的总结，管理水平难以提高，人员队伍不稳定，专业性不强，管理成本高昂.依靠建设单位的临时性指挥部的管理模式，已越来越不能适应工程建设的发展和需要，一种新型的专业化社会化的工程项目管理模式呼之欲出。这就是专业化社会化的工程项目管理公司。
参考文献：
[1]吴俊，胡昊，李波. 工程建设监理的风险管理[J]. 建筑经济，2006，（03）：68-72.
[2]吴运华. 建设单位在工程建设中的风险与防范措施[J]. 湖北社会科学，2006，（10）：115-116.
