1. introduction to Systems Analysis and Design

1. introduction

시스템?

: 주어진 인풋을 가지고 프로세싱 과정을 거쳐 가치를 창출하고 사용자가 원하는 의미있는 아웃풋을 만드는 것

 

시스템 제작시 정형화된 제작과정이 필요한 이유?

1. 무작정 만든 프로젝트는 대부분 실패한다.

2. 시스템을 만드는 것은 직관적인 것이 아니다.

3. 프로젝트는 늦어지고, 예산초과되거나 계획보다 적은 기능만 만들어지는 경우가 존재한다.

 

System Analyst, 시스템분석가? :

가치를 창출하기 위한 시스템 설계하는 사람

비즈니스 프로세스를 반드시 이해해야하는 사람

특정 스킬들이 요구되는 사람

업무를 분석하고 목표를 설정하고 개선시키고 아이디어를 구현하기 위한 정보 시스템을 설계함.

 

2. SDLC : Systems Developemnt Life Cycle

SDLC : 시스템의 퀄리티를 높이는 것을 목표하는 4단계 순환구조 형태의 시스템개발 생애주기

planning(기획) : 프로젝트 계획

analysis(분석) : 소프트웨어 가치창출을 위해 어떤 기능을 넣을 것인지 요구사항분석하여 결정

design(디자인) : 시스템 개발 작업의 기반이되는 설계도면 작성

implementation(구현) : 설계도면을 가지고 실제로 시스템 제작

 

SDLC process

프로세스는 4 phases로 구성 : planning -> analysis -> design -> implementation

각각의 phase는 여러 steps들로 구성

각각의 phase는 산출물이 존재 : deliverables(산출물)

phases들은 순차적, 증가적(결과물이 증가), 반복적(수정,보완반복->퀄리티향상)으로 실행됨

 

Deliverables(산출물)

기획 : 시스템 요구서, 현실성 분석, 작업 계획 보고서

분석 : 시스템 제안서

디자인 : 시스템 설계도면

구현 : 실제 시스템 소스코드, 유지보수 계획

 

 

3. SDLC Phases

Planning phase

> 시스템 요구사항, 기술실행 가능성, 경제적 이익 실현성, 사회적 통용가능성등을 파악하여 작업계획을 구성하고,

이를 적절한 개발기간동안 현재의 인적자원 상황에 맞게 적절히 배분하는 계획단계이다.

project initiation

시스템 요구사항확인

feasibility analysis(실효분석) 실행

1. technical feasibility : 기술적으로 구현가능한가

2. economic feasibility : 소프트웨어를 만들었을 때 얼마나 이익을 가져올 것인가

3. organizatoinal feasibility : 소프트웨어가 사회적으로 통용가능한가

project management

workplan 작성

staff the project : 인적자원의 보유기술, 프로젝트 참여현황 파악

프로젝트 진행현황 파악

 

Analysis Phase : 가치창출을 위해 소프트웨어를 분석하고 어떤 기능을 넣을지 결정하는 단계

develop an analysis strategy : 분석전략 수립

model the current system : 현재 시스템 파악하여 추보완점파악

formulate the new system : 새로 추가할 기능 파악

2. gather the requirements : 사용자/개발자/관계자들의 요구사항수집

develop a system concept : 시스템 컨셉정의

create a business model to represent : 비즈니스모델 정의

3. develop a system proposal : 시스템 제안서(산출물) 작성

 

Design phase : 시스템개발작업의 기반이되는 설계도면 작성

develop a design strategy : 설계전략수립

design architecture and interfaces : 시스템의 구조와 인터페이스 설계

develop databases and file specifications : 데이터베이스 및 파일형식 개발

develop the program design to specify : 프로그램설계 명시

 

Implementation phase : 설계도면을 가지고 실제로 구현하는 단계

construct the system

- 구현

- 테스트

install system

- 사용자 교육

3. 유지보수

 

4. SDLC Methodologies

정의 : SDLC를 구현하기 위한 정형화된 방법론

- 시스템 목적, 특징에 따라 적합하게 사용할 수 있는 여러가지 방법론이 존재한다.

1. Process oriented : input을 받아 output을 만드는 작업, 소프트웨어의 모듈, 프로세스에 초점을 둔 방법론

