883 Part A 思维导图模板_ProcessOn思维导图、流程图

1

Intro System Analysis and Design

Infomation technology

Five elements in an information system: Hardware, Software, Data, Processes, People

SDLC

1. Identify the problem or need and obtain approval 2. Plan and monitor the project, i.e., what, how and who 3. Discover and understand the details of the problem or need 4. Design the system components that solve the problem 5. Build, test, and integrate system components 6. Complete system tests and then deploy the solution

System Analyst

General approach to problem solving

<ol><li>Research and understand the problem. 研究和了解问题</li><li>Verify that the benefits of solving the problem outweigh the costs. 验证解决该问题的好处是否大于成本。</li><li>Define the requirements for solving the problem. 定义解决问题的要求。</li><li>Develop a set of possible solutions(alternatives) 制定一套可能的解决方案（替代方案）</li><li>Decide which solution is best, and make a recommendation. 决定哪种解决方案是最好的，并提出建议。</li><li>Define the details of the chosen solution. 界定所选解决方案的细节。</li><li>Implement the solution. 实施解决方案。</li><li>Monitor to make sure that you obtain the desired results. 监测以确保你获得预期的结果。</li></ol>

分析师具备的知识和技巧

分析师相关职业

IT项目管理

Project、Job、exploration的区别

System Analysis and System Design 

项目属性 Project Attributes

<ol><li>has a unique purpose</li><li>is temporary</li><li>is developed using progressive elaboration</li><li>requires resources, often from various areas</li><li>should have a primary customer or sponsor</li><li>involves uncertainly</li></ol>

项目约束 Project constraints

scope

cost

time

• Quality • Resources • Risk

项目成功 Project Success

什么是项目管理?

<ul><li>the application of knowledge, skills, tools and techniques to project activities to meet project requirements</li><li>meet the triple constraint 使项目满足需求</li></ul>

Project Management Tools and Techniques

Project charter (integration)

Scope statement, and WBS (scope)

Gantt charts, network diagrams, critical path analysis (time)

Cost estimates and earned value management (cost)

Fishbone diagrams (quality)

项目管理员要具备的技能

2

SDLC example

6 core 

1. Identify the problem or need and obtain approval 识别总问题总需求并获批

系统愿景文档 system vision document

组成

Problem Description

System Capabilities

Business Benefits

作用: 描述了新系统的总体目标。它的目的是提供有关需求和解决方法的基本信息，以帮助客户决定是否批准一个开发项目。

干什么活?

1.根据实际问题,确定待开发系统的总目标,总功能

2.描述系统能解决的问题,带来的利益,从而获得批准

总结:实际问题→系统要实现的总功能→系统带来的利益→获得批准

2. Plan and monitor the project, i.e., what, how and who  计划和监测项目，即什么、如何和谁？

Work Breakdown Structure       ↓ Work Sequence Draft

List of tasks and estimated effort

Work Sequence Draft: 将WBS中的任务按依赖关系排序

干什么活?

1. 确定项目的所有子系统(组件)

2.决定第一轮要完成的子系统                 ...

步骤

1.识别此次循环完成的子系统包含哪些任务 → Work Breakdown Structure

2. 按依赖关系排序这些任务,完成进度表 → Work Sequence Draft

3 识别子系统需要的资源,并为每个任务分配人

总结:总功能(core 1)→所有子系统→总的WBS→总的WSD(Work Sequence Draft)→此轮循环要完成的子系统的WBS和WSD

3. Discover and understand the details of the problem or need 发现并理解问题或需求的细节

干什么活?

Do preliminary fact-finding to understand requirements  Develop a preliminary list of use cases and a use case diagram Develop a preliminary list of Domain classes and a Domian class diagram

Do in-depth fact-finding to understand requirements 做深入的事实调查以了解需求 Understand and document the detailed workflow of each use case 理解并记录每个用例的详细工作流程 Define the user experience with sketches of screens and reports needed for each use case. 用每个用例所需的屏幕和报告的草图来定义用户体验。 Build a Use Case Diagram for one subsystem Build an Activity Diagram (Workflow) for each use case Draft a Screen Layout for each use case (User Interface)

1.收集信息

Various techniques: Interviewing key users,  observing work processes,  reviewing documentation and existing systems, and even researching other solutions.

