用织梦做网站需不需授权,企业网站开发,做暧暖ox免费网站,建设银行网站-个人业务软件架构之开发管理 第 13 章#xff1a;开发管理13.1 项目的范围、时间与成本13.1.1 项目范围管理13.1.2 项目成本管理13.1.3 项目时间管理 13.2 配置管理与文档管理13.2.1 软件配置管理的概念13.2.2 软件配置管理的解决方案13.2.3 软件文档管理 13.3 软件需求管理13.3.1 需求… 软件架构之开发管理 第 13 章开发管理13.1 项目的范围、时间与成本13.1.1 项目范围管理13.1.2 项目成本管理13.1.3 项目时间管理 13.2 配置管理与文档管理13.2.1 软件配置管理的概念13.2.2 软件配置管理的解决方案13.2.3 软件文档管理 13.3 软件需求管理13.3.1 需求变更13.3.2 需求跟踪 13.4 软件开发的质量与风险13.4.1 软件质量管理13.4.2 项目风险管理 13.6 软件的运行与评价13.7 软件过程改进 第 13 章开发管理
美国国防部曾于 20 世纪 70 年代中期专门针对软件项目失败的原因做了调查。调查结果显示 70%的失败软件项目都是因为管理不善引起的而并不是事先以为的技术实力不够。到了 20 世纪 90 年代据对美国软件工程实施现状的调查显示大约只有 10%的项目尤其是商用软件能够按预先计划的费用和进度交付。因此业界认为影响软件研发项目全局的因素是管理水平而技术只影响局部这就有必要从项目管理的角度去管理软件的开发和运行。
加强项目管理的好处是明显的它可以控制财务成本、提高资源利用率改进客户关系缩短开发时间降低成本提高利润、生产率、产品质量和可靠性完善公司内部协调等。
根据美国项目管理协会的项目管理知识体系可知项目管理是指“在项目活动中运用专门的知识、技能、工具和方法使项目能够实现或超过项目干系人的需要和期望。”一 般的项目管理可以分为范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通 管理、风险管理、采购管理和整体管理 9 个知识领域。对于软件的开发管理来讲软件范围管理、软件进度管理、软件成本管理、软件配置管理属于整体管理、软件质量管理、软件风险管理、开发人员管理属于人力资源管理7 个方面的管理尤为重要软件开发的每个阶段、每个过程都要重视这几个方面的管理。
13.1 项目的范围、时间与成本
项目管理首先要考虑三个约束条件项目范围、时间进度、成本预算。在签订软件开发合同时要明确项目的任务是什么发起人要通过项目获得什么样的产品或服务这属于项目范围的范畴项目需要多长时间进度如何安排这属于时间进度的范畴项目需要花费多少资金来源如何这属于项目成本的范畴。
13.1.1 项目范围管理
所谓项目范围管理包括保证项目顺利完成所需的全部工作过程。其目的是控制项目的全部活动都在需求范围内以确保项目资源的高效利用。它主要包括项目启动、范围计划编制、范围定义、范围核实和范围变更控制 5 个部分的内容。项目启动指批准项目启动或者允许项目进入下一个阶段范围计划编制是将生产项目产品所需进行的项目工作渐进明细和形成文件的过程项目范围定义是把主要的项目可交付成果分解成更小、更易管理的单元以达到如下目的
提高对成本、时间及资源估算的准确性。为绩效测量与控制定义一个基准计划。便于进行明确的职责分配。
正确的范围定义是项目成功的关键。“当范围定义不明确时不可避免的变更会使最终项目成本大大超出预算因为这些不可避免的变更会破坏项目节奏导致返工、增加项目历时、降低生产率和工作人员的士气”。范围核实是项目干系人发起人、客户正式接受项目范围的过程。范围核实需要审查可交付成果和工作结果以确保它们都已经正确圆满地完成。如果项目被提前终止范围核实过程应当对项目完成程度建立文档。范围核实与质量控制是不同的范围核实是有关工作结果的“接收”而质量控制是有关工作结果的正确性。 项目范围变更控制涉及的是
对造成范围变更的因素施加影响以确保这些变更得到一致认可确定范围变更是否已经发生当范围变更发生时对实际变更进行管理。范围变更控制必须与其他控制管理过程进行控制、成本控制和质量控制结合在一起使用才能取得良好的效果。
13.1.2 项目成本管理
所谓项目成本管理是保证在批准预算内完成项目所需要的过程。成本对项目有关各方来说都是非常敏感的问题。因此成本管理在软件项目管理中是一项非常重要的工作。软件项目的成本不仅包括开发成本也包括开发之前立项阶段及软件在运行中的费用。此外操作者的培训费用和项目所使用的各种硬件设施费用也都是整个项目成本的一部分这些成本都需要很好地计划和控制。 项目成本管理包括资源计划编制、成本估算、成本预算、成本控制 4 个主要部分内容。
资源计划编制是确定为完成项目各活动需什么资源人、设备、材料和这些资源的数量。资源计划与成本估算是紧密相关的。成本估算就是计算出完成一个项目的各活动所需各资源成本的近似值。当一个项目按合同进行时应区分成本估算和定价这两个不同意义的词。成本估算所涉及的是对可能数量结果的估算——执行组织为提供产品和服务的花费是多少而定价是一个商业决策——执行组织为提供的产品或服务索取多少费用。成本估算是定价要考虑的因素之一。成本估算包括确认和考虑各种不同的成本估算替代方案。例如软件设计阶段多做些工作可减少编码阶段的成本。而成本估算过程必须考虑增加的设计工作所多花的成本是否被以后的节省所抵消。
成本预算是把估算的总成本分配到单个活动或工作包上去建立基准计划来度量项目实际绩效。成本控制的内容有对造成成本基准计划变化的因素施加影响以保证这种变化得到一致认可确定成本基准计划是否已经发生变化当变化发生和正在发生时对这种变化执行管理。成本控制包括以下方面
监测成本执行情况以寻找出并掌握计划的偏差及原因。确保所有变更都准确地记录在成本基准计划中。防止把不正确、不适宜或未批准的变更纳入成本基准成本。将批准的变更通知项目干系人。采取措施把预计的成本控制在可接受的范围内。成本控制包括寻找产生正负偏差的原因。成本控制必须和其他控制过程结合。例如如果成本偏差采取不恰当的应对措施常会引起项目的质量和进度问题或引起项目在后期出现无法接受的风险。
13.1.3 项目时间管理
时间管理包括确保项目按时完成所需的各个过程。它包括活动定义、活动排序、活动历时估算、进度计划编制、进度控制 5 个部分内容。活动定义是对 WBS 中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义并形成文档。为使项目目标得以实现在这个过程中对活动做出定义无疑是必要的。活动排序是确定各活动之间的依赖关系并形成文档。活动必须被正确地加以排序以便今后制定切实可行的进度计划。排序可由计算机辅助或用手工排序。
项目活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程。历时估算的输入通常来自项目团队中熟悉该活动特性的个人和团体。估算通常采用渐进明细的方式同时此过程需考虑输入数据的质量和可获得性。因此可以假设此估算逐步精确并且其质量水平是已知的。项目团队中最熟悉具体活动性质的个人或团队应当完成历时估算。制订进度计划要决定项目活动的开始和结束日期。若开始和结束日期是不现实的项目就不可能按计划完成。进度计划、历时估算、成本估算等过程交织在一起这些过程反复多次最后才能确定项目进度计划。进度控制涉及的是对造成进度变更的因素施加影响以确保这些变更得到一致认可确定进度变更是否已经发生 当变更发生时对实际变更进行管理。
13.2 配置管理与文档管理
随着软件规模和复杂性的增大许多大型开发项目往往都会延迟和超出预算软件开发不得不直面越来越多的问题表现为开发的环境日益复杂代码共享日益困难需跨越的平台增多软件的重用性需要提高软件的维护越来越困难。
为了解决这些问题作为控制软件系统一系列变化的学科软件配置管理Software Configuration ManagementSCM应运而生。其主要作用是通过结构化的、有序化的、产品化的管理软件工程的方法来维护产品的历史鉴别和定位产品独有的版本并在产品的开发和发布阶段控制变化通过有序管理和减少重复性工作配置管理保证了生产的质量和效率它涵盖了软件生命周期的所有领域并影响所有数据和过程。作为软件开发中一个重要过程实现在有限的时间和资金内满足不断增长的软件产品质量要求软件配置管理已经逐渐受到各类软件企业的重视。
13.2.1 软件配置管理的概念
对于软件配置管理IEEE 给出了一个定义SCM 是指在软件系统中确定和定义构件源 代码、可执行程序、文档等在整个生命周期中控制发布和变更记录和报告构件的状态 和变更请求并定义完整的、正确的系统构件的过程。在 IEEE 标准 729-1983 中软件配 置管理包括以下几个方面功能
配置标识产品的结构、产品的构件及其类型为其分配唯一的标识符并以某种形式提供 对它们的存取。版本控制通过建立产品基线控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如它将解决哪些修改会在该产品的最新版本中实现的问题。状态统计记录并报告构件和修改请求的状态并收集关于产品构件的重要统计信息。例如 它将解决修改这个错误会影响多少个文件的问题。审计和审查确认产品的完整性并维护构件间的一致性即确保产品是一个严格定义的构件 集合。例如它将解决目前发布的产品所用的文件的版本是否正确的问题。生产对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来 生成的问题。过程管理确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用 户的产品是否经过测试和质量检查的问题。小组协作控制开发统一产品的多个开发人员之间的协作。例如它将解决是否所有本地程 序员所做的修改都已被加入新版本的产品中的问题。 而在另外一个标准 ISO9000.3 中对软件配置管理系统做了如下要求唯一地标识每个软件项的版本标识共同构成一个完整产品的特定版本的每一软件项的版本控制由两个或多个独立工作的人员同时对一个给定软件项的更新按要求在一个或多个位置对复杂产品的更新进行协调标识并跟踪所有的措施和更改这些措施和更改是在从开始直到放行期间由于更改请求或 问题引起的。
两个文件都强调了配置管理三个核心部分版本管理、问题跟踪和建立管理其中版本 管理是基础。版本管理应完成以下主要任务
建立项目重构任何修订版的某一项或某一文件利用加锁技术防止覆盖当增加一个修订版时要求输入变更描述提供比较任意两个修订版的使用工具采用增量存储方式提供对修订版历史和锁定状态的报告功能提供归并功能允许在任何时候重构任何版本权限的设置晋升模型的建立提供各种报告。
13.2.2 软件配置管理的解决方案
目前软件配置管理的解决方案有许多厂商提供如 Rational ClearCaseMerant PVCS Microsoft VSS。大部分软件具备版本控制、建立管理、构造管理、问题追踪这些基本的功能 模块有些软件还融合了需求管理、需求变更管理技术并支持工作流程以至Internet/Intranet 应用的异地通信和管理功能。可以看到软件配置管理的趋势是涉及面越来越广将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。
常用的软件配置管理工具主要有如下产品Rational ClearCaseMerant PVCSMicrosoft VSSCVS。
1Rational ClearCase ClearCase 是 Rational 公司的主要配置管理工具可以用于 Windows 和 UNIX 开发环境。ClearCase 主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务支持 Client/Server 网络结构。ClearCase 提供了全面的配置管理功能包括版本控制、工作空间管理、建立管理和过程控制而且无须软件开发者改变他们现有的环境、工具和工作方式。 下面列举其主要功能 1版本控制。ClearCase 的核心功能是版本控制它是对软件开发进程中一个文件或一个目录发展过程进行追踪的手段通过分支和归并功能支持并行开发。在软件开发环境中ClearCase 可以对每一种对象类型包括源代码、二进制文件、目录内容、可执行文件、文档、测试包、编译器、库文件等实现版本控制。因而ClearCase 提供的能力远远超出资源控制并且可以帮助团队在开发软件时为他们所处理的每一种信息类型建立一个安全可靠的版本历史记录。
2工作空间管理。所谓空间管理即保证开发人员拥有自己独立的工作环境拥有自己的私人存储区同时可以访问成员间的共享信息。ClearCase 给每一位开发者提供了一致、灵活的可重用工作空间域。它采用名为 View 的新技术通过设定不同的视图配置规格帮助程序员选择特定任务的每一个文件或目录的适当版本并显示它们。View 可以让开发者在资源代码共享和私有代码独立的不断变更中达到平衡从而使他们的工作更有效。
3建立管理。ClearCase 自动产生软件系统构造文档信息清单而且可以完全、可靠地重建任何构造环境。ClearCase 也可以通过共享二进制文件和并发执行多个建立脚本的方式支持有效的软件构造。使用 ClearCase构造软件的处理过程可以和传统的方法兼容。对 ClearCase 控制的数据既可以使用自制脚本也可使用本机提供的 make 程序但 ClearCase 的建立工具clearmake支持 UNIX和 omake支持 NT为构造提供了重要的特性自动完成任务、保证重建的可靠性、存储时间和支持并行的分布式结构的建立。此外ClearCase 还可以自动追踪、建立产生永久性的资料清单。
4过程控制。ClearCase 有一个灵活、强大的功能可以明确项目设计的流程。ClearCase 为团队通信、质量保证、变更管理提供了非常有效的过程控制和策略控制机制。ClearCase 可以有效地设置监控开发过程这体现在为对象分配属性超级链接历史记录定义事件触发机制访问控制查询功能等几个方面。自动的常规日志可以监控软件被谁修改、修改了什么内容及执行政策如可以通过对全体人员的不同授权来阻止某些修改的发生无论任何时刻某一事件发生应立刻通知团队成员对开发的进程建立一个永久记录并不断维护它。综上所述ClearCase 支持全面的软件配置管理功能给那些经常跨越复杂环境如 UNIX、Windows 系统进行复杂项目开发的团队带来巨大效益。此外ClearCase 也支持广泛的开发环境它所拥有的特殊构件已成为当今软件开发人员、工程人员和管理人员必备的工具。
2Merant PVCS Merant 的 PVCS 是世界领先的软件开发管理工具在软件生命周期管理市场占有绝大多数市场份额是公认的工业标准。全球的著名企业、软件机构、银行等诸多行业及政府机构大多数都应用了 PVCS。它能够实现配置管理中的各项要求并且能和多种流行开发平台集成为配置管理提供了很大的方便。PVCS 包含多种工具几乎覆盖了软件开发管理中的所有问题。
PVCSVersionManager能完整、详细地记录开发过程中出现的变更和修改可快速得到系统中任何文件的各个版本并使修订版本自动升级。PVCSConfigurationBuilder为软件系统提供了可靠的自动重建过程。它保证系统在任何时候对某一发布的产品准确地进行重建避免发生错误同时自动地对修改过的模块重新编译以节省时间。PVCSTracker在整个开发过程中确定和追踪软件的每一变更的要求。PVCSNotify将软件状态的变更通过 E-mail 通知组织机构中的其他成员。PVCSReporter为 GUI 界面环境提供一个客户报表工具使用它能很容易地生成和存储多个项目的报表。PVCSProductionGateway提供了局域网间与大型机 MVS 系统双向同步互联。PVCSDeveloper’sToolkit为 PVCS 客户提供了应用程序开发接口API使项目信息通过编程访问。PVCSRequisitePro提供了一个独特的 MicrosoftWord 界面和需求数据库从而可以使开发机构实时、直观地对来自于最终用户的项目需求及需求变更进行追踪和管理可有效地避免重复开发保证开发项目按期、按质、按原有的资金预算交付用户。
上述的 8 个模块既可以单独安装和使用也可以相互集成建立工业化软件开发企业所需的完整的软件开发管理环境。PVCS 不仅很好地解决了代码重用、数据丢失等问题它还从下述的几个主要方面满足了软件开发机构迅速增长的市场需求成为全球开发机构首选的软件配置管理工具。
3Microsoft VSSCVS 微软的 VSSVisual SourceSafe提供了基本的认证安全和版本控制机制包括 CheckIn入库、CheckOut出库、Branch分支、Label标定等功能。版本控制是工作组软件开发中的重要方面它能防止意外的文件丢失、允许反追踪到早期版本、并能对版本进行分支、合并和管理。在软件开发中比较两种版本的文件或找回早期版本的文件时源代码的控制是非常有用的。
VSS 是一种源代码控制系统它提供了完善的版本和配置管理功能以及安全保护和跟踪检查功能。VSS 带有一个专业的文档、代码管理库通过将有关项目文档包括文本文件、图像文件、二进制文件、声音文件、视频文件存入数据库进行项目研发管理工作。通过 VSS 与 APT 系统的配合能够对文件进行控制用户可以根据需要随时快速有效地共享文件。从文档的控制流程增加、删除、修改、借阅等到文档的修改信息记录实现完善的文档管理。VSS 提供了历史版本的提取、提供源码历史版本对比。VSS 文件一旦被添加进 VSS它的每次改动都会被记录下来用户可以恢复文件的早期版本项目组的其他成员也可以看到有关文档的最新版本并对它们进行修改VSS 也同样会将新的改动记录下来。用 VSS 来组织管理项目使得项目组间的沟通与合作更简易而且直观。
VSS 可以同 Visual studio 开发环境及 Microsoft Office 应用程序集成在一起提供了方便易用、面向项目的版本控制功能。VSS 可以处理由各种开发语言、创作工具或应用程序所创建的任何文件类型用户可以同时在文件和项目级进行工作。VSS 面向项目的特性能更有效地管理工作组应用程序开发工作中的日常任务。VSS 的客户端既可以连接服务器运行也可以在本机运行非常适合于个人程序开发的版本管理。CVS并发版本系统ConcurrentVersions System是主流的开放源码的版本控制系统Linux 和 UNIX 下系统自带的版本控制工具。CVS 对于从个人开发者到大型、分布式团队都是有用的。与微软 VSS 在实现功能上属于同一个级别不过支持的操作平台不一样。
13.2.3 软件文档管理
所谓文档是指某种数据媒体和其中所记录的数据。它具有永久性并可以由人或机器阅读通常仅用于描述人工可读的东西。在软件工程中文档常常是用来对活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信息。在软件生产过程中总是产生和使用大量的信息。软件文档在产品的开发过程中起着重要的作用。
1软件文档的作用 1管理依据。在软件开发过程中管理者必须了解开发的进度、存在的问题和预期目标。每一阶段计划安排的定期报告提供了项目的可见性把开发过程中发生的事件以某种可阅读的形式记录在文档中。定期报告还提醒各级管理者注意该部门对项目承担的责任及该部门效率的重要性。开发文档规定若干个检查点和进度表使管理者可以评定项目的进度如果开发文档有遗漏、不完善或内容陈旧则管理者将失去跟踪和控制项目的重要依据。管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据分析评估项目、检查调整项目/计划、调配专用资源实现对软件开发的工程管理。
2任务之间联系的凭证。大多数软件开发项目通常被划分成若干个任务并由不同的小组去完成。学科方面的专家建立项目分析员阐述系统需求设计员为程序员制定总体设计程序员编制详细的程序代码质量保证专家和审查员评价整个系统性能和功能的完整性负责维护的程序员改进各种操作或增强某些功能。这些人员需要的互相联系是通过文档资料的复制、分发和引用而实现的因而任务之间的联系是文档的一个重要功能。大多数系统开发方法为任务的联系规定了一些正式文档。分析员向设计员提供正式需求规格说明设计员向程序员提供正式设计规格说明等
3质量保证。软件文档能提高开发效率。软件文档的编制使得开发人员对各个阶段的工作都进行周密思考、全盘权衡、减少返工。并且可在开发早期发现错误和不一致性便于及时加以纠正。那些负责软件质量保证和评估系统性能的人员需要程序规格说明、测试和评估计划、测试该系统用的各种质量标准以及关于期望系统完成什么功能和系统怎样实现这些功能的清晰说明必须制订测试计划和测试规程并报告测试结果他们还必须说明和评估完全控制、计算、检验例行程序及其他控制技术。这些文档的提供可满足质量保证人员和审查人员上述工作的需要。
4培训与参考。软件文档作为开发人员在一定阶段的工作成果和结束标志它的另一个功能是使系统管理员、操作员、用户、管理者和其他有关人员了解系统如何工作以及为了达到他们各自的目的如何使用系统。
5软件维护支持。记录开发过程中有关信息便于协调以后的软件开发、使用和维护。维护人员需要软件系统的详细说明以帮助他们熟悉系统找出并修正错误改进系统以适应用户需求的变化或适应系统环境的变化。软件文档提供对软件的运行、维护的有关信息便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解。
6历史档案。良好的文档系统作为全组织范围内共享所存储的文档信息对于软件企业而言也是一个很好的学习资源。通常文档记载系统的开发历史可使有关系统结构的基本思想为以后的项目利用。系统开发人员通过审阅以前的系统以查明什么部分已试验过了什么部分运行得很好什么部分因某种原因难以运行而被排除。良好的系统文档有助于把程序移植和转移到各种新的系统环境中。
7销售可能。软件文档便于潜在用户了解软件的功能、性能等各项指标为他们选购符合自己需要的软件提供依据。
从某种意义上来说良好的文档管理是优秀项目的重要标志文档是软件开发规范的体现和指南也是记录和管理知识的重要形式。文档与知识管理文档是固化的知识是显性知识的重要载体按规范要求生成一整套文档的过程就是按照软件开发规范完成一个软件开发的过程。从历史经验来看写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢但随着项目的进展部门间配合越来越多、开发方对用户需求越来越细开发者越来越需要知道系统设计的开发思路和用户的进一步功能需求才能使自己的开发朝着正确的方向推进。一个明显的例子就是系统整合或者某些环节是建立在其他环节完成的基础之上时就更显现出文档交流的准确性和高效性。文档的管理虽然是一个非常烦琐的工作但是长远来看它不仅使项目的开发对单个主要人员的依赖减少从而减少人员流动给项目带来的风险更重要的是在项目进行到后 10%的时候起到拉动项目的作用。所以在使用工程化的原理和方法来指导软件的开发和维护时应当充分注意软件文档的编制和管理。
2文档的归类 按照文档产生和使用的范围软件文档大致可分为 3 类开发文档管理文档产品文档。
1开发文档。开发文档是描述软件开发过程包括软件需求、软件设计、软件测试、保证软件质量的一类文档开发文档也包括软件的详细技术描述程序逻辑、程序间相互关系、数据格式和存储等。开发文档起到如下 5 种作用它们是软件开发过程中包含的所有阶段之间的通信工具它们记录生成软件需求、设计、编 码和测试的详细规定和说明
它们描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做它们用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时管理者将失去跟踪和控制软件项目的一个重要工具它们形成了维护人员所要求的基本的软件支持文档。而这些支持文档可作为产品文档的一部分它们记录软件开发的历史。基本的开发文档包括可行性研究和项目任务书需求规格说明概要设计说明详细设计说明包括程序和数据规格说明项目开发计划软件集成和测试计划质量保证计划、标准、进度安全和测试信息。
2产品文档。产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品的文档起到如下 3 种作用
为使用和运行软件产品的任何人规定培训和参考信息使得那些未参加开发本软件的程序员维护它促进软件产品的市场流通或提高可接受性。 产品文档主要应用于下列类型的读者用户——他们利用软件输入数据、检索信息和解决问题 -运行者——他们在计算机系统上运行软件维护人员——他们维护、增强或变更软件。
产品文档包括如下内容用于管理者的指南和资料他们监督软件的使用宣传资料通告软件产品的可用性并详细说明它的功能、运行环境等一般信息对任何对其感兴趣的人描述软件产品。基本的产品文档实物包括培训手册参考手册和用户指南软件支持手册产品手册和信息广告维护修改建议等。
3管理文档。这种文档建立在项目管理信息的基础上从管理的角度规定涉及软件生存的信息。它包括项目开发计划、测试计划开发过程的每个阶段的进度和进度变更的记录软件变更情况的记录相对于开发的判定记录开发人员职责定义测试报告、开发进度月报项目开发总结等。
另外软件文档从用途上还可以分为内部文档和外部文档。其中内部文档包括项目开发计划、需求分析、架构设计说明、详细设计说明、构件索引、构件成分说明、构件接口及调用说明、构件索引、构件接口及调用说明、类索引、类属性及方法说明、测试报告、测试统计报告、质量监督报告、源代码、文档分类版本索引和软件安装打包文件等。外部文档主要包括软件安装手册、软件操作手册、在线帮助、系统性能指标报告和系统操作索引等。
3文档编制计划 软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力制定一个对文档编制要求的实施规定。对于一个具体的应用软件项目项目负责人应根据上述实施规定确定一个文档编制计划。
文档计划可以是整个项目计划的一部分或是一个独立的文档。应该编写文档计划并把它分发给全体开发组成员作为文档重要性的具体依据和管理部门文档工作责任的备忘录。编制计划的工作应及早开始对计划的评审应贯穿项目的全过程。如同任何别的计划一样文档计划指出未来的各项活动当需要修改时必须加以修改。导致对计划作适当修改的常规评审应作为该项目工作的一部分所有与该计划有关的人员都应得到文档计划。 文档计划一般包括以下几方面内容
列出应编制文档的目录提示编制文档应参考的标准指定文档管理员提供编制文档所需要的条件落实文档编写人员、所需经费及编制工具等明确保证文档质量的方法为了确保文档内容的正确性、合理性应采取一定的措施如评审、鉴定等绘制进度表以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。
还必须明确要编制哪几种文档详细程度如何各文档的编制负责人和进度要求审查/批准负责人和时间进度安排在开发时期内各文档的维护、修改和管理的负责人以及批准手续。文档计划还应确定该计划和文档的分发有关的开发人员必须严格执行这个文档编制计划。文档计划还应该规定每个文档要达到的质量等级以及为了达到期望的结果必须考虑哪些外部因素。
4对文档质量的要求如果不重视文档编写工作或是对文档编写工作的安排不当就不可能得到高质量的 文档。质量差的文档一般会使读者难以理解给使用者造成许多不便会削弱对软件的管理难以确认和评价开发工作的进展情况提高软件成本一些工作可能被迫返工造成误操作。一般而言好的软件文档要求具备如下特征。
1针对性。文档编制前应分清读者对象。对不同的类型、不同层次的读者决定如何满足适应他们的需要。 管理文档主要面向管理人员。用户文档主要面向用户。这两类文档不应像开发文档面向开发人员那样过多地使用软件的专业术语。
2精确性。文档的行文应当十分确切不能出现多义性的描述。同一课题几个文档的内容应当是协调一致、没有矛盾的。
3清晰性。文档编写应力求简明如有可能配以适当的图表以增强其清晰性。
4完整性。任何一个文档都应当是完整的、独立的它应自成体系。例如前言部分应做一般性介绍正文给出中心内容必要时还有附录列出参考资料等。同一课题的几个文档之间可能有部分内容相同这种重复是必要的。不要在文档中出现转引其他文档内容的情况。如一些段落没有具体描述用“见××文档××节”的方式。
5灵活性。各个不同软件项目其规模和复杂程度有着许多实际差别不能相同看待。应根据具体的软件开发项目决定编制的文档种类。
13.3 软件需求管理
在软件开发的整个过程中随着客观条件的变化和客户对软件或业务理解的加深会产生很多新的软件需求项目经理需要经常面对需求变更。需求管理的目的就是控制和维持事先约定保证项目开发过程的一致性使用户能够得到他们最终想要得到的软件产品。下面的内容主要涉及需求管理的两个方面需求变更、需求跟踪。
13.3.1 需求变更
需求变更是指在软件开发过程中用户确定软件需求之后由于各种客观和主观条件的 变化用户增加了新的需求或改变了原有需求。项目经理需要在整个项目生命周期中管理需求变更将项目变更的影响降到最低。进行需求变更控制的主要依据是项目计划、变更请求和反映项目执行状况的绩效报告。为保证项目变更的规范性和项目的有效实施通常软件开发机构会采取如下措施。
1项目启动阶段的变更预防。对于任何项目变更都无可避免也无从逃避只能积极应对。这个应对应该是从项目启动的需求分析阶段就开始了。对一个需求分析做得很好的项目来说基准文件定义的范围越详细、清晰用户跟项目经理的分歧就越少。如果需求做得好文档清晰且有客户签字那么后期客户提出的变更超出了合同范围就需要另外处理。
2项目实施阶段的需求变更。成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念 “需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求评估变更可能带来的风险和修改基准文件。控制需求变更需要注意以下几点
需求一定要与投入有联系如果需求变更的成本由开发方来承担则项目需求的变更就成为必然了。所以在项目的开始无论是开发方还是出资方都要明确这一条需求变软件开发的投入也要变。需求的变更要经过出资者的认可使需求的变更有成本的概念。这样项目实施涉及各方就能够慎重地对待需求的变更。小的需求变更也要经过正规的需求管理流程。在实践中人们往往不愿意为小的需求变更去执行正规的需求管理过程认为降低了开发效率浪费了时间。但正是由于这种观念才使需求逐渐变为不可控最终导致项目的失败。还要注意沟通的技巧。实际情况是用户、开发者都认识到了上面的几点问题但是由于需求的变更可能来自客户方也可能来自开发方因此作为需求管理者项目经理需要采用各种沟通技巧来使项目的各方受益。
13.3.2 需求跟踪
需求跟踪是指在软件需求管理的过程中定义需求变更流程分析需求变更影响控制变化的版本维护需求变更记录,跟踪每项需求状态。
1确定需求变更控制过程。制定一个选择、分析和决策需求变更的标准过程所有的需求变更都需遵循此过程。
2进行需求变更影响分析。评估每项需求变更以确定它对项目计划安排和其他需求的影响明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3建立需求基准版本和需求控制版本文档。确定需求基准这是项目各方对需求达成一致认识时刻的一个快照之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明以避免将底稿和基准或新旧版本相混淆。
4维护需求变更的历史记录。将需求变更情况写成文档记录变更日期、原因、负责人、版本号等内容及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传应指定专人来负责更新需求。
5跟踪每项需求的状态。可以把每一项需求的状态属性如已推荐的已通过的已实施的或已验证的保存在数据库中这样可以在任何时候得到每个状态类的需求数量。
13.4 软件开发的质量与风险
随着软件开发的规模越来越大软件的质量问题越来越引起人们的关注。关于软件质量IEEE 729—1983 标准有以下定义
软件产品满足给定需求的特性及特征的总体的能力。软件拥有所期望的各种属性组合的程度。顾客或用户认为软件满足他们综合期望的程度。软件组合特性在使用中满足用户预期需求的程度。
从上述这个定义可以看到质量不是绝对的它总是与给定的需求有关。因此对软件质量的评价总是在将产品的实际情况与从给定的需求中推导出来的软件质量的特征和质量标准进行比较后得出来的。尽管如此这里给出的软件质量还是一个模糊的概念且难以衡量。所以软件质量管理的目的是建立对项目的软件产品质量的定量理解和实现特定的质量目标。
13.4.1 软件质量管理
项目质量管理包括保证项目能满足原先规定的各项要求所需要的过程即“总体管理功能中决定质量方针、目标与责任的所有活动并通过诸如质量规划、质量保证、质量控制、质量改进等手段在质量体系内加以实施”。软件质量管理着重于确定软件产品的质量目标、制订达到这些目标的计划并监控及调整软件计划、软件工作产品、活动及质量目标以满足顾客及最终用户对高质量产品的需要及期望。
软件质量管理包括三个部分质量计划——判断哪些质量标准与本项目相关并决定应如何达到这些质量标准质量保证——定期评估项目总体绩效建立项目能达到相关质量标准的信心质量控制——监测项目的总体结果判断它们是否符合相关质量标准并找出如何消除不合格绩效的方法。
1软件质量计划 在正式进行软件开发前需要制订一个软件质量计划用于说明项目管理团队将如何实施其质量方针。用 ISO9000 的话来说它应该说明项目质量体系即“用以实施质量管理的组织结构、责任、程序、过程和资源”。目前国际上有许多质量标准较常用的是 ANSI/IEEE STOL730—1984983—1986 标准。质量计划可以识别哪些质量标准适用于本项目并确定如何满足这些标准的要求。在软件质量计划阶段应该完成如下活动
对项目的软件质量活动做出计划。对软件产品质量的可测量的目标及其优先级进行定义。确定软件产品质量目标的实现过程是可量化和可管理的。为管理软件产品的质量提供适当的资源和资金。对实施和支持软件质量管理的人员进行实施和支持过程中所要求的培训。对软件开发项目组和其他与软件项目有关的人员进行软件质量管理方面的培训。按照已文档化的规程制订和维护项目的软件质量计划。 项目的软件质量管理活动要以项目的软件质量计划为基础。在整个软件生命周期要确定、监控和更新软件产品的质量目标。
2软件质量保证质量保证指为项目符合相关质量标准要求树立信心而在质量系统内部实施的各项有计划的系统活动。质量保证应贯穿于项目的始终在事件驱动的基础上对软件产品的质量进行测量、分析并将分析结果与既定的质量标准相比较以提供质量改进的依据。如果属于软件外包还需要对软件产品的定量质量目标进行合理的分工分派给项目交付软件产品的承包商。
3软件质量控制质量控制指监视项目的具体结果确定其是否符合相关的质量标准并判断如何杜绝造成不合格结果的根源。软件质量的控制不单单是一个软件测试问题评审、调试和测试是保证软件质量的重要手段。质量控制指监视项目的具体结果确定其是否符合相关的质量标准并判断如何杜绝造成不合格结果的根源。质量控制应贯穿于项目的始终。项目结果既包括产品结果例如可交付成果、也包括项目管理结果例如成本与进度绩效。质量控制通常由机构中的质量控制部或名称相似的部门实施软件质量控制包括如下活动对软件产品进行测试并将测试结果用于软件质量管理活动的状态。高级管理者定期参与评审软件质量管理的活动。 软件项目负责人定期参与评审软件质量管理的活动。
软件质量保证评审小组负责评审软件的质量管理活动和工作产品并填写相关报告。 1软件评审。软件评审并不是在软件开发完毕后进行评审而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误如果这些错误不及时发现并纠正会不断地扩大最后可能导致开发的失败。
首先要明确评审目标包括如下部分
发现任何形式表现的软件功能、逻辑或实现方面的错误通过评审验证软件的需求保证软件按预先定义的标准表示已获得的软件是以统一的形式开发的使项目更容易管理。
其次评审过程应包括
召开评审会议。会议结束时必须做出以下决策之一① 接受该产品不需作修改② 由于错误严重拒绝 接受③ 暂时接受该产品。评审报告与记录所提出的问题都要进行记录在评审会结束前产生一个评审问题表另外必须完成评审简要报告。还应该遵循基本的评审准则如对每个正式技术评审分配资源和时间进度表评审产品而不是评审设计者不能使设计者有任何压力会议不能脱离主题应建立议事日程并维持它评审会不是为了解决问题而是为了发现问题限制争论与反驳对每个被评审的产品建立评审清单以帮助评审人员思考
2测试。软件测试是软件开发的一个重要环节同时也是软件质量保证的一个重要环节。所谓测试就是用已知的输入在已知环境中动态地执行系统或系统的构件。测试一般包括单元测试、模块测试、集成测试和系统测试。如果测试结果与预期结果不一致则很可能是发现了系统中的错误测试过程中将产生下述基本文档。
测试计划确定测试范围、方法和需要的资源等。测试过程详细描述与每个测试方案有关的测试步骤和数据包括测试数据及预期的结果。测试结果把每次测试运行的结果归入文档如果运行出错则应产生问题报告并且必须经过调试解决所发现的问题。
13.4.2 项目风险管理
无论是系统集成还是软件开发IT 公司经常面临着各种项目的实施和管理面临着如何确定项目的投资价值、评估利益大小、分析不确定因素、决定投资回收时间等众多问题。并且一个 IT 项目无论其规模大小必然会为被实施方用户在管理、业务经营等多方面带来变革这就使 IT 项目必然具有高风险性的特点。尤其是近年来IT 项目的广泛实施一方面为众多的企业带来了管理、经营方面的革新而另一方面夭折、中断、失败的项目也不在少数。因此如何在项目实施中有效地管理风险、控制风险已经成为了项目实施成功的必要条件。
实际上项目风险的管理不仅贯穿于整个项目过程而且在项目事件发生之前风险的分析就已经开始。可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分事前控制——风险管理规划事中控制——风险管理方法事后控制——风险管理报告。
1项目风险管理的概念 根据 PMBOK2000 版的定义风险管理指对项目风险进行识别、分析、并采取应对措施的系统过程。它包括尽量扩大有利于项目目标事项发生的概率与后果而尽量减小不利于项目目标事项发生的概率与后果。项目风险按是否有可确定性划分为已知风险、可预知风险、不可预知风险。按风险管理的内容又可以划分为如下几种类型。
1内部技术风险技术变化和创新是项目风险的重要来源之一。一般说来项目中采用新技术或技术创新无疑是提高项目绩效的重要手段但这样也会带来一些问题许多新的技术未经证实或并未被充分掌握则会影响项目的成功。还有当人们出于竞争的需要就会提高项目产品性能、质量方面的要求而不切实际的要求也是项目风险的来源。
2内部非技术风险公司的经营战略发生了变化相关的战略风险、涉及公司管理/ 项目管理人员管理水平等的管理风险以及与范围变更有关的风险没有按照要求的技术性能和质量水平完成任务的质量风险没有在预算的时间范围内完成任务的进度风险没有在预算的成本范围内完成任务的成本风险。
3外部法律风险包括与项目相关的规章或标准的变化如许可权、专利、合同失效、诉讼等。
4外部非法律风险主要是指项目的政治、社会影响、经济环境的变化组织中雇佣关系的变化如公司并购、政府干预、货币变动、通货膨胀、税收、自然灾害等。这类风险对项目的影响和项目性质的关系较大。
2风险管理的过程风险管理包括对项目风险识别、分析和应对的过程从而将正面事件影响扩大到最大化和将负面事件影响减少到最小化。项目风险管理的主要过程包括
风险管理规划决定如何指导和规划项目的风险管理活动。项目风险识别找到哪些风险可能影响项目并记录其特征。定性风险分析完成风险和环境的定性分析并按其对项目目标的影响进行排序。定性风险分析是决定具体风险的重要性并指导做出相关反应的一种方法。与风险相关的动作的时间相关性可能使风险的重要性加大。定量风险分析度量风险的可能性和后果估量其对项目目标的潜在影响。风险应对计划创建过程和技术来为项目目标增进机会和减小威胁。风险监督与控制在项目生命周期中监视现存的风险、识别新的风险、执行缓解风险计划及评估其效果。
上述过程不仅彼此有交互作用而且也同其他知识领域的过程有交互作用。一般来说每个过程在项目中至少出现一次。
1风险识别。风险的识别就是识别整个项目过程中可能存在的风险事件。在项目开始、每个项目阶段中间、主要范围变更批准之前都要进行风险识别实际上它在整个项目生命周期内都是一个连续的过程。要识别风险首先应该了解在软件开发的各个阶段都有可能发生哪些风险风险事件或风险来源。表 13-1 列出软件开发各阶段可能发生的风险。 其中初始阶段主要进行大部分需求分析、小部分设计大部分业务建模和需求、少部分分析设计设计阶段主要进行大部分设计、小部分编码大部分分析设计部分实施及测试开始考虑部署实施阶段进行大部分编码和测试也涉及小部分设计大部分实施及测试部分部署收尾阶段完成安装及维护大部分部署。 除了考虑项目过程之外软件企业在人力资源管理中也存在风险如招聘失败、新政策引起员工不满、技术骨干突然离职等这些事件会影响公司的正常运转甚至会对公司造成致命的打击。特别是高新技术企业由于对人的依赖更大所以更需要识别人力资源方面的风险。
以上只是列举了常见的风险事件对不同项目可能发生的风险事件不同应该对具体项目识别出真正有可能发生在该项目的风险事件。一般是根据项目的性质从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方意见就形成项目的风险列表并对这些风险事件进行描述如可能性、可能后果范围、预计发生时间、发生频率等。风险识别的有效方法有很多如建立风险项目检查表、因果分析图、采访各种项目干系人等。
2风险分析。确定了项目的风险列表之后接下来就可以进行风险分析了。风险分析的目的是确定每个风险对项目的影响大小一般是对已经识别出来的项目风险进行量化估计这里要注意三个概念。
风险得失值它是指一旦风险发生可能对项目造成的影响大小说明可能造成的损失。如果损失的大小不容易直接估计可以将损失分解为更小部分再评估它们。风险得失值可用相对数值表示建议将损失大小折算成对计划影响的时间表示。风险概率它是风险发生可能性的百分比表示是一种主观判断。风险值风险值又风险曝光度或风险暴露它是评估风险的重要参数“风险值” “风概率” “风险影响”。如某一风险概率是 25%一旦发生会导致项目计划延长 4 周因而风险值 25% 4 周 1 周。 风险分析就是对以上识别出来的风险事件做风险影响分析。通过对风险及风险的相互作用的估算来评价项目可能结果的范围从成本、进度及性能三个方面对风险进行评价确定哪些风险事件或来源可以避免哪些可以忽略不考虑包括可以承受哪些要采取应对措施。
3风险应对方法。完成了风险分析后就已经确定了项目中存在的风险及它们发生的可能性和对项目的风险冲击并可排出风险的优先级。此后就可以根据风险性质和项目对风险的承受能力制订相应的防范计划即风险应对。制订风险应对策略主要考虑以下 4 个方面的因素可规避性、可转移性、可缓解性、可接受性。风险的应对策略在某种程度上决定了采用什么样的项目开发方案。对于应“规避”或“转嫁”的风险在项目策略与计划时必须加以考虑。
项目中的风险永远不能全部消除PMBOK2012 版提到 4 种应对方法 规避。规避风险指改变项目计划以排除风险或条件或者保护项目目标使其不受影响。虽然项目永远不可能排除所有的风险事件但某些具体风险则是可以规避的。出现于项目早期的某些风险事件可以通过澄清要求、取得信息、改善沟通或获取技术专长而获得解决。通过分析找出发生风险事件的原因消除这些原因来避免一些特定的风险事件发生。例如如何避免客户不满意客户不满意有两种情况一种情况是没有判断客户满意度的依据即没有双方互相认可的客户验收标准还有一种是开发方没有达到验收标准即没有满足用户 需求。不管是哪一种开发方都有不可推卸的责任只要做好以下环节就完全可以避免业务建模阶段要让客户参与需求阶段要多和客户沟通了解客户真正的需求目标系统的模型或 DEMO 系统要向客户演示并得到反馈意见如果反馈的意见和 DEMO 系统出入比较大时一定要将修改后的 DEMO 系统再次向客户演示直到双方都达成共识为止要有双方认可的验收方案和验收标准做好变更控制和配置管理等。 转移。转移风险指设法将风险的后果连同应对的责任转移到第三方身上。转移风险实际只是把风险管理责任推给另一方而并非将其排除。该方法基本上需要向承担风险者支付风险费用。它包括利用保险、履约保证书、担保书和保证书。可以利用合同将具体风险的责任转嫁给另一方。如果项目的设计是稳定的可以用固定总价合同把风险转嫁给卖方。虽然成本报销合同把较多的风险留给了顾客或赞助人但如果项目中途发生变化时它有助于降低成本。 减轻。通过降低风险事件发生的概率或得失量来减轻对项目的影响。提前采取行动以减小风险发生的概率或者减小其对项目所造成的影响这样比在风险发生后亡羊补牢地进行补救要有效得多。减轻风险的成本应估算得当要与风险发生的概率及其后果相称。项目预算中考虑应急储备金是另一种降低风险影响的方法。例如经过风险识别发现项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。 接受。接受风险造成的后果。采取此项技术表明项目团队已经决定不为处置某项风险而改变项目计划或者表明他们无法找到任何其他应对良策。主动地接受风险包括制定一套万一发生风险时所准备实施的应变计划。例如为了避免自然灾害造成的后果在一个大的软件项目中考虑了异地备份中心。 确定风险的应对策略后就可编制风险应对计划它主要包括已识别的风险及其描述、风险发生的概率、风险应对的责任人、风险对应策略及行动计划、应急计划等。
4风险应对计划。针对需要采取应对措施的风险事件开发应对计划一旦发生风险事件就实施应对计划。应对计划常应用于项目进行期间发生的已识别风险事先制订应变计划可大大降低风险发生时采取行动的成本。风险触发因素例如缺失的中间里程碑应确定其定义并进行跟踪。如果风险的影响甚大或者所选用的对策不见得有效时就应制订一套后备权变计划。该项计划可包括留出一笔应急款项、制定其他备用方案、或者改变项目范围。最常见的接受风险的应对措施是预留应急储备或者简称储备包括为已知风险留出时间、资金、或者资源。为所接受的风险所预留的储备取决于按可接受风险水平计算所得影响的大小。
例如在一个软件开发项目中某开发人员有可能离职离职后会对项目造成一定的影响则应该对这个风险事件开发应对计划过程参照如下进行调研确定流动原因。在项目开始前把缓解这些流动原因的工作列入风险管理计划。项目开始时作好一旦人员离开时便可执行的计划以确保人员离开后项目仍能继续进行。 制定文档标准并建立一种机制保证文档及时产生。对所有工作进行细微详审使更多人能够按计划进度完成自己的工作。对每个关键性技术人员培养后备人员。 当然该应对计划需要花费一定的成本在考虑风险成本之后决定是否采用上述策略。
5风险监控。制定了风险应对计划后风险并非不存在在项目推进过程中还可能会增大或者衰退。因此在项目执行过程中需要时刻监督风险的发展与变化情况并确定随着某些风险的消失而带来的新的风险。风险监控包括两个层面的工作其一是跟踪已识别风险的发展变化情况包括在整个项目周期内风险产生的条件和导致的后果变化衡量风险减缓计划需求。其二是根据风险的变化情况及时调整风险应对计划并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析并采取适当的应对措施。对于已发生过和已解决的风险也应及时从风险监控列表调整出去。
最有效的风险监控工具之一就是“前 10 个风险列表”它是一种简便易行的风险监控活动是按“风险值”大小将项目的前 10 个风险作为控制对象密切监控项目的前 10 个风险。每次风险检查后形成新的“前 10 个风险列表”。
13.5 人力资源管理 软件项目人力资源管理包括为最有效地使用参与项目人员所需的各项过程一般包括组织规划、人员招募和团队建设三个主要过程。
1组织规划组织规划用于确定、记录并分派项目角色、职责和请示汇报关系。角色、职责和请示汇报关系可以分派给个人或者集体。这些个人与集体可以是项目实施组织的一部分也可以来自组织外部通过人员招聘、借用等方式获得。实施组织往往与某个具体职能部门相关例如工程部门、销售部门或者财务部门通过与职能经理协商、谈判等方式获得。
软件项目组织一般由担当各种角色的人员所组成。每位成员扮演一个或多个角色常见的一些项目角色包括策划师、数据库管理员、设计师、操作/支持工程师、程序员、项目经理、项目赞助者、质量保证工程师、需求分析师、用户、测试人员等。组织规划取决于可供选择的人员、项目的需求及组织的需求组织的具体形式可以有三种方案垂直方案、水平方案和混合方案。以垂直方案组织的团队由多面手组成每个成员都充当多重角色。以水平方案组织的团队由专家组成每个成员充当一到两个角色。以混合方案组织的团队既包括 多面手又包括专家。
如果可供选择的人员中大多数人员是多面手则往往需要采用垂直方案同样如果大多数人员是专家则采用水平方案。如果正引入一些新人即使这些人员都是合同工则仍然需要优先考虑项目和组织。本节描述了形成团队组织的垂直、水平和混合方案并指出了它们各自的优缺点。
1垂直团队组织。垂直团队由多面手组成。如功能模块分配给了个人或小组然后由他们从头至尾地实现该功能模块。其优点在于以单个功能模块为基础实现平滑的端到端开发开发人员能够掌握更广泛的技能。而缺点也很明显多面手通常是一些要价很高并且很难找到的顾问。多面手通常不具备快速解决具体问题所需的特定技术专长。主题专家可能不得不和若干开发人员小组一起工作从而增加了他们的负担。所有多面手水平各不相同。
2水平团队组织。水平团队由专家组成。此类团队同时处理多个功能模块每个成员都从事功能模块中有关其自身的方面。其优点在于能高质量地完成项目各个方面需求、设计等的工作一些外部小组如用户或操作人员只需要与了解他们确切要求的一小部分专家进行交互。其缺点在于专家们通常无法意识到其他专业的重要性导致项目的各方面之间缺乏联系由于专家们的优先权、看法和需求互不相同所以项目管理比较困难。
3混合团队组织。混合团队由专家和多面手共同组成。多面手继续操作一个功能模块的整个开发过程支持并处理多个功能模块使各部分的专家们一起工作。它可能拥有前两种方案的优点外部小组只需要与一小部分专家进行交互专家们可集中精力从事他们所擅长的工作各个功能模块的实现都保持一致。但是它可能拥有前两种方案的缺点尽管这应该由多面手来调节专家们仍然不能认识到其他专家的工作并且无法很好地协作多面手较难找到故而项目管理仍然较难。
因而要综合考虑、确定团队组织方案。在方案确定后合理配备人员是成功完成软件开发项目的切实保证。所谓合理配备人员应包括按不同阶段适时运用人员恰当掌握用人标准。一般来说软件项目不同阶段、不同层次技术人员的参与情况是不一样的。如人员配置不当很容易造成人力资源的浪费并延误工期。特别是采用恒定人员配备方案时在项目的开始和最后都会出现人力过剩而在中期又会出现人力不足的情况。 在多数项目中组织规划大都是作为项目早期阶段的一部分进行的。但在项目的整个过程中都应对其结果定期检查以保证其继续适用性。如果当初的组织规划已不再适用就应该及时对其进行修改。
2人员招募人员招募指获取分派到项目上、并在那里工作所需的人力资源个人或集体。在多数环境中很可能无法到“最佳”资源因此项目管理团队必须注意保证所物色到的人力资源符合项目要求。通过前一阶段完成的成果——人员配备管理计划来进行实际的人员招募。首先必须了解组织可用/备用人员库的情况。按照组织规划确定的人力资源需求情况充分考虑可调配人员的特点。要考虑的问题主要有
以往经验——这些个人或集体以前是否从事过类似或者相关的工作工作表现如何个人兴趣——这些个人或集体对本项目的工作感兴趣吗能否得到——最理想的个人或集体人选能在规定期限内招募到手吗胜任与熟练程度——需要何种能力及何种水平
而后通过谈判、事先分派和采购等方式获取项目人员以保证项目在规定期限内获得足以胜任的工作人员。其中谈判对象可能是实施组织的职能经理也可能分到其他项目团队以争取稀缺或特殊人才得到合理分派。在某些情况下人员可能事先被分派到项目上。这种情况往往发生在项目是方案竞争的结果而且事先已许诺具体人员指派是获胜方案的组成部分或者项目为内部服务项目人员分派已在项目章程中明确规定。在实施组织缺乏完成项目所需的内部人才时就需要动用采购手段。项目经理是团队组织的核心其综合素质直接影响项目的成败。一般要求项目经理具备如下能力
1领导能力。项目经理必须具备高超的领导才能和强烈的科技意识和较强的业务处理能力。领导能力简单地说通过项目团队来达到目标。
首先项目经理应懂得如何授权和分配职责采取参与和顾问式的领导方式发挥导向和教练作用让成员在职责范围内充分发挥能动性自主地完成项目工作
其次项目经理应善于激励。由于项目经理通常没有太大的权力对成员进行物质方面的激励因此非物质激励方式就特别重要。例如借助项目的唯一性给项目成员接受挑战的机会往往可以对优秀的项目成员起到极大的激励作用另外对项目成员的工作成绩要及时表示认可。及时是非常重要的并且最好是当众表扬例如在上级领导或客户面前对项目团队或具体成员做出正面的评价。
第三项目经理应该为成员树立榜样表现出积极的心态成为团队的典范和信心的源泉。只有身先士卒各方面以身作则才能得到广大开发人员的认可和信任才能树立较高的威信。
第四项目经理应该能够果断抉择负责人的重要任务是决策特别是有多种选择的情况下一个正确的选择往往事半功倍。
2沟通技巧。有效的沟通是项目顺利进行的保证沟通及时、集思广益、步调一致才能取得项目最终的成功。项目过程中项目经理需要通过多种渠道保持与团队及分包商、客户方、公司上级的定期交流沟通及时了解项目的进程、存在的问题及获得有益的建议。沟通的方式可以是口头的或书面的如面谈、电话、邮件、会议等。在沟通过程中项目经理应善于提问并做到有效地聆听能经常站在对方的角度思考问题。
3人际交往能力。良好的人际关系有助于项目的协调避免生硬的操作方式。项目经理必须积极对外联络充分利用外部资源例如其他部门做过类似项目者可以向他们取经甚至直接获得源码。这对一个项目争取时间避免重复工作很重要项目协调是随时需要的主要来自于项目内部及客户可能是资源的配置问题也可能是项目范围的调整等。人际交往需要从一点一滴做起而且往往发生在项目工作之外项目经理需要采取主动、热情的姿态。
4应付压力的能力。项目的特点决定了项目工作过程存在一定的不可预见性项目经理需要做好随时面对压力甚至是冲突的准备。一旦面临压力或冲突最重要的是保持冷静避免使项目陷入困境。项目经理要以乐于解决问题的姿态出现在团队及上级或客户面前。
5培养员工的能力。出色的项目经理重视对项目成员的培养通过项目过程使小组每个成员都能发挥才能并提升员工的能力促进员工的自我发展。项目经理要帮助成员明晰自己的职业与技能发展方向分配合适的工作任务鼓励学习和相互交流让项目小组成员具有很强的成就感。
6时间管理技能。当需要在同一时段处理两项以上的任务时时间管理就是必要的。而项目经理往往需要同时面对数项甚至十几项任务可见有效的时间管理是极为重要的。项目经理不仅需要管理好自己的时间还需要与相关部门及人员订立时间使用协议尽量减少非预期的时间占用。
合格的项目经理具有敏锐的洞察力能瞄准目标实事求是精心组织坚决果断灵活应变享有信誉善于制订计划解决问题沟通信息具有良好的市场意识和交际能力。当然同时满足这些条件比较困难但是他应该具有实现这些条件的素质并注重经验的积累、素质的提高和能力的培养。
3团队建设项目团队的建设既包括提高项目干系人作为个人做出贡献的能力也包括提高项目团队作为集体发挥作用的能力。个人的培养管理能力与技术水平是团队建设的基础而团队建设则是项目实现其目标的关键。
因为软件开发是一项长期艰苦的工作一个团结、协作的团体才能在规定的时间内完成一个质量上乘的软件项目。团队中的每个人必须积极融入整个集体中不能互相推诿更不能互相埋怨和指责正确的态度是大家在充分信任的基础上团结协作、互相帮助、主动承担任务利用集体的智慧获得成功。整个团队就是一部机器只有每一个齿轮都能正常运作才能生产出优质的产品。
人是最宝贵的资源在软件项目中应该为软件开发人员和管理人员等各类项目人员营造一个和谐、良好的工作氛围为开发人员创造出一个人尽其才的环境也是项目成功的重要环节让他们能得心应手地施展自己的才华特别在工作安排上要煞费苦心针对每个人不同的特长根据项目的具体环境和条件把人员合理地安排在恰当的岗位上。使他们能感到项目成功的把握并有积极的工作心态将项目作为自己事业的一部分确保项目队伍的稳定性和连续性。在项目结束之际项目团队的各个成员是否感到他们从自己的经历中学到了一些知识、是否喜欢为这次项目工作以及是否希望参与组织的下一个项目都是非常重要的。
对于软件项目团队的成长规律有人归纳出了以下 4 个阶段 1形成阶段。形成阶段促使个体成员转变为团队成员。每个人在这一阶段都有许多疑问我们的目的是什么其他团队成员的技术、人品怎么样每个人都急于知道他们能否与其他成员合得来自己能否被接受。
为使项目团队明确方向项目经理一定要向团队说明项目目标并设想出项目成功的美好前景及成功所产生的益处公布项目的工作范围、质量标准、预算及进度计划的标准和限制。项目经理在这一阶段还要进行组织构建工作包括确立团队工作的初始操作规程规范沟通渠道、审批及文件记录工作。所以在这一阶段对于项目成员采取的激励方式主要为预期激励、信息激励和参与激励。
2震荡阶段。这一阶段成员们开始着手执行分配到的任务缓慢地推进工作。现实也许会与个人当初的设想不一致。例如任务比预计的更繁重或更困难成本或进度计划的限制可能比预计的更紧张成员们越来越不满意项目经理的指导或命令。 震荡阶段的特点是人们有挫折、愤怨或者对立的情绪。这一阶段士气很低成员可能会抵制形成团队因为他们要表达与团队联合相对立的个性。 因此在这一阶段项目经理要做导向工作致力于解决矛盾决不能希望通过压制来使其自行消失。这时对于项目成员采取的激励方式主要是参与激励、责任激励和信息激励。
3正规阶段。经受了震荡阶段的考验项目团队就进入了发展的正规阶段。项目团队逐渐接受了现有的工作环境团队的凝聚力开始形成。这一阶段随着成员之间开始相互信任团队内大量地交流信息、观点和感情合作意识增强团队成员互相交换看法并感觉到他们可以自由地、建设性地表达他们的情绪及意见。在正规阶段项目经理采取的激励方式除参与激励外还有两个重要方式一是发掘每个成员的自我成就感和责任意识引导员工进行自我激励二是尽可能地多创造团队成员之间互相沟通、相互学习的环境以及从项目外部聘请专家讲解与项目有关的新知识、新技术给员工充分的知识激励。
4表现阶段。团队成长的最后阶段是表现阶段。这时项目团队积极工作急于实现项目目标。这一阶段的工作绩效很高团队有集体感和荣誉感信心十足。团队能感觉到被高度授权如果出现技术难题就由适当的团队成员组成临时攻关小组解决问题后再将相关知识或技巧在团队内部快速共享。
这一阶段项目经理需要特别关注预算、进度计划、工作范围及计划方面的项目业绩。如果实际进程落后于计划进程项目经理就需要协助支持修正行动的制定与执行。这一阶段激励的主要方式是危机激励、目标激励和知识激励。需要强调的是对于信息系统建设人才要更多地引导他们进行自我激励和知识激励。当然足够的物质激励是不言而喻的它从始至终都是最有效的激励。 激励的结果是使参与信息系统的所有成员组成一个富有成效的项目团队这种团队具有如下特点
能清晰地理解项目的目标每位成员的角色和职责有明确的期望以项目的目标为行为的导向项目成员之间高度信任、高度合作互助。总之科学地进行团队建设有助于按期、保质、高效、在预算内完成软件项目。
13.6 软件的运行与评价
软件的运行与评价是指软件开发结束后交付用户使用用户在实际使用中对软件是否符合开发时制定的一系列评价标准进行打分看是否满足了用户的使用要求。通常关注如下几点:
1软件的稳定性和可靠性评价。软件的稳定性指软件在一个运行周期内、在一定的压力条件下软件的出错几率、性能劣化趋势等并观察其运行环境内的应用服务器、数据库服务器等系统的稳定性。从用户角度看,软件在使用过程中如果出现系统故障、系统反应速度慢等就表明软件本身的可靠性需要提高。通常在软件交付用户使用前都要进行大量的系统功能测试和用户可靠性测试如果测试工作做得很好后期运行使用时这方面的问题会减少。
2软件是否满足了用户的需求。满足用户的需求是软件开发的基本要求。系统交付使用前需要用户对系统提供的需求进行评价。用户评价的标准就是归档的需求文档用户可以根据文档的要求逐个检查系统是否提供了相应的功能。只有软件满足了用户需求用户才会同意交付使用。
3软件实施给用户带来的好处。这是用户需要软件开发的原因。通常体现为价值指标,如节省多少人工成本节省业务流程时间减小数据质量出错率等。软件交付用户使用后一段时间用户可以测量相应的指标是否满足了之前设定的目标对新系统给予评价。
13.7 软件过程改进
处于激烈市场竞争中的软件开发机构若想在预定的期限内用有限的资金满足不断增长的软件产品的需求就必须不断加强软件开发过程的管理对软件开发的所有环节施加有效的管理和控制将软件的开发逐渐转变成为一种工业化的生产过程。
软件过程改进Software Process ImprovementSPI用于帮助软件企业对其软件生产过程进行计划、过程诊断、改进方案的制订及实施等工作。它的实施对象是软件企业的软件过程即软件产品的生产过程也包括配置管理、软件维护等辅助过程。目前使用最多的软件过程改进模型包括 CMM、CMMI、ISO9000 和 ITIL 等系列标准。
1CMM W-CMM软件能力成熟度模型为软件企业的过程能力提供了一个阶梯式的进化框架阶梯共有五级。第一级实际上是一个起点任何准备按 CMM 体系进化的企业都自然处于这个起点上并通过这个起点向第二级迈进。除第一级外每一级都设定了一组目标如果达到了这组目标则表明达到了这个成熟级别可以向下一个级别迈进。 CMM 体系不主张跨越级别的进化因为从第二级起每一个低的级别实现均是高的级别实现的基础。
1初始级。初始级的软件过程是未加定义的随意过程项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范但若这些规范未能覆盖基本的关键过程要求且执行没有政策、资源等方面的保证时那么它仍然被视为初始级。
2可重复级。根据多年的经验和教训人们总结出软件开发的首要问题不是技术问题而是管理问题。因此第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程一个可重复的过程则能逐渐进化和成熟。第二级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。实施这些过程从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
3定义级。在第二级仅定义了管理的基本过程而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准而且无论是管理还是工程开发都需要一套文档化的标准并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程剪裁出与项目适宜的过程并执行这些过程。过程的剪裁不是随意的在使用前需经过企业有关人员的批准。
4管理级。第四级的管理是量化的管理。所有过程需建立相应的度量方式所有产品的质量包括工作产品和提交给用户的产品需有明确的度量指标。这些度量应是详尽的且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成一种标准的工业生产活动。
5优化级。第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程即优化执行步骤。如果一个企业达到了这一级那么表明该企业能够根据实际的项目性质、技术等因素不断调整软件生产过程以求达到最佳。
2CMMI CMMICapability MaturityModel Integration即能力成熟度模型集成。CMMI 是 CMM 模型的最新版本。CMMI 与 CMM 最大的不同点在于CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分即系统工程SE和软件工程SW是基本的科目对于有些组织还可以应用集成产品和过程开发方面IPPD的内容如果涉及供应商外包管理可以相应地应用SSSupplier Sourcing部分。
CMMI 有两种表示方法一种是和软件 CMM 一样的阶段式表现方法另一种是连续式的表现方法。这两种表现方法的区别是阶段式表现方法仍然把 CMMI 中的若干个过程区域分成了 5 个成熟度级别帮助实施 CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将 CMMI 中过程区域分为四大类过程管理、项目管理、工程及支持。对于每个大类中的过程区域又进一步分为基本的和高级的。这样在按照连续式表示方法实施 CMMI 的时候一个组织可以把项目管理或者其他某类的实践一直做到最好而其他方面的过程区域可以完全不必考虑。
3ISO 9000 国内软件公司采用的 ISO 9000 系列质量体系认证通常有 ISO 9001 的 1994 年版和2000 年版。ISO 9001 和 CMM 非常相似的是两者都共同着眼于质量和过程管理而且它们都是基于戴明博士的全面质量管理 TQM 产生的因此不存在任何矛盾的地方。但是它们的基础是不同的ISO9001ISO9000 标准系列中关于软件开发和维护的部分确定一个质量体系的最少需求而 CMM 强调持续过程改进。在 1994 年版的 ISO 9001 中CMM 2 级的 6 个关键过程区域所涉及的部分基本上都比较明确地作出了要求而 CMM 3 级的7 个关键过程区域中所涉及的内容大多数都提到了但做出的要求不是非常详细。很多实施了 94 版 ISO9000 的企业在了解了 SW-CMM 以后普遍反映 CMM 比 ISO 的要求明确、详细得多。如果 94 版 ISO 实施的效果很好的话实施 CMM 2 级工作量是可以减少很多的。而 2000 版的 ISO 则和 CMM 有更多的直接对应的关系甚至是大量 CMM 4 级和 5 级的要求。
4ITIL ITIL信息技术基础设施库是英国政府中央计算机与电信管理中心CCTA在 20 世纪 90 年代初期发布的一套 IT 服务管理最佳实践指南。在此之后CCTA 又在 HP、IBM、BMC、CA 和 Peregrine 等主流 IT 资源管理软件厂商近年来所做出的一系列实践和探索的基础之上总结了 IT 服务的最佳实践经验形成了一系列基于流程的方法用以规范 IT 服务的水平并在 2000 年至 2003 年期间推出新的 ITIL V2.0 版本于 2007 年推出 V3.0 版本。
ITIL 为企业的 IT 服务管理实践提供了一个客观、严谨、可量化的标准和规范企业的IT 部门和最终用户可以根据自己的能力和需求定义自己所要求的不同服务水平参考 ITIL 来规划和制定其 IT 基础架构及服务管理从而确保 IT 服务管理能为企业的业务运作提供更好的支持。对企业来说实施 ITIL 的最大意义在于把 IT 与业务紧密地结合起来从而让企业的 IT 投资回报最大化。
