软件项目管理规范标准

软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开辟所必须的知识、技术及工具。

根据美国项目管理协会 PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。

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

软件项目管理
问题定义可行性与
分析需求
系统设计程序实现测试确认维护支持
图 1 软件工程的演化过程
为保证软件项目获得成功，必须清晰其工作围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。

软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且惟独当软件开辟工作最后结束时才终止。

管理的过程分为如下几个步骤：
启动软件项目是指必须明确项目的目标和围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。

软件项目一旦启动，就必须制定项目计划。

计划的制定以下面的活动为依据。

估算项目所需要的工作量
估算项目所需要的资源
根据工作量制定进度计划，继而进行资源分配
做出配置管理计划
在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控
制和调整，但要确保计划的完整性和一致性。

对项目计划的完成程度进行评审。

并对项目的执行情况进行评价。

项目管理人员根据软件合同确定软件项目是否完成。

项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。

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

软件需软件工程过程中的重要一环，是软件设计的基础，也是用户和软件工程人员之间的桥梁。

简单地说，软件需求就是确定系统需要做什么，严格意义上，软件需系统或者软件必须达到的目标与能力。

1 、目标
需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。

在需求管理中，软件工程组的工作是采取适当的措施来保证分配的需求，即要将分配的需求文档化，控制需求的变化，负责项目实施过程中需求的实现情况。

需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。

需求管理的目标有两个：
使软件需求受控，并建立供软件工程和管理使用的需求基线。

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

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

2 、原则
为进行有效的需求管理，普通要遵循如下五条原则：
需求一定要分类管理
进行软件项目管理的时候，一定要将软件需求分出层次。

不同层次需求的侧重点、描述方式、管理方式是不同的。

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

需求必须文档化
需求必须有文档记录。

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

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

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

3 、需求管理活动
需求管理在需求开辟的基础上进行，贯通于整个软件项目过程，是软件项目管理的一部份。

在软件项目进行的过程中，无论正处于哪个阶段，一旦有需求错误浮现或者任何有关需求的变更浮现，都需要需求管理活动来解决。

需求管理是一个对系统需求变更了解和控制的过程。

初始需求导出的同时就启动了需求管理规划，一旦形成为了需求文档的草稿版本，需求活动就开始了。

需求活动的具体容如表 1所示。

需求管理活动变更控制
版本控制
需求跟踪
需求状态
活动的任务
建议需求变更并分析其影响，做出是否变更的决策确定单个需求和 SRS (即功能规格说明)的版本定义对于其他需求及系统元素的联系链
定义并跟踪需求的状态
表 1 需求管理活动
4 、需求管理质量保证
需求验证过程
需求验证很重要，如果在构造设计开始之前，通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量就，能大大减少项目后期的返工现象。

需求验证可按以下步骤进行：审察需求文档依据需求编写测试用例编写用户手册确定合格的标准验证的容
在需求验证过程中，要对需求文档中定义的需求执行多种类型的检查。

有效性检查----对于每项需求都必须证明它是正确有效的，确实能解决用户面对的问题。

一致性检查----在需求文档中，需求不应该冲突，即对同一个系统功能不应浮现不同的描述或者相互矛盾的约束。

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

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

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

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

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

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

需求评审
需求分析完成后，应由用户和系统分析员共同进行需求评审。

鉴于需求规格说明是软件设计的基础，需求评审需要有客户方和承包商方的人员共同参预，检查文档中的不规之处和遗漏之处。

1 、软件项目估算
软件项目估算包括工作量估算和成本估算两个方面。

软件估算作为软件项目管理的一项重要容，是确保软件项目成功的关键因素。

估算是指通过预测构造软件项目所需要的工作量的过程。

初步的估算用于确定软件项目的可行性，详细的估算用于指导项目计划的制定。

2 、软件规模
工作分解结构
对软件项目进行估算遇到的第一个问题就是软件规模，即软件的程序量。

软件规模是软件工作量的主要影响因素。

软件项目的设计有一个分层结构，这一分层结构就对应着工作分解结构(WBS，Work Breakdown Structure) ，它将软件过程和软件产品结构联系起来。

图 2是一个典型的 WBS结构。

图 2 典型的 WBS
有了工作分解结构之后，还必须定义度量标准用以对软件规模进行估计。

常用的软件规模 度量标准有两种：代码行 LOC(Lines of Code)和功能点FP(Function Points) 。

代码行
代码行 LOC 是常用的源代码程序长度的度量标准，指源代码的总行数。

源代码中除了可执 行语句外，还有匡助理解的注释语句。

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

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

成本估算步骤如下：
建立目标-----规划需要的数据和资源-----确-定软件需求------拟定可行的细节 ------运用多种独立的技术和原始资料------ 比较并迭代各个估算值------随访跟踪 4 、软件项目进度管理
制定项目计划
项目计划在项目开始的时候制定，并随着项目的发展不断发展。

软件项目计划的要素包括 目标、合理的概念设计、工作分解结构、规模设计、工作量估计和项目进度安排。

项目计划为 管理者提供了根据计划定期评审和跟踪项目发展的基础。

