Wanna be a thinker

■기획이란?
시장과 고객의 요구를 듣고, 이에 합당한 상품을 만들기 위해, 그 상품의 외관과 기능을 설계하는 것이다.

■웹사이트 구축 과정
1. 분석
    1. 요구사항 분석
        1. 실현 가능한 요구 사항인가?
            - 실현 가능한 것과 불가능한 것을 구분한다.
            - 실현 불가능한 것은, 고객을 설득해야 한다.
        2. 요구한 기능과 유사한 기능이 있는가?
            - 예전에 이미 개발했던 기능이면, 소스를 재활용하여 시간과 노력을 절약할 수 있다.
        3. 고객이 요구한 것보다 더 좋은 방법은 없는가?
            - 고객의 요구보다 좋은 것을 제안할 수 있어야 한다.
    2. 벤치마킹
        - 고객에게 제대로 된 요구 사항이 없을 경우, 타 사이트나 서비스를 참고하여 제안해야 한다.
        - 고객이 요구한 기능이 타 사이트나 서비스에서 어떻게 운영되고 있는지 보여줄 때 도움이 된다.
        1. 이용자층 분석
        2. 디자인, 레이아웃 분석
        3. 서비스 분석
        4. 마케팅 분석
        5. 종합 평가
            - 평가를 통해 도입할 것과 도입하지 않을 것을 구분하기 위해서이다.
    3. 기능, 정책 정의
        1. 기능 정의서 작성
            - 개발자가 구현해야 할 기능들을 한 눈에 볼 수 있도록 정리하기 위해서이다.
            - 개발에 소요되는 시간을 판단할 재료가 된다.
            - 화면 정의서를 작성할 때 참고하면, 필요한 화면과 그 화면에 필요한 기능을 정리하기 수월하다.
        2. 정책 정의서 작성
            - 예1) 회원 가입은 어떤 정보들을 받을 것인가.
            - 예2) 비회원 구매를 허용할 것인가.
            - 예3) 회원가입 시, 어떤 원칙에 따라 포인트를 제공할 것인가.
    4. 일정 산출
        1. 일정표 작성
            - 각 단계별 소요되는 시간과 필요한 경비를 산출하여, 고객과 상담하기 위해서이다.
2. 설계
    1. 사이트
        1. 사이트 구조 설계
            - 기능 정의서를 토대로 유사한 기능을 묶고, 기능 별 연계 관계를 따져 계층화하고, 경로를 설정하여 사이트 구조를 설계한다.
            - 고객의 의도에 맞게 활발한 느낌이나 차분한 느낌 등의 디자인 콘셉트를 정해야 한다.
        2. 사이트맵 작성
    2. 화면
        1. 화면 설계
        2. 화면 정의서 작성
        3. 디자인 시안 작성
3. 구현
    1. 디자인
    2. 퍼블리싱
    3. 개발
        1. 디자인 시안, 퍼블리싱 결과물 등 검토
            - 화면 정의서대로인가.
            - 고객의 의도대로인가.
    4. 테스트
        1. 테스트 시나리오 작성
            - 화면이 의도대로 작동하는지 확인한다.
    5. 웹사이트 오픈
        1. 모니터링
            - 개발 단계에서 문제가 없던 것이, 운영 단계에서 문제가 생기지는 않는지 확인한다.

1. 목적

역할의 분리를 통한 유지 보수 용이성, 개발 효율의 향상

2. 종류

1) MVC(Model, View, Controller)

2) MVP(Model, View, Presenter)

3) MVVM(Model, View, View Model)

2.1. MVC

2.1.1. 동작

(1) 사용자의 Action들은 Controller에 들어온다.

(2) Controller는 사용자의 Action을 확인, Model을 갱신한다.

(3) Controller는 Model을 나타내 줄 View를 선택한다.

(4) View는 Model을 이용하여 화면을 표시한다.

2.1.2. 특징

- Controller는 여러 개의 View를 선택할 수 있는 1:n 구조이다.

- Controller는 View를 선택할 뿐, 직접 갱신하지는 않는다.(View는 Controller를 알지 못한다.)

2.1.3. 장점

- 단순하여 보편적으로 많이 사용된다.

2.1.4. 단점

- View와 Model간 의존성이 높아 App 규모가 커짐에 따라 복잡해져서 유지 보수가 어려워 진다.

2.2. MVP

* Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해주는 부분으로

                 View와 Model을 붙여주는 접착제 역할이다.

2.2.1. 동작

(1) 사용자의 Action들은 View를 통해 들어온다.

(2) View는 데이터를 Presenter에 요청한다.

(3) Presenter는 Model에게 데이터를 요청한다.

(4) Model은 Presenter에게 요청받은 데이터를 응답한다.

(5) Presenter는 View에게 데이터를 응답한다.

(6) View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다.

2.2.2. 특징

- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 한다.

- Presenter와 View는 1:1 관계이다.

2.2.3. 장점

- Presenter를 통해서만 데이터를 전달받기 때문에 View와 Model간 의존성이 없다. (MVC 패턴의 단점을 해결)

2.2.4. 단점

- View와 Presenter 사이의 의존성이 높다.

- App이 복잡해질수록 View와 Presenter 사이의 의존성이 강해진다.

2.3. MVVM

* View Model : View를 표현하기 위해 만든 View를 위한 Model이자 View를

                     나타내기 위한 데이터 처리를 하는 부분이다.

2.3.1. 동작

(1) 사용자의 Action들은 View를 통해 들어온다.

(2) View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달한다.

(3) View Model은 Model에 데이터를 요청한다.

(4) Model은 View Model에게 요청 받은 데이터를 응답한다.

(5) View Model은 응답 받은 데이터를 가공하여 저장한다.

(6) View는 View Model과 Data Binding하여 화면을 나타낸다.

* View와 View Model은 데이터 바인딩 되어, View Model의 값이 변경될 시 View도 갱신된다.

2.3.2. 특징

- MVVM 패턴은 Command 패턴, Data Binding 패턴 두 가지를 사용하여 구현된다.

- Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성을 제거했다.

- View Model과 View는 1:n 관계이다.

2.3.3. 장점

- View와 Model 사이의 의존성이 없다.

- Command 패턴과 Data Binding 패턴 덕에 View와 View Model 사이의 의존성도 없다.

- 각 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있다.

2.3.4. 단점

- View Model의 설계가 쉽지 않다.

출처 : beomy.tistory.com/43