工学软件项目计划

0软件项目管理信息科学与工程学院软件工程系崔焕庆2024/7/11RoadMap

项目结束

项目执行控制

项目计划

项目初始2024/7/12前情回顾项目立项阶段甲方：招标书、乙方选择、签署合同乙方：项目分析、竞标、签署合同项目章程：确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。生存期模型：瀑布、V、增量、原型、螺旋、渐近模型。3第二篇软件项目计划2024/7/14RoadMap

合同计划

风险计划

沟通计划

人力计划

质量计划

成本计划

时间计划

集成计划范围计划

项目结束

项目执行控制

项目计划

项目初始5第2章范围计划2024/7/16为什么进行范围计划？

做过项目的人可能会有这样的经历：一个项目做了很久，感觉总是做不完，就像是一个无底洞。用户总是有新需求要项目开发来做，就像用户在“漫天要价”，而开发方在“就地还钱”。实际上，这里涉及一个“范围管理”的概念。项目哪些该做，做到什么程度，哪些不该做，都是由“范围管理”来决定的。缺乏正确的项目范围界定是导致项目失败的主要原因之一。项目管理中最重要也是最难做的就是确定项目范围。2024/7/17

开发软件系统最为困难的部分就是准确说明开发什么。

——弗雷德里克·布鲁克斯2024/7/18什么是范围管理1.什么是范围？

产生项目产品所包括的所有工作及产生这些产品所用的过程。产品范围界定——产品或服务范围的特征和功能。工作范围界定——项目工作的完成，为的是能交付一个有特殊特征和功能的产品。2.范围管理

对项目包括什么和不包括什么的定义与控制过程。用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程，有一个共同的理解。2024/7/19本章要点一、关于软件需求二、需求管理过程三、编写需求规格的方法四、任务分解定义五、任务分解方法六、任务分解结果的检验七、案例分析2024/7/110软件需求的重要性

40%~60%的问题是在需求分析阶段埋下的隐患。40%的开发总费用是返工开销。70%~80%的返工是需求方面的错误导致的。80%的失败项目是需求分析不明确造成的。总之，好的需求管理是项目成功的第一位因素。采用需求管理可以给项目组带来很多的好处，直至项目取得成功。2024/7/111项目失败的原因分析No.

Top10Factors

平均值

1

Inadequaterequirementsspecification

4.5

2

Changesinrequirements

4.3

3

Shortageofsystemsengineers

4.2

4

Shortageofsoftwaremanagers

4.1

5

Shortageofqualifiedprojectmanagers

4.1

6

Shortageofsoftwareengineers

3.9

7

Fixed-pricecontract

3.8

8

Inadequatecommunicationsforsystemintegration

3.8

9

Insufficientexperienceasteam

3.6

10

Shortageofapplicationdomainexperts

3.6

Scale:5=VerySerious3=Serious1=NoSerious

Source:Carnegie-MellonUniversity,SoftwareEngineeringInstitute2024/7/112什么是软件需求需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。正在构建的系统必须符合的条件或具备的功能。——Rational用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。——MerlinDorfman、RichardH.Thayer2024/7/113软件需求的层次业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。

2024/7/114软件需求的层次业务需求用户需求描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件―响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

2024/7/115软件需求的层次业务需求用户需求功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求，因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。

三个层次2024/7/116软件需求的层次业务需求用户需求功能需求系统需求用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。2024/7/117软件需求的层次业务需求用户需求功能需求非功能性需求系统需求对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。2024/7/118软件需求的层次业务需求用户需求功能需求非功能性需求约束和假设系统需求限制了开发人员设计和构建系统时的选择范围。2024/7/119软件需求的层次业务需求用户需求功能需求软件需求规格Softwarerequirementspecification非功能性需求约束和假设系统需求2024/7/120软件需求的层次编号功能需求1提供病历信息录入2提供病历信息的条件查询3提供统计、月统计、年统计，并提供打印功能编号性能需求1必须支持100个客户的同时访问2应该在10秒内必须从10000条记录中检索出需要的患者信息3应该在2分钟之内给出季度统计报告2024/7/121本章要点一、关于软件需求二、需求管理过程三、编写需求规格的方法四、任务分解定义五、任务分解方法六、任务分解结果的检验七、案例分析2024/7/122需求工程

需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求工程需求管理需求开发需求获取需求分析需求规格编写需求验证变更管理2024/7/123

需求获取是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。