2. Data centered : 어떻게 가공하여 의미있는 데이터를 만들지와 같은 데이터에 초점을 둔 방법론

3. Object-oriented : 객체지향개념(객체, 객체의 메서드, 객체간 상호작용 등)을 적용한 방법론

4. Structured development : SDLC의 phases와 각 phase의 steps들의 구조에 초점을 둔 방법론

5. Rapid actoin development : 빠른 개발 진행, 빠른 새 요구사항 대처등에 초점을 둔 방법론

 

Structured development

- Waterfall Development

- Parallel Development

 

Waterfall Development

- Planning -> Analysis -> Design -> Implementation 과정을 시간 순차적으로 진행하는 방법

- 전단계가 끝나고 다음단계로 넘어가면 다음단계에서 발견한 오류나 수정할 점을 전단계에 피드백하는 것이 아니라 해당단계에서 수정 보완을 해야 하는 특징이 있다.

장점 : 시스템 요구사항을 분명히 할 수 있다. 프로젝트 진행에서 요구사항의 변경이 최소화 된다

- 단점 : 디자인이 설계도면에 매우 세부적으로 명시되어야 한다. 시스템 제안부터 출시까지 긴 시간이 걸린다

 

Parallel Development

- Planning -> Analysis -> Design -> Implementation 과정 중 design 단계에서 여러 subproject들로 나뉘어 병렬적으로 프로젝트를 진행하고 각각의 subproject들의 implementation을 통합하는 방식

- 전단계가 끝나고 다음단계로 넘어가면 다음단계에서 발견한 오류나 수정할 점을 전단계에 피드백하는 것이 아니라 해당단계에서 수정 보완을 해야 하는 특징이 있다.

장점 : 스케줄시간이 감소된다. 재작업의 확률이 줄어든다

단점 : subproject들을 병합하는데 어려움이 있을 수 있다.

 

Rapid Action Development Methodology는

- 빨리 개발과정을 진행하여, 빠르게 시스템을 완성하는 것을 목표로하는 방법론으로 요구사항이 자주변하거나, 출시날짜가 임박한 경우에 주로 적용된다.

1. Phased Development Methodolgy

2. Prototyping

3. Thoroway Prototyping

 

Phased Development Methodolgy

기능의 우선순위를 매겨 코어 기능을 탑재된 시스템을 우선적으로 만들어서 낮은 버전으로 출시하는 방법론

낮은 버전 출시이후 받은 피드백은 다음버전에 반영하여,다음 버전은 좀 더 다양한 기능들이 탑재되고 이전버전의 결점이 보완된 상태로 출시된다.

장점 : user가 시스템을 빨리 이용가능. user의 추가적인 요구를 다음버전에 반영가능

단점 : user가 이용하는 시스템은 불완전한 시스템

 

Prototyping

시스템(완제품) 만들기전 시스템프로토타입(반제품, system의 코어기능은 탑재되어 있지만 UI가 완벽하게 구현되지 않은 소프트웨어)을 미리 만드는 방법론

- 프로토타입에서 부족한 부분은 피드백되어 수정 보완되고 이런 과정이 계속 반복되어 원하는 기능과 퀄리티가 만족되면 실제 시스템을 만든다.

장점 : user가 프로토타입을 빨리 사용해 볼 수 있어 상호작용을 빠르게 해볼 수 있다.
user가 필요한 변경사항을 확인하여 실제 요구사항을 제시할 수 있다

단점 : 초기 디자인의 퀄리티가 떨어질 수 있다.

 

Thoroway Prototyping

“디자인 프로토타입”을 만듬으로써 완벽한 설계도면을 만드는것을 목표로하여 완성된 디자인프로토타입으로

디자인을 하고 해당 디자인으로 시스템을 만드는 방법론

장점 : 시간적, 비용적,기술적등 리스크를 최소화. 실제 시스템이 만들어지기 전에, 중요한 이슈들을 미리 알수 있다.

 

적절한 방법론을 선택하는 기준

-> 사용자 요구사항을 분명히 함.

제작에 필요한 기술을 확보할 수 있는가?

시스템의 복잡도는 어떠한가?