2从信息中提取需求并用UML初步描绘出来

Use case List →Use Case Diagram → Activity Diagram

Domain class List → Domain Class Diagram

Draft a Screen Layout原型

子系统架构图等各种图    ....

总结:收集信息,提取用户需求,用UML将需求即用例初步描绘出来

4. Design the system components that solve the problem 设计解决该问题的系统组件

实现数据库表(确定具体的字段类型) Design the database (schema)

设计系统架构配置图 Design an Architectural Configuration Diagram

确定具体用例接口,并实现接口 Design class diagram

干什么活?

总结:将Core3中的初步UML图具体化,并实现代码和创建数据库表

5. Build, test, and integrate system components 构建、测试和整合系统组件

干什么活?

总结:对core4的接口进行测试,整合成子系统

6. Complete system tests and then deploy the solution 完成系统测试，然后部署解决方案

干什么活?

总结:将所有子系统整合,测试,部署

第一次迭代回顾和下一次迭代（期中考试选择题考到过） This sample project was a 6-day iteration of small project

大多数项目都有更多的迭代 终端用户需要参与进来，特别是在第1、2、3和6天。 第4天和第5天同时涉及设计和编程。 第二次迭代将关注产品信息子系统 遵循与第一次迭代类似的开发过程

3

Investigating system Requirements[Core 3] 调查系统需求

步骤细分:

1.Gather detailed information

2.Define requirements

What are Requirements?

Functional requirements:   the activities the system must perform

Non-functional requirements:   Constraints and performance goals

FURPS Requirements Acronym

3.Prioritize requirements.

4.Develop user-interface dialogs

5.Evaluate requirements with users

Stakeholder

internal   VS   external

operational  VS  executive 操作人员       VS   高管

4

3.1information Gathering 收集信息

interview

问题类型

开放性问题 Open-ended questions

Closed-ended questions

questionaire

与采访有什么不同? 问卷更适合什么场景?

调查问卷 <ul><li>适合从可能在不同地点的大量利益相关者收集信息</li><li>通常用于为使用其他技术进行进一步研究获得初步见解</li><li>不适合学习过程、工作流或技术</li><li>开放式问题可能得不到回答</li></ul>

3.4Models and Modelling 选择模型并建模

什么是Model?

将从信息中提取的需求进行UML可视化描述

建立问题模型的好处/理由?

▪从建模过程中学习 ▪通过抽象降低复杂性 ▪记住所有细节 ▪与其他开发团队成员沟通 ▪与各种用户和利益相关者进行沟通 ▪为将来的维护/改进记录所做的工作

模型的分类?

Textual model– something written down, described

Mathematical models– formulas, statistics, algorithms

Graphical models– diagram, schematic

统一建模语言UML

Doucumenting Workflows 记录工作流

Activity Diagrams 活动图

制作活动图步骤?

•确定代理商以创建合适的泳道 •为泳道中的活动确定合适的椭圆 •用箭头连接椭圆 •必要时使用决策符号和同步条   ▪ 使用决策符号来表示非此即彼的情况——一条路径或另一条路径，但不能同时表示两者   ▪ 对平行路径使用同步条，即两条路径都采用的情况。包括开始和结束同步条

5

3.2识别提取需求(识别用例)

事件分解技术 Event Decomposition Technique 从系统响应请求的角度出发

特点:  更完善和全面

what?  通过识别系统必须响应的事件确定用例      对于每一个事件,命名一个动名词来描述系统在响应时做了什么

eg: 注册账户的整个过程就是一个事件,这个事件系统必须响应,可以将这个事件作为一个需求(用例)

事件的类型

外部事件 external event

时间事件 temporal event

状态/内部事件 state event

EBP

A most fundamental task in a **Elementary business process (EBP)** that is performed by one person in one place in response to a business event, adds measurable value, and leaves the system and its data in a stable and consistent state. 业务流程中最基本的任务，由一个人在一个地方对业务事件作出反应，增加可衡量的价值，并使系统及其数据处于稳定和一致的状态。

把use case分解去鉴别3种不同的event类别