进度安排
在确定了项目的资源(总成本及时间等)后，把其分配到各个项目开辟阶段中，即确定项 目的进度。

项目各阶段的工作量可以参考表 2：
系统
子系统
模块 模块 模块 模块 模块 模块 模块 模块 模块
子系统
子系统
表 2 项目各阶段的工作量
项目整体进度安排的过程如下：
① 根据项目总体进度目标，编制人员计划。

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

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

进度安排的详细程度取决于相应工作分解结构的详细程度，而工作分解结构又取决于项目 当前所处阶段与历史经验。

进度安排计划随着项目的发展而动态调整，逐渐趋于更加详细准确。

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

编码规：
代码头标示 命名规则
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ /* 文件名 ： c_inter.cpp */ /* 模块名 ： C- Interface */ /* 创建者 ： your name 日期 ： 2003-7-10 */ /* 修改者 ： 日期 ： */ /* */ /* 功能描述 ： */ /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
项目阶段 概念设计 详细设计 编码和单元测试 集成测试 软件验证
工作量(%) 3.49 11.05 23.17 27.82 34.47
软件测试计划的目标是找出软件缺陷，并尽可能早一些保证得到修复。

利用组织良好的测 试计划、测试案例、测试报告交流和制定测试工作是达到目标的保证。

测试计划应该包括： · 建立每一个测试阶段的目标。

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

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

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

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

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

开辟工具管理：
Myeclipse6.0
测试工具管理：
我们用瀑布模型来描述一个软件开辟的生命周期，如图 3所示：
图 3 软件开辟生命周期(瀑布模型)
需求规格说明
概要设计文档
详细设计文档
源 代 码
测试报告
测试报告
验收报告
需求分析
概要设计
详细设计
编 码
单元测试
集成测试
测试报告
软件开辟生命周期与文档、角色之间的关系见表 3：
表 3 生命周期阶段与文档、角色间的关系
管理整个项目过程。

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

对项目的技术及方案总体把握，配合系统分析员做一些大的工作，审查系统分析员做好的 各种设计，对系统分析员提出的问题一起去解决。

和项目经理一起参预需求分析，形成需求规格说明文档。

根据需求规格说明文档做概要设 计，形成概要设计文档。

根据概要设计文档做详细设计文档。

在编码及测试阶段协助程序员、 测试人员编码和测试。

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

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

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

参预角色
项目经理、系统分析员 项目经理、系统分析员 项目经理、系统分析员 程序员 程序员 测试员
生命周期阶段 需求分析 概要设计 详细设计 编码 单元测试 测试
结果文档 需求规格说明 概要设计文档 详细设计文档 源代码 测试报告 测试报告
整个项目分为三个阶段：开始阶段、实施阶段、收尾阶段。

(1) 、项目开始阶段
1 确定项目组成员
2 确定组织结构
3 确定项目组成员在项目中的具体角色及其工作职责 (2) 、项目实施阶段
1 项目经理制定项目开辟计划
2 准备基础设施(软件、文档摸板、工具)
3 按照项目开辟计划由项目经理组织实施
① 每周定期召开项目组全体成员会议
会议容包括：阶段总结、当前项目开辟进度、下阶段计划安排、当前遇到的各种
艰难(技术上的、或者组织上的或者人力上的等等) 。

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

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

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

在每天工作结束后上
传所有自己更新的文档与代码。

(3) 、项目收尾阶段
总结 文件存档
项目服务贯通于整个项目，从开始至收尾，服务对象为客户。

项目经理
系统分析员
程序员 程序员 程序员 程序员 测试员 测试员 文档管理员
技术经理
1. 日报、周报、月报
自项目正式启动之日起，项目组成员需向项目经理提供相关工作日报、周报、月报。

项目经理整合后需每日向客户提供项目情况日报，每周提供周报、每月提供月报(注：可 忽略日报，视项目情况而定) 。

2. 问题响应时间
客户提出问题需做到及时响应，并分出问题的轻重缓急。

暂定办法为：
客户提出问题，做到第一时间响应，如： “已收到，稍后给您回复！”；
所有问题汇总后上报相关部门负责人，且每一个问题均需分出“优先级”：高、中、
低三个等级；
今 优先级为“高”的问题：第一时间解决，并给出解决时间； 今 优先级为“中”的问题：正常工作安排，给出解决时间按； 今 优先级为“低”的问题：可暂缓处理，但需给出最终解决时间；
今 问题解决完成，反馈给客户经理时，需附上解决方法，如暂时无法解决，需
说明原因；
客户经理需当天反馈客户，并提出修改时间围。

客户
了解项目进度
客户经理
日报、周报、月报
3. 跟踪提醒服务
项目进行过程中，会需要客户提供不少项目相关的文档资料，项目经理、需求分析师 需及时提醒客户相关负责人索取。

需求确认也要及时，便与项目的快速启动。

解决问题反馈：问题解决后，需要收到客户的反馈信息，注意提醒客户。

邮件反馈
反馈解决方法
反馈解决时间
解决问题
客户
提出问题
客户经理
And
分出优先级
提交相关人员
第一时间响应
And。