精华内容
下载资源
问答
  • 软件项目管理案例教程韩万江课后习题答案第四版
    万次阅读 多人点赞
    2021-01-01 07:29:35

    第一章 软件项目管理概述

    填空

    1.敏捷模型包括4个核心价值,对应12个敏捷原则。
    2.项目管理包括启动过程组计划过程组执行过程组控制过程组收尾过程组 5个过程组。

    判断

    1.搬家属于项目。
    2.项目是为了创造一个唯一的产品或者提供一个唯一的服务而进行的永久性的努力。×
    3.项目管理目的是要让过程能够被共享、复用,并得到持续的改进。
    4.项目具有临时性的特征。
    5.日常运作存在大量的变更管理,而项目基本保持连贯性的。×
    6.项目开发过程中可以无限制地使用资源。×
    7.相比较传统开发的过程,敏捷开发属于自适应过程。

    选择

    1.下列选项中不是项目与日常运作区别的是(C
    A.项目是以目标为导向的,日常运作是通过效率和有效性来体现的
    B.项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理
    C.项目需要有专业知识的人来完成,而日常运作的完成无需特定的专业知识
    D.项目都是一次性的,日常运作是重复进行的
    2.以下都是日常运作和项目的共同之处,除了(D
    A.由人来做
    B.受制于有限的资源
    C.需要规划、执行和控制
    D.都是重复性工作
    3.下面选项中不属于PMBOK的知识域的是(A
    A.招聘管理
    B.质量管理
    C.范围管理
    D.风险管理
    4.下列选项中属于项目的是(C
    A.上课
    B.社区保安
    C.野餐活动
    D.每天的卫生保洁
    5.下列选项中正确的是(C
    A.一个项目具有明确的目标而且周期不限
    B.一个项目一旦确定就不会发生变更
    C.每个项目都具有自己的独特性
    D.项目都是一次性地由项目经理独自完成
    6.(B)是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力
    A.过程
    B.项目
    C.项目群
    D.组合
    7.下面选项不是《敏捷宣言》中的内容的是(C
    A.个体和交互胜过过程和工具
    B.可以工作的软件胜过面面俱到的文档
    C.敏捷开发过程是自适应的过程
    D.响应变化胜过遵循计划
    8.下列活动不是项目的是(C
    A.野餐活动
    B.集体婚礼
    C.上课
    D.开发操作系统
    9.下列选项不是项目特征的是(C
    A.项目具有明确的目标
    B.项目具有限定的周期
    C.项目可以重复进行
    D.项目对资源成本具有约束性

    问答

    1.项目管理知识体系(PMBOK)包括哪10个知识域?
    项目集成管理项目范围管理项目时间管理项目成本管理项目质量管理项目人力资源管理项目沟通管理项目风险管理项目采购管理项目干系人管理
    2.请简述项目管理的5个过程组及其关系。
    启动过程组计划过程组执行过程组控制过程组收尾过程组
    关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。其中,计划过程组、执行过程组、控制过程组是核心管理过程组。
    3.项目的特征是什么?
    目标性相关性临时性独特性资源约束性不确定性

    第二章 项目确立

    填空

    1.项目确立之后,项目负责人会进行自造-购买决策,确定待开发产品的哪些部分应该采购、外包开发、自主研发等。
    2.PMI人才三角重点关注技术项目管理领导力战略和商务管理3个关键技能。
    3.在立项阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。

    判断

    1.项目立项可以确立项目目标、时间和资源成本,同时得到项目发起人的认可。(
    2.项目招标对于一个项目的开发是必需的,即便项目是内部项目。(×
    3.自主研发相当于make or buy中的make。(
    4.项目建议书是项目计划阶段开发的文档。(×
    5.项目立项需要获得项目经理的认可,但不需要项目发起人的认可。(×
    6.项目章程是项目执行组织高层批准的确认项目存在的文件,其中不包括对项目经理的授权。(×
    7.乙方即提供方(有时也成为卖方),是为顾客提供产品或服务的一方。(
    8.在软件项目合同中,甲方是需求方,乙方是供方。(
    9.敏捷项目采取的是仆人式管理方式。(

    选择

    1.下列不是项目立项过程内容的是(B
    A.项目的目标
    B.项目的风险
    C.项目的时间表
    D.项目使用的资源和经费
    2.以下哪项不包括在项目章程中(C
    A.对项目的确认
    B.对项目经理的授权
    C.对项目风险的分析
    D.项目目标的概述
    3.项目建议书是(C)阶段开发的文档
    A.项目执行
    B.项目结尾
    C.项目初始
    D.项目计划
    4.下列不属于甲方招投标阶段任务的是(A
    A.编写建议书
    B.招标书定义
    C.供方选择
    D.合同签署
    5.下列不属于乙方招投标阶段任务的是(D
    A.项目分析
    B.竞标
    C.合同签署
    D.招标书定义
    6.PMI人才三角不包括(B
    A.技术项目管理
    B.测试能力
    C.领导力
    D.战略和商务管理

    问答

    1、某公司希望开发一套软件产品,如果选择自己开发软件的策略,公司需要花费30000元,根据历史信息,维护这个软件每个月需要3500元。如果选择购买软件公司产品的策略,需要18000元,同时软件公司为每个安装的软件进行维护的费用是4200元/月。该公司该如何决策?
    自制方案:
    制造费 30000元维护费 3500元/月
    购买方案:
    购买费 18000元维护费 4200元/月
    制造差额:30000-18000=12000元
    服务差额:4200-3500=700元
    自制方案承受月份:12000/700=17.14
    如果产品在17个月以内可以选择购买方案,如果超过17个月选择自造方案。

    2、什么是项目章程?
    项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件,包括对项目的确认、对项目经理的授权和对项目目标的概述。

    第三章 生存期模型

    填空

    1.瀑布模型生存期模型要求项目所有的活动都严格按照顺序执行,一个阶段的输出是下一个阶段的输入。
    2.总体上,项目生存期模型可以是预测型或适应型
    3,DevOps是Development和Operation的组合。

    判断

    1.瀑布模型不适合短期项目。(×
    2.增量型生存模型可以避免一次投资带来太大的风险。(
    3.V模型适合的项目类型是需求很明确,解决方案很明确。而且对系统的性能要求比较严格。(
    4.瀑布模型和V模型都属于预测型生存期模型。(
    5.瀑布模型要求项目所有的活动都严格按照顺序执行,一个阶段的输出是下个阶段的输入。(
    6.极限编程(XP)从3个层面提供了13个敏捷实战。(
    7.敏捷包括《敏捷宣言》的价值观、12个原则,以及一些通用实践。(×

    选择

    1.对于某项目,甲方提供了详细、准确的需求文档,我们的解决方案也很明确,且安全性要求非常严格,此项目采用(C)比较合适。
    A.瀑布模型
    B.增量型生存期模型
    C.V模型
    D.XP模型
    2.下面属于预测型生存期模型的是(A
    A.瀑布模型
    B.增量型生存期模型
    C.Scrum模型
    D.原型模型
    3.下面关于敏捷模型描述不正确的是(D
    A.与传统模型相比,敏捷模型属于自适应过程。
    B.可以应对需求的不断变化
    C.Scrum模型、XP模型、DevOps模型等都属于敏捷模型
    D.敏捷模型是预测型和迭代型的混合模型
    4.XP模型的实践原则不包括一下哪一点(D
    A.快速反馈
    B.假设简单
    C.包容变化
    D.详细设计
    5.在项目初期,一个项目需求不明确的情况下,应避免采用以下哪种生存期模型(C
    A.快速原型模型
    B.增量式模型
    C.V模型
    D.Scrum模型
    6.关于迭代模型,下列说法不正确的是(D
    A.不断反馈原型
    B.可以加快开发速度
    C.项目需求变化大
    D.不多次提交

    问答

    1.写出3中你比较熟悉的生存期模型,并说明这些模型适用于什么情况下的项目。
    (1)瀑布模型
    适用于软件需求很明确的软件项目,即一般适用于功能明确、完成、无重大变化的软件系统的开发。
    即:
    1)在项目开始前,项目的需求过程已经被很好地理解、也很明确,而且项目经理很熟悉为实现这一模型所需的过程。
    2)解决方案在项目开始前也很明确
    3)短期项目可以采用瀑布模型
    (2)V模型
    适用于项目需求在项目开始前很明确,解决方案在项目开始前也很明确,项目对系统的安全很严格。如航天飞机控制系统,公司的财务系统等
    (3)快速原型模型
    适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候

    2.混合模型是一种什么样的模型?
    对于整个项目,没有必要使用单一的方法。为了达到特定的目标,项目经常要结合不同的生命周期元素。预测、迭代、增量和敏捷方法的组合就是一种混合方法

    第四章 软件项目范围计划

    填空

    1.需求管理包括需求获取需求分析需求规格编写需求验证需求变更5个过程。
    2.敏捷项目主要采用用户故事来描述需求。

    判断

    1.需求规格说明可以包括系统的运行环境。(
    2.数据流分析法是一种自下而上逐步求精的分析方法(×
    3.需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。(
    4.需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。(
    5.用户故事常常写在卡片上,然后将其部署到墙上。(
    6.软件项目系统的响应时间属于功能性需求。(×
    7.数据字典是由数据项、数据流及操作指令组成的。(×

    选择

    1.下列不属于软件项目管理需求过程的是(D
    A.需求获取
    B.需求分析
    C.需求规格编写
    D.需求更新
    2.下列不属于数据字典的组成部分的是(D
    A.数据项
    B.数据流
    C.数据文件
    D.数据库
    3.下列不属于UML需求视图的是(A
    A.甘特图
    B.用例图
    C.状态图
    D.顺序图
    4.下列关于用户故事的描述不正确的是(D
    A.英文名称:user story
    B.不使用技术语言来描述
    C.可以描述敏捷需求
    D.一种数据结构
    5.(A)是软件项目的一个突出特点,可以导致软件项目的蔓延。
    A.需求变更
    B.暂时性
    C.阶段性
    D.约束性
    6.下列不属于结构化方法分析的是(D
    A.数据流图
    B.数据字典
    C.系统流程图
    D.用例图
    7.下列不属于软件需求范畴的是(A
    A.软件项目采用什么样的实现技术
    B.用户希望软件能做到什么样的事情
    C.用户需要软件实现什么样的功能
    D.用户需要软件达到什么样的性能
    8.敏捷项目一般采用下面(C
    A.用户用例
    B.DFD
    C.用户故事
    D.数据字典

    问答

    1.下图是SPM项目需求规格文档中的一个用例图,请根据图中信息判断参与者是什么角色?并写出至少3个用例,如登录,注册等。
    1)参与者是课务管理系统中的学生用户。
    2)登录、注册、查看成绩

    2.采用典型的用户故事模板描述上题中的注册功能。
    As a user, I want to register so that I can have my own count.

    第五章 软件项目范围计划——任务分解

    填空

    1.任务分解是将一个项目分解为更多的工作细目或者子项目,是项目变得更小、更易管理、更易操作。
    2.WBS的全称是任务分解结构(Work Breakdown Structure)
    3.WBS最底层次可交付成果是工作包

    判断

    1.WBS提供了项目范围基线。(
    2.一个工作包可以分配给另一个项目经理去完成。(
    3.如果开发人员对项目比较熟悉或者对项目大局有把握,开发WBS时最好采用自底向上方法。(×
    4.对于一个没有做过的项目,开发WBS可以采用自底向上方法()
    5.在任务分解结果中,最底层的要素必须是实现项目目标的充分必要条件。(
    6.一个工作包应当由唯一主体负责。(
    7.WBS的最高层次的可交付成果是工作包。(×
    8.对任务的分解只能是自上而下的。(×
    9.WBS的最底层任务是能分配到一个人完成的任务。(
    10.敏捷项目的一个Epic还可以继续分解为一些用户故事。(

    选择

    1.WBS非常重要,因为下列原因,除了(D
    A.确定项目范围基准
    B.防止一楼工作
    C.为项目估算提供依据
    D.确定项目经理
    2.WBS中的每一个具体细目通常指定唯一的(A
    A.编码
    B.地点
    C.功能模块
    D.提交截止期限
    3.下列不是创建WBS的方法的是(C
    A.自顶向下
    B.自底向上
    C.控制方法
    D.模板参照
    4.任务分解是,(D)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组合起来,形成更高级别的WBS层。
    A.模板参照
    B.自顶向下
    C.类比
    D.自顶向上
    5.下列关于WBS的说法,不正确的是(D
    A.WBS是任务分解的结果
    B.不包括在WBS中的工作就不是该项目的工作
    C.可以采用提纲式或者组织结构图形式表示WBS的结果
    D.如果项目是一个崭新的项目,则最好采用自顶向下方法开发WBS
    6.检验WBS分解结果的标准不包括(B
    A.最底层的要素是否是实现目标的充分必要条件
    B.分解的层次不少于3层
    C.最底层元素是否重复
    D.最底层圆度是否有完整清晰的定义
    7.WBS是对项目由粗到细的分解过程,它的结构是(B
    A.分层的集合结构
    B.分级的树形结构
    C.分层的线性结构
    D.分级的图状结构
    8.任务分解是,(B)方法按从一般到特殊的方向进行,从项目的大局着手,然后主板分解子细目,将项目变为更细,更完善的部分。
    A.模板参照
    B.自顶向下
    C.类比
    D.自底向上

    问答

    1.试写出任务分解的方法和步骤
    任务分解的基本步骤
    1)确认并分解项目的组成要素(WBS编号)
    2)确定分解标准,按照项目实施管理的方法分解,而且分解的标准要统一
    3)确认分解是否详细,是否可以作为费用和时间估计的标准,明确责任。
    4)确定项目交付成果(可以编制WBS字典)
    5)验证分解正确性。验证分解正确后,建立一套编号系统
    任务分解方法:模板参照法、自顶向下、自底向上、类比法

    2.当项目过于复杂时,可以对项目进行任务分解,这样做的好处是什么?
    将一个项目分解为更多的工作细目或者子项目,使项目变得更小,更易管理,更易操作,这样可以提高估算成本、时间和资源的准确性,使工作变得更易操作,责任分工更加明确

    第六章 软件成本计划

    填空

    1.软件项目成本包括直接成本和间接成本,一般而言,项目人力成本属于直接成本。
    2.再在项目初期,一般采用的成本估算方法是类比估算法
    3.功能点方法中5类功能组件的计数项是外部输入外部输出外部查询内部逻辑文件外部接口文件
    4.敏捷项目一般采用故事点估算方法。
    5.用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算。

    判断

    1.故事点估算是一个相对的估算过程。(
    2.在软件项目估算中,估算结果是没有误差的。(×
    3.人的劳动消耗所付出的代价是软件产品的主要成本。(
    4.功能带你估算与项目所使用的语言和技术有关。(×
    5.COCOMO81有3个等级的模型是有机型、嵌入型、半嵌入型。(×
    6.经验对于估算来说不重要(×
    7.估算时既要考虑直接成本又要考虑间接成本。(
    8.在进行软件估算的时候,可以直接考虑参照其他企业的模型进行项目估算。(×
    9.间接成本是与一个具体项目相关的成本。(×

    选择

    1.三点估算法选择的3钟估算值不包括(D
    A.最可能成本
    B.最乐观成本
    C.最悲观成本
    D.项目经理估算
    2.下面关于估算的说法,错误的是(C
    A.估算是有误差的
    B.估算时不要太迷信数学模型
    C.经验对于估算来说不重要
    D.历史数据对估算来说非常重要
    3.假设某项目的注册功能为3个功能点,而其中成绩录入工作量比注册功能工作量略多,如果采用Fibonacci等级标准估算,则成绩录入功能的估算值是(A
    A.5个故事点
    B.4个故事点
    C.6个故事点
    D.7个故事点
    4.(B)是成本的主要因素,是成本估算的基础。
    A.计划
    B.规模
    C.风险
    D.利润
    5.成本估算方法不包括(D
    A.代码行
    B.功能点
    C.类比法
    D.关键路径法
    6.下列不是UFC的功能计数项的是(C
    A.外部输出
    B.外部文件
    C.内部输出
    D.内部文件
    7.成本预算的目的是(A
    A.生产成本基线
    B.编写报告书
    C.指导设计过程
    D.方便进度管理
    8.下列不是软件项目规模单位的是(D
    A.代码长度LOC
    B.功能点FP
    C.人天、人月、人年
    D.小时
    9.在成本管理过程中,每个时间段中各个工作单元的成本是(B
    A.估算
    B.预算
    C.直接成本
    D.间接成本

    问答

    1.项目经理正在进行一个图书馆信息查询系统的项目估算,他采用Delphi的专家估算方法,邀请了3位专家进行估算,第一位专家给出了2万元、7万元、12万元的估算值,第二位专家给出了4万元、6万元、8万元的估算值,第三位专家给出了2万元、6万元、10万元的估算值,试计算这个项目的成本估算值。
    答:专家一:Ei=(ai+4mi+bi)/6=(2+47+12)/6=7
    专家二:Ei=(ai+4mi+bi)/6=(4+4
    6+8)/6=6
    专家三:Ei=(ai+4mi+bi)/6=(2+4*6+10)/6=6
    Ei=(7+6+6)/3=6.33(万元)

    2.如果某软件公司正在进行一个项目,预计有50KLOC的代码量,项目是中等规模的半嵌入型的项目,采用中等COCOMO模型,项目属性中只有可靠性为很高级别(即取值为1.3),其他属性为正常(书上说,正常就是1),计算项目是多少人月的规模,如果是2万元/人月,则项目的费用是多少?
    答:Effort=a*(KLOC)bF
    查表a=3,b=1.12,F=1
    Effort=3.0
    501.121.31=311.82(人月)
    所以项目的费用为2* Effort=623.64万元

    3.已知某项目使用C语言完成,该项目共有85个功能点,请用IBM模型估算源代码行数、工作量、项目持续时间、人员需要量以及文档数量。
    答:C语言代码行与功能点的关系近似为150LOC/FP,所以,85个功能点代码行数为L85150=12750行=1.75KLOC,则:工作量估算E=5.2L0.91=5.212.750.91≈52.725(人月)
    项目时间 D=4.1
    L0.36=4.112.750.36≈10.25(月)
    人员需求量S=0.54
    E0.6=0.5452.7250.6≈5.829(人)
    文档数量 DOC=49
    L1.01=49*12.751.01≈640.857(页)

    第七章 软件项目进度计划

    填空

    1.关键路径决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间。
    2.时间是一种特殊的资源,以其单向性、不可重复性、不可替代性而有别于其他资源。
    3.在ADM网络图中,箭线表示活动(任务)
    4.应急法平行作业法都是时间压缩法。
    5.工程评估评审技术采用的加权平均的公式是PERT历时=(O+P+4M)/6,其中O是乐观值,P是悲观值,M是最可能值。

    判断

    1.一个工作包也可以通过多个活动完成(
    2.在项目进行过程中,关键路径是不变的(×
    3.在PDM网络图中,箭线表示的是任务之间的逻辑关系,节点表示的是活动(
    4.项目各项活动之间不存在相互联系与相互依赖关系。(×
    5.在资源冲突问题中,过度分配也属于资源冲突。(
    6.浮动是在不增加项目成本的条件下,一个活动可以延迟的量。(×
    7.在使用应急法压缩时间的过程中,不一定要在关键路径下选择活动来进行压缩。(×
    8.时间是项目中灵活性最小的因素(
    9.外部依赖关系又称强制性依赖关系,指的是项目活动与非项目活动之间的依赖关系(×
    10.当估算某活动时间,存在很大不确定时应采用CMP估计(×
    11.敏捷项目一般采取远粗近细的计划模式,敏捷发布的计划相当于远期计划,迭代计划相当于近期计划。(

    选择

    1.下面说法中不正确的是(D
    A.EF=ES+duration
    B. LS=LF-duration
    C.TF=LS-ES=LF-EF
    D.EF=ES+lag
    2. “软件编码完成之后,我才可以对它进行软件测试”,这句话说明了哪种依赖关系?(A
    A.强制性依赖关系
    B.软逻辑关系
    C.外部依赖关系
    D.里程碑
    3. (A)可以显示任务的基本信息,使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。
    A.甘特图
    B.网络图
    C.里程碑图
    D. 资源图
    4. (C)是项目冲突的主要原因,尤其在项目后期。
    A.优先级问题
    B.人力问题
    C.进度问题
    D.费用问题
    5. 以下哪一项是项目计划中灵活性最小的因素?(A
    A.时间
    B.人工成本
    C.管理
    D.开发
    6. 以下哪一项不是任务之间的关系?(D
    A.结束-开始
    B.开始-开始
    C.结束-结束
    D.结束-开始-结束
    7. 快速跟进是指(A
    A.采用并行执行任务,加速项目进展
    B. 用一个任务取代另外的任务
    C.如有可能,减少任务数量
    D.减轻项目风险
    8. 下面哪一项将延长项目的进度?(A
    A.lag
    B.lead
    C.赶工
    D.快速跟进
    9. 下面哪一项可以决定进度的灵活性?(B
    A.PERT
    B.总浮动
    C.ADM
    D.赶工
    10.(B)可以表示敏捷项目的进度,并且可以表示出剩余的任务
    A.燃起图
    B.燃尽图
    C.里程碑图
    D.网络图

    问答

    1.对一个任务进行进度估算时,A是乐观者,估计用6天完成,B是悲观者,估计用24天完成,C是有经验者,认为最有可能用12天完成,那么这个任务的历时估算介于10天到16天的概率是多少?
    解:E=(6+24+4*12)/6=13, δ=(24-6)/6=3
    E-δ=10
    E+δ=16

    所以任务历时估算介于10——16天的概率为:68.3%
    2.请将下图所示的PDM(优先图法)网络图改画为ADM(箭线法)网络图。
    略略略
    3.根据下面任务流程图和下表给出的项目历时估算值,采用PERT方法估算,求出项目在14.57天内完成的概率的近似值。
    解:E1=(2+6+43)/6=20/6,E2=(4+8+46)/6=6,E3=(3+6+4*4)/6=25/6
    任务方差、标准差分别为:
    所以,E= E1+ E2+ E3=13.5天,δ=1.07
    E-δ=12.43,E+δ=14.57 [12.43,14.57]的概率为:68.3%
    E-2δ=11.36,E+2δ=15.64 [11.36,15.64]的概率为:95.5%
    E-3δ=10.29,E+3δ=16.71 [10.29,16.71]的概率为:99.7%
    所以,项目在14.57天内完成的概率为:50%+68.3%/2=84.15%

    第八章 软件项目质量

    填空

    1.(审计)是对过程或产品的一次独立质量评估。
    2.质量成本包括预防成本和(缺陷成本)。
    3.软件质量是软件满足明确说明或者隐含的需求的程度。
    4、McCall质量模型关注的3个方面是产品运行产品转移产品修改
    5、质量管理总是围绕着质量保证和质量控制过程两个方面进行。
    6、质量保证的主要活动是项目执行过程审计项目产品审计

    判断

    1、质量是满足要求的程度,包括符合规定的要求和客户隐含的需求。(
    2、软件质量是软件满足明确说明或者隐含的需求的程度。(
    3、软件质量可以通过后期测试得以提高。(×
    4、质量计划可以确定质量保证人员的特殊汇报渠道。(
    5、软件质量是代码正确的程度。(×
    6、敏捷项目要求全程的质量审查(×

    选择

    1.下列不属于质量管理过程的是(D
    A.质量计划
    B.质量保证
    C.质量控制
    D.质量优化
    2.项目质量管理的目标是满足(C)的需要
    A.老板
    B.项目经理
    C.项目
    D.组织
    3、下列属于质量成本的是(A
    A.预防成本
    B.缺陷数量
    C.预测成本
    D.缺失成本
    4、下列不是质量计划方法的是(C
    A.质量成本分析
    B.因果分析图
    C.抽样分析
    D.基准对照
    5.下列不是软件质量模型的是(D
    A.Boehm质量模型
    B.McCall质量模型
    C.ISO/IEC 9216质量模型
    D.Mark质量模型
    6.质量控制非常重要,但是进行质量控制也需要一定的成本,(B)可以降低质量控制的成本。
    A.进行过程分析
    B.使用抽样统计
    C.对全程进行监督
    D.进行质量审计
    7、McCall 质量模型不包含(C
    A.产品修改
    B.产品转移
    C.产品特点
    D.产品运行
    8、下面(D)不是敏捷项目的质量实践
    A.结对编程
    B.TDD
    C.迭代评审
    D.需求规格编写过程审计

    简答

    1、简述质量保证的主要活动,以及质量保证的要点。
    质量保证的主要活动是项目执行过程审计和项目产品审计。
    质量保证的要点是:对项目进行评价、推测能否达到质量指标、建立对项目的信心

    2、简述质量保证与质量控制的关系。
    质量保证(QA)是通过评价项目整体绩效,建立对质量要求的信任,提供项目和产品可视化的管理报告。这个任务本身并不能提高产品的质量,但是通过质量保证的一系列工作可以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。
    质量控制(QC)是确定项目结果与质量标准是否相符,同时,确定消除不符的原因和方法,它控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。
    质量保证是后期质量活动,质量控制是前期质量活动。它们是有区别的:质质量保证是针对项目实施过程的管理手段,质量控制是针对项目产品的技术手段;实施质量保证是针对过程改进和审计的,强调的是过程改进和信心保证。实施质量控制是按照质量要求,检查具体可交付成果的质量,强调的是具体的可交付成果。

    第九章 软件配置管理计划

    填空

    1.完整性和可跟踪性是软件配置管理的核心功能。
    2.基线标志开发过程中一个阶段的结束和里程碑。
    3.基线变更控制包括变更请求变更控制变更批准/拒绝变更实现等步骤。
    4.版本管理变更管理是配置管理的主要功能。
    5.基线变更时,需要经过SCCB授权。
    6.SCCB的全称是软件配置控制委员会

    问答

    1.一个软件配置项可能有多个标识。(×
    2.基线提供了软件开发阶段的一个特定点。(×
    3.有效的项目管理能够控制变化,以最有效的手段应对变化,不断命中移动的目标。(
    4.一个(些)配置项形成并通过审核,即形成基线。(
    5.软件配置项是项目需定义其受控于软件配置管理的款项,每个项目的配置项是相同的。(×
    6.基线的修改不需要每次都按照正式的程序执行。(×
    7.基线产品是不能修改的。(×
    8.基线修改应受到控制,但不一定要经SCCB授权。(×
    9.变更控制系统包括从项目变更申请、变更评估、变更审批到变更实施的文档化流程。(
    10.持续支付领域强调对项目所有的相关产物及其之间的关系都要进行有效配置管理(
    11.持续支付更倾向于使用基于分支的开发模式(×

    选择

    1.下列不属于SCCB的职责的是(D
    A.评估变更
    B.与项目管理层沟通
    C.对变更进行反馈
    D.提出变更申请
    2.为了更好地管理变更,需要定义项目基线,关于基线的描述,下列描述正确的是(B
    A.不可变化
    B.可以变化,但是必须通过基线变更控制流程处理
    C.所以的项目必须定义基线
    D.基线发生变更时,必须修改需求
    3.软件配置管理无法确保以下哪种软件产品属性(A
    A.正确性
    B.完整性
    C.一致性
    D.可控性
    4.变更控制需要关注的是(B
    A.阻止变更
    B.标识变更,提出变更,管理变更
    C.管理SCCB
    D.客户的想法
    5.以下哪项不是项目配置管理中可能遇到的问题?(B
    A.找不到某个文件的历史版本
    B.甲方与乙方在资金调配上存在意见差异
    C.开发人员未经授权修改代码或文档
    D.因协同开发中,或者异地开发,版本变更混乱导致整个项目失败

    问答

    1.写出配置管理的基本过程。
    (1)配置项标识、跟踪;(2)配置管理环境建立;(3)基线变更管理;(4)配置管理审计;(5)配置状态统计;(6)配置管理计划。
    2.说明软件配置控制委员会(SCCB)的基本职责。
    评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项目管理层沟通。
    3.写出几个常见的软件配置项。
    软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清单、测试规格说明书、测试计划、测试用例与实验结果、可执行程序、用户手册、维护文档。

    第十章 软件项目团队计划

    填空

    1.可以充分发挥部门资源优势集中的组织结构为(职能型组织结构
    2.组织结构的主要类型(职能型)、(项目型)、(矩阵型
    3.(会议形式)沟通最有可能协助解决复杂的问题。
    4.当项目中有20个人时,沟通渠道最多有(190)。

    判断

    1.项目干系人是项目计划的一部分。(
    2.项目型的优点是可以资源共享。(×
    3.应尽量多建立一些沟通渠道。(×)
    4.项目沟通的基本原则是及时性、准确性、完整性和可理解性()
    5.在IT项目中,成功的最大威胁是沟通的失败()
    6.责任分配矩阵是明确项目团队成员的角色与职责的有效工具()
    7.口头沟通不是项目沟通的方式(×)
    8.对于紧急的信息,应该通过口头的方式沟通;对于重要的信息,应采用书面的方式沟通()
    9.沟通计划包括确定谁需要信息,需要什么信息,何时需要信息,以及如何接收信息等()
    10.敏捷团队的人员一般在3~9人,而且一般集中地在一个场地开发,可以围坐一个桌子开会(

    选择

    1.(A)以图形方式展示项目团队成员及其报告关系这样可以减少沟通渠道,减少成本
    A.项目组织图
    B.甘特图
    C.网络图
    D.RAM图
    2.下面不是敏捷角色的是(D
    A.产品负责人
    B.团队促进者
    C.跨职能团队成员
    D.合同管理者
    3、在项目管理的3种组织结构中,适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构是( C)
    A.矩阵型组织结构
    B.项目型组织结构
    C.职能型组织结构
    D.都一样
    4、项目经理花在沟通上的时间是(B)
    A.20%-40%
    B.75%-90%
    C.60%
    D.30%-60%
    5.在(C)组织结构中,项目成员没有安全感
    A.职能型
    B.矩阵型
    C.项目型
    D.弱矩阵型
    6、下列关于干系人的描述中,不正确的是(D
    A影响项目决策的个人、群体或者组织
    B影响项目活动的个人、群体或者组织
    C影响项目结果的个人、群体或者组织
    D所有项目人员
    7.编制沟通计划的基础是(== A==)
    A.沟通需求分析
    B.项目范围说明书
    C.项目管理计划
    D.历史资料
    8.项目团队原来有5个成员,现在人员扩充,又增加了3个成员这样沟通渠道增加了(A
    A.2.8倍
    B.两倍
    C.4倍
    D.1.6倍
    9.对于项目中比较重要的通知,最好采用(B)沟通方式
    A.口头
    B.书面
    C.网络方式
    D.电话
    10.在一个高科技公司,项目经理正在为一个新的项目选择合适的组织结构,这个项目涉及多的领域和特性,他应该选择(A)组织结构
    A.矩阵型
    B.项目型
    C.职能型
    D.组织型

    简答

    1.写出5种以上项目沟通方式
    沟通方式主要有书面沟通和口头沟通、语言沟通和非语言沟通、正式沟通和非正式沟通、单向沟通和双向沟通、网络沟通等
    2.对于特别重要的内容,你认为一般采用哪些方式才能确保有效沟通
    对于特别重要的内容,要采用多种方式进行有效沟通确保传达到位,除发送邮件外还要电话提醒、回执等,重要的内容还要通过举行各种会议进行传达

    第十一章 软件项目风险计划

    填空

    1.风险评估的方法包括定性和定量风险分析。
    2.决策树分析是一种形象化的图表分析方法。
    3.项目风险的三要素是风险事件风险事件发生的概率风险造成的影响
    4.回避风险是指尽可能地规避可能发生的风险,采取主动放弃或者拒绝使用导致风险的方案。
    5.定量风险评估主要包括访谈盈亏平衡分析决策树分析模拟法敏感性分析等方法。

    判断

    1.任何项目都是有风险的。(
    2.风险是损失发生的不确定性,是对潜在的、未来可能发生损害的一种度量。(
    3.风险识别、风险评估、风险规划、风险控制是风险管理的4个过程。(
    4.应对风险的常见策略是回避风险、转移风险、损失控制和自留风险。(
    5.项目的风险几乎一样。(×
    6.购买保险是一种回避风险的应对策略(×
    7.敏捷项目没有长期计划,这本身也是一个风险,因为存在一些无法识别的风险。(

    选择

    1.下列不属于项目风险的三要素的是(B)。
    A.一个事件
    B.事件的产生原因
    C.事件发生的概率
    D.事件的影响
    2.下列属于可预测风险的是(C)。
    A.不现实的交付时间
    B.没有需求或软件范围的文档
    C.人员调整
    D.恶略的开发环境
    3.下列不是风险管理过程的是(D
    A.风险评估
    B.风险识别
    C.风险规划
    D.风险收集
    4.下列说法错误的是(D)。
    A.项目风险的3个要素是一个事件、事件发生的概率、事件的影响
    B.风险规划的4个过程是风险识别、风险评估、风险规划、风险控制
    C.风险规划的主要策略是回避风险、转移风险、损失控制、自留风险
    D.项目风险是由风险发生的可能性决定的
    5.在一个项目的开发过程中采用了新的技术,为此,项目经理找来专家对项目组人员进行技术培训,这是什么风险应对策略?(B)。
    A.回避风险
    B.损失控制
    C.转移风险
    D.自留风险
    6.下列不属于风险评估方法的是(D)。
    A.盈亏平衡分析
    B.模拟法
    C.决策树分析
    D.二叉树分析

    更多相关内容
  • 软件项目报价表

    2018-09-26 17:51:37
    软件项目报价表模板。分为软件开发的人员费用、维护费用、服务器费用等
  • 软件项目投标书

    热门讨论 2018-03-17 10:56:47
    软件项目投标书 范文,目录结构可以借鉴,大家放心下载
  • 软件项目需求明细以及报价单

    热门讨论 2018-09-25 16:05:03
    简单且实用的一个软件项目需求分析明细和报价,以及模块负责人和开发周期安排的excel模板。
  • 软件项目投标书-技术部分

    热门讨论 2016-11-30 09:45:53
    包括4份文档,基本涵盖软件项目技术应答部分,可以用于技术标书制作时参考。
  • 软件项目管理案例教程,完整扫描版,非课件

    千次下载 热门讨论 2013-12-09 12:27:02
    本书是国家示范性软件学院系列教材之一 是一部关于软件项目管理的实用教材 全书以案例的形式 讲述了软件项目管理的全过程 并辅以一个贯穿始终的案例 本书向软件项目管理人员传授项目管理的理论 方法以及技巧 通过...
  • 软件项目验收报告-模板(全)

    热门讨论 2016-06-15 13:51:42
    软件项目验收报告-模板(全)
  • 软件项目管理知识点总结

    千次阅读 多人点赞 2020-12-27 18:18:16
    软件项目管理第1章 软件项目管理概述1、项目的基本概念(注意与日常运作的区分)和特征;2、软件项目及特征;3、项目管理的基本概念;4、项目管理知识体系(以2017年发布的PMBOK6的十个知识领域为准);5、适用于...

    软件项目管理

    第1章 软件项目管理概述

    1、项目的基本概念(注意与日常运作的区分)和特征;

    项目的定义和特征:
    (1)美国项目管理权威机构--项目管理协会(Project Management Institute,PMI)认为,项目是为完成某一独特的产品或服务所做的一次性努力.
    (2)德国DIN(德国工业标准)69901认为,项目是指在总体上符合下列条件的唯一性任务:
    ①具有预定的目标;
    ②具有时间、财务、人力和其他限制条件;
    ③具有专门的组织.
    (3)《项目管理质量指南(ISO10006)》定义项目为:“具有独特的过程,有开始和结束日期,由一系列相互协调和受控的活动组成.过程的实施是为了达到规定的目标,包括满足时间、费用和资源等约束条件”.
    (4)中国项目管理知识体系纲要(2002版)中对项目的定义为:项目是创造独特产品、服务或其他成果的一次性工作任务.
    (5)联合国工业发展组织《工业项目评估手册》对项目的定义是:“一个项目是对一项投资的一个提案,用来创建、扩建或发展某些工厂企业,以便在一定周期内增加货物的生产或社会的服务.”
    (6)世界银行认为:“所谓项目,一般系指同一性质的投资,或同一部门内一系列有关或相同的投资,或不同部门内的一系列投资”.
    (7)一般地说,所谓项目就是指在一定约束条件下(主要是限定资源、限定时间、限定质量),具有特定目标的一次性任务.
    共同特征:
    (1)一次性
    (2)独特性
    (3)目标的明确性
    (4)活动的整体性
    (5)组织的临时性和开放性
    (6)开发与实施的渐进性
    常见的习题都是选出符合项目定义的事物,如:创建一个具有特定功能的软件是项目,但是日常打扫卫生就不属于项目
    项目的特征:
    1.有明确的目标
    2.项目之间的活动具有相关性
    3.限定的周期
    4.有独特性
    5.资源成本的约束性
    6.项目的不确定性
    项目与日常运作有什么不同:
    1.项目是一次性的,日常运作是重复进行的
    2.项目是以目标为导向的,日常运作是通过效率和有效性体现的
    3.项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理
    4.项目存在大量的变更管理,而日常运作则基本保持连贯性

    2、软件项目及特征;

    软件产品与其他任何产业的产品不同,它是无形的,完全没有物理属性。对于这样看不见,摸不着的产品,难以理解,难于架驭。但它确实是把思想、概念、算法、流程、组织、效率、优化等融合在一起了。因此,要开发这样的产品,在许多情况下,用户一开始给不出明确的想法,提不出确切的要求。他说不清究竟他需要的是什么。在开发的过程中,程序与其相关的文档常常需要修改。在修改的过程中又可能产生新的问题,并且这些问题很可能在过了相当长的时间以后才会发现。文档编制的工作量在整个项目研制过程中占有很大的比重。但从实践中看出,人们对它不感兴趣、认为是不得不做的苦差事,不愿认真地去做。因而直接影响了软件的质量。软件开发工作技术性很强,要求参加工作的人员具有一定的技术水平和实际工作的经验。但事实上,人员的流动对工作的影响很大。离去的人员不但带走了重要的信息,还带走了工作经验。
    软件项目的特殊性:
    1.为逻辑实体而非物理实体,具有抽象性
    2.没有明显的制造过程,也不存在重复生产
    3.软件项目的开发受到计算机硬件的制约
    4.不可能完全摆脱手工开发模式
    5.软件本身是相当复杂的,涉及因素众多,需求多变
    6.软件项目投入大、成本高

    3、项目管理的基本概念;

    项目管理是管理学的一个分支学科 ,对项目管理的定义是:指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程。项目管理是对一些成功地达成一系列目标相关的活动(譬如任务)的整体监测和管控。这包括策划、进度计划和维护组成项目的活动的进展。

    4、项目管理知识体系(以2017年发布的PMBOK6的十个知识领域为准);

    1.项目整合管理(以前版本称为项目综合管理,或项目集成管理),包括6个子过程:制订项目章程;制定项目管理计划;指导与管理项目执行;监控项目工作;实施整体变更控制;结束项目或阶段。
    2.项目范围管理,包括6个子过程:规划范围管理;收集需求;定义范围;创建WBS;确认范围;控制范围。
    3.项目进度管理,包括7个子过程:规划进度管理;定义活动;排列活动顺序;估算活动资源;估算活动持续时间;制定进度计划;控制进度。
    4.项目成本管理,包括4个子过程:规划成本管理;估算成本;制定预算;控制成本。
    5.项目质量管理,包括3个子过程:规划质量管理;实施质量保证;控制质量。
    6.项目人力资源管理,包括4个子过程:规划人力资源管理;组建项目团队;建设项目团队;管理项目团队。
    7.项目沟通管理,包括3个子过程:规划沟通管理;管理沟通;控制沟通。
    8.项目风险管理,包括6个子过程:规划风险管理;识别风险;实施定性风险分析;实施定量风险分析;规划风险应对;控制风险。
    9.项目采购管理,包括4个子过程:规划采购管理;实施采购;控制采购;结束采购。
    10.干系人管理,包括4个过程:识别干系人;规划干系人管理;管理关系人参与;控制干系人参与。

    5、适用于软件项目管理的知识体系。

    软件项目管理特征:
    1.软件是纯知识产品,其开发进度和质量很难估计和度量,生产率也难以预测和保证。
    2.项目周期长,复杂度高,变数多
    3.软件项目提供的是一种服务,需要满足一群人的期待,即需要满足一群想法和利益各不相同的人的需求

    ​第2章 项目确立 &第3章 生存期模型【项目初始】

    1、理解项目启动的基本过程(项目评估、项目立项、招投标、发布项目章程);

    1.项目评估:就是在直接投资活动中,在对投资项目进行可行性研究的基础上,从企业整体的角度对拟投资建设项目的计划、设计、实施方案进行全面的技术经济论证和评价,从而确定投资项目未来发展的前景。
    2.项目立项:指成立项目,执行实施。特别是大中型创业项目或行政收费项目,要列入政府、社会、经济发展计划中。
    3.招投标:招投标一般指招标投标。招标投标是基本建设领域促进竞争的全面经济责任制形式。一般由若干施工单位参与工程投标,招标单位 (建设单位) 择优入选,谁的工期短、造价低、质量高、信誉好,就把工程任务包给谁,由承建单位与发包单位签订合同。
    4.发布项目章程:项目章程是证明项目存在的正式书面说明和证明文件。

    2、项目章程的主要内容和作用;

    项目章程:项目章程是指项目执行组织最高层批准的一份以书面签署的确认项目存在的文件,包括对项目的确认、对项目经理的授权和项目目标的概述。严格的说,项目章程包括开始一个项目或项目阶段的正式授权。
    项目章程是一个正式的文档,它正式的认可一个项目的有效性,并指出项目的目标和管理方向。它授权项目经理来完成项目,从而保证项目经理可以组织资源用于项目活动。项目章程由项目发起人、出资人或者高层管理人员签字。

    3、理解各生存期模型的优缺点及适用场景。

    1.瀑布模型:分析、设计、编码、测试和维护严格按照步骤进行,适合于项目开始前有明确需求和明确解决方案的项目,如公司的财务系统、库存管理系统、短期项目等。
    2.V模型:是瀑布模型的变种,强调测试的重要性,将开发活动与测试活动紧密的联系在一起。适合于对系统的性能、安全有严格要求的项目。
    3.增量模型:由瀑布模型演变而来,假设需求可分阶段,分成一系列增量产品分别开发。适合于项目开始明确了需求的大部分,但对市场和用户把握不是很准,对于有庞大和复杂功能的系统也可考虑增量开发。
    4.螺旋式模型:该模型在四个象限上分别表达了计划制定、风险分析、项目实施、客户评估四个方面的活动,通过一系列瀑布模型的不断循环来逐步规避风险,适合于不确定因素较多,风险较大的项目。
    5.渐进式阶段模型:综合了增量模型和螺旋式模型的一个实用模型,渐进式前进,阶段式提交。适合各种规模的项目,尤其是大中型项目,以及希望随时可查看的未来项目

    第4章 软件项目需求管理

    1、软件需求的概念及层次;

    软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。
    业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
    用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。
    功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。

    2、需求工程的组成。

    1.需求获取阶段
    需求获取首先需要的是技术的支持,其次,在需求获取工作中主要涉及了 3 个至关重要的因素:应搜集什么信息;从什么来源中搜集信息;用什么机制或技术搜集信息。再次,需求获取的开始,代表着软件项目正式开始实施,正所谓万事开头难。综合上述 3 个点使得需求获取成为软件开发中最困难、最关键、最易出错也是最需要交流的方面。在工作开展中,主要是就业务流程、组织架构、软硬件环境和现有系统等相关内容进行沟通,挖掘系统最终用户的真正需求,把握需求的方向。在需求获取调研会中首先对需求获取方法作了验证。现行的需求获取方法一般有基于调查的需求获取方法、基于用例的需求获取方法、原型法等几种方法。各种需求获取方法各有利弊。
    2.需求分析阶段
    需求分析与需求获取是密切相关的,需求获取是需求分析的基础,需求分析是需求获取的直接表现,两者相互促进,相互制约。需求分析与需求获取的不同主要在于需求分析是在已经了解承建方的实际的客观的较全面的业务及相关信息基础上,结合软、硬件实现方案,并做出初步的系统原型给承建方做演示。承建方则通过原型演示来体验业务流程的合理化、准确性、易用性。同时,用户还要通过原型演示及时地发现并提出其中存在的问题和改进意见和方法。
    3.文档编写阶段
    需求开发的最终成果是,在对所要开发的产品达成共识后,所编写的具体的文档。需求文档是在需求获取和需求分析两个阶段任务结束时生成的,所以文档要包含所有需求。在此阶段先要从软件工程和文档管理的角度出发依据相关的标准审核需求文档内容,确定需求文档内容是否完整。对需求文档中存留问题进行修改的工作。
    4.需求确认阶段
    需求确认主要是针对《需求规格说明书》的评审,保证需求符合优秀需求成熟的特征,并且符合好的需求规格说明的特征。在需求确认阶段需要保证以下几点:
      (1)软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征。
      (2)从系统需求、业务规则或其他来源中正确的推导出软件需求。
      (3)需求是完整的、高质量的。
      (4)需求的表示在所有地方都是一致的。
      (5)需求为继续进行产品设计和构造提供充分的基础。
    5.需求跟踪阶段
    需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系,确保产品依据需求文档进行开发,建立与维护“需求——设计——编程——测试”之间的一致性,确保所有工作成果符合用户需求。需求跟踪是一项需要进行大量手工劳动的任务,在系统开发和维护的过程中一定要随时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直接影响产品质量,降低维护成本,容易实现复用,同时,需求跟踪还需要建设方的大力支持。
    6.需求复用阶段
    在软件项目实施过程中,许多不同项目间存在着许多相似的需求,尤其是类型相同的项目在不同的用户群众的实施中,需求的相似性就更加明显、更加普遍了。有了需求复用,建设方就能快速的形成一个需求的原型,这样,后期的需求工作只需要在此原型的基础上进行修改、扩充和完善即可,大大提高了需求分析的工作进度。所以,对于需求的复用就需要加以重视。对于需求复用,首要责任就是要提取可复用的需求,对需求复用的理解和扩充。其次就是要保证需求复用不存在冲突。
    7.变更控制阶段
    需求变更在软件项目开发中是不可避免的。无休止的需求变更只会造成各种资源无休止的浪费,但是其中也不乏有许多是必要的、合理的需求变更。对于需求变更,首先是要尽量及早的发现,以避免更大的损失。其次,是要采取相应的、合理的变更管理制度和流程,这样同样可以降低需求变更带来的风险。
    8.版本控制阶段
    版本控制是管理需求规格说明和其他项目文档必不可少的一个方面,也是需求变更文档化管理的最有效办法。可以详细记录发生需求变更的需求文档版本的版本,发生变更的原因,变更发生的控制记录,并对变更后的需求文档进行唯一版本号的标识。使得每个成员都能及时访问最新版本的需求文档。
    实施版本控制的基础是需求基线,所谓需求基线就是项目组成员一经承诺将在某一特定产品版本中实现的功能性和非功能性需求的集合。需求基线的确定可以保证项目的涉众各方可以对发布的产品中希望具有的功能和属性有一个一致的理解。

    需求获取和包含的主要活动。

    1.需求获取指通过与用户交流、对现有系统的观察及对任务进行分析,从而开发、捕获和修订用户的需求
    2.需求获取的主要活动:1.了解客户方的所有用户类型及潜在的类型。2.对用户进行访谈和调研,包括会议讨论邮件提问、自行搜索等各种形式。3.对收集到的用户需求作进一步分析整理4.将调研得到的用户需求以适当形式呈交给用户和开发方相关人员。

    需求分析的主要内容和处理不明确需求

    需求分析的主要内容有:1.以图形表示的方法描述系统的整体结构,包括边界和接口等。2.通过原型、页面流或其他方式向用户提供可视化界面,以便用户对需求做出自己的评价。3.以模型描述系统的功能项、数据实体、外部实体以及是实体间的关系、状态转换等
    处理不明确需求:1.让用户参与开发,以便及时对不明确需求做出修正。2.开发用户界面原型,以便用户更好的确认需求。3.召开需求讨论会议,汇总和确认需求。4.强化需求分析和评审,让用户参与需求评审并签字认可。

    如何做好需求变更管理

    1.建立需求基线
    2.确定需求变更控制过程
    3.成立变更控制委员会SCCB
    4.进行需求变更影响分析
    5.跟踪所有受需求变更影响的工作产品
    6.建立需求基准版本和需求控制版本文档
    7.维护需求变更的历史记录
    8.跟踪每项需求的状态
    9.衡量需求的稳定性

    第6章 软件项目成本计划(含第5章 任务分解)

    1、软件项目成本管理的总体过程;

    1 资源计划过程–决定完成项目各项活动需要哪些资源(人、设备、材料)以及每种资源的需要量。
    2 成本估计过程–估计完成项目各活动所需每种资源成本的近似值。
    3 成本预算过程–把估计总成本分配到各具体工作。
    4 成本控制过程–控制项目预算的改变。

    2、软件项目成本的组成;

    软件成本度量需要先估算软件的规模,即所需工作量的估算,然后根据工作量,通过一定的公式估算出成本。首先我们理解软件生命周期包括策划阶段、需求阶段、设计阶段、构建阶段、测试阶段、部署阶段。软件规模估算所估算的正是后四个阶段的工作量。

    软件成本的构成可分为直接成本和间接成本,具体可分为直接人力成本,间接人力成本,间接非人力成本,直接非人力成本。

    1.直接人力成本,包括开发方项目组成员的工资、奖金、福利等人力资源费用

    2.直接非人力成本,包括办公费、差旅费、培训费、业务费、采购费及其他费用

    3.间接人力成本,指开发方服务于研发管理整理需求的非项目组人员的人力资源费用分摊

    4.间接非人力成本,指开发方不为研发某个特定项目而产生,但服务于真题研发活动的非人力成本分摊

    3、WBS的作用、特点及分解方法;

    即利用WBS方法,先把项目任务进行合理的细分,分到可以确认的程度,如某种材料,某种设备,某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是:
    ①对项目需求作出一个完整的限定。
    ②制定完成任务所必需的逻辑步骤。
    ③编制WBS表。
    项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明,它应确认必须达到的目标。如果有资金等限制,该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点,其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能,用来指导成本估算的总进度表应含有项目开始和结束的日历时间。
    一旦项目需求被勾划出来,就应制定完成任务所必需的逻辑步骤。在现代大型复杂项目中,通常是用箭头图来表明项目任务的逻辑程序,并以此作为下一步绘制CPM或PERT图以及WBS表的根据。
    编制WBS表的最简单方法是依据箭头图。把箭头图上的每一项活动当作一项工作任务,在此基础上再描绘分工作任务。
    进度表和WBS表完成之后,就可以进行成本估算了。在大型项目中,成本估算的结果最后应以下述的报告形式表述出来:
    ①对每个WBS要素的详细费用估算。还应有一个各项分工作、分任务的费用汇总表,以及项目和整个计划的累积报表。
    ②每个部门的计划工时曲线。如果部门工时曲线含有“峰”和“谷”,应考虑对进度表作若干改变,以得到工时的均衡性。
    ③逐月的工时费用总结。以便项目费用必须削减时,项目负责人能够利用此表和工时曲线作权衡性研究。
    ④逐年费用分配表。此表以WBS要素来划分,表明每年(或每季度)所需费用。此表实质上是每项活动的项目现金流量的总结。
    ⑤原料及支出预测,它表明供货商的供货时间、支付方式、承担义务以及支付原料的现金流量等。
    采用这种方法估算成本需要进行大量的计算,工作量较大,所以只计算本身也需要花费一定的时间和费用。但这种方法的准确度较高,用这种方法作出的这些报表不仅仅是成本估算的表述,还可以用来作为项目控制的依据。最高管理层则可以用这些报表来选择和批准项目,评定项目的优先性。 以上介绍了三种成本估算的方法。除此之外,在实践中还可将几种方法结合起来使用。例如,对项目的主要部分进行详细估算,其他部分则按过去的经验或用因素估算法进行估算。

    4、软件项目规模估算的基本方法(LoC、FP、UCP);

    1.LoC:面向规模的软件度量通过规范化质量和生产率测量的方法得到,这种测量是基于所生产软件的规模(Size)确定的。为了与其他项目中的同类度量相比较,选择代码行作为规范化,这样,就可以为每个项目产生一组简单的、面向规模的度量标准:
    ●每千行代码(KLOC)的错误数。
    ●每千行代码行(KLOC)的缺陷数。
    ●每千行代码行(KLOC)的成本。
    ●每千行代码行(KLOC)的文档页数。
    ●每人月错误数。
    ●每页文档的成本。
    面向规模的软件度量,通常并不被认为是软件开发过程中最优的方法,因为有很多因素直接影响代码的行数。
    减小估算误差的方法(PERT估计):请多位专家分别估计程序的最小规模a,最可能规模m,最大规模b,然后计算出这三种规模的平均值 ,最后计算出程序规模的平均值:
    在这里插入图片描述

    2.FP:采用功能点估算法可得出最终的功能点数(FP),然后将FP转换为Loc(Java语言采用平均值70,即一个功能点对应代码行数量为70),一代码行的研发成本为15元。据此估算出软件研发成本。
    项目管理成本=研发成本12%,
    质量保证成本=研发成本
    8%,
    配置管理成本=研发成本6%,
    项目直接成本=研发成本+项目管理成本+质量保证成本+配置管理成本;
    项目间接成本(包含办公场所租赁费用、水电、保安、福利、培训、软硬件设备等分摊到该项目的费用)=项目直接成本
    20%;
    项目总成本=项目直接成本+项目间接成本=项目直接成本*(1+20%)。
    3.UCP:如果采用用例点估算法可得出最终的用例点数(UCP)。软件生产率PE采用20人时/用例点,研发人员的平均成本为400元/天,据此估算出软件研发成本。
    项目管理成本=研发成本12%,
    质量保证成本=研发成本
    8%,
    配置管理成本=研发成本6%,
    项目直接成本=研发成本+项目管理成本+质量保证成本+配置管理成本;
    项目间接成本(包含办公场所租赁费用、水电、保安、福利、培训、软硬件设备等分摊到该项目的费用)=项目直接成本
    20%;
    项目总成本=项目直接成本+项目间接成本=项目直接成本*(1+20%);

    5、软件项目成本估算的各基本方法(专家判定、类比、自顶向下、自底向上、算法模型)及特点;

    1.专家判定:基于历史信息,专家判断可以对项目环境及以往类似项目的信息提供有价值的见解。专家判断还可以对是否需要联合使用多种方法,以及如何协调方法之间的差异提出建议。(出题基本就是,A专家B专家C专家各自报价多少,求一个平均数)也称为Delphi法,聘请一个或多个领域专家和软件开发技术人员,由他们分别对项目成本进行估计,并最后达成一致而获得最终的成本。
    2.类比:成本类比估算,指利用过去类似项目的实际成本作为当前项目成本估算的基础。当对项目的详细情况了解甚少时(如在项目的初期阶段),往往采用这种方法估算项目的成本。类比估算是一种专家判断。类比估算的成本通常低于其他方法,而且萁精确度通常也较差。此种方法在以下情况中最为可靠:与以往项目的实质相似,而不只是在表面上相似,并且进行估算的个人或集体具有所需的专业知识。
    常考:已知一个功能点,还有1200个功能点,则是类比估算法
    3.自顶向下与自底向上:1.自顶向下估算法是从项目的整体出发,进行类推,即估算人员根据以往完成类似项目所消耗的总成本或工作量,来推算将要开发的信息系统的总成本或工作量。然后,按比例将它分配到各个开发任务单元中,是一种自上而下的估算形式,通常在项目的初期或信息不足时进行。例如,在合同期和市场招标时等。不是非常精确的时候或在高层对任务的总的评估的时候采用这种方法。该方法的特点是简单易行和花费少,但具有一定的局限性,准确性差,可能导致项目出现困难。2.自底向上估算法也叫工料清单法,这种成本估算方法是利用项目工作分解结构图,先由基层管理人员计算出每个工作单元的生存成本,再将各个工作单元的生产成本自下而上逐级累加,汇报给项目的高层管理者,最后由高层管理者汇总得出项目的总成本。采用这种方法进行成本估算,基层管理者是项目资源的直接使用者,因此由他们进行项目成本估算,得到的结果应该十分详细,而且比其它方式也更为准确。但是这种方法实际操作起来非常耗时,成本估算工作本事也要大量的经费支持。
    4.模型算法:。根据项目特征,用数学模型来预测项目的成本。一般采用历史成本信息(这些信息与项目成本的一些软件度量标准相关)来建立估算模型,并通过这个模型预测工作量和成本。

    6、理解软件项目成本预算;

    项目成本估算,是对完成项目工作所需要的费用进行估计和计划,是项目计划中的一个重要组成部分。要实行成本控制,必须先估算费用。费用估算过程实际上是确定完成项目全部工作活动所需要的资源的一个费用估计值,这是一个近似值,既可以用货币单位表示,也可用工时、人月、人天等其他单位表示。在进行费用估算时,也包括各种备选方案的费用估算。
    项目成本估算方法就是运用一系列科学的手段去对项目有关工程技术、经济、社会等方面的条件和情况进行调查、研究、分析,从而推算出项目所需成本的手段。

    7、软件项目成本控制(监控),掌握赢得值分析法各种量的计算。

    成本管理是软件项目管理的主要内容之一,分析了目前软件开发成本管理过程中存在的问题,提出了将进度和成本联系起来考虑,使工作量和实际成本匹配的方法。结合现有的估算方法,设计成本管理系统并将其应用于软件项目管理平台中,旨在改善软件开发中成本超支的现象,为企业提高效益。

    赢得值法用三个基本值来表示项目的实施状态,并以此预测项目可能的完工时间和完工时的可能费用,三个基本值是:累计计划成本额:某一时点应当完成的工作所需投入资金或花费成本的累计值。它等于计划工程量与预算单价的乘积之和。该值是衡量工程进度和工程费用的一个标尺或基准。
    赢得值:某一时点已经完成的工作所需投入资金的累计值。它等于已完工程量与预算单价的乘积之和。它反映了满足质量标准的工程实际进度和工作绩效,体现了投资额到工程成果的转化。
    实际成本额:某一时点已完成的实际工作所花费的成本总金额。它等于已完工程量与实际支付单价的乘积之和。
    通过三个基本值的对比,可以对工程的实际进展情况作出明确的测定和衡量,有利于对工程进行监控,也可以清楚地反映出工程管理和工程技术水平的高低。使用赢得值法进行成本、进度综合控制,必须定期监控以上三个参数。具体步骤如下:
    (1)项目预算和计划首先要制订详细的项目预算,把预算分解到每个分项工程,尽量分解到详细的实物工作量层次,为每个分项工程建立总预算成本TBC(Totalbud-getedcost)。项目预算的的第二步是将每一TBC分配到各分项工程的整个工期中去。每期的成本计划依据各分项工程的各分项工作量进度计划来确定。当每一分项工程所需完成的工程量分配到工期的每个时段,就能确定何时需用多少预算。这一数字通过截止到某期的过去每期预算成本累加得出,即累计计划预算成本CBC(cumulativebudgetedcost)或BCWS.其中,Rb代表预算单价;Qs代表计划工程量;i代表某一预算项;n代表预算项数;t代表时段;j代表当前时段。CBC反映了到某期为止按计划进度完成的工程预算值。它将作为项目成本、进度绩效的基准。
    (2)收集实际成本项目执行过程中,会通过合同委托每一工作包的工作给相关承包商。合同工程量及价格清单形成承付款项。承包商在完成相应工作包的实物工程量以后,会按合同进行进度支付。在项目每期对已发生成本进行汇总,即累计已完工程量与实际单价之积,就形成了累计实际成本CAC(cumulativeactualcost)或ACWP.
    (3)计算赢得值(earned value)
    如前所述,仅监控以上两个参数并不能准确地估计项目的状况,有时甚至会导致错误的结论和决策。赢得值是整个项目期间必须确定的重要参数。对项目每期已完工程量与预算单价之积进行累计,即可确定累计赢得值CEV(cumulative earned value,)或BCWP.
    (4)成本/进度绩效利用以上几个指标即可以比较分析项目的成本/进度绩效和状况,CEV与CAC实际是在同样进度(相同工作量)下的价值比较,它反映了项目成本控制的状况和效率,因此,衡量成本绩效的指标或称成本绩效指数CPI(costperformanceindex,)可由如下公式确定;
    CPI=CEV/CAC另一衡量成本绩效的指标是成本差异CV(costvariance),它是累计赢得值与累计实际成本,即CV=CEV-CAC与CPI一样,这一指标表明赢得值与实际成本的差异,CV是以货币来表示的。
    同样,CBC与CEV是在同样价格体系(预算价)下的工程量的比较,它用货币量综合反映了项目进度的总体状况,因此,可按上述方法同样去衡量进度绩效。
    以上分析可对整个项目进行,也可针对某一独立的工作包进行。
    (5)成本/进度控制有效成本/进度控制的关键是经常地、及时地分析成本/进度绩效,及早地发觉成本/进度差异,以便在情况变坏之前能够采取纠偏措施。
    成本、进度综合控制包括如下内容,分析成本、进度绩效以确定需要采取纠正措施的工作包,决定采取何种纠偏措施。
    修订项目计划,包括工期和成本估计,综合筹划控制措施。
    要做好成本、进度综合控制,应十分关注CPI或CV的走势,当CPI小于1或逐渐变小、CV为负且绝对值越大时,就应该及时制定纠偏措施并加以实施。应集中注意力在那些有负成本差异的工作包或分项工程上,根据CPI或CV值确定采取纠正措施的优先权,也就是说,CPI最小或CV负值最大的工作包或分项工程应该给予最高优先权。总体进度控制可使用相同原理和方法。
    (此题考的还挺多)

    任务分解及作用

    任务分解就是将一个项目分解为更多的工作细目或者子项目,使项目变的更小、更易管理、更易操作。他是一个化繁为简,分而治之的过程
    作用:
    1.提供了项目范围基线,是范围变更的重要输入
    2.为评估和分配任务提供具体的工作包
    3.进行估算和编制项目进度的基础
    4.对整个项目成功的集成和控制起到非常重要的作用

    项目管理度量指标

    BCWS:计划完成工作的预算成本 BCWS=计划工作量*预算单价

    BCWP(挣得值):已完成工作量的预算成本 BCWP=已完成工作量*预算单价

    ACWP:已完成工作量的实际费用 ACWP=实际完成工作量*实际单价

    CV:费用偏差。表示完成相同任务的任务实际费用和预算费用的差额。CV=BCWP-ACWP

    SV:进度偏差,BCWP与BCWS之间的差异SV=BCWP-BCWS

    CPI:是指挣得值与实际费用之比。CPI=BCWP/ACWP

    SPI:进度执行标准:是指项目挣得值与计划值之比,SPI=BCWP/BCWS

    第7章 软件项目进度计划(重点!!)

    1、软件项目进度管理的总体过程;

    项目进度管理是指在项目实施过程中,对各阶段的进展程度和项目最终完成的期限所进行的管理,是在规定的时间内,拟定出合理且经济的进度计划(包括多级管理的子计划)。
    在执行该计划的过程中,经常要检查实际进度是否按计划要求进行,若出现偏差,便要及时找出原因,采取必要的补救措施或调整、修改原计划,直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。
    项目进度管理一般包含项目进度计划的制定和项目进度计划的控制两部分。
    主要任务
    1.活动定义
    2.活动排序
    3.活动历时估计
    4.人物资源估计
    5.制定进度计划
    6.进度控制项目跟踪

    2、活动之间的逻辑关系(FS、SS、FF、SF)及依赖关系(强制、选择、内部、外部);

    FS关系:完成—开始关系,即:前一工作完成后,后续工作才能开始。
    SS关系:开始—开始关系,即:前一工作开始后,后续工作才能开始。
    FF关系:完成—完成关系,即:前一工作完成后,后续工作才能完成。
    SF关系:开始—完成关系,即:前一工作开始后,后续工作才能完成。
    依赖关系亦称“逻辑关系”。在项目管理中,指表示两个活动(前导活动和后续活动)中一个活动的变更将会影响到另一个活动的关系。通常活动之间的依赖关系包括强制依赖关系(所做工作中固有的依赖关系)、可自由处理的依赖关系(由项目队伍确定的依赖关系)和外部依赖关系(项目活动与非项目活动之间的依赖关系)三种形式

    3、活动排序的网络图(ADM和PDM的区分、特点);

    首先是网络图:
    用图形直观地显示项目各项活动之间的逻辑关系和排序。
    网络图是活动排序的结果,它可以展示各项目活动之间的关系。
    通过网络图可识别关键活动,并确定某一活动进度的变化对后续工程和总工期的影响。
    在网络图中一个活动用一个方框、节点或者其他方式表示
    每一个活动被各种关系线相连接着
    网络图开始于一个任务、工作、活动、里程碑
    网络图结束于一个任务、工作、活动、里程碑
    有些活动具有前置任务或者后置任务
    1.ADM箭线图法
    在ADM网络图中,箭线表示活动(任务)
    代号表示前一任务的结束,同时也表示后一任务的开始.
    两个代号唯一确定一个任务,因此称为双代号网络图
    双代号网络计划一般仅使用结束到开始的关系表示方法,因此为了表示所有工作之间的逻辑关系往往需要引入虚活动加以表示
    在我国这种方法应用较多,软件较多
    在这里插入图片描述

    2.PDM
    构成PDM网络图的基本特点是节点(Box)
    节点(Box)表示活动(任务)
    用箭线表示各活动(任务)之间的逻辑关系
    可以方便的表示活动之间的各种逻辑关系
    在这里插入图片描述
    在这里插入图片描述

    4、项目历时估计的方法(重点在CPM和PERT);

    1.CPM关键路径法
    确定项目网络图
    每个活动有单一的历时估算
    关键路径是网络图中持续时间最长的路径
    关键路径可以确定项目完成时间
    组成关键路径的任务称为关键任务,任何关键任务的延迟都会导致项目工期的延期,所以关键任务的缓冲期都是0
    在这里插入图片描述

    2.PERT工程评价技术:利用PDM任务网络图和加权历时估算公式计算项目总历时
    3.定额估算法:根据项目规模、投入资源即单位生产率计算项目历时,公式为T=Q/(R*S)
    4.经验导出模型:使用根据大量历史项目统计得出的模型公式计算,如COCOMO模型等
    5.基于承诺的进度估计发:从需求出发,由开发人员承诺项目进度
    6.Jones的一阶估算准则:根据项目功能点数及开发商评级,使用公式粗略估计项目历时
    7.其他:专家估计法、类推估计法、模拟估计法等。

    5、时间压缩法中的赶工(掌握时间压缩与成本增加呈线性的情况)

    赶工:拿资源换时间
    赶工在项目管理中的定义:对成本和进度进行权衡,确定在尽量少增加费用的前提下最大限度地缩短项目所需要的时间。赶工进度并非总能产生可行的方案,反而常常增加成本。
    赶工原则是“采用优先考虑赶工费用率最低的工作”。压缩工期势必要采取相应施工措施和技术措施,则造成施工成本增加;通俗的说就是“用金钱换时间”。

    6、甘特图和里程碑图的基本特点。

    甘特图(Gantt chart)又称为横道图、条状图(Bar chart)。其通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况。
    在这里插入图片描述

    里程碑图是一个目标计划,它表明为了达到特定的里程碑,去完成一系列活动。
    在这里插入图片描述
    菱形小方快

    7.何谓正推法?简述其计算任务历时的基本步骤及计算公式

    1.正推法是按照时间顺序计算任务网络图上各活动的最早开始时间和最早完成时间的有效方法
    2.计算步骤:
    a.首先建立项目的开始时间,项目的开始时间是网络图中第一个活动的最早开始时间
    b.从左到右从上到下进行计算,遍历所有路径
    c.当一个任务有多个前置任务时,其最早开始时间应取前置任务其中最大的最早完成时间
    3.计算公式:
    a.EF=ES+Duration(任务历时)
    b.ES(2)=EF(1)+Lag(1为前置任务2为后置任务,Lag为滞后时间)

    第8章 软件项目质量计划

    1、软件质量的基本概念和内涵;

    概括地说,软件质量就是“软件与明确地和zhi隐含地定义的需求相一致的程度”。具体地说,软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述定义强调了以下三点:
    (1)软件需求是度量软件质量的基础,与需求就一致就是质量不高。
    (2)指定的标准定义了一组指导软件开发的准则,如果没有遵守这些准则,几乎肯定会导致质量不高。
    (3)通常,有一组没有显式描述的隐含需求(如期望软件是容易维护的)。如果软件满足明确描述的需求,但却不满足隐含的需求,那么软件的质量仍然是值得怀疑的。
    影响软件质量的主要因素,这些因素是从管理角度对软件质量的度量。可划分为三组,分别反应用户在使用软件产品时的三种观点。正确性、健壮性、效率、完整性、可用性、风险(产品运行);可理解性、可维修性、灵活性、可测试性(产品修改);可移植性、可再用性、互运行性(产品转移)。

    2、软件质量模型;

    在这里插入图片描述
    软件的 6 个质量特征:
    功能性(Functionality):当软件在指定条件下使用时,软件产品提供满足明确和隐含需要的功能的能力;
    可靠性(Reliability):在指定条件下使用时,软件产品维持规定的性能级别的能力;
    易用性(Usability):在指定条件下使用时,软件产品被理解、学习、使用和吸引用户的能力;
    效率(Efficiency):在规定条件下,相对于所用资源的数量,软件产品可提供适当性能的能力;
    可维护性(Maintainability):软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度;
    可移植性(Portability):软件产品从一种环境迁移到另一种环境的能力。

    3、软件质量保证(QA)常见活动、质量控制(QC)常见活动,两者区别。

    1.软件质量保证(QA)其目的是向管理者提供适当的对软件项目正在进行的过程和正在构造的产品的可视性,
    包括审计软件产品(中间产品和最终产品)和开发过程以验证它们符合通用的过程和标准,
    向管理者、顾客或其他方提供信任,
    确保项目质量与计划保持一致。
    这个任务本身并不能提高产品的质量
    一般由专门的质量保证人员实施
    2.质量控制(Quality Control,QC)是确定项目结果(中间结果和最终结果)与质量标准是否相符,并及时纠正产品缺陷的过程。
    在这里插入图片描述
    比较:
    质量保证重在保证过程被正确执行,属于管理职能,针对项目实施过程的管理手段;
    质量控制重在检验产品的质量,属于检查职能,针对项目产品的技术手段;
    质量控制是针对具体产品的质量管理,在具体环节上提高产品质量,促进具体产品的质量改善;
    质量保证确保项目以一套成熟高效的做事方法开展和实施,在总体上提高信心。依靠在QA制约下的开发过程,能够前瞻性地从制度上保障开发出好产品。因此,具有良好QA管理的企业,容易获得客户更多的信任。企业性能产生突破。

    第9章 软件项目配置计划

    1、理解软件项目配置管理基本活动;

    软件配置管理是识别、定义系统中的配置项,在软件生命周期中控制它们的变更,记录并报告配置项和变更请求的状态,并验证它们的完整性和正确性的一个过程。
    配置管理是否有成效取决于三个要素:人、规范、工具
    主要包括
    1.软件配置管理组织
    2.配置项的标识、跟踪
    3.建立配置管理环境
    4.配置项版本控制
    5. 基线变更管理
    6. 配置审核
    7. 配置状态统计和报告
    8.配置管理计划

    2、配置管理的基本概念(配置、配置项、基线、版本、SCCB)和目的。

    配置的概念最早应用于制造系统,其目的是有效标识复杂系统的各个组成部分。
    如今软件的复杂性日益增大,如仍把软件当作单一的整体,就无法解决所面临的问题,因此,软件产品同样需要类似材料清单的概念,配置的概念由此引入软件领域。
    1.配置:在软件开发过程中生成各种制品的总和叫做这个项目的软件配置(程序、文档、数据)。
    2.配置项:

    项目需定义其受控于软件配置管理的款项。
    为了配置管理的目的而作为一个单位来看待的软件要素的集合。
    具体有:
    a.程序(源代码、可执行程序)
    b.文档
    c.属于软件产品组成部分的工作成果,如需求文档、设计文档、测试用例、测试报告、用户手册、维护文档等;
    d.在管理过程中产生的文档,例如各种项目计划、状态报告,这些文档虽然不是产品的组成部分,但也值得保存。
    e.数据(内部或外部)
    f.有时也会把特定版本开发工具(如编译器、开发工具、CASE工具)等列入配置管理项
    g.每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等

    3.基线:已经通过了正式评审的配置项,它可以作为进一步开发的基础,并且只有通过正式的变更控制过程才能修改。在软件工程环境中,基线通常标志着软件开发过程中的里程碑,这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的软件制品的提交。基线的主要属性有:名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”;为内部开发用的基线则称为一个“Build”。
    4.版本:是一个基线或一个软件配置项的特例。
    5.SCCB:软件配置控制委员会
    6.目的:
    记录软件产品的演化过程
    确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置
    最终保证软件产品的完整性、一致性、追朔性、可控性
    软件配置管理主要功能
    版本控制:采取相应的流程和工具,对软件开发过程中产生的各种文件的版本进行管理。(核心内容)
    变更管理:为防止开发人员对软件的随意变更而进行的管理上的审核过程,包括变更请求、变更评估、批准/拒绝、变更实现。
    其他:配置审计、配置状态统计等。

    第10章 软件项目团队计划

    1、理解项目各类型组织结构(职能型、项目型、矩阵型)的优缺点及适用性;

    职能型:
    优点:1.可以充分发挥职能部门的资源集中优势。2.部门的专家可以同时为部门内的不同项目使用。3.便于相互交流,相互支援。4.可以随时增派人员。5.可以将项目和本部门的职能工作融为一体
    缺点:1.项目和部门利益发生冲突,职能部门更重视本部门的目标,会忽略项目目标2.资源平衡会出现问题。3.权力分割不利于各个职能部门的交流和团结协作4.行政隶属关系使得项目经理没有充分的权力

    项目型:
    优点:1.项目经理对项目可以负全责。2.项目目标单一,以项目为中心,有利于项目顺利进行。3.避免了多重领导.4.组织结构简单,交流简单,效率高
    缺点:1.资源不能共享2.各个独立的项目处于相对封闭的状态,不利于公司政策的贯彻3.对项目组织的成员缺少一种事业上的连续性和安全感4.项目组织间处于分割状态,缺少信息交流。

    矩阵型
    优点:1.专职的项目经理负责整个项目,以项目为中心2.公司的多个项目可以共享各个职能部门的资源3.即利于项目目标的实现,有利于公司目标方针的贯彻4.项目成员的顾虑减少了
    缺点:1.容易引起职能经理和项目经理权利的冲突2.资源共享也能引起项目之间的冲突3.项目成员有多头领导

    2、软件项目团队所需的角色、职责;

    在这里插入图片描述

    3、项目沟通计划的主要内容;

    项目沟通计划是对于项目全过程的沟通工作,沟通方法、沟通渠道等各个方面的计划与安排。就大多数项目而言,沟通计划的内容是作为项目初期阶段工作的一个部分。同时,项目沟通计划还需要根据计划实施的结果进行定期检查,必要时还需要加以修订。所以项目沟通计划管理工作是贯穿于项目全过程的一项工作,项目沟通计划是和项目组织计划紧密联系在一起的,因为项目的沟通直接受项目组织结构的影响。

    4、项目干系人分析的“四步法”。

    干系人(stakeholder)是能影响项目决策、活动或者结果的个人、群体或者组织,以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、群体或者组织。
    项目干系人分析四步法:
    无遗漏地识别项目干系人
    按重要性对干系人进行分析
    按支持度对干系人进行分析
    项目干系人分析坐标格

    第11章 软件项目风险管理

    1、风险的概念;

    风险是项目的一个固有的不确定的事件或者条件,一旦发生,就会对一个或多个项目目标(如范围、进度、成本和质量)造成积极或消极的影响。也就说风险的发生可能给项目带来问题,也可能给项目带来机会。对于这两种性质不同的风险,在传统的风险管理中都属于其研究对象。

    2、软件风险的来源;

    软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。
    分类
    从预测的角度将风险分为3类:
    已知风险(known known):是通过仔细评估项目计划、开发项目的经济和技术环境以及其他可靠的信息来源之后可以发现的那些风险。例如,不现实的交付时间;没有需求或软件范围文档;恶劣的开发环境等。
    可预测的风险(known unknown):是指能够从过去项目的经验中推测出来的风险。例如,人员变动;与客户之间无法沟通等。
    不可预测的风险(unknown unknown):是指可能,但很难事先识别出来的风险

    根据风险内容(范围),风险可分为
    技术风险:是指由于与项目研制相关的技术因素的变化而给项目建设带来的风险,包括潜在的设计、实现、接口、验证和维护、规格说明的二义性、技术的不确定性、“老”技术与“新”技术等方面的问题。
    费用风险:是指由于项目任务要求不明确,或受技术和进度等因素的影响而可能给项目费用带来超支的可能性。
    进度风险:是指由于种种不确定性因素的存在而导致项目完工期拖延的风险。该风险主要取决于技术因素、计划合理性、资源充分性、项目人员经验等几个方面。
    管理风险:是指由于项目建设的管理职能与管理对象(如管理组织、领导素质、管理计划)等因素的状况及其可能的变化,给项目建设带来的风险。
    社会环境风险:是指由于国际、国内的政治、经济技术的波动(如政策变化等),或者由于自然界产生的灾害(如地震、洪水等)而可能给项目带来的风险。
    商业风险:是指开发了一个没有人真正需要的产品或系统(市场风险);或开发的产品不符合公司的整体商业策略(策略风险);或构成了一个销售部不知道如何去出售的产品(销售风险)等。
    其它:人员风险、客户风险、产品风险、过程风险等

    3、软件项目风险管理的总体过程;

    风险管理是指在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程。
    通过风险识别、风险分析和风险评价去认识项目的风险,并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制,妥善处理风险事件造成的不利后果,以最小的成本保证项目总体目标的实现。

    4、风险识别的基本方法;

    在这里插入图片描述

    5、风险评估(分析)的基本方法(定性和定量);

    风险评估又称风险预测,就是对识别出的风险做进一步分析,对风险发生的概率进行估计和评价,对风险后果的严重程度进行估计和评价,对风险影响范围进行估计和评价,以及对于风险发生时间进行估计和评价。
    风险评估可采用定性风险评估和定量风险评估来进行。
    定性风险评估主要是针对风险概率及后果进行定性的评估。
    例如采用历史资料法、概率分布法、风险后果估计法等。历史资料法主要是应用历史数据进行评估的方法,通过同类历史项目的风险发生情况,进行本项目的估算。
    风险评估的方法——定量风险评估
    定量风险评估是一种广泛使用的管理决策支持技术。一般,在定性风险分析之后就可以进行定量风险分析。
    定量风险分析过程的目标是量化分析每一个风险的概率及其对项目目标造成的后果,也分析项目总体风险的程度。定量风险评估可以包括以下方法:
    访谈
    因果关系分析
    决策树分析
    模拟法

    6、风险应对策略。​

    主要应对策略—回避风险
    回避风险是对所有可能发生的风险尽可能的规避,采取主动放弃或者拒绝使用导致风险的方案。例如放弃采用新技术。
    注意事项
    对风险有足够的认识,而且风险发生概率极高,影响极严重
    当其他风险策略不理想的时候,可以考虑
    可能产生另外的风险,如不采用新的开发技术,导致开发的产品技术落后
    不是所有的情况都适用的
    主要应对策略—转移风险
    转移风险是为了避免承担风险损失,有意识将损失或与损失有关的财务后果转嫁出去的方法:例如出售、分包、开脱责任合同(通过免责合同等手段说明不对后果负责)、保险。
    注意事项
    通过分包来转移风险实际上是将一种风险置换成了另一种风险,如分包商交付延误的风险、成本上升的风险
    软件保险(软件如使用过程中出了问题,保险公司来赔偿损失)已经存在
    主要应对策略—损失控制
    损失控制是指在风险事件发生前消除风险可能发生的根源并减少风险事件的概率,在风险事件发生后减少损失的程度。
    损失控制的基点是消除风险因素和减少风险损失。
    损失控制根据目的不同,分为:损失预防和损失抑制
    损失预防是指损失发生前为了消除或减少可能引起风险的各种因素而采取的各种具体措施。制订预防性计划包括针对一个确认的风险事件的预防方法以及风险发生后的应对步骤。
    损失抑制(风险缓解)是指风险发生时或风险发生后为了减少损失幅度所采取的各项措施。
    主要应对策略—自留风险
    自留风险又称承担(接受)风险,由项目组织自己承担风险事件所致损失的措施。类型:
    主动自留风险
    被动自留风险

    关于项目管理考试的大题分析

    赢得值必考

    赢得值(Earned Value)分析法是一种能全面衡量项目成本、进度的整体方法,以资金已经转化为项目成果的量来衡量,是一种完整和有效的项目监控指标和方法。
    赢得值分析法用BCWS、BCWP、ACWP三个基本值来表示项目状态,项目管理者能够清楚的辨别项目的进度和成本是否存在偏差。并以此预测项目可能的完工时间和完工时的可能费用。
    累计计划成本额(BCWS)或称累计计划投资额(CBC)
    某一时点应当完成的工作所需投入资金或花费成本的累计值。
    等于计划工作量与预算单价的乘积之和。
    是衡量项目进度和成本费用的一个标尺或基准。
    完成投资额(BCWP)或称累计赢得值(CEV)
    某一时点已经完成的工作所需投入资金的累计值。
    等于已完成工作量与预算单价的乘积之和。
    是反映了满足质量标准的工作实际进度和工作绩效,体现了投资额到项目成果的转化。
    实际成本额(ACWP)或称累计实际成本(CAC)
    某一时点已经完成的工作所实际花费成本的总金额。
    等于已完成工作量与实际支付单价的乘积之和。
    两个公式
    在这里插入图片描述
    在这里插入图片描述

    决策树必考

    比较简单

    PDM图必考

    知识点:
    若随机变量X服从一个数学期望为μ、方差为σ2的正态分布,记为N(μ,σ2)。其概率密度函数为正态分布的期望值μ决定了其位置,其标准差σ决定了分布的幅度。当μ = 0,σ = 1时的正态分布是标准正态分布。
    2、正态曲线下,横轴区间(μ-σ,μ+σ)内的面积为68.268949%。
    P{|X-μ|<σ}=2Φ(1)-1=0.6826
    横轴区间(μ-2σ,μ+2σ)内的面积为95.449974%。
    P{|X-μ|<2σ}=2Φ(2)-1=0.9544
    横轴区间(μ-3σ,μ+3σ)内的面积为99.730020%。
    P{|X-μ|<3σ}=2Φ(3)-1=0.9974
    对于PERT法
    图像题:
    正推过程:按照时间顺序计算最早开始时间和最早完成时间的过程
    首先建立项目的开始时间(网络图中首个活动ES:项目的开始时间)
    从左到右,从上到下进行任务编排,求出每一个活动的ES与EF(EF=ES+活动估计工期)
    当一个后置活动有多个前置活动时,选择其中最大的最早完成时间作为后置活动的最早开始时间.
    ES(S)=Max{EF(Pi)},Pi : 活动S的所有直接前置活动
    在这里插入图片描述

    历时估计基本方法-CPM
    逆推过程:按照逆时间顺序计算最晚开始时间和最晚结束时间的方法
    首先建立项目的结束时间(网络图中最后一个活动的最晚结束时间)
    从右到左,从上到下进行计算,求出每一个活动的LF和LS(LS=LF-活动的估计工期)
    当一个前置活动有多个后置活动时,选择其中最小的最晚开始时间作为前置活动的最晚完成时间.
    LF§=Min{LS(Si)},Si : 活动P的所有直接后置活动
    在这里插入图片描述

    填空题

    1.实现项目目标的制约因素有项目范围成本进度计划和客户满意度

    2.一个组织的管理工作包括战略管理运作管理项目管理

    3.项目管理的五要素是技术、方法、团队建设、问题、过程

    4.项目管理的战术关注点是进度、成本、范围和质量

    5.项目管理的核心是进度管理成本管理

    6.项目管理过程大致分为项目开始、项目计划、项目执行控制和项目结束四个阶段

    7.项目管理的5个标准化过程组是启动过程组、计划过程组、控制过程组、执行过程组和收尾过程组

    8.项目管理的战略关注点是人员、问题和过程

    9.项目按来源可分为合同项目内部项目两大类

    10.甲方初始过程包括招标书定义、一方选择、合同签署三个阶段

    11.招标的方式有公开招标、有限招标、多方洽谈、直接谈判等多种

    12.项目经理的主要责任包括开发计划、组织实施、项目控制

    13.乙方初始过程包括招标书定义、乙方选择、合同签署三个阶段

    14.需求主要指用户对软件的功能性能的要求

    15.软件需求包括业务需求、用户需求和功能需求

    16.任务分解的标准主要有生存期、功能组成、其他方法等几种

    17.任务分解的方法主要有参照、类比、自顶向下、自底向上等几种

    18.进度管理常用的图标有甘特图、网络图、里程碑图、资源图

    19.编址进度计划需要从成本估计、时间估计和进度编制三维考虑

    20.进度编制的基本方法主要有关键路径法、时间压缩法、资源调整尝试法、关键链路法

    21.时间压缩法可分为应急法和平行作业法

    22.成本管理包括成本预测、分析、决策和控制

    23.项目规模(工作量统计)的计量方式包括规模估算和成本估算两大类,计量单位常为货币

    24.成本估算需要考虑直接成本间接成本两大块。最常用的估算方式是代码行、功能点、类比估算法、参照估算、专家估算法

    25.软件质量是软件满足明确说明隐含的需求的程度,可通过合同、标准、图纸三个方面共11项特性加以描述

    26.主观质量模型(ICEDT)包括直观性、一致性、效率、耐久性和体贴五个方面

    27.软件质量管理由质量管理计划、质量保证和质量控制三个过程

    28.审计是一种常见的对过程或者或者产品的一次独立评估活动,他包括项目执行过程评审和项目产品审计两方面

    29.软件项目常用的质量控制活动包括静态分析、动态测试、缺陷跟踪三个方面

    30.影响软件项目进度、质量和成本的因素是人、技术和过程

    31.组织结构的主要类型有职能型、项目型和矩阵型三种

    32.风险规划的主要策略有回避风险、转移风险、损失风险和自留风险

    33.项目评审按时间通常分为定期评审、阶段评审和事件评审

    34.甲方合同管理主要包括验收和违约处理两个过程

    展开全文
  • 软件项目开发计划书

    千次下载 热门讨论 2012-11-17 02:48:24
    软件项目开发计划书》以学生成绩管理系统为例,很好的描述软件项目开发计划详细操作流程。
  • 软件项目管理笔记

    万次阅读 2020-05-13 09:51:18
    软件项目管理概述 1.实现项目目标的制约因素有: 项目范围 成本 进度计划 客户满意度 2.项目管理包括: 启动过程组 计划过程组 执行过程组 控制过程组 收尾过程组 3.什么是项目: 为了创造一个唯一的产品或者...

    第一章.软件项目管理概述

    1.实现项目目标的制约因素有:

    • 项目范围
    • 成本
    • 进度计划
    • 客户满意度

    2.项目管理包括:

    • 启动过程组
    • 计划过程组
    • 执行过程组
    • 控制过程组
    • 收尾过程组

    3.什么是项目:

    为了创造一个唯一的产品或者提供一个唯一的服务而进行的临时性的努力,所以说项目具有临时性特性

    4.过程管理就是对过程进行管理,目的是要让过程能够被共享,复用,并得到持续的改进

    5.项目与日常运作的区别与共同点:

    项目日常运作
    以目标为导项通过效率和有效性的体现
    通过项目经理及其团队工作完成的职能式的线性管理
    项目是一次性的日常运作可以重复进行

    共同点:

    都需要人来做;而且都受资源限制;都需要规划,执行,控制

    6.项目的特征:项目均是有时间范围的,所以最能表现项目特征的是确定期限

    7.请简述项目管理的 5 个过程组及其关系

    (1)启动过程组:主要是确定一个项目或一个阶段可以开始了,并要求着手实行;定义
    和授权项目或者项目的某个阶段。 (2)计划过程组: 为完成项目所要达到的商业要求而进行
    的实际可行的工作计划的设计、 维护, 确保实现项目的既定商业目标。 计划基准是后面跟踪
    和监控的基础。 (3)执行过程组:根据前面制定的基准计划,协调人力和其他资源,去执行
    项目管理计划或相关子计划。 (4)控制过程组: 通过监控和检测过程确保项目达到目标, 必
    要时采取一些修正措施。 集成变更控制是一个重要的过程。 (5)收尾过程组: 取得项目或阶
    段的正式认可并且有序地结束该项目或阶段。 向客户提交相关产品, 发布相关结束报告, 并
    且更新组织过程资产并释放资源。
    关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。
    其中,计划过程组、执行过程组、控制过程组是核心管理过程组。

    8.项目的特征是什么

    目标性、相关性、临时性、独特性、资源约束性、不确定性

    第二章.项目确立

    1.项目立项之后,项目负责人会进行自造购买决策,确立待开发产品的哪些部分的应该采购,外包开发,自主研发等

    2,项目经理的主要职责是:

    • 开发计划
    • 组织实施
    • 项目控制

    3.在(立项)阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。注意:项目立项是需求方(甲方)提出的需求

    4.项目招标阶段

    • 甲方过程:

    (招标书定义) 、(供方选择)、(合同签署)

    • 乙方过程:

    (项目分析) 、(竞标)、(合同签署)
    总而言之:甲方:客户(上帝),乙方:软件开发方

    5.项目建议书是项目立项阶段(项目的初始阶段)开发的文档

    6.甲方(顾客,需求方)招标阶段的任务是:

    • 招标书定义
    • 供方选择
    • 合同签署

    7.某公司希望开发一套软件产品, 如果选择自己开发软件的策略, 公司需要花费 30000 元,根据历史信息,维护这个软件每个月需要 3500 元。如果选择购买软件公司产品的策略,需要 18000 元,同时软件公司为每个安装的软件进行维护的费用是 4200 元/月。该公司该如何决策?

    自制方案:
    制造费 30000 元 维护费 3500 元/月
    购买方案:
    购买费 18000 元 维护费 4200 元/月
    制造差额: 30000-18000=12000 元
    服务差额: 4200-3500=700 元
    自制方案承受月份: 12000/700=17.14
    如果产品在 17 个月以内可以选择购买方案,如果超过 17 个月选择自造方案。

    8.什么是项目章程?

    项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件, 包括对项
    目的确认、对项目经理的授权和项目目标的概述等。

    9.招标书主要包括那几部分内容?

    招标书主要包括三部分内容:技术说明、 商务说明和投标说明。技术说明主要对采购的
    产品或者委托的项目进行详细的描述, 商务说明主要包括合同条款。 投标说明主要是对项目
    背景、标书的提交格式、内容、提交时间等做出规定。

    第三章.生存期模型

    1.瀑布模型 生存期模型中, 要求项目所有的活动都严格按照顺序进行,一个阶段的输入是下一个阶段的输入。

    2.敏捷开发通过迭代和快速用户反馈应对管理的不确定性和变更

    3,每日站立会议是(Scrum)模型敏捷开发实践

    4.瀑布模型适合短期项目

    5.增量式模型可以避免一次性投资太多带来的风险

    6.各个模型的优缺点:

    模型特点缺点使用范围
    瀑布模型线性,阶段计划分明,以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导缺乏灵活性,无法解决需求不明确或者不准确的情况;(2)由于开发是线性的,只有到末期才能见到开发成果,增加了开发的风险;(3)早期的错误到后期才能发现适用于需求明确,解决方案明确的项目
    V模型纠正了人民不重视测试阶段的重要性的错误认识,将测试分等级,并且和前面的开发阶段对应仍然将测试作为一个独立的阶段,并没有提高抗风险能力与瀑布模型类似
    快速原型模型有助于增进软件人员和用户对系统服务需求的理解文档容易被忽略,建立原型的许多工作会被浪费掉,项目难以规划和管理适用于需求不明确,动态变化的项目
    增量模型增强了客户使用的信心,逐步提出对后续增量的需求;增量由高到低的优先级确定保障了系统重要功能部分的可靠性;项目总体失败的风险比较低增量粒度选择问题,确定所有的基本服务比较苦难适用于需求大部分明确,系统较为复杂,有一定的技术风险

    渐进式模型:

    • 缺点:需要精心规划各个阶段目标,每个阶段提交的是正式版本,所以工作量会增加
    • 使用范围:主要适用于中型或者大型项目,是目前开发中最常用的开发模型
      敏捷生存模型:通过迭代和快速的用户反馈管理不确定性和应对变更
      敏捷开发宣言:

    个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;相应变化胜过遵循计划
    适用于需求不明确的情况下采用

    7.三种你熟悉的生存期模型,并说明这些模型适用于什么情况下的项目

    (1)瀑布模型
    适用于软件需求很明确的软件项目, 即一般适用于功能明确、 完成、 无重大变化的软件系统
    的开发,即:
    1) 在项目开始前,项目的需求已经被很好的理解、也很明确,而且项目经理很熟悉为实现
    这一模型所需要的过程。
    2) 解决方案在项目开始前也很明确。
    3) 短期项目可采用瀑布模型。
    (2)V 模型
    适用于项目需求在项目开始前很明确、解决方案在项目开始前也很明确,项目对系统的
    安全很严格,如航天飞机控制系统、公司的财务系统等。
    (3)快速原型模型
    适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候。

    第四章 软件项目范围计划——需求管理

    1.需求管理包括:

    • 需求获取
    • 需求分析
    • 需求规格编写
    • 需求验证
    • 需求变更

    2.原型分析方法 是其中一种需求建模方法。

    3.结构化分析方法是一种自下而上逐步求精的分析方法

    4.软件项目管理需求过程:

    • 需求获取
    • 需求分析
    • 需求规格编写

    5.数据字典组成部分:

    • 数据项
    • 数据流
    • 数据文件

    6.下列不属于 UML 需求视图的是?

    甘特图(甘特图用于做计划的视图)
    属于需求的视图的是:用例图,状态图,顺序图

    7.属于需求建模的方法:

    • 原型方法
    • 面向对象的用例分析方法
    • 功能列表方法

    8.(需求变更)软件项目的一个突出特点,可以导致软件项目的蔓延

    9.结构化方法设计有:

    • 数据流图
    • 数据字典
    • 系统流程图

    10.我们常常从哪些方面着手处理需求不明确的问题?

    (1)让用户参与开发
    (2)开发用户界面原型
    (3)需求讨论会议
    (4)强化需求分析和评审

    第五章 软件项目范围规划——任务分解

    1.任务分解是将一个项目分解为更多的工作细目或者 子项目 ,是项目变得更小、更易管理、更易操作

    2.一般来说,进行项目分解时,可以采用 清单 或图表 两种形式来表达任务分解的结果。

    3.WBS的全称是 任务分解结构 :Work Breakdown Structure。

    4.WBS最底层次可交付成果是 :工作包 work package。

    5.WBS提供了项目范围基线

    6. 一个工作包可以分配给另一个项目经理去完成。(注:工作包应当由唯一主体负责,可以分配给另外一位项目经理通过子项目的方式完成。)

    7.对于一个没有做过的项目,开发 WBS时可以采用自底向上方法。

    8. 在任务分解结果中,最底层的要素必须是实现项目目标的充分必要条件。

    9.任务分解是将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理和操作。

    10.一个工作包应当由唯一主体负责。

    11.WBS的最底层任务是能分配到一个人完成的任务。

    12…WBS非常重要,因为:

    帮助组织工作,防止遗漏工作,为项目估算提供依据 但是不包括确定团队成员责任

    13.WBS中的每一个具体细目通常都指定唯一的编码

    14.创建 WBS的方法有:

    自顶向下 ,自底向上 ,模板参照,不包括控制方法

    15.任务分解时,

    (自底向上)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组织起来,形成更高级别的 WBS层。
    (自顶向下)方法从一般到特殊的方向进行,从项目的大局着手,然后逐步分解子细目,将项目变为更细、更完善的部分

    16.WBS的定义:

    (1)WBS是任务分解的结果;(2)不包括再 WBS中的任务就不是该项目的工作;(3)可以采用清单或者图表的形式标识WBS的结果

    17.检验 WBS分解结果的标准:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层元素是否有重复
    • 最底层要素是否有清晰完整定义

    18.WBS是对项目由粗到细的分解过程,它的结构是:分级的树形结构

    19.任务分解的方法和步骤

    任务分解的基本步骤:

    • 确认并分解项目的组成要素 (WBS编号 ) 。
    • 确定分解标准,按照项目实施管理的方法分解,而且分解的标准要统一。
    • 确认分解是否详细,是否可以作为费用和时间估计的标准,明确责任。
    • 确定项目交付成果(可以编制 WBS字典)。
    • 验证分解正确性。验证分解正确后,建立一套编号系统。

    任务分解方法:

    • 模板参照方法
    • 类比方法
    • 自上而下
    • 自下而上

    20.当项目过于复杂是,可以对项目进行任务分解,这样做的好处是什么?

    将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理、 更易操作,这样可以提高估算成本、时间和资源的准确性,使工作变得更易操作,责任分工更加明确。

    21.检验任务分解结果的标准是什么?

    检验任务分解结果的标准有:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层要素是否有重复的
    • 每个要素是否清晰完整定义
    • 最底层要素是否有定义清晰的责任人
    • 是否可以进行成本估算和进度安排

    第六章 项目成本计划

    1.软件项目成本包括直接成本和间接成本,一般而言,项目人力成本归属于直接成本。

    2.再在项目初期,一般采用的成本估算方法是类比估算法。

    3.功能点方法中 5 类功能组件的计数项是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件。

    4.软件项目的主要成本是人的劳动的消耗所需要的代价。

    5.用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算

    6.人的劳动消耗所付出的代价是软件产品的主要成本。

    7.估算时既要考虑直接成本又要考虑间接成本。

    8.(规模)是成本的主要因素,是成本估算的基础

    9.常见的成本估算方法:

    代码行,功能点,类比法;记住不包括关键路径法

    10.UFC的功能计数项:

    UFC:未调整功能点计数
    包括:外部输出,外部文件,内部文件

    11.成本预算的目的是:产生成本基线

    12.估算的基本方法包括:

    1)代码行,功能点;2)参数估算法;3)专家估算法;记住不包括函数估算法

    13.在项目初期,进行竞标合同时,一般采用的成本估算方法是类比估算法

    14.软件项目规模单位有:

    • 代码长度(LOC)
    • 功能点(FP)
    • 人天,人月,人年
      不包括小时

    15.在成本管理过程中,每个时间段中等各个工作单元的成本是(预算)

    16.项目经理正在进行一个图书馆信息查询系统的项目估算,他采用 Delphi 的专家估算方法,邀请了 3 位专家进行估算, 第一位专家给出了 2 万元、 7 万元、 12 万元的估算值, 第二位专家给出了 4 万元、 6 万元、 8 万元的估算值,第三位专家给出了 2 万元、 6 万元、 10 万元的估算值,试计算这个项目的成本估算值

    专家一: Ei=(ai+4mi+bi)/6= (2+47+12)/6=7
    专家二: Ei=(ai+4mi+bi)/6=(4+4
    6+8)/6=6
    专家三: Ei=(ai+4mi+bi)/6= (2+4*6+10 )/6=6
    Ei=(7+6+6)/3=6.33 (万元)

    17.如果某软件公司正在进行一个项目,预计有 50KLOC的代码量,项目是中等规模的半嵌入型的项目,采用中等 COCOMO模型,项目属性中只有可靠性为很高级别(即取值为 1.3),其他属性为正常 (书上说, 正常就是 1),计算项目是多少人月的规模, 如果是 2 万元 /人月,则项目的费用是多少?

    Effort=a* (KLOC)b F
    查表 a=3,b=1.12,F=1
    Effort=3.0
    50
    1.12 1.31=311.82 (人月)
    所以项目的费用为 2* Effort=623.64 万元

    18.已知某项目使用 C语言完成,该项目共有 85 个功能点,请用 IBM 模型估算源代码行数、工作量项目持续时间、人员需要量以及文档数量。

    C 语言代码行与功能点的关系近似为 150LOC/FP,所以, 85 个功能点代码行数为
    L=85150=12750 行=12.75KLOC,则:工作量估算 E=(5.2L)的0.91次方 =(5.212.75)的0.91次方≈52.725(人月)
    项目时间 D=(4.1
    L)的0.36次方 =(4.112.75)的 0.36次方 ≈10.25(月)
    人员需求量 S=(0.54
    E)的 0.6次方 =0.5452.725的0.6次方 ≈5.829(人)
    文档数量 DOC=49
    L 的1.01次方 =49*12.75的1.01次方≈640.857(页)

    第七章软件项目进度计划

    1.关键路径 决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间

    2.时间 是一种特殊的资源,以其单向性、不可重复性、不可替代性而有别于其他资源,是项目计划中灵活性最小的因素 。

    3.在 ADM 网络图中,箭线表示 活动(任务),结点表示前一个任务的结束,同时表示后一个任务的开始 。

    4.应急法 和平行作业法 都是时间压缩法。

    5.任务(活动) 之间的排序依据主要有 强制性依赖关系、 软逻辑关系、 外部依赖关系 等。

    6.工程评估评审技术采用加权平均的公式是 PERT历时 =(O+P+4M)/6 ,其中 O 是乐观值, P是悲观值, M 是最可能值。

    7.一个工作也可以通过多个活动完成。

    8.在项目进行过程中,关键路径是可变的

    9.在 PDM 网络图中,箭线表示的是任务之间的逻辑关系,节点表示的是活动。

    10.在资源冲突问题中,过度分配也属于资源冲突。

    11.浮动是在不增加项目成本的条件下,一个活动可以延迟的时间量

    12.在使用应急法压缩时间时,要在关键路径上选择活动来进行压缩,因为能够压缩的都是关键路径。

    13.时间是项目规划中灵活性最小的因素。

    14.常用的公式:

    • EF(最早完成时间)=ES(最早开始时间)+duration(任务的历时时间)
    • LS(最晚开始时间)=LF(最晚完成时间)-duration(任务的历时时间)
    • TF(总浮动:在不影响项目最早完成时间)=LS(最晚开始时间)-ES(最早开始时间)=LF(最晚完成时间)-EF(最早完成时间)
    • FF(自由浮动:在不影响后置任务最早开始的时间)=ES(最早开始时间)-EF(最早完成时间)-lag(本任务与后置任务之间的之后时间)

    15.常见的依赖关系:

    • 强制性依赖关系
    • 软逻辑关系
    • 外部依赖关系
    • 里程碑

    16.(甘特图)可以显示任务的基本信息,使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。

    17.(进度问题)是项目冲突的主要原因,尤其在项目后期。

    18.编制进度的基本方法:

    • 关键路径法
    • 时间压缩法
    • 资源平衡法
      注:系统图法不是

    19.快速跟进是指采用并行执行任务,加速项目进展

    20.(lag)将延长项目的进度

    21.(总浮动)可以决定进度的灵活性

    22.对一个任务进行进度估算时, A 是乐观者,估计用 6 天完成, B 是悲观者,估计用 24天完成, C是有经验者,认为最有可能用 12 天完成,那么这个任务的历时估算介于 10天到 16 天的概率是多少?

    E=(6+24+4*12)/6=13 , δ=(24-6)/6=3
    E-δ =10
    E+δ=16
    查表(p139)得任务历时估算介于 10—— 16 天的概率为: 68.3%

    23.请将下图所示的 PDM(优先图法)网络图改画为 ADM(箭线法)网络图。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RbSNI3en-1589334555768)(1.png)]

    上图对应的 ADM 图如下所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wJ2BirqS-1589334555770)(2.png)]

    24.根据下面任务流程图和下表给出的项目历时估算值,采用 PERT方法估算,求出项目在14-57 天内完成的概率的近似值。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Tpm3FGPR-1589334555772)(3.png)]
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p2qjSfsr-1589334555774)(4.png)]

    标准差:δ=(P-O)/6;

    第八章软件项目质量计划

    1.(审计)是对过程或产品的一次独立质量评估。

    2.质量成本包括预防成本和(缺陷成本)。

    3.质量管理包括(软件质量计划) 、(软件质量保证) 、(软件质量控制)等过程。

    4.(软件质量)是软件满足明确说明或者隐含的需求的程度。

    4.McCall 质量模型关注的 3 个方面是(产品运行) 、(产品转移) 、(产品修改)。

    5.质量管理总是围绕着(质量保证)和(质量控制)过程两个方面进行。

    6.质量保证的主要活动是(项目执行过程审计)和(项目产品审计)

    7.质量是满足要求的程度 ,包括符合规定的要求和满足顾客隐含需求

    8. 软件质量是软件满足明确说明或者隐含的需求的程度。

    9.质量形成于产品或者服务的开发过程中, 而不是事后的检查 (测试) 把关等。

    10.质量计划可以确定质量保证人员的特殊汇报渠道。

    11.质量管理过程:

    • 质量计划
    • 质量保证
    • 质量控制

    12.项目质量管理的目标是满足(项目)的需要

    13.质量成本:

    • 预防成本(评估费用和评估费用)
    • 缺陷成本(内部费用和外部费用)

    14.软件质量模型:

    • Boehm 质量模型
    • McCall 质量模型
    • ISO/IEC 9216质量模型

    15.质量控制非常重要,但是进行质量控制也需要一定的成本, (使用抽样统计)可以降低质量控制的成本。

    16.McCall 质量模型包含:

    • 产品修改
    • 产品转移
    • 产品运行
    • 不包括产品特点

    17.质量计划中可以采用哪些方法?

    质量计划中可以采用以下几种方法:
    (1)试验设计:试验设计是一种统计学方法,确定哪些因素可能会对特定变量产生影响。
    (2)基准对照:是一种寻找最佳实践的方法,是利用其他项目的实施情况作为当前项目性能衡量的标准。
    (3)质量成本分析:质量计划必须进行质量成本的综合分析,以便决定质量活动。
    (4)流程图方法:可以显示系统的各种成分是相互的关系,帮助我们预测在何处可能发生何种质量问题。
    (5)因果分析图:也称鱼刺图。描述相关的各种原因和子原因如何产生潜在问题或影响,将影响质量问题的 “人员、 设备、参考资料、 方法、环境”等各方面的原因进行细致的分解,方便地在质量计划中制定相应的预防措施。

    18. 简述质量保证的主要活动,以及质量保证的要点。

    质量保证的主要活动是项目执行过程审计和项目产品审计。
    质量保证的要点是:对项目进行评价、推测能否达到质量指标、建立对项目的信心

    19.简述质量保证与质量控制的关系。

    质量保证( QA)是通过评价项目整体绩效 ,建立对质量要求的信任,提供项目和产品可
    视化的管理报告。 这个任务本身并不能提高产品的质量, 但是通过质量保证的一系列工作可
    以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。
    质量控制( QC)是确定项目结果与质量标准是否相符 ,同时 ,确定消除不符的原因和方法,它
    控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。
    质量保证是后期质量活动,质量控制是前期质量活动。它们是有区别的 :质质量保证是针对
    项目实施过程的管理手段,质量控制是针对项目产品的技术手段 ;实施质量保证是针对过程
    改进和审计的, 强调的是过程改进和信心保证。 实施质量控制是按照质量要求, 检查具体可
    交付成果的质量,强调的是具体的可交付成果。

    第九章软件配置管理计划

    1. 配置管理最终保证软件产品的(完整性) 、(一致性)、(追溯性)、(可控性)。

    2.(完整性和可跟踪性)是软件配置管理的核心功能。

    3.(基线)标志开发过程中一个阶段的结束和里程碑。

    4. 基线变更控制包括(变更请求) 、(变更控制) 、(变更批准 /拒绝)、(变更实现)等步骤。

    5.(版本管理) 、(变更管理)是配置管理的主要功能。

    6. 基线变更时,需要经过( SCCB)授权。

    7. SCCB的全称是(软件配置控制委员会) 。

    8.基线提供了软件生存期中各个开发阶段的一个特定点(记住是各个开发阶段,不是单独的某一个开发阶段)

    9.一个(些)配置项形成并通过审核,即形成基线。

    10.变更控制系统包括从项目变更申请、 变更评估、 变更审批到变更实施的文档化流程。

    11. 基线修改应受到控制,而且一定要经 SCCB授权。

    12.基线产品是可以修改的

    13.基线的修改需要每次都按照正式的程序执行。

    14. 软件配置项是项目需定义其受控于软件配置管理的款项, 每个项目的配置项不一定是相同的。

    15.SCCB的职责:

    • 评估变更
    • 与项目管理层沟通
    • 对变更进行反馈
    • 注意:提出变更申请不是sccb的职责

    16.为了更好地管理变更, 需要定义项目基线, 关于基线:

    可以变化,但是必须通过基线变更控制流程处理

    17.软件配置管理可以确保软件产品完整性,一致性,可控性,但是无法确保产品的正确性

    18.变更控制需要关注的是:标识变更,提出变更,管理变更

    19.配置管理的基本过程:

    (1)配置项标识、跟踪; ( 2)配置管理环境建立; (3)基线变更管理; (4)配置管理审
    计;(5)配置状态统计; ( 6)配置管理计划。

    20.软件配置控制委员会( SCCB)的基本职责:

    评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项
    目管理层沟通。

    21.配置管理在软件 开发中的作用,并列举至少两种配置管理工具

    软件配置管理是软件项目管理的重要内容,也是保证软件质量的重要手段。它能
    够对软件开发过程进行有效管理和控制, 从而实现软件产品的完整性、 一致性、可控性,使
    产品极大程度地与用户需求相吻合。 它能够控制、 记录、追踪对软件的修改并形成规范文档,
    方便日后维护和升级,更重要的是能够保护代码资源,积累软件财富,提高软件重用率。
    配置管理工具有: Harvest、 Perforce、ClearCase、PVCS、CVS\SVN、 VSS

    22.写出几个常见的软件配置项

    软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清
    单、厕所规格说明书、 测试计划、 测试用例与实验结果、 可执行程序、 用户手册、 维护文档。

    第十章软件项目人员与沟通计划

    1. 沟通管理的基本原则是及时性、准确性、完整性、可理解性。

    2.可以充分发挥部门资源优势集中的组织结构为职能型组织结构

    3. 沟通计划用于确定谁需要信息,需要什么信息,何时需要信息,以及如何将信息分发给他们。

    4. 组织结构的主要类型:

    • 职能型(适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构,是目前最普遍的项目组织形式,它是一个标准的金字塔型组织形式)
    • 项目型(在这种组织结构中项目成员没有安全感)
    • 矩阵型(项目涉及多的领域和特性)

    5. 会议形式 沟通最有可能协助解决复杂的问题。

    6.当项目中有 20 个人时,沟通渠道最多有 190。

    公式:N(N-1)/2  其中N:表示人员总数
    

    7.项目干系人是项目计划的一部分。

    8.项目沟通的基本原则是及时性、准确性、完整性和可理解性

    9.在 IT 项目中,成功的最大威胁是沟通的失败

    10.责任分配矩阵是明确项目团队成员的角色与职责的有效工具

    11.对于紧急的信息, 应该通过口头的方式沟通; 对于重要的信息, 应采用书面的方式沟通

    12.人员计划描述项目的团队人员什么时候,以及如何加入和离开团队

    13.沟通计划包括确定谁需要信息, 需要什么信息, 何时需要信息, 以及如何接收信息等

    14.人员管理计划没有明确的具体体现形式, 作为项目计划的一部分, 其详细程度因项目而异

    15.项目经理花在沟通上的时间是 75%-90%

    16.干系人:

    • 影响项目决策的个人、群体或者组织
    • 影响项目活动的个人、群体或者组织
    • 影响项目结果的个人、群体或者组织
    • 注意只有这三种,并不是适应所有的项目人员

    17.编制沟通计划的基础是沟通需求分析

    18. 团队:

    • 是一定数量的个体成员的集合
    • 团队应注重个人发挥,应该将某项任务分工给擅长该技术的职员
    • 团队的目的是开发出高质量的产品
    • 团队包括自己组织的人、供应商、分包商,注意没有客户

    19.写出 5 种以上项目沟通方式

    沟通方式主要有书面沟通和口头沟通、 语言沟通和非语言沟通、 正式沟通和非正式沟通、
    单向沟通和双向沟通、网络沟通等

    20.矩阵型项目组织结构的优缺点是什么

    优点是: 1、专职的项目经理负责整个项目,以项目为中心,能迅速解决问题。在最短的时间内调配人才,组成一个团队,把不同职能的人才集中在一起。
    2、多个项目可以共享各个职能部门的资源。在矩阵管理中,人力资源得到了更有效的利用,减少了人员冗余。
    3、既有利于项目目标的实现,也有利于公司目标方针的贯彻
    4、项目成员的顾虑减少了,因为项目完成后,他们任然可以回到原来的职能部门,不用担心被解散,而且他们能有更多机会接触自己企业的不同部门。
    缺点是 1、容易引起职能经理和项目经理权利的冲突。
    2、资源共享可能引起项目之间的冲突
    3、项目成员有多位领导,即员工必须要接受双重领导,因此经常有焦虑与压力

    第十一章软件项目风险计划

    1.风险评估的方法包括

    • 定性风险分析
    • 定量风险分析。

    2.决策树分析是一种 形象化的图表分析 方法。

    3.项目风险的三要素是

    • 风险事件
    • 风险事件发生的概率
    • 风险造成的影响

    4.(回避)风险是指尽可能地规避可能发生的风险, 采取主动放弃或者拒绝使用导致风险的方案

    5.风险规划的主要策略(应对风险的常见策略)是:

    • 回避风险
    • 转移风险
    • 损失控制
    • 自留风险

    6.软件项目风险识别常采用 德尔菲方法、头脑风暴法、情景分析法、风险条目检查表、其他等方法。

    7.定量风险评估主要包括 访谈、盈亏平衡分析、决策树分析、模拟法、敏感性分析 等方法。

    8.风险管理的 4 个过程:

    • 风险识别
    • 风险评估
    • 风险规划
    • 风险控制

    9.风险的三要素:

    • 一个事件
    • 事件发生的概率
    • 事件的影响

    10.险评估方法:

    • 盈亏平衡分析
    • 模拟法
    • 决策树分析

    11.一个项目在进行规划的时候,碰到了一个风险问题,项目经理决定是否采用方案 A。如果采用方法 A 需要使用一个新的开发工具,而能够掌握这个工具的概率是 30%,通过使用这个工具可以获利 5 万元,如果采用方案 A 而不能掌握这个工具,将损失 1 万元。利用决策树分析技术说明这个项目经理是否应该采用这个方案 A?(绘制决策树)

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tZxOV8Nj-1589334555777)(5.png)]
    EMV:损益期望值
    公式:EMV=(outcome(回报)*成功概率-亏本 * 亏本概率)
    EMV=(50000 * 30%-10000 * 70%) =8000

    12.某企业在今年有甲乙两种产品方案可以选择,每种方案的状态、收益和概率如表 11-11 所示,绘制决策树时,判断哪种方案将有更大收益。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ya7FxaAB-1589334555778)(6.png)]
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M7GW4oxz-1589334555780)(7.png)]

    第十二章软件项目合同计划

    1.买房风险最高的合同类型: FFP(固定总价合同)

    2.为执行项目而从项目团队外获取产品、服务或者成果的过程称为:采购

    3.合同双方当事人承担不同角色,这些角色包括:甲方、乙方

    4.软件外包的基本步骤:竞标邀请、评估候选乙方的综合能力、确定承包商

    5.如果 CPPC合同类型中成本百分比是 10%,估计成本是 10 万元,当实际成本是 20 万元是,合同金额应该为: 22 万元

    20+10% * 20=22万

    6.一个 CPFF合同类型,估计成本是 10 万元,固定费用是成本 1.5 万元,当成本提高至 20万元是,合同金额为: 21.5 万元

    20+1.5=21.5万

    7.合同类型有:

    • 成本补偿类合同(CPCC)
    • 固定价格类合同(FFP)
    • 单价类合同()
    • 成本加奖金( CPIF)合同
    • 成本加成本百分比(CPPC)
    • 固定成本加奖金(FPIF)

    8.招标书可以是合同计划的输出

    9.对于甲方来说,风险最高的是 CPCC合同类型,风险最低的是 FFP合同类型,乙方则相反

    10.某项目采用成本加奖金的成本补偿类合同,当预算成本为 20 万元,利润 4 万元,且奖励分配为 80/20 时,如果实际成本降至 16 万元,则项目总价为

    项目总价=成本+奖金(节约成本 * 20%)+利润=16+(节约成本=20-16=4)4 * 20%+4=20.8万

    11.合同是需要靠( 相关法律法规)约束的

    12.项目预计成本 10 万,成本百分比 20%,如实际成本 8 万,则合同金额:

    8+20%*8=9.6

    13.成本加奖金合同,激励比 80/20; 估计成本 12 万,利润 1 万。如实际成本 12 万,则合同金额为: 12+1=13 万;如实际成本为 11 万,则合同金额为

    11+1+(12-11)20%=12.2

    第十三章项目集成计划

    1.软件项目管理最终要的 4 个要素是:

    • 范围
    • 质量
    • 进度
    • 成本

    2.质量和成本成一定的正比关系,进度和成本成一定的反比关系,范围和成本成一定的正比关系

    3.为了加快项目进度,可以适当见减低过程中的质量标准

    4.项目集成管理包括:

    • 对计划的集成管理和项目跟踪控制的集成管理
    • 保证项目各要素协调
    • 在相互影响的项目目标和方案中做出权衡
    • 没有软件设计文档

    5.设成本 C 是范围 S、质量 Q、进度 T的一个函数 C=F(S,Q,T),在成本或时间不充足的情况下,可以通过减小范围或者( 降低质量)来解决。

    6.项目管理过程中的进度目标,成本目标,质量目标,范围目标等各个目标之间是(相互关联和制约的)

    7.软件项目管理要素:

    • 范围
    • 质量
    • 成本
    • 不包含交互

    8.项目集成计划的特点:

    • 综合性
    • 全局性
    • 内外兼顾性
    • 不包含针对性

    第十四章项目集成计划执行控制

    1.项目执行控制的基本步骤:

    1)建立计划标准; 2)观察项目的性能; 3)测量和分析结果; 4)采取必要措施; 5)做好计划修订工作,控制反馈。

    第十五章项目核心计划执行控制

    1.软件项目中的软件开发成本是总成本的主要部分。

    2.当 SV=BCWP-BSWS<0时,表示项目进度落后。

    3.代码评审由一组人对程序进行阅读、讨论和争议,它是质量控制过程。

    4.挣值分析法也称为已获取价值分析,是对项目的实施进度、成本状态进行绩效评估的有效方法。

    5.从质量控制图的控制上限和控制下线,可以知道接受的过程的偏差范围。

    6.范围控制的重点是避免需求的变更。

    7. 一个任务原计划 3 个人全职工作 2 周完成,而实际上只有 2 个人参与这个任务,到第二周末完成了任务的 50%,则 CPI=?

    CPI(成本效能指标)=BCWP(已经完成工作的成本预算)/ACWP(到目前为止花了多少钱) * 100%
    * CPI>1:低于预算 ;=1:按照计划进行;<1:超过预算

    8.记录反映当前项目状态的项目性能数据是控制项目的基础。

    9. 项目进度成本控制的基本目标是在给定的限制条件下,用最短时间、最小成本、以最小风险完成项目工作。

    10.代码走查是在代码编写阶段,开发人员自己检查自己的代码。

    11. 在使用应急法压缩进度时,能够进行压缩的只有关键路径。

    12. 累计费用曲线中某时间点 ACWP(到目前为止花了多少钱)比 BCWS(到目前为止本应该完成的工作是多少)高,意味着在这个时间点为止,实际的成本要比计划的高,二者之间的差值就是成本差异。

    13. 技术评审的目的是尽早发现工作成果中的缺陷,并帮助开发人员技师消除缺陷,从而有效的提高产品质量。

    14. 项目原来预计于 2014.5.23 完成 1000 元的工作,但到 2014.5.23 只完成 850 元工作,而为了这些工作花费 900 元,则成本偏差和进度偏差分别是

    SV(进度差异)=BCWP(到目前为止实现了多少价值)-BCWS(到目前为止应该完成多少)
    所以SV=850-1000=-150
    CV(费用差异)=BCWP(到目前为止实现了多少价值)-ACWP(到目前为止花了多少钱)
    所以CV=900-850=50

    15.如果成本效能指标 CPI=90%,他说明投入 1 元产生 0.9 元的效果

    16.进度控制重要的一个组成部分是确定进度偏差是否需要采取纠正措施

    17.资源平衡最好用于(非关键路径)活动

    18.当项目进展到(20%)左右时, CPI处于稳定

    19.抽样统计的方法中,以小批量的抽样为基准进行检验

    20.质量控制的3 个要点:

    • 检查项目结果
    • 依据相关质量标准进行跟踪检查
    • 确定消灭质量问题的措施

    21.某项目由 1、2、3、4 四个任务构成,该项目目前执行到第 6 周末,各项工作在其工期内的每周计划成本、每周实际成本和计划工作量完成情况下表所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8g7YrGmu-1589334555781)(8.png)]

    1.根据提供的信息,计算截至第 6 周末该项目的 BCWS、ACWP、BCWP

    BCWS=10+15+5+10+10+10+20+10+10+5+5=100;
    ACWP=10+16+8+10+10+12+24+12+5+5=112
    BCWP=10+15+5+(10+10+10+20+10+10)/2+(5+5+25+5)/2=95

    2.计算第 6 周末的成本偏差 CV、进度偏差 SV,说明结果的实际意义

    CV=BCWP-ACWP= -17
    SV=BCWP-BCWS= -5

    3.照目前情况,计算完成整个项目实际需要投入多少资金?写出计算公式。

    CPI=BCWP/ACWP=84%
    EAC=BAC/CPI=170/84% = 202

    22.某项目正在进行中,下表是项目当前运行状况的数据,任务 1、2、3、4、5、6 计划是按顺序执行的,表中也给出了计划完成时间和实际的执行情况。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pqy65eOI-1589334555782)(9.png)]

    1.计算 BAC

    BAC=5+25+120+40+60+80=330

    2.计算截至 2014 年 4 月 1 日的 BCWP、BCWS、 ACWP、 SV、SPI 、 CV、CPI等指标。

    BCWP=5+25+40=70
    BCWS=10+20=30
    ACWP=10+20+50=80
    SV=BCWP-BCWS=40
    SPI=BCWP/BCWS=175%
    CV=BCWP-ACWP=-10
    CPI=BCWP/ACWP=87.5%

    23.试述 Pareto 规则

    80%的问题是由 20%的原因引起。

    第十六章项目辅助计划执行控制

    1.项目周例会是一种正式沟通方式。

    2.在马斯洛的需求层次理论中,最高层需求是自我实现。

    3. Y理论属于参与理论

    4.风险管理是连续的过程。

    5.管理干系人参与和控制干系人参与都是干系人管理的任务。

    6.敏捷生存期模型中的每天站立会议是很有效的一种沟通方式。

    7.对于冲突而言,冲突常常是有利的事情

    8.项目培训特点:

    • 时间短
    • 针对性强
    • 见效快

    9.冲突解决方法:

    • 解决问题( confrontationorproblemsolving )
    • 妥协( compromise )
    • 强迫方式( forcingmode )
    • 撤退( withdrowal )

    10.项目中的小组成员要同时离开公司,项目经理首先应该( 实施风险计划 )。

    11.一个软件项目团队中一般有哪些人员角色?

    项目经理、架构分析师、系统分析师、 DBA、程序开发人员、测试人员、系统工程师、
    质量管理人员

    十七章 项目结束过程

    1.项目目标已经成功实现,可交付成果已经出现;或者项目无法继续进行,这时项目可以 终止 了。

    2.项目结束过程包括

    • 制定结束计划
    • 完成收尾工作
    • 项目最后评审。

    3.是否在预算成本内完成项目、是否实现目标、是否达到项目客户的期望等都是检验项目成功与失败的标准。

    4. 项目验收过程是甲方对乙方交付的产品或服务进行验收检验,以保证它满足合同条款的要求。

    5. 项目计划中确定的可交付成果已经出现, 项目的目标已经成功实现时, 可终止项目。

    6.一个项目的交付验收,意味着项目的结束

    7.当一个项目的目标已经实现,或者明确看到目标已经不可能实现时,项目就应该终止。

    8. 客户接受项目的交付结果之前,项目经理应该检查交付结果的质量

    9.不包括在项目验收过程中的是 项目总结

    10.项目终止的条件:

    • 项目计划中确定的可交付成果已经出现,项目的目标已经成功实现
    • 项目已经不具备实用价值
    • 项目由于各种原因而导致无限期拖长
    • 不包括项目需求发生了变化

    11.项目成功与失败的标准是:

    • 是否实现目标
    • 可交付成功如何
    • 是否达到项目客户的期望
    • 不包括项目人数庞大

    12. 在项目的末期,与卖方的合同还有尚未解决的索赔,项目经理(进行合同收尾,合同收尾之后,可能采取法律行动)。

    展开全文
  • 软件项目实施方案标准范文

    千次下载 热门讨论 2013-10-15 15:47:52
    软件项目实施方案范文
  • 软件项目开发流程

    万次阅读 多人点赞 2019-10-08 05:30:56
    首先 看一下基本软件项目开发流程图 其中 1.需求分析: 通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书。 2.总体设计: 通过分析需求信息,对系统的外部条件及内部...

     

     

     

     软件开发流程(Software development process)

     首先 看一下基本软件项目开发流程图

    其中

    1.需求分析:
      通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书。
    2.总体设计:
      通过分析需求信息,对系统的外部条件及内部业务需求进行抽象建模,最终形成概要设计说明文档。
    3.详细设计:
      此部分在对需求和概要设计的基础上进行系统的详细设计(也包含部分代码说明)。
    4.开发编程:
      对系统进行代码编写。
    5.测试分析与系统整合:
      对所有功能模块进行模拟数据测试及其它相关性测试并整合所有模块功能。
    6.现场支持:
      系统上线试运行进行现场问题记录、解答。
    7.系统运行支持:
      系统正式推产后,对系统进行必要的维护和BUG修改

     

     

    需求分析是怎样做的?

    需求分析是构建软件系统的一个重要过程。 一般,把需求类型分成三个类型: 

    1、业务需求(business requirement)
      反映了组织机构或客户对系统、产品高层次的目的要求,它们在项目视图与范围文档中予以说明。 
    2、用户需求(user requirement) 
      文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明。 3、功能需求(functional requirement)
      定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。

     

    业务需求和用户需求是软件需求分析的基础,也是软件构建的前提。
    系统分析员通过对业务需求和用户需求的分解,将其转换成可以形式化描述的软件功能需求。
    开发软件系统最为困难的部分,就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。

      客户也经常是矛盾的。事实上,很少有客户能够明确的知道怎样的一个系统对自己是最有益处的,他们往往在集中方案之间徘徊,于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。
      客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任,但是,当一个软件项目因为客户事先没有预料到的情况而导致失败的时候,即使客户不会追究开发方的责任,就软件项目本身而言,也已经是失败的。
     
    总结: 
    良好的需求分析是软件成功的基础。
    在软件项目整个过程中系统分析员主动进行沟通,提出指导性意见。当软件融合了客户和系统分析员双方智慧,其质量将会进一步得以提高。

     

     

    软件开发管理规范流程图

      摘项目管理的根本目的是按时、保质、保量完成预期交付的成果。项目管理要让整个组织能清楚理解项目实施的目的、影响、进度,应做到项目组所有员工都应理解项目实施的原因、意义及客户的要求。在项目管理中还能看到公司高层领导通过实际行动表现出来的对于项目实施的支持与帮助,通过以制度化管理来组织合理安排员工的工作职责和角色转换。为满足上述要求,就必须让员工、企业、客户能接受并适应新的“软件项目开发管理规范”。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


     

    1.启动阶段

      这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的,首先要明确项目的总体战略目标,对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务,以及需要解决什么样的问题和需要满足客户或市场的什么要求等,同时还要总结项目工作的范围、所需资源、大约开支、各种风险,以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析,通过项目的意向书总结出来,由此确证客户或项目发起人和赞助者的要求与期望,并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。

    • 产品领域研究

      研究产品所在领域的状况,为项目论证提供依据。研究内容包括:

    产品领域的现状和前景
    产品领域的商业模式和业务流程
    产品的价值和盈利空间
    产品的特性和复杂度

     

     

    • 技术可行性研究

      研究产品的实现技术,总结技术可行性。研究内容包括:

    类似产品的当前实现技术和技术趋势
    实现技术的候选方案
    各个方案的优点、成本和风险
    开发团队与实现技术的匹配情况

     

     

     

    • 项目论证

      基于商业和技术等方面对项目的可行性进行论证,确定项目是否开展。如果开展项目,则进一步论证项目的总体方案。

      论证的内容包括:

    商业可行性
    技术可行性
    当前产品与类似产品的比较
    项目收益和前景
    项目的成本和风险
    项目的总体方案

     

     

    • 确定项目目标和范围

      项目开始时,所有相关人员必须对项目的目标和范围达成共识,形成共同的项目愿景。并把愿景叙述为《项目开发大纲》向相关人员传达。

    《项目开发大纲》的内容包括:

     

    概 

    用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责

    高级功能

    用一个段落来综述产品,再用一个段落来描述每个重要的功能

    不实现的功能

    用一个段落来描述每个对产品有用的但本项目不实现的功能

    涉 

    用一个段落来明确每个重要的涉众群体和他们的风险股本

    项目需求

    用一个段落来讲述每个重要的项目需求

    项目风险

    按风险暴露量对每个重要的项目风险都用一个段落来讨论

    项目回报

    用一个段落综述产品的回报,其后再对每个重要的项目回报都用一个段落来讨论

    结 

    用一到三个段落将上述所有部分联系起来,明确项目的需求和风险,再用论点和论据来总结为什么这个项目会成功

     

     

     

    2.计划阶段

      这个阶段的工作是为整个项目做计划。项目开始后,首先要确定项目的具体范围,明确定出项目到底要做什么,总结、归纳并定出产品的功能。然后进一步制定项目的计划,列出每项具体工作,并建立所有工作任务的重要性及顺序;确定每项工作的执行人和所需资源;根据人员的配置和能力设定各项工作和整个项目的完成时间表。

    • 规模、工作量评估

      围绕各项计划的制定工作对项目的规模、工作量等进行评估,评估的内容包括:

    模块数量与复杂度
    输入、输出和对外接口等数量与复杂度
    SLOC和功能点
    非生产性的支持工作量
    开发工作量(人月)
    进度与里程碑
    进度风险

     

     

    • 定制项目开发计划

      项目开发计划体现了项目组对整个开发周期的预期,指定了项目开发的总体方针。与其他计划一样,项目开发计划不是固定不变的,在执行过程中要对计划进行监控,可能会根据实际情况修改计划并重新发布。

    《项目开发计划》的内容包括: 

    概 

    用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责。

    (《项目开发计划》的概述部分应该是《项目开发大纲》中概述部分的拷贝。当项目计划改变时,修订《项目开发计划》的概述部分而不是修订《项目开发大纲》。这样,以后在进行项目评价时,通过比较《项目开发大纲》和《项目开发计划》的概述,就能看出项目是如何改变的)

    高级功能

    用一到五页的篇幅来概述产品的功能,其中,要包括这些功能的附加信息(开发者需要这样的信息来了解实现需求)。

    项目成员

    确定软件工程职能角色,以及分配到这些角色的人员数量。

    软件过程

    概述这个项目中所应用的软件过程。

    (具体内容可在《质量保证计划》中定义)

    软件工程方法

    概述这个项目中所应用的软件工程方法和技术。

    (具体内容可在《质量保证计划》中定义)

    进度和工作量

    这一部分要表达出整个项目进度和工作量的估计。其中要包括:

    • 对固定不变的里程碑和同步点的解释
    • 在评估中的设想情况、评估中的不准确性的可能来源
    • 随着项目的进展如何更新评估

    (具体进度表内容可在《开发进度表》中定义)

    风险管理计划

    概述这个项目中风险管理计划。

    (具体内容可在《风险管理计划》中定义)

    测 

    概述这个项目中要收集的测量。

    软件工具

    列出要使用的每一项软件工具,以及该工具所支持的任务。

    项目支持

    硬件支持 明确所需的硬件,包括那些需要移动、获取或升级的硬件。

    软件支持 明确所需的软件,包括需要获取、安装或升级的软件件。

    人力支持 由哪个人、部门或团队为开发组的哪项任务提供支持。

     

     

    • 定制风险管理计划

      风险管理任务包括:风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解和风险监控

     《风险管理计划》定义这些任务的执行流程和人员分配。

      《风险管理计划》的内容包括:

     

    概 

    用文字和图表概述风险管理任务的总体执行流程。

    风险识别

    详细说明“风险识别”任务的实施细节和各项工作的负责人。

    风险分析

    详细说明“风险分析”任务的实施细节和各项工作的负责人。

    确定风险优先级

    详细说明“确定风险优先级”任务的实施细节和各项工作的负责人。

    定制风险化解方案

    详细说明“定制风险处理方案”任务的实施细节和各项工作的负责人。

    风险化解

    当风险发生时,需要采取相应的措施化解风险。

    这部分的内容是描述风险化解工作的操作规范和流程。

    风险监控

    详细说明风险监控任务的实施细节和各项工作的负责人。

     

     

     

      风险管理中通常会用到《Top N 风险列表》,风险列表按照风险暴露量排序列出当前项目中主要的N个风险,《Top N 风险列表》的内容包括:

     

    本周排名

    本周的排名(如果本周已被完全化解用“---”表示)

    上周排名

    上周排名(如果是新识别的风险用“---”表示)

    上表周数

    该风险已上表的周数

    风 

    风险的名称或简述

    类 

    风险类型(只针对进度相关的风险):

    • 计划编制
    • 组织和管理
    • 设计和实现
    • 客户和需求
    • 承包商
    • 产品
    • 人员
    • 过程
    • 技术
    • 外部环境
    • 开发环境

    发生概率

    风险发生的百分比概率

    损失程度

    风险发生时损失的进度(工作日或工作周)

    暴露量

    发生概率 X 损失程度

    状 

    风险的当前状态:未发生、已发生、已化解

    化解方案

    简述风险的化解方案,如果有具体的化解方案文档则链接到相应文档

    化解进度

    对已发生的风险,简述化解进度(未发生的风险用“---”表示) 

     

    • 定制质量保证计划 

      保证工作质量的一个重要步骤是制定一套合理的质量保证计划并贯彻执行。

      《质量保证计划》的内容包括:

    概 

    说明编写的目的、适用范围以及对相关人员的要求等

    软件过程

    详细说明这个项目中所应用的软件过程。

    软件工程方法

    详细说明这个项目中所应用的软件工程方法和技术。

    工作规范

    对工程方法中的各种工作任务进行规范,明确执行的时机、流程和准则等。这些工作任务包括:

     

    常规开发活动

    (需求分析、架构设计、详细设计、编码和测试、发布和实施等)

    会议

    (工作例会、进度会议、审查会议等)

    评审

    (方案评审、技术评审、质量评审等)

    测量

    (产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等)

    其他活动

    (技能培训、资料收集、内部流、客户沟通等)

     

     

    • 定制开发进度计划

      基于当前对项目的规模和工作量评估,定制初步的开发进度表,作为项目开发计划的组成部分。

      《开发进度表》的内容包括:

    项目的开始和结束时间
    项目各个阶段的开始和结束时间
    每个阶段的工作任务及其开始和结束时间
    每个工作任务的子任务的及其开始和结束时间
    里程碑和同步点
    角色的定义和任务分配

     

       作为跟踪项目进度的重要依据,进度表在项目推进过程中需要不断细化。另外,当实际进度与计划进度出现偏差时,需要修改进度表并重新发布。

     

     

     

    3.执行阶段

      这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源,如:人员、设备、费用、技术、信息,由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度,定期向全体项目人员及项目的发起人报告项目状态。

    • 需求分析

      分析产品的关键需求、对架构设计有影响的需求和风险较高的需求,直到分析的程度能开展足界面原型设计和架构设计工作。

      《需求规格说明书》的内容包括:

     

    商业或业务需求

    从商业或业务角度宏观上对产品或系统的要求。它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。

    1. 做什么
    2. 做的范围
    3. 对结果的要求

    使用者需求

    从客户对软件产品或系统使用方案的角度出发,描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。

    功能需求

    根据上述使用者需求列出的使用方案,列出开发者必须为软件产品或系统实现的功能。

    性能需求

    1. 运行速度、容量、并发性能
    2. 对资源的利用率
    3. 对外界输入的反馈速度和准确性
    4. 对差错的负荷能力

    系统需求

    • 必须适应的运行环境的要求

    (包括运行平台、网络及其他硬件要求)

    • 与其他系统兼容的要求

    (包括与操作系统、数据库、浏览器及其他应用软件的兼容要求)

    • 与外部其他系统和组件的接口要求

    质量需求

    • 对用户重要的质量标志

    (可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性)

    • 对开发者重要的质量标志

    (可维护性、多用转换性、重复使用性、可测试性)

    其他需求

    不属于上述需求范围的,但受到其他环境和商业合同影响的要求。

    1. 国家或地区的任何特别的标准
    2. 软件使用界面的特别要求
    3. 与知识产权有关的要求
    4. 软件所面对的市场和行业的规范
    5. 客户的特别要求

    开发的局限

    对开发的成功与否起很大影响的因素,是开发能力的局限:

    1. 人员的局限
    2. 技术的制约和局限
    3. 客户的特别要求

    《需求分析报告》的编制方式可以是多样的,例如把所有“非功能性需求”组织成“外部接口需求”、“质量属性需求”和“需求约束”。

    • 界面原型设计

      明确了系统的关键需求后,就可以进行界面原型设计工作,获取用户的反馈,尽快确定产品的界面基调。同时要编写一份《界面设计概要》文档,作为后续的界面设计工作的指导。

      《界面设计概要》的内容包括:

    • 设计的理念
    • 理念的来源或参考
    • 设计的要点
    • 与类似产品界面的对比

     

    • 架构设计

      架构设计从关键需求开始,建立概念性的架构,并逐步细化和验证。最终生成架构设计说明书和架构基线代码。

      架构设计的方法:可以从几个不同的视角进行架构设计,然后汇总综合得出完整的设计。

    《架构设计说明书》的内容包括:

     

    概 

    说明编写的目的、适用范围以及设计原则等。

    逻辑架构

    关注功能。其设计着重考虑功能需求。

    1. 细化功能单元
    2. 发现通用机制
    3. 细化领域模型
    4. 确定子系统接口和交互机制

    开发架构

    关注程序包。其设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性和易测试性等。

    1. 确定要开发或直接利用的程序包之间的依赖关系
    2. 确定采用的技术、框架等

    数据架构

    关注持久化数据的存储方案。其设计着重考虑“数据需求”。

    1. 持久化数据存储方案
    2. 数据传递、数据复制、数据同步等策略

    运行架构

    关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性,例如性能、可伸缩性、持续可用性和安全性等。

    1. 确定引入哪些进程与线程
    2. 确定主动对象、被动对象,以及控制关系
    3. 处理进程线程的创建、销毁、通信机制、资源争用等
    4. 协议设计

    物理架构

    关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。

    1. 确定物理配置方案
    2. 确定如何将目标程序映射到物理节点

    总 

    基于上述的设计进行总结,并描述架构基线。

     

     架构设计的另一个重要任务是编写架构基线代码,基线代码表述和验证架构,同时也是指导后续开发的基础代码。架构基线代码的内容包括:

    所有工程项目
    工程目录结构
    软件包结构
    导入所有依赖包
    基础公共代码
    架构框架代码
    架构框架示例代码和测试代码
    数据库框架

    展示了软件架构师的工作和成功的软件架构设计包含的内容:

    软件架构师的工作

    成功的软件架构设计

      软件构建

       软件可以分阶段进行构建,每个阶段可以使用增量的方式开发,用通过若干个Build构建,最后发布阶段性产品成果。

      (注意:在这里 ,名词“阶段”的含义和本文其他地方的含义不一样)

     

    • 阶段计划

      构建阶段计划的内容包括:

    确定本阶段要实现的功能
    列出阶段任务
    计划Build构建数量
    细化《开发进度表》中本阶段的工作内容

     

     

    • Build 构建

       Build构建以增量的方式执行阶段的开发任务,每个Build构建的周期一般不超过两星期,每一次Build构建都会发布为一个内部版本,并提交测试。测试发现的问题留待以后的Build构建解决。

     

    • Build计划

      《Build计划》的内容包括:

    本次Build的版本号
    本次Build的历时
    本次Build的工作任务
      要解决的遗留Bug
      本应由以前的Build实现的,但推迟到本次Build实现的功能
      要实现的新功能
      其他工作任务
    工作任务分配

     

     

    • 需求细化

      根据《Build计划》,细化本次Build要实现的需求,细化到能进行详细设计为止。有了细化的需求后就编写本次Build的测试计划。

      《测试计划》的内容包括:

    • 功能测试
      要测试的功能
      测试时间
      测试方式
      验收标准

       

    • 其他测试(性能测试、边界测试、使用界面测试、可用性测试、安全性测试等)
      要测试的内容
      测试时间
      测试方式
      验收标准

       

    • 。。。。。。

     

    • 界面设计

      根据细化的需求设计用户界面,当界面确定后即可编写测试用例。

      《测试用例》的内容包括:

    测试用例对应的功能模块
    测试用例的性质(功能测试用例、性能测试用例、。。。。。。)
    输入(或操作步骤)
    期望输出
    实际输出(执行测试后再填写)
    是否通过(执行测试后再填写)

     

     

    • 详细设计

      详细实际每项需求的实现方法,对于重要的设计决策、算法、公共模块和外部接口等必须以模块设计文档的形式进行记录。《模块设计文档》的内容包括:

    模块名称
    设计思想
    设计图表(类图、流程图等)
    要点描述(包、接口、类、方法、算法、设计模式)
    测试方式

     

     

    • 编码、单元测试

      编码和单元测试是开发人员的工作,对于重要的代码都必须进行单元测试,编写代码必须遵守下列准则:

    遵守编码规范
    编码前必须充分理解相关的需求
    编码前先进行设计,把流程理顺
    注意设计方法和设计模式的灵活运用
    总体考虑问题,使代码遵从架构并容易测试
    设计时要充分考虑异常情况和临界条件
    严禁Copy-Paste,注意提取公共代码,在编码过程中实现重构
    异常处理必须记录日志,严禁草率地直接打印异常信息
    灵活运用ASSERT() / VERIFY()等断言来帮助调试程序
    单元测试是程序员的工作,所以编码完成后必须对代码严格测试
    功能代码完成后必须先做以下4件事情:
      编译代码,保证编译通过
      (不运行程序)对代码进行全面检查
      用调试模式启动程序,一行一行单步执行代码,并注意调试输出
      改变条件,让代码尽可能走遍所有程序分支
    Check In代码前必须保证能编译通过

     

     

    •  创建Build

      代码集成发布前需冻结代码,所有人把要提交的代码Check In,并保证编译后的程序能在测试服务器上正常启动,界面能正常打开。同时还要提交Build清单。

      《Build清单》的内容包括:

    Build版本号和日期
    改正的Bug
    修改的功能
    实现的新功能
    其他说明

     

     

    • 集成测试

      按照《测试计划》针对《Build清单》执行《测试用例》,测试完成后编写测试报告。

      《测试报告》的内容包括:

    测试用例汇总(用例数量、通过的用例数量、未通过的用例数量等)
    Bug汇总(Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等)
    测试计划执行情况
    测试总结

     

     

     

    • 阶段产品发布

      构建阶段完成后发布阶段产品成果,向用户展示并接受用户反馈,同时做好阶段总结。

      《发布清单》的内容包括:

    产品版本号和日期
    改正的Bug
    修改的功能
    实现的新功能
    其他说明

     

      《阶段总结报告》的内容包括:

    阶段任务的完成情况
    进度计划的执行情况
    用户的反馈情况
    本阶段碰到的主要问题
    下一阶段的改进建议

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    4.控制阶段

      这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核,与项目计划所期望的结果进行比较,找出实际结果与计划的差别,并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题,如:对缺乏的资源的补偿调节;对项目的进度表及各项具体工作的优先级或顺序的修订。

    • 风险管理

      开发期间要对风险进行监控,定期检查、更新和发布《风险列表》。

     

    • 质量管理

      1)  评审

      评审是质量保证的重要环节,原则上每个重要的工作任务或阶段结束前都必须经过评审,如:方案评审、计划评审、需求评审、设计评审和代码评审等,工作是否被通过、是否需要修改或重做均由评审结果决定,评审结果以《评审报告》的形式发布。

      《评审报告》的内容包括:

     

    基本信息

    评审主题、时间、提交者、评审者等

    评审内容

    评审内容的列表和简述

    问答记录

    评审过程中重要的问答记录

    评审结论

    整个评审的结果,如:

    1. 完全通过,无需修改
    2. 基本通过,需要作小量修改,但不必再评审
    3. 大体通过,需要作一些修改,之后再评审
    4. 不通过,需要作大幅修改,之后必须重新评审

    评审意见

    针对评审结论提出的意见和建议

     

     

     2)  测试

      测试是对被构建产品最直接有效的质量保证措施,测试结束后需要提交《测试报告》。

     

    • 变更管理

      开发过程中经常会出现多种变更,如:需求变更、设计变更或人员变更等。这些变更通常会对开发进度造成影响,因此要对变更及其处理过程进行跟踪,最后报告变更的处理结果。

      《变更处理报告》的内容包括:

     

    基本信息

    变更主题、发生时间等

    详细信息

    变更的详细描述

    变更处理

    变更的处理方式和步骤

    处理结果

    变更的处理结果

    变更影响

    变更对项目造成的影响

     

    • 进度监控

      项目进度会议是了解项目实际进度的有效措施,在会议中评审工作报告,解决遇到的问题并计划下一步工作:

      《工作报告》的内容包括:

    基本信息:  报告者、汇报时间、工作时间段等
    工作情况:  已完成的工作、未完成的工作
    遇到的问题:工作中碰到的阻碍
    工作计划:  下一步的工作计划

     

     

      项目进度会议的另一个重要议题是审查进度表,了解项目实际进度与计划进度的差异。为进度表调整和资源调配提供重要依据。

     

    • 测量

      在项目开发过程中,收集一些关键的测量,对了解项目状态和进行项目决策很有帮助,同时也为以后的项目提供历史数据参考。每个测量都要生成测量报告并存档。

      《测量报告》的内容包括:

    基本信息,包括测量主题、测量时间、测量者等
    测量内容和测量值
    测量分析

     

     

     

     

    5.结束阶段

      这个阶段的工作是确保项目的最终结果或提交物达到计划的要求,并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作,对整个项目的经历进行总结,修订项目文档,用户培训等。

    • 产品测试

      因为产品即将验收和发布,所以必须对产品进行完整测试,产品测试比其他测试要求更严格,当产品的质量达到发布的要求后才能发布。产品的质量由《测试报告》体现。

     

    • RC版本发布

      发布RC版本让用户体验并收集反馈意见,为产品验收作准备。RC版本发布后,产品不应该有大改动,一般只是界面的局部调整。

     

    • 编制用户文档

      针对不同的使用者角色,编制相应的用户文档,对管理者用户需要提供《安装、维护指南》,对普通用户需要编制《产品使用手册》。

      《安装、维护指南》的内容包括:

    产品各组件的说明
    产品部署架构
    安装、配置和卸载等步骤
    启动、停止和重启等操作
    其它操作:日志、备份、还原等

     

     

      《产品使用手册》的内容包括:

    产品介绍
    各个功能的介绍
    通过实际案例介绍各个功能的使用方式和操作步骤

     

     

    • 产品使用培训

      对于为特定客户开发的软件产品,在发布前需要对用户进行产品的使用培训。培训前需要部署好操作环境,编写培训资料,然后组织培训会议。

     

    • 产品验收

      对于为特定客户开发的软件产品,通常根据签订的开发合同和产品方案等条款逐项验收,验收时,用户通常会执行验收测试案例。

     

    • 最后修订

      在产品验收通过后,正式发布前对产品作最后的修订,可能包括:

    开发文档修订
    用户文档修订
    代码整理

     

     

    • 正式版发布

      正式版的发布标志着开发阶段的结束,产品从此时起进入维护阶段,正式发布前可能要做一些准备工作,如:数据迁移和环境配置等。

          

    • 项目总结

      项目结束后需要对整个项目开发阶段的工作进行总结,交流心得,吸取经验和教训,并归档为《项目总结报告》。

      《项目总结报告》的内容包括:

    总体评价
    成本、收益汇总
    重要心得
    管理总结
    技术总结

     

     

    6,总结

      软件项目开发经历多个阶段,每个阶段包含多个任务,每个任务会产生相应的工件。需要相应的质量保证措施对任务进行监控,保证任务的执行。任务完成后也需要对任务进行评审,保证任务的质量。

      这些工作均由开发团队和相关人员按照工作流程执行。因此,合理的角色任务分配和沟通制度是软件项目成功的重要保障。

     

     列出几种比较普遍的角色和任务划分方案:

    职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因,一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分,这样团队中的每个成员才可能有清晰的责任和目标。

      软件开发不管采用哪种生命周期模型和开发方法论,整个过程都会包含需求,设计,开发,测试,配置管理等各项活动。而这些活动会对应到项目中的不同角色,项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。

     

      方案一 项目负责人总览全局

      对于小作坊的软件开发团队,可以由一个项目负责人总览全局。项目负责人承担从用户需求->软件需求->总体设计的所有工作。同时还需要做到整个团队进度规划,质量保证,配置管理和沟通协调等相关工作。所以小型项目团队对项目负责人的业务,技术和沟通管理等技能都要求较高,项目负责人是项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。

      我们这里指的小型团队并不是只一个人单打独斗的项目,所以项目负责人最好不要介入到模块设计和编码活动中,而是应该把重点放在进度的控制和质量的保证上面。由于项目负责人一般有较强的技术能力,所以项目负责人可以承担项目中要使用的一些新技术的研究,项目中一些疑难问题的解决等相关工作。项目负责人还应该有计划的设计开发人员的代码进行Review,对发现的规范性,性能,复用差等问题跟项目成员确认,并写入到项目开发规范中。

     

      方案二 项目负责人和开发负责人分离

      在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同来确认项目的总体方案和架构。项目负责人的重点在项目管理和与客户交流沟通上,只有确认清楚第一手的用户需求,才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚就开工,项目成员完全凭借着自己的感觉在做系统,过程中又不注意与用户及时反馈和迭代,导致开发出完全不能使用的系统;开发负责人的重点是对整个开发过程负责,包括对项目经理确认的进度目标进行任务的进一步分解,安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理,架构的核心移动到了开发负责人,而项目经理仅仅是参与讨论和评审。而单独剥离出开发负责人后,可以更好的对开发过程进行跟踪和协调,开发负责人重点放在项目内部,而避免过多去和外部干系人沟通和协调。

     

      方案三 测试的专职化

      对于项目团队发展到5-10的时候,项目中的测试工作必须专职化的由测试人员来完成。一般测试人员的配置比例为4-6个开发人员需要配置一名专职化的测试人员。测试人员站在第三方和模拟使用者角度来进行系统的测试,可以更好的发现系统的BUG和相关问题,有效的保证系统的质量。

      方案三中项目经理工作进一步清晰,项目经理不在承担软件需求和架构的相关工作。而重点放在项目内外的沟通协调和整个项目进度计划的安排上。这个时候项目中的设计负责人对整个系统的总体设计方案和架构负责,而且设计负责人也将不在参与具体的功能模块的设计和开发工作。设计负责人的重点转化到的软件需求的开发和总体设计上面(如涉及到RUP中的用例建模,用例分析,架构设计,组件接口复用)。

     

      方案四 项目经理和需求角色分离

      当项目团队的规模发展到12-20人的时候,项目团队基本上可以算做中小型的项目团队。这个时候项目经理完全专职化做项目管理的工作。包括项目进度计划制定,项目跟踪监控,风险分析和控制,项目度量分析和决策等相关内容。对于需求活动设置专门的需求工程师岗位来完成需求的开发。同时项目中设置专门的架构设计人员,架构设计人员不再负责需求的开发工作,而重点在于系统总体设计方案的确定,系统的4+1视图的分析,同时架构人员要考虑整个系统的集成方案的确定和具体功能单元和模块的集成。

      由于项目规模的扩大,项目的配置项更加复杂,项目也需要同时起开发,测试,集成和BugFix等多个分支。因此需要设置专门的配置管理员来进行项目的配置管理。

      对于项目同时需要开发新版本,又需要对已经发布的维护版本进行功能改进的时候,项目中要考虑设置专门的维护人员。由维护人员来完成项目小功能的改进和BUG的修复。这样新版本设计开发人员可以更专注的进行新功能的开发。

     

     

     

     

     

     

     

    阶段完成标志

      在项目开发过程中,当一个阶段完成后才会开展下一个阶段的工作;另外,“某个阶段完成”通常被定义为项目的一个里程碑,里程碑标识了项目的进度,它是项目开发和控制的重要参考,对整个项目有重要的意义。因此,“确证某个阶段是否已经完成”的工作非常有重要。

     

    • 每一个阶段的结束以它特定任务的完成为象征

      只有当某个阶段中被规定的所有工作任务都完成了,这个阶段才算真正结束,整个项目才可以进入到下一个阶段中去。反过来说,要是阶段中某个任务没有全部完成,按照项目的定义,整个阶段就不能算是完成,因此项目就不能进入到下一个阶段去。

    • 衡量阶段结束的工作结果必须是实在的交付品

      阶段中的任务是否完成是透过任务活动中产生的交付品来体现的,交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如:某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束,都应该有这样的实质性东西的完成作为象征。

    • 跨阶段的进程以阶段结尾的合格验证和审核来决定

      当一个阶段结束时,在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证,并检查这一阶段的工作质量和效率,由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点,表示项目的进程离开了上一个阶段而进入了下一个阶段。

     

     

     

     

     

         1 相关系统分析员和用户初步了解需求,然后用WORD列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。 
      2 系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还例出相关的界面和界面功能。 
      3 系统分析员和用户再次确认需求。 
      4 系统分析员根据确认的需求文档所例用的界面和功能需求,用迭代的方式对每个界面或功能做系统的概要设计。 
      5 系统分析员把写好的概要设计文档给程序员,程序员根据所例出的功能一个一个的编写。 
      6 测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能,然后验收。 


      举个例子来看: 
      1 某公司想找人订做一套人事管理软件,从某种渠道上得知我们有提供这种服务,所以联系上了我们。 \
      2 我们会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给他们用,然后回来做个方案给他们,其中方案的内容包括:我们开发出来的软件大概的界面是怎样?方便什么人使用?什么人可以使用什么功能?方便到什么程度?大概的硬件要求是怎样等? 
      3 他们看了方案后,确定他们就是要做一套这样的软件,我就开始开发这套软件。 
      4 我们把开发出来的软件交用他们使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,我们会第第一时间修改这些功能,直到他们要求的所有功能都能很完美的解决掉。









     

    转载于:https://www.cnblogs.com/hwaggLee/p/4483720.html

    展开全文
  • 软件项目组织架构安排

    万次阅读 2019-04-06 19:45:58
    这个主题涉及到三个方面,项目计划管理、组织管理和技术管理范畴。 项目计划管理是项目管理中的一个大... 从软件企业整体的组织架构来说,不外乎包括项目型、职能型、矩阵型几类。当然其中有偏项目型的组织结构,...
  • 软件公司软件项目投标书模板

    热门讨论 2011-08-19 17:18:19
    软件项目投标书模板软件项目投标书模板软件项目投标书模板软件项目投标书模板软件项目投标书模板
  • 软件项目管理案例教程 第4版 课后习题答案

    万次阅读 多人点赞 2019-11-30 01:18:05
    软件项目管理案例教程 第4版 课后习题答案 第一章 一、填空题 1.敏捷模型包括(4)个核心价值,对应(12)个敏捷原则。 2.项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾...
  • 软件项目风险管理

    千次阅读 2020-02-10 11:42:37
    本文通过文献综述总结了软件项目中的常见风险因素及其分类。 从上个世纪发展到现在,软件早已从解决特殊问题的途径和信息数据分析的工具演化成一门独立的产业,但在提供客户所需要的软件的能力方面取得的进展却十分...
  • 软件项目管理电子书合集

    热门讨论 2011-07-07 10:34:09
    集合了网上经典的软件项目管理电子书,书目全面,方便大家下载阅读使用
  • 3、项目立项之后,项目负责人会进行(自造-购买)决策,确定待开发产品的哪些部分应该采购、外包开发、自主研发等。 4、PMI人才三角重点关注(技术项目管理)、(领导力)、(战略和商务管理)3个关键技能。 5、在...
  • 软件项目的全生命周期

    万次阅读 多人点赞 2018-10-12 16:52:05
    就职于软件行业的人,无论是销售、售前、技术还是财务一定都会接触到关于项目运作相关的工作,不同职位的员工对于项目的关注点也大不相同,财务人员关注项目的收款节点;销售人员关注项目的商务关系及前期引导;实施...
  • 软件项目实施计划

    万次阅读 2018-12-21 09:23:57
    一、 软件项目类型介绍 1、 真正意义上的项目(从无到有) 此类项目属于客户定制型开发,实施周期相对较长 流程如下: 2、 复制型项目(软件复用) 此类项目相对小点,对现有产品进行对应修改,实施周期较...
  • 关于软件项目管理的一些问题

    千次阅读 2020-06-06 20:54:21
    1. 项目管理计划书的制作过程 确定项目范围 可交付成果,wbs 项目资源 项目进度计划 角色、责任、项目组织结构 成本和预算 风险 2. 怎么确定项目范围 把客户的需求转变为对项目产品的定义 通过wbs,把项目...
  • 软件项目管理考前复习资料

    万次阅读 多人点赞 2018-12-12 16:53:27
    软件项目管理概述 1.实现项目目标的制约因素有: 项目范围 成本 进度计划 客户满意度 2.项目管理包括: 启动过程组 计划过程组 执行过程组 控制过程组 收尾过程组 3.什么是项目: 为了创造一个唯一的产品或者...
  • 华为公司软件项目管理全过程文档模板

    千次下载 热门讨论 2011-10-24 22:00:08
    华为公司软件项目管理全过程文档模板华为公司软件项目管理全过程文档模板华为公司软件项目管理全过程文档模板华为公司软件项目管理全过程文档模板华为公司软件项目管理全过程文档模板华为公司软件项目管理全过程文档...
  • 软件项目管理案例复习题

    万次阅读 多人点赞 2020-03-27 09:36:51
    项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾过程 5个过程组。 、搬家属于项目。(√) 、项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。(×...
  • 第三章 软件项目范围管理

    万次阅读 多人点赞 2018-06-01 17:49:48
    项目范围对项目的影响是决定性的,它确定了软件项目工作内容的多少。有效的范围管理可以保证项目只做必须做的事情,避免范围蔓延和做无用功,同时也避免不清晰的需求所导致的严重的系统缺陷。 本章内容提要n3.1 ...
  • 软件项目管理(学习笔记)

    千次阅读 多人点赞 2020-05-04 14:26:42
    1.项目项目管理 项目    1.项目项目是一次性的、以目标为导向的(目标明确)、通过项目经理及其团队工作完成的、存在大量的变更管理。     2.项目的特点: 有明确的目标性 明确...
  • 软件项目管理进度表(excel)

    千次下载 热门讨论 2011-08-24 13:55:27
    XL-EasyGantt V3 Gold-2 -r1.xls软件项目管理进度表(excel)国外很出名的一个excel表格相当强大
  • 第二章 软件项目立项与规划

    万次阅读 2018-05-18 18:09:08
    第一节 发现项目机会§客户的需求和问题就是选择项目的依据,是项目投资机会。§通常投资者是从以下几个方面发现项目投资机会:1.市场需求。进行市场分析,客观地分析市场现状(市场容量的大小,供求情况),预测...
  • IT软件项目开发总结报告

    热门讨论 2011-06-05 17:33:34
    a. 本项目的名称和所开发出来的软件系统的名称; b. 此软件的任务提出者、开发者、用户及安装此软件的计算中心。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料
  • 软件项目总结模板

    千次阅读 2019-09-29 14:17:46
    实际工作中,整理了软件项目的总结关注点: 1、交付: 完成了哪些交付成果? 哪些工作没完成?原因是什么? 2、进度: 实际进度和计划进度发生了哪些变化? 应用了哪些进度控制方法? 3、成本: 实际成本与...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,592,518
精华内容 637,007
关键字:

软件项目

友情链接: tijiaoshuju.zip