《软件开发过程中项目管理问题研究,项目管理论文.docx》由会员分享，可在线阅读，更多相关《软件开发过程中项目管理问题研究,项目管理论文.docx（7页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件开发过程中项目管理问题研究,项目管理论文随着信息技术的飞速发展，软件产品的规模也越来越庞大,各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。但国内软件企业对于软件项目的认知，在一定程度上盲目多于理性、理论多于实践。鉴于上述问题，本文分析了基于项目管理的软件开发经过需要注意的几个问题。 1需求开发要注意的问题 需求开发作为软件项目启动的初始工作有两个目的:发现真正的需求并以合适于用户和开发人员的方式加以表述。 发现需求即需求获取, 真正的需求 是指在实现时能够给用户带来预期价值的需求 以合适于用户和开发人员的方式 即需求定义,主要是指对需求的最后描绘叙述必须让用户和开发
2、人员无歧义的理解。在需求开发经过,软件开发人员要注意如下的两个问题: 1.1 不要忽视非功能需求 通常，需求分析人员更多的关注功能需求，而忽视非功能需求，进而导致 NV2( 即 下一版本 ) 陷阱。陷入 NV 陷阱后，产品的质量会大打折扣，甚至 拿不出手 。另外，不完好的需求也容易导致架构的错误设计，如:1.1.1 XX 查询的响应时间必须小于 1 秒;1.1.2 并发用户的数量每小时超过 10000个用户对于此类性能方面的非功能需求，直接影响到架构中持久层设计所采用的技术，而且这种架构上的缺陷实际上很难在 下一版本 轻易的改变。为了防止陷入 NV 陷阱，非功能性需求从一开场就要被提出来，和功
3、能性需求一样遭到应有的重视。假如这些非功能性需求是确实需要的，就应该被写入需求规格书，并在产品开发经过中接受实现在状况况的检查。 1.2 正确面对需求变更 在大多数软件项目中最不稳定的部分就是需求。在项目需求分析阶段，必需全面的、应尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其它软件的接口要求，以及对项目进行评估的各种评价标准。但由于各方面的原因用户需求始终处在一个持续变化的状态中，这是项目开发人员必须的接收的事实。那么对于这样的现在状况，软件开发者该怎么办呢? 其一是把需求变化控制在最小的范畴，在需求变化发生之前尽量减少需求变化; 其二是在设计软件体系构造时，不仅应该
4、想到怎样知足如今已经提出的用户需求,同时也应适当地考虑到需求的变更，想办法应对需求变化，例如:采用面向对象的思想。世界都是由对象组成的，而对象都是持久的。面向对象的开发方式方法的精华真髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，由于企业的形式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方式方法就被称为 OOAD(Ob-ject Orient Analysis Design 面向对象的分析和设计)。 2项目管理人员需要克制的障碍 项目管理是一项控制性的工作,项目管理者的工作重点就是控制和协调。项目管
5、理者首先要确保每个成员完全理解任务,要把任务的目的解释清楚，并强调他对最终期限及评估成果的期望。 在软件的整个开发经过中项目管理者需要有效的监控工作进展，并提供应每个成员必要的协助，以确保整个开发团队朝着目的前进，并且在项目迭代开发经过中的设定可观测的里程碑。作为团队开发的项目管理者,要让整个开发团队有效地运转，发挥团队每位成员的最大能量,必需要克制以下障碍： 2.1障碍一:不信任员工 最简单的例子是，在重量级(Heavyweight)方式方法3(制定了大量的规则的 RUP 方式方法)中,基本假设是对人的不信任，但不信任就会产生很多的问题，比方士气不高，计划赶不上变化，创新能力低下，跳槽率升高
6、等等。轻量级( Lightweight) (像XP 这样只制定少量的规则来规范行为的方式方法)方式方法的出发点是互相信任，做到这一点是很难的，但是一旦做到了，那么这个团队就能高效运作。 2.2 障碍二:对任务的控制走向极端 很多项目管理者害怕失去对任务的控制。假如能够保持沟通与协调的顺畅，采用类似 关键会议制度 等手段，强化信息流通的效率与效果，任务在完成的经过中，失控的可能性其实是很小的。同时，在布置任务的时候，项目管理者应该尽可能地把问题、目的、资源等，向各成员交代清楚，也有助于避免任务失控。 2.3 障碍三: 管理意识薄弱 在软件企业中，项目经理大多是技术骨干。因而有些项目管理者凭着自个
7、的技术实力宁可自个做得很辛苦，也不愿意把工作内容交给团队成员。为什么呢? 他们以为，教会部下怎么做，得花上好几个小时; 自个做的话，不到半小时就做好了，花那么多时间教他们，还不如自个做更快些。问题是: 难道项目管理者就这样一直把所有的事情都自个做吗? 由于团队成员的经历体验、技能等方面的差异，尽管项目管理者自个亲身动手可能做得比其他成员好，但是假如项目管理者能够教会团队成员，就会发现: 其他成员可以以做得一样好，甚至更好。也许今天项目管理者要耽搁几个小时来教其他成员干活，但以后他们会为项目管理者节省几十、几百个小时，让项目管理者有时间对关键业务作更多的更深切进入的考虑，以保证软件开发的成功。
8、3 软件模块的再认识 每一个软件模块都具有三项职责: 第一个职责是它运行起来所完成的功能，这也是该模块存在的原因; 第二个职责是它要应对变化，几乎所有的模块在它的生命周期内都要变化，开发者应保证这种改变尽可能的简单。一个难以改变的模块是拙劣的，即便能够工作，也需要对它进行修正; 第三个职责是能和阅读它的人很好的沟通，对该模块不熟悉的开发人员也能比拟容易的阅读并理解它。一个无法进行沟通的模块也是拙劣的，同样也需要对它进行修正。 当开发人员最初编写一个模块时，代码对于他们来讲看起来也许是清楚明晰的。这是由于他们专注于代码的编写，对代码非常熟悉。 经过一段时间后，开发者回过头来在去看那个模块，就知道
9、自个怎么会编写如此糟糕的代码。为了防止这种情况的发生，开发人员必须站在阅读者的位置，对代码进行必要的重构，这样其他的阅读者就能够理解代码，同时所有的代码也需要团队中其他成员的评审。 4 重视经历体验的总结 在软件开发的经过中，对每一问题的解决不可能一开场就有一个好的方式方法，在解决一系列类似的问题后，开发人员再回过头来重新审视和评价自个解决问题的方式方法，在大多数情况下，开发人员都能够对这些解决方式方法加以提炼，对具有共性的解决方式方法进一步抽象，寻求更通用的解决方式，并将该设计经历体验提交到团队资源库组织成项目事件库。项目尽管有其独特性，但借鉴从同类型的项目之间的经历体验教训提炼出来的知识是
10、很特别有价值的。 在项目的收尾阶段，不仅仅是给项目的利益相关者一个正式交代，还有一个任务就是项目整个经过的经历体验教训予以提炼构成企业的知识财富4。企业的知识往往是隐含、散落在员工群体中，因而需要将员工的隐性知识转化成公司的显性知识。 结束语 项目管理固然没有非常高深的理论，但要真正施行起来，也绝非易事。对于软件开发企业而言，这不是一个小的改变，而是一种变革，企业需要为此付出艰辛的努力，进而在实践中锻炼提高，解决各种各样的问题，使项目管理工作越做越好。 以下为参考文献： 1郑人杰等.实用软件工程M.北京:清华大学出版社,1997.4. 2新产品开发项目中的需求问题EB/OL. 3Roger S.Pressman;黄柏素,梅宏译.软件工程-实践者的研究方式方法 M. 北京: 机械工业出版社,1999,10. 4丁荣贵等.软件企业项目管的有效性研究J.经济与管理研究,2005,4.