产品开发流程图

一,瀑布型;

一般面向确定的需求,用瀑布型,可增加开发效率;

需求->分析->设计->编码->测试

优点:需求变化不大时,开发效率高,质量可控;
确定:需求变化很大时,灵活性很差;

需求设计端改了,下游的产品实现端已经完成此功能或者模块,无法灵活的应对需求的变化,得推翻重写。

参考:https://www.ngui.cc/el/1189020.html?action=onClick

二,迭代型开发过程;

一般面向不确定的需求,用迭代型,可试错,降低系统风险;

迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程。

迭代型开发,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

如下图:

延伸到敏捷开发:
敏捷开发采用的就是迭代模式,敏捷开发使用了迭代开发模型,敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

敏捷开发将一个大项目拆分成几个子项目,每个子项目又拆分成若干功能,每个功能又拆分成若干个故事点,故事点是一个可用可测试的单元。从时间上来说,每个子项目会安排1〜8个Sprint,每个Sprint—般为1〜2周,这样一个子项目大概有1〜3个月。

UML (重点:用例图、活动图、状态图)

用例图 – 类似于功能架构图,区别于功能架构图的是,能体验出功能之间的关系(包含、扩展);
活动图 – 类似于系统的流程图,区别于流程图的是,可通过不同角色之间的权限显示出各个角色的功能;活动图主要学习基本活动图泳道活动图
状态图 – 实体(对象)再某个生命周期内通过某种操作(事件/动作),达到某种状态的改变和转移,就是实体的状态图。

统一建模语言(英语:Unified Modeling Language,缩写UML),通俗的讲,就是将现实中所有的实体(对象)、关系、活动、状态、复杂的处理逻辑等,抽象后用模型的方式表现出来,建立一个更好解决问题的办法。

UML模型,通过模型,映射出现实中固定领域或对象问题的解决办法、方案。

UML是一种模型语言,UML图是模型的一种表达形式。其作用域不局限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

UML语言中主要的三种模型:
功能模型:从用户的角度展示系统的功能,包括用例图;
对象模型:采用对象,属性,操作,关联等概念展示系统的结构和基础,包括类别图、对图;
动态模型:展现系统的内部行为。包括序列图,活动图,状态图;

使用UML模型的作用和好处:
1,为用户提供现成的、有表现力的可视化建模语言,以便他们开发和交换有意义的模型。
2, 为核心概念提供可扩展性 (Extensibility) 和特殊化 (Specialization) 机制。
3,独立于特定的编程语言和开发过程。
4,为了解建模语言提供一个正式的基础。
5,鼓励面向对象工具市场的发展。
6,支持更高层次的开发概念,如协作,框架,模式和组件。
7,整合最佳的工作方法 (Best Practices)。

  • 表达和阐述系统的结构或行为;
  • 让系统设计图像化;
  • 提供构建系统的模板;
  • 有助于理解复杂系统;
  • 记录你所做的决定;

为什么要为事务进行UML模型?
1,将事务的模型提取出来,显性化,让不同的人对业务的理解达成一致;要归类复用,避免重复的工作,让不同的参与人员能够关注到系统/规划的各个流程。
2,最终其实是为了让系统(产品)简化、扩展度强、复用性强、灵活度、与组织(实体)的对应度密切或接近;

业务领域建模的设计步骤
领域模型设计是需求分析的关键步骤。它帮助用户及需求分析人员建立业务概念,确定用户业务的问题域,系统涉及的业务范围等等。  
1. 从业务描述中提取名词;  
2. 从提取出来的名词中总结业务实体,区分名词中的属性、角色、实体、实例,形成问题域中操作实体的集合;  
3. 从业务实体集合中抽象业务模型,建立问题域的概念;  
4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系;

UML图:
1,用例图:
很多产品经理应该站在用户的角度,去分析用户想要做什么,有什么痛点;
用例图组成:
(1),参与者 – 主动使用者;
(2),用例(使用案例,usecase)- 要做什么;
(3),关联 – (包含/依赖include,继承extend,泛化generalization);
(4),系统边界 – 类似于MVP,首先要确定项目的核心,不要将系统边界扩大化;

可将用例图看成一句话,主、谓、宾,例如,学生们要查阅书籍,那么其中参与者就是学生,用例就是查阅书籍,将学生对象和用例模型关联起来,就是使用案例;

用例和用例之间也有几种关系:
(1),泛化关系,类似于继承,用例继承另外一个用户/参与者继承另外一个参与者;
(2),包含关系,例如【手机银行转账】和【用户身份验证】之间,就是包含关系,因为每次转账的时候,必须得验证身份,如果不进行身份验证,那么就无法完成转账;
(3),扩展关系,例如【系统手机号登录】和【email登录】之间,是扩展关系,如果不用手机号登录,亦可以用email登录,相互没有制约关系;

用例图和用例描述合称用例建模。
用例描述:

概要,用几行字描述用例的作用和目的;
场景(脚本),描述一个用例在某种条件下的具体执行流程,分为基本场景和例外场景(异常情况下的场景);
事件流,描述用例在各种条件下的具体流程;

用例图需要注意的几点:
1,分析出几个角色,角色之间的关系(泛化);
2,分析出角色要做的事务,事务之间的关系是包含还是扩展;
3,事务(用例)之间要做到具有复用性、灵活性,扩展性;
4,画图时每种箭头的寓意不同,不能混淆,尽量简介易懂。

如下图所示,用例图:

//
//一份用例描述的例子
  用例名称:网站公告发布 
  用例标识号:202 
   参与者:负责人 
  简要说明:
  负责人用来填写和修改家教网站首页的公告,公告最终显示在家教网站的 首页上。 
  前置条件:
  负责人已经登陆家教网站管理系统 
  基本事件流:
   1. 负责人鼠标点击“修改公告”按钮
  2. 系统出现一个文本框,显示着原来的公告内容
  3. 负责人可以在文本框上修改公告,也可以完全删除,重新写新的公告
  4. 负责人编辑完文本框,按“提交”按钮,首页公告就被修改
   5. 用例终止 
  其他事件流A1:
  在按“提交”按钮之前,负责人随时可以按“返回”按钮,文本框 的任何修改内容都不会影响网站首页的公告 
  异常事件流:
  1. 提示错误信息,负责人确认
   2. 返回到管理系统主页面 
  后置条件:
  网站首页的公告信息被修改 
   注释:无
//
//

2,活动图,

用来表现业务流程,表现用例图中某个用例的业务的详细事件流,表现一个用例到底涉及到哪些对象,使用了哪些消息。

备注,产品业务流程图,可以通过UML中的活动图进行替代;

活动图参考:
https://blog.csdn.net/m0_70819559/article/details/127086569

如下图所示,活动图(泳道) :

延伸到领域模型:

领域模型,是UML模型其中的一种模型。

领域模型是一种分析模型,用于分析理解复杂业务领域问题,具体到软件开发过程中就是在分析阶段分析如何满足系统功能性需求。

是一种综合分析与设计一体的模型,注重系统设计与需求分析、系统需求的衔接,设计出系统与需求有较好的一致性,针对合理的需求变化也更具有良好的扩展性。

领域模型,其实就是需求的一种量化过程所得到的产物。

重点:https://www.zhihu.com/question/25089273

领域模型

参考:https://www.jianshu.com/p/fe45506ea358

延展:

绘制产品流程图的六个步骤:
1、定义角色,明确在整个流程中,都有哪些人,或哪些系统会参与。
以电商为例,按参与人分,可以是:
前台:消费者、卖家、平台客服
后台:卖家、代理商、供货商、库管、物流人员、财务人员
按参与系统分,可以是:
前台:电商网站、账户中心、支付系统
后台:商品管理系统、订单系统、客户关系管理系统、客服系统、工单系统、供应链系统、财务系统、物流管理系统、库存管理系统等等。
一般来说,人和系统角色,都会出现在流程图中,当多个角色同时出现,需要选用跨系统的泳道图来绘制,以清晰描述角色和角色之间的业务出发流转关系。

2,定义实体,实体,就是各角色在系统中执行任务的承载物,通常是线下流程实物在线上的虚拟替代。比如消费者购买的“商品”,购买时产生的“订单”,客服处理的“工单”,财务处理的“发票”,物流处理的“运输单”、库存处理的“货架位置”等。我们课程中“实体概念定义表”就是用来描述实体的。

3,定义实体状态,角色在执行任务时产生的实体,会根据不同条件,产生不同状态。如“订单”这个实体,就会有“待支付、已支付、已发货、已收获、申请退款、已退款、已完成”等状态;“工单”实体,会有“待指派、已指派、已处理、无需处理、已完成、已关闭”等状态。需要产品经理根据不断和业务方沟通,把可能场景下的状态都穷尽罗列出来。找到这些实体状态,你就可以顺利产出状态流图了。

4,定义行为。指角色在业务流中需要执行的操作,比如对于客户,有:放入购物车、下单、支付、收货、评价等;对于卖家,有:采购商品、录入商品、上架商品、确认订单、取消订单、发货、退货等,不同行为,会对不同实体产生不同状态的变更。

5,定义分支条件。所谓分支条件,就是指角色在执行操作,产生行为时,由于进行了不同条件的选择,而触发的实体状态的变更。比如客户在下单后,如果执行了“取消订单”行为条件,订单状态就会变更为“已取消”,如果执行了“支付”行为条件,订单状态就会变为“待支付”;进一步,如果条件为“支付成功”,订单状态变为“已支付”,如果条件为“失败”,订单状态仍旧是“待支付”;再进一步,如果条件为“支付超时”,订单状态就变为“已取消”。

6,绘制流程。把每个角色,每个行为,在不同分支条件下,产生的实体,及实体状态,全部绘制出来,用线连接起来,就是一套完整的流程图了。

UML一些核心点记录:
1,include(包含/依赖)关键字:

指用例和用例之间的关系是包含关系,例如A —include — B,表示A用例包含了B用例,且在执行A用例时,必须先(要)执行B用例。
被包含的用例通常是一个辅助性的、可重复使用的用例,它被包含用例调用以完成特定的操作。
2,Composition(包含)关键字:
指一种包含和被包含状态,指实体和实体之间的状态关系,某一个实体是另外一个实体的一部分,例如发动机是汽车的一部分。通常表示实体(类)之间的包含状态;
例如:A对象是汽车,B对象是发动机引擎,那么A里边就包含了B,也就说是A类中有一个属性B,代表汽车的发动机。
3,extend(扩展)关键字:
表示一个用例在执行的过程中可以选择性地扩展另一个用例。被扩展的用例通常是主要用例的可选或条件性行为。
例如:
[1],有一个用例 A ,代表在线支付,另一个用例 B 代表使用优惠券,支付用例可能在执行过程中选择性地扩展使用优惠券用例。
[2],用一个用例A代表账号密码登录,用例B为google login,用例C为手机号登录,那么B和C就是用例A的扩展用例,表示为下图0-3-1:
4,关键字generalization(泛化/继承):
用于表示类之间的继承关系,其中一个类是另一个类的特殊形式。子类继承了父类的属性和方法,并且可能添加新的属性和方法。
如果有一个类 A 代表动物,另一个类 B 代表狗,那么狗是动物的一种,存在 generalization 关系,B继承于A。
示例,如下图0-3-2:

图:0-3-1(扩展)
图:0-3-2 (泛化)

Leave a Reply

Required fields are marked *