需求获取依据工具与技术成果项目章程干系人登记册访谈焦点小组会议引导式研讨会群体创新技术群体决策技术问卷调查观察原型法需求文件需求管理计划需求跟踪矩阵2024/7/124需求获取用户要求基线需求扩展需求软件需求主要任务：是和用户方的领导层、业务层人员访谈把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有系统的运行状况等信息。2024/7/125需求获取方法开始前：做好准备，写出访谈提纲进行中：要注意聆听和引导结束后：要写感谢信旁敲侧击的方式复述，复述，复述聆听不要指导两个人去访谈让被访者上司安排不要问太多2024/7/126需求获取方法头脑风暴法（集思广益会）德尔菲技术（1）根据问题的特点，选择和邀请相关专家。（2）将与问题有关的信息提供给专家，请他们各自独立发表自己的意见，并写成书面材料。（3）管理者收集并综合专家们的意见后，将综合意见反馈给各位专家，请他们再次发表意见。如果分歧很大，可以开会集中讨论；否则，管理者分头与专家联络。（4）如此反复多次，最后形成代表专家组意见的方案。2024/7/127需求获取方法其他方法：需求研讨会用例模型角色扮演原型法Q&A邮件提问电视电话会议访谈2024/7/128需求的分析、整理和确认

目标：要知道每个需求的“为什么”；从“如何实现”

“实现什么”；分析隐含需求。ID需求描述理由所有者优先级状态需求跟踪矩阵2024/7/129需求获取注意问题1、识别真正的客户2、正确理解客户的需求3、具备较强的忍耐力和清晰的思维4、使用符合客户语言习惯的表达5、提供需求开发评估报告6、尊重开发人员和客户的意见，妥善解决矛盾7、划分需求的优先级8、说服和教育客户2024/7/130需求分析需求阶段设计阶段编码阶段开发测试验收阶段运行阶段1x3x-6x10x15x-40x30x-70x1000x2024/7/131需求分析模型当前系统逻辑模型物理模型目标系统模型化物理模型怎么做具体化抽象化实例化逻辑模型做什么导出理解需求表达需求2024/7/132需求分析活动1、以图形表示的方式描述系统的整体结构，包括系统的边界与接口。2、向用户提供可视化的界面，用户可以对需求做出自己的评价。3、以模型描述系统的功能项、数据实体、外部实体、实体间的关系、实体之间的状态转换。2024/7/133处理需求不明确问题的方法1、让用户参与开发。2、开发用户原型界面。3、需求讨论会议。4、强化需求分析与评审。2024/7/134需求规格需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。2024/7/135软件需求规格说明的原则从现实中分离功能，即描述要“做什么”而不是“怎样实现”。采用一定的规格说明语言。如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。规格说明应该包括系统运行环境。规格说明应该是一个认识模型。规格说明应该容许不完备性并允许扩充。SRS实例2024/7/136需求验证内容1、需求的正确性2、需求的一致性3、需求的完整性4、需求的可行性5、需求的必要性6、需求的可检验性7、需求的可跟踪性8、最后签字与其他软件需求或高层需求不相矛盾验证是否所有可能的状态、状态变化、转入、产品和约束都在需求中描述验证每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施。验证需求是否是用户需要的验证是否能写出测试案例来满足需求，如用演示、检测等来确定产品是否确实按需求实现了每项需求以一种结构化的，粒度化的方式编写并单独标明。避免大段大段的叙述2024/7/137需求变更管理1、确定变更控制过程2、建立软件变更委员会3、进行变更影响分析4、跟踪变更影响的产品5、建立基准和控制版本6、维护变更的历史记录7、跟踪每项需求的状态8、衡量需求稳定性选择、分析、决策项目进度、资源、工作量、项目范围、对其他需求的影响确定、已实现、暂缓、新增、变更记录需求基线的数量和每周或每月的变更2024/7/138变更申请需求方开发方忽略选择变更方式SCCB评估项目经理自行决定根据评估结果拒绝接受本次修改下个版本再修改修改合同相关信息修改相关需求修改相应的项目计划需求变更管理过程2024/7/139本章要点一、关于软件需求二、需求管理过程三、编写需求规格的方法四、任务分解定义五、任务分解方法六、任务分解结果的检验七、案例分析2024/7/140编写需求规格的方法原型方法结构化分析法面向对象的用例分析法功能列表法关联模型行为模型数据模型结构化模型面向对象模型其他方法2024/7/141编写需求规格实例——关联模型ATM系统分支账目系统分支柜台系统维护系统安全系统数据应用总帐目系统2024/7/142编写需求规格实例——行为模型预订机票准备机票记帐行班目录记帐文件旅行社订票单航班费用旅客机票2024/7/143编写需求规格实例——状态机模型微波炉2024/7/144编写需求规格的思维方法：六顶思考帽2024/7/145本章要点一、关于软件需求二、需求管理过程三、编写需求规格的方法四、任务分解定义五、任务分解方法六、任务分解结果的检验七、案例分析2024/7/146WBS(WorkBreakdownStructure)任务分解的过程将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。任务分解的结果WBS（任务分解结构）。WBS面向可交付成果的。Workpackages（工作包）WBS的最低层次的可交付成果代表项目经理监督和控制项目进度的最低层工作。工作包也可以指代说明和报告、一件特殊的硬件设备（如：特定的服务器）。2024/7/147WBS(WorkBreakdownStructure)WBS第1层WBS第2层工作包2024/7/148WBS的清单类型

1.

变化计数器1.1

比较两个版本的程序1.1.1

