产品开发流程与小项目开发管理模板.doc

单元六 产品开发步骤及相关知识61 产品开发步骤162 小项目开发管理361 产品开发步骤62 小项目开发管理一个企业管理，大企业有大企业方法，小企业也有小企业方法，假如把她人经验生搬硬套到自己身上，可能会适得其反。一样，管理一个开发项目也一样，大项目和小项目标方法不完全一样。但从另一个角度来看，项目标大和小并没有本质区分，很多方法是共通。1小项目标特点大家知道，软件危机出现起源于部分大型项目标不停延迟甚至失败。小项目相比之下，含有以下特点: 1.项目功效相对较少 2.开发人员较少 3.开发周期较短 另外，在现实中，有很多小项目是由部分中小企业进行开发，这些企业往往人员流动性较大，这也是不容忽略一个现实. 2小项目开发中常犯错误小项目看起来比较简单，比较轻易成功，所以大家往往忽略了小项目标管理，其实这是一个误解，小项目开发中轻易犯以下部分错误: 1.开发之前没有认真地进行项目可行性和工作量估量。往往因为项目较小，便很草率地制订一个开发日程表，没有认真地估量项目难度，结果实际完成时间和估量完成时间往往有较大差异。 2.没有真正设计过程 开发人员少，意味着不一样人员模块之间交互、接口相对少部分。开发周期短意味着往往是一样多个人从头到尾负责一个项目。这二者全部让人轻易犯些错误。往往是多个人碰一下头，讨论一下最基础；软硬件结构、函数接口便分头去做自己工作了，没有一份较正式文档。 这种做法潜在危险之一是有人可能会对讨论出接口、结构了解有偏差(应该认可人是会犯错误)。一个误解可能造成以后返工。 另一个潜在危险是因为讨论时忽略了一些情况，等大家全部按当初分工完成属于自己工作后，才发觉各个模块组合起来却形不成一个完整系统。其根源在于没有一个负责协调人员不停监控整个开发过程。 第三个潜在危险是一旦有些人中途退出开发队伍，其它人加入时，新来人难以了解以前她人做好代码，索性自己从头来。另外，没有文档程序，以后维护和版本升级全部比较困难。 3.不经过单元测试而直接进入系统测试 造成这一现象原因是每个模块相对比较简单，不过为了测试一个模块需要建立部分测试环境。比如，为了测试一个函数是否正确，应该用部分测试数据去调用该函数，需要编写部分测试数据。但很多开发人员嫌麻烦，认为反正其它模块也很快出来了，直接用真正数据来运行几次就行了。 殊不知，一旦直接进入系统测试，发觉运行结果不正确后需要一步步查找。因为模块间调用关系，可能查了很久才发觉是某个模块问题。这种方法一来效率比较低，大量时间用在了将一个错误定位在模块上了。另外因为这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候全部是正常数据，极少出现边界情况，可能一些边界情况轻易被忽略，很久以后才被发觉。不过假如对每个模块进行单元测试时全部进行一下边界测试，就会很轻易消除部分隐患。真可谓欲速则不达也。 3合理开发步骤 合理开发模式，一句话形容就是麻雀虽小，五脏俱全，即使是小型项目标开发，仍然应该遵照项目开发通常规律，必需步骤不能省略。不过小项目有它本身部分特点，实施起来能够相对灵活些。 以下从多个方面描述一下比较合理模式. 1.需求获取 在进入正式开发之前，必需先从用户处获取正确需求。在这上面花费相当初间是很必需。 项目能够大致分为委托开发和企业立项开发两大类。 对于委托开发，比如给某单位开发一套该单位专用系统，通常见户对于项目要完成哪些功效已经有了一个比较清楚轮廓，而且往往在开发协议中已经大致地要求了。 不过，开发协议上要求只是一个大约框架，在进入开发之前必需和用户进行比较具体交流和讨论，了解清楚用户心目中产品到底是什么样子。这个步骤假如没有好好做，往往到了开发工作后期才发觉开发人员了解和用户要求有部分误解，那么肯定造成时间上浪费。 对于企业立项开发项目，在开发之前应该做一定市场调查工作，首先是从经济效益考虑，调查产品潜在市场有多大，其次是从技术角度，必需了解清楚潜在用户对产品多种功效上要求，比如，用户现在使用什么产品，对该产品有什么意见和要求等等，依据调查统计结果决定立即开发产品部分技术指标。 为了比很好地和用户进行交流，使用部分工具是很有好处。 2.需求分析 在了解用户需求以后，将需求用一个模型来表示，就是需求分析。 这部分包含到具体方法，在此不具体讨论，不过标准上可能需要不停修改而形成一份分析文档。 强调多个问题:（1）要分清问题域和系统责任系统责任是指所要开发项目应该完成功效，而问题域是包含全部相关部分。比如你要开发一个程控机计费程序，程控机已经是现成，输出数据格式也已经是固定，你程序仅仅需要从程控机中读取对应信息，那么，程控机在你系统里只是一个外部东西，把它作为一个类可能就是无须要，仅仅需要一个类来完成读数据操作。又如，你需要在一个已经存在数据库上开发部分应用，数据库格式已经固定，而且已经有一个后台程序在运行，你需要开发一个新前台程序，这时，服务器程序对你来说就是一个外部东西。不过，象这种外部内容必需在分析文档中有部分说明，作为系统外在约束。 （2）需求获取和需求分析关系用什么方法来完成需求获取，在很大程度上影响了需求分析做法。 比如当初采取Use Case来表示用户需求，那么从多种序列图中选出相互交互各个实体，就是一个个类。 （3）分析和设计过程衔接分析过程内容是用类结构来表示目标系统，并不设计具体实现，如采取什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成。面向对象方法优点是分析、设计、编码过程表示法统一，能比很好衔接。不过，是把分析和设计阶段分开，采取瀑布式开发，还是采取其它方法，要看具体情况。 对于需求潜在改变不大项目，能够采取瀑布模型，有一个很显著设计阶段，这么做好处是有一份比较完整分析文档，这么以后假如需要采取不一样编程语言、或采取其它平台时，便能够以这份分析文档作为开发基础。 对于需求改变频繁项目，可能采取少许分析;少许设计;少许编码;测试方法更适宜，而且随时可能要返回到前面某个一阶段去进行修改。不过这意味着可能没有一份完整分析文档。 现在很多CASE工具并不区分分析和设计阶段。不过，这并不意味着开发就能够对分析和设计不加区分，CASE工具如同一支笔，怎样用好还得还人。 3.设计过程 设计阶段工作包含: 对分析模型必需修改。可能需要对一些类结构进行部分修改，这些修改原因可能是编程环境要求，或为了重用以前一些工作。 定义界面部分、数据访问(数据库)部分。 因为现在很多编程语言全部能够可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段工作量并不大。 4.编码 进入编码工作以后，可能会发觉前面分析或设计阶段一些错误，这时应返回到前面阶段进行必需修改。 5.测试 如前所述，即使是小项目，也应该严格地进行测试。 4人员安排 比较小项目，往往是多个人来完成，这多个人基础上从头到尾参与开发。在这多个人中，有一位项目责任人，负责分析、设计和协调工作。因为项目小，项目责任人也要参与编程,那么这人必需把时间合理利用， 注意以下以点标准:1.协调多个人工作比自己完成一段编码更关键. 因为协调上出了漏洞，可能造成很大问题，所以项目责任人必需随时监控各开发人员工作，包含内容是否和要求发生偏差，进度是否滞后等等。 只有在完成这些工作以后，项目责任人剩下时间才能用于编程。 2.给每个开发人员明确任务书. 不管是用面向对象或其它方法开发，分析、设计模型只是从功效角度来描述系统。不过，具体开发时每个开发人员必需很明确自己任务，这些任务应该采取明确文档来表示。 3.让大家全部大致熟悉设计模型. 让每个开发人员全部清楚自己所做工作在整个系统中处于什么地位，有时侯可能会发觉设计模型中漏洞，避免了各人代码编写完成以后又要修改后果。