曾经有一位常年混迹于中关村的朋友跟我说，现在但凡是计算机公司，都搞软件开发，几个大学生都能搞软件公司，世道变了。其实看看当今这个信息时代，计算机软件的规模和复杂度随着时代的进步也在增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。老V在此分析了 10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。
误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对需求的修改几乎是必然的。
分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。
加注：后期对需求的修改的修改是必然的，关键还是要控制主变更的范围。而且对于核心功能和逻辑是不允许随便变更的。前期需求分析要引入原型开发方法和客户细化需求，另外用户往往是很少有耐心将你的需求文档仔细看完的，关键还是需求分析人员要仔细，需求评审过程要仔细。对于不明确的地方在设计开发前必须要搞清楚。另外版本交付过程要迭代起来，要尽可能早的交付给客户可用的迭代一版本以便客户能够尽快反馈意见。
误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。
分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容易被实现。 加注：不清楚有谁这样认为，估计只有用户这样认为。作为一个软件开发人员应该有这些尝试。我们提倡敏捷开发和架构设计的灵活和可扩展，也是为了使开发能够适应变化，但并不代表变更都很容易实现。
误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。
分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移--不是着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。
批注:这主要跟软件项目本身的特点关系很大，以上分析中给出的主要应该是针对较大型的产品化软件开发项目。而对于规模较小，业务功能逻辑较简单，以及在软件企业公用平台已经有积累的情况下，编码可能承担主要的工作量。
误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。
分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。
批注：再次强调源代码就是最好的详细设计文档，不知道该误区是否是作者自己的误区还是教科书看多了。对于需要算法流程和伪码的一般都是很复杂的涉及算法的业务功能，如整个MRP运算逻辑的实现。
误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。 [本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
