博客分类:
advance
2011年09月01日
UR(user requirement)：
针对Use Case 及 Use Case Description (但仅针对需求的描述及说明输入输出 及重要的stakeholder关系说明 限制条列等)
以 User goal Level 产出 SRS
SA(system analysis)：
针对UR 的 UC 及 UCD 进一步的延伸 包括流程的定义 例外的流程 及相关TEST PLAN 限制说明等
就我认为SA 应该补捉的是Dynamic 分析也就是行为面(behavioral)
透过 UC 及UCD 的修正、Sequence D、Activity D、StateChart D、Collabation D 当然是视需要来挑选Diagram 最好加入System Prototyping (UI、Flow等)
SA 要执行的层面是 What is ? 比UR 更深入的来看系统
SD(system design)：
以SA 产出的上述之Diagram 来进行 Static 分析也就是结构面（Structural）
利用 Class D、Object D、Component D、Deployment D 来Model 出物件关系及物件属性及方法等(当然是视需要来挑选Diagram )含DB Design
SD 要执行的层面是How to? 依SA 的需求来架构系统
注:
我个人一直觉得 DB Schema 的结构性分析或定义
往往都被提到该由SA 或SD 甚至是 SA 规划大致规格 SD 细部调整
但我后来读了许多文章与书后发现在UML Model 下 DB 的Design 根本不该出现
因为若是以DB Design 的角度来看系统设计 思维已被绑死在DB 的限制之上
而非跳脱到物件导向层次 但是当然最终还是会回归到DB (或 Storage)
只是是否如 UML 其它前辈先进所说
「当Static Model 被设计出来 你的DB Schema 也就设计出来了 系统也可以实作了？？」
我不否认我感到质疑 无论是方法结果或是Performance 等来说
我相信都很难被实现在现行的专案环境中
不过我自己认为最好的方法还是要有DB 的Design：
「SD Model Schema、Architect Review、DBA tuning Performance」
当然现实环境专案大小会影响到人员的配置与成本
应该可以做调整与fix
RA(Requirement Analyze)需求分析
>工作内容：
对使用者或 Key Man 进行访谈，以使用者角度了解并定义流程及需求，或针对现行作业中於资讯化过程中可能造成窒碍难行的方案进行流程转化与修正。
>角色特质：
沟通引导强、思绪条理优、脸皮耐心够。
>产出：
作业流程图 DFD、系统功能表Function List、系统雏型Prototyping（使用者介面需求）、使用者需求文件 URS、需求追溯 RTM。
SA(System Analyze)系统分析
>工作内容：
依 RA 所产出URS 文件及RFP、会议纪录等，转化为系统程式面需求，此时需评估使用者需求转化为系统后的可行性、合理性，若具有该专案或产业 Domain Know How 於系统需求面的描绘会更趋明确。
>角色特质：
沟通技巧棒、具技术 Sense、思绪逻辑强、撰文表达好。
>产出：
系统雏型Prototyping（整合客户流程及介面需求）、软体需求文件 SRS 、SIT 测试个案、需求追溯 RTM。
Use Case、Use Case Specification、Activity Diagram。
SD(System Design)系统设计
>工作内容：
由SA 产出之SRS及Prototyping 进行软体细部设计，针对开发程式语言的特性进行软体规格设计，除以完成系统功能为目的外，需考量系统的扩充弹性、可用性、可靠性、效能性、维护性等。
>角色特质：
技术能力强、组织能力好、工具应用佳。
>产出：
系统设计书SDD、Unit Test 测试个案、需求追溯 RTM。
Class Diagram、Sequence Diagram、Table Schema、ERD。
from http://wzl.idv.tw/index.php?title=ra_e_sa_c_amyaf_ eima&more=1&c=1&tb=1&pb=1
在这一行混一混也快四年了，程式写的越来越少，想的却越来越多，
但SD & SA的工作却都没试过，这得有些机运
目前手上的案子也是缺少这些文件的
只是现在看这个案子已经是个庞然大物
如果要针对这个庞然大物来做文件还真的不知道如何下手
而且我做出来的文件怎
advance
2011年09月01日
UR(user requirement)：
针对Use Case 及 Use Case Description (但仅针对需求的描述及说明输入输出 及重要的stakeholder关系说明 限制条列等)
以 User goal Level 产出 SRS
SA(system analysis)：
针对UR 的 UC 及 UCD 进一步的延伸 包括流程的定义 例外的流程 及相关TEST PLAN 限制说明等
就我认为SA 应该补捉的是Dynamic 分析也就是行为面(behavioral)
透过 UC 及UCD 的修正、Sequence D、Activity D、StateChart D、Collabation D 当然是视需要来挑选Diagram 最好加入System Prototyping (UI、Flow等)
SA 要执行的层面是 What is ? 比UR 更深入的来看系统
SD(system design)：
以SA 产出的上述之Diagram 来进行 Static 分析也就是结构面（Structural）
利用 Class D、Object D、Component D、Deployment D 来Model 出物件关系及物件属性及方法等(当然是视需要来挑选Diagram )含DB Design
SD 要执行的层面是How to? 依SA 的需求来架构系统
注:
我个人一直觉得 DB Schema 的结构性分析或定义
往往都被提到该由SA 或SD 甚至是 SA 规划大致规格 SD 细部调整
但我后来读了许多文章与书后发现在UML Model 下 DB 的Design 根本不该出现
因为若是以DB Design 的角度来看系统设计 思维已被绑死在DB 的限制之上
而非跳脱到物件导向层次 但是当然最终还是会回归到DB (或 Storage)
只是是否如 UML 其它前辈先进所说
「当Static Model 被设计出来 你的DB Schema 也就设计出来了 系统也可以实作了？？」
我不否认我感到质疑 无论是方法结果或是Performance 等来说
我相信都很难被实现在现行的专案环境中
不过我自己认为最好的方法还是要有DB 的Design：
「SD Model Schema、Architect Review、DBA tuning Performance」
当然现实环境专案大小会影响到人员的配置与成本
应该可以做调整与fix
RA(Requirement Analyze)需求分析
>工作内容：
对使用者或 Key Man 进行访谈，以使用者角度了解并定义流程及需求，或针对现行作业中於资讯化过程中可能造成窒碍难行的方案进行流程转化与修正。
>角色特质：
沟通引导强、思绪条理优、脸皮耐心够。
>产出：
作业流程图 DFD、系统功能表Function List、系统雏型Prototyping（使用者介面需求）、使用者需求文件 URS、需求追溯 RTM。
SA(System Analyze)系统分析
>工作内容：
依 RA 所产出URS 文件及RFP、会议纪录等，转化为系统程式面需求，此时需评估使用者需求转化为系统后的可行性、合理性，若具有该专案或产业 Domain Know How 於系统需求面的描绘会更趋明确。
>角色特质：
沟通技巧棒、具技术 Sense、思绪逻辑强、撰文表达好。
>产出：
系统雏型Prototyping（整合客户流程及介面需求）、软体需求文件 SRS 、SIT 测试个案、需求追溯 RTM。
Use Case、Use Case Specification、Activity Diagram。
SD(System Design)系统设计
>工作内容：
由SA 产出之SRS及Prototyping 进行软体细部设计，针对开发程式语言的特性进行软体规格设计，除以完成系统功能为目的外，需考量系统的扩充弹性、可用性、可靠性、效能性、维护性等。
>角色特质：
技术能力强、组织能力好、工具应用佳。
>产出：
系统设计书SDD、Unit Test 测试个案、需求追溯 RTM。
Class Diagram、Sequence Diagram、Table Schema、ERD。
from http://wzl.idv.tw/index.php?title=ra_e_sa_c_amyaf_ eima&more=1&c=1&tb=1&pb=1
在这一行混一混也快四年了，程式写的越来越少，想的却越来越多，
但SD & SA的工作却都没试过，这得有些机运
目前手上的案子也是缺少这些文件的
只是现在看这个案子已经是个庞然大物
如果要针对这个庞然大物来做文件还真的不知道如何下手
而且我做出来的文件怎
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
