中小型软件项目开发Read.doc

中小型软件项目开发一：编写目的本文档的编写旨在探寻规范的软件开发流程、加快软件开发速度、提高软件开发质量、降低项目综合成本。IT界有一句格言：You can do it right; you can do it fast; you can do it cheap. Pick two. 而我们要做的就是：提供优质服务、项目周期短、成本低廉二：总体说明项目从用户需求说明书的提出，到系统的第一个完整版本的交付使用经历了若干或复杂或简单的过程，但不管项目大小如何一般需要经历以下几个步骤：1 需求分析。2 撰写需求规格说明书3 总体设计4 详细设计5 编码实现6 测试、试运行、上线7 验收8 日常维护9 （下一个版本的循环开发）在以上各步骤中尤其重要的是系统分析和撰写需求规格说明书。当定义好需求规格说明书后需要用户签字确认，以此作为项目验收的依据，在中大型项目中尤其重要。失败的项目原因很多但以下几点比较普遍：（1）商务运作中为了拉住“单子”对客户的众多纷繁复杂的要求一味的妥协让步满口答应。项目开发计划、时间表等完全依照客户意见，不以具体项目的客观事实为依据，不做认真细致严格的项目复杂度、项目工作量的评估。（2） 不做细致的用户需求分析导致项目后期的需求变更较大不能按期完成项目。三：项目开发经历的各阶段在项目开发的各阶段时间比例方面，中小项目一般控制在1： 40% 设计2： 40% 编码3： 20% 总体设计/试运行31 需求分析阶段研究客户需求，从中找出需求中模糊不清的地方，反复讨论确认。在不断的确认中，包括需求的总体认知、需求边界定义、目前技术条件下的可实现需求、用户界面等。通过项目组内讨论、与客户（直接客户、间接客户）讨论等方式不断清晰客户真正的需求，从而撰写需求规格说明书，在取的客户认可后签字，以此做为项目开发的第一个里程碑。在项目验收时以此作为验收的主要依据在系统分析阶段与客户的沟通方式可以通过（1）项目静态图、项目静态界面DEMO（2） 系统用例图（例如：rose软件的用例图） 等方式与客户沟通。本阶段要完成的工作有：1撰写项目需求分析报告本报告主要目的是项目分析人员提出需求的疑难不清问题，为与客户有效、准确沟通准备必要的材料。2画用例图 描述系统各个不同用户类型与本系统及其他系统等的交互过程。3建立项目静态界面DEMO使得用户在项目初期就可以看到项目上线实施后的使用界面和使用方法等4 做必要的技术预研等。32撰写需求规格说明书需求规格说明书的撰写主要目的是把客户天马行空、纷繁复杂、凭想象等的理想需求中变成在一定时间段、一定技术条件下可实现的需求。不然项目会很难满足客户的理想需求，永远被客户的理想需求所限制，陷入一种非常被动的状态。33总体设计在完成项目需求规格说明书后，就进入项目总体设计的阶段。在总体设计阶段需要完成的文档有：1 项目总体设计-概要设计说明书、2 数据库设计报告3 项目总体开发时间表在此阶段应该建立项目的正式开发环境、项目测试环境、建立项目基本开发框架且导入项目管理配置工具中（例如：CVS、VSS等）等在项目的以上阶段完成后，建议进行项目总体设计和总体开发准备情况的评审工作。在公司、集团专家组评审通过后本阶段结束，这算做项目的第二个里程碑。在进行下一阶段前，目前项目组可以对SCCB（软件变更控制委员会）提交的资料有：1：需求规格说明书2：项目总体设计概要说明书3：项目界面设计说明书（及界面DEMO）4：项目数据库设计说明书等5：项目总体开发时间表34详细设计在项目完成总体设计和搭建完毕开发环境后，就可以进行项目的详细设计。在项目中建议详细设计由项目编写“后台”程序的资深人员编写。主要完成每个负责的业务模块从界面到业务实现到数据库连接操作的主要步骤和数据库的实现SQL。最好在条件允许的情况下编写模块单元测试程序，在整个模块编码阶段完成后进行程序单元测试工作。（“测试驱动”的开发理念）详细设计目的是在不编写代码和少量代码的情况下，完成项目模块的模拟编程实现。在详细设计阶段可以对项目某模块做准确的工作量统计，依此为依据整个项目比较准确的工作量就可以被统计出来。35编码实现（略）36测试、试运行、上线（略）话说小型软件项目开发的流程规范 一、 问题提出特点大家知道，“软件危机”起源于一些大型项目的不断延迟甚至失败。与大项目相比，小项目具有以下特点:n 项目功能相对较少 ；n 开发人员较少； n 开发周期较短。 现存问题小项目看起来比较简单，比较容易成功，人们往往容易忽视小项目的管理，其实这是一种误解。据我了解，小项目开发中容易出现以下问题： 1、开发之前没有认真地进行项目可行性和工作量的估计。往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差距。 2、没有真正的设计过程 。开发人员少，不同人员的程序之间交互、接口相对少一些。开发周期短往往是几个人从头到尾负责一个项目，几个人碰一下头，讨论一下最基本的数据结构、函数接口便各自为政了，没有一份较正式的文档来规范各自职责和项目细节。 这时带来的危害有 ：1）。 是有人可能会对所讨论的接口、结构理解有偏差，可能会造成以后的返工。 2）。 潜在的危险是由于讨论时忽略了某些情况，等大家都按时完成分工任务后，才发现各个模块组合起来却无法形成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。 3）。 一旦有人中途退出开发队伍，其他人加入时，难以理解以前别人做好的代码，又要从头做起。另外，没有文档的程序，日后维护和版本升级都比较困难。这个问题在*系统中尤其突出，有如下现象：一）. 需求分析做得不好，没有最终的需求文档，很多需求到最后还要重新加进去，资料零散不集中，甚至有些资料早已丢失。二）. 没有系统完整的设计文档。系统中数据库有三个，没有完整的联系起来。很多数据日冗余，各个系统的接口不友好，有些还欠缺，使得系统有些地方都连接不起来。 三）. 由于人员的流动，文档资料不全，给后面的修改带来极大的困难。3、不经过单元测试而直接进入系统测试 。造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。 针对以上问题，结合日神系统及我之前的开发经验，我在开发小型系统时应该注意如下几个方面，严格把关，应该可以顺利完成项目。二、 解决之道1开发原则1）。团结合作，整体至上。2）。注意项目进度和项目质量，记住我们是提供一个符合合同要求且限时的解决方案给客户，不是完美产品（公司现状）。3)。麻雀虽小，五脏俱全。即使是小型软件的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小软件有它自身的一些特点，实行起来可以相对灵活些。4）。尽量重用现有的资源。2整个软件实施周期1）.需求获取在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。软件项目可以大致分为专用软件和通用软件两大类。l 对于专用软件，例如给某客户开发一套该公司专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。 如果客户是想升级现有系统，那么现在你要做的是理解之前系统实现了什么，客户新增的需求是否合理，旧系统的各个功能跟新需求怎么联系起来等问题。l 对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如：用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。对通用的软件，尽量使用软件复用，不过这是要评估修改的规模。为了比较好地与用户进行交流，使用一些工具是很有好处的。 为了讨论用户界面，可以用vc#.net,dream waver,frontpage等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)为了讨论软件运行的流程，可以采用Visio的Use Case图。注意：要让所以需求都界面化，并提交客户确认，会签保存文档 2).需求分析在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类-类之间关系,可能需要不断修改而形成一份分析文档。这边强调几个问题。一）是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。并且要组织要接口。二）是需求获取与需求分析的关系。用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。三）。是分析与设计过程的衔接。分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程 语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设 计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采 用其他的平台时，便可以以这份分析文档作为开发的基础。对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。不过当项目验收时，要把需求重新整理一下，确认存档。现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得由人。3）.设计过程设计阶段的工作包括:对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。定义界面部分、数据访问(数据库)部分。由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。设计后要把所有的文档提交客户确认后才进行下面的编码4）.编码进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。5）.测试如前所述，即使是小项目，也应该严格地进行测试。由于人员少，如果没有独立的测试人员的话，可以进行交叉测试，既程序员之间交互测试对方的程序。千万别自己测试自己的程序，但是程序在开发提交前，程序员是要自己认真测试所做单元的。3、人员的安排比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，经验告诉我几条原则:1）协调几个人的工作比自己完成一段编码更重要.由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。 只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 2）给每个开发人员明确的任务书.不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。但是，具体开发时每个开发人员必须非常明确自己的任务和完成时间（最好先给开发人员预估时间，我不喜欢项目经理强力下放），在执行过程中项目负责人要及时了解进度，这些任务应该尽量采用明确的文档来表示。3）让大家都大致熟悉设计模型.让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。4）整个系统再怎么小，都必须安排两个人以上负责。在获取客户需求时最好有两个人在场：项目经理和一个开发人员，开发人员一般做笔录和一些遗漏的提示。这样，不管以后人员怎样变动，整个项目应该就不会被人“遗忘”。 4项目双方的配合1。提供百分百的服务 1）。满足客户需求 客户需求肯定是永无止境的，所以要按合同的需求来做。 满足客户一些方便性的需求，注意必须是可以解决的而且要及时给以解决。 2）。提供和谐的沟通服务l 提供全方位的沟通环境（方式）提供全天的在线服务（就是让客户在工作时间内都能跟你-项目经理聊上几句，当然这是一定要是业务范围之内）。l 提供多种方式的服务（可以msn,qq,电话，邮件，直接上门等）。l 用对待老板的态度来对待你的客户。 3）。提供更有建设性的专业服务。l 很多客户只知道他们的生产流程，他们的工作方式，所以我们要提供专业性的建议，沟通利害关系，注意此时态度要温和。如果客户执意要执行，可以给他们一个反例，然后夸大后果，注意要专业性和合理性，之后我认为客户就会驯服些了。l 多提供一些能使需求更快捷的方案。2。以结果为向导1）。项目只有验收才能收款，所以要有结果，对于项目开发人员来说，任何一件事都是要朝着项目验收的方向进行。2）。我们是提供有限额限时的项目解决服务，因此要及时把项目收拢，分阶段。客户的需求不一定全都要做的。不属于该阶段的需求应该及时友好提示制止客户的需求，任何新的额外的必要的需求都要提交给上级和业务经理评估是否要做。3与客户沟通的心得 应该来说，一般的程序员跟客户的接触是比较少，但是由于是小项目，人员少，所以在这种情况下一般项目组里的人都有机会跟客户进行接触（只不过是直接或者是间接），一般在沟通是注意如下几点： 1请用开朗的微笑给你的客户服务。2明白客户是公司生存的根本，所以要用友好的，积极，热诚的态度来跟他们沟通， 记住要把对待你的老板的态度来对待你的客户，得罪客户意味着你跟你的老板过不 起。3 记住要把客户的意见/需求及时记下来，尽量当面记下，不清楚的及时提问。4 客户的意见/需求是可以修改的，这时需要用商量和建议性的态度，还有加上合理专业性。千万别无理强制。5 及时将客户一切动向跟项目总监和相关的业务经理反映，积极提出意见供参考。6 当与客户沟通出现问题时，不管问题大小，千万不可跟客户相关人员当面吵骂，我知道有些客户人员的素质是不高，不过千万别跟他们一般见识，千万不行进行人身攻击。最惨情况下，先停止一切争执和该次出差的任何事项回公司。及时跟相关人员汇报，及时提出解决方案，速度要快，如需要换人就换人。7 在与客户打交道时，平级的问题就在等级人员进行周旋，不要跨级。及时把结果跟上级汇报。8 上面“结果为向导”的第二点。9 任何跟客户谈的需求结果都要客户回签，所有交接的文档都要确认和存档。（可以利用电子邮件进行确定，如写成跟上级报告交接情况然后CC一份给客户，注意别泄密）10主动跟进客户的需求，同时也要紧跟我们向客户提出的要求和资料，不要以为客户会到时自动回答你或者把资料及时交给你。一般来说，在项目上线测试后，客户的动作就回慢下来，此时他们是想拖时间了，所以我们要积极及时跟进，限制测试时间，赶紧催验收。要不然后项目将成为无限期。5公司内部部门间的配合一般来说系统的开发人员的工作是很少跟其他的部门有关联的，但是如果是一个商业项目时，那么就不是独立了，至少一个项目会相关到开发实施，业务人员和财务人员。从项目开发角度来说应该注意下面几点：1 所有的努力都是为项目顺利进行，并通过验收2 整体至上，一个项目成功不是个人英雄的结果，而是团队合作创造的。3 根据我们公司具体情况，项目经理在平常就应该把项目进度，项目实施遇到的情况（不管是否技术问题），出访等情况跟相关的业务人员进行沟通，如果电子邮件CC一份给他们。4 当需要其他部门出面帮忙时，请事先通知是否有空，需要准备那些资料。5 把握重要里程碑，积极预先准备好各种资料提交给其他门部，如开始的项目需求方案等。