（工商管理专业论文）电力系统应用软件项目开发的风险管理.pdf

摘要 摘要 当前，随着我国企业现代化管理水平的日益提升，公司信息化管 理程度的高低已经成为现代管理不可或缺的一个环节。基于以上背 景，大型企业管理系统软件的开发日益频繁。作为软件开发企业，如 何建立科学规范的大型软件项目开发的风险管理模式成为新的挑战。 同时，从理论高度研究与之相关的的风险管理体系亦成为项目管理学 科关注的一个新内容。 本文试图以作者亲历开发的某电力系统软件开发项目为案例，从 理论和实践层面对大型软件系统的项目风险管理进行研究。案例中的 项目经由中国电力企业联合会在全国公开招标，标的为开发一套电力 生产可靠性管理信息系统，实现的功能为对全国电力生产的可靠性数 据进行有效的采集、统计、分析。 论文结合了部分管理学的基本理论，重点分析了该类型项目开发 中主要面i 临的几类风险：项目选择风险、需求风险、技术风险、人员 风险、软件质量风险。同时，对如何应当上述不同风险提出了对应的 解决方案。 在软件系统项目管理领域，作者希望自己的研究工作成果对构建 适合我国电力市场发展现状的软件开发风险管理模式提供有价值的 参考意见。 关键词：项目管理软件电力系统风险管理 a b s n 丑c t a b s t r a c t n o w a d a y s ，t l l em a n a g e m e n to fi n f o m l a t i o ni i le n t e r p r i s e sh a sb e c o m e o n eo ft h ec m c i a lp a r t so fm o d e mm a n a g e m e n tw i mt h ei m p r o v e m e n to f e n t e i p r i s em a i l a g e m e n ti nc h i n a ，w h i c hm a k e st h ed e v e l o p m e n to f m a n a g e m e n ti b 衄a t i o ns o f 啊a r em o r e 矗e q u e n c y h o wt ob u i i da s c i e n t m c ，n o r i i l a t i v em o d eo fr i s ki n a n a g e m e n tf o rs o n w a r ed c v e l o p m e n t b e c o m e san e wc h a l l e n g e m e a n w h i l e ，i n v c s t i g 砒i n gc o r r e l a t i v er i s k m a n a g e m e n tt h e o r e t i c a l l yh 鹊t 1 1 m e di m oan e wc o n t e n to fp r o j e c t m a n a g e m e m t h i sd i s s e r t a t i o ns e t sad e v e l o p m e n to fp o w e rs y s t e ms o f w a r ea sa n e x 锄p l e ，a n di n v e s t i g a t e sp 叫e c tr i s ki n a n a g e m e mo fc o i i 【p l e xs o f t w a r e s y s t c m st l l e o r e t i c a l i ya n dp r a c t i c a l l yt h ep r o j e c ti nm ec a s eh a si n v e s t c d p u b l i cb i d d i n gb yc e c f r o ma l lo v e rt h ec o 叫时t h ca ho ft h eb i d d i n g ， m n c t i o n m gt oc o l l e c t ，s t a t i s t i c ，姐da l l a l y s i s t h ed 吕旺ao fe l e c t r i c i t y p r o d u c t i o 玛i s t 0 d e v e i o pas e t o fi n 如m l a t i o ns y s t e mf o re l e c 订i c i t y s e c u r i 魄 t h ed i s s e r t a t i o n w h i c hc o 埘【b i i l e s w i t l l也eb a s i ct h e o r i e so f m a n a g e m e n t ，e m p h 粥i z e st oa n a l y z es o m es p e c i e so fr i s km a ta p p e a r w h e np r o j e c te x p l o i t s ，c o n c l u d i n gr i s ko fp r o j e c tc h o i c e ，r i s ko fd e m a i l d ， r i s k0 ft e c h n i q u e ，r i s ko fp e r s o n n e la n dr i s ko fs o f h v a r eq u a l i 珏 m e a i lw ：h i l e ，w a y sh a v eb e e np u tf o r v ，a r dt os o l v e 吐l ep r o b l e m st h a th o w t oc o p ew i t l l t l l er i s ka b o v e i n 也e 五e l do fs o f l w a r es y s t e mp r o j e c tm a l l a g e m e n t ，t h ea u m o rh o p e s t h ed i s s e r t a t i o n 、i l lb ew o m l yi nc o n s t m c t i n gt h er i s km a n a g e m e n tm o d e 、v h i c hi sf i tf o ro u r 口r e s e r l tm 丑】出d n d i t i o n k e yw o r d ：p r o j e c tm 锄a g e m e n t s o 矗啪r ep o w e rs ”t e m r i s km a n a g e m e n t 独创性声明 本人声明，所呈交的学位论文是我个人在导师指导下进行的研究 工作及取得的研究成果。尽本人所知，除了文中特别加以标注和致谢 的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不 包含为获得北京交通大学或其他教学机构的学位或证书而使用过的 材料。与我一起工作的同志对本研究所做的任何贡献已在论文中作了 明确的说明并表示了谢意。 本人签名：圭蝤鉴迟 项目背景 1 研究背景和意义 1 1 国内研究状况 虽然目前中国大多数i t 企业的项目管理模式仍然处于摸索阶段， 还远远没有达到成熟的阶段，但较传统模式而言，已经取得了一定的 成果，项目管理的优势主要体现在如下三个方面： ( 1 ) 提高管理效率 相对于传统的行政管理模式下由一个人负责很多项目而言，项目 管理的模式无疑更加明确了负责人，明确了其权利与义务。 ( 2 ) 降低综合成本 用项日管理的思路来考虑成本，在产品的原材料成本以外，还需 要关注产品的生产成本、运作成本和售后成本。其中，关于生产成本， 需要重点关注生产过程中的成品率以及模具的可互换性；对于运作成 本，需要考虑产品的运输成本、产品的生命周期以及产品升级所需要 的改造成本；对于售后成本，需要考虑售后的服务成本。 ( 3 ) 提高产品质量 项目管理过程中专职的质量工程师、质量管理员参与、对项目进 行跟踪为保证产品的质量奠定了基础；用项目管理的思路，在项目结 束以后进行总结，可以将获得的经验和教训文字化，对于以后进行的 项目将是一笔宝贵的财富，正所谓4 前事不忘，后事之师”。电力系统 是我国在生产和管理过程中应用计算机技术较早的领域之一，经过几 年飞速发展，软件产品的规模也越来越庞大，小规模作坊式开发方式 已经越来越不适应发展的需要。各软件企业都在积极将软件项目管理 引入开发活动中，对开发实行有效的管理。本文所涉及的项目小组， 在公司中的发展过程中也经历了从小到大，项目管理制度逐渐健全的 过程。 北京交通大学硕士学位论文 1 2 本文研究的意义 由于软件开发不同于其他产品的制造，软件的整个过程都是设计 过程( 没有制造过程) ；另外，软件开发不需要使用大量的物质资源， 而主要是人力资源；并且，软件开发的产品只是程序代码和技术文件， 并没有其他的物质结果。基于上述特点，软件项目管理与其他项目管 理相比，有很大的独特性。 对于电力系统而言，软件的开发过程有其特殊之处： ( 1 ) 由于电力生产是资金、技术密集型生产方式。生产过程的 专业性较强，用户与开发小组之间专业沟通难度大，理解需求存在一 定的障碍，在项目初期识别和确认客户需求上需要做很多努力。 ( 2 ) 由于电力生产是不阅断连续作业，为保证其可靠性在硬件 和软件上经常采用多重冗余，对于生产用软件要求有较高的可靠性， 如果由于软件的稳定性差造成的不良后果对于生产者来说可能是致 命的。用户对于软件的可靠性的关注程度要优于其它方面，所以在 项目尾期的测试验收阶段往往要花费较大的精力。 ( 3 ) 目前电力系统本身的管理、组织处于变革之中，各种政策， 法规都在不断完善，同时随着新技术的出现设备变化较快。受此影响 项目所涉及的目标、任务、周期在各个阶段都会发生变化，如何进 行有效的调整保证项目的顺利实施也是项目管理者经常面对的问题。 本人出于对该行业运用项目管理的兴趣和目前所从事的软件开 发工作实务中存在问题的一点理解，以及在导师的启发下，选择了 “电力系统应用软件项目开发的风险管理”作为硕士研究生论文。本 文从分析多个亲自参与的电力系统软件开发项目着手，期望从中总结 出的成功或失败的经验可以为从事电力系应用统软件开发企业提供 可资借鉴的一般性规律。尤其对于其特殊性问题的解决方案能给业界 作为参考。 2 项目背景 2 本文研究项目简介 本文所分析的案例是一个由本人全程参与的真实、完整的大型电 力系统软件开发过程案例，分析了其中项目管理的特点。本文所分析 的项目是由中国电力企业联合会全国公开招标，标的为开发一套电力 生产可靠性管理信息系统，旨在对全国电力生产的可靠性数据进行有 效的真实的统计、分析。该项目自2 0 0 1 年开始进入前期规划，到2 0 0 4 年实施完毕。期间经历了电力体制改革、电力可靠性技术标准变化、 非典的影响。项目本身经受了诸多风险，这些风险包括：项目风险、 需求风险、客户风险、项目人员风险。 以下是对于可靠性软件开发 项目的简要回顾： 2 0 0 1 年2 月1 6 一1 7 日，“电力可靠性信息管理系统软件( 网络版) 研讨会”在张家口市召开，会上国电公司电教中心作为竞标单位介 绍了开发方案。同年9 月，电力可靠性管理中心正式委托国电公司电 教中心开发“发电设备可靠性信息管理系统( 网络版) ”、“输变电 设施可靠性信息管理系统( 网络版) ”两套程序。 为了研发好这两套网络版软件，我们分别成立了两个开发小组， 同时成立了顾问小组开发组，按照中电联和可靠性中心领导要求，本 着技术先进，过程严谨，保证质量的原则进行研制开发。按照商业化 运做模式对软件开发全过程进行管理、控制、监督。从正式开始研发 到全国测评、需求变化、软件修改、再次测评，直至取得出版编号、 软件封装。经历了近4 年时间。 下面就软件开发过程做简要说明。 2 12 0 0 1 年项目简要回顾 2 0 0 1 年1 月成立可靠性软件研发筹备组，制作开发方案，准备参 加2 月份的可靠性软件竞标。得到可靠性中心正式委托后，正式成立 了发电、输变电电力可靠性管理信息系统( 网络版) 研发小组， 其 中领导组成员3 人，发电专家组8 人，输变电专家组8 人，程序员1 0 北京交通大学硕士学位论文 人，系统分析员3 人，顾问组成员4 人，共计3 6 人。 2 0 0 1 年9 月1 l 曰双方正式签署技术开发合同，并确定了技术开 发方案。 同时从9 月开始进行全国范围的可靠性软件需求侧调研工 作，内容涉及用户的硬件系统，网络环境，数据库类型，及对未来软 件的期望等，形式包括问卷调查，电话咨询，上门询问等。开发小组 收集分析相关数据后，采纳各方专家意见又重新修改和完善了技术开 发方案。 9 月1 8 日一1 9 日，电力可靠性管理中心在北京组织召开了发电、 输变电可靠性信息管理系统( 网络版) 软件研讨会，专家们踊跃发言， 积极发表意见，对某些问题展开了深入地探讨，对需要解决的关键技 术问题达成了一致的意见，并就网络版的开发提出了很多好的建议和 意见。专家们充分肯定了公司提出的方案总体思路和可行性。 2 0 0 1 年软件开发成本支出情况： ( 1 ) 成立了发电和输变电两个开发小组和两个专家小组，每个 开发小组由5 人组成，人工费用支出o 万元；专家小组每组由8 名专 家组成，支出咨询劳务费o 万元。为软件开发租用办公室和单身宿舍， 共支出1 万元。 ( 2 ) 购置了o 万元的专用软、硬件，使用原有设备计提折旧费0 万元。 ( 3 ) 支付各种计算机耗材、文具、低值易耗品、邮电费、水电 费等材料费0 万元。 ( 4 ) 本年度共召开了7 次会议，开发组来京汇报工作共5 次， 分赴青岛、邹县、荷泽、浙江、湖北等地调研共支出会议费0 万元。 ( 5 ) 开会等差旅费o 万元。 两个软件全年共支出o 万元。( 出于商业原因，略去真实费用) 2 22 0 0 2 年项目简要回顾 开发组按计划继续推进软件实施工作，多次在山东和北京就可靠 性专业问题和专家组开座谈会讨论。两个开发组聘请荷泽供电局、枣 庄供电局、黄台电厂，十里泉电厂等基层单位用户做应用层顾问，共 4 项目背景 同交流磋商软件基层使用问题。同时就有关技术问题多次与可靠性中 心进行交流讨论，其中包括输变电企业编码和事件编码；概率统计分 析方案；组合电裂等部分内容。 按照中心要求可靠性软件要在网络功能和分析功能两方面有所 突破，特别要具有预警性可靠性分析功能。为此开发组就概率统计分 析模块与山东大学数学系李煤教授，青岛远洋学院计算机系赵宪佳教 授共同探讨，多次歼会得出概率统计分析模块初步设想。由于概率分 析及故障预测专业性较强，男聘请了数学专家成立了概率分析专家 组， 开始启动概率分析及故障预测建模过程。并辅助软件开发小组 建立可靠性专业数据模型。开发小组开始编写主程序代码。 程序取得一定进展后，2 0 0 2 年7 月1 5 日至1 7 日在可靠性中心演 示了软件雏形。概率分析专家组介绍了发电机的设备寿命分布曲线和 模型。开发组就信息网络，概率统计分析，编码问题，风力机组，燃 汽轮机组和母管制机组问题与可靠性中心进行了交流，希望能得到更 为具体的需求。开发组向可靠性中心提出了设置固定i p 地址的建议。 开发小组继续软件的编写和修改工作，一个月后完成了输变电设 施可靠性信息管理系统( 网络版) 产品测试大纲，8 月就历史数据转 换、数据库平台、使用说明、w e b 等问题来京与可靠性中心讨论。2 8 日概率统计及故障预测分析得出初步模型，为该部分内容编程奠定基 础。 随着软件的进一步成熟，9 月1 6 日一2 0 日，山东电力集团公司生 技部李红梅科长和三名地市级可靠性专工在山东专门对输变电软件 进行了测试。1 0 月1 1 日一1 2 目，山东电力集团发电公司杜冠洲和三 名电厂可靠性专工在山东专门对发电软件进行了测试。测试后专家对 两个软件提出了建设性的意见和建议。两个开发组将这些意见整理后 反馈可靠性中心，可靠性中心经讨论修改了软件的部分需求，特别对 w e b 功能作了进一步的要求。由于新编码未能及时公布，软件编制工 作暂时停滞，开发小组根据新需求开始软件的修改工作。 2 0 0 2 年软件开发成本支出情况： ( 1 ) 2 0 0 2 年软件开发进入到了实质阶段，开发人员9 次来京向 可靠性中心汇报工作。请专家开专题研讨会5 次，同时请基层用户对 程序进行测试并提意见7 次，共支出差旅费o 万元，会议费o 万元， 北京交通大学硕士学位论文 咨询、测试劳务费0 万元，材料费支出0 万元。 ( 2 ) 由于概率统计分析需要专业人员进行指导，又聘请了3 名 专家，故本年度人工费用支出o 万元，房费0 万元。 ( 3 ) 设备计提折旧o 万元。 两个软件全年共支出o 万元。( 出于商业原因，略去真实费用) 2 32 0 0 3 年项目简要回顾 随着软件功能的进一步完善，可靠性中心和开发组及其它三个单 位于1 月2 1 日在山东省电力集团公司信息中心会议室召开了可靠性 数据传输测试环境准备会议， 2 3 日组织进行了包括山东省电力集团 公司，青岛电业局，济南电业局，北京可靠性中心，三地网络数据传 输测试。此次测试取得了成功，实现了在广域网环境下顺利的进行数 据上报和接收i 可通过i n t e r n e t 网进行上报和接收，并且可以穿过 代理服务器：在局域网内可根据权限进行数据共享；系统运行稳定。 2 0 0 3 年可靠性中心新编码发给部分单位征求意见，同时将编码结 构和部分内容发给开发组，开发组根据得到的编码进行数据转换部分 的研发。3 月1 7 曰参加在京召开的电力可靠性管理编码研讨会， 会上专家就编码提出很多建议。由于编码变动对软件影响很大，开发 组建议可靠性中心尽快推出完善后的编码。由于新编码迟迟不能确 定，新旧数据转换的编制工作受到严重影响，同时程序部分也受到影 响。开发组向中心提出服务器配置建议，由于中心短期内无法解决服 务器和固定i p 问题。开发组向可靠性中心提供一台服务器，并向电 信运营商租用了固定i p 地址便于软件开发。同时编写输变电、发电 可靠性软件网络版风险评估及应对措施。 3 7 月受非典影响与各地交流受到影响。为了保证软件开发进程， 开发组单独租用封闭环境进行开发。期间发电设备可靠性概率统计 分析完成，根据可靠性中心的新需求w e b 查询实施方案确定。根据软 件进展开发小组开始测试软件并筹备9 月的全国测试会。 2 0 0 3 年9 月1 5 一1 9 日在山东召开第一次全国测试会。会议代表共 计3 8 名。测试会上由于代表需求差别很大，对两个软件提出了许多 6 项目背景 意见和建议，新旧编码转换部分由于编码原因未能取得原定目的。软 件在界面友好，使用习惯上存在一定问题，并有部分错误。会后开发 组认真总结代表意见。与可靠性中心经过讨论修改了软件需求。 开发组在对软件的不断完善基础上于1 0 月2 9 一3 0 日由山东省电 力集团公司生技部对两个软件进行了全面测试。对软件修改后的结果 表示满意。1 1 月可靠性新编码陆续发行。开发组用新编码重新对数据 转换部分进行修改，其它涉及新编码的内容也重新进行了编程。 2 0 0 3 年1 1 月5 一1 4 日，电力可靠性管理中心在北京分别对发电、 输变电可靠性信息管理系统( 网络版) 软件组织了测试会，可靠性中 心要求开发组每周来京汇报工作进展情况。 2 0 0 3 年软件开发成本支出情况： ( 1 ) 2 0 0 3 年软件开发有了一定的成果，开发人员多次与中心领 导沟通，并召开了一次全国范围的大规模测试会，同时也进行了多次 小范围的测试，期间共支出差旅费0 万元，会议费0 万元，咨询、测 试劳务费o 万元，材料费o 万元。 ( 2 ) 2 0 0 3 年虽然有”非典”的发生，但我们软件开发工作并没有 停止，专门为开发组租用封闭场所进行开发，支出房费o 万元，人工 费用o 万元。 ( 3 ) 设备折旧o 万元。 两个软件全年共支出o 万元。( 出于商业原因，略去真实费用) 2 42 0 0 4 年项目简要回顾 可靠性软件开发组根据新需求继续对软件进行完善，与可靠性中 心在业务上保持密切联系。应可靠性中心要求，开发组于2 月7 日一3 月1 0 曰在华北电力大学进行封闭式修改完善。另外组织有关人员编 制了新旧编码校对表，并根据该表继续完善新旧数据转换功能。期间 可靠性中心对程序进行了多次审核。并邀请北京供电局，华北电网， 山西省电力局相关专工进行了测试。 由于3 年来全国电力系统信息建设较快，数据库变化较大，为保 证软件顺利使用进行了可靠性软件数据库及版本调查。开发组采用邮 北京交通大学硕士学位论文 寄问卷和电话咨询方式，得到了大量反馈信息。整理总结后确定了相 应程序的版本。 3 月3 日一6 日北京召开发电软件全国测试会，5 月1 2 1 3 日山东 省青岛市进行了输变电软件全国测试会。代表对两个软件充分予以肯 定，希望能尽快推广使用。同时也提出了更高层次的需求。开发组与 可靠性中心经讨论部分采纳了代表建议，对软件进一步完善。 我们信守对中电联可靠性中心的严谨承诺，本着慎重、稳妥的原 则，两个程序在推广前进行了全国试用工作。发电程序6 月2 8 开始 全国试用。开发组派专人分别在大唐集团，华北电网有限公司，华电 国际电力股份有限公司，华电国际电力股份有限公司总部，邹县电厂， 青岛电厂，十里泉电厂实地安装了软件并进行了培训。输变电程序于 6 月2 8 日一7 月2 日派人到枣庄，菏泽安装和培训，应当地要求完成 数据转换工作。7 月5 日派人到北京电力公司总部安装。应当地要求 完成数据转换工作。同日到通州区及其下属变电工区安装。7 月6 日 派人到北京电力公司变电工区安装。7 月1 2 日在京对北京电力公司下 属1 9 个单位进行培训。应当地要求，于7 月2 3 日完成山东电力集团 公司总部程序安装。 9 月完成了四个版本数据库的转换工作，进行程序的最后测试工 作，准备封装程序，开始印刷说明书，产品包装。 2 0 0 4 年软件开发成本支出情况： ( 1 ) 2 0 0 4 年春节过后，开发人员集中到华北电力大学进行后续 新增功能的开发，聘请专业人员进行多次测试，并召开了两次全国性 测试会，截止6 月底，支出差旅费o 万元，会议费o 万元，咨询、测 试劳务费0 万元，材料费0 万元。 ( 2 ) 房费1 万元，人工费用0 万元，设备折旧费o 万元。 两个软件卜6 月份共支出。万元。( 出于商业原因，略去真实费 用) 软件项目开发的风险管理 3 软件项目开发的风险管理 软件风险是指软件开发过程中及软件产品本身可能造成的伤害 或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身 包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选 择e 风险是介于确定性和不确定性之间的状态，是处于无知和完接知 识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因 素的改变。 当在软件工程领域考虑风险时，我们要关注以下的问题：什么样 的风险会导致软件项目的彻底失败? 用户需求、开发技术、目标计算 机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成 功产生什么影响? 对于采用什么方法和工具，需要多少人员参与工作 的问题，我们如何选择和决策? 对软件质量要达到什么程度习是“足 够的”? 当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这 些风险就是真正的风险了。在我们能够标识出软件项目中的真正风险 之前，识别出所有对管理者和开发者而言均为明显得风险是很重要 的。 3 1 项目选择的风险 项目风险是指围绕项目本身包括预算、进度、人力( 工作人员和 组织) 、资源、客户、需求等方面的问题以及它们对软件项目的影响。 电力系统软件项目可以分为：以生产为主体，直接参与控制，运 行监测和其他自动化过程的生产软件，诸如热工系统，继电保护系 统，数据采集系统，这类产品要求的技术含量很高，有些软件是直接 写入芯片当中，同时还要对电力生产的过程有详尽的了解。进入这类 产品市场的门槛较高，行业竞争并不十分激烈。诸多因素当中如需求， 资源，预算等比较稳定。对于项目本身的影响较小。另外一大类为紧 密围绕电力生产服务的管理信息系统，如：m i s 系统，财务管理系统， 密围绕电力生产服务的管理信息系统，如：m i s 系统，财务管理系统， 北京交通大学硕士学位论文 人事管理系统，教育培训l 系统，0 a 系统，客服系统，及其它根据用户 需求定制定做的项目。这类项目由于市场门槛较低，参与竞争企业较 多，竞争激烈。同时客户需求不断变化，在开发时很容易陷入泥潭。 属于风险较高的项目类别。如果进一步细分市场，如财务管理系统， 教育培训系统人事管理系统等，这类产品有其另外的特点。这类产品 由于通用性较高，如果一个客户顺利完成后。即便在成本考核上可能 认为这个项目是失败的，由于有很高的可移植性，在其他客户中稍做 改动变成功实施。如果存在这种续延的客户，这类项目从长远角度 来看，风险还是比较低的。项目风险威胁项目计划，如果风险变成现 实，有可能会拖延项目的进度，增加项目的成本。项目风险的因素还 包括项目的复杂性、规模、结构的不确定性。 3 2 需求风险 很多电力软件项目在确定需求时都面临着一些不确定性和混乱。 当在项目早期如果忽视了这些不确定性，并且在项目进展过程当中得 不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与 需求相关的风险因素，那么就很有可能产生错误的结果或者拙劣地制 作正确的产品。每一种情况都会导致使用户不满意。这种风险存在的 可能性在电力系统的表现尤为突出。开发方处于明显的劣势地位，信 息的不对称，沟通的缺乏，往往导致生成模糊的、错误的需求理解。 在这样的基础之上往往造成严重的后果，真至到了项目开发中期才有 所领悟，不得不重头再来。 在电力软件项目的开发过程中，需求变化渗透在整个软件项目的 生命周期中，从软件的项目立项，研发，维护，随着用户的对软件的 不断了解，对使用软件的感受有变化，以及整个软件技术水平的新升 级，都会对软件提出新的需求，在功能上要求不断完善，性能上要 求更为优化，以及使用上提出提高用户友好性的要求a 在软件项目管理整个过程中，项目负责人经常面对用户的需求变 更。要及时有效处理这些需求变更，否则项目计划会一再调整，软件 交付同期一再拖延，项目研发人员的士气将越来越低落，将直接导致 】o 软件项目开发的风险管理 项目成本增加、质量下降及项目交付日期推后。随着日期的推延新的 需求会层出不穷，最后形成恶性循环。 3 2 1 项目初期需求风险 由于电力生产是资金、技术密集型生产方式。生产过程的专业性 较强，用户与开发小组之间专业沟通难度大，理解需求存在一定的障 碍，特别是直接用于生产的软件，项目小组必须熟悉所要处理对象的 生产流程，关键控制点，在项目初期识别和确认客户需求上需要做很 多努力。电力生产人员不可能用项目小组所希望的软件流程的方式来 表达生产过程，往往初期的沟通是效率低下的，甚至是无效的。一种 行之有效的方法是项目小组使用调查问卷的形式，对所要处理的对象 有一个大致的了解，这也是初步建立软件大体框架的基础。下面是本 项目初期的一份调查问卷。该调套问卷涉及了用户的计算机应用和网 络建设水平，用户专业要求两方面的内容。 初期需求风险主要表现在以下方面： 对产品缺少清晰的认识 对产品需求缺少认同 在做需求中客户参与不够 3 2 2 初期需求风险防范对策 a ) 需求分析是整个项目管理中需要重点控制的几个关键节点之 一，首先思想上一定要重视。 b ) 需求分析报告的编写者要参与到需求的搜集工作中，准确领 会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的 客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措 施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问 题，以便防止遗漏。 c ) 需求报告的编写者要能够对客户需求进行深入分析，区别出 哪些需求存在曰后变更的可能，哪些需求属于相对固定的，哪些需求 北京变通大学硕士学位论文 能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。 d ) 需求分析报告对功能细节的描述不能有歧义，描述一定要全 面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理 解。可以通过评审，用大家的力量来避免这种情况发生 e ) 需求报告的每个关乎功能的描述都要让客户明白和理解，客 户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互 相推托责任纠缠不清的情况。 f ) 需求报告一定要经过一个有技术人员和业务人员参加的评 审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能 的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不 完善的、遗漏的等等问题 对于可靠性项目初期需求，一个最有效的手段就是通过调查问卷 的形式来确定。当时项目小组设计了多份调查问卷，从用户信息系统 建设现状、可靠性工作的专业需求等几个方面进行了大范围详尽的调 查，以下是其中的调查问卷( 表2 一1 ) ： 该调查涉及全国6 0 多家电力生产单位，在1 个多月的时间内得 到了大量珍贵的数据，摸清目前电力系统信息网络建设的现状，同时 就当时的可靠性专业需求作了初步的定义。 下面为经过项目小组总结后的问卷反馈信息( 表2 2 ) ： 由此可以看出开发需求阶段的主要目的，是确定项目明确的目标 和清晰的范围，并通过提高企业高层的认识，强化企业对项目的支持 力度。同时通过调查工作可以与用户建立初步的关系。为以后项目顺 利实施打下良好的人际关系基础。在项目实施过程中，如何得到企业 高层的承诺和支持，往往是信息主管和项目经理最为关注的。高层对 技术的商业价值的理解，是项目负责人后继运作的关键基础之一。特 别是电力系统m i s 系统的建设，高层领导的支持甚至成为项目成败 的因素。如果不能很好的解决这个问题，项目将面临包括企业对风险 的承担能力有限、项目投资和其它资源保障存在困难等问题。 1 2 鏊壁婴旦要垄塑墨堕篁里 表2 1 ：可靠性项目初期需求的调查表 输变咆设膪可靠性管理信息系统软件( 网络版) 调研问卷 一、系统软硬件调研 】) 您所处的单位是否有自己的局域舟? 口已拥有口还没有口正在组建 2 ) 您所处的单位同上级单位的网络连接情况是： 口电力广域对连接 口i n t e 胍t 连接 3 ) 您所在单位是否有独立的大型数据库服务器? ( 如果没有请越过下面三个问题 口已拥有口还没有口正在组建 4 ) 您所在单位的大型数据库服务器的硬件配置情况是： 口小型机 口多c p u 服务器口普通p c 机 口其他( 请写出具体配置) 5 ) 您所在单位的大型数据库服务器所采用的数据库系统是： 口s y 队s e 口o r a c l e 口d b 2ds o ls e r v e r 口其他( 请写出具体名称) 一 二、输变电功能调研 1 “两络版”在开发中准备可以进行多用户录入，方法有二：一是多个用户同时录入数据， 如几个人同时录入设施运行数据等；二是按照岗位职责的不同，进行不同的录入，如可靠性 专工和线路工区、变电工区的人分别完成运行事件的部分录入工作量对于上述两种方案， 您认为哪一种更需要，还是都不需要或者都需要? 2 原软件的注册功能是否方便7 ! ! 室奎望奎堂堡主堂堡垒壅 输变电设施类型 是否方便原因 一般设施 口是口否 全封 i j 组合电器内元件 口是口否 全封闭组台电嚣 口是口否 电缆线路、架空线路口是口否 新路器口是口否 3 ，对原软件线路合并部分是否满意? 有何建议? 4 您对数据注册部分有什么新的想法? 原因是? 5 原软件的运行登记功能是否方便? 输变电设施类型 是否方便原因 一般设施口是口否 全封闭组合电器内元件口是口否 全封闭组合电器口是口否 表2 2 ：调查问卷的反馈信息 i 输变电设施类型 是否需要增加参数 需要增加的参数 架空线路是 7 1 与设备铭牌参数相一致 否4 02 增加线路改造日期因为新变电所在老 线路上开口接入( 或改道) 肘，线路长 度往往有变化，考虑增加长度不是很大， 因此一般开口后的两条线投运日期不 变 1 4 软件项目开发的风险管理 电缆线路是 61 电缆终端头型号、电缆中间接头个数、 否3 5 型号 阻波器是 41 额定电感，阻抗、热稳定时间、热稳定 否5 4 电流、动稳定电流、爬电比距 耦合电容器是 4l 上节电容量、下节电容量、爬电比矩 否5 0 避雷器是 4l ， 1 m 耐压 否5 32 工频放电电压、节敛、灭弧电感、爬电 比距，在线监测仪 3 2 3 项目实旌过程中的变动需求的管理 项目实施过程中的需求的变化问题是每个开发人员、每个项目经 理都遇到的问题，也是最头痛的问题，一旦发生了需求变化， 不得 不来修改设计、重写代码、修改测试用例、调整项目计划等等，需 求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，使 需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按 照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般 不是突发的革命性的变化，最常见的是项目需求的渐变( p r o j e c t s c o p ec r e e p ) 问题，这种渐变很可能是客户与开发方都没有意识到 的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了 一番天地。 随着项目的进展，软件的框架已经建立，原始的初步的需求已经 转化为可以看见的软件内容，用户已经可以看到软件的雏形，双方已 经建立起了一定的较为顺畅的沟通渠道和沟通方式，用户和项目小组 开始成熟，此时用户可能发现软件所表现的方式或者是实现的功能并 非预期想象，对于前面所提的需求出现了变化，这种改动可能是很小 的或者是局部的变化，然而对项目小组来讲麻烦才刚刚开始。 可靠性项目自2 0 0 1 年到2 0 0 2 年用1 年时间完成产品雏形后，项 北京交通大学硕士学位论文 目实施过程中需求变动长达两年的时间，在这两年中新的需求不断出 现，双方不得不定期召开技术交流会以确定新的需求内容是否合理， 原有程序是否需要重做。对于双方都是一个很痛苦的过程。 根据本项目的经验，变动后的需求确认通过技术交流会是最为有效的 手段，会上双方可以做充分的交流，会议所商定的内容以双方纪要的 形式予以确认。 以下是本项目一份典型的技术交流会纪要： 2 0 0 3 1 2 2 6 技术交流会议纪要 会议地点：电培中心会议室 与会入员： 可靠性管理中心：蒋锦峰、左晓文、赵凯、陈丽娟、吴字鹏 开发方：张中江、王鲁辛蟛、武兆彪、侯玉启、李庆昌、刘云录 会议内容： 2 0 0 3 年1 2 月2 6r 在电培中心会议室，电力可靠性管理中心与开发方采用 问答的方式，就可靠性管理工作中有关编码原则、结构、内容，可靠性管理规 程等进行了充分的交流，明确了相关部分的具体内容。同时讨论了目前软件当 中存在的闯题，对下一步软件开发工作具有积极意义。( 具体内容见附页) 蒋锦峰主任代表电力可靠性管理中心对开发方就可靠性编码及规程理解 程度表示满意，好于预期。对开发方所付出的辛勤劳动表示慰问，希望开发方 能为了共同的目标做最后的努力。 会议初步定于2 0 0 4 年1 月5 曰，开发方来京将修改后的发电、输变电程 序进行安装测试。 附页 2 0 0 3 一1 2 2 6 会议确认的输变电问题总结 1 、线路注册合并和线路运行合并的方法按以裁的方法处理。 2 、设备跟踪问题按以前的方法处理。 3 、厂家编码要针对第三位进行处理，可以方便用户选择各类厂家。 4 、现在对企业代码的理解和处理是正确的。 5 、在综合分析中，增加按责任原因编码后两位的分析。 6 、同一安装位置上的要退出设备的退出日期和将投运设备的授运日期必须是同一 软件项目开发的风险管理 7 、改事件录入中时间的方式，使终止时间可以录入2 4 ：0 0 点。 3 2 4 受需求变动影响的方面 程序本身的变化，有时可能只需要对局部进行修改，也有最糟的 结果，虽然对用户看起来是很小的需求变动然丽程序来讲可能要做结 构上的调整，这对于整个项耳小组来讲无疑是场器梦。 程序员心理的变化，小的修改不会引起反感，但是对于有一定工 作置的修改工作，并非每个人都能泰然接受。以前的工作程序员都是 倾注了心血，此时由于并非自身原因而导致的否定甚至重来多少会引 起不愉快的情绪。他们会归咎于用户。如果不能正确的处理，会引起 项目小组成员与用户间的摩擦，导致双方在沟通上产生不必要的障 碍。 用户的变化，随着用户的逐渐成熟，对于软件的具体要求也越来 越清晰，此时不单是对原有需求的细化，而且对于软件功能提出了新 的更高层次的需求。对软件的未来功能充满了期待，甚至出现了不切 实际的需求。 项目时间的变化，在这个阶段项目的进程可能远远的偏离了原有 的计划。安排好的进度被打破，原来已经完成的工作不得不重来。项 目进程陷入了反复拉锯的状态。 表2 3 ：项目时问计划表 开发阶段起始时间 终止时间阶段性成粟 需求分析阶段 2 0 0 1 7 1 52 0 0 1 9 2 5 需求说明书 总体设计阶段 2 0 0 1 9 2 右2 0 0 i 1 1 1 5 总体设计说明书 详细设计阶段 2 0 0 1 1 1 1 62 0 0 2 1 1 0 详细设计说明书 编码及单元铡试阶段 2 0 0 2 1 ，l l2 0 0 2 3 1 0 软件程序编码及测试 整体测试 2 0 0 2 3 1 12 0 0 2 5 ，1 0 测试方案、测试报告 试运行及完善2 0 d 2 5 1 12 0 。2 】o 3 i最终程序 北京交通大学硕士学位论文 上面的表格是该项目初期的时间计划，而在实际实施中，由于不 断出现的需求变动导致整个项目整整推迟了2 年! 项目成本的变化。由于时间的延期项目成本也将增加，小的修 改可能不需付出太多成本，但是由于这些小的修改项目积累到一定程 度成本增加的数量也可能会是惊人的。 3 2 5 需求变动风险的应对方法 作为项目的管理者应更为瑾性的分析这些风险并且能正确的进 行处理： a 首先需求一定要与投入有必然的联系，否则如果需求变更的成 本由开发方来承担，则项目需求的变更就成为必然了。接受需求变更 目前却是软件开发商不得不接受的结果。所以，在项目的开始无论是 开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。 b 需求的变更要经过用户的书面确认。 需求的变更引起投入的变化，所以要通过用户的认可，这样才会 对需求的变更有成本的概念，能够慎重地对待需求的变更。 c 小的需求变更也要经过正规的需求管理流程。 小的需求变更也要经过正规的需求管理流程，否则会积少成多。 人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降 低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可 控，最终导致项目的失败。召开技术交流会是一种不错的选择。 d 精确的需求与范围定义并不会阻止需求的变更。 并非对需求定义的越细，越能避免需求的渐变，这是2 个层面的 问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是 永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。 实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需 求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不 愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需 求，他们的目的可能是使软件做的更精致。于是作为需求管理者、项 目经理需要采用各种沟通技巧来使项目的各方各得其所。 软件项目开发的风险管理 基于上述的问题，必须对需求进行管理，使需求自b 够真正成为软 件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持 一致，使需求可以复用。 3 ，3 技术风险 主要的技术风险来自两个方面 3 3 1 来自当前时期的技术条件的风险 当前时期的技术条件包括了技术发展速度和主流技术的发展方 向。由于目前信息系统无论在硬件还是软件上都处于一个飞速发展的 时期，从3 8 6 5 8 6 只用了短短几年的时间，并且正在按照摩尔定律不 断发展，软件水平的提高更为引人注意，操作系统的更迭、网络技术 的广泛应用、数据库类型的多样化使得软件开发人员知识老化率不断 升高。以往技术不能实现的结果，新技术轻易就可变为现实。这些变 化往往是用户需求改变的重要因素。技术风险成为软件开发中重要的 风险因素。包括：潜在地设计、实现、接口、验证和维护等方面的问 题。 选择开发工具，对未来技术的发展走势的判断的不确定性、陈旧 的技术、以及“过于先进”的技术也是风险因素。人们总是认为在 技术开发中要采用先进的技术，然而在实际的项目实施中往往采用的 是较为成熟的技术，先进的技术本身存在着教大的风险，主要有：是 否是主流技术? 稳定性如何? 市场接受能力如何? 是否代表了未来 技术的发展趋势? 等等。 下面的风险检查表中的条目标识了与建造的技术相关的常见风 险： 该技术对于公司而言是否是新的尝试。 客户的需求是否需要创建新的算法或输入、输出技术； 待开发的软件是否需要使用新的或未经证实的硬件接口； 待开发的软件是否需要与开发商提供的未经证实的软件产 北京交通大学硕士学位论文 品接口； 待开发的软件是否需要与功能和性能均未在本领域得到证 实的数据库系统接口； 产品的需求是否要求采用特定的用户界面； 产品的需求中是否要求开发某些程序构件，这些构件与你 的公司以前开发的构件完全不同； 需求中是否要求采用新的分析、设计、测试方法； 需求中是否要求使用非传统的软件开发方法： 需求中是否有过分的对产品的性能约束； 客户能确定所要求的功能是否可行? 3 3 ，2 技术使用者自身的素质和对未来发展的判断 除了软件技术的飞速发展外经历丰富员工也是重要的技术风险 之一，如果没有经验丰富编程技巧高超的程序员，项目团队可能会因 为技术的原因影响项目的成功。程序员实际的技术水平，对新技术 的适应能力，开发人员的技术偏好特别是对于一个长期项目，在一年 中所出现的新技术和新的编程工具对软件的开发有着较大的影响。本 项目经历3 年的时间，期间由于技术人员的问题直接影响到项目的实 施，另一个值得重视的因素是程序员可能热衷于挑战突破技术的极限 而把整个项目引入歧途。 在这个项目中，为了避免这类问题的发生，在开发前期作了大量 的调查，研讨。尽量的减少了由于程序员个人因素造成的项目整体方 向的偏差。 下面为当时项目小组对于开发工具的选择的权衡： 我们在可靠性项目中开发工具的选择 3