喵喵博客

第一章 软件可以复制无数份，而每个系统都是独一无二的。 IEEE1998把软件需求分成： 1、功能需求（业务需求，用户需求，系统需求） 2、性能需求（响应速度，精度，容量，负载，系统吞吐量，运行时资源消耗） 3、质量属性（灵活性，高效性，可靠性，可维护性，健壮性，可用性） 4、对外接口（软件接口，硬件接口，数据库接口） 5、约束 （编程语言，硬件设备，软件环境，条件、假定） 常用的需求调研方式包括： 观察法 体验法 问卷调查法 访谈法 单据分析法 报表分析法 需求调研会法 一、选择题 1、需求分析最终结果是产生（ B ）。 A. 可行性分析报告 B. 需求规格说明书 C. 项目开发计划 D. 设计说明书 2、需求规格说明书的内容不应包括（ B ） A. 主要功能 B. 算法的详细过程 C. 用户界面和运行环境 D. 软件性能 3、需求规格说明书的作用不包括（ D ） A. 软件设计依据 B. 开发人员与用户对软件要做什么的共同理解 C. 软件验收依据 D. 软件可行性研究的依据 4、下面不属于需求分析师工作职责的是（ D ）。 A. ...

第一章 引论 采用先进的开发方式和较完善的开发流程，可以减少错误的引入，但不可能完全杜绝软件中的错误。 软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早地发现错误并及时地修正。 为什么要进行软件测试？答案很简单，就是为了保证软件质量。 软件测试，就好比制造工厂的质量检验，是对软件产品和阶段性工作成果进行质量检验，力求发现其中的各种缺陷，并督促缺陷得到修正，从而控制软件产品的质量。 Bill Hetzel在1983年，软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性能力，并确定其是否达到了预期结果。 Glenford J. Myers在1979 测试是为了发现错误而执行一个程序或者系统的过程。 Glenford J. Myers的软件测试定义，虽然受到业界的普遍认同，但也存在一些问题，例如： 如果只强调测试的目的是寻找错误，就可能使测试人员容易忽视软件产品的某些基本需求或客户的实际需求，测试活动可能会存在一定的随意性和盲目性。 如果只强调测试的目的是寻找错误，使开发人员容易产生一个错误的印象，认为测试人员的工作就是挑毛 ...

判断题 [ ] 一个软件配置项可能有多个标识。 [ ] 基线提供了软件开发阶段的一个特定点。 [x] 有效的项目管理能够控制变化，以最有效的手段应对变化，不断命中移动的目标。 [x] 一个（些）配置项形成并通过审核，即形成基线。 [ ] 软件配置项是项目需定义其受控于软件配置管理的款项，每个项目的配置项是相同的。 [ ] 基线的修改不需要每次都按照正式的程序执行。 [ ] 基线产品是不能修改的。 [ ] 基线修改应受到控制，但不一定要经SCCB授权。 [x] 变更控制系统包括从项目变更申请、变更评估、变更审批到变更实施的文档化流程。 [ ] 在软件项目配置管理中最终应保证软件产品的完整性、一致性、有效性、机密性。 [x] 项目干系人是项目计划的一部分。 [ ] 项目型的优点是可以资源共享。 [ ] 应尽量多建立一些沟通渠道。 [x] 项目沟通的基本原则是及时性、准确性、完整性和可理解性 [x] 在IT项目中，成功的最大威胁是沟通的失败 [x] 责任 ...

软件项目管理（1-8章课后题） 判断题 [x] 搬家属于项目。 [ ] 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。 [x] 过程管理目的是要让过程能够被共享、复用，并得到持续的改进。 [x] 项目具有临时性的特征。 [ ] 日常运作存在大量的变更管理，而项目基本保持连贯性的。 [ ] 项目开发过程中可以无限制地使用资源。 [ ] 项目招标对于一个项目的开发是必需的，即便项目是内部项目。 [x] 自主开发相当于make or buy决策中的make。 [ ] 项目建议书是项目计划阶段开发的文档。 [ ] 项目立项需要获得项目经理的认可，但不需要项目发起人的认可。 [ ] 项目章程是项目执行组织高层批准的确认项目存在的文件，其中不包括对项目经理的授权。 [x] 乙方即供方（有时也称卖方）是为顾客提供产品或服务的一方。 [x] 在软件项目合同中，甲方是需求放，乙方是供方。 [ ] 项目初始阶段甲方为软件开发方，乙方为顾客。 [ ] ...

第一章 一.填空题 敏捷模型包括（4）个核心价值，对应（12）个敏捷原则。 项目管理包括（启动过程组）.（计划过程组）.（执行过程组）.（控制过程组）.（收尾过程组）5个过程组。 二.判断题 搬家属于项目。（√） 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的永久性的努力。（×） 过程管理就是对过程进行管理，目的是要让过程能够被共享.复用，并得到持续的改进。（√） 项目具有临时性的特征。（√） 日常运作存在大量的变更管理，而项目基本保持连贯性的。（×） 项目开发过程中可以无限制地使用资源。（×） 相比传统开发的预测性过程，敏捷开发属于自适应过程（√） 三.选择题 下列选项中不是项目与日常运作的区别的是（C） A. 项目是以目标为导向的，日常运作是通过效率和有效性体现的。 B. 项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理。 C. 项目需要有专业知识的人来完成，而日常运作的完成无需特定专业知识。 D. 项目是一次性的，日常运作是重复性的。 以下都是日常运作和项目的共同之处，除了（D） A. 由人来做 B. 受限于有限的资源 C. 需 ...

