需求阶段项目如何监理.pdfVIP

需 求 阶 段 项 目 如 何 监 理 ？ 在原则上，需求阶段监理应尊重承建方的项目管理和项目分析能力；在具体的任务开展上，以不深入、 不干扰承建方的自主权为主，除非在项目合作过程中发现承建方的项目管理以及项目分析能力存在很 大的差距和不足。 为了保证项目的成功，监理方必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、 同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80 ％是由 于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而 项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用承建方的软 件。作为第三方的监理公司，必须提醒承建方、客户方重视需求分析的重要性，采用必要的手段和方 法来进行需求调研，同时监理方也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的 需求和方向，才能在将来的功能界定、开发范围上有发言权。 如何进行需求分析需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题， 再了解细节的问题。 一个应用软件系统（记为 S ）的涉及面可能很广，可以按不同的问题域（记为D ）分类，每个问 题域对应于一个软件子系统。 S = { D1 ，D2 ，D3 ，… Dn }问题域Di 由若干个问题（记为P ）组成，每个问题对应于子系统中 的一个软构件。 Di = { P1 ，P2 ，P3 ，… Pm }问题Pj 有若干个行为（或功能，记为F ），每个行为对应于软构件中 的实现接口。 Pj = { F1 ，F2 ，F3，… Fk }需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节 的技术员都合适。在写需求说明书时应该注意两个问题：1.最好为每个需求注释“为什么”，这样可让 程序员了解需求的本质，以便选用最合适的技术来实现此需求。 2.需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需 求。 图一 第一阶段访谈式项目中角色、流程图 图二 第二阶段访谈式项目中角色、流程图 重点监控需求分析由于项目的特殊性和行业覆盖的广阔性，以及需求 分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分 析又的的确确难做。其原因基本是由于以下情况造成的。 客户说不清楚需求有些客户对需求只有朦胧的感觉，当然说不清 楚具体的需求。例如全国各地的很多部门、机构、单位在进行应用系 统以及网络建设时，客户方的办公人员大多不清楚计算机网络有什么 用，更缺乏IT 系统建设方面的专家和知识。此时，用户就会要求软 件系统分析人员替他们设想需求。工程的需求存在一定的主观性，为 项目未来建设埋下了潜在的风险。 需求自身经常变动根据以往的历史经验，随着客户方对信息化建 设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目 的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需 求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需 求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求， 哪些是易变的需求，以便在进行系统设计时，将软件的核心建筑在稳 定的需求上，同时留出变更空间。咨询监理方在需求分析的功能界定 上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分 析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什 么”的系统功能界限。 分析人员或客户理解有误软件系统分析人员不可能都是全才，更 不可能是行业方面的专家。客户表达的需求，不同的分析人员可能有 不同的理解。如果分析人员理解错了，可能会导致以后的开发工作劳 而无功。记得一则笑话，有个外星人间谍潜伏到地球刺探情报，它给 上司写了一份报告：“主宰地球的是汽车。它们喝汽油，靠四个轮子 滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住 着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”所以分析人员 知识的专一性也会造成需求分析的误解和失败。这时，咨询监理公司 就必须根据实际的项目需求调研计划，提醒承建方加强业务了解程度 和注重沟通技巧。 需求分析方法论 根据以往的工程经验，需求分析工作方法，应该定位在“三个阶 段” （也称“三步法”。 第一阶段：“访谈式” （Visitation） 这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通， 主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组 织架构、业务流程、硬件环境