시스템의 신뢰도는 얼마나 중요한가?

시간을 얼마나 주어졌는가?

스케쥴을 예측할 수 있는가?

 

5. the Systems Analyst

- 변화에 잘 적응하는 사람으로써, 유저들의 기술적 역량등을 향상시키기 위한 방법들을 분명히하고 소프트웨어를 사용하도록 권장하며 교육시킨다.

 

Systems Analyst skills

technical skills : 기술을 이해해야 한다

business : 비즈니스 프로세스를 알아야 한다

analytical : 문제해결을 할수있는 분석적 역량

communications : 상대방이 기술을 잘 알든 모르든 상관없이 잘 소통할 수 있는 커뮤니케이션 역량

interpersonal : 리더쉽과 관리능력

ethics : 윤리적역량

 

Systems Analyst 역활

Business analyst : 시스템이 어떻게 비즈니스 밸류를 창출할지 찾고 새로운 비즈니스 프로세스와 정책을 설계

Systems analyst : 어떻게 기술이 비즈니스 프로세스를 향상시킬수 있을지 파악. 새로운 비즈니스 프로세스를 설계

Infrastructure analyst : 시스템이 인프라 표준에 부합하도록 해야하며, 인프라변화가 있더라도 시스템이 잘 적응하도록 해야한다.

Change management analyst : 프로젝트 진행중 발생하는 변경사항들을 관리, 유저 훈련 계획 개발 및 집행

Project manager : 프로젝트를 총괄하여 관리하는 사람 (스케쥴 설정, 작업 분배)

 

6. Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design

- Object-Oriented System을 UML을 이용하여 분석하는 방법론

use-case를 분석 : 유저가 어떻게 시스템을 사용하는가

구조 분석 : 객체간의 상화관계 분석

반복적, 증가적 분석 : 데이터와 프로세스를 반복적으로 추가하여 더 많은 기능들이 제공됨

 

Object-Oriented Systems

클래스

object : 클래스의 instance

attribute :　클래스의 속성

state : 특정시간에 클래스가 가지고 있는 value, 관계

2. methode, message

methode : 클래스의 행동

message : 한 object에서 다른 object로 전달되는 정보

3. encapsulation

- encapsulation : 데이터와 프로세스를 결합

information hiding : 외부에서 클래스의 기능성이 보이지 않는다

4. inheritance

: 서브클래스는 슈퍼클래스의 데이터와 methode를 상속받을 수 있다.

 

7. Engineering workflows

business modeling

requirement

analysis

design

implementation

testing

deployment – 유지보수

 

8. UML : Unified Modeling Language

UML, Unified Modeling Language

시스템 개발 과정에서, 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어

총 14개의 다이어그램이 다음과 같이 2 그룹으로 나누어진다.

1. Structure diagrams : 소프트웨어의 구조를 중점적으로 나타냄 (6개)

2. Behavior diagrams : 소프트웨어의 행동을 중점적으로 나타냄 (8개)

 

Structure diagrams

시스템의 data와 staric realationships을 표현하는 다이어그램들로 다음과 같이 6개의 diagrams이 속한다

1. class : 객체 내부의 속성과 메서드를 정리하여 정의한 것

2. object : 클래스를 인스턴스화 한 것

3. package : 비슷한 object들의 그룹

4. deployment : 소프트웨어가 작동하는 환경

5. component : input을 받아 내부에서 프로세싱을 하고 output을 출력하는 모듈

6. composite structure : component들로 구성된 구조

 

Behavior diagrams

object들 사이의 dynamic relationships을 나타내는 다이어그램들로 다음과 같이 8개의 diagram이 속한다

1. activity : 어떤 object의 행동을 나타냄

2. sequence : 여러 object들의 연속적인 행동들을 나타냄

3. communication : object들간의 연결 관계를 나타냄

4. interaction overview : object들간의 action을 통한 데이터 송수신

5. timing : 순서, 시간적인 개념

6. behavior state machine : 하나의 object에서 내부상태에 따른 행동양상을 나타냄

7. protocol state machine : 여러 object들 사이의 상태에 따른 행동양상을 나타냄

8. use-case diagrams : 사용예제로 어떤 기능을 어떻게 사용하는 나타냄