软件项目管理系统要求规范

软件项目管理规范

一、软件项目管理的定义

软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。

软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。

图1 软件工程的演化过程

二、软件项目管理的过程

为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤：

（1）启动软件项目

启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。

（2）制定项目计划

软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。

·估算项目所需要的工作量

·估算项目所需要的资源

·根据工作量制定进度计划，继而进行资源分配

·做出配置管理计划

（3）跟踪及控制项目计划

在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控制和调整，但要确保计划的完整性和一致性。

（4）评审项目计划

对项目计划的完成程度进行评审。并对项目的执行情况进行评价。

（5）编写管理文档

项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。

三、软件项目管理的内容

软件项目管理的内容涉及上述软件项目管理过程的方方面面，概括起来主要有如下几

项。

（1）软件项目需求管理

软件需求是软件工程过程中的重要一环，是软件设计的基础，也是用户和软件工程人员之间的桥梁。简单地说，软件需求就是确定系统需要做什么，严格意义上，软件需求是系统或软件必须达到的目标与能力。

1、目标

需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。需求管理的目标有两个：

·使软件需求受控，并建立供软件工程和管理使用的需求基线。

·使软件计划、产品和活动与软件需求保持一致。

在需求管理过程，为实现第一个目标，必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制；为实现第二个目标，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。

2、原则

为进行有效的需求管理，一般要遵循如下五条原则：

·需求一定要分类管理

进行软件项目管理的时候，一定要将软件需求分出层次。不同层次需求的侧重点、描述方式、管理方式是不同的。

·需求必须分优先级

在软件项目中，如果出现过多的需求，通常会导致项目超出预算和预定进度，最终导致软件项目的失败，因而需求的优先级可能比需求本身更加重要。

·需求必须文档化

需求必须有文档记录。该文档必须是正确的、最新的、可管理的、可理解的，是经过验证的，是在受控的状态下变更的。

·需求一旦变化，就必须对需求变更的影响进行评估

无论需求变化的程度如何，只要需求变化了就必须进行评估，这是基本的原则。

·需求管理必须与需求工程的其他活动紧密整合

进行需求管理一定不能脱离需求工程，需求工程包括了需求获取、需求分析、需求描述、需求验证、需求管理，因而需求管理必须与前面的几个需求阶段保持密切相关。

3、需求管理活动

需求管理在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误出现或任何有关需求的变更出现，都需要需求管理活动来解决。需求管理是一个对系统需求变更了解和控制的过程。初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求活动就开始了。需求活动的具体内容如表1所示。

表1 需求管理活动

4、需求管理质量保证

· 需求验证过程

需求验证很重要，如果在构造设计开始之前，通过验证基于需求的测试计划和原型测试来 验证需求的正确性及其质量，就能大大减少项目后期的返工现象。需求验证可按以下步骤进行：

依据需求编写测试用例 编写用户手册 确定合格的标准 · 在需求验证过程中，要对需求文档中定义的需求执行多种类型的检查。

有效性检查----对于每项需求都必须证明它是正确有效的，确实能解决用户面对的问题。 一致性检查----在需求文档中，需求不应该冲突，即对同一个系统功能不应出现不同的描述或相互矛盾的约束。

完备性检查----需求文档应该包括所有系统用户想要的功能和约束。

现实性检查----检查需求以保证能利用现有技术实现。

可检验性检查----描述的需求能够实际测试。

可跟踪性检查----需求的出处被清晰地记录，每一系统功能都能被跟踪到要求它的需求集合，每一项需求都能追溯到特定用户的要求。

可调节性检查----需求变更能够不对其他系统带来大规模的影响。

可读性检查----需求说明能否被系统购买者和最终用户读懂。

· 需求评审

需求分析完成后，应由用户和系统分析员共同进行需求评审。鉴于需求规格说明是软件设计的基础，需求评审需要有客户方和承包商方的人员共同参与，检查文档中的不规范之处和遗漏之处。

（2） 软件项目估算与进度管理

