关于项目经理年终工作总结范文

　　合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。

　　以下我从几个方面描述一下我认为比较合理的模式.

　　1.需求获取

　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。

　　软件项目可以大致分为专用软件和通用软件两大类。

　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。

　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。

　　对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。

　　为了比较好地与用户进行交流，使用一些工具是很有好处的。　　为了讨论用户界面，可以用VB，delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)

　　为了讨论软件运行的流程，可以采用UML的UseCase图。

　　2.需求分析

　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。

　　这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系，可能需要不断修改而形成一份分析文档。

　　我想强调几个问题。

　　一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。

　　二是需求获取与需求分析的关系。

　　用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。

　　例如当初采用UseCase来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。

　　三是分析与设计过程的衔接。

　　分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。

　　对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。

　　对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。

　　现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。

　　3.设计过程

　　设计阶段的工作包括:

　　对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。

　　定义界面部分、数据访问(数据库)部分。

　　由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。

　　4.编码

　　进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。

　　5.测试

　　如前所述，即使是小项目，也应该严格地进行测试。