一：产品开发管理模式有哪些
列举4种产品开发管理模式，如下：
1、PACE：产品及周期优化法
PACE（Product And Cycle-time Excellence，产品及周期优化法）是美国管理咨询公司PRTM于1986年提出的，并由PRTM应用于指导企业产品开发流程的改进，它提供了一个完整的通用框架、要素和标准的术语。
2、IPD：集成产品开发
IPD（Integrated Product Development，集成产品开发），其思想来源于PACE，在此基础上， Motorola、杜邦、波音等公司在实践中继续加以改进和完善，由IBM在学习、实践中创建，并成功地协助华为实施了该体系。IPD集成产品开发流程概括起来就是“一个结构化流程、二类跨部门团队、三个系统框架集、四个主要决策评审点 、五项核心理念、六个重要阶段、七个关联要素和八项定位工具 ”，其核心思想是流程重整和产品重整。
3、SGS：门径管理系统
SGS(Stage-Gate System)门径管理系统，由Robert G. Cooper于20世纪80年代创立，并应用于美国、欧洲、日本的企业指导新产品开发。（Cooper ：长期致力于产品创新(开发)管理研究，尤其是实证研究，他认为通过广泛调查和统计分析，可以发现产品创新(开发)规律，它的许多实证研究报告成为理论界和企业界进行新产品成败分析的重要依据）
4、PVM：产品价值管理模式
产品价值管理（PVM）的思想是基于盈利模式、D.Lehmann和Crawford的《Product Management》，以及SGS门径管理系统，于2002年创立的最新产品开发和产品管理模式，在欧洲、美国、日本被许多中小企业及全球知名品牌企业所采用，PVM详细介绍了盈利模式及其设计方法，以顾客、需求和市场为焦点，以竞争和利润为导向，从企业愿景、战略落实到产品规划，围绕产品管理和产品生命周期轴线，讨论了新产品从概念构思到商业化的整个过程，强调基于商业模式的价值链和价值流分析，合理的战略与严密的评价程序是产品创新(开发)的可靠保证。
希望上述回答对您有所帮助！
二：什么叫线性产品开发模式？该如何理解
指量与量之间按比例、成直线的关系，在数学上可以理解为一阶导数为常数的函数；非线性(non-linear)则指不按比例、不成直线的关系，一阶导数不为常数。
在规定工作范围内，器件、网俯或传输媒介符合叠加原理的工作属性。
三：什么是互联网上最好的产品开发模式
现在的互联网产品开发体系里可以大致分为三类：第一类是完全使用软件开发模式，走CMMI，重文档，重流程，重测试这样带来的缺点就是开发周期长，流程烦琐，自然无法适应快速发展，更新换代以天为单位计算的互联网产品；第二类是野路子，极少或者完全没有文档，页面直接以PS为标准，功能设定以口头交流为主，这样的公司一般是小公司和非互联网公司，缺点是流程混乱，质量差，产品无法得到有效控制；第三类是将软件开发体系中符合互联网特点的部分借鉴过来，再根据自身产品特点加以改进，形成符合自身产品特点的开发体系，缺点是建立这一套体系需要时间和人才投入，一般公司不会为重建流程体系投入过多精力。
四：除了IPD还有其它产品开发模式可选吗
我们知道，产品开发是企业价值实现过程中的主线，其是否优秀将对企业绩效（包括财务和质量等）产生较大差别。目前，除了IPD，国际上的主流产品开发模式还有以下几种：
1. 基于系统工程的传统职能式开发。国内大量使用，而国外在系统工程基础上与时俱进，研究并实践了一些更优化的模式；
2. 门径管理系统（SGS)。由Robert G. Cooper于20世纪80年代创立；
3. 产品及周期优化法（PACE）。由美国PRTM公司于1986年提出，它是IPD的前身；
4. 能力成熟度集成（CMMI）。涉及软件、系统集成等方面的流程改进，于2000年发布，CMMI是帮助企业建立“可以自我形成好流程”的机制，但不少企业把它也当成了一种开发模式（流程）；
5. 产品价值管理（PVM）。主要基于唐纳德•莱曼（D.Lehmann）和莫尔•克劳福德(Merle Crawford)的《产品管理》一书，于2002年创立。
在选择IPD的时候不妨参考以下理由，也许能帮助企业尽快下决心：
第一、IPD源于一套完善的学术理论体系——PACE，并经过世界上优秀企业的实践和优化，报道称世界500强中近80%的公司都直接采用了IPD或间接采用（以PACE为基础的衍生模式）；
第二、除民用企业外，还有大量军工企业在使用，比如波音公司；
第三、IBM是硬件和软件制造商，具有硬件和软件双重开发经验；
第四、IPD的应用取得了卓越效果，IBM公司是在1992年亏损额高达80亿美元的困境下开始实施的，2008底在世界500强中排名第45位，位居IT业榜首，DELL、Microsoft位居其后；
第五、对于我国也是适用的，华为公司于1998年引进IPD，经过三年“先僵化、后优化、再固化”的落地实施及不断完善，已经发展成为2008年中国电子信息百强的领军企业（海尔、联想分列第二、第三）。
五：软件开发模式有哪些？
软件开发模式有哪些?
快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）
快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能
（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）
优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
缺点：
A、 所选用的开发技术和工具不一定符合主流的发展
B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下
增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）
与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代
与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）
优点：
1、 人员分配灵活，一开始不需要投入大量人力资源
2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）
3、 增量能够有计划的管理技术风险
缺点：
1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
注：
这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
原型模型：（样品模型，采用逐步求精的方法完善原型）
主要思想：
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，
采用方法：
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应
优点：
(1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。
（2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：
1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：
喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）
它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分
无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>）
优点：
1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程
不便之处：
1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
螺旋模型：（适合用于需求经常变化的项目<适合于大型复杂的系统>）
它主要是风险分析与评估，沿着螺线进行若干次迭代，
过程：
1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
2、 风险分析：分析评估所选方案，考虑如何识别和消除风险
3、 实......余下全文>>
六：软件开发模式有哪些？
软件开发模式有哪些?快速原型模型：（需要迅速造一个可以运行的软件原型，以便理解和澄清问题）快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义，快速设计开发出软件系统的原型（展示待开发软件的全部或部分功能和性能
（过程：用户对该原型进行测试评定，给出具体改善的意见以及丰富的细化软件需求，开发人员进行修改完善）优点：
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险
缺点：
A、 所选用的开发技术和工具不一定符合主流的发展
B、 快速建立起来的系统加上连续的修改可能会造成 产品质量底下增量模型：（采用随着日程时间的进展而交错的线性序列，每一个线性徐磊产生软件的一个可发布的“增量”，第一个增量往往就是核心的产品）与其他模型共同之处：它与原型实现模型和其他演化方法一样，本质都是迭代与原型实现模型不同之处：它强调每一个增量均发布一个可操作产品，（它不需要等到所有需求都出来，只要摸个需求的增量包出来即可进行开发）优点：
1、 人员分配灵活，一开始不需要投入大量人力资源
2、 当配备人员不能在限定的时间内完成产品时，它可以提供一种先推出核心产品的途径，可现发布部分功能给用户（对用户起镇静作用）
3、 增量能够有计划的管理技术风险缺点：
1、 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析注：
这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程
原型模型：（样品模型，采用逐步求精的方法完善原型）主要思想：
先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求，采用方法：
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应优点： (1）开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 （2）缩短了开发周期，加快了工程进度。
（3）降低成本。
缺点：
1、当重新生产该产品时，难以让用户接收，给工程继续开展带来不利因素。
2、不宜利用原型系统作为最终产品。采用原型模型开发系统，用户和开发者必须达成一致：
喷泉模型：（以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目）它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
相互迭代：软件的摸个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分
无间隙:它在各项活动之间没有明显边界（如分析和设计活动之间<由于对象概念的应用，表达分析，设计，实现等活动只用对象类和关系>）优点：
1、 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程不便之处：
1、由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
2、这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况螺旋模型：（适合用于需求经常变化的项目<适合于大型复杂的系统>）它主要是风险分析与评估，沿着螺线进行若干次迭代，
过程：
1、 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
2、 风险分析：分析评估所选方案，考虑如何识别和消除风险
3、 实施工程：实施软件开发和验证；
4、 客户评估：评价开发工作，提出修正建议，制定下......余下全文>>
七：B/S开发模式与C/S开发模式有什么区别
C/S模式是一种两层结构的系统,第一层在客户机上安装了客户机应用程序,第二层在服务器上安装服务器管理程序.在C/S模式的工作过程中,客户机程序发出请求,服务器程序接收并且处理客户机程序提出的请求,然后返回结果.
C/S模式有以下特点:
1.C/S模式将应用与服务分离,系统具有稳定性和灵活性
2.C/S模式配备的是点对点的结构模式,适用于局域网,有可靠的安全性
3.由于客户端实现与服务器端的直接连接,没有中间环节,因此响应速度快
4.在C/S模式中,作为客户机的计算机都要安装客户机程序,一旦软件系统升级,每台客户机都要安装客户机程序,系统升级和维护较为复杂
B/S模式，即浏览器/服务器模式，是一种从传统的两层C/S模式发展起来的新的网络结构模式，其本质是三层结构的C/S模式。在用户的计算机上安装浏览器软件，在服务器上存放数据并且安装服务应用程序，服务器有WWW服务器和文件服务器等。用户通过浏览器访问服务器，进行信息浏览、文件传输和电子邮件等服务。
B/S模式有以下特点：
1.系统开发、维护、升级方便
每当服务器应用程序升级时，只要在服务器上升级服务应用程序即可，用户计算机上的浏览器软件不需要修改，系统开发和升级维护方便
2.B/S模式具有很强的开放性
在B/S模式下，用户通过通用的浏览器进行访问，系统开放性好
3.B/S模式的结构易于扩展
由于Web的平台无关性，B/S模式的结构可以任意扩展，可以从包含一台服务器和几个用户的小型系统扩展成为拥有成千上万个用户的大型系统
4.用户使用方便
B/S模式的应用软件都是基于Web浏览器的，而Web浏览器的界面是类似的。对于无用户交换功能的页面。用户接触的界面都是一致的，用户使用方便
八：weblogic 开发模式和生产模式的区别
SSL不同
开发模式：可以使用 WebLogic Server 安全服务提供的示范数字证书和示范密钥库。利用这些证书，可设计出在由 SSL 担保的环境中工作的应用程序。
生产模式：不应使用示范数字证书和示范密钥库。如果这样做，将会显示警告消息。要使用正式申请的数字证书
部署应用程序不同
开发模式：WebLogic Server 实例可以自动部署和更新驻留在 domain_name/autodeploy 目录中的应用程序（其中 domain_name 为域名）。
生产模式：由于自动部署功能已禁用，因此必须使用 WebLogic Server 管理控制台、weblogic.Deployer 工具或 WebLogic 脚本工具 (WLST)。
生产模式一般使用BEA的JDK，开发模式就无所谓了
九：敏捷开发模式用的测试是什么模型
【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离
建立单元测试覆盖率等度量指标
共享质量目标意味着质量责任由所有工程师共同承担
开发测试应该建立一定的测试覆盖......余下全文>>
十：什么是MVC开发模式以及它和传统开发模式的区别
故此模式适合小规模的WEB应用开发。JSP+JavaBean开发，虽然实现了逻辑功能和显示功能的分离，但是由于视图层和控制层都是由JSP页面实现的，即视图层和控制层没有实现分离，所以它任然属于Model1模式。Model2模式——MVC开发模式它是为了克服Model1存在的不足而设计的，MVC的具体含义是：model+view+control，即模型+视图+控制，这样的模式集成了JSP、Serclet、JavaBean，非常适合大型项目的开发。View视图层：代表和用户交互的界面，可以通过html、xml、applet小java程序等实现，它仅仅负责数据的采集和处理（显示）。在JSP中它由JSP页面单独实现。Model模型层：它常常使用JavaBean来编写，它接受视图层请求的数据，然后进行相应的业务处理并返回最终的处理结果，它负担的责任最为核心，并利用JavaBean具有的特性实现了代码的重用和扩展以及给维护带来了方便。Control控制层：(1)各层各负其责，互不干涉。各自更新之后对其它层没有任何干扰；(2)MVC开发模式有利于责任分工，让专门人员分别从事专门层的设计，提高工作效率和质量；(3)组件可以得到很好的重用，由于分工明确，各层的组件可以独立成一个可以重用的组件。
扫一扫手机访问