•  Consider the external events in the system environment that require a response from the system, and identify and name the use cases 考虑系统环境中需要系统响应的外部事件，并识别和命名用例 •  Consider the temporal events that require a response from the system, identify and name the use cases | 考虑需要系统响应的时间性事件，识别并命名用例 •  Consider the state events that the system might respond to, and identify and name the use cases and then define the state changes  考虑系统可能响应的状态事件，并确定和命名用例，然后定义状态变化

事件与序列的先验条件和反应 Events VS  Sequence of Prior Conditions and Responses

事件是一个需求,要站在合适的角度去解读,太高就是系统,太低就是用例中的一个步骤

用户目标技术 User Goal Technique 从用户的目标角度出发

what?   通过确定系统完成哪些用户目标来确定用例

特点:  简单、高效

步骤

1.识别系统中所有的用户并将用户分类

2.采访用户, 询问他们希望系统可以为他们完成的任务

3.进一步探索,将任务提炼为用户目标

3.3定义功能需求

定义功能需求就是就是将识别的需求用规范的格式给出(这里的规范格式指的是"用户故事"和"用例")

用户故事 User Stroy

what? 用一句话描述用户为了达到某个目标而做的工作/操作

适合 Agile 开发

比UML图不正式,简陋

用户故事模版

验收标准 acceptance criterial

验收标准确定了任务完成时必须出现的特性

用例 Use Cases

what?   用例是系统执行活动,通常是对用户请求的响应

一般用动名词来命名一个用例, eg查找产品信息

用例模板: 一般用UML用例图和流程图来描绘

6

领域建模 Domain Modeling

问题域与事物 problem domain and Things

what? 问题域是开发的想系统所要解决的问题、满足的需求的对应的现实范围 Eg:如我要开发一个送货系统,现实中送货员取餐,选择路线,和交通工具,送餐给顾客(问题域).                                                                                                                          ↓ 这个问题领域涉及的事物包括店家,送货员,路线,顾客等所有的数据实体              (域对象)

系统分析过程中的"domain class" = 数据库设计过程中的"data entity"

从问题域中识别事物(域类/对象)的方法

问题领域 = 问题域 = Problem Domian 事物 = 问题领域类  = 数据实体 = 对象

头脑风暴技巧 BrainStorming Technique

How? 使用一份清单，列出通常找到的所有常见类型的事物，并用头脑风暴来确定每种类型的领域类别

名词技术 Noun Technique

How? <ul><li>识别出描述系统时出现的所有名词，并确定每个名词是否是我们需要记住的东西,并区分是一个领域类、还是一个类中的属性</li><li>识别出需要被存储在系统中的事物</li></ul>

领域类 Problem Domain Class

关联 Association <ul><li>类之间的自然而然发生的关系</li></ul>

多重性 Multiplicity

关联的类型

领域建模类图 Domain Modelling Class Diagram

领域类图细节

领域建模类图包含类的属性和类的关联关系

7

领域建模:复杂问题

关联类 Association class     在多对多关联关系中的中间类

泛化 VS 继承 Generalization/Specialization VS Inheritance <ul><li>泛化是指父类-子类这种层次结构</li><li>继承是指子类继承父类中的属性</li></ul>

抽象类 VS 具体类 Abstract class VS Concrete class

整体与部分关系 Whole Part Relationships

简要用例描述 Brief Use Case Description

8

用例建模Ⅱ Use Case Modelling

对象行为-状态机器图 Object Behavior – State Machine Diagram

状态机图中的要素: <ul><li>origin state(初始状态):一次transition中的开始状态</li><li>destination state(目标状态):一次transition中的结束状态</li><li>pseudostate(伪状态):最开始的状态,用●实心黑色圆圈表示</li><li>action-expression(动作表达式): 作为一次transition的一部分必须完成的一些活动</li><li>guard-condition(监守条件):一个true/false测试，用于查看转换是否可以触发</li></ul>

特别说明: <ul><li>状态机图用于描绘类对象在其生命周期过程中的状态转换和过度条件</li><li>状态一般用类的属性表示</li><li>不是所有类都有必要画状态机图,如上图中的打印机对象有关机状态(伪状态),等待状态,工作状态</li></ul>

状态机图中的并发路径 concurrent path

•并发路径通常由同步条显示(与活动图相同) •从一个状态衍生的多个状态是一个“or”条件 •从同步条衍生的多个状态是一个“and”条件