预处理1.1.2

文件比较1.1.3

结果处理1.2

找出修改后的程序中增加和删除的代码行1.2.1

找出增加的代码行1.2.2

找出删除的代码行1.3

统计修改后的程序中增加和删除的代码行数1.3.1

统计增加代码行数1.3.2

统计删除代码行数1.4

统计总的代码行数1.5

设定标记以指示修改的次数1.6

在程序的头部增加修改纪录2024/7/149WBS的图表类型飞行系统飞行器支持设备设施测试与评价项目管理培训数据系统工程管理支持性项目管理活动设备培训设施培训服务培训技术命令工程数据管理数据实物模型运作测试开发测试基地大楼维护设施组织层次的中间层次的补给站层次机身引擎通信系统导航系统消防系统2024/7/150WBS的图表类型家庭装修设施结构墙体地板门窗厨房厕所洗浴空调照明通讯洁具燃具风机垃圾橱柜水池上水管下水道龙头阀门过滤网2024/7/151WBS的图表类型软件产品发行版本5.0项目管理项目需求详细设计构建整合测试管理会议规划培训资料用户文档软件培训资料用户文件软件培训资料用户文件软件培训资料用户文件软件2024/7/152WBS的图表类型文艺演出节目剧务后勤经营策划编导排练表演化妆道具灯光音响交通就餐住宿安全广告销售票务财务2024/7/153任务分解步骤确认并分解项目的组成要素确定分解标准确定分解是否详细确定项目交付成果验证分解的正确性(建立编号)2024/7/154分解标准生存期功能组成项目的组织单位。。。。2024/7/155分解标准应统一学生管理按照生命期分解规划需求设计编码测试提交按照产品组成分解1.1

招生管理1.2

分班管理1.3

学生档案管理1.4

学生成绩管理2024/7/156分解标准应统一不能同时使用两种标准进行分解招生管理分班管理学生档案管理学生成绩管理规划需求设计编码测试提交2024/7/157WBS字典WBS编码缩写描述标准历时费用负责人备注描述和定义WBS中的元素，以及其他的计划信息，如预算、工期、责任人等。2024/7/158WBS字典WBSDICTIONARYControlAccountIDNo.WorkPackageNo.DateofUpdateResponsibleOrganization/IndividualWorkPackageDescriptionAcceptanceCriteriaDeliverablesAssumptionResourcesAssignedDurationScheduleMilestonesCostDueDateInter-dependenciesBeforeAfterthisworkthisworkPackage________________Package________________Approvedby:PM:

_________Date:________2024/7/159本章要点一、关于软件需求二、需求管理过程三、编写需求规格的方法四、任务分解定义五、任务分解方法六、任务分解结果的检验七、案例分析2024/7/160任务分解方法使用指南类比法自上而下自下而上心智图法2024/7/161使用指南一些组织通常都会为特定项目制订WBS的格式和内容。例如：美国国防部（DOD）要求项目承包方基于DOD提供的WBS建议准备WBS，并据此审查承包方的成本建议和基于WBS的自身内部成本估算。很多组织提供开发WBS的准则和模板，以及过去项目的WBS样例。

PMI开发了一个WBS实践标准为制作和应用WBS提供准则和指南，其中还包含了WBS样例库，涵盖了很多行业领域各种类型的项目,如：网页设计、电信、、服务业外包、软件开发等。PMI会员免费下载(WWW.PMI.ORG)，非会员需购买。WBS模板2024/7/162自上而下与自下而上自上而下法是创建WBS的传统方法，即：从项目最大项开始，将它们分解成下一级的项。这个过程实际上就是对工作的进一步细分。该方法适用于对整个项目有宏观技术把握的项目经理使用。自下而上法项目组成员首先识别出尽可能多的与项目有关的具体任务；随后，将这些具体的任务集中分类并组织成概要任务或WBS中的较高层次。该方法通常比较耗时。项目经理通常运用该方法处理全新的系统。2024/7/163心智图法（MindMapping)

心智图法，又称思维导图，是一种从核心思想向外辐射出分支的方法，用以组织思路和想法。该方法可以让人们以非线性方式构想，用形象的无结构化的方法定义WBS的项，随后可以直接将信息转化成图表格式。2024/7/164心智图法（MindMapping)1、首先在纸的中心画一个彩图，既明确主题，且刺激创意性思维。2、多用图画，醒目，利于记忆。3、以粗体字书写，这样更清晰，便于阅读，便于反馈。4、字词以线相连，这样形成一个基本框架结构。5、多用单个的词语，这样每个词语间连接起来更自如，联想空间更大，更自由，更多变。6、多用各种颜色，同样是为了醒目，强化记忆。7、大脑应尽可能地保持“自由”，这样可以充分利用其创造性。任何关于事物应朝何处发展及是否应包括在思维导图中等方面的“思维”，都会直接使大脑创造性思维减速。2024/7/165心智图法（MindMapping)2024/7/166心智图法（MindMapping)2024