《单元6 产品开发流程及相关知识.docx》由会员分享，可在线阅读，更多相关《单元6 产品开发流程及相关知识.docx（7页珍藏版）》请在知海网上搜索。
项目批准后，决策生效，企业必须对新产品进行审批，人员和资源将投入到项目中。
1、对已形成的新产品概念进行营销战略规划是新产品开发过程中的一个重要阶段。
想法的筛选。
2、产品开发过程在概念开发和产品规划阶段整合有关市场机会、竞争力、技术可行性和生产需求的信息，以确定新产品的框架。
3、产品开发的五个阶段是项目立项、产品设计和开发、过程设计和开发、产品和过程确认、反馈、评价和纠正措施(SOP)。
4、新产品开发过程的第一阶段是寻找产品创意，即想象或创造新产品的过程。
5、一般来说，新产品开发的过程可以分为五个关键流程:产品规划、需求管理、产品设计、开发上线、版本迭代。
设计验证测试。
根据产品需求申请相关专利、软件著作权等知识产权保护。
产品开发的阶段划分取决于开发什么产品。
如果寻求共性的总结，产品开发一般应该分为六个阶段。
6、编号:时间:2021年X月X日这是一条通往书籍之山的道路，学习永无止境页码:第7页，共7页第六单元产品开发流程及相关知识1产品开发流程2小型项目开发管理1产品开发流程2小型项目开发管理一个企业的管理，大公司有大公司之道，小公司也有小公司之道。
如果把别人的经验生搬硬套到自己身上，可能会适得其反。
7、同样，一个开发项目的管理也是一样的，大项目和小项目也不完全一样。
8、但从另一个角度来看，大项目和小项目没有本质区别，很多方法都是通用的。
事件的特征众所周知，“软件危机”的出现源于一些大型项目的不断延期甚至失败。
相比之下，小型项目具有以下特征:该项目功能相对较少。
开发者更少了开发周期短另外，现实中很多小项目都是一些中小公司开发的，这些公司往往人员流动很大，这也是一个不容忽视的现实。
2小型项目开发中的常见错误小项目看起来简单，容易成功，所以人们往往忽略了小项目的管理。
其实这是一个误区，以下是小项目开发中容易犯的错误:在开发之前，没有仔细估算项目的可行性和工作量。
往往因为项目小，就草草做了一个开发进度，没有认真估计项目的难度。
因此，实际完成时间往往与预计完成时间相差很大。
没有真正的设计过程。
开发者少是指不同人的模块之间的交互和接口相对较少。
短开发周期意味着同一批人通常从头到尾负责一个项目。
两者都让人容易犯一些错误。
往往几个人见面，讨论最基本的；软硬件结构和功能接口分开各干各的，没有更正式的文档。
这种方法的潜在危险之一是，有些人可能对所讨论的接口和结构有错误的理解(应该承认，人会犯错误)。
一个误会可能会造成以后的返工。
另一个潜在的危险是在讨论中忽略了一些情况。
大家按照当时的分工完成自己的工作后，才发现所有的模块都无法组合成一个完整的系统。
其根源在于没有一个负责协调的人来不断监控整个开发过程。
第三个潜在的危险是，一旦有人中途退出开发团队，其他人加入，新人就很难理解别人之前做过的代码，简单的从零开始。
此外，没有文档的程序很难在将来维护和升级。
不用单元测试，直接进入系统测试。
造成这种现象的原因是每个模块都比较简单，但是为了测试一个模块，需要建立一些测试环境。
比如为了测试一个函数是否正确，你要用一些测试数据来调用这个函数，你需要写一些测试数据。
但是很多开发者觉得很麻烦，觉得反正其他模块很快就出来了，用真实数据运行几次就好了。
众所周知，一旦直接进入系统测试，在发现运行结果不正确后，需要一步步去找。
因为模块之间的调用关系，可能需要很长时间才能发现是某个模块的问题。
这种方法效率很低，而且要花费大量时间来定位模块上的错误。
另外，由于这种测试是不完全的，当一个模块被调用时，可能大部分时间都是正常数据，很少有边界条件。
可能有些边界条件很容易被忽略，时间长了才发现。
但是，如果每个模块都在边界进行测试，就很容易消除一些隐患。
可以说欲速则不达。
3合理开发流程合理的发展模式可以用一句话来形容，就是“麻雀虽小，五脏俱全”。
即使是小项目的开发，也还是要遵循项目开发的一般规律，必要的步骤不能省略。
但是小项目有自己的特点，可以相对灵活的实施。
下面从几个方面来描述一个比较合理的模型。
需求获取在进入正式开发之前，首先要获取用户的精准需求。
在这上面花相当多的时间是必要的。
项目大致可以分为两类:委托开发和公司项目开发。
对于委托开发，比如开发一个公司专用的系统，一般用户对项目要完成什么功能有一个清晰的轮廓，往往在开发合同中已经有了大致的约定。
然而，开发合同中规定的只是一个总体框架。
在进入开发之前，需要和用户有更具体的交流和探讨，了解用户心目中的产品是什么样的。
如果这一步做得不到位，往往在开发工作的后期会发现开发者的理解和用户的需求之间存在一些误区，必然导致时间的浪费。
对于公司已经启动开发的项目，在开发之前要做一定的市场调研。
一方面，从经济效益的角度出发，应该调查产品的潜在市场。
另一方面，从技术的角度，需要了解潜在用户对产品各种功能的要求，比如用户现在在用什么产品，对产品有什么意见和要求等等。
，并根据调查的统计结果决定待开发产品的部分技术指标。
为了更好的与用户交流，使用一些工具是非常有益的。
需求分析在了解了用户的需求之后，用一个模型来表达需求，这个模型就是需求分析。
这部分涉及到具体的方法，这里不再赘述，但原则上可能需要不断修改，形成分析文档。
强调几个问题:(区分问题域和系统责任。
系统责任是指待开发项目应完成的功能，问题域包含所有相关部分。
比如你要开发一个程控计算机开票程序，程控计算机是现成的，输出数据格式是固定的。
你的程序只需要从程控计算机中读取相应的信息。
那么，“程控计算机”在你的系统中只是一个外物，可能没必要把它当成一个类，只需要一个类就可以完成数据读取操作。
另一个例子是，您需要在现有的数据库上开发一些应用程序。
数据库的格式已经固定，并且已经有一个后台程序在运行。
你需要开发一个新的前台程序。
这个时候，服务器程序对你来说就是一个外在的东西。
但是，这种外部内容必须在分析文档中解释为系统的外部约束。
(需求获取与需求分析的关系用什么方法完成需求的获取，很大程度上影响了需求分析的实践。
比如一开始用用例来表示用户的需求，那么从各种序列图中选取的交互实体就是类。
(分析和设计过程之间的联系分析过程的内容是用类的结构来表示目标系统，不需要设计具体的实现，比如用什么编程语言，运行在什么操作系统平台上等等。
这些具体的实现是在设计阶段完成的。
面向对象方法的优点是分析、设计和编码过程的表示是统一的，可以更好地连接。
但具体是把分析和设计阶段分开，采用瀑布式开发还是其他方式，要看具体情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，瀑布模型有明显的设计阶段。
这样做的好处是有一个比较完整的分析文档，这样以后如果需要不同的编程语言或者其他平台，可以把这个分析文档作为开发的基础。
对于需求变化频繁的项目，可以采用少量分析；少量的设计；少量编码；测试的方式比较合适，可能随时需要回到前一个阶段进行修改。
但这意味着可能没有完整的分析文档。
现在，许多CASE工具并不区分分析和设计阶段。
然而，这并不意味着开发可以区分分析和设计。
CASE工具就像一支笔，怎么用好都要还给他人。
设计程序设计阶段的工作包括:对分析模型进行必要的修改。
一些类结构可能需要修改，这可能是由于编程环境的要求或者为了重用一些以前的工作。
定义接口部分和数据访问(数据库)部分。
目前很多编程语言都可以可视化设计界面，所以往往会把一部分界面工作留给编码阶段。
所以设计阶段的工作量并不大。
编码进入编码工作后，可能会发现之前的分析或设计阶段的一些错误，所以要回到之前的阶段，进行必要的修改。
试验如前所述，即使是小项目也应该进行严格的测试。
4人员安排较小的项目往往由几个人完成，基本上从头到尾都参与开发。
在这些人中，有一个项目负责人，负责分析、设计和协调。
因为项目小，项目负责人也要参与编程，所以这个人一定要合理利用时间，注意以下原则:协调几个人的工作比自己完成一段编码更重要。
因为协调上的漏洞，可能会导致很大的问题，所以项目负责人必须随时监控开发人员的工作，包括内容是否偏离要求，进度是否滞后等等。
这些任务完成后，项目负责人的剩余时间才能用于编程。
给每个开发人员一个明确的任务书。
无论是用面向对象还是其他方法开发，分析设计模型都只是从功能的角度来描述系统。
但是每个开发人员在具体的开发过程中必须非常清楚自己的任务，这些任务要在明确的文档中表达出来。
让大家熟悉设计模型。
让每一个开发人员都知道自己的工作在整个系统中处于什么位置，有时候可能会发现设计模型中的漏洞，从而避免自己写完代码后不得不修改代码的后果。
第7页共7页。
