初始阶段第二天

         今天是项目开始的第二天，随着对环境的熟悉，项目组也慢慢步入了正规。 因为前期对需求多少有些投入，所以整理起来并不是十分困难。但正如我之前所说，在真正的软件开发过程中，用户都不知道自己的需求。随着项目的深入，这个问题会逐渐报露出来。所以需要一套有效的方法对其加以重视。在整理需求规约的过程中，发现真实的需求和当初的设想有大量的差异。主要体现在两个方面。一方面是因为用户对项目的期望，往往期望和现实的不贴切造成了需求整理的出入。另一个主要的问题是我们对需求的整理不够科学，喜欢固步自封。常常以为自己看到的就是需求，而不去思考这些表象的背后。用户在看到这种需求时是认可的，因为它确实是需求的一部分，但这种需求并不完整，只是概念上的一致。在剩余油分析的过程中，我发现了这种问题的存在。之前获得的需求虽然没有大的变动，但是有些内容完全是因为文档整理的问题而错过了。所以在需求的整理过程中，一定要注意文档的描述，尽可能不要使用模糊的字眼。正如需求的要求一样，要正确，要清晰。还有就是一定要和客户多加交流，这种交流最好是面对面的，可视的。人的想像力是无穷的，在这种无穷想像力的背后往往是对不同事物的同一种描述。所以更加确定的一点是需求的整理尽可能建立在原型的基础上，这种原型可能是类似的项目，或者GUI快速原型，甚至是一个简略的代码实现。需求的准确性永远比华丽的文档更重要。关于剩余油分析的需求规约文档正在书写中，我想这书写的文档在后期一定要经过无数次的更改，这种更改在前期越频繁越好，否则带给项目组的将是无穷无尽的资源浪费。     
         风险列表的整理是伴随着整个需求探索的，而有些风险在接手项目的第一时间往往就可以表现出来。而这些风险可能在项目的开展过程中已经不再是风险，真正的风险却隐藏在项目的背后。比如剩余油分析，很多风险是直接暴露出来的。DWG文件格式的读写，Surfer图像的处理，B/S结构下图像的实时交互以及方法的动态加载等内容。这些问题的描述、可能的解决方案都还没有整理到风险列表中。还有就是开发工具、环境的配置，以及基于实际的项目计划和迭代计划。这些问题都需要加紧去落实。

      所以下午的任务还很多。前期的任务完成的越多，越能换取更多的反馈，给项目争取宝贵的时间，这很重要。