精华内容
下载资源
问答
  • 运动控制需要的数学知识比较多,如数据拟合/回归算法,插补算法,优化及数学模型设计分析等,不同的行业不同的工艺需要的数学知识往往也不一样,如果对数学比较感兴趣的,行会比较有意思。当然这行的计算机...

         运动控制这一行的软件比较特殊,主要体现在:

    1.专业性强,其需要的知识往往是自动化专业方面的知识,如一些控制原理或规划算法,当然专业性的概括还不只这些,要做好运动控制,没有在这一行的一定专业知识的积累也是不行的,多少要懂得一些机械方面的知识

    2.理论特色明显

    数学底子好的人,做这一行比较有优势。运动控制需要的数学知识比较多,如数据拟合/回归算法,插补算法,优化及数学模型设计分析等,不同的行业不同的工艺需要的数学知识往往也不一样,如果对数学比较感兴趣的,做这一行会比较有意思。当然这一行的计算机软件和计算机方面的理论知识也是分不开的。

    3.编程基础起点较高

          在这个JAVA C#等具有开发快速特点横行的时代,运动控制软件主流的使用的都是C/C++。当随着计算机硬件条件不断扩展别的软件行业对实时性的要求几乎都不做什么特别要求的时候,这个行业还在不断的强调需要达到MS级,需要更快的算法,需要更合理的模型。

    4.这一行比较吸引人的地方

          如果你感觉机器人(手),比较有意思。你了解过数控系统对一个国家的重要性,你想接触到能真正做到理论结合实际的软件行业。那么无疑运动控制软件是你的首选。

    5.这是个朝阳行业

          当那些做物流软件,ERP,网页,游戏开发多如过江之卿的时候,运动控制软件在国内才刚刚开始,并且正在进入一个很关键的时期,国内目前这方面的人才比较难招,毕竟这个行业需要自动化和计算机两方面的知识,这是个跨学科的行业,现在进入还不晚。

     

     

          说了这么多,我也想多认识一些这方面的朋友。如果大家感兴趣,欢迎和我聊聊,我的邮箱是dch_robot@yahoo.com.cn qq:235945859,当然也可以给我发站内消息。对于同行的交流,我向来是非常珍惜的,到目前为止我见过的做这一行的软件开发人员不超过10个,CSDN上有个叶子(他的主页:http://hi.csdn.net/space-1960504.html ),微软的MVP,很有名气,我想知道他的人肯定不少,我很欣赏这哥们喊出的口号:“十年软件,十年硬件”,他以前就是搞工控(和运动控制还是有些区别的,是运动控制的上一层)这一行的,现在这哥们跑微软去做.Net MF去了,做这一行可上可下。

     

    展开全文
  • 针对上图的一个判断条件,在这里将分别讨论判定覆盖、判定条件覆盖、条件组合覆盖的情况: 设T1=A>3,T2=B>3;为该判定节点的两个子条件。 (一)判定覆盖:  所谓的判定覆盖就是让判定的真分支和假...

    针对上图的一个判断条件,在这里将分别讨论判定覆盖、判定条件覆盖、条件组合覆盖的情况:

    设T1=A>3,T2=B>3;为该判定节点的两个子条件。

    (一)判定覆盖:

        所谓的判定覆盖就是让判定的真分支和假分支各执行一次,只要列出的子条件能够满足真假分支各一次就可以了:

    例如: A=4,B=3(T1=True,T2=False)走了真分支,A=3,B=3(T1=False,T2=False)走了假分支。

        当然,能走真假分支都走的条件组合还有很多种,这里随便选一种就可以了。

    (二)判定条件覆盖(条件覆盖):

        所谓判定条件覆盖就是给出的条件组合里面每个子条件的真、假都出现过,也就是T1(True,False),T2(True,False)都出现过。现在如果我们拿过问题(一)的条件组合,那么得到的就是:

         A=4,B=3(T1=True,T2=False)

        A=3,B=3(T1=False,T2=False)

    发现T1(True,False)都有了,T2(__,False)只有False,没有出现True,所以随便补充一个T2=True的条件组合就可以了:

        A=3,B=4(T1=False,T2=True)

        这样就满足判定条件覆盖了,当然,如果不在问题(一)的基础上扩展的话,可以用判定条件覆盖的最暴力的方式给出答案:

         A=4,B=4(T1=True,T2=True)

        A=3,B=3(T1=False,T2=False)

    这样就满足了判定条件覆盖。

    (三)条件组合覆盖:

        所谓的条件组合覆盖,就是一个判定的所有子条件的组合情况都出现一次。一般使用列表法,把子条件的所有组合情况都列出来,然后填表:

     

    T1T2红色是从问题AB
    TRUETRUE(二)继承的55
    FALSEFALSE------33
    TRUEFALSE绿色是补充的43
    FALSETRUE--------34

     

        在表格中的A B组合就满足了条件组合覆盖,可见条件组合覆盖是包含着判定条件覆盖的,而判定条件覆盖不一定包含判定覆盖。

     

        注:本例中给出的测试用例严格来讲都是错误的,因为一个完整的测试用例,还要给出结果,这里只是为了说明问题,程序是截块的,所以就只给了输入,没有给输出。

     

    展开全文
  • 如何做一个软件项目经理?----写给公司所有的开发人员


    注:文本中的“我”,均是网上作者(前三部分来自网络文章,第四部分除外)。

    第一部分:软件项目经理的要求

    首先是一个管理者,其次熟悉某些工具,某几种语言,行业背景,项目管理技能。

    软件项目经理面临的恶劣环境,我们绝大部分软件企业运行在相对混乱的状态(CMM一级),组织不大可能对项目以及项目经理的责任做出明确、合适的界定,所以,影响项目成功的一切因素都是项目经理的责任,包括客户、环境、考核、激励等等。

    一、责任心。取得项目的成功无疑是项目经理的责任。项目经理只有把客户的满意和企业长期利益作为自己的责任,项目成功才有可靠的基础,对于公司的战略性项目尤其如此。

    二、常识和直觉。大多数有违常识和直觉的做法最终会被证明为错误的,项目经理要积累足够多别人已犯的错误充实自己的常识。如果发现项目中有违反常识的现象,应该把它作为一个问题来解决,看一看是自己的常识需要改变还是这个现象需要改变。项目经理要尽量使项目按照常规运作,不要故弄玄虚,或过多使用程序员不熟悉的新名词来表现自己的水平,这样不仅无助于程序员形成良好的心态,而且无谓增加了项目的混乱。项目经理面对的是不断变化的环境和未知的将来。早上去上班,也许某个关键程序员要辞职,客户的需求发生了重大的变化,或是老板又有了什么让你头疼的新主意。面对这样的环境,项目经理必须保持敏锐的嗅觉,准备弹性较大的项目计划和设计方案,在大部分变化到来之前有所准备,以免项目受到重大的打击。

    三、学习的心态。软件技术的发展日新月异,项目经理必须了解最新的发展方向,如:JEE或 .NET,UML等等,看看能否应用于项目之中。而且项目经理还得学习管理方面的知识,CMM,PMBOK或是RUP,学习这些理论体系对于国内的大部分小企业来说,最重要的不是完全的导入,首先应该从这些先进思想中看到差距,在关键问题上做好改善工作,逐步推动项目管理和技术的进步。每个程序员都有其独到之处,项目经理应承认程序员有强于自己之处,并尽力促进成员间知识、技能的交流。

    四、尽一切力量去维护项目团队。国内的软件企业一般没有很好的文化和管理去构造一个富有凝聚力的团队。维持项目团队的稳定和战斗力更多成为项目经理的责任。项目经理必须关心程序员:1、尽力让程序员专注于自己的工作,杂事造成的影响远比这些事本身花的时间多。相对说来,程序员在处理杂事的时候效率会比一般人更低,也更容易犯错误,从而导致情绪变坏,影响工作。项目经理有时候应勇于承担勤杂工作。 2、要有宽容的心态,特别是对程序员。现在的程序员都比较年轻,自己觉得有点骄傲的资本,又处在一个浮燥的环境中,所以,有时候会做出一些过分的行为,项目经理千万不能太过在意。3、甘做幕后英雄,不斤斤计较。项目经理经常要在技术上支持程序员,但不能到处宣扬,而要把成绩更多归功于程序员。在项目紧张的时候,项目经理有时间的话要参与到繁琐的测试和调试工作中,或做一些代码工作。 4、维护公平原则。项目经理在分配工作、对项目成员进行考核评估时必须做到公平合理,让大家心悦诚服。

    五、沟通与交流。项目经理应该了解参与系统设计开发的成员,他们的特长和兴趣在哪里,以便更好地进行交流,这种非正式的项目外的交流对于团队的建设是至关重要的。此外,成功的项目经理也要善于与公司领导层的沟通,这是获得必要的资源支持的保证。有些优秀的软件项目经理可以与项目成员、相关部门或客户进行很好的交流,但没能与上级进行良好的沟通,他们在领导一个或几个项目取得成功之后,却发现在新的项目中缺少了基本的来自领导的支持。最终,有些项目经理选择了离开公司,而另一些则不得不放弃项目经理的角色。沟通与交流能力基本上是技术出身的大部分项目经理的致命伤。十年前,软件界最需要的是天才的开发人员,最近几年管理的重要性日益凸现,软件公司开始寻找优秀的天才项目经理。事实证明,天才总是可遇不可求的,而管理系统不能建立在小概率的基础上。解决软件企业的问题最终将依赖于组织管理水平的提高,比如说薪酬与激励政策、开发流程的优化、完善的培训制度,在一个管理良好的组织环境中,项目经理的责任以及履行责任的难度会大大降低,企业将不必再寻找天才的项目经理,相反,企业会成为优秀项目经理成长的基地。

    也有人这样说的:

    首先,了解项目管理的相关领域知识吗?你知道PMP的九大知识领域吗?你清楚CMMI、ISO对项目流程控制的各项要求吗?如果你有肯定的回答,那么恭喜你,你向项目经理的路上前进了20%。项目管理的知识领域越来越广,项目计划、时间管理、资源管理、成本控制、风险管理、质量管理乃至对供应商的管理等,每一块内容都有大量的知识需要学习和掌握,而且需要参与其中的实践经验。这么重要的内容,为什么只占了20%,你肯定很奇怪。没有错,即使你对项目管理知识掌握的了如指掌,那也只能有20%的加分。因为,这些知识仅仅是书本上的内容,通过学习大家都能掌握;即使不能全部记在脑海中,都可以边做项目边照着书上说的流程进行工作。如果每个项目照着流程按部就班地走下去都可以顺利完成,那还要项目经理干什么呢?所以,除了知识之外,另外80%的东西才是重点。

    协调能力!这是一个合格的项目经理必须具备的能力

    什么叫协调能力?就是与各色人等打交道的能力。项目经理的职位,其实是没有行政管理的权力的,就是对项目内的成员没有管理的权力,更多的时候做的工作是一个项目协调人。一个项目启动后,项目的成员可能都是临时从各个部门调来的,作为项目经理,需要与各个部门的人去协调每个成员的参与项目的时间期限。项目经理需要安排工作与每个项目成员,人都是一个个体,各种性格都有,如何与不同性格的人交道,这可不是一时半会儿能学得会的。项目经理也需要与上层领导协调,当项目推迟了,如何向领导解释原因,如何向领导申请更多的资金与资源,如何说服领导更加支持这个项目,这都是协调能力的体现。除此之外,项目经理还需要与客户协调,面对客户漫无边际的需求要求,如何加以限制,面对客户的种种苛求,如何一一化解,当最终产品提交给客户后,如何减少客户的抱怨,尽早的签收,这些都需要项目经理有非常强的,把与项目相关的所有shareholder全部摆平的能力。这一点,应该占到40%的比例,也就是说,如果达到上面两条,你就可以做一个及格的项目经理了。但这还是远远不够的。

    文笔!

    项目经理几乎可以不用写代码,但更多的工作是写文档以及报告。这几乎占据了项目经理大半的工作时间。

    从合同到项目计划再到项目报告,项目经理都需要极强的文笔写作功底。清晰,明确是文档的基本要求,更多的时候,项目经理需要从不同的角度解析同一个问题,而让人得到不同的结果。当然,如果你能把死的写成活的,黑的写成白的,那恭喜你,这20%你可以拿满分。

    沟通能力!

    不仅仅是语言沟通能力,还包括察颜观色的能力。项目经理未必需要口若悬河,出口成章,但说出的话一定让人清楚的明白;同时,也要通过表情,动作等身材语言,了解对方的内心想法。这一点,真得很难,有的人一辈子未必学得会与别人沟通。所以,只能看你的天份了。这一点,应该点到10%。

    最后10%,就是抗压能力

    作为项目经理,一定要能承受常人不能承受的巨大压力。尤其在项目遇到问题,进展不顺的时候,在成本上升和面临着最终期限快到的时候,如何承受并缓解那种压力,不是每一个人都能够做到的。如果你遇到一点事就郁郁寡欢,放不下,那在项目的重压之下,会是对你精神与身材的双重折磨。

     

    第二部分:软件项目经理的职责

    1、不断地识别项目干系人,并管理好项目干系人的期望。

       比如一个软件产品开发项目,可能的干系人包括但不限于:

       投资方希望通过产品赚钱

       产品用户希望产品好用、能给自己带来使用价值和良好的使用体验

       项目团队希望通过该产品体现自己的创造力、成就感,并收获劳动回报和能力提升

       政府机构希望该产品有着良好的社会效应

       ……

    项目干系人不是一开始就能完全识别出来的,所以需要不断识别

    要管理好项目干系人的期望,需要良好的沟通技能,要能换位思考,充分从对方的角度去理解与认识

    注:项目干系人,其实就是项目相关的人员。这是项目管理理论中的术语。

    2、组建和建设一支强有力的项目团队。

    项目团队是项目成功的关键要素,组建团队、激励并持续建设团队、协调好团队内部的关系和任务分配、充分沟通,是项目经理必须一直要做的事情。

    建设项目团队,包括了招募、培训、调配、指导等各方面的工作。

    3、做好项目管理计划,充分管控项目的范围、进度、成本、质量、风险等要素。

    项目的范围、进度、成本、质量、风险管控是项目管理的基本要素,也是项目经理要做的事情之一。当然,具体的需求调研及确认、系统架构设计、详细设计、开发、测试、变更、风险、文档、验收、交付、培训等等,甚至包括项目进度计划,都可以分解给项目团队成员来做,但项目经理要负责总体的管理和掌控,协调各方面的资源。

    4、总结项目。

    项目结束、产品验收交付后,项目经理的一个重要工作就是总结和分析项目的成败得失,尤其是充分总结经验和教训,作为自己、团队、所在的企业组织以后项目的借鉴和参考。

     

    注:软件项目经理,如果过多地深入到产品设计、开发过程,而或多或少地忽略其真正应该专注和关注的职责,对项目有害无益。我们目前项目多,人少,每个项目经理都要参与到自己项目或者别人的项目中担负相应的工作,需要高效调整自己的工作计划,并每天执行和修正工作计划。

     

    第三部分:如何做一个成功的项目经理

    软件项目管理是“以过程为核心、以度量为基础、以人为本”的,在此过程中需要充分地集成技术方法、工具、过程、资源(人力、资金、时间等)等要素,谁来领导这个集成工作呢?是项目经理。项目经理是项目组的灵魂,是项目组中很重要的一个角色,无论是对于个人英雄的时代,还是基于过程的管理时代,都必须依靠人来实现管理,这就是“以人为本”。无论管理多么正规,过程是对形式的管理,而内容的管理必须依靠个人的能力。

    项目经理,是大多数软件公司中最难选的人。为什么呢?有实践经验又有理论知识的项目经理少之又少,而且即使有身价也比较高,所以在软件公里面"勉强的项目经理比比皆是",有一定的开发经验,程序写的很好,有一定资历,虽然没有受过正规训练,也可能没有做过管理人员,但是没有办法,公司缺人,只好选他做项目经理了。当然,也不排除不具备上面的条件就做的很好的。99年我主管过1个成功的项目,该项目是为我们的一个老用户开发一块外围的采购模块,挂接在财务系统中。该项目组的成员都是刚参加工作的本科毕业生,他们是第一次用DELPHI开发应用软件,项目经理也是他们其中一个比较有管理思想的员工,在上学时是学生干部,比较有组织能力,我做为项目主管,对项目组进行管理的指导,因为我也从未用DELPHI做过开发,可想而知,该项目的人员风险有多大!项目的需求分析请了一位有经验的老员工来做,并由该员工做出概要设计,详细设计、实现与实施都是由项目组来做,他们竟然在规定的时间里按照需求完工了!在去现场实施之前我都以为不应该这么顺利,结果在他们实施完毕的几个月里面,用户用的很好,只有几个小的地方对界面进行了调整,没有进行软件的正确性维护!真是难以置信。为什么呢?在事后进行总结时,大家得出得结论是:我们是严格按照公司的软件工程规范做的。并非有经验的员工才可以做项目经理!新手一样可以成功!

    那么,究竟如何来选择一个项目经理呢?我们先看一下项目经理的来源。

    (1)专职的项目经理,比如说在公司里有项目管理部,专门是项目经理的派出机构,项目经理经过专业的培训与认证。

    (2)兼职的项目经理,来源于某一个技术部门,如开发部或事业部,同时可以兼任其他岗位。

    对于专职的项目经理,如果项目组中的成员有兼职的情况,即同一个项目成员可能同时参与多个项目,这时就存在资源竞争的问题,需要项目组之间进行协调,由于组员与项目经理没有行政的隶属关系,因而项目的协调很成问题。对于第二种方式,往往项目经理只会对他熟悉的作业内容、熟悉的人员进行管理,名义上是项目经理,实际是个局部经理。因此在选择设置公司的组织结构时,在选择项目经理时要充分考虑上述的两种情形。

    一个合格的项目经理,下面的要求是必须的:

    要公正无私

    99年我主管过一个项目,该项目的项目经理在分配奖金时论资派辈,不按业绩,使得项目组中资历浅但是干活多的员工怨言很大,导致整个项目的积极性很差,最后不得不由我出面制定新的业绩评估办法。如果一个项目经理不能做到公正无私,他就难以服众,无法带好项目团队。

    要有良好的职业道德

    2002年在我经手主管的一个项目中,由于项目经理蓄意隐瞒了项目的真实进展情况,对用户的承诺没有兑现,而导致用户不信任他,向公司提出了撤换项目经理的要求。用户对于项目有知情权,给用户暴露出问题不一定是坏事,因为只要大家能够互相理解,才能保证项目的顺利进展。如果明知完不成进度,而故意隐瞒了真相,当然是要受到惩罚的。

    要具有管理的基本技能与知识

    要做一个好的项目经理,他肯定要好好的学习一些关于项目管理的基础知识,进行项目管理的技能训练,既要有管理意识,还要有管理的基本技能,要"心有余且力也有余"。

    要具有很好的沟通与表达能力

    项目经理要和方方面面的人员沟通,包括项目组内的人员、市场人员、用户、上级主管,也要和各个层次的人员打交道,为了项目的成功要通过沟通交流消除来自各方面的阻力。譬如,一个系统集成的项目,在用户现场布线时,你可能要和用户的工程主管、电工、施工队等各种角色沟通,否则,可能因为很小的问题,你的系统就要失败。

    要有很强的分析问题解决问题的能力

    项目经理要能够通过现象看到本质,通过细节发现大问题,发现问题后要果断采取措施,而不是延误时机。如果一个项目经理对问题比较麻木,不能防微杜渐,那么就谁都可以做项目经理了!

    要懂技术,不要求精通,但是要全面

    这可能是争议比较大的一个原则,因为如果按此原则执行,那些拿到PMP证书的专职项目经理如何找工作?使用不懂技术的项目经理我也曾经尝试过,用过一个不懂开发的人来做项目经理,他主要对项目的进度负责,进行项目组内外的协调,但是为了弥补其不足,必须还要给他配一个助手专门负责技术。对于大的项目这种方式是可以的,对于小的项目而言肯定不能这样做,否则就会出现资源浪费,项目经理的工作量不饱满。所以我的意见还是要使用懂技术的项目经理,这样他能清楚地知道组员在做什么、做的怎么样,能够发出正确的方向性指令,而不是瞎指挥,外行领导内行。

    要谦虚,不能不懂装懂

    有的项目经理搞一言堂,听不进去大家的意见,而且不懂装懂。有一位软件公司的人力资源部经理向我诉说了他们公司由于软件项目经理选择不当而带来的烦恼。2001年他们公司聘用了一位项目经理,该项目经理被程序员们冠以"外行领导内行"的帽子,团队中绝大多数成员对他非议很多,他也听不进去别人的意见,从而使项目团队的效率很低,项目的质量很差,系统开始实施后,就陷入到大量的纠错改错的泥潭中。

    要平易近人,不要摆架子

    如果你的项目经理不能做到这一点,你肯定会对这样的项目经理很反感的!你也不会去和他很好地沟通的,当然项目组的效率也不会很高的。

    以上是对项目经理的基本要求,如果他能够在此基础上还有其他更好的优点,当然应该选中他。

    给项目经理充分授权

    在软件企业里面,一般有2种类型的组织结构:

    (1)事业部制:在事业部里面包含一个产品生命周期的所有职责:产品开发、产品客户化、项目实施、产品的售后服务、市场、渠道等。

    (2)功能部门制:即将市场、销售、产品开发、项目开发、实施服务、研发管理、测试的职能分散在不同的部门中,按功能划分部门。

    无论是哪种组织结构,对于项目组而言一般都需要采用动态的项目组方式,即项目组的成员是由不同部门的人员抽调到一个项目组中来,当项目完成后,项目组的成员就再回到各自的部门中。对于静态的部门它的职责是提供合适的人员,培养人员的专业技能,进行专业职能的标准化工作,各职能部门就象人才的蓄水池,而项目组简单来讲就是用人。在动态组织的项目组中很容易出现的问题是项目经理的权力不够或者项目经理的权威不够,所以一定要充分授权。

    不要轻易撤换项目经理

    2002年初,我接手了一个项目,该项目已经换了3任项目经理,导致该项目的工期一拖再拖,每换一次项目经理就要和用户协调一次,每换一次项目经理,用户就要将项目的需求重新讲一遍,用户何其无辜!

    所以在项目执行过程中,不要换项目经理。但是,换项目经理的情况在企业里是比较常见的,有时候企业也确实是不得已而为之,如项目经理离职了或者生病了。在项目初期要识别出这一风险,为了规避此风险在项目组内部可以实行AB角的方法,即有一个组员,他能够和项目经理一样熟悉项目的整体进展情况,一旦项目经理离开了,他随时可以补上。如果必须换项目经理时,也要选择一个恰当的时机,比如说系统开发完了,进入了实施阶段,可以将项目经理换成善于做实施工作的项目经理,再比如说在需求调研完了,可以换项目经理。

    牢记上面的原则,相信您的项目的成功概率会大大提高!

     

     

     

    展开全文
  • 浅谈软件开发中的假设条件

    千次阅读 2018-06-18 08:01:30
     翻开第篇聊假设条件的博客,发现已经快2年了。...这篇博客首先关联软件开发中的不确定性和假设条件,其次给出软件开发中假设条件的定义,最后举几由未妥善管理假设条件引起问题的例子。  在软件开发中,存...

     

        翻开第一篇聊假设条件的博客,发现已经快2年了。那篇主要涉及了点架构方面假设条件的东西,不是很全,今天开一篇聊一下软件开发中的假设条件。如果把假设条件限定在架构方面,稍显冷门。但如果将其扩展到整个软件开发中,这里面已有的工作非常多。这篇博客首先关联软件开发中的不确定性和假设条件,其次给出软件开发中假设条件的定义,最后举几个由未妥善管理假设条件引起问题的例子。

        在软件开发中,存在很多不确定性,但为了实现项目目标(如在计划内完成项目),涉众往往需要应对这些不确定的事物(如假设条件制定)。例如系统中需要采用一种新技术,而该技术的发布日期存在不确定性。那么涉众可能会假设一个可能的发布日期。软件开发中有许多针对不确定性的研究。以下给出四个例子。Ziv等人提到软件开发中有多种不同的不确定性,如需求分析中的不确定性、系统需求过渡到设计乃至代码中的不确定性、软件再工程中的不确定性、软件复用中的不确定性、测试中的不确定性[1]。例如Ziv等引用Humphrey书中的内容[2]以解释为什么需求分析中含有不确定性:即对于一个新的软件系统,在用户使用前需求都不会完全的清晰。Liu等人[3]关注需求不确定性,并讨论了需求不确定性、涉众间的冲突、软件项目效率间的关系。例如Liu等人认为需求不确定性导致不稳定的需求,而这种需求可以进一步导致涉众间的冲突。Whittle等人[4]提出了一种语言(RELAX)以解决自适应系统中的需求不确定性。Whittle等人认为不确定性来源于两个方面:(1)环境不确定性(即环境可能发生变化)以及(2)行为不确定性(即需求可能变化)。Cheng等人[5]同样提到环境不确定性是研究和采用动态自适应的关键因素,即根据系统环境的变化,持续地改变系统的行为。他们说道:“在开发周期内,不可能预知所有未来可能遇到的系统环境条件集合。

        本人认为不确定性和假设条件应作为两种不同但相关的概念:应对不确定性存在多种方式,其中一种方式就是制定显式的或者隐式的假设条件。例如上述的例子中,涉众也可通过选择采用其他技术的方式以应对该不确定性。

        在英文字典中,假设条件的定义为:“a thing that is accepted as true or as certain to happen, without proof”[6]或者“a fact or statement taken for granted”[7]。本人定义软件开发中的假设条件为:在没有足够证据支持的情况下,被接受或认可为真的软件开发知识。根据Alavi和Leidner[8]的文章以及Aurum等人[9]书中的描述,软件开发知识代表在软件开发中与事实、过程、概念、解释、想法、观察、判断相关的个性化信息。以上对假设条件的定义强调在软件开发中,假设条件具备不确定性的特征:涉众相信但不确定特定的软件开发知识的重要性、影响、适当性、适应性、正确性等。例如某项目经理假设其项目开发团队中的软件工程师具备足够的技能和能力来完成该项目。在这条描述中,该项目经理并非完全确定这些软件工程师是否具备足够的技能和能力。又如某软件开发人员假设修改构件A不会影响系统中的其他构件。在此描述中,该开发人员不确定修改构件A所造成的影响。在软件开发中假设条件是一个较为宽泛的主题:不同类型的假设条件被广泛地讨论(如需求假设条件[11]、软件架构假设条件[12]、软件构造假设条件[13])。不同的涉众(例如设计师、需求工程师、开发人员和测试人员)频繁地在工作中制定假设条件[13]。       

        因为未得到妥善管理的假设条件可能在软件开发中导致多种问题,许多研究者指出软件开发中假设条件及其管理的重要性[7]。以下提供五个相关例子。首先,Corbató[14]在图灵奖获奖演讲中指出:项目早期往往会制定一些假设条件。在后期,例如增加新功能时,若不注意这些假设条件则可能导致设计漏洞。其次,Garlan等人[15]指出:软件架构中不兼容的假设条件可能导致架构的不匹配(如构件或者连接器之间的不匹配)。软件架构的不匹配可能会导致进一步的问题,如设计的违反和低质量的架构。再次,因为假设条件概念的主观性,涉众可能对已经存在的假设条件产生误解[16]。对假设条件的误解可能进一步造成对其他相关软件制品的误解。例如因为对设计决策背后假设条件的忽视,涉众可能误解这些设计决策的真正含义。第四,Steingruebl和Peterson[17]提出未归档的软件开发中的假设条件可能导致软件的故障。例如假设系统将在单机模式下运行,则不必考虑外部安全性(如跨站脚本攻击和系统权限设计)。 但若该假设条件未被归档,当系统运行环境发生改变时(如系统将被部署到网络上),则可能导致安全问题。最后,Bazaz等人[18]定义系统脆弱性为“a state of the system from which it is possible to transition to an incorrect system state”,并指出对系统资源假设条件的违反可能导致系统变得脆弱(如内存或者I/O系统出现漏洞)。 

     

     

     

    [1] H. Ziv, D. Richardson, and R. Klösch. The Uncertainty Principle in Software Engineering. Technical Report, 1997.  

    [2] W.S. Humphrey. A Discipline for Software Engineering. SEI Series in Software Engineering, Addison-Wesley, 1995. 

    [3] J.Y.C. Liu, H.G. Chen, C.C. Chen, and T.S. Sheu. Relationships among interpersonal conflict, requirements uncertainty, and software project performance. International Journal of Project Management, 29(5): 547–556, 2011. 

    [4] J. Whittle, P. Sawyer, N. Bencomo, B.H.C. Cheng, and J.M. Bruel. RELAX: A language to address uncertainty in self-adaptive systems requirement. Requirements Engineering, 15(2): 177-196, 2010.  

    [5] B.H.C Cheng, P. Sawyer, N. Bencomo, and J. Whittle. A goal-based modeling approach to develop requirements of an adaptive system with environmental uncertainty. In: Proceedings of the 12th International Conference on Model Driven Engineering Languages and Systems (MODELS), Denver, CO, USA, pp. 468-483, 2009. 

    [6] Oxford Dictionaries. http://www.oxforddictionaries.com/definition/english/assumption  

    [7] Merriam-Webster. http://www.merriam-webster.com/dictionary/assumption 

    [8] M. Alavi and D.E. Leidner. Review: Knowledge Management and Knowledge Management Systems: Conceptual Foundations and Research Issues. MIS Quarterly, 25(1): 107-136, 2001. 

    [9] A. Aurum, R. Jeffery, C. Wohlin, and M. Handzic. Managing Software Engineering Knowledge, Springer-Verlag, New York, 2003. 

    [10] P. Kroll and P. Kruchten. The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP. Addison-Wesley Professional, 2003.

    [11] C.B. Haley, R.C. Laney, J.D. Moffett, and B. Nuseibeh. Using trust assumptions with security requirements. Requirements Engineering, 11(2): 138-151, 2006.  

    [12] M.M. Lehman and J.F. Ramil. Rules and tools for software evolution planning and management. Annals of Software Engineering, 11(1): 15-44, 2001. 

    [13] G.A. Lewis, T. Mahatham, and L. Wrage. Assumptions Management in Software Development. Technical Report, CMU/SEI-2004-TN-021, 2004. 

    [14] F.J. Corbató. On building systems that will fail. ACM Turing Award lectures, Year Awarded 1990, Communications of the ACM, 34(9): 72-81, 1991. 

    [15] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is still so hard. IEEE Software, 26(4): 66-69, 2009. 

    [16] R. Roeller, P. Lago, and H. van Vliet. Recovering architectural assumptions. Journal of Systems and Software, 79(4): 552-573, 2006. 

    [17] A. Steingruebl and G. Peterson. Software assumptions lead to preventable errors. IEEE Security & Privacy, 7(4): 84-87, 2009.

    [18] A. Bazaz, J.D. Arthur, and J.G. Tront. Modeling security vulnerabilities: A constraints and assumptions perspective. In: Proceedings of the 2nd IEEE International Symposium on Dependable, Autonomic and Secure Computing (DASC), Indianapolis, IN, USA, pp. 95-102, 2006.

    展开全文
  • https://blog.csdn.net/mj813/article/details/52451355,对原文进行整理 问:软件测试的原则? ... 问:你在测试中发现了一个 bug ,但是开发经理认为这不是一个 bug ,你应该怎样解决。 1、将问题提交到缺陷...
  • 对于一个成熟的软件产业来说,软件产品的质量至观重要。人们设定软件产品的质量目标就是要找到用户的质量需求与这些质量特性的相关性,并将其转化为开发过程中可度量的技术指标或能力指标,作为质量控制的依据。 ...
  • 互运行性:把该系统和另一个系统结合起来需要的工作量的多少 软件质量保证的措施主要有:基于非执行的测试(也称为复审或评审),基于执行的测试(即以前讲过的软件测试)和程序正确性证明。 复审主要用来保证在编码...
  • 判定覆盖/分支覆盖:是指选择足够的测试用例,使得运行这些测试用例时,每判定的所有可能结果至少出现次, 但若程序中的判定是有几条 件联合构成时,它未必能发现每个条件的错误;条件覆盖:是指选择足够的...
  • 吸引了众多的人加入这行业,那么,软件测试到底是做什么的,想要成为软件工程师,你就必须先清楚它的职责内容。1.测试和发现软件中存在的软件缺陷使用各种测试技术和方法来测试和发现软件中存在的软件缺陷。测试...
  • 软件需求评审会到底做什么

    万次阅读 2014-03-24 22:05:56
    软件需求评审会重要吗? 经常这样问自己,软件做完需求调研后,就进行需求分析,进而进行概要设计、详细设计、系统研发及测试,交付客户使用。可是,交给客户用的时候,...软件需求是软件开发的最重要的一个输入,需
  • 架构师不仅仅是团队中的角色,更是种思维方式,就算你是程序员,每天也会很多设计决定,这其中有些颇具架构意义,任何人一旦做出了影响软件系统结构的决定,实际上已经充当了临时的架构师,而无论你是什么角色,...
  • 一款app都需要哪些硬件软件什么的,才能保证这个app在用户的手机上正常运行? 请大神们详细的给我一个框架试的回答,最好有图片!谢谢!!! 1.硬件都需要哪些东西,比如服务器架设等等?? 本人一点不懂,完全的...
  • 书接上回:技术总监和CTO的区别 浅谈CTO的作用----软件公司如何开源节流(一) 讲完一个产品的艰难生产之路,我们还要回到产品的源头,如何开发一个可以开源的产品。尤其对于现在已经既定规则既定圈子的管理软件行当...
  • 什么软件测试?

    万次阅读 2018-03-21 22:07:47
    什么软件测试?What is software testing?软件测试是在测试中识别软件产品和服务的准确性和质量的过程。显然,它的诞生是为了验证产品是否满足客户的特定先决条件、需求和需求。在天的工作结束前,确定特定的最终...
  • 什么软件测试?软件测试的目的、意义是什么软件测试的流程是什么? 小伙伴儿们,大家好呀! 我最近是过的不太好呀,最近工作属实是...知识点什么软件测试,软件测试的定义? 答: 1.软件测试(Software Tes
  • 软件开发到底是在做什么

    千次阅读 2018-06-10 10:57:50
    一、基本定义 软件开发是根据用户要求建造出软件系统或者系统中软件部分的一个产品开发的过程。软件开发是一项包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制的系统工程。换句话说,软件...
  • 西门子PLC的仿真软件S7-PLCSIM,可以帮助用户在线查看程序状态,并可以模拟各种条件,进行PLC软件的模拟调试。但是,该软件无法对外通讯,因此,无法进行通讯试验。通过NetToPLCSim(免费)可以实现外部的访问。本文...
  • 一个软件测试人员的经验分享

    万次阅读 多人点赞 2007-03-02 11:14:00
    出来做软件测试三,四年了,确实正应了那句“测试不如开发”,只是个人观点,而且我工作过都是外企和大型国有企业,软件测试流程和管理都相对很规范化的。 下面几点给测试的朋友参考一下: 1、钱肯定少过开发人员...
  • 软件测试中条件覆盖,路径覆盖,语句覆盖,分支覆盖的区别 举例子吧 if A and B then Action1 if C or D then Action2 语句覆盖最弱,只需要让程序中的语句都执行遍即可 。上例中只需设计测试用例使得A=true B=...
  • 1、要有一个合法的域名。(如:https://www.baidu.com) 2、要有一个开发者账号,在这里注册:https://mp.weixin.qq.com/ 3、要有开发工具,在这里下载:...
  • 软件工程导论—软件测试

    万次阅读 多人点赞 2020-05-13 21:26:49
    1. 软件测试基础 2. 单元测试 3. 集成测试 4. 确认测试 5. 白盒测试技术 6. 黑盒测试技术 7. 调试 8. 软件可靠性
  • 软件测试:一个水杯的测试

    万次阅读 2017-03-28 20:29:21
    一个水杯的测试 满有意思,如果你愿意,可以发挥一下你的想象先,然后再看看别人例子,你会更加有收获噢!测试是一种思想,一种思路,当你脑子里面这个思路思想很清晰的时候 我们测试人员什么东东不会测试?HOHO!!...
  • 软件测试基础知识 - 说说黑盒与白盒的测试方法

    万次阅读 多人点赞 2019-02-11 11:48:37
    分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!请点击http://www.captainbed.net Definition Provide a surrogate or placeholder for another object to control ...
  • 前言 Xmind是一款非常专业的思维导图软件,收费好几百元,不过还是很多用户,因为目前用的最多,也简单易用。XMind界面友好、功能...XMind中的思维导图结构包含一个中心根主题,和围绕中心主题辐射的众多主要分支...
  • 软件质量有什么特性?

    万次阅读 2012-05-24 18:35:18
    软件质量有什么特性?《软件工程—产品质量》(GB/T 16260-2006)中规定对软件的每个质量特性与子特性都有定义:一、功能性:是指当软件在...互操作性:是指软件产品与一个或多个规定系统进行交互的能力。保密安全性
  • 鉴于每个环节都可以一个专题来进行探讨,所以受篇幅和时间限制,本文对有关问题未深入剖析,只做一个宏观上的介绍。一般而言,软件测试从项目确立时就开始了,前后要经过以下一些主要环节: 需求分析→测试...
  • 市面上40~50款效果图软件,哪一个适合你呢?
  • 题目:查询同时工作于"硬件"和"软件"两部门的每雇员的名字和年龄 select ename,age from emp WHERE eid in (select eid from works where did = '软件' or did = '硬件' GROUP BY eid having count(eid) = ...
  • 软件测试工作总结(

    千次阅读 2018-11-04 22:01:11
    1、为什么要在一个团队中开展软件测试工作?  因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 689,788
精华内容 275,915
关键字:

做一个软件需要什么条件