课程简介
分析与设计这两个词我们平时经常听到，到底什么是分析？又要怎样去设计？
软件分析往往指的是以用户需求为基准的分析，它是一个项目的开端，也是项目实施最重要的关键点，软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。而设计是基于分析基础上的实际操作，拉曼《UML和模式应用》一书中，对分析与设计概括成：分析是做正确的事，设计是正确地做事。
课程收益
1．学会挖掘、洞察用户需求并将其转化为产品需求；
2．掌握将产品需求映射到软件系统设计；
3．分析UML在需求分析及系统设计中的要点，及系统分析中对象的发掘要点；
4．掌握系统的分层设计及如何设计出高可扩展系统；
5．掌握实际项目中的系统间、模块间、系统内的接口设计。
受众人群
软件设计师、软件开发人员、开发团队中的设计人员、系统分析人员
课程时长
2天（12H）
课程大纲
| 内容 | 课程纲要 | |
| 单元1：将用户需求转换为产品需求 | 内容1、用户需求与用户体验 | 1. 用户需求的抽象 2. 产品体验的用户 3. 用户需求的多样性 4. 处理用户需求的常见方法 ž 改变现状：根据用户需求改产品 ž 降低期望：通过降低期望提高用户对产品的满意度 ž 需求转移：通过其他需求或者更改需求的表现形式达到用户期望 |
| 内容2、如何发掘用户动机、确定用户需求？ | 1. 用户需求与用户动机 2. 经典的需求收集步骤——参考大师们的方式（Karl T.Ulrich.Steven D.Eppinger等） 3. 情景分析法 4. 原则：用户需求转换为产品需求要基于产品框架/结构的基础上 | |
| 内容3、用户需求转换为产品需求 | 1. 抽象出用户需求——确定用户动机或期望 2. 用户与产品交互过程分析 3. 根据用户动机去创造需求 4. 分析用户动机 5. 考虑产品框架的限制 6. 根据产品框架将需求实例化 7. 深挖用户需求 8. 产品设计做到极致 | |
| 典型案例分析：分析某电子书系统，分析需求设计中的教训及成功的经验，进行用户需求转换为产品需求概述 | ||
| 单元2：将产品需求映射到软件系统设计 | 内容1、明确系统的运营和业务模式 | 1. 不同的运营定位，对系统的方向性影响 2. 分析项目类型、所处环境等，明确运营模式 3. 传统软件销售 VS 互联网盈利模式 4. 平台软件 VS 功能软件、提供软件 VS 提供服务、提供工具 VS 提供一体化解决方案 5. 需求映射到软件设计中的约束 |
| 内容2、客户关系及需求的约束 | 1. 能解决用户痛点的系统，才是成功的系统 2. 理解用户的潜台词 3. 换位思考的要点 | |
| 内容3、系统的部署及运维条件的约束 | 1. 大而全 VS 小而精 2. 大系统的部署要点 3. 自建生态环境与借助外力 4. 考虑系统的运维成本及方式 | |
| 内容4、考虑系统流转的因素 | 1. 系统是如何流转的，初始数据/账号是如何形成的 2. 系统中，各部门在其中的职责是如何分配的 3. 系统中，各部门是如何协作的 4. 盈利模式对架构设计的影响（卖软件/卖账号/提供平台/提供内容/提供服务） 5. 开放平台与封闭平台策略 6. “撇清关系”与“一包到底”策略 | |
| 案例分析：实际案例，分析从产品需求、运营、消息、运维的角度考虑系统架构，及不同维度因素对系统设计的影响。 | ||
| 单元3：系统建模实践 | 内容1：UML需求分析与建模实践 | 1. UML视图：静态、动态、用例、物理视图 2. UML中关系的辨析与误用讨论 3. UML中用例建模的要点，Actor与用例建模中的注意事项 4. 用例的深层次讨论：Use-Case与系统服务层的关系及要点 5. UML使用中9大误区的讨论及辨析！ |
| 内容2：系统分析过程及实践 | 6. 设计模型的内容与演进 7. 全局分析：选用架构模式；识别关键抽象；标识分析机制；常见的分析机制 8. 局部分析：提取分析类：分析类的类型划分：边界类、实体类、控制类，分析类在模型中的位置，边界类的复用，控制类的变通 9. 分析需求场景：消息与责任；事件序列在边界、实体及控制类间的原则；控制类在交互图中的表现特征；交互图的正确性 10. 整理分析类：分析类的责任和关联关系；动态与静态的关系；确定类的责任 11. 设计类和子系统接口 | |
案例分析：分析UML在需求分析及系统设计中的要点，及系统分析中对象的发掘要点。 | ||
| 单元4：需求分析到建模案例分析 | 内容1、案例实践：Pos收银系统：从需求到系统对象建模建立 | 1. 项目背景介绍 2. 需求分析：确定系统的目标和特性。 3. 选择领域对象。 4. 确定对象的职责。 5. 确定动态场景。 |
| 内容2、案例实践：薪酬管理系统：从需求到系统架构设计 | 1. 项目背景介绍 2. 需求分析，Use-Case分析 3. 第1次设计 4. 对象建模的疑问和辨析 5. 第2次迭代 6. 从需求到软件架构设计中的模式运用 | |
| 内容3、案例实践：咖啡壶控制系统：从需求到系统架构选取 | 1. 项目背景介绍 2. 需求分析，初始设计中的问题 3. 分析问题的本质 4. 逐步调整设计 5. 总结：流程、抽象、控制 | |
| 内容4、案例实践：信息投递系统：从需求到系统建模 | 5. 项目背景介绍 6. Use-Case设计中的要点问题 7. 分层领域模型的简历 8. 总结：建模要抓住问题的关键问题，实用为王！ | |
| 典型案例分析：分析某Pos收银系统、薪酬管理系统、咖啡壶控制系统、信息投递系统这几个实际的案例，剖析如何进行系统建模。 | ||
| 内容5：系统的分层设计及如何设计出高可扩展系统 | 内容1、领域模型——系统分层设计 | 1. 面向对象的领域模型设计方法 2. 失血模型、贫血模型与充血模型的博弈 3. 外观层职责及设计要点 4. 服务层职责及设计要点——如何避免“庞大的服务层” 5. 模型层职责及设计要点——Vo类对象与富方法类的博弈 6. 数据访问层职责及设计要点——数据访问层与服务层的职责分配 7. 大型系统中的数据访问层设计要点 |
| 内容2、可扩展系统的特征及如何达成实践 | 1. 灵活性设计基本原则：最低复杂度 2. 局部化变更-可修改性战术目标是减少由某个变更直接影响的模块数量. 3. IOC思想在可扩展系统中的运用 4. ESB/SOA思想在系统设计中的运用 5. 利用或搭建云存储与云计算 | |
| 内容3、案例实践：通用文件处理系统——高可用系统的达成 | 1. 灵活性设计基本原则：最低复杂度 2. 局部化变更-可修改性战术目标是减少由某个变更直接影响的模块数量. 3. IOC思想在可扩展系统中的运用 | |
| 内容6、系统接口设计及演化分析 | 内容1、系统内接口的设计 | 1. 接口的本质 2. 接口的可见性 3. 基类与接口的区别与辨思 4. 内接口与外接口 5. 普通接口与智能接口 |
| 内容2、系统间接口的设计 | 1. Web接口的发展及选择：DCOM、Webservice、WebApi、RestFull 2. 接口的分层 3. 接口版本控制 4. 可伸缩接口的设计 5. 接口的无状态性 6. 接口设计中粒度平衡的技巧 | |
| 内容3、系统接口现代状况及发展潮流 | 1. 暴露UI的接口 2. 本地代理的用途 3. Html5潮流的冲击及对接口设计的影响 4. 轻量级Web服务器及本地数据库对接口设计的影响 5. 模糊化的服务器端及客户端 | |
| 型案例分析：分析实际项目中的系统间、模块间、系统内的接口设计，重点阐述在接口设计时，如何达在系统发生变化时，使原有系统免受/少受冲击。 | ||
| 内容7、系统的演化及架构设计总结（略讲） | 内容1、大系统的分析及演化 | 1. 应对压力第一步：将数据库分离出去 2. 大系统的常见手段：使用缓存 3. 改善应用服务性能：使用应用服务器集群改善并发/负载均衡 4. 数据库垂直切分和读写分离 5. 反向代理、负载均衡和CDN 6. 业务拆分/数据水平拆分 7. 分布式服务 |
| 内容2：软件架构设计总结 | 1. 面向对象设计原则理解 2. 一些软件设计的原则 3. 逻辑层 vs 物理层 4. 服务层的设计及分析总结 5. 面向服务架构及松散耦合 | |
| 典型案例分析：通过淘宝的系统等额发展，展示大系统的演化过程及每个阶段的要点，并进行系统设计的总结。 | ||
Galen Kang
百林哲咨询（北京）有限公司专家团队成员
Galen Kang
百林哲咨询（北京）有限公司专家团队成员
Galen Kang
百林哲咨询（北京）有限公司专家团队成员
Galen Kang
百林哲咨询（北京）有限公司专家团队成员
Galen Kang
百林哲咨询（北京）有限公司专家团队成员
京ICP备2022035414号-1
