- 1、本文档共67页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件项目管理天津大学软件学院王 赞wangzan@tju.edu.cn 项目初始 项目计划 项目执行控制 项目结束RoadMap第二篇软件项目计划没有计划的情况协调性工作资源投入开发工作计划性工作有计划的情况协调性工作资源投入开发工作计划性工作计划的重要性PMI:项目成功的三大要素(法宝):计划、计划、计划计划是通向项目成功的路线图进度计划是最重要的计划项目进度计划编制进度计划的三步曲任务分解(WBS)--范围基准成本估算资源、进度安排--成本基准,进度基准 项目 初始 项目 计划 项目执 行控制 项目 结束范围计划 时间 计划 成本 计划 质量 计划 人力 计划 沟通 计划 风险 计划 合同 计划 集成 计划RoadMap软件项目管理第2章软件项目范围计划本章要点一、软件需求管理过程二、需求建模的基本方法三、任务分解过程四、任务分解方法五、任务分解检验软件需求需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。业务需求用户需求质量特性非功能性需求约束和假设功能需求系统需求软件需求规格软件需求的层次需求管理的重要性项目失败的原因分析平均值No. Top 10 Factors 1 4.5 Inadequate requirements specification 不充分的需求规范2 4.3 Changes in requirements 需求的改变3 4.2 Shortage of systems engineers 缺乏系统工程师缺乏了解软件特性的经理人4 4.1 Shortage of software managers 缺乏合格的项目经理5 4.1 Shortage of qualified project managers 缺乏软件工程师6 3.9 Shortage of software engineers 固定价合同7 3.8 Fixed- price contract Inadequate communications for system integration 8 3.8 系统集成阶段交流与沟通不充分, 9 3.6 团队缺乏经验Insufficient experience as team 10 缺乏应用领域专家3.6 Shortage of application domain experts Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Engineering Institute软件需求管理的过程需求确认需求获取需求分析需求验证编写需求规格需求变更需求变更需求工程基本任务需求工程需求开发需求管理需求获取需求分析变更管理需求验证需求规格说明需求获取图示需求获取软件需求 扩展需求基线需求用户要求需求分析定义需求分析是为最终用户所看到的系统建立一个概念模型,是对需求的抽象描述。 需求分析模型需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解,使之成为整个开发工作的基础。软件需求规格说明的原则从现实中分离功能,即描述要“做什么”而不是“怎样实现”采用一定的规格说明语言如果被开发软件只是一个大系统中的一个元素,那么整个大系统也包括在规格说明的描述之中规格说明应该包括系统运行环境规格说明应该是一个认识模型规格说明应该容许不完备性并允许扩充Case/ReqSpec-new.doc规格文档参考引言系统定义 应用环境功能规格 性能需求产品提交实现约束质量描述其它签字认证需求验证需求是正确的吗?需求是一致的吗?需求是完全的吗?需求是实际可行的吗?需求是必要的吗?需求是可检验的吗?需求是可跟踪的吗?最后的签字需求总在变化需求变更管理确定需求变更控制过程建立变更控制委员会(SCCB)进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性需求变更管理管理和控制需求基线的过程需求变更控制系统 一个正式的文档,说明如何控制需求变更 建立变更审批系统需求方开发方变更申请选择变更方式忽略SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划软件基线产品修改提交单申请人Bob申请日期2010。10.11项目名称项目管理系统阶段名称系统设计文件名称RCR-PM-01.doc, RCR-PM-02.doc,变更简述如下修改内容1)修改测试流程控制:将2个
文档评论(0)