关于软件项目管理的一些问题_软件项目管理涉及的问题-CSDN博客

本文链接：https://blog.csdn.net/coder_xiaobai/article/details/106532845

1. 项目管理计划书的制作过程

确定项目范围

可交付成果，wbs

项目资源

项目进度计划

角色、责任、项目组织结构

成本和预算

风险

2. 怎么确定项目范围

把客户的需求转变为对项目产品的定义

通过wbs，把项目产品的定义转化为对项目工作范围的说明

项目干系人认可并接受项目范围

授权与执行项目工作，并对项目进展进行控制

3. 确认项目范围的依据

环境因素

组织过程资产

项目章程

项目初步范围说明书

4. 工作范围怎么确定，内容范围怎么确定

工作范围：通过wbs对项目所涉及的工作进行分解，所欲哦这些工作构成了项目的整体范围（以可交付成果为分解对象，以结果为导向）

内容范围：在项目定义时确定，生成的详细范围说明书说明了项目可交付成果以及生成这些可交付成果所要求的工作

5. 用什么方法定义工作范围

制定WBS的方法：类比法，由下至上法，由上至下法

6. 工作范围和内容范围有什么不一样

工作范围：wbs

内容范围：可交付成果

7. RUP模型有什么好处

迭代式开发：允许每次迭代过程需求发生变化，通过不断迭代细化对问题的理解。降低了开发风险，提高了开发效率

需求管理：RUP提供了如何获取、组织系统的功能和约束条件并将其文档化的方法

便于复用的软件体系结构：组件时可复用的单位，用组件组成系统可以达到软件复用的目的。RUP展示了如何设计一个灵活的、有很强适应性的、有利于理解和便于复用的软件体系结构

有利于可视化建模：RUP常常和UML联系，有利于建立软件系统的可视化模型。RUP模型提供了对软件系统进行可视化建模的方法

对软件质量进行验证：在RUP中，软件质量的评估不再是事后进行或单独小组进行的分离活动，而是贯穿与软件开发过程中，这样有利于及早发现软件中的不足

8. 为什么RUP初始阶段还有测试实现部分

原型

9. RUP每个阶段的工作以及里程碑

初始阶段：为系统建立商业案例并确定项目的边界；生命周期目标里程碑

细化阶段：分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素；生命周期结构里程碑

构造阶段：所有的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。重点放在管理资源及控制运作以优化成本、进度和质量；初始功能里程碑

交付阶段：确保软件对最终用户是可用的。为发布做准备的产品测试，基于用户反馈的少量调整；产品发布里程碑。

10. 用项目型组织结构的原因

项目经理负责整个项目，人员使用灵活性强

公司建立了适应矩阵式管理的企业文化

公司以项目为单位，多个项目同时进行研发，项目可以分享多个部门的技术人才储备，有利于共享和高效利用公司资源

项目的组织结构灵活，可以快速响应市场的变化和客户的需求项目的组织结构灵活，可以快速响应市场的变化和客户的需求

11. 3.1.1项目管理目标是什么

项目质量管理

12. 总体目标、局部目标是配置管理吗

不是

13. 什么是风险

风险是指不良后果或损失、灾难发生的危险和机会

风险是损失发生的不确定性

风险是在一定条件下、一定期限内，某一事件其预期结果与实际结果之间的变动程度

14. 如何制定WBS

使用指导方针：根据颁布的制定WBS的指导方针、样本、模板制定WBS

类比法：借助类似产品的WBS，用它作为起点，制定新项目的WBS

由上至下法：从项目最大的单位开始，逐步将它们分解成下一级的多个子项

由下至上法：让项目组成员一开始就尽可能地确定项目有关的各项具体任务，然后再将各项具体任务进行整合，并归总到WBS的上一级内容当中

15. 分配资源的依据

工作分解结构、项目进度计划、历史资料、项目范围说明书、项目资源说明、项目组织的管理政策和原则

16. 时间怎么分配合理

专家评估法

（类比估算法）单一时间估算法：借鉴类似活动的活动时间

（历时的三点估算法）三种时间估算法：首先确定乐观时间、最可能时间、悲观时间，然后估算得出的任务时间平均值

17. 每个阶段的工作量是怎么确定的

专家估算法

自上而下：利用历史信息估算

自下而上：为工作包作估算

18. 任务怎么分解（制定WBS的过程）

明确项目的主要可交付成果

确定每个可交付成果的详细程度是否已经达到了足以编制恰当的成本和持续时间的估计

确定可交付成果的组成元素

核实分解的正确性

19. 制定WBS的依据（范围定义的依据）

项目文件：项目章程、项目初步范围说明书、项目范围管理计划、批准的变更请求

搜集的信息：环境因素和组织过程资产信息、IT项目专业领域对项目可交付成果和项目工作的客观要求方面的信息、项目限制条件与假设条件信息

20. 如何制定质量计划

任务：识别哪些质量标准适应本项目，并确定如何满足这些标准的要求

输入：质量方针、范围说明、产品描述、标准和规则

方法和技术：收益/成本分析、检验基准法、流程图

输出：质量管理计划、操作定义、检查表、其他过程输出

21. SQA和V&V的关系

相同点：两者的目标都是监控项目和产品，确保客户得到符合质量标准的产品

不同点：

SQA：是一种内部的方法，主要处理标准的符合问题和产品流的符合问题。SQA并不评估软件本身是否符合技术规范，包括安全、保密和质量属性等，也不评估功能和性能需求。

V&V：关注一个项目产品的技术属性及其开发过程。V&V为评估一个软件是否满足它的技术规范和所期望的使用，提供了详细的工程评价。

如果组织得当，SQA和V&V是可以互补的，几乎没有多少重叠，二者配合可为软件开发工作提供综合的保证程序

22. SQA是什么，工作内容是什么

SQA（软件质量保证）为了使软件开发的流程按照事先定义的规范进行，以保证软件质量活动。

工作内容：评审软件产品、工具与设施；审查软件开发过程；参与管理评审；形成SQA报告；处理相互关系

23. 项目里面哪一部分是V&V的工作

软件测试

验证针对的是需求说明书，检验软件是不是根据需求来设计实现的；确认针对的是用户，检验软件能否满足用户的需求。

24.3.1 工期质量成本这些数据从哪来的

项目章程，项目管理计划：需求管理计划、风险管理计划、相关方参与计划、范围基准，项目文件：假设日志、需求文件、需求跟踪矩阵、风险登记册、相关方登记册；事业环境因素；组织过程资产

25. 风险管理的过程

风险管理规划：决定如何开展项目风险管理活动

风险识别：判断风险对项目的影响，以书面形式记录特点

定性风险分析：对风险进行排序，以便随后进一步分析

定量风险分析：对识别的风险进量化分析

风险应对规划：根据项目目标制定风险应对方案

风险监控：在整个项目周期中，跟踪已识别的风险、监控残余风险、识别新风险和实施应对计划，并对其有效性进行评估

26.需求风险的应对措施

获取完整、准确的需求：

成立由技术人员、业务人员、测试人员等组成的项目组，项目组应吸收既懂技术又懂业务的复合型人才

将用户群分类，选择每类用户的典型代表，采用面对面交谈、到办公地点拜访用户、观察用户工作、将用户工作录像、了解工作组织、自我尝试、让用户在工作时边想边说、让用户参与设计、利用调查和问卷等各种方法和各用户建立起良好的沟通环境和氛围

让用户畅所欲言，罗列出所有的需求，并将用户最原始、最完整的要求准确记录下来

对于用户表达不清的、非常模糊的、笼统的、尺度难以控制的需求，分析人员要善于挖掘、善于诱导、甚至给用户演示一些实际应用系统来启发用户对目标系统的理解和认识，帮助用户表达其正确的需求

帮助用户预测开发过程中可能会发生的变更及今后应用中可能进行修改升级的潜在需求，通过沟通进行需求确诊，这将会大大减少需求的变更

建立系统原型

进行有效的需求变更管理：

建立需求基线，需求基线是需求变更的依据

制定简单、有效的变更控制流程，并形成文档

成立项目变更委员会（CCB）或职能相关的类似组织，负责裁定接受哪些变更

需求的变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认

需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致，记录需求变更

跟踪每项需求的状态

衡量需求稳定性

27.变更委员会是什么构成的

用户方和开发方的决策人员

28.可交付成果会影响哪些内容

项目范围、项目质量控制、项目进度

29.项目可交付物属于哪些知识域

项目范围

30.RUP怎么控制风险

通过迭代：风险推动了迭代计划，迭代是围绕着处理特定风险而计划的，尝试限制风险或减少风险。

RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

定期复审风险列表可评估风险降低策略的效用，这反过来又推动了项目计划的修订及随后迭代计划的修订。

降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

31.RUP初始阶段如何降低风险

关注整个项目进行中的业务和需求方面的主要风险，由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

32.RUP里面的需求风险怎么控制

RUP需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。

33. 3.1.1项目管理目标的依据是什么

公司过往的开发经验

公司实行的质量要求的标准

必须符合的行业和国家的法律法规

34.有哪些风险

项目规模和复杂度，需求，变更影响，组织，进度计划，资金，团队，技术，商业因素，项目管理

35.为什么会产生需求风险

用户不能正确表达自身的需求，业务人员配合力度不够，用户需求的不断变更，需求不完整、有遗漏，需求过简，需求描述多义性，忽略了用户的特点分析，需求的时间没有保障

36.技术风险怎么产生

开发人员技术经验不足

技术创新所需要的相关技术不配套不成熟，相关的设施、设备不完善

对技术创新的市场预测不够

37.细化阶段怎么解决风险,可以解决哪些风险

细化阶段精化系统范围和需求，可以降低需求风险

39.细化阶段主要解决哪些需求

范围、主要功能和诸如性能等非功能需求

40.风险监控怎么做的

依据：项目风险管理计划、项目风险应急计划、项目沟通、其他的风险识别和分析

工具和方法：附加的风险应对计划、核对表、偏差分析技术、定期的项目风险评估

结果：新的项目风险应对措施，变更申请，控制风险活动

41.风险识别一般怎么识别

收集资料

估计项目风险形式

将潜在的风险识别出来

42.风险检查单从哪里来的

经验？

43.用户代表从哪来的，是来自用户吗

公司成员

不是来自用户，用户代表是代表用户的，是用户与公司的沟通纽带，要了解用户需求，然后用公司的优势满足用户的要求。

44.RUP模型怎么解决各种风险

通过迭代

降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。

降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。

加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。

45.RUP模型怎么保证质量

软件质量评估不再是事后型的或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中

45.细化阶段迭代什么

需求——精细化系统范围和需求

分析——确定构造什么

设计——创建稳定的架构

实现——构造架构基线

测试——测试架构基线

46.构造阶段的迭代

需求——揭示任何遗漏的需求

分析——完成分析模型

设计——完成设计模型

实现——构造初始运作功能

测试——测试初始运作功能

47.RUP9大核心工作流（6个过程工作流，3个支持工作流）

商业建模：商业建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

需求：需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

分析和设计：分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

实现：实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

测试：测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

部署：部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

配置和变更管理：配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

项目管理：软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

环境：环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

48. 文档由谁来做

文档	编写人员
《嚣张瘦软件需求规格说明书》	需求人员
《嚣张瘦软件概要设计说明书》	设计人员
《嚣张瘦软件详细设计说明书》	设计人员
《嚣张瘦软件用户手册》	开发人员
嚣张瘦软件系统	开发人员
《嚣张瘦软件集成测试报告》	测试人员
《嚣张瘦软件系统测试报告》	测试人员
《嚣张瘦软件验收报告》
《嚣张瘦软件测试报告》	测试人员
《嚣张瘦软件项目进度管理计划》	项目经理
《嚣张瘦软件项目进度管理报告书》	项目经理
《嚣张瘦软件配置管理计划》	配置管理人员
《嚣张瘦软件状态报告书》	项目经理
《嚣张瘦软件质量保证计划》	SQA 人员
《嚣张瘦软件质量报告》	SQA 人员
《嚣张瘦软件验证与确认计划》	软件验证与确认人员

49. 项目整合管理过程

制定项目章程

制定项目初步范围说明书

制定项目管理计划

指导与管理项目执行

监控项目工作

变更控制

项目收尾

50.软件质量怎么保证

建立SQA小组

选择和确定SQA小组活动，并作为SQA计划的重要输入

制定SQA计划，明确SQA活动与整个软件开发生命周期中各个阶段的关系

执行SQA计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具

不断完善质量保证过程中存在的不足，改进项目的质量保证过程

51.三种组织结构的区别

52.项目范围管理有什么

产生什么样的可交付成果

如何产生这些可交付成果

53. 成本管理过程

成本估算：对完成项目所需成本的估计，是项目计划中的一个重要的、关键的、敏感的部分

成本预算：把估算的总成本分配到项目的各个工作细目，建立成本基准计划以及衡量项目绩效

成本控制：保证各项工作在各自的预算范围内进行

54.成本估算的依据

项目资源需求计划

项目范围说明书

项目进度计划

工作分解结构

风险管理计划

55.质量是如何影响成本的

软件的高质量，会使增加开发时期的成本，但在维护时期的成本会较低

低质量的软件，开发时期的成本较低，但是在维护时期成本交高

56.项目的整合体现在哪

项目计划制定：收集其他计划整合项目计划

项目计划执行：实施项目计划

整体变更控制：调整整个项目的变更

57.风险监控

建立项目风险控制体系

确定项目要控制的风险事件

落实项目风险控制的责任

实施和跟踪项目风险的控制

确定项目风险是否消除

项目风险控制效果的评价

58. 业务模型包括什么内容？

商业用例模型和商业对象模型

组织视图：组织结构的静态模型。包括：层次组织结构的人员(people not human)资源，生产资源(比如，设备，运输等)以及计算机、通信网络结构等。
数据视图：业务信息的静态模型。包括：物理模型图，数据模型，知识结构，信息载体，技术术语和数据库模型等。
功能视图：业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。
控制（业务）视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。