1、软件项目估算

软件项目估算包括工作量估算和成本估算两个方面。软件估算作为软件项目管理的一项重要内容，是确保软件项目成功的关键因素。估算是指通过预测构造软件项目所需要的工作量的过程。初步的估算用于确定软件项目的可行性，详细的估算用于指导项目计划的制定。

2、软件规模

· 工作分解结构

对软件项目进行估算遇到的第一个问题就是软件规模，即软件的程序量。软件规模是软件工作量的主要影响因素。软件项目的设计有一个分层结构，这一分层结构就对应着工作分解结构（WBS,Work Breakdown Structure ），它将软件过程和软件产品结构联系起来。图2是一个典型的WBS 结构。

图2 典型的WBS

有了工作分解结构之后，还必须定义度量标准用以对软件规模进行估计。常用的软件规模度量标准有两种：代码行LOC(Lines of Code)和功能点FP(Function Points)。

·代码行

代码行LOC是常用的源代码程序长度的度量标准，指源代码的总行数。源代码中除了可执行语句外，还有帮助理解的注释语句。

·功能点

功能点度量是在需求分析阶段基于系统功能的一种规模估计方法，该方法通过已经初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目，从而确定功能点数量。3、软件项目成本估算

成本估算是对完成软件项目所需费用的估计和计划，是软件项目计划中的一个重要组成部分。

成本估算步骤如下：

建立目标-----规划需要的数据和资源------确定软件需求------拟定可行的细节

------运用多种独立的技术和原始资料------比较并迭代各个估算值------随访跟踪

4、软件项目进度管理

·制定项目计划

项目计划在项目开始的时候制定，并随着项目的进展不断发展。软件项目计划的要素包括目标、合理的概念设计、工作分解结构、规模设计、工作量估计和项目进度安排。项目计划为管理者提供了根据计划定期评审和跟踪项目进展的基础。

·进度安排

在确定了项目的资源（总成本及时间等）后，把其分配到各个项目开发阶段中，即确定项目的进度。项目各阶段的工作量可以参考表2：

表2 项目各阶段的工作量

项目整体进度安排的过程如下：

①根据项目总体进度目标，编制人员计划。

②将各阶段所需要的资源和可以取得的资源进行比较，确定各阶段的初步进度，然后

确定整个项目的初步进度。

③对初步进度计划进行评审，确保该计划满足要求，否则就重复上面的步骤。

进度安排的详细程度取决于相应工作分解结构的详细程度，而工作分解结构又取决于项目当前所处阶段与历史经验。进度安排计划随着项目的进展而动态调整，逐渐趋于更加详细准确。

（3）代码管理

对于软件过程中经常遇到的变更问题,如果没有有效的机制进行控制,将会引起巨大的混乱,导致项目的失败.代码管理就是作为变更控制机制而引入到软件项目中的,其关键任务是控制代码变更活动,在软件项目管理中占有重要地位。

用SourceSafe软件平台对代码进行管理，以保证对代码版本进行有效控制。

1、在SourceSafe中建立源代码管理数据库

首先启动Visual SourceSafe 6.0 Admin，单击Tool菜单，单击Create Database，然后在存储

区中适当的位置创建SourceSafe数据库。Visual SourceSafe就会在该位置创建一些目录和文件，其中包含一个叫srcsafe.ini的配置文件，当需要打开一个SourceSafe数据库时，只需要打开这个配置文件就可以了。

2、在SourceSafe中实现共享签出

①单击Users，单击Open SourceSafe Database，选择上一步中创建的数据库（即srcsafe.ini ），然后单击Open。

②在Tool菜单中，单击Options。然后在General选项卡上，选择Allow multiple checkouts，然后单击OK。

③在SourceSafe中添加用户

单击Users，单击Add User，在弹出的对话框中输入项目组中各个开发人员的用户名和密码，并设置权限，作为各个开发人员操作SourceSafe数据库的标识的权限。

