软件开发过程

软件开发过程朱大治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):与系统交互的角色或系统用例(Usecase):系统能为外部参与者提供的功能柜员用例简述用例名称：销户用例简述：帮助银行工作人员完成银行客户申请的活期账户销户工作，需客户提供证件和密码。优先级：高储蓄系统“销户”用例简述通过简短的文字对用例进行描述一般而言，用例简述应包含成功场景的简单描述用例规约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地址等节点软件配置操作系统，中间件，执行环境可部署单元架构设计中的逻辑设计视角，眼界是整个系统或一个独立的子系统将系统分解梳理设计出系统中的重要组件，并进行子系统划分关注组件间如何配合，交互以满足功能性需求设计主要的内部接口和所有外部接口充分考虑，衡量系统的各种非功能性需求（可用性，性能，可扩展性等），应用如分层，分割，缓存，集群，分布式，异步，冗余，自动化等架构模式识别可重用的方法，组件，并做出购买，制造或重用已有组件的决定详细设计中的逻辑设计关注度集中在一个独立的组件根据架构设计中对此组件的职责功能界定以及外部接口定义来进行内部的详细逻辑设计类图，对象图，时序图状态图其他重要的活动或工件项目定义系统上下文架构概览图架构决策