软件开发过程

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,软件开发过程,朱大治,Agenda,架构设计,领域建模,用例技术,软件需求过程,软件过程概述,一般的软件过程,概念化阶段,分析阶段,架构设计阶段,并行开发与测试阶段,验收与交付阶段,愿景,需求,架构,可执行系统,交付的系统,架构师相关的细化模型,分析阶段,需求分析,领域建模,架构设计阶段,确定关键需求,概念性架构设计,细化架构,验证架构,概念性架构,实际架构,关键需求决定架构,全面认识需求,多视图探寻架构,尽早验证架构,Agenda,架构设计,领域建模,用例技术,软件需求过程,软件过程概述,需求，架构设计阶段过程示意图,概念化阶段,分析阶段,需求分析,领域建模,架构设计阶段,概念化阶段,愿景与范围文档,项目的起源,项目目标,主要特性,功能范围,成功要素,1.,业务需求,a),项目背景,b),业务机遇,c),业务目标,d),客户或市场需求,e),提供给客户的价值,f),业务风险,2.,项目愿景的解决方案,a),项目愿景陈述,b),主要特性,c),假设和依赖环境,3.,范围和局限性,a),项目首次发布的范围,b),随后发布的范围,c),局限性和专用性,4.,业务环境,a),项目客户概貌,b),项目的优先级,5.,产品成功的因素,如果软件开发只能有一份文档，那它应当就是,愿景文档,软件需求基础,需求捕获,需求分析,系统分析,需求捕获,需求分析,系统分析,需求分析：做什么,系统分析：怎么做,需求阶段的成果物,需求捕获,采集：需求类型，描述，背景，提出者，记录者,成果：需求采集卡,需求分析,目的：对原始需求进行分析，整理，辨别，归纳,成果：软件需求规格说明书,系统分析,方法：面向对象分析（结构化分析）,成果：分析类图，鲁棒图，序列图（数据流图）,工程领域的需求分类,以建造大桥为例,功能需求：联结南北的公路交通,约束条件：不能影响万吨轮从桥下通过,使用期质量属性：能在湍急的江流中保持稳固,建造期间的质量属性：施工方便,软件需求的类型,软件需求,功能需求,非功能需求,约束,质量属性,运行期质量属性,开发期质量属性,设计或项目的某些限制条件,软件系统应提供的服务,为用户提供的服务,为其他系统提供的服务,质量属性,运行期质量属性,开发期质量属性,性能,(Performance),安全性,(Security),易用性,(Usability),持续可用性,(Availability),可伸缩性,(Scalability),互操作性,(Interoperability),可靠性,(Reliability),鲁棒性,(Robustness),易理解性,(Understandability),可扩展性,(Extensibility),可重用性,(Reusability),可测试性,(Testability),可维护性,(Maintainability),可移植性,(Portability),各类需求与软件架构之间的关系,约束,架构,功能,质量属性,遵守,限制,从根本上支持,从根本上影响,影响,适应,导致某些功能需求,导致某些质量属性需求,从约束性需求导出功能需求和质量属性需求的例子,非功能需求,功能需求,约束,运行期质量属性,开发期质量属性,必须执行国家统一规定的利率，并与最新公布的利率调整方案保持一致,.,可配置性,.,调整利率的实用功能,.,对某银行系统进行的需求分析,各类需求的易变性,易变化性,（低到高）,需求种类,质量属性需求,约束性需求,功能需求,各类需求的易变性,功能需求最易变化,用例图往往是稳定的,用例规约则可能频繁变化,质量属性最为稳定,性能，安全性，持续可用性,约束稳定性稍差,技术趋势变化，法律法规重新界定，用户组织调整改组,SRS,需求分析过程,业务目标,特性列表,用例图,用例简述,用例规约,界面原型,可执行原型,非功能性需求,界面原型或可执行原型用来帮助客户发现他真正想要的功能,原型界面产物不应放入,SRS,，因为它们属于设计，而不是需求,进行需求分析时，不应遗漏业务和技术发展与变化的可能性，必要时，将潜在需求变化记录在案,Agenda,架构设计,领域建模,用例技术,软件需求过程,软件过程概述,用例技术,需求阶段的业界事实标准,用于所有用例的技术：,用例图,用于单个用例的技术,用例实现,用例描述,用例简述,用例规约,用例相关技术,鲁棒图,（静态视角）,序列图,（动态视角）,需求捕获技术,需求分析技术,系统分析技术,用例图,开户,销户,参与者,(Actor):,与系统交互的角色或系统,用例,(Use case):,系统能为外部参与者提供的功能,柜员,用例简述,用例名称：销户,用例简述：帮助银行工作人员完成银行客户申请的活期账户销户工作，需客户提供证件和密码。,优先级：高,储蓄系统“销户”用例简述,通过简短的文字对用例进行描述,一般而言，用例简述应包含成功场景的简单描述,用例规约,1.,用例名称,销户,2.,简要说明,帮助银行工作人员完成银行客户申请的活期账户销户工作,3.,事件流,3.1,基本事件流,1),银行工作人员进入“活期账户销户”程序界面,2),银行工作人员用磁条读取设备刷取活期存折磁条信息,3),系统自动显示此活期账户的客户资料信息和账户信息,4),银行工作人员核对销户申请人的证件，并确认销户,5),系统提示客户输入取款密码,6),客户使用密码输入器，输入取款密码,7),系统校验密码无误后，计算利息，扣除利息税（调用结息,用例），计算最终销户金额，并打印销户和结息清单,8),系统记录销户流水及其分户账信息,3.2,扩展事件流,1),如果存折磁条信息无法读出，需要手工输入账号,2),如果销户申请人的证件与客户资料信息不符或其他业务因素，而不,予受理的，银行工作人员直接退出,3),如果系统密码校验错误，提示重新输入密码，密码校验失败超过,3,次，系统提示并自动退出,用例规约,4.,非功能性需求,申请受理处理的过程操作时间应在,30,秒内,打印的销户和结息清单应该清晰明了,5.,前置条件,账户为正常状态（即不是挂失，冻结或销户状态）,6.,后置条件,销户成功并将销户信息存入数据库，,证件不符而退出,密码不符而退出,7.,扩展点,无,8.,优先级,高,实践中我们可以对用例规约进行裁剪或扩充，比如增加用例的“使用频率”，“需求背景及可能的变化”等供架构师在架构设计时进行参考,用例实现,客户资料,销户流水,活期账户,利息率,利息税率,计算利息,销户,活期账户销户界面,磁条读取设备,打印设备,银行工作人员,销户用例的用例实现（鲁棒图）,用例技术与需求层次的关系,业务需求：组织要达到的目标,用户需求：用户使用系统来做什么,行为需求：开发人员需要实现什么,用例图,用例简述,用例规约,用例实现,业务需求,用户需求,行为需求,初步设计,用例技术与需求捕获，需求分析的关系,需求采集卡,故事卡,用例图,+,用例简述,用例规约,需求捕获技术,需求分析技术,架构设计不应等到所有用例被细化到用例规约的程度才开始，对架构设计起关键作用的功能需求只占功能需求的一小部分，这部分用例应该已经被细化到用例规约的程度，它们和其他非功能需求一起决定架构设计方案,Agenda,架构设计,领域建模,用例技术,软件需求过程,软件过程概述,什么是领域模型,账户,凭证,-,生效日,-,作废日,银行卡,-,卡号,存折,-,存折号,存单,-,存单号,领域模型,UML,类图示例,1,*,领域模型,UML,状态图示例,挂失,正常,冻结,销户,开户,开户额,10,销户,挂失,身份证,解挂,身份证,冻结,授权,解冻,授权,存款,取款,需求分析中的困难,领域模型是对实际问题领域的抽象，它“穿透,”,用户想要的功能的表象，专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系，因此，开发方和用户在,”,领域模型“上达成的共识，往往比在,”,功能需求“上达成的共识”更升一级,”,从而也更稳固,用户的参与不够，造成需求分析成果中假设的成分太多,用户：需求很明白啊，不用向你们这样投入这么大的精力吧,事实：用户真正使用软件系统一段时间之前，他们往往并不确切知道自己需要什么,需求分析中的困难,对于需求分析而言，存在一个领域知识的“夯实”概念，我们再需求分析过程中，应该搞清楚一部分领域知识，就将此部分知识建模并将模型在整个项目组公开，再搞清楚一部分领域知识，再建模并将模型在整个项目组公开,问题领域太复杂时，需求分析的开展会遇到困难,需求分析过程中，可能不断地因“对关键领域问题的理解不足”而卡壳或者争论不休，例如，银行系统中客户，账户，凭证的关系因“一本通”，“一卡通”的出现变得复杂了，需求讨论可能一而再，再而三的影响需求分析的推进,领域建模与需求分析的关系,项目启动,领域建模,需求分析,架构设计,详细设计,详细设计,详细设计,领域建模所处的位置,需求定义,领域模型,界面,可扩展性等方面的架构决策,设计类,持久数据模型,实现类,领域知识及词汇,要展现的内容,要持久化的内容,精化,精化,影响可扩展性,分析阶段,架构设计阶段,开发阶段,Agenda,架构设计,领域建模,用例技术,软件需求过程,软件过程概述,软件架构,4+1,视图,用例视图,站在用户的立场分析系统应提供的,服务，其他视图的出发点,逻辑视图,最终用户的功能,过程视图,非功能性需求,实现视图,开发人员,物理视图,系统工程师,用例视图,简要描述系统提供的,服务（用例）,用例图,用例简述,详细描述系统提供的,服务（用例场景）,用例规约,用例场景图,逻辑视图,设计人员把系统分解成一系列的关键抽象（组件）以满足典型和重要的用例场景,鲁棒图（静态）,时序图（动态）,状态迁移图（动态）,ER,图，领域模型,业务实体类（概念类图，数据字典）,过程视图,描述系统非功能性需求的解决方案,以进程或线程为视角，说明系统如何满足诸如可用性，分布式，并发等非功能性需求,明确进程间通信的形式，比如同步或异步消息，,RPC,，共享内存等,组件图中的组件到底是什么,组件,(Component,）本身是高内聚，松耦合，职责专一的可重用设计元素,但在,作,UML,图时，在不同阶段的设计有可能都使用到,Component,这个图元，这时它不拘泥于上述定义，它有可能对应到,一个,进程,一个外部系统,一个线程,一个具体类,一个包含多个类的模块,一个特定任务（,Job,）,开发视图,源代码的组织,代码层级，程序包或文件目录设计,代码的构建,可部署单元列表，依赖关系,内外部接口定义,重要方法（重要的参数或返回值的数据结构）,物理视图（部署视图）,地理位置,网络拓扑,节点硬件配置,设备型号，,CPU,，内存，硬盘，,IP,地址等,节点软件配置,操作系统，中间件，执行环境,可部署单元,架构设计中的逻辑设计,视角，眼界是整个系统或一个独立的子系统,将系统分解梳理设计出系统中的重要组件，并进行子系统划分,关注组件间如何配合，交互以满足功能性需求,设计主要的,内部,接口和所有外部接口,充分考虑，衡量系统的各种非功能性需求（可用性，性能，可扩展性等），应用如分层，分割，缓存，集群，分布式，异步，冗余，自动化等架构模式,识别可重用的方法，组件，并做出购买，制造或重用已有组件的决定,详细设计中的逻辑设计,关注度集中在一个独立的组件,根据架构设计中对此组件的职责功能界定以及外部接口定义来进行内部的详细逻辑设计,类图，对象图，,时序图,状态图,其他重要的活动或工件,项目定义,系统上下文,架构概览图,架构决策,