软件项目管理规范.docx
- 文档编号:7410234
- 上传时间:2023-01-23
- 格式:DOCX
- 页数:11
- 大小:154.07KB
软件项目管理规范.docx
《软件项目管理规范.docx》由会员分享,可在线阅读,更多相关《软件项目管理规范.docx(11页珍藏版)》请在冰豆网上搜索。
软件项目管理规范
软件项目管理规范
一、软件项目治理的定义
软件项目治理是软件工程和项目治理的交叉学科,软件项目治理的概念涵盖了治理软件产品开发所必须的知识、技术及工具。
依照美国项目治理协会PMI对项目治理的定义能够将软件项目治理定义为:
在软件项目活动中运用一系列知识、技能、工具和技术,以满足软件需求方的整体要求。
软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等,所有这些活动都必须进行治理,软件项目治理贯穿于软件工程的演化过程之中,如图1所示。
图1软件工程的演化过程
二、软件项目治理的过程
为保证软件项目获得成功,必须清晰其工作范畴、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。
软件项目的治理工作在技术工作开始之前就应开始,而在软件从概念到实现的过程中连续进行,且只有当软件开发工作最后终止时才终止。
治理的过程分为如下几个步骤:
(1)启动软件项目
启动软件项目是指必须明确项目的目标和范畴、考虑可能的解决方案以及技术和治理上的要求等,这些信息是软件项目运行和治理的基础。
(2)制定项目打算
软件项目一旦启动,就必须制定项目打算。
打算的制定以下面的活动为依据。
●估算项目所需要的工作量
●估算项目所需要的资源
●依照工作量制定进度打算,继而进行资源分配
●做出配置治理打算
(3)跟踪及操纵项目打算
在软件项目进行过程中,严格遵守项目打算,关于一些不可幸免的变更,要进行适当的操纵和调整,但要确保打算的完整性和一致性。
(4)评审项目打算
对项目打算的完成程度进行评审。
并对项目的执行情形进行评判。
(5)编写治理文档
项目治理人员依照软件合同确定软件项目是否完成。
项目一旦完成,那么检查项目完成的结果和中间记录文档,并把所有的结果记录下来形成文档而储存。
三、软件项目治理的内容
软件项目治理的内容涉及上述软件项目治理过程的方方面面,概括起来要紧有如下几
项。
〔1〕软件项目需求治理
软件需求是软件工程过程中的重要一环,是软件设计的基础,也是用户和软件工程人员之间的桥梁。
简单地说,软件需求确实是确定系统需要做什么,严格意义上,软件需求是系统或软件必须达到的目标与能力。
1、目标
需求治理是一种猎取、组织并记录软件需求的系统化方案,同时也是一个使客户与项目开发组对不断变更的软件需求达成并保持一致的过程。
在需求治理中,软件工程组的工作是采取适当的措施来保证分配的需求,即要将分配的需求文档化,操纵需求的变化,负责项目实施过程中需求的实现情形。
需求治理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同明白得。
需求治理的目标有两个:
●使软件需求受控,并建立供软件工程和治理使用的需求基线。
●使软件打算、产品和活动与软件需求保持一致。
在需求治理过程,为实现第一个目标,必须操纵需求基线的变动,按照变更操纵的标准和规范的过程进行需求变更操纵和版本操纵;为实现第二个目标,必须就变更和软件项目各小组达成共识,对软件项目打算做出调整,其中包括人员的安排、用户的沟通、成本的调整、进度的调整等。
2、原那么
为进行有效的需求治理,一样要遵循如下五条原那么:
●需求一定要分类治理
进行软件项目治理的时候,一定要将软件需求分出层次。
不同层次需求的侧重点、描述方式、治理方式是不同的。
●需求必须分优先级
在软件项目中,假如显现过多的需求,通常会导致项目超出预算和预定进度,最终导致软件项目的失败,因而需求的优先级可能比需求本身更加重要。
●需求必须文档化
需求必须有文档记录。
该文档必须是正确的、最新的、可治理的、可明白得的,是通过验证的,是在受控的状态下变更的。
●需求一旦变化,就必须对需求变更的阻碍进行评估
不管需求变化的程度如何,只要需求变化了就必须进行评估,这是差不多的原那么。
●需求治理必须与需求工程的其他活动紧密整合
进行需求治理一定不能脱离需求工程,需求工程包括了需求猎取、需求分析、需求描述、需求验证、需求治理,因而需求治理必须与前面的几个需求时期保持紧密相关。
3、需求治理活动
需求治理在需求开发的基础上进行,贯穿于整个软件项目过程,是软件项目治理的一部分。
在软件项目进行的过程中,不管正处于哪个时期,一旦有需求错误显现或任何有关需求的变更显现,都需要需求治理活动来解决。
需求治理是一个对系统需求变更了解和操纵的过程。
初始需求导出的同时就启动了需求治理规划,一旦形成了需求文档的草稿版本,需求活动就开始了。
需求活动的具体内容如表1所示。
需求治理活动
活动的任务
变更操纵
建议需求变更并分析其阻碍,做出是否变更的决策
版本操纵
确定单个需求和SRS〔即功能规格说明〕的版本
需求跟踪
定义关于其他需求及系统元素的联系链
需求状态
定义并跟踪需求的状态
表1需求治理活动
4、需求治理质量保证
●需求验证过程
需求验证专门重要,假如在构造设计开始之前,通过验证基于需求的测试打算和原型测试来
验证需求的正确性及其质量,就能大大减少项目后期的返工现象。
需求验证可按以下步骤进行:
审察需求文档依据需求编写测试用例编写用户手册确定合格的标准
●验证的内容
在需求验证过程中,要对需求文档中定义的需求执行多种类型的检查。
有效性检查----关于每项需求都必须证明它是正确有效的,确实能解决用户面对的问题。
一致性检查----在需求文档中,需求不应该冲突,即对同一个系统功能不应显现不同的描述或相互矛盾的约束。
完备性检查----需求文档应该包括所有系统用户想要的功能和约束。
现实性检查----检查需求以保证能利用现有技术实现。
可检验性检查----描述的需求能够实际测试。
可跟踪性检查----需求的出处被清晰地记录,每一系统功能都能被跟踪到要求它的需求集合,每一项需求都能追溯到特定用户的要求。
可调剂性检查----需求变更能够不对其他系统带来大规模的阻碍。
可读性检查----需求说明能否被系统购买者和最终用户读明白。
●需求评审
需求分析完成后,应由用户和系统分析员共同进行需求评审。
鉴于需求规格说明是软件设计的基础,需求评审需要有客户方和承包商方的人员共同参与,检查文档中的不规范之处和遗漏之处。
(2)软件项目估算与进度治理
1、软件项目估算
软件项目估算包括工作量估算和成本估算两个方面。
软件估算作为软件项目治理的一项重要内容,是确保软件项目成功的关键因素。
估确实是指通过推测构造软件项目所需要的工作量的过程。
初步的估算用于确定软件项目的可行性,详细的估算用于指导项目打算的制定。
2、软件规模
●工作分解结构
对软件项目进行估算遇到的第一个问题确实是软件规模,即软件的程序量。
软件规模是软件工作量的要紧阻碍因素。
软件项目的设计有一个分层结构,这一分层结构就对应着工作分解结构〔WBS,WorkBreakdownStructure〕,它将软件过程和软件产品结构联系起来。
图2是一个典型的WBS结构。
图2典型的WBS
有了工作分解结构之后,还必须定义度量标准用以对软件规模进行估量。
常用的软件规模度量标准有两种:
代码行LOC(LinesofCode)和功能点FP(FunctionPoints)。
●代码行
代码行LOC是常用的源代码程序长度的度量标准,指源代码的总行数。
源代码中除了可执行语句外,还有关心明白得的注释语句。
●功能点
功能点度量是在需求分析时期基于系统功能的一种规模估量方法,该方法通过差不多初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目,从而确定功能点数量。
3、软件项目成本估算
成本估确实是对完成软件项目所需费用的估量和打算,是软件项目打算中的一个重要组成部分。
成本估算步骤如下:
建立目标-----规划需要的数据和资源------确定软件需求------拟定可行的细节
------运用多种独立的技术和原始资料------比较并迭代各个估算值------随访跟踪
4、软件项目进度治理
●制定项目打算
项目打算在项目开始的时候制定,并随着项目的进展不断进展。
软件项目打算的要素包括目标、合理的概念设计、工作分解结构、规模设计、工作量估量和项目进度安排。
项目打算为治理者提供了依照打算定期评审和跟踪项目进展的基础。
●进度安排
在确定了项目的资源〔总成本及时刻等〕后,把其分配到各个项目开发时期中,即确定项目的进度。
项目各时期的工作量能够参考表2:
项目时期
工作量〔%〕
概念设计
3.49
详细设计
11.05
编码和单元测试
23.17
集成测试
27.82
软件验证
34.47
表2项目各时期的工作量
项目整体进度安排的过程如下:
①依照项目总体进度目标,编制人员打算。
2将各时期所需要的资源和能够取得的资源进行比较,确定各时期的初步进度,然后
确定整个项目的初步进度。
③对初步进度打算进行评审,确保该打算满足要求,否那么就重复上面的步骤。
进度安排的详细程度取决于相应工作分解结构的详细程度,而工作分解结构又取决于项目当前所处时期与历史体会。
进度安排打算随着项目的进展而动态调整,逐步趋于更加详细准确。
〔3〕代码治理
关于软件过程中经常遇到的变更问题,假如没有有效的机制进行操纵,将会引起庞大的纷乱,导致项目的失败.代码治理确实是作为变更操纵机制而引入到软件项目中的,其关键任务是操纵代码变更活动,在软件项目治理中占有重要地位。
编码规范:
代码头标示命名规那么
源代码文件头注释规范
/**********************************/
/*文件名:
c_inter.cpp*/
/*模块名:
C-Interface*/
/*创建者:
yourname日期:
2003-7-10*/
/*修改者:
日期:
*/
/**/
/*功能描述:
*/
/**********************************/
〔4〕测试打算
软件测试打算的目标是找出软件缺陷,并尽可能早一些保证得到修复。
利用组织良好的测试打算、测试案例、测试报告交流和制定测试工作是达到目标的保证。
测试打算应该包括:
·建立每个测试时期的目标。
·确定每项测试活动的进度和职责。
·确定工具、设施和测试库的可用性。
·建立用于打算和进行测试以及报告测试结果的规程和标准。
·制定衡量测试成功与完成的准那么。
第一进行单元测试,然后进行集成测试。
〔5〕工具治理
开发工具治理:
Myeclipse6.0
测试工具治理:
四、软件开发过程
我们用瀑布模型来描述一个软件开发的生命周期,如图3所示:
图3软件开发生命周期(瀑布模型)
五、生命周期时期与文档、角色间的关系
软件开发生命周期与文档、角色之间的关系见表3:
生命周期时期
结果文档
参与角色
需求分析
需求规格说明
项目经理、系统分析员
概要设计
概要设计文档
项目经理、系统分析员
详细设计
详细设计文档
项目经理、系统分析员
编码
源代码
程序员
单元测试
测试报告
程序员
测试
测试报告
测试员
表3生命周期时期与文档、角色间的关系
六、项目角色职能
项目经理:
治理整个项目过程。
包括制定打算、项目跟踪、项目成员的角色分配、和谐、治理,软件配置治理,文档标准制定,文档审查等。
技术经理:
对项目的技术及方案总体把握,配合系统分析员做一些大的工作,审查系统分析员做好的各种设计,对系统分析员提出的问题一起去解决。
系统分析员:
和项目经理一起参与需求分析,形成需求规格说明文档。
依照需求规格说明文档做概要设计,形成概要设计文档。
依照概要设计文档做详细设计文档。
在编码及测试时期协助程序员、测试人员编码和测试。
程序员:
依照详细设计文档进行编码,并对自己的代码模块进行单元测试,形成单元测试报告。
测试员:
在编码完成后,做系统测试,形成测试报告,通知项目经理测试结果。
文档治理员:
对所有项目文档进行治理,保持所有文档的同步与一致。
七、项目成员结构
八、项目实施时期
整个项目分为三个时期:
开始时期、实施时期、收尾时期。
〔1〕、项目开始时期
1确定项目组成员
2确定组织结构
3确定项目组成员在项目中的具体角色及其工作职责
〔2〕、项目实施时期
1项目经理制定项目开发打算
2预备基础设施〔软件、文档摸板、工具〕
3按照项目开发打算由项目经理组织实施
1每周定期召开项目组全体成员会议
会议内容包括:
时期总结、当前项目开发进度、下时期打算安排、当前遇到的各种困难〔技术上的、或组织上的或人力上的等等〕。
2项目组成员每周撰写周打算、周总结。
3项目所有相关文档、代码要保持同步更新及版本一致。
4项目组成员在每天开始工作前,下载所有最新文档与代码。
在每天工作终止后上传所有自己更新的文档与代码。
〔3〕、项目收尾时期
总结
文件存档
九、项目服务规范
项目服务贯穿于整个项目,从开始至收尾,服务对象为客户。
1.日报、周报、月报
自项目正式启动之日起,项目组成员需向项目经理提供相关工作日报、周报、月报。
项目经理整合后需每日向客户提供项目情形日报,每周提供周报、每月提供月报〔注:
可忽略日报,视项目情形而定〕。
2.问题响应时刻
客户提出问题需做到及时响应,并分出问题的轻重缓急。
暂定方法为:
●客户提出问题,做到第一时刻响应,如:
〝已收到,稍后给您回复!
〞;
●所有问题汇总后上报相关部门负责人,且每个问题均需分出〝优先级〞:
高、中、低三个等级;
✧优先级为〝高〞的问题:
第一时刻解决,并给出解决时刻;
✧优先级为〝中〞的问题:
正常工作安排,给出解决时刻按;
✧优先级为〝低〞的问题:
可暂缓处理,但需给出最终解决时刻;
✧问题解决完成,反馈给客户经理时,需附上解决方法,如临时无法解决,需说明缘故;
●客户经理需当天邮件反馈客户,并提出修改时刻范畴。
3.跟踪提醒服务
项目进行过程中,会需要客户提供专门多项目相关的文档资料,项目经理、需求分析师需及时提醒客户相关负责人索取。
需求确认也要及时,便与项目的快速启动。
解决问题反馈:
问题解决后,需要收到客户的反馈信息,注意提醒客户。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 规范
![提示](https://static.bdocx.com/images/bang_tan.gif)