（机械设计及理论专业论文）基于cmm的中小软件企业软件开发管理方法探讨.pdf

iii april, 2004 摘 要 中小软件企业是构成我国软件产业的主体部分其发展和进步对我国信息化 产业的进展有着重要意义本文结合实践探讨了将 cmm 理论应用到中小软件 企业软件开发管理过程的方法和实施手段 文章基于两个 mis 项目实例对其开发管理方法进行深入探讨并由此延伸 到应用软件系统的开发管理文章主要针对需求管理项目策划项目跟踪和监 控以及项目总结进行详细阐述并对本文提出的项目管理模式中的配置管理进行 了展望 需求管理是 cmm 中的首个关键过程域在实践中将需求管理分为需求开发 和需求管理需求开发包括需求分析验证是项目开始时的主要环节而需求 管理是对需求和需求开发过程的全程管理贯串整个项目生命周期软件需求分 为业务规则和软件质量性需求二者构成了客户对产品的最终需求需求管理将 围绕这两种需求的获取和实现展开 项目策划勾画了需求转化为产品的蓝图其主要活动包括软件开发过程定义 项目工作任务拆分项目进度安排和风险管理项目控制过程是本文提出的项目 跟踪和监控的实践模式其基本思想是通过对项目基本数据的收集分析来提高项 目的可视性和可控性利用动态的数据分析控制决策保证项目被控规范地运 行 项目总结是中小软件企业软件项目管理中重要过程项目总结是企业得以持 续发展的重要活动目的是获得项目知识建立企业的项目资源库 关键词中小企业 软件能力成熟度 cmm 项目管理 软件开发 iv abstract as principal parts of information industry, small and medium-sized software- enterprises development and improvement improve significant for progress of the information industry of our country. combining practice, this paper probe into the method and implementation means which is getting in cmm theory and used in the small and medium-sized software-enterprise. based on the example of two mis projects, this paper probes into the method for development and management of mis system. and the method is extended to the application software system. this article mainly focuses on and explains in detail the software requirement management, software project planning, software project trace and oversight and project summarizing. the software requirement management (srm) is the first key process area (kpa) in the cmm. srm is divided into requirement development and requirement managing in practice. requirement development including requirement analysis and verify is the key link when project begins. requirement managing is focus on the requirement and process of requirement development, which run through the life period of whole project. software requirement consist of business rule and the quality requirement of software, which is the ultimate requirement that customers desire to the product. requirement management will evolve around how to obtain and realize these two kinds of requirements. software project planning (spp) delineating the blueprint of how the requirement turn into the products, which activity mainly including software development course define, project work breakdown structure (wbs), project schedule and risk management. the project controlling course (pcc) is one practice mode of software project trace and oversight spto be advanced in this article. the conception of pcc in essence is to v improve the controllability and visualization of the project by the means of collecting and analyzing the project data and to ensure the project to be running and controlling on the course by means of dynamic analysis of data and decision-making of controlling. the project summarization is the important activity to ensure an enterprise can develop continuously, the purpose is to obtain project knowledge and set up the project resources bank in the enterprise. key words: small and medium-sized enterprise capability maturity model for software cmm project management software development 1 1 绪 论 1.1 研究背景及动机 自上个世纪 90 年代以来软件工程不仅从方法论的角度为管理人员和开发人 员提供了可见的结构和有序的思考方式而且从大量的成功软件开发项目中总结 出了众多的宝贵设计经验同时随着计算机硬件和网络技术的发展以及企业 数字化的深层次需求软件开发的规模和周期呈不断扩大愈趋复杂之势在这 种背景下国际上软件工程方法与开发技术的研究方兴未艾最为典型瞩目的 成果就是美国卡耐基.梅隆大学以watts humphrey 为首的cmm capability maturity model for software软件能力成熟度模型课题组于 1987 年提出并不断得到实 践修订的 cmm 理论如今cmm 被越来越多的软件组织所采用并取得了可 喜的成效cmm 在各国软件行业已产生了巨大的影响123 国内自 1998 年航天部门首次引进 cmm 实施以来已有近 200 家软件企业和 机构先后通过了 cmm 评估认证最高级别高达 cmm5而且参与的企业数每年 呈上升趋势3实践表明实施 cmm 对软件企业或机构的软件项目管理起到了极 大的促进作用通过实施 cmm 过程评估软件企业可以清楚地知道自身管理上 的优势和弱点进而改进自身的管理方法 作为目前国际上最实用的软件生产过程标准和软件企业成熟度等级认证标 准cmm 能帮助软件企业改进和优化管理实现软件生产工程化但是 cmm 提 供的实践指南是以美国大型软件项目为基础的在国内中小软件企业中可操作性 的研究尚无成熟的理论体系同时软件企业实施 cmm 是需要投入较大数量的 人力资金等资源通过 cmm 认证的企业一般都具有较大规模资金相对充裕 目前在我国中小企业中,cmm 的实施和应用并不普及中小型软件企业如何借鉴 cmm 的理论和经验来提升项目管理水平是一个值得深入研究的课题同时 cmm 作为评估承包商软件工程能力的一种方法也可以作为企业评估自身软件开 2 发能力的一种手段24 1.2 研究对象及现状 本文基于笔者在多家中小型软件企业的实践经验以及在校课题项目的实践工 作展开的研究的对象为中小型软件企业中进行的软件项目研究的目的在于探 讨基于 cmm 的适合中小型软件企业的项目开发管理方法 专业 it调查机构赛迪资讯的数据表明我国软件产业以中小企业为主50 人以下的企业占 55%左右50200 人的企业占 42%左右1000 人以上的仅有北 大方正和中软总公司东软软件集团用友软件集团等十几家公司 7本文中 中小软件企业的定义是人数在 100 人以下企业依靠软件项目获取利润而得到生 存发展这些企业的项目开发普遍存在管理水平较低自有核心技术较弱容易 受人力资源和资金水平的制约等问题 在中小型软件企业中业务项目主要集中在应用软件上涉及金融政府 电信等众多的领域根据赛迪资讯的统计数据在应用软件项目中一般 oa 办 公企业信息系统等 mismanagement information system 管理信息系统项目占 大部分比例由于 mis 系统的发展过程和开发方法具有很强的代表性因此本文 的分析是基于 mis 系统实例展开 mis 是一个由人计算机通讯设备及网络等组成的进行管理信息的收集 传递储存加工维护和使用实现辅助一个企业的事务处理和管理职能的系 统4由此可以看出 mis 系统的基本特点就是 1mis 系统是一个人机系统其实质是一个使得管理信息在人和计算机之间 交互和处理的系统 2mis 系统是以管理信息为核心为管理服务的系统管理信息是系统运行 的基础和最终输出 3管理模式和方法对系统起着决定性作用一个 mis 系统往往只能适应特定 的管理模式和组织管理与信息在系统中相互依存不可或缺 3 4人的因素是系统能否健全运行和推广的决定因素系统的适应性和易用性 可能最终影响系统是否按照期望的目标产生经济效益和实际收益 mis 系统按照信息对象来分类可以划分为三个不同层次由于管理活动可分 为战略计划管理控制业务处理因此可以按照信息的服务对象将 mis 系统划 分战略计划级管理控制级和业务处理级其关系如图 1-1 所示 图 1-1 mis 系统层次图 由图 1-1 可以看出不同层次的 mis 系统存在一定程度的依赖关系同时又组 合成一个整体系统自下而上的过程也是 mis 系统不断发展和深入应用的历史过 程将本文中的 mis 概念扩展延伸到 mrperpurp 等相关系统讨论的范围 涵盖了所有应用到企业运营管理各个方面的应用软件系统在中小软件企业的项 目中具有极大的代表性同时 mis 系统作为国内应用行业广泛系统数量众多并 且将会继续大规模开发应用的软件系统研究总结其开发管理方法具有较强的可 行性和重要的现实意义 1.3 研究方法及实例 软件开发过程的研究涵盖管理学心理学系统过程理论等多个方面的内容 我们可以将其分为产品工程层面和管理工程层面本文将从软件过程这一管理 层面的角度探索适合国内实际情况的软件开发管理方法采用实例分析和项 目回溯的方法对软件开发过程的规划和管理进行了分析探讨 本论文主要涉及两个中重量级的 mis 系统开发研究课题武汉市度量衡管理 所计量 mis 系统项目与广东省新会市电力工业局电力信息系统项目从项目管理 的角度对这些课题进行回溯与研究并总结其相应的开发管理方法 业务信息系统 功能信息系统 决策支 持系统 4 武汉市度量衡管理所计量 mis 系统以下简称计量信息系统是由华中科技 大学机械科学与工程学院与武汉市度量衡管理所合作开发的一套计量信息系统 属于 mis 系统层次中的业务信息系统武汉市度量衡管理所是武汉市质量技术监 督局直属的法定计量检定机构依法对武汉地区的相关计量器具进行量值传递 执行强制检定和其他测试任务为实施计量监督管理提供相应的技术保证开发 计量 mis 系统的目标就是为了进一步提高武汉地区的计量工作水平采用先进的 计算机技术和网络技术通过 mis 系统加强自身的业务管理为广大客户提供便 捷丰富的信息查询服务为众多企业提供良好的质量保证和完善的检定服务该 项目开发维护从 2002 年持续到 2003 年 6 月开发工作量约 12 人月包括两个子 系统计量业务信息管理系统计量信息公众服务系统分别面向不同的用户提 供业务管理和信息查询服务 广东省新会市电力工业局电力信息系统以下简称电力信息系统属于 mis 系统层次中的功能信息系统并初步具有企业决策支持系统的特点该项目从 1996 年开始由机械学院工业设计实验室和广东省新会电力工业局合作先后开发了 广东省新会电力工业局 intranet/mis 系统所包含的系列子系统该项目分软件 和硬件两大部分其中硬件部分包括综合布线和计算机设备软件分两个阶段实 施开发工作量约 40 人年开发有电力局 internet 网站和 16 个子系统变电设备 管理系统线路管理系统人事劳资管理系统领导查询信息系统物资管理信 息系统 工程管理信息系统 用电与经营管理信息系统 电网实时监测 scada 供电 gis/mis 系统 城区所用电设备检查管理系统 10kv 线路设备管理信息系统 汽车服务公司管理系统计划生育管理信息系统消防保卫管理信息系统招待 所管理信息系统 qc 管理信息系统等 本系统中子系统的开发管理方法不尽一致 依据各自特色采用了不同的方法为本文提供了丰富的实践基础 1.4 课题内容及论文的主要工作 本课题是结合两个实际项目进行的笔者在实际项目中运用相关理论知识做 5 了大量的工作并在实践中验证理论知识提出了本文的观点进而做更深层次 的探讨笔者参与课题中的主要工作内容包括以下几个方面 1项目策划 计量信息系统的项目立项后就开始了项目规划工作主要涉及项目评估项 目所需技术设备人员安排以及资源分配等前期工作 2系统分析与需求分析 计量信息系统项目的系统分析是在武汉市度量衡管理所有关领导的支持下 在多次直接同目标用户交流并详细分析有关业务文档数据资料和业务管理方 法的过程中完成系统分析的目标是充分论证项目的可行性效益成本并形成了 一系列开发支持文档包括系统总体说明书数据流程说明书业务流程说明 系统概要设计说明和模块数据结构说明同时在与目标用户充分交流的基础上 结合其实际的业务管理方法形成规范的组织管理架构描叙文档建立合 适的信息 沟通机制在系统分析过程中还必须充分考虑单位的外部因素包括计量行业 通常的业务特点以及计量行业的信息化建设程度在综合内外因素后拟定系统的 技术方案并估算系统开发的成本以及时间 笔者的开发团队在充分考虑武汉市度量衡管理所的软硬件环境后对其系统 需求进行分析论证并利用系统原型同用户交流深化需求引导用户进一步发掘其 未来的潜在需求最终形成完善的需求说明书并建立需求变更管理机制需求调 查与分析是一个比较长期的双方交流过程和对目标系统的深入认知过程该过程 实际上贯彻到项目的整个实施阶段笔者在项目开发管理过程中建立良好的需求 变更管理机制这段工作为本文第 2 章的观点提供了实践基础 需求调查与系统分析是双方沟通的结果充分考虑了双方的实际情况在协 调的基础上形成双方都认同的项目开发方案并建立了相应的文档 3系统实施 系统实施是在系统分析及需求分析的基础上进行系统的开发包括系统的概 要设计详细设计数据库结构设计以及系统编码测试等工作计量信息系统 的计量业务信息管理系统包括计量检定管理计量检验管理计量标准管理计 6 量人员管理设备资产管理等五个主要功能模块其网络架构采用 c/s 模式 client/server 客户端/服务器模式前台开发环境应用 visual basic6.0开发平台 后台数据库系统采用微软的 ms sql server 7.0 数据库管理系统计量信息公众服 务系统是基于 internet 的多层架构系统主要采用 jsp/servletejb 等技术实现 运行平台为 j2ee 开发运行环境并使用应用服务器 bea weblogic7.0利用 ms sql server 数据库管理系统与计量业务信息管理系统实现数据共享 系统的数据库运行在 ms sql server 数据库管理系统dbms上共设计了 39 个库表基本涵盖计量业务所需的业务数据构建了其业务逻辑 4系统维护 系统维护工作主要包括人员培训以及与系统相关的数据维护处理同时对系 统的运行提供足够的技术支持针对武汉市度量衡管理所的业务变化情况对系 统做相应的小范围调整 5项目回溯与总结 项目回溯工作包括整理计量信息系统和电力企业系统的相关文档并对两个 项目的项目过程进行回溯评审电力信息系统已经在广东省新会市电力工业局运 行多年期间计算机以及网络技术已经发生了巨大变化同时企业的发展也对自 身信息化建设的状况提出了更高的要求该项目周期较长涉及的内外部环境变 化比较明显给项目管理与开发方法提出很高的要求回溯该项目的整个过程对 于改进软件开发方法和项目管理方法具有很大的研究价值该项目也很好的反映 了 mis 系统的发展过程和不同阶段的特点同时该项目开发期间出现的一些问题 和经验为计量信息系统的开发起到了良好的辅助参考作用 计量信息系统是一个借鉴了 cmm 模型思想进行软件开发管理的项目它的 成功实施对于项目管理方法的研究和探讨有明显的实践意义相比电力信息系统 可以比较全面地反映了不同层次 mis 系统的项目开发管理方法 7 2 需求管理 2.1 基于cmm的需求管理模型 2.1.1 cmm需求管理模型 在 cmm 模型中 需求管理 spp software requirement manager 是 2 级 cmm level 2中的第一个关键过程域kpa key process area按照 cmm 要求可以 将 kpa 的结构模型化下图 2-1 所示 srp 的目标有两个 1目标1 分配给软件的系统需求是受控的建立供软件工程和管理使用的基 线 2目标2 软件计划产品和活动与分配给软件的系统需求保持一致36 srp的执行约定是项目遵循一书面的 组织上的方针去管理分配给软件的系统 需求 srp的执行能力包括4项能力主要针对企业对需求的获取与管理提出的能 力中还包含一系列活动和验证方法 关键域 kpa 能 力 执 行 约 定 执 行 能 力 图 2-1 kpa 结构图 目 标 8 2.1.2 应用需求管理模型 需求管理是指充分理解客户对软件产品的已知需求和预期需求并在项目过程 中对客户需求进行管理的过程需求管理的目的是在顾客和将处理顾客需求的软 件项目之间建立对顾客需求的共同理解7912因此该模型在实践时将围绕其两个 目标分解出多个过程和活动并且贯穿于项目的整个生命周期 客户需求是指软件客户或产品用户对项目最终产品的期望和要求包括产品 目的产品功能产品质量技术资源运行环境以及开发成本和开发时间等要 素6客户需求可以分为技术性需求和非技术需求例如产品交付日期交付方 式等获取客户需求并将其纳入项目的管理控制中将达到目标1在项目周期的 不同阶段可以追溯客户需求的内容可实现目标2因此需求管理模型实际可以用 下列过程和活动说明 1客户需求分析 主要包括同客户沟通获取需求确认需求并文档化等活动 2软件需求分析 根据文档化的客户需求进而分析软件系统的需求其实质是客户需求的细 化系统化活动包括系统分析需求项定义等 3需求变更管理 包括需求发生变更时对需求的控制管理和跟踪活动 4客户需求追溯 在产品中根据其功能检查需求项是否被涵盖即可以依据功能找到需求也 可以根据需求检查功能 在上面的过程中模型的执行约定执行能力将会在实践中得到验证和体现 具体的需求管理过程实际是由软件组织按照cmm的要求自行定义的 因此 cmm 中需求管理kpa只是为实践指明了对软件需求管理是否达到一定标准的检查点和 评估内容这些检查点同样可以被中小企业应用到实际的项目开发管理中为项 目的需求过程提供指南 9 2.2 中小软件企业的应用模式 2.2.1 概述 在国内多数中小软件企业软件项目中需求管理没有建立一套完整的方法和 过程项目凭借项目成员的个人能力卡车因子track actor比例太重17由于 企业要应对较大的生存压力人员安排上存在多个角色重叠各方面的资源不能 到位的现象鉴于这样的情况要想企业完全按照 cmm 的规定来执行管理流程 绝非易事但按照 cmm 理论对需求管理过程进行定义和检查会起到很好的效 果本节将对如何在中小软件企业项目的需求工作中应用 cmm 模型的思想进行 阐述由于中小软件赖以生存发展的项目绝大部分是应用软件因此这部分的阐 述将基于 mis 系统展开 需求管理过程是一个能动的变化的系统进程它始终贯串到整个项目周期 的各个任务阶段软件工程师抱怨客户需求总是不断变化需求没有明确定义而 无法管理好软件的系统需求那是因为没有把我把握需求管理的本质对于本文 中的实例而言其系统需求随着技术的发展和客户公司业务改革进程而不断调整 如何管理这种动态的变化就是需求管理工作必须面对的问题同时mis 系统 中往往蕴涵了管理思想和管理实践的基本因素对在不断发展的企业而言国家 政策产品市场人员安排等内外部环境因素必然在不断的改变这种变化带来 了对 mis 系统需求的变化这样的变化将在项目的各个阶段发生需求管理就是 要管理这种变化 本文提出将需求管理过程分解为需求开发需求验证和需求变更管理三个基本项 目子过程为cmm需求管理kpa 在中小软件企业中的应用提供了一个实践模式 将客户沟通需求获取需求分析系统分析等活动的集合定义为需求开发 该过程的典型出口就是客户需求说明书和软件系统需求分析报告 需求验证是指对项目计划活动中对需求的追溯检验的一系列活动其出 口包括需求状态跟踪表需求追溯表 10 需求变更管理主要是指围绕需求变更的处理方法和管理活动出口包括需求 变更申请表已被批准变更引起的后续活动已被明确 2.2.2 需求开发 需求开发是指对一个软件项目需求的获取分析文档化和评审的过程是 对业务规则的发现定义验证和描述的过程同时也是开发人员与客户对业务 规则在产品中的表达形式的共同理解过程需求开发是一个基础过程涉及客户 和软件需求开发人员的很多方面使得该过程具有很强的复杂性和重要性需求 获取分析编写需求规格说明和验证并不遵循线性的顺序这些活动是相互隔 开增量和反复的需求分析人员与客户沟通合作过程中客户将会提出关于目 标系统的问题需求分析人员必须回答这些问题并取得客户所提供的信息需求 获取同时需求分析人员将处理这些信息以理解它们并把它们分成不同的 类别还要把客户需求同可能的软件需求相联系分析然后分析人员可以 使客户信息结构化并编写成文档和示意图说明下一步就可以让客户代 表评审文档并纠正存在的错误验证这四个过程贯穿着需求开发的整个阶段 在中小软件企业中项目以应用型的mis软件项目为主因此其需求开发过程 将围绕业务规则和客户的质量性需求进行为了在产品解决方案和问题之间达成 一致理解需求开发过程是一个往复的迭代过程需求分析将会伴随在项目其他 阶段具体模型可以用下图2-2说明 图2-2需求开发过程模型 业务规则 质量属性 需求获取 需求分析 需求定义 需求验证 需求文档 需求基线 11 从图中可以看出客户对产品的需求可以分为功能性需求业务规则质量 性需求质量属性两者的分析处理办法存在差别功能性需求侧重于业务规则 的发现和定义通常是显式的需求可以精确定义验证能方便地借助专门工具 进行分析处理质量性需求则是关于业务规则在产品中表现形式和表现结果的需 求定义很难利用辅助工具进行定义描述必须根据分析人员开发人员和客户 的沟通结果进行反复定义验证基于项目的实际经验和 mis 系统的特征本文 将重点讲述质量性需求的分析定义的思想方法 功能性需求指软件产品必须具有能够完成某种业务或处理客户事务的功能 客户利用该软件产品将获得一系列的功能功能性需求同客户业务紧密联系往 往带有很强的行业特征例如电力公司要求为其开发的电力 mis 系统必须具有管 理电力设备计量电能等功能以替代以往的手工数据操作这些功能需求又同 单位组织架构业务流程等紧密联系这类功能的获取与分析工作要求开发人员 能够深入了解客户的业务运作熟悉客户单位的管理模式并能对行业有所了解 更高的要求是开发方必须在新的系统采用先进的管理思想帮助客户改善其业务 因此在业界流行的开发合作模式是软件开发方与专业的咨询公司一起为产品进 行功能性需求分析这种模式是适应大型的企业信息系统开发需求而来可以充 分发挥各自的优势取长补短对于中小型软件项目产品的功能性需求分析有 客户方与分析开发人员共同合作完成主要依赖于分析人员的能力和客户对问题 的认知程度和描述能力 产品的质量性需求是指客户对产品的易用性执行速度可靠性稳定性等 方面的问题和需求这些问题和要求都可以用软件质量来概括因此也称为产品 的质量性属性客户除了要求软件产品能够处理业务外通常还会表达对系统的 运行速度出现异常后的处理方式操作的简便性等特征的期望这些质量性需 求是很难定义的并且它们经常造成开发者设计的产品和客户满意的产品之间的 差异就像robert charette(1990)指出的那样真正的现实系统中在决定系统 的成功或失败的因素中满足非功能需求往往比满足功能需求更为重要优秀 的软件产品反映了这些竞争性质量特性的优化平衡如果分析者在需求的获取阶 12 段不去探索客户对质量的期望而产品满足了他们的要求这只是幸运的表现 但更多的可能是客户失望和开发者沮丧216用户对产品质量性需求的描述是感性 的模糊的不同类型的用户对产品质量性要求认知程度不同分析人员在获取 质量性需求时往往感到无从是可其实不管用户提出怎样的问题和要求产品 的质量性属性可以按照图2-1所示特征进行分类描述图2-3展示产品质量性需求特 征的范围和关注者 图 2-3 产品质量属性特征分类示意图 产品的不同部分与所期望的质量特性有着不同的组合高效性可能对某些部 分是很重要的而可用性对其它部分则很重要应用于整个产品的质量特性与特 定某些部分某些用户类或特殊使用环境的质量属性要区分开2本文强调应重视 获取客户对产品的质量性需求在项目实践中可以按照上述内容对客户需求进行 检验避免遗漏忽略 需求获取的目的是更好地理解客户当前和预期的问题和需求在需求开发中 让客户或用户充分参与到软件项目中是一种行之有效的办法这各方人员具备良 好的合作方式和沟通能力获取需求的方法因人而异可以采取多样的需求分析 方法和技术关键是必须描述清楚用户的业务规则客观要求获取的需求必须 翔实形成文档并可验证力求全面清晰 需求获取是在问题及其最终解决方案之间架设桥梁的第一步获取需求的一 有效性a v a i l a b i l i t y 高效性( e f f i c i e n c y ) 灵活性( f l e x i b i l i t y ) 完整性( i n t e g r i t y ) 可靠性( r e l i a b i l i t y ) 互操作性( i n t e r o p e r a b i l i t y ) 健壮性( r o b u s t n e s s ) 易用性( u s a b i l i t y ) 用户关注 开发者关注 可维护性 ( m a i n t a i n a b i l i t y ) 可移植性 ( p o r t a b i l i t y ) 可重用性 ( r e u s a b i l i t y ) 可测试性 ( t e s t a b i l i t y ) 13 个必不可少的结果是对项目中描述的客户需求的普遍理解一旦理解了需求分 析者开发者和客户就能探索出描述这些需求的多种解决方案参与需求获取者 只有在他们理解了问题之后才能开始设计系统否则对需求定义的任何改动都 会造成设计上的大量返工把需求获取集中在用户任务上而不是集中在用户接 口上有助于防止开发组由于草率处理设计问题而造成的失误 2.2.3 需求验证 需求验证的目的是决定开发的产品是否能够完成开始时所确定的需求检查 产品是否能够完成要求的任务需求验证包括对需求分析报告的评审与确认对 需求实例的测试和评估以及其他面向用户的需求定义活动例如在计量管理信息 系统中用户界面需求的验证是通过界面原型演示来验证不同用户对界面的需求 而界面需求性的提出是建立在可验证的基础上的就是说我们能够根据需求而 通过设定某种检验标准对最终产品进行评估并给出或是或非的唯一回答 需求验证在需求开发乃至整个项目管理中的作用是多方面的需求验证工作 的完成时间结果好坏将影响需求管理的整个过程并对项目进度软件质量项 目成本等起制约作用主要体现在下面几点 1及早地验证客户需求是控制需求风险的主要手段例如在计量管理信息 系统中对检验业务的需求确认使我们及时发现了理解的偏差避免了在开发后 期对系统大范围更改 2通过需求验证降低需求的不确定性需求验证的过程也是客户发现潜在 需求和更正自身理解偏差的过程 3需求验证可以反映开发人员与客户之间对系统的理解的一致性要求需求 理解必须通过迭代最终达成一致 4审查文档中存在二义性表述模糊的地方使需求规格说明书清晰明确 5需求验证是建立需求基线和确定产品目标的必要前提也是同客户决策层 达成一致的必要手段 14 需求验证的工作可以有项目经理开发人员分析人员等角色去完成对于 中小软件企业只要任务清晰责任明确就可以实现 cmm 中对分配需求的控 制目标需求验证的主要工作内容包括 1 审查需求文档 对需求文档进行正式审查是保证软件质量的很有效的方法 组织一个由不同代表如分析人员客户设计人员测试人员组成的小组 对需求规格说明书及相关模型进行仔细的检查另外在需求开发期间所做的非正 式评审也是有所裨益的 2依据需求编写测试用例根据用户需求所要求的产品特性写出黑盒功能测 试用例客户通过使用测试用例以确认是否达到了期望的要求还要从测试用例 追溯回功能需求以确保没有需求被疏忽并且确保所有测试结果与测试用例相一 致同时要使用测试用例来验证需求模型的正确性如对话框图和原型等 3编写用户手册在需求开发早期即可起草一份用户手册用它作为需求规 格说明的参考并辅助需求分析优秀的用户手册要用浅显易懂的语言描述出所有 显式的业务规则对用户可见的功能而辅助需求如质量属性性能需求及对用 户不可见的功能则在需求规格说明书中予以说明 4确定需求基线确定合格的标准让用户描述什么样的产品才算满足他们的 要求和适合他们使用的将合格的测试建立在使用情景描述或使用实例的基础之 上 需求验证工作完成后的需求文档包括需求规格说明书用户手册功能原型 用例和测试实例等内容这些是项目规划的基础数据对项目的进展有着决定性 作用 需求验证的人员配置基本上由客户方用户角色代表决策者高层分析人员 与开发人员组成例如在计量信息系统项目中专门由评审组对产品需求进行 评审任何不符合要求的需求定义和描述都及时得到更正评审组由客户方的主 管书记业务科长开发方的项目负责人组成负责审核需求文档主要检查双 方对产品需求的理解是否一致全面详细参与需求验证的客户方评审人员必 须对产品所依赖的业务规则运行环境以及产品需求矛盾的处理决策有发言权 15 同时对业务细节和质量性需求有完整的把握和理解这样才能真正地验证需求 及时解决其中的问题并对建立的产品需求基线负责需求验证通常需要客户负责 人在需求文档中签字确认这时必须考虑签字的权威性和有效性因为后期一旦 发生需求变更由此引起的矛盾与责任冲突的焦点往往集中在需求验证中正是 因为存在这样的问题需求验证的人员配置就应相当慎重关于需求变更将在需 求变更管理中详细深入讨论 2.2.4 需求变更管理 需求变更管理是贯串整个项目阶段的一个关键过程其主要任务是应用适当 的技术和策略对需求工程的各个活动与作业进行管理控制跟踪针对中小软 件企业的资源和能力本文认为需求管理的具体任务与工作内容可以概括如下 1确定需求变更控制过程确定一个选择分析和决策需求变更的过程所 有的需求变更都应遵循此过程商业化的问题跟踪工具都能支持变更控制过程 2建立变更控制委员会组织一个由项目风险承担者组成的小组作为变更控 制委员会由他们来确定需求变更的内容此变更是否在项目范围内评估它们 并对此评估做出决策并设置实现的优先顺序制定目标版本 3进行需求变更影响分析应评估每项选择的需求变更以确定它对项目计 划安排和其它需求的影响明确与变更相关的任务并评估完成这些任务需要的工 作量通过这些分析将有助于变更控制委员会做出更好的决策影响分析可以提 供对建议的变更的准确理解帮助做出信息量充分的变更批准决策通过对变更 内容的检验确定对现有的系统做出是修改或抛弃的决定或者创建新系统以及 评估每个任务的工作量进行影响分析的能力依赖于跟踪能力数据的质量和完整 性 4跟踪所有受需求变更影响的工作产品当进行需求变更时参照需求跟踪 能力矩阵找到相关的其它需求设计模板源代码和测试用例这些相关部分可 能也需要修改这样能减少因疏忽而不得不变更产品的机会这种变更在变更需 16 求的情况下是必须进行的 5建立需求基准版本和需求控制版本文档确定一个需求基准这是一致性 需求在特定时刻的快照之后的需求变更遵循变更控制过程即可每个版本的需 求规格说明都必须是独立说明以避免将底稿和基准或新旧版本相混淆最好的 办法是使用合适的配置管理工具在版本控制下为需求文档定位 6 维护需求变更的历史记录 记录变更需求文档版本的日期以及所做的变更 原因还包括由谁负责更新和更新的新版本号等版本控制工具能自动完成这些 任务版本控制是管理需求的一个必要方面需求文档的每一个版本必须被统一 确定组内每个成员必须能够得到需求的当前版本必须清楚地将变更写成文档 并及时通知到项目开发所涉及的人员为了尽量减少困惑冲突误传应仅允 许指定的人来更新需求这些策略适用于所有关键项目文档 7跟踪每项需求的状态建立一个数据库其中每一条记录保存一项功能需 求保存每项功能需求的重要属性它包括状态如已推荐的已通过的已实 施的或已验证的这样在任何时候都能得到每个状态类的需求数量示例见本 章最后实例分析 8衡量需求稳定性记录基准需求的数量和每周或每月的变更添加修改 删除数量过多的需求变更是一个报警信号意味着问题并未真正弄清楚项 目范围并未很好地确定下来或是政策变化较大 9使用需求管理工具商业化的需求管理工具能帮助项目组在数据库中存储 不同类型的需求为每个需求项确定属性可跟踪其状态并在需求与其它软件 开发工作产品间建立跟踪能力联系链例如笔者采用 ms excel 工具来记录 上述关于需求管理工作内容的体系框架在中小软件企业的实际项目中可以结 合资源的配置情况进行适当裁剪但是这一过程必须明确清晰最理想的是能 结合企业管理方法形成良好切实可行的制度否则一旦属于卡车因子的人员流 失将给项目和企业带来巨大的损失 17 2.2.5 需求文档 文档是项目同客户项目组内部沟通和交流的重要工具和方法在中小软件 企业中对文档的重视程度不足和开发过程的定义不清使得项目的文档数量和质 量都存在严重问题因此本文在这里将需求文档的内容重要性以及要求专门 作为一节进行详细阐述 需求文档是需求工作的阶段性总结与成果也是伴随整个项目的指导性纲领 文件项目开发的后续工作都是以需求文档的内容为基础展开的广义地讲需 求文档的内容包括需求规格说明书用户手册需求程序文件如 uml 描述文件 数据字典项目词汇表实例测试及测试文件等 需求文档的质量是决定了软件项目的可维护性可控制性的笔者认为一个 管理完善的项目其首要的任务就是建立一套完善的文档管理办法这里的文档包 括项目需求执行监督等各个阶段的文档资料其管理制度对格式内容版 本控制以及变更方法和传播范围做出符合团队情况的约定和限制在项目的后续 阶段开发工作将围绕需求文档展开产品描述解决方案测试等都要求需求 作为基础文档将成为项目内部沟通交流的主要信息源对于人员变化频繁的项 目而言文档是项目得以继续展开的接力棒 在软件业的发展中对需求文档的关注很广泛深入目前应用最广泛的有 国标规范的需求规格说明书供参考同时其单一的文档结构也在实际应用中 暴露了不少问题随着计算机辅助分析工具的大规模使用需求文档的形式也在 不断变化总体来说对需求文档的要求有如下几点 1一致性无二义性 2简洁规范符合约定 3版本控制界限明确 4变更权限与责任定义清晰 5必须由客户评审认可若条件允许最终的需求文档必须符合质量管理小 组的评审意见和管理体系24 18 对需求文档的评审可以采用内部评审与客户评审两种方式目的是在最大范 围内保证需求文档的有效性 由于很多中小软件企业没有专门的质量管理人员因此笔者认为设置一位非 专门的文档管理人员也可以在一定程度上有效管理需求文档但是理想的情况 是设置专门的质量管理人员负责组织需求文档的评审这也是中小软件企业完全 按照 cmm 要求进行项目开发管理所面临的障碍 2.3 实例分析 上述模型是基于电力信息系统的实践提出来的同时在计量信息系统以及笔 者参与的其他类似项目中该模式的思想得到了进一步完善计量信息系统利用上 述思想进行项目管理并获得了成功下面用该实例对上述理论进行细化分析 计量信息系统项目的需求分析过程采用了图2-2模型 在实践中主要有以下步骤 1定义项目的基本视图和总体范围项目立项时就进行了该步的工作 2确定用户类型定义用户角色选择适当的代表并确认客户方的主体负 责人按照度量衡管理所的科室划分每一位科长都充当一种用户角色 3确定需求决策者和他们的决策过程具体做法是通过与武汉度量衡管理所 的业务主管们面对面沟通了解然后整理记录形成文档后确认 4选择项目所用的需求获取技术并建立业务规则模型或实例这里采用的 方法是利用快速原型法核实记录 5运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级 6从用户那里收集质量属性的信息和其它非功能需求 7详细拟订使用实例使其融合到必要的功能需求中 8评审使用实例的描述和功能需求 9根据需要开发分析模型用以澄清需求获取的参与者对需求的理解 10开发并评估用户界面原型并发现定义还未理解的或潜在的需求 11从使用实例中开发出概念测试用例计量信息系统的界面设计需求基本 由此而来 12用测试用例来论证使用实例功能需求分析模型和原型 19 13在继续进行设计和构造系统每一部分之前重复第5到12步 上述工作从 2002 年 3 月项目立项开始持续到 4 月份完成客户需求与系统 分析的大部分工作这期间度量衡管理所根据开发人员提供的系统原型在此 基础提出一些新的功能需求和对质量属性的要求需求的明确过程是典型的迭 代反复过程 广义上过程具体的实施同企业文化需求管理参与人员的能力和素质紧 密相关实施过程中用户和开发人员关注的重点不尽相同用户注重质量性 需求的描述和表达感性因素占很大比例开发人员重视业务规则希望得到 客观显式的信息如果客户与开发人员之间的沟通存在障碍双方都以自己 的角度自己的专业术语进行沟通这就使得大家并不能够很好地就软件需求 达成共识结果导致项目难以成功这样的教训笔者在电力信息系统中得到明 显体会事实上相关统计数据表明在这些不成功的项目中由于需求不清晰 需求不完整等方面的因素占到了 60左右17鉴于上述原因在计量信息系 统中开发人员一开始就投入到客户方业务规则和管理思想的研究上在较短 时间内理解了客户方的意图和面临的问题在第 4 步骤中果断采用了快速原型 法为需求获取工作提供了良好的开端 计量管理信息系统项目需求开发过程中客户参与到项目实践中计量信 息系统项目对 cmm 中需求管理 kpa 的理论进行了必要的裁剪按照本文中的 基本理论进行需求管理在项目中让度量衡管理所的技术人员和决策人充分参 与到需求过程中避免过于急功近利将关注的重点放在业务规则business rule上而忽略其他因素这样做的原因就是因为项目组在实践过程中认识到 实施项目时若无足够的用户参与很容易忽略用户的质量性需求结果系统人 员获得的需求存在片面不完整的问题导致项目在需求阶段隐藏下了巨大的 风险因此该项目在实施过程通过设计系统的原型让用户充分表达其需求 其过程按照图 2-2 的模型多次迭代 分配的需求被充分理解 需求变更所带来了 的不良影响得到了妥善控制和处理使得需求管理过程始终保持了可视可控 的良好秩序同时客户的对系统的要求得到了充分尊重和体现项目组获得 客户方的认可建立了良好的关系下面是计量信息系统的部分质量性需求的 20 记录文档摘要从中可以看出质量性需求的具体体现形式以及计量信息系统的 具体需求 表 2-1 计量信息系统软件需求记录摘选 需求项编号 需求类别 需求描述 登录状态 示例原型编号 qui-title1 界面设计 界 面 主 题 要 活 泼轻松又不失 庄重关键功能 界面设计符合女 性心理要求以 浅色为主 已验证 title1.frm 目录: serverwhdlhextitle1 qui-title2 界面设计 检验管理模块输 入项顺序必须按 照表格 jy-002 设 备登记表的排列 顺序排列 已验证 title2.frm 目录: serverwhdlhextitle2 qui-input 界面设计 所有有输入框的 地方要求已白色 为背景色焦点 所在输入框的背 景色为淡绿色 已