微型的项目实践感悟 .docxVIP

工程建筑学相关资料ENGINEERING ARCHITECTURE RELATED INFORMATION 工程建筑学相关资料 ENGINEERING ARCHITECTURE RELATED INFORMATION PAGE PAGE 1 微型的项目实践感悟  　1、什么是微型项目　　微型项目是指绝大部分工作由一个人员负责的项目，这个核心成员负责项目的系统分析、构架、及绝大部分的编码工作。项目的持续时间一般不会超过一个月。项目的参与人员除了核心的程序员外还可能一部分辅助人员，包括第二程序员（负责一部分编码工作）、美工（负责界面设计）等。　　微型项目的规模一般很小，业务逻辑也比较简单，价格一般也不会超过10K.程序员通常直接和对方领导打交道。客户大多没有任何技术背景。需要程序员直接负责系统的需求分析。　　2、微型项目分析　　2.1一般流程：　　微型项目的流程可以说没有什么特别的，因为项目较小，通常谈不上工程学方法。但是因为系统需求的不确定性较大，一般来说，敏捷得思路比较适合。流程如图所示：　　以上过程有时候并没有什么明显的界限。鉴于项目的规模，大多时候在分析需求的时候，构建就慢慢的形成了，在形成构架的过程中，很多编码上的难点也就了然于胸了。对于需求上的变化，几乎是必然的。很多时候，项目预期一个月，但是一个星期就可以做完，剩下的三个星期都是在应对需求的变化。　　2.2需求分析　　这种小型项目的需求可能会千奇百怪，从常见的OA到医院的药房管理。从用户的角度看，他们通常是为了方便自己的工作，提高效率。但是什么样的程序才能满足他们的要求，他们也不知道。所以程序员就需要自己找到需求。　　怎样进行需求的分析呢，一般是从用户沟通和对用户工作流程的观察出发。　　在和用户的沟通之中，用户一般不会有系统的想法，或者用户的想法不现实。我们要做的就是把用户的想法记下来，然后从中提炼出真正的需求，打个比方：在一个医院药房管理系统中，用户说药材会分为中药和西药。真正的需求其实是药材需要进行分类，否则当项目开发出来用户或许就会要求增加中西合剂。当然，这里是要求敏锐的捕捉到用户的真正需求，而不是无限制的做猜想而增加项目不必要的复杂性。还有一些是不清楚的需求描叙，仍然用那个药房管理系统为例，用户要求记录入库出库信息。这条描述其实很不清楚：要记录哪些信息？纪录多长时间内的信息？信息需不需要有汇总和统计？当然需求的分析是一个渐进的过程。这里不但要求分析人员有敏锐的捕捉能力，还要求和用不断的和用户沟通，更多的让用户参与到系统的开发中来。　　一般交付之后用户的需求都会变更，这是因为用户没有技术背景，根本不可能清楚的描述系统的需要。所以用户一旦看到最终的系统，就会发现和自己预想的想法有很大的出入。所以这里的交付是个相对的感念，实际是指持续交付。所以敏捷开发在这类项目中是非常合适的工程学方法。　　2.3文档的管理　　对于微型项目，几乎一个目录就可以保存所有的文件，这样做的方法也是为了便于备份和转移。我常用的目录结构如下：　　1， Database.数据库目录。如果系统有不同的多种数据库，可以在该目录下根据数据库类型建立子目录，比如说SqlServer，Access等。然后根据版本建立下一层子目录。需要注意的时，有的数据库，比如SqlServer 2000.会锁定数据库文件，这样在备份或者转移项目的时候就需要先停止数据库服务。　　2， Design.主要是保存PageDesgin或者UIDesign.　　3， Document.这个目录比较重要，保存的时所有的文档。下面按照“日期+文档名称”的规则为每一个文档建立子目录。注意，这个目录下的文档是正式提交的文档。同时，一个文档可能提交过N个版本。　　4， Member.重要目录。用于保存项目所有成员的文档。类似于版本控制器。每个成员按名称建立自己的子目录，再在自己的目录下按照“日期+该工作名称”的方法建立目录。目录下保存该项工作所有资料。包括文字、图片等。这样每个成员的工作记录都有据可查。 　　5，Publish.项目发布的目录。按照“时间+版本”的方式发布，我们的目标就是尽早的发布！注意发布中应该含有所有相关信息，包括程序（安装程序）、数据库脚本、帮助文档，甚至是刻录光盘的Autorun.Inf.　　6，Ref.引用目录，里面放的是项目引用的第三方类库和相关的帮助文档等。　　7，Solution.重要目录。这就是我们的解决方案所在的地方了！一般是按照版本建立解决访问。　　8，Source.参考资料。可以是文档，图片，也可以是别人的产品，开源项目等。只要是对项目有参考价值的，都应该被捕捉。　　9，Team.团队的公用文件夹。存放公用的信息，比如说成员的联系方式等。