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

H:精品资料建筑精品网原稿ok（删除公文）建筑精品网5未上传百度单元六 产品开发流程及相关知识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.让大家都大致熟悉设计模型. 让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位, 有时侯可能会发现设计模型中的漏洞, 避免了各人的代码编写完毕之后又要修改的后果。