STPE3013Process 设计 方法文档格式.docx
《STPE3013Process 设计 方法文档格式.docx》由会员分享，可在线阅读，更多相关《STPE3013Process 设计 方法文档格式.docx（24页珍藏版）》请在冰豆网上搜索。
-过程层次图中不可以出现相同的功能及过程。
-从上级功能分解出的所有子功能带有上级功能的特性。
-不是单元过程时就会分解成2个以上的过程。
-单元过程必须对数据的进行CRUD（Create,Read,Update,Delete）中的一个。
3.过程明细（ProcessSpecification）
3.1.意义及目的
过程明细是在最终节点中出现的对数据流图的Process来说明把输入数据加工成输出数据的过程。
过程明细和跟数据字典一起补充数据流图的制作，从而使过程分析更具有准确性。
为此一贯性的定义数据流图，数据字典，过程明细。
（1）种类
制作过程明细的方法是根据不同过程的特性或水准来使用。
一般来说上级水准的过程以叙述的形式制作，下级水准的过程是为了更准确，更明确的记述过程，使用结构图化记述（StructuredDescription）形式。
制作过程明细书的方法如下.
3.2.结构化语言（StructuredLanguage）
结构化语言是以简单的单词制作指令或算术式来表示简单结构。
这里说的要使用的简单的单词是在数据字典中定义的数据名称或添加必要的数据。
这方式类似于结构化设计语言的编写结构（顺序,分支,循环）.
例）
IF职位>
2
THEN工资=基本工资+（基本工资*0.25）
ELSE工资=基本工资+实际OT
ENDIF
DOCASE
CASE职位=10
补助金=200,000
CASE职位=9
补助金=100,000
ENDCASE
REPEAT
总工作时间=总工作时间+加班时间
ENDIF到月变化为止
3.3.决策树（DecisionTree）
决策树中表示各种条件与活动树结构。
这个方法是根据过程的复杂输出信息的决策而不同，也就是说具有不同的输入信息时使用。
因为用结构化语言描述过多的过程时会出现混淆现象。
通过以下的例子右边的节点表示条件右边的节点表示活动结果,节点连接线是表示根据条件的分歧。
例）예금기간별이자율（按存款期间的利率）
3.4.决策表（DecisionTable）
跟决策树一样对复杂的决策判选择时使用.决策表左侧中记述输入资料或条件在下面记述活动。
还有表述决策表的右端的根据条件的规则。
制作决策表的步骤如下。
1掌握所有条件。
2组和条件后计算有可能发生的CASE数。
3决策表的左侧记述条件，在右侧以数字方式表示CASE数。
4决策表的底部记述有可能发生的所有活动结果。
5组合在表中的各种条件根据规则表述‘Y’或“N’。
6根据各种条件中组合（规则编号），给决定的相应的活动表示’Y’。
7检查决策表确认是否有错误的地方。
例）存款期间/按金额的利率
3.5.
构造海图（StructureChart）
顺序（Sequence）,选择（Selection）,循环（Iteration）3种基本逻辑结构来组成，3个基本逻辑结构是必须带有一个入口和一个出口。
这方式是把逻辑流以Top-Down的方式进行模型化设计，可以在开发后减少维修也使各模块儿的功能更容易理解。
主要在单元过程明细书上使用。
例）
3.6.NS海图
与构造海图具有相同的长处使用流程顺序，但不需要过程流走向标记。
也是以IfThenElse的控制结构和DoWhile与DoUntil等的循环结构来表述。
4.过程依赖图（ProcessDependencyDiagram）
4.1.意义及目的
过程依赖图是表述业务功能（BusinessFunction）内部各种过程的关系。
即对在业务功能上通过被事件响应的过程间的顺序（Sequence）与依赖性（Dependency）进行分析,是一种可让用户更容易理解也是更易于反馈的方式。
过程依赖图使用于输入实体模型与功能体系（FunctionHierarchy）。
可使在此过程中充分的理解业务功能也可改善实体模型及功能体系。
制作过程依赖图有以下优点。
-可以业务为主的分析方法来可跟用户进行沟通。
-可对功能体系（FunctionHierarchy）进行完整性检验。
-기可增进对以定义的业务功能的理解。
-定义相关与业务的主要事件,过程,结果（Result）。
-改善实体模型。
过程依赖图是以过程（Process）,事件（Event）,依赖性（Dependency）,结果（Result）,ProcessBreak要素组成,要素的特点如下
4.2.过程（Process）
过程是为了使输入的数据得到预想的结果而执行的数据处理过程,反映一个以上的事件的同时创出符合的业务目的结果。
过程依赖图上表示的Process的特征如下。
-有些过程是通过外部事件的引发而启动,这样的事件提供启动过程的输入或状态。
过程的执行结果可能引发外部事件或持续后续事件。
-记述对所有Process名字与目的,这可使相关事件和过程更加易于分析.
-所有过程至少有一个以上的结果。
之后具有选择性的结果时（OptionalResult）,检查是否带有必要性的别的方案。
Process标记是以方框表示,方框内容表示Process名称。
图1）Process依赖图中的Process
4.3.事件（Event）
事件引发过程的启动或在一次启动。
事件包括外部组织引发的外部事件（ExternalEvent）和在一定时间段内引发的计时事件（TimeEvent）。
事件是已以下规则标记。
-事件是以空心箭头标记,同时在空心中填写事件名。
-事件一项丛左方向留到右方向。
-事件一项连接Process，Process组或Processbreak。
图2）Process的依赖图上的事件。
4.4.依赖性（Dependency）
表示Process间的先行关系。
即使用箭头来标记相互关联的过程间执行顺序来把握先行Process与后续过程。
根据依赖类型标记方法多少会改变。
（参考依赖性类型）
그림3）Process的依赖图上的事件。
4.5.结果（Result）
结果是功能或过程结束时的系统状态或过程产生的结果物。
结果还分一下两种来区分。
-外部结果（ExternalResult）:
意味着超出业务范围的结果。
举例来说客户，交易所或传达到别的部门的信件，公文，产出物，收据等。
-内部结果（InternalResult）:
虽然Process范围在外部，但在业务范围内启动别的Process的带有事件性质的结果。
例如：
异常处理报告书,Archivetape,系统建模等。
结果中记述事件间的关系。
结果按以下规则来标记.
-结果是以大空心箭头标记,空心中填写结果名称。
-结果一项丛右到左的方向。
-结果是一项连接与产出结果的Process或Process组。
图4）Process依赖图结果
4.6.ProcessBreak
ProcessBreak是Process虽然已结束,但后续Process因各种原因无法启动时发生的。
即后续Process开始的状态或数据为完全准备或不适合Process的启动时发生。
标记ProcessBreak是充分考虑以下事项。
-ProcessBreak之后的Process一项等待别的事件发生后执行，在这时发生的事件是一准备好符合条件的数据或已接收到开始启动的时间点方面的消息。
-执行ProcessBreak后续过程中不满足必要的几个条件，所以不能进行时标记。
还有虽然满足所有条件，但不需要即刻执行的必要时不用标记。
实际上这不是日常一般情况也可能是人为发生的情况。
ProcessBreak根据以下规则来标记。
-ProcessBreak是以‘U’侧过来的方式标记,记述ProcessBreak名。
-ProcessBreak名是一般记述实体名。
图5）Process依赖图上的ProcessBreak
4.7.依赖性类型
（1）顺序依赖性（SequentialDependency）
标记两个过程之间必须的依赖性。
即AProcess执行后执行BProcess，.
图6）Process依赖图例题-顺序依赖性（SequentialDependency）
（2）选择依赖性（OptionalDependency）
标记两个过程间的选择性的依赖。
即AProcess执行后才能执行BProcess
图7）Process의존도예제-선택의존성（OptionalDependency）
（3）并行依赖性（ParallelDependency）
标记3个以上的过程즉AProcess执行后必须执行B或者CProcess，也就是说B与C.Process是以并行或顺次性的执行。
图8）Process依赖图例题-并行依赖性（ParallelDependency）
（4）相互排它依赖性（MutuallyExclusiveDependency）
标记3个以上Process间的（或事件）相互排它依赖。
即执行A之后只能执行B或CProcess中的一个Process。
图9）Process依赖图-相互排它依赖性（MutuallyExclusiveDependency）
（5）循环依赖性（IterativeDependency）
对现行Process反复执行后续Process。
即AProcess执行之后反复执行（Loop）BProcess。
为了表示循环/重复（Iteration）在出现Process的方框上部画线条后“当…型”或“直到…性”等可表示重复回数的内容。
图10）Process依赖图例题-循环依赖性（IterativeDependency）
Process依赖图例
图11）国内销售业务
5.过程模型向导
5.1.数据字典（DataDictionary）
（1）概要
数据字典（DataDictionary）是定义数据流图中记述的所有数据信息。
可以查找在数据流图中难以理解的语言或相应项目，也就是带有字典的性质。
事实上无数据字典的数据流图除了提供极少的信息以外没有别的意义。
数据字典和数据流图得一起存在。
（2）构成项目
数据字典是用来补全数据流信息的，所以必须仔细/明确地进行记述,记述如下事项。
Ø
数据的意义
数据的意义是给相应的系统说明适当，易于理解的用语,最好不要反复说明。
要是记述数据时对数据名称或意思反复说明时会让数据字典变得非常复杂。
数据结构项
记述构成数据的所有结构项目,这时具有较多的数据或结构项过于复杂时利用下向式分解方法来进行分解。
下项分解数据的步骤如下。
⏹结构项以一定的类型进行分组。
⏹给各组赋予带有意思的名称。
⏹定义对各组的结构项目。
同义词
使用者对相同的数据使用不通的名字或在分析阶段中因不同的分析家的命名所混淆时记述同义词。
定义同义词时事先对一个同义词记述相关的数据构成项。
例）控制细目=医疗保险费+报销费+缴纳金
*同义词:
控制事项*
（3）使用记号
标记法
含义
=
左侧与右侧相同。
例子）加班时间=每小时3,000元,月40小时限度。
+
构成要素间的AND关系。
例子）每月工资金额=基本工资+岗位工资。
{}
意味者重复.反复几次的数据项在{}内进行记述。
还有在{}的左侧记述最小重复数右侧记述最多重复数。
要是不记述反复次数默认为最小0最大无限。
例子）家族事项=2{家族名称+相关}10
[|]
意味着在[]中用“|”来分开的项目中选择一个。
例子）职位=[管理|生产|事务工作]
（）
（）中的数据项可以省略的意思。
例子）固定数=（家族数）+（资格数）
**
**中记述数据项的说明。
例子）风险数=20,000*从生产科通知*
5.2.数据流程图（DataFlowDiagram）
数据流图（DataFlowDiagram）是画出应用程序系统中业务数据的输入/输出关系的工具。
数据流图使分析师与用户之间更容易沟通，同时可以更加正确的掌握需求。
（2）构成要素
Process（Process）:
Process是加工输入数据后输出新数据的转换过程。
标记法为先画空心圆，然后在圆心内部填写名称，编号，在中心填写过程执行名称与或系统名称。
这时的Process的特性如下：
⏹在圆心中标记的过程名称里记述业务或过程行为者。
⏹过程中必须存在输入的数据。
无输入的数据时不能自动生成数据。
例子）
数据流（DataFlow）:
以模型化的形式表示数据的流向.
数据流的特性如下:
⏹以箭头标记数据的流动方向同时记述代表数据的（数据群）名称.
⏹数据流连接与过程间过程或过程与存储介质.
数据存储介质（DataStore）:
数据存储介质表现出不移动的数据集合.数据存储介质的特性如下:
⏹数据存储介质以两个并行的直线中填写存储介质的名称来表示。
⏹数据存储介质必须依靠数据的输入输出连接过程。
⏹数据存储介质可以用文件,软盘,文件装订，橱柜等所有可存储的形式来表示。
外部实体（ExternalEntity）:
外部实体是表现对相应应用程序系统发生的数据开始与结束。
特性如下：
⏹外部实体是依靠数据流来连接到过程。
⏹外部实体在内部可以是社员，部门，其他系统。
在外部可以是客户，交易所，外部机关，外部系统。
⏹外部实体是在ContextDiagram（DFDLevel0）与最高阶段的数据流图中记述。
（3）DFD阶段化
应用程序系统的规模大又复杂时以下向式的分解方式来表现数据流图。
数据流图以下向式的方式分解成如下阶段来表示。
ContextDiagram（DFDLevel0）
用要开发的系统和外部的关系来表现开发系统范围。
制作过程如下：
⏹设定要开发的系统范围来把相应的系统看成一个Process。
⏹要开发的系统和系统相关的外部环境以外部实体来表现。
⏹系统与外部环境间的接口来表示数据流（箭头）。
顶级阶段的数据流图（DFDLevel1）
把要开发的系统一眼能看清楚的形式表示的形态，表现开发范围内的功能与必要的子系统。
制作步骤如下：
⏹设定把要开发的系统的子系统的范围。
⏹把各子系统以一个Process来表示。
⏹表示子过程间的数据流。
中间阶段的数据流图（DFDLevel2,3...）
把最高阶段的数据流图中表示的子系统更加细分的方式来集成除了最高阶段数据数据流图与最低阶段的数据流图以外的数据流图的集合。
这时一个以上的Process分解成下阶段的数据流图。
最低阶段的数据流图（DFDLevelN）
不能再细分成子阶段的过程,表现上级阶段中没有表示出来的所有数据流与数据存储介质。
例子）DFD阶段
（3）DFD制作指南
制作数据流图时有着为了要维护数据流图的一致性与制作上的错误而必要的原则。
不遵守此规则时会导致数据流图的初期分析与上一个阶段的数据流图上的不一致性。
为了正确的制作遵守以下规则。
数据存储原则
通过什么样的Process来输出相应的数据时必须要输入相关的所有数据。
没有输入数据时数据不可能生成于Process自身内,Process是单纯加工输入数据的作用。
以下例子是为了输出控制细目而把输入数据进行积累，之后把增加输入数据流与输出数据流进行正确的转换。
最小数据输入原则
最小数据输入原则是什么样的输入数据通过Process加工成输出数据的过程中必须表现必要的数据流。
下面的例子中可以看出工资金额在此Process中不是必要的数据。
数据流图均衡原则
上级阶段的Process是相应子阶段的数据流图间有着相同的输入/输出数据流与数据存储介质。
下面的例子中DFDLevel1的ProcessA相关的输入数据流A与输出数据流B.C在DFDLevel2中标记为输入/输出数据流。
数据变换原则
在输入数据流中变换成输出数据流的形态有以下4种。
通过考虑这些可更容易掌握数据变换。
数据性质变换
数据性质变换是通过一定的公式与计算，编辑过程来输出完全更改的数据。
在下列图中可看出利润额度与目标达成率是通过Process来把输入的数据性质变换成输出数据（百分比形式）。
数据合成变换
数据合成是合成两个以上的输入数据来变换成输出数据或相反的把一个输入数据变换成连个以上的输出数据。
数据观点变化
数据观点变化是对输入数据以毫无变化的输出数据的方式。
只有把相同的数据用什么角度去看来取新名称。
下面例子是接受顾客卡来确认是否是新规客户的，在此数据是毫无变化的，只有名称改变了而已。
数据结构（构成）变化
数据结构的变化是输入数据与输出数据间具有相同的值，但通过数据的排列或样式来变更数据的结构形态的方式（列:
给用户的友好形态）。
6.原型（Prototyping）
6.1.意义及目的
原型是系统的全部或一部分快速构建起来后，跟用户确认/并检查，然后再进行修改的方法。
通过用户和开发人员原型可以把要开发的系统的构建方向变的更加具体。
6.2.原型种类
原型根据适用方法来分为3种，根据原形的目的或项目特性来适当的使用方法。
-Exploratoryprototyping
为了系统用户和经营层需求更加明确而适用的方法。
这方法在设计结束后便结束。
-Experimentalprototyping
重点放在符合特别的目的技术（知识）实现焦点中。
用户通过Pilot来明确需要什么样的技术（知识）与资源。
-Evolutionaryprototyping
反复执行系统设计，编码，用户检验,修改工作，直到系统完全开发为止的一种方法。
使用集成开发工具来设计，构建，快速开发作为目的。
6.3.连接方法（制作方法）
原型连接方法中根据分割方式分水平（Horizontal）连接方法与竖直（Horizontal）连接方法。
各连接方法如下.
-水平原型（Horizontalprototyping）
分解应用程序系统的各层面（用户接口,导航流,逻辑等）来一层一层进行开发。
此方法最长用，很适用于相互关联性较高的业务功能应用程序。
-垂直原型（Verticalprototyping）
构建应用程序系统的所用层,然后按功能类别开发的方法.即对分解成一定单位的业务功能构建从用户接口开始到数据连接。
这方法适用于独立性较强的业务功能组成的应用程序的开发。
下列图是以水平/垂直来分解的原形,表示用户接口，导航流等各应用程序软件层结构。
图1）水平（Vertical）and垂直（Horizontal）原型
6.4.原型生命周期（LifeCycle）
原形生命周期具有如下阶段的特征。
-执行以提案的对系统的分析及基本设计。
-构建原形。
通过集成开发工具来构建.
-检查原形。
原形需要用户的检查,需要修改时执行循环生命周期。
这过程是直到最终确认及审核。
-设计非原形部分（Non-prototype）。
使用结构图设计方法来设计非原形部分（Non-prototype）.非原形部分一般包含非常典型的Process或控制,监视,安全过程。
-要是完成系统构建/原形强化，非原形明细书为了最终系统的构建强化原形。
完成最终逻辑模型与数据字典。
-图2）Evolutionaryprototyping生命周期
6.5.原型优点
传统的开发方法是使用画与文件来开发者与用户间的较容易沟通的前提下使用。
即用户需求是在需求分析完全结束后定义的，同时假设以后不会出现其它变更要素时使用。
但这样的方法是难于反映在不断的经营环境中用户要新添加的需求。
原型如下形式表示不需要上述假设。
-项目参与者间的,特别是需要用户与开发者之间有效的沟通手段。
-软件开发的进化观点中原形式通过反复构建来修正，也急时提供对应用程序维护及技术（知识）信息。
原型效果如下.
-通过原形的循环过程可具体画要添加的或预想不到的需求。
-减少设计的不确实性来减少项目失败风险。
-用户和开发者间的确立直接反馈减少执行错误，缩短开发时间。
-初期原型阶段开始到连续进化其间通过不断的测试与评审来减少错误。
-提高对系统开发时的用户参与率。
-原型的开始效果是可加强用户与开发者之间的沟通效果。
6.6.风险要素
原型必须是根据共识的开发方法论来执行。
没有对原形系统的设计及标准的原形，会对最后的修改变得困难。
原形可发生地风险要素如下。
-迅速并容易设计想法代替好的结构化的设计想法。
-可提高用户的需
升级会员 