上面三步创建了源代码管理数据库和及进行项目开发中各个开发人员访问源代码数据库的用户名和访问权限。开发人员每天上班时到SourceSafe数据库中将自己的代码取出来(Check Out)，每天下班前将自己的代码放进(Check In)SourceSafe数据库。

注意：开发人员在没有对IDE中的项目项事先执行Get操作的前提下，千万不要使用Check In命令。从源代码管理获取最新版本后，才可以将个人更改与SourceSafe上的主控副本合并。如果在没有获取最新版本的Web项目的情况下签入自上次签出后已发生更改的文件，则可能会造成数据的丢失。

编码规范：

代码头标示命名规则

源代码文件头注释规范

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */

/* 文件名： c_inter.cpp */

/* 模块名： C-Interface */

/* 创建者： your name 日期： 2003-7-10 */

/* 修改者：日期： */

/* */

/* 功能描述： */

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */

（4）测试计划

软件测试计划的目标是找出软件缺陷，并尽可能早一些保证得到修复。利用组织良好的测试计划、测试案例和测试报告交流和制定测试工作是达到目标的保证。测试计划应该包括：·建立每个测试阶段的目标。

·确定每项测试活动的进度和职责。

·确定工具、设施和测试库的可用性。

·建立用于计划和进行测试以及报告测试结果的规程和标准。

·制定衡量测试成功与完成的准则。

首先进行单元测试，然后进行集成测试。

（5）工具管理

开发工具管理：

Visual https://www.360docs.net/doc/5d10019970.html, 2003

Microsoft Sourcesafe

测试工具管理：

Nunit （单元测试工具）

四、软件开发过程

我们用瀑布模型来描述一个软件开发的生命周期，如图3所示：

图3 软件开发生命周期(瀑布模型)

五、生命周期阶段与文挡、角色间的关系

软件开发生命周期与文档、角色之间的关系见表3：

表3 生命周期阶段与文挡、角色间的关系

六、项目角色职能

项目经理：

管理整个项目过程。包括制定计划、项目跟踪、项目成员的角色分配、协调、管理，软件配置管理，文挡标准制定，文挡审查等。

技术经理：

对项目的技术及方案总体把握，配合系统分析员做一些大的工作，审查系统分析员做好的

各种设计，对系统分析员提出的问题一起去解决。

系统分析员：

和项目经理一起参与需求分析，形成需求规格说明文挡。根据需求规格说明文挡做概要设计，形成概要设计文挡。根据概要设计文挡做详细设计文挡。在编码及测试阶段协助程序员、测试人员编码和测试。

程序员：

根据详细设计文挡进行编码，并对自己的代码模块进行单元测试，形成单元测试报告。测试员：

在编码完成后，做系统测试，形成测试报告，通知项目经理测试结果。

文挡管理员：

对所有项目文挡进行管理，保持所有文挡的同步与一致。

七、项目成员结构

八、项目实施阶段

整个项目分为三个阶段：开始阶段、实施阶段、收尾阶段。

（1）、项目开始阶段

1 确定项目组成员

2 确定组织结构

3 确定项目组成员在项目中的具体角色及其工作职责

（2）、项目实施阶段

1 项目经理制定项目开发计划

2 准备基础设施（软件、文挡摸板、工具）

3 按照项目开发计划由项目经理组织实施

①每周定期召开项目组全体成员会议

会议内容包括：阶段总结、当前项目开发进度、下阶段计划安排、当前遇到的各

种困难（技术上的、或组织上的或人力上的等等）。

②项目组成员每周撰写周计划、周总结。

③项目所有相关文挡、代码要保持同步更新及版本一致。

④项目组成员在每天开始工作前，下载所有最新文挡与代码。在每天工作结束后上

传所有自己更新的文挡与代码。

（3）、项目收尾阶段

（2）总结

（3）文件存档

附录

附录1 项目开发计划

附录2 需求规格说明书

附录3 概要设计说明书

附录4 详细设计说明书

附录5 周计划

附录6 周总结

附录7 测试计划

附录8 产品及配置项标识规范