面向对象软件开发过程初始阶段

面向对象软件开发过程初始阶段第一页，共二十八页，编辑于2023年，星期五提纲§7b.1POS案例§7b.2初始阶段的主要工作§7b.3需求类型§7b.4用例模型：写出实际语境中的需求§7b.5识别其他需求§7b.6从初始阶段到细化阶段2第二页，共二十八页，编辑于2023年，星期五§7b.1POS案例POS系统：记录销售信息，处理支付过程，常用于零售店。系统包括：硬件：计算机，条码扫描器软件：与其他系统连接：第三方税金计算器和库存控制系统系统要求：相对容错：库存系统故障不影响销售和付款，即：如果远程服务（库存系统）暂时中断，系统必须能够获取销售信息和处理现金付款，不至于营业瘫痪。多客户终端：瘦客户Web终端、PC、触摸屏、无线PDA易于客户化，如不同用户在开始一个新的销售或增加新商品时要求执行一些额外的业务逻辑，系统应该灵活支持。3第三页，共二十八页，编辑于2023年，星期五§7b.2初始阶段的主要工作初始阶段应该考虑以下问题：项目的构想怎么样？商业案例是什么？可行性如何？购买还是开发？粗略估计一下成本，估计收益。项目是否停止或继续进行？主要目标：只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究系统即可。（深入的研究是细化阶段的工作）概括为：预见项目的范围、构想和商业案例；项目相关人员是否就项目的构想达成基本的一致，项目是否值得继续进行认真的研究。4第四页，共二十八页，编辑于2023年，星期五§7b.2初始阶段的主要工作初始阶段的时间比较短暂，只要建立起初始的一般构想，并确定项目是否可行，是否值得细化研究就行。工件注解构想和商业案例描述高层的目标和约束、商业案例，并提供一个执行摘要用例模型描述功能需求和相关的非功能需求(10%)补充规范描述其他需求术语表关键的领域术语风险列表和风险管理计划描述业务、技术、资源和进度上的风险，以及如何减轻这些风险或该如何应对。原型和概念验证阐明构想，验证技术问题迭代计划描述在第一次细化迭代中该做什么？阶段计划和软件开发计划对细化阶段的持续时间和工作量进行低精度的猜测。开发涉及的工具、人员、培训和其他资源。开发案例描述为本项目定制的统一过程的步骤和工件。在统一过程中，总需求为项目定制一些步骤或工件。5第五页，共二十八页，编辑于2023年，星期五§7b.3需求类型需求就是系统必须提供的能力和必须遵从的条件。需求管理更推崇用“一种条理化的方法来寻找、记录、组织和跟踪系统不断变化的需求”。需求类型：FURPS＋Function（功能）：特性、能力、安全性Usability（可用性）：人性化因素、帮助和文档；Reliability（可靠性）：故障周期、可恢复性、可预测性；Performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率；Supportability（可支持性）：适应性、可维护性、国际化、可配置性。＋：一些辅助性和次要的因素。Implementation（实现）：资源限制、语言和工具、硬件等；Interface（接口）：与外部系统接口所加得约束；Operations（操作）：系统操作环境中的管理Package（包装）Legal（授权）：许可证或其他方式。6第六页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求系统需求：为了满足客户使用系统的目的。用例：就是描述客户如何使用系统来达到目的的一组情节。以此来发现和记录系统的功能性需求。用例描述功能性需求的思想是由IvarJacobson在1986年提出来的，表达的主要思想是：在需求分析中专注于考虑系统怎么才能增加价值和实现目标。在面向用户目标的语境中考虑系统的功能和特性，这是用例的分析关键。用例模型是文本文档，UML中的用例图只是给出了角色和用例的名称和关系。7第七页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求黑箱用例Black-boxusecases——推荐使用将系统描述为具有某种职责,描述系统必须做什么（功能需求），而非如何做（设计），即：将系统看成一个黑箱，观察系统的外部行为：如：系统记录销售信息√系统将销售写入数据库×系统为销售生成INSERTSQL语句××8第八页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求用例建模的基本过程：1.选择系统边界：POS作为一个系统，包含软件、POS机、输入终端等，收银员、支付授权、税金计算等不包括在系统之内。2.识别主要角色：主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者。找出用户目标次要角色：为系统提供服务的那些参与者。说明外部接口和协议后台角色：对用例的行为感兴趣。保证找到并满足所有必要的兴趣。3.识别主要角色的目标一般来讲：第2和第3步是同时进行的。9第九页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求谁或什么使用该系统？交互中，它们扮演什么角色？谁安装系统？谁启动和关闭系统？谁维护系统？与该系统交互的是其他什么系统？谁从该系统获取信息，谁提供信息给系统？有什么事情发生在固定时间？角色：_______________角色职责：________________________________角色识别问题：_______________________________________________________________角色描述模板10第十页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求谁来启动和停止系统？谁来进行用户管理和安全管理？是否存在一个监控进程，其在系统错误的时候能够重启系统？系统升级怎样处理？主动升级还是被动升级？谁来管理系统？由于系统对时间事件进行响应，“时间”是否也是一个角色？谁来评估系统的活动或性能？谁来评估日志？日志是否能够远程获取？上述问题能够帮助我们找出容易遗漏的角色和目标11第十一页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求收银员：处理销售、处理租赁、处理返回、入款、出款……经理：启动、关机……系统管理员：添加用户、修改用户、删除用户、安全管理、系统表管理……销售活动分析系统：分析销售数据和销售表现……12第十二页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求4.定义用例：一般来讲，要为每个用户目标定义一个基本业务过程（EBP）级别的用例。EBP：由一个人在某个时间某个地点执行的一项任务，这项任务是对某一业务事件的反应，而且能够增加可以度量的业务价值，并且能够保持数据状态的一致。用例分析时，应该专注于EBP级别的用例。如：“验证身份”不是EBP级别的用例，是更低级别的用例，但是，由于它是很多EBP用例的前提或者一部分，所以可以单独写成用例。但是不要定义过多低级别上的用例，它们只是EBP中的一个步骤。具体步骤？用户目标企业目标13第十三页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求用例的表达简洁用例：简明扼要，通常用在主要场景。场景：是角色和系统之间的一系列特定的活动和交互，是用例的实例。临时用例：非正式的段落格式。详述用例详述用例的格式主要参与者：项目相关人员及其兴趣：把用例作为项目相关人员与系统之间的行为契约，从而界定系统必须做什么。前置条件：用例执行前的条件。后置条件：用例执行成功后的保证。14第十四页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求主要成功场景：（基本流程、典型流程）场景一般记录三种步骤：角色与系统之间的交互；验证动作（通常由系统完成）系统完成状态改变（如：记录什么、修改什么）扩展：（替代流程）扩展由两部分组成：条件和处理。以系统或角色能够检测到的某事物作为条件。特殊需求：与用例相关的非功能性需求质量属性：性能、可靠性、易用性设计约束技术与数据的变化列表：描述技术上的设计约束，特别是有关I/O的技术。发生频率待解决的问题15第十五页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求用例：处理销售主要参与者：收银员项目相关人员及其兴趣：前置条件：收银员必须已经被识别和授权后置条件：存储销售信息、准确计算税金、更新账目和库存信息、记录提成、生成收据、记录支付授权服务的许可。主要成功场景：1.顾客携带商品到达POS机收费口2.收银员开始一次新的销售3.收银员输入商品标识4.系统记录单件商品，并显示该商品的描述、价格、累加值。价格可以根据一套定价规则来计算。

