软件开发管理如何风险管理？
4个回答
展开全部
去百度文库，查完整内容>来自用户的内容:gzdxue软件开带兄枝发项目如何进行风险管理。参与过大型软件项目的人都会意识到，很多事情都有可能出错，一旦出错，可能会给项目带来伤害、损失或其他不利影响。风险是项目中发生一系列事件或不利结果的可能性。软件开发是一项高风险的活动，在项目开发过程的任何阶段都可能存蠢敏在风险。主动风险管理可以使项目过程更加稳定，获得对项目的高度跟踪和控制能力，避免和转移风险或减轻风险带来的不利影响。风险管理是识别、分析、应对和监控项目风险的过程，是项目管理中一项重要的管理活动。有效实施软件风险管理是成功完成软件项目开发的保证。风险管理的实现必须包括三个要素:一是必须在项目开发计划中制定风险管理计划；第二，项目预算必须包括解决风险所需的资金；第三，在评估风险时，风险的影响也必须包括在项目计划中。下面，我们就针对软件开发过程中经常出现的风险，谈谈我们所采取的防范措施。1.要求不明确。在软件开发过程中，经常会遇到需求不明确的情况。这类问题往往表现在需求未定义、需求未定义、需求描述不清晰、需求缺失、需求矛盾等诸多方面。在软件开发过程生命周期的每个阶段，需求不明确造成的浪费是最大的，必须尽快解决。很难确定用户的需求。我们经常从以下几尘孙个方面来处理需求不明确的问题:
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
展开全部
风险管理的达成必须包括三个要素：
首先，在项目开发计划中必须制定风险管理计划；
第二，在项目预算中必须包含解决风险所需的经费；
第三，评估风险时，风险的影响也必须纳入项目计划中。
下面就软件开发过程中经常发生的风险，谈谈我们采取的预防措施。
1、需求不明确
需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：
（1） 让用户参与开发
提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。
在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。
仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。
（2） 开发用户界面原型
用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。
（3） 需求讨论会议
对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。
（4） 强化需求分析与评审
首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。
2、项目缺少可见性
当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成[1]。软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。
（1） 迭代开发
采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是一些典型的迭代：
一次简短的先期迭代，以建立规模和前景并确定商业理由；
一次精化迭代，其间将为稳定的构架划定基线；
一次构建迭代，其间将实现用例并充实构架；
几次产品化迭代，将产品转移到用户群。
每次迭代，都要充分接收用户的评审意见，以便为自我纠正。渐近式的功能交付，有利于降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是最好的进展报告。
（2） 技术评审
技术评审是确保软件质量的重要环节，技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交悄铅叉审查，或者是高级开发人员逗运带对普通开发人员的审查；会议评审一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业务两个方面的专家，经常性地让精通业务的用户专家参与项目评审，是项目成功的重山芦要保证。
另外，充分利用质量审查的工具软件，也有利于提高代码质量。例如：在Eclipse开发环境中，可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。
（3） 持续集成
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决[1]。
开发小组应制定持续集成的制度，一般情况下每日构建一次，可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后，及时向版本控制系统（如CVS）提交代码，而且不应该向版本控制系统提交有问题（编译通不过）的代码。
每日构建、持续集成，让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道距离整体完成还有多远。
3、新技术引入
技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术，不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。
（1） T形软件开发
在项目开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索。例如：基于JavaEE5构建全国联网售票系统，涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题，应该优先处理这些问题；对开发所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技术，要做深度探索。
越是技术复杂度高的项目，就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决，则为时已晚。
（2） 充分论证
新技术开发是探索性很强的工作，潜在着许多失败的风险。在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。在制定决策时，情报的数量和质量致关重要。掌握的信息越多、越准确，才能作出正确的的决策，项目失败的风险也就相对减少；反之，承担的风险就会增大。
（3） 同行经验
针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利用互联网，通过搜索同行经验，往往事半功倍。要充分利用世界日益平坦化的优势，对于不能尽快解决的问题，可以先放一放，可能过不了几天，网上就有相类似问题的解决方案了。
4、技术兼容性风险
硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。往往系统集成的项目越复杂，兼容性问题就越有可能存在。
（1） 设计先行
在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中，明确相关设备的技术参数和配置要求。
（2） 售前产品测试
在做项目招投标工作时，要求投标方在售前提供产品兼容性测试，以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目，要在开发工作的早期，做技术兼容性测试，以避免在项目开发后期才暴露技术兼容性问题。
例如，我们在开发深圳市汽车客运站售票及站务联网调度系统时，为了确保技术兼容，在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作，并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时，暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题，如果这些问题在系统实施时才暴露或处理，势必会拖延项目进度。
5、性能问题
由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计。无论是用户还是开发者，谁都不希望出现性能问题。
（1） 性能规划
在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计。在做数据库设计时，应争取DBA参与。
另外，在技术方法方面，尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等，尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题，既费钱又费时。
（2） 性能测试
在开发过程中，要重视性能测试和压力测试，尽可能模拟现实使用环境，搭建测试平台。另外，由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。
（3） 充足的调试时间
在项目开发计划中，为后期性能优化留有余地。在对系统进行性能优化后，要进行性能测试和压力测试，可能还要做几次回归测试。因此，应该留有充足的时间和人力。
6、仓促上线
在项目实施过程中，系统切换上线环节最容易出纰漏。项目好不容易开发完成了，却在最后最后时刻功溃一匮。如果项目小，影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。
（1） 应急预案
面对各种不可预知的风险，要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周，都会做好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常工作时，准备手工票就是最坏的打算。
（2） 分步切换
为了减少风险的影响，可以做系统分步切换的方案。例如：售票系统在切换时，往往用新系统售预售票，或者是用新系统售长途车站，用旧系统暂时售短程票。待新系统运行稳定后，再全面切换到新系统。针对多个用户单位的系统切换，也可分单位进行。
（3） 交叉培训
新旧系统切换过程中，用户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班，让早班的用户在交班时培训中班的用户，中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。
7、可用性问题
软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。
（1） 了解用户
到用户工作现场，了解目标用户使用软件的真实目的，从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。例如：售票系统中，使用频度最高的界面是售票界面，售票员最关心的是钱不要出错（多了没收、少了要赔），因此，应收款和找余字体的显示应该突出、醒目；同样，票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计，尽量减少售票员敲击键盘的次数。否则，在日发旅客流量达七、八万人次的大型客运站，如果用户界面设计得不好，售票员一天工作下来，手指都会敲麻木。
（2） 参与型设计
与用户协作，让用户参与用户界面的设计、评审与测试，确保用户能够全面地、及早地发现可用性等方面的问题，并及时纠正。
让客户参与设计，而不要让客户设计，项目经理或高级设计人员应该主导设计。
（3） 竞争性分析
通过对市场上同类竞争性产品进行分析，或者对这些产品进行实验性测试，了解这些产品的用户界面问题，从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计，而是通过分析竞争产品的优势和弱点，能够比以前的设计做得更好[5]。
（4） 一致性
如果用户知道同样的命令或同样的操作总会产生同样的效果，那么他们在使用系统时就会更加自信，同时也鼓励他们进行探索性学习，因为他们已经具备了使用系统新部分的基础知识[Lewis er al。1989]。
开发团队应遵循公司或小组制定的用户界面标准，就可以在很多方面保持一致性，切忌不要一个系统存在多种不同的界面风格。
郑州观致电子商务,拥有有效资源, 多起成功案例, 专业制作水平, 提供微期货平台搭建、分销系统开发、捕鱼游戏开发、第三方支付软件开发、商城网站建设、电商网站建设、网站定制开发、手机app软件开发、微信小程序开发、电商系统开发、办公系统软件开发一系列服务。精英团队为您以后保驾护航!
8、结论
在信息系统集成项目中，风险是多种多样的，是无处不在的。在项目管理活动中，要积极面对风险，要培养。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目，应加强风险管理。如果不主动驾驭风险，就会面临风险。
首先，在项目开发计划中必须制定风险管理计划；
第二，在项目预算中必须包含解决风险所需的经费；
第三，评估风险时，风险的影响也必须纳入项目计划中。
下面就软件开发过程中经常发生的风险，谈谈我们采取的预防措施。
1、需求不明确
需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：
（1） 让用户参与开发
提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。
在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。
仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。
（2） 开发用户界面原型
用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。
（3） 需求讨论会议
对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。
（4） 强化需求分析与评审
首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。
2、项目缺少可见性
当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成[1]。软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。
（1） 迭代开发
采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是一些典型的迭代：
一次简短的先期迭代，以建立规模和前景并确定商业理由；
一次精化迭代，其间将为稳定的构架划定基线；
一次构建迭代，其间将实现用例并充实构架；
几次产品化迭代，将产品转移到用户群。
每次迭代，都要充分接收用户的评审意见，以便为自我纠正。渐近式的功能交付，有利于降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是最好的进展报告。
（2） 技术评审
技术评审是确保软件质量的重要环节，技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交悄铅叉审查，或者是高级开发人员逗运带对普通开发人员的审查；会议评审一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业务两个方面的专家，经常性地让精通业务的用户专家参与项目评审，是项目成功的重山芦要保证。
另外，充分利用质量审查的工具软件，也有利于提高代码质量。例如：在Eclipse开发环境中，可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。
（3） 持续集成
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决[1]。
开发小组应制定持续集成的制度，一般情况下每日构建一次，可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后，及时向版本控制系统（如CVS）提交代码，而且不应该向版本控制系统提交有问题（编译通不过）的代码。
每日构建、持续集成，让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道距离整体完成还有多远。
3、新技术引入
技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术，不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。
（1） T形软件开发
在项目开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索。例如：基于JavaEE5构建全国联网售票系统，涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题，应该优先处理这些问题；对开发所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技术，要做深度探索。
越是技术复杂度高的项目，就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决，则为时已晚。
（2） 充分论证
新技术开发是探索性很强的工作，潜在着许多失败的风险。在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。在制定决策时，情报的数量和质量致关重要。掌握的信息越多、越准确，才能作出正确的的决策，项目失败的风险也就相对减少；反之，承担的风险就会增大。
（3） 同行经验
针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利用互联网，通过搜索同行经验，往往事半功倍。要充分利用世界日益平坦化的优势，对于不能尽快解决的问题，可以先放一放，可能过不了几天，网上就有相类似问题的解决方案了。
4、技术兼容性风险
硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。往往系统集成的项目越复杂，兼容性问题就越有可能存在。
（1） 设计先行
在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中，明确相关设备的技术参数和配置要求。
（2） 售前产品测试
在做项目招投标工作时，要求投标方在售前提供产品兼容性测试，以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目，要在开发工作的早期，做技术兼容性测试，以避免在项目开发后期才暴露技术兼容性问题。
例如，我们在开发深圳市汽车客运站售票及站务联网调度系统时，为了确保技术兼容，在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作，并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时，暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题，如果这些问题在系统实施时才暴露或处理，势必会拖延项目进度。
5、性能问题
由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计。无论是用户还是开发者，谁都不希望出现性能问题。
（1） 性能规划
在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计。在做数据库设计时，应争取DBA参与。
另外，在技术方法方面，尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等，尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题，既费钱又费时。
（2） 性能测试
在开发过程中，要重视性能测试和压力测试，尽可能模拟现实使用环境，搭建测试平台。另外，由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。
（3） 充足的调试时间
在项目开发计划中，为后期性能优化留有余地。在对系统进行性能优化后，要进行性能测试和压力测试，可能还要做几次回归测试。因此，应该留有充足的时间和人力。
6、仓促上线
在项目实施过程中，系统切换上线环节最容易出纰漏。项目好不容易开发完成了，却在最后最后时刻功溃一匮。如果项目小，影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。
（1） 应急预案
面对各种不可预知的风险，要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周，都会做好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常工作时，准备手工票就是最坏的打算。
（2） 分步切换
为了减少风险的影响，可以做系统分步切换的方案。例如：售票系统在切换时，往往用新系统售预售票，或者是用新系统售长途车站，用旧系统暂时售短程票。待新系统运行稳定后，再全面切换到新系统。针对多个用户单位的系统切换，也可分单位进行。
（3） 交叉培训
新旧系统切换过程中，用户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班，让早班的用户在交班时培训中班的用户，中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。
7、可用性问题
软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。
（1） 了解用户
到用户工作现场，了解目标用户使用软件的真实目的，从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。例如：售票系统中，使用频度最高的界面是售票界面，售票员最关心的是钱不要出错（多了没收、少了要赔），因此，应收款和找余字体的显示应该突出、醒目；同样，票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计，尽量减少售票员敲击键盘的次数。否则，在日发旅客流量达七、八万人次的大型客运站，如果用户界面设计得不好，售票员一天工作下来，手指都会敲麻木。
（2） 参与型设计
与用户协作，让用户参与用户界面的设计、评审与测试，确保用户能够全面地、及早地发现可用性等方面的问题，并及时纠正。
让客户参与设计，而不要让客户设计，项目经理或高级设计人员应该主导设计。
（3） 竞争性分析
通过对市场上同类竞争性产品进行分析，或者对这些产品进行实验性测试，了解这些产品的用户界面问题，从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计，而是通过分析竞争产品的优势和弱点，能够比以前的设计做得更好[5]。
（4） 一致性
如果用户知道同样的命令或同样的操作总会产生同样的效果，那么他们在使用系统时就会更加自信，同时也鼓励他们进行探索性学习，因为他们已经具备了使用系统新部分的基础知识[Lewis er al。1989]。
开发团队应遵循公司或小组制定的用户界面标准，就可以在很多方面保持一致性，切忌不要一个系统存在多种不同的界面风格。
郑州观致电子商务,拥有有效资源, 多起成功案例, 专业制作水平, 提供微期货平台搭建、分销系统开发、捕鱼游戏开发、第三方支付软件开发、商城网站建设、电商网站建设、网站定制开发、手机app软件开发、微信小程序开发、电商系统开发、办公系统软件开发一系列服务。精英团队为您以后保驾护航!
8、结论
在信息系统集成项目中，风险是多种多样的，是无处不在的。在项目管理活动中，要积极面对风险，要培养。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目，应加强风险管理。如果不主动驾驭风险，就会面临风险。
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
展开全部
风险管理是在项目进行过程中不断对风险进行识别、评估、制定策略和监控风险的过程,它被认为是控制大型软件项目风险的最佳实践。风险管理是在风险尚未产生或形成之前,对风险进行识别,并且评估风险出现的概率以及可能产生的影响,按风险从高到低排序，有计划地进行管理,旨在识别出判禅做风险,然后采取措施使它们对项目的影响最小。风险管理的目标在于提高项目积极事件的概率和影响,降低项目消极事件的概率和影响。风险管理意味着在风险损失还没有发生之前先对其进行处理。通常来说,在风险管理实掘衡施前需要进行风险规划,即决定采用什么方式方法、如何计划项目风险的活动,指导对于特定项目如何进行风险管理。
只有进行较好的风险管理,才能有效地控制项目的准备实施与落地,如项目的成本、进度和产品需求等,同时可以防止意外问题的出现,即使出现,也可以降低风险的程度﹐风险管理的重要性包括如下内容。
(1)对潜在风险的预袭磨测会最大限度地降低其对期望结果的影响。
(2）实现提早做好相应的计划,从而降低风险发生时造成的压力。如果没有事先制定好相应的应急方案,那么风险发生时就会手足无措。宝贵的时间会浪费在寻找替换方案上，而这又会减少最终实施替换方案的时间,从而危及产品的质量。此外,在高度压力下做出的决定通常来说都不如事先制定好的有效。
只有进行较好的风险管理,才能有效地控制项目的准备实施与落地,如项目的成本、进度和产品需求等,同时可以防止意外问题的出现,即使出现,也可以降低风险的程度﹐风险管理的重要性包括如下内容。
(1)对潜在风险的预袭磨测会最大限度地降低其对期望结果的影响。
(2）实现提早做好相应的计划,从而降低风险发生时造成的压力。如果没有事先制定好相应的应急方案,那么风险发生时就会手足无措。宝贵的时间会浪费在寻找替换方案上，而这又会减少最终实施替换方案的时间,从而危及产品的质量。此外,在高度压力下做出的决定通常来说都不如事先制定好的有效。
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
展开全部
作者：Intech-Porter 链接：https://zhuanlan.zhihu.com/p/25545669 来源：知乎 著作权归作者所有。商业转载请联腔腔系作者获得授权，非商业转载请注明出处。
创业者在创业过程中，肯定碰过几次程序员人间蒸发导致技术开发难以接手的案例。我也听说过不少类似的烂摊子。通常，创业者本身不懂技术或是对技术一知半解的状况，就更容易被程序员唬得一愣一愣的。别以为这种事只有遇到外包才会发生，我也看过技术合伙人学会隐身术后就人间蒸发的惨痛案例。
因此，我都建议每个非技术背景的朋友，都要学些一些开发基础知识。这样当程序员出问题的时候，就不致于发生不知道代码、资料库不知在何处的窘境。为了把风险降到最低，以下来谈谈创业者在与程序员合作时需要注意的几个重点。
防范风险前，先了解工程师对公司的期许
防范风险前，先了解工程师对公司的期许理想的情况下，我们都不希望让一个优秀的程序员离开团队，希望程序员能与公司一同成长、长久共事。所以我们可以先了解对于大部分程序员来说，对公司的期许是什么。
一般来说，我们都知道营运端的人需要技术端的人做出平台来让公司运转，而风险就在于技术端的人没办法如期完成工作，更严重是有的无法交出一个像样的平台，甚至人间蒸发。所以这也是为什么敏捷开发的理念，将产品开发的周期减短，也是减轻风险的一种方式。
但是反过来，大家不知道有没有想过，对技术端的人来说，风险在哪里？这边举一个我最常用的例子，如果一个程序员在阿里巴巴写一行代码跟在创业公司写一行代码，谁的价值比较高？答案显而易见，当然是阿里巴巴。因为使用者的量体大小，造成软体平台的价值有所差异。所以对程序员来说，如果他有更好的机会发挥更大的作用，同样的事情对应的营运端期许越高，本来就是他对于营运端的期许，发挥不如预期自然也成为风险。
一家公司成功的关键之一，就是降低人才的流动率，让每个人的技能与经验能够不断的累积而成长，也能完成对自己的期待。然而往往事与愿违，或许对于耿直的程序员来说，有更好的选择，也因此管理技术的风险才会显得如此的重要。
技术管理的风险在何处？如何将问题降到最低？
技术容易发生问题的地方，根据我们过去的经验，简单可分为几种：
问题一：
开发团队因故无法完成或交付任务。
这种状况其实还可以细分为完成一半还是全没完成，以及程序员还有办法联络到还是无法联络到。因此在做管理的当下，一定要记得掌握一些基本的原则。
预防方法:
代码一定要用Git 管理，并且定期请工程师Commit 代码，而且一定要写Commit Log。如果是做到一半的开发，至少会大概知道程序员写到哪。
数据库定期备份，虽然程序员有时候会做自动备份，但是有时候翻脸不认人的时候，还是有数据存在自己电脑最实在。
所有的服务器帐号密码一定要有列表，如果交接后，请全数变更。这样比较不怕程序员消失，就无法进入服务器进行管理与备份。
最关键也最重要的就是要有技术文件，但是很多人其实并不了解要做哪些文件才算齐全，不过至少有张图让你了解你们用了几台Server，大概系统的架构长怎样，API规划的文件是怎样，这些基本的理解，最好还是要有一些文件去做纪录和呈述。
问题二
数据库发生问题或是不翼而飞：前阵子发生伍笑衫的血淋淋案例就是Gitlab 的工程师不小心删除服务器的数据库，这些状况都让不少代码与数据付之一炬。
预防方法：升让
数据库备份其实也是一门学问，除了现在有很多云端服务会提供自动备份硬盘，建议还是可以定期一个月手动异地备份一次。
进一步请工程师使用Docker 进行管理，Docker 除了单纯的程式与资料备份外，能够更快地还原整体开发环境。
转移Schema 前一定要进行测试，很多数据的毁损与遗失，往往发生在schema 改变的当下，也因此，每次转移前的备份，决定是否要停机转移等等，都是需要谨慎思考的问题。
我认为作为一家创业公司的创始人，最好能够自己稍作了解，或是跟着走一趟，毕竟数据销毁的事，对很多IT 公司来说，应该就是命脉了。
问题三：
开发时间过久才发现大家想的不一样。
这问题有两种，一种是工程师的能力与原本评估有落差，另一点则是沟通不善。沟通不到位较为简单处理。但以评估落差来说，对于找外包或是再找其他工程师的方案，其实各有不同的恼人问题，对外包来说，麻烦的是如果头款已经支付，很难做到一半停下来，而换其他工程师的话，熟悉代码可能要好久，这都是普遍可以见到的状况。
预防方法：
如果是沟通不良的问题，团队可以用两到三周的时间作为一个循环，让工程团队定期做一个简单的Demo，每一次的工作都不宜开出一个太大的项目组，有别于以往长期项目组的思维，凡事要做到尽善尽美的思维一定要改掉。反过来说，每一个项目开发组慢慢建立，从主要功能到辅助功能分批完成，可以有阶段性的产出并且经历测试，这点非常重要。
针对选择招聘程序员或是外包团队，很多人会问说怎么可以确认工程师的水平？当然可以做reference check 或是code review，也许有些帮助。
很多人可能会想说，如果我们公司有良好的文化，有一大堆零食，有很好的福利，聘一个很厉害的工程师来，应该就不会遇到上述的这些问题了吧。但事实上是，即使连Google这么梦幻的公司，他们要写的每一行代码之前，开发者都必须先交出文件（Design Guide），去阐述待开发组的目的、功能、引用哪些Library等等，才能够进行开发。良好的文件管理与测试习惯，绝对会是风险管理的最大帮手。
永远要对最坏的状况有所准备
这篇文章提到的内容，对很多技术管理者来说，可能是基本中的基本，不过对于新手创业家来说，却是容易被忽略和受伤害的一环，有一些好的idea，却遇到一些不在预期内的风险，最后造成了不好的结果，这是相当可惜的事。因此，对于创业家来说，了解技术的风险，就像了解财务的风险一样，都是需要学习的功课。
创业者在创业过程中，肯定碰过几次程序员人间蒸发导致技术开发难以接手的案例。我也听说过不少类似的烂摊子。通常，创业者本身不懂技术或是对技术一知半解的状况，就更容易被程序员唬得一愣一愣的。别以为这种事只有遇到外包才会发生，我也看过技术合伙人学会隐身术后就人间蒸发的惨痛案例。
因此，我都建议每个非技术背景的朋友，都要学些一些开发基础知识。这样当程序员出问题的时候，就不致于发生不知道代码、资料库不知在何处的窘境。为了把风险降到最低，以下来谈谈创业者在与程序员合作时需要注意的几个重点。
防范风险前，先了解工程师对公司的期许
防范风险前，先了解工程师对公司的期许理想的情况下，我们都不希望让一个优秀的程序员离开团队，希望程序员能与公司一同成长、长久共事。所以我们可以先了解对于大部分程序员来说，对公司的期许是什么。
一般来说，我们都知道营运端的人需要技术端的人做出平台来让公司运转，而风险就在于技术端的人没办法如期完成工作，更严重是有的无法交出一个像样的平台，甚至人间蒸发。所以这也是为什么敏捷开发的理念，将产品开发的周期减短，也是减轻风险的一种方式。
但是反过来，大家不知道有没有想过，对技术端的人来说，风险在哪里？这边举一个我最常用的例子，如果一个程序员在阿里巴巴写一行代码跟在创业公司写一行代码，谁的价值比较高？答案显而易见，当然是阿里巴巴。因为使用者的量体大小，造成软体平台的价值有所差异。所以对程序员来说，如果他有更好的机会发挥更大的作用，同样的事情对应的营运端期许越高，本来就是他对于营运端的期许，发挥不如预期自然也成为风险。
一家公司成功的关键之一，就是降低人才的流动率，让每个人的技能与经验能够不断的累积而成长，也能完成对自己的期待。然而往往事与愿违，或许对于耿直的程序员来说，有更好的选择，也因此管理技术的风险才会显得如此的重要。
技术管理的风险在何处？如何将问题降到最低？
技术容易发生问题的地方，根据我们过去的经验，简单可分为几种：
问题一：
开发团队因故无法完成或交付任务。
这种状况其实还可以细分为完成一半还是全没完成，以及程序员还有办法联络到还是无法联络到。因此在做管理的当下，一定要记得掌握一些基本的原则。
预防方法:
代码一定要用Git 管理，并且定期请工程师Commit 代码，而且一定要写Commit Log。如果是做到一半的开发，至少会大概知道程序员写到哪。
数据库定期备份，虽然程序员有时候会做自动备份，但是有时候翻脸不认人的时候，还是有数据存在自己电脑最实在。
所有的服务器帐号密码一定要有列表，如果交接后，请全数变更。这样比较不怕程序员消失，就无法进入服务器进行管理与备份。
最关键也最重要的就是要有技术文件，但是很多人其实并不了解要做哪些文件才算齐全，不过至少有张图让你了解你们用了几台Server，大概系统的架构长怎样，API规划的文件是怎样，这些基本的理解，最好还是要有一些文件去做纪录和呈述。
问题二
数据库发生问题或是不翼而飞：前阵子发生伍笑衫的血淋淋案例就是Gitlab 的工程师不小心删除服务器的数据库，这些状况都让不少代码与数据付之一炬。
预防方法：升让
数据库备份其实也是一门学问，除了现在有很多云端服务会提供自动备份硬盘，建议还是可以定期一个月手动异地备份一次。
进一步请工程师使用Docker 进行管理，Docker 除了单纯的程式与资料备份外，能够更快地还原整体开发环境。
转移Schema 前一定要进行测试，很多数据的毁损与遗失，往往发生在schema 改变的当下，也因此，每次转移前的备份，决定是否要停机转移等等，都是需要谨慎思考的问题。
我认为作为一家创业公司的创始人，最好能够自己稍作了解，或是跟着走一趟，毕竟数据销毁的事，对很多IT 公司来说，应该就是命脉了。
问题三：
开发时间过久才发现大家想的不一样。
这问题有两种，一种是工程师的能力与原本评估有落差，另一点则是沟通不善。沟通不到位较为简单处理。但以评估落差来说，对于找外包或是再找其他工程师的方案，其实各有不同的恼人问题，对外包来说，麻烦的是如果头款已经支付，很难做到一半停下来，而换其他工程师的话，熟悉代码可能要好久，这都是普遍可以见到的状况。
预防方法：
如果是沟通不良的问题，团队可以用两到三周的时间作为一个循环，让工程团队定期做一个简单的Demo，每一次的工作都不宜开出一个太大的项目组，有别于以往长期项目组的思维，凡事要做到尽善尽美的思维一定要改掉。反过来说，每一个项目开发组慢慢建立，从主要功能到辅助功能分批完成，可以有阶段性的产出并且经历测试，这点非常重要。
针对选择招聘程序员或是外包团队，很多人会问说怎么可以确认工程师的水平？当然可以做reference check 或是code review，也许有些帮助。
很多人可能会想说，如果我们公司有良好的文化，有一大堆零食，有很好的福利，聘一个很厉害的工程师来，应该就不会遇到上述的这些问题了吧。但事实上是，即使连Google这么梦幻的公司，他们要写的每一行代码之前，开发者都必须先交出文件（Design Guide），去阐述待开发组的目的、功能、引用哪些Library等等，才能够进行开发。良好的文件管理与测试习惯，绝对会是风险管理的最大帮手。
永远要对最坏的状况有所准备
这篇文章提到的内容，对很多技术管理者来说，可能是基本中的基本，不过对于新手创业家来说，却是容易被忽略和受伤害的一环，有一些好的idea，却遇到一些不在预期内的风险，最后造成了不好的结果，这是相当可惜的事。因此，对于创业家来说，了解技术的风险，就像了解财务的风险一样，都是需要学习的功课。
已赞过
已踩过<
评论
收起
你对这个回答的评价是？
更多回答（2）
推荐律师服务：
若未解决您的问题，请您详细描述您的问题，通过百度律临进行免费专业咨询