画状态机图的步骤: <ol><li>选择一个合适的有必要的领域类</li><li>列出生命周期中可能经历的状态和退出该状态的条件(transition-name)</li><li>画出初始图</li><li>看看所有没有并发路径</li><li>看看没有连线之间的状态所有存在转换</li><li>补充监守条件和动作表达式</li></ol>

用例描述 Use case description <ul><li>用例描述就是用来描述一个用例的处理细节的文本模型 </li></ul>

简要用例描述 Brief Use Case Description

What? 就是用一句话描述用例的主要步骤

用例图      就是用UML图图形化的展示用例与参与者(actor)之间的关系

完全开发的用例描述 Fully Developed Use Case Description

What? 用文字详细充分的描述一个用例的处理细节,步骤等,是记录用例最正式的方法

模版

用例UML活动图 UMLActivity Diagram for Use Case

系统顺序图 System Sequence Diagram (SSD)

What? 用于展示在用例或场景下消息在参与者与系统自动化部分之间的传递顺序

表示方法

循环Loop

* [测试条件] 返回值 := 接口名(参数列表)

* 表示Loop [测试条件] 只有测试条件为真才发送消息 := 是固定写法 接口名要求动名词

分支Alternative

用例和增删改查 Use Case and CRUD

9

Core4.系统设计基础I

系统分析:理解所开发的系统要满足什么需求的相关活动 系统设计:明确系统如何去满足需求的相关活动

系统分析创建需求模型,系统设计根据需求模型创建设计模型

SDLC中的与设计相关的活动

10

定义系统的体系结构

计算机网络LAN/WLAN/URL

协议

分布式架构

三层模型: <ul><li>View layer</li><li>Business logic layer</li><li>Data access layer</li></ul>

架构图 Architectural Diagrams

Location Diagrams

Network Diagrams

Deployment Diagrams

11

面对对象设计基础

分析模型→设计模型

介绍设计模型

设计类图 Design class diagram

顺序图 Sequence Diagram

交流图 Communication Diagram

Class-Responsibility- Collaboration (CRC) card

面对对象设计步骤

设计类 <ul><li>就是设计阶段有哪几种类</li><li>因为分析阶段只有问题域类(实体类)</li></ul>

Entity class

分析阶段从问题域中识别出来的类,由于设计阶段需要加入一些在计算机程序中用于辅助的类, 所以将问题域类在设计阶段称为实体类

Boundary class or view class

存在于系统自动化边界上的类，例如输入窗口表单或Web页面

Controller class

在边界类和实体类之间充当中介的类，充当视图层和域层之间的交换机

Data access class

用于从数据库检索数据和将数据发送到数据库

<<strereotype>> 用于表明这是设计阶段的哪种类

用于描述设计类的符号

可见性属性名:属性类型 = 初始化值 {属性特征?是不是主键}

"= 初始化值" 可以省略 "{key}" 可以省略

可见性方法名(参数列表): 返回值类型

从用例→最终设计类

开发首切设计类图 First-Cut Design Class Diagram

1.选定一个用例

2.拿到从这个用例识别出的领域类(实体类),这些类比较简陋,只有属性

3.详细描述属性(增加可见性,属性类型,是否有初始值,特性)

4.增加类与类之间的"导航可见性箭头" Navigation visibility arrows

开发CRC图,用于辅助设计"最终设计类"

开发最终设计类

12

部署新系统

core5:测试

core6:部署

<ul><li>Direct deployment</li><li>Parallel deployment</li><li>Phased deployment</li></ul>

SDLC

1.识别问题并获批

vision document

问题描述

功能

利益

2.计划项目,who,what,how  [确定系统架构/确定所有子系统,]

3.识别并理解问题和需求  [对此轮循环的子系统进行需求分析]

发现并理解子系统的问题和需求

1.收集信息

2.识别用例

3.定义用例并描绘

4.设计实现

5.测试

6.整合部署

A1提出SDLC   ↓ A2展开SDLC   ↓ A3展开SDLC Core3   ↓ A4细化Core3中的"1.收集信息(用户目标技术,事件分解技术)"和"4.对需求(用例)进行UML描绘"   ↓ A5细化Core3中的"2.识别用例(从收集的信息中提取需求)"和"3.对需求进行定义(以规范的格式地给出一个需求)"