系统架构设计师-开发管理

在初步项目范围说明书中己文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：
①项目章程。②项目范围管理计划。③组织过程资产。④批准的变更申请。

项目范围是为了达到项目目标，为了交付具有某种特制的产品和服务，项目所规定要做的。
在信息系统项目中，产品范围是指信息系统产品或者服务所应该包含的功能，项目范围是指为了能够交付信息系统项目所必须做的工作。产品范围是项目范围的基础。产品的范围定义是信息系统要求的度量。而项目范围的定义是生产项目计划的基础。产品范围描述是项目范围说明书的重要组成部分。

项目的成本管理中，成本预算将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。

项目时间管理包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。
为了得到工作分解结构(Work Breakdown Structure，WBS)中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就是活动定义。
鱼骨图(也称为Ishikawa图)是一种发现问题“根本原因”的方法，通常用来进行因果分析。

配置项是构成产品配置的主要元素，配置项主要有以下两大类： (1)属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等; (2)属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。所以设备清单不属于配置项。

所有的配置项都应列入版本控制的范畴。配置项的状态通常有3种，分别是草稿、正式发布和正在修改。

配置管理是PMBOK、IS09000和CMMI中的重要组成元素，它在产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理方法，是项目管理的基础工作。配置管理是通过技术和行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。

产品配置是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置项（ConfigurationItem，CI)，配置项主要有两大类： 属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等。属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分，但是值得保存。

软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。用户文档：用户文档是用户了解系统的第一步，它可以让用户获得对系统的准确的初步印象。用户文档至少应该包括下述5方面的内容：(1)功能描述：说明系统能做什么； (2)安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；(3)使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误时怎样恢复和重新启动）；(4)参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）；(5)操作员指南（如果需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。
系统文档：所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是非常重要的。

项目管理工具具有以下特征： (1) 覆盖整个软件生存周期； (2) 为项目调度提供多种有效手段； (3)利用估算模型对软件费用和工作量进行估算； (4) 支持多个项目和子项目的管理； (5) 确定关键路径，松弛时间，超前时间和滞后时间； (6)对项目组成员和项目任务之间的通信给予辅助； (7) 自动进行资源平衡； . (8) 跟踪资源的使用； (9)生成固定格式的报表和剪裁项目报告。 成本估算工具就是一种典型的项目管理工具。

需求管理
①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。
②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。
③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。

软件需求工程是包括创建和维护软件需求文档所必须的一切活动的过程，可以分为需求开发和需求管理两大工作。
需求开发包括需求获取、需求分析、编写需求规格说明书（需求定义）和需求验证4个阶段。在需求开发阶段需要确定软件所期望的用户类型，获取各种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。
需求管理是一个对系统需求变更、了解和控制的过程，逋常包括定义需求基线、处理需求变更和需求跟踪方面的工作。需求管理强调：控制对需求基线的变动；保持项目计划与需求的一致；控制单个需求和需求文档的版本情况；管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；跟踪基线中的需求状态。
需求开发与需求管理是相辅相成的，需求开发是主线、目标；需求管理是支持、保障。

需求定义的过程也就是形成需求规格说明书的过程，通常有两种需求定义的方法： 严格定义方法和原型方法。
严格定义方法也称为预先定义，需求的严格定义建立在以下基本假设之上：
①所有需求都能够被预先定义。这意味着在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。但这种假设在许多场合是不能成立的。
②开发人员与用户之间能够准确而清晰地交流。
③采用图形（或文字）可以充分体现最终系统。在使用严格定义需求的开发过程中，开发人员与用户之间交流与沟通的主要工具是定义报告，包括文字、图形、逻辑规则和数据字典等技术工具。
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。采用原型方法时需注意一下几个问题：
①并非所有的需求都能在系统开发前被准确地说明。
②项目干系人之间通常都存在交流上的困难。
③需要实际的、可供用户参与的系统模型。
④有合适的系统开发环境。
⑤反复是完全需要和值得提倡的。需求一旦确定，就应该遵从严格定义的方法。

需求变更
(1)所有需求变更必须遵循变更控制过程： 
(2) 对于未获得批准的变更，不应该做设计和实现工作； 
(3)变更应该由项目变更控制委员会决定实现哪些变更； 
(4) 项目风险承担者应该能够了解变更数据库的内容； 
(5)决不能从数据库中删除或者修改变更请求的原始文档； 
(6) 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 
软件开发工具：需求分析工具、设计工具、编码与排错工具。
软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

CMM即软件开发能力成熟度模型，是用来指导软件过程改进的。

来源：珑志凤