实用软件工程方法PPT10

第10章项目计划阶段课程介绍本章从六个方面介绍MSF应用开发项目计划阶段首先是计划阶段的主要活动；为了做出主项目进度表的调度原理；计划阶段的成功标准；达到里程碑的工作产品；建议的中间里程碑；最后是各角色在本阶段的重点工作本章内容计划阶段的活动调度原理计划阶段的成功标准计划阶段的文档计划认可里程碑及中间里程碑计划阶段小组角色的职责本章小结问题和讨论10.1计划阶段的活动技术验证解决方案的设计创建主项目计划创建主项目进度建立开发和测试环境10.1.1技术验证考察技术该技术能否手工安装或配置（使技术处在理想条件下，无需与生产环境匹配）写出文档：为使这种技术能工作必须做的事为设计提供信息开始标识问题和技术风险，并记入文档按照对风险和问题最佳的理解，更新主项目进度表10.1.2解决方案的设计设计过程设计过程与计划的关系概念设计逻辑设计物理设计10.1.2设计过程概念设计逻辑设计物理设计场景，对象和服务，用户界面逻辑数据库，构件，用户界面物理数据库10.1.2设计过程与计划的关系小组基准概念设计未到达基准即开始逻辑设计，而物理设计必须在概念设计到达基准才开始10.1.2概念设计（1）1.概念设计过程的定义、目的和输出2.概念设计视图概念概念设计是业务和用户观点的视图业务解决方案逻辑物理10.1.2概念设计（2）设计者需要调查的问题业务需求或问题是什么？谁是用户？用户真正做的是什么？用户需求是什么？已有什么？什么是最优解决方案？得到最优解决方案时，如何了解概念设计目标设计完全基于业务和用户提供的真实数据关于产品的连贯的、集成的描述有价值的抽象或分类层次业务、用户和项目小组达成共识的期望集合设计小组意见一致与企业体系结构同步小组沟通的基础10.1.2概念设计（3）澄清概念设计概念创建场景场景以叙述和图形的方式对问题和解决方案进行描述场景是一个理解需求、以及与用户交流的有效方法创建场景的一个方法是使用故事板（storyboard）概念设计不是作用完整的功能规范开发部分的功能规范用户接口细节设计一个高效的用户接口系统组件定义了解协同工作的部件技术解决方案设计一个解决业务问题的解决方案10.1.2概念设计（4）概念设计的价值在特定的业务环境下讨论需求和功能特性代表了业务需要与用户需求为初步规范提供了输入支持交互的目标最小化了重复工作量提供了改变用户工作实践的信息提供了长期的、可扩展的设计规划10.1.2逻辑设计（1）逻辑设计过程的定义、目标和输出逻辑设计视图逻辑设计视图是从项目小组的观点来看待解决方案10.1.2逻辑设计（2）澄清逻辑设计的概念逻辑设计不是作用技术解决方案定义必须以技术支持的业务需要揭示技术限制及机会对特定物理模型的优化标识可以实现的技术标识那些因基础架构和部署原因而必须调整逻辑设计的地方10.1.2逻辑设计（3）逻辑设计的价值管理复杂性设立边界、描述接口，提供一个有机的结构使多个小组可以交互揭示概念设计中的不一致和错误消除冗余，标识潜在的重用为物理设计提供基础改进系统各部分的运作在项目组成员间形成解决方案的公共视图10.1.2物理设计（1）物理设计的定义、目的和输出物理设计视图物理设计视图描述了开发者对解决方案的看法10.1.2物理设计（2）澄清物理设计的概念物理设计不是作用编码为开发创建编码规范技术部署选择技术10.1.2物理设计（3）物理设计的价值评估实现的可选项提供一个灵活的基于组件的设计成为估计费用、进度和资源的基础对应内部里程碑和内部发布，把解决方案映射到过程模型求精并更新风险寻找与企业体系结构的兼容性可以从逻辑设计回溯到使用场景10.1.3创建主项目计划主项目计划由以下十个计划组成：部署计划（deploymentplan）试运行计划（pilotplan）采购计划（purchasingplan）设施计划（facilitiesplan）测试计划（testplan）培训计划（trainingplan）沟通计划（communicationplan）容量计划（capacityplan）安全性计划（securityplan）预算计划（budgetplan）10.3部署计划对组件而言，是从开发环境迁移到生产环境，部署计划就是迁移计划部署计划的关键域和处理方法迁移计划考虑操作系统迁移；应用程序部署/升级；硬件平台迁移涉及的关键域途径安装策略分阶段或同时，逐站点或逐部门，推或拉意外事故计划(保证业务连续)并行系统，完全备份和恢复，或无意外事故站点/整个业务调查方法计划阶段全部调查，或部署阶段逐站点调查部署机制全自动网络安装，部分按脚本安装和手工安装部署资源内部IT员工或承包商系统支持途径分层支持或试运行和全力支持10.1.3试运行计划试运行（pilot）是将解决方案部署到生产实际环境中的第一次机会，只部署最关键的组件和要求相应的操作者试运行计划的关键域和处理方法涉及的关键域途径试运行组件的选定紧要的业务需要的，可见性好的或对用户组有影响的，或有失败风险的试运行的工作范围通过解决方案功能性和部署过程的部分测试，或解决方案和部署过程的全面测试试运行成员个数少量参与者、整个部门、或整个站点试运行数一个或少数几个试运行反馈机制与计划阶段同时或部署阶段逐站点部署时10.1.3采购计划硬件和软件采购时应该考虑以下方面与供货商签约订货处理事先配置入库/上货架验收/存放过时设备处理10.1.3设施计划设施变动物理设施计划应该考虑以下方面楼宇许可证最终用户的工作空间电缆安置其他局域/广域网设施服务器设施10.1.3测试计划测试计划关键域和处理方法涉及的关键域途径要测试的类型以及每种测试类型要用到的功能/技术领域单元测试，集成（系统）测试，性能测试，强度测试，可用性测试及回归测试测试的格式和成功准则全文档测试场景和测试结果，以及口头签收的非正规测试变更控制程序式的检入/检出过程和非正式传递过程配置管理硬件、软件和文档标准的集中管理和配置的本地管理问题追踪问题标识、优先级。在疵病追踪数据库中的追踪，以及通过E-mail的问题追踪10.1.3培训计划培训计划的关键域和处理方法涉及的关键域途径培训对象所有受影响的用户,以前的终端用户，IT管理者，桌面帮助设计人培训工具手把手培训、讲解风格式培训、基于计算机或WEB的培训，一对一培训、作业辅助培训和讲义培训材料的开发买或编写培训期全日，半日，两小时，或特定的培训完成时间先于部署，部署期间，部署刚完成或按用户要求培训资源内部培训人员或按合同培训人员10.1.3沟通计划沟通计划潜在的受众潜在的方式潜在的消息所有用户面对面开会发生了什么，为什么发生所有受影响的用户备忘录它将何时发生管理人业务沟通会影响到谁所有IT人员内联网用户会受到什么影响IT管理人E-mail用户应作何准备帮助桌面语音邮件用户怎样才能得到更多的信息10.1.3容量计划容量计划涉及以下方面本解决方案产生了多少附加的网络流量这些附加的网络流量将如何影响到用户当前的系统和网络是否有能力处理预期的用途增加服务器是否有必要增强系统和网络容量所要求的硬件设施是什么10.1.3安全性计划安全性计划涉及以下方面建立的安全指南如何维护在缺乏安全指南的情况下，为缓解风险要采取什么行动如果建立的安全措施与项目的成功完成有了冲突，将采取什么样的临时安全措施安全性计划要考虑成本和被保护对象的价值10.1.3预算计划标识预期的费用和费用约束，需要考虑：功能规范其他的项目计划（例如，开发、部署、试运行、采购、器材、测试、培训、沟通、增容、安全）客户的期望值10.1.4创建主项目进度主项目进度（masterprojectschedule）包括：开发进度表测试进度表用户教育进度表后勤管理进度表产品管理进度表10.1.4创建主项目进度（1）估算技术对人的任命；技术的成熟度；系统的复杂性；环境的稳定性；所用开发工具；调整和分析工具的可用性；协调技术和小组技术水平的关系；小组动态性；可重用性的机遇；客户的期望值；设计的灵活性和模块性；企业文化任务层次上的估算指南小组的领导人实施任务分解和定优先级；由小组成员作任务层次上的估算；每个任务都有一个起始和结束点；产生一个单独的产品或工作产品；任务要分配到个人；为了反馈和改正及时，任务的粒度可调整（约半天到一周）10.1.4创建主项目进度（2）容许的不确定性缓冲时间小组的目标是一个内部里程碑由程序管理者控制缓冲时间缓冲时间并不是为很差的任务定义安排的内部里程碑开发时间外部可见里程碑10.1.5建立开发和测试环境10.2调度原则微软总结了大量调度实践中的经验提出以下四条原则：估算工作量由底向上上市日期坚定不动的意识风险驱动调度为不确定的未来调度10.2.1估算工作量由底向上谁做这个工作，就由谁去推断这个工作需要的时间，应该是一个基本的信条。当然，精确不是目标，任何人都有预断不到之处——JimMcCarthy《软件开发动力学》10.2.2上市日期坚定不动的意识一旦商定项目产品的上市日期决不轻易更改有利于培养员工的意志品质：“言而有信”任何工作失误都会导致资源（成本）增加10.2.3风险驱动调度把注意力集中在优先级最高的风险上，并按优先级安排任务风险驱动的调度还鼓励尽早在概念上证实原型较大的风险一般起因是在上层或最上层，而缓解和消除必须在下层做切实的工作10.2.4为不确定的未来调度未来是不确定的为了使不确定变为相对确定一些，人们把大任务化小是常用的办法使用离散任务设立中间里程碑（interimmilestone）增加缓冲时段。10.2.4使用离散任务大任务化为相对独立的小任务如果无法化小，那么就建立中间里程碑使用离散任务的好处持续时间短，出错的余地小；出了问题影响面小，易于控制；任务小，工作量估算容易精确10.2.4设立中间里程碑可以把大的功能集分解为若干小的功能集，作为中间里程碑这些小的功能集越独立越好在中间里程碑评估项目进展，并调整项目计划把每个中间里程碑当作一次实际的发布缓冲时段内部发布1特征开发内部发布2测试和稳定化验收测试里程碑评审6-8周2-4周2-3周10.2.4增加缓冲时段不仅可留出处理偶发因素的时间，对于保证按时完成也是必须的，它还有助于允许角色或小组的隐私设立项目缓冲时段缓冲时段开发时间小组估计日期里程碑10.3计划阶段的成功标准干系人和项目组针对项目就以下几点达成一致：要交付的解决方案组件主要项目里程碑的日期如何构建解决方案创建好开发和测试环境开始对项目进行变更控制和配置管理发起人和（或）主要干系人正式认可本阶段的交付成果和完成的工作10.4计划阶段文档项目计划阶段的工作产品工作产品目的责任者功能规范文档描述要做什么程序管理主项目计划描述怎么做程序管理主项目进度表描述何时做程序管理复审主风险评估文档描述在制作中的任何问题程序管理10.4.1功能规范文档功能规范文档的内容功能规范的作用功能规范文档编制指南功能规范文档常见的缺陷功能规范审核10.4.1功能规范文档（1）功能规范文档的内容内容解释远景概述远景文档总结，以及解决方案的业务环境设计目标影响决策的关键设计目标，包括性能、可靠性、时限、可访问性、可用性产品需求客户/用户的需求，包括优先需求和冲突平衡用户概述按业务案例说明谁在什么时候用到本产品的什么功能特性按优先级排出的产品功能特性及其功能，说明包括用户界面、导航产品依赖性高层依赖是外部系统，底层依赖是共享组件进度总结主项目进度表的概述，关键的日期及其工作产品，上市日期风险风险列表附录设计过程的输出10.4.1功能规范文档（2）功能规范的作用功能规范是开发主项目计划，主进度表的基础功能规范记录了项目组和客户/用户达成的共识功能规范文档编制指南要理解本规范文档使用者的需要风格一致不要想一次成，要多次反复，收集反馈明确写出产品，功能特性是什么找出核心的功能特性集，以及产品改进和新版本的生成将已明确的项目变量转变成设计目标功能规范