收银员重复3～4步，直到商品输入结束。5.系统显示总值并计算税金。6.收银员请顾客付款。7.顾客支付，系统处理支付。8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统和库存系统。9.系统打印收据10.顾客带着商品和收据离开。……16第十六页，共二十八页，编辑于2023年，星期五§7b.4用例模型：写出实际语境中的需求用例图1.用例图要简单；2.用例的主要工作不是画图，而是写出文本。收银员支付授权服务处理销售处理退货收款分析活动17第十七页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求用例模型只是描述了系统的功能性需求，其他需求放在下列工件中描述：补充规范：未在用例中描述的FURPS+需求。术语表：术语及其定义，还可以用作数据字典。构想（vision）：概述项目的远景。构想用简洁的语言表达项目总体想法，包括：项目为什么被提出？有哪些问题？有哪些项目相关人员？他们需要什么？以及提出了哪些解决方案等。定义了项目相关人员对待开发产品的见解，根据项目相关人员的主要需要和系统特性来规定。18第十八页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求补充规范修订历史简介功能性跨越许多用例的一般功能日志和错误处理可插入的业务规则安全性可用性人性因素可靠性可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，以使交易能够完成。性能19第十九页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求可支持性适应性可配置性实现约束采购的组件免费的开放源码的组件接口值得注意的硬件及其接口软件接口领域（业务）规则：规定一个领域或者业务如何操作，如：信用卡支付需要签名。法律问题有关感兴趣的领域信息20第二十页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求构想修订历史简介定位商业机会问题综述产品定位综述替代方案和竞争对手项目相关人员描述项目相关人员（非用户）概述用户概述项目相关人员主要的高级别目标和问题用户级别目标用户环境21第二十一页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求产品纵览产品远景优点概述假设和依赖成本和定价授权和安装系统特性概述系统特性是系统提供的一个外部可观测到的服务，这种服务能够直接满足项目相关人员的需要。特性是系统能做的事情。系统会做<某特性>其他需求和约束22第二十二页，共二十八页，编辑于2023年，星期五§7b.5识别其他需求术语表修订历史定义术语定义和相关信息别名23第二十三页，共二十八页，编辑于2023年，星期五§7b.6从初始阶段到细化阶段初始阶段的检验点：初始阶段并非项目的需求阶段，而只是一个简短（为期1周）的步骤，用来决定项目的基本可行性、风险、范畴。细化阶段进一步探讨需求。初始阶段的可能活动和工件包括：一个简短的需求讨论会（为期2天）；命名大多数的角色、目标和用例。用简短格式书写大部分用例；用详细格式书写10%～20%的用例，以更好地理解项目的范畴和复杂性。识别最具风险的质量需求。编写构想和补充规范的第一个版本。风险列表概念验证原型和特殊需求的技术可行性研究用面向用户界面原型澄清功能性需求构想购买/构建/重用什么组件的建议，在细化阶段完善组件高层候选架构和组件建议计划第一次迭代候选工具列表24第二十四页，共二十八页，编辑于2023年，星期五§7b.6从初始阶段到细化阶段细化是这样的一系列迭代：开发团队认真地研究、实现核心架构，阐明主要需求并处理高风险的问题。早期的迭代处理那些业务上重要的但不含技术风险的场景。