项目核心计划执行控制 软件项目范围管理-传统和敏捷 范围管理 范围执行控制是监督项目和产品的范围状态 管理范围基准变更的过程 目的:产生满意的交付成果 传统针对于wbs 分析技术 偏差分析 将范围基准和实际的结果进行比较来确定偏差是否在临界值之内,或者需要采取必要的纠正措施 趋势分析 趋势偏差随时间变化的情况,来判断范围管理是在改善还是正在恶化 范围控制要点 防止不合理的范围扩张 蔓延 镀金 敏捷项目:需求不断被定义 把需求列入未完成项 不断的构建和评审原型系统 通过发布多个版本来明确需求 成本控制管理-图解控制法 是一种偏差分析,利用时间图,进度图,成本图,资源图对项目的性能偏差进行分析,审查目标绩效和实际绩效之间的差异. 甘特图 延迟图,越弯曲,偏差越大 时间线 费用曲线图 资源图偏差 偏差分析与控制 精确记录任务消耗的实际时间 量化任务的计划偏差 持续时间偏差(%)=({实际持续时间-计划持续时间}/{计划持续时间})*100 进度偏差(%)=({实际结束时间-计划结束时间}/{计划持续时间})*100 对计划偏差 ...

项目集成计划执行控制 项目集成计划 项目的进度目标和成本目标关系是最近的 工期与质量也有关系 项目管理重要的四个要素 范围(S) 质量(Q) 进度(T) 成本© C=F(S,Q,T)C=F(S,Q,T)C=F(S,Q,T) C与S正比 C与Q正比 C与T反比 项目集成计划管理 对项目每个专项项目进行层层协调,满足项目相关人员的利益要求和期望 基本步骤 建立标准 采集项目实际数据 实际结果与计划比较 决定是否修正计划 修正计划协调各方 敏捷项目集成管理 敏捷方法能促进团队成员以及相关领域专家的身份参与整合管理 项目经理的关注点在于营造一个合作型的决策氛围 对具体产品的规划和交付授权交给团队来控制 确保团队有能力应对变更 变更过程可视为一个敏捷项目

软件项目合同计划 项目合同类型 项目采购 为了执行项目而从项目团队外部获取产品,服务或者结果的过程称为采购 合同 合同是具有法律效力的协议 双方自愿达成的协议 签订这具有相应的法律能力 有充分的签约理由 具有合法的目的 合同类型 成本补偿合同 向卖方支付为完成工作而发生的全部合法实际成本,外加一笔费用作为卖方的利润 适用于工作范围预计会在合同执行期间发生重大变更 类型 成本加固定费用 成本加激励费用 成本加奖励费用 总价合同 总价合同为既定产品,服务或者成果的采购设定一个总价 这种合同应该在已明确定义需求,且不会出现重大范围变更的情况下使用 类型 固定总价(最常用) 固定价格加奖励费 总价加经济价格调整 工料合同(上两种综合) 客户必须为每一个单位的工作量付出一定的报酬 是成本补偿合同和总价合同的特点混合型合同 例如 工程师单价130美元/工时 产品单价1500元/功能点 项目合同计划 合同计划 明确合同如何进行委托,委托什么项目,何时进行,费用如何等 选择需要的合同类型,采用的招标方式,合同形式等 输出形式 ...

软件项目风险计划 风险管理过程 风险定义 风险是对潜在的，未来可能发生损害的一种度量，如果风险确实发生了，则会对项目产生有害的或者负面的影响 软件风险对软件开发过程及软件产品本身可能造成的伤害或损失 风险类型 预测角度 已知风险 可预测风险 过去项目经验 不可预测风险 范围角度 商业风险 管理风险 人员风险 技术风险 开发环境风险 客户风险 过程风险 产品规模风险 风险三要素 风险事件 事件概率 事件影响 风险管理的四个过程 下节 风险管理计划 风险识别 识别事件系统化确定对项目计划的威胁，识别已知和可预测的风险 德尔菲方法 选择相关的领域专家，与专家建立直接的函询联系，整理后再匿名返回给各位专家，连续三五次，到所有专家意见趋向一致 头脑风暴法 专家小组内通过专家会议，激发专家创造性思维，获取相应的分析 情景分析法 类似于撰写电影剧本，对变化进行情景或画面的描述 利用风险条目检查表 最常用 根据条目的回复检查风险 风险评估 对风险事件发生概率的评估，对项目风险形象的评估，给出项目风险的排序 分析 风险发生的概 ...

软件项目团队计划 团队计划 人员职责计划 项目组织结构主要类型 职能型 以部门为主体承担项目 可以一个部门承担多个，也可多个部门承担一个 适合于由一个部门完成的项目或技术比较成熟的项目 优点：充分发挥职能部门的资源集中优势，便于相互交流，相互支援 缺点：项目和部门利益发生冲突的时候会丢失项目目标，资源平衡也会出现问题 项目型 单目标垂直的组织方式 一个项目一个项目组，项目完成后就解散 以项目经理为首 优点：项目经理对项目负全责，以项目为中心 缺点：资源不能共享，对成员缺少连续性和安全感 矩阵形 职能型和项目型混合 从部门中选择合适的项目成员，组成临时的项目组 优点：专职的项目经理 以项目为中心 缺点：容易引起项目经理和职能经历之间的利益冲突，资源共享也会引发冲突 人员职责计划 责任分配矩阵RAM 对项目团队成员进行项目分工，明确角色和职责 组织分解结构OBS 按照组织现有的部门，单元或团队进行排列，并列出工做任务 文本型 干系人计划 干系人是能够影响项目决策，活动或者结果的个人，群体或者组织以及会受到或者自认为会受到项目决策，活 ...