Karzin Lab

Project.다원 Ensemble_개발(1)_DB 구축 및 TABLE 생성

오늘부터 개발 시작이니 진행한 부분 들고왔습니다.

오늘은 DB구축하고 TABLE 생성 및 관리용 사용자 추가 및 권한부여 하였습니다.

아까 변경된 공통코드의 ER Diagram과 Class Diagram 게시글 올리고나자마자

샤워하고 바로 DB작업 진행하다가 어디선가 벌레가 나타나는바람에 조금 늦어졌네요 ㅠㅠ;;;;; (벌레 싫어... 한 40분 날려먹었...)

DB 툴을 쓸까하다가 오늘은 귀찮아서 그냥 Console로 작업했습니다.

저는 그냥 Console이 편해서........ (어줍잖은 무료 툴 쓰느니 차라리...)

특히 저는 vim계열을 아직까지도 좋아해서 ㅋㅋㅋㅋㅋㅋㅋ

1. DB 구축

데이터베이스 명은 dawon_erp_ensemble로 만들었습니다.

2. TABLE 생성

 - common_code : 공통코드

 - employee : 사원 (임시)

 - equip_status : 장비 정보

 - equipment : 장비

 - file : 파일

 - project : 프로젝트 (임시)

3. 관리용 사용자 추가 (Back-End단에서 연결에 필요한 계정)

 - dawon

 - ensemble

 두개의 테스트 계정 추가. 일단은 테스트용으로 진행하고 추후 연동시 user는 변경될수도 있습니다~

솔직히 DB 구축하는거 어려운것도 아니거니와, table 생성하는거야 이미 설계 문서가 있는 만큼 많은 시간 들일 필요없이 금방 끝냈습니다.

단지 위에서 말한거처럼 벌레가... 으아!!!! (흐름 다 끊기고 ㅠㅠㅠ)

자취생에게는 벌레가 아무리 익숙하게 보여도 익숙하지가 않네요..ㅠㅠㅠ (이젠 어디서 '딱딱' 소리만 들려도 바로 천장부터 확인하는...)

특히 밤 늦게까지 불을 켜놓고 작업을 해서 그런지 딱정벌레(?)류가 자꾸 어디서 기어들어오네요.ㅠㅠㅠㅠㅠㅠㅠ

어쨌든 DB는 금방 마무리 되었고, 이제는 저번에 다운로드한 IDE(Eclipse)에 Spring 환경만 구축해주면 될 것 같네요!

 -> Spring 환경 구축 -> DB연동작업 -> 개발 시작 -> (프로토타입)테스트

이제 나머지는 위 순서로 진행하면 될 것 같고, 개발은 아마 설계자료가 있는 만큼 금방 마무리 되지 않을까 싶네요.

작업하며 참고한 설계 문서

 - Project.다원 Ensemble_설계(3)_장비관리 ER Diagram

 - Project.다원 Ensemble_설계(9)_장비관리 Class Diagram

 - Project.다원 Ensemble_설계(10)_공통코드 ER Diagram, Class Diagram

버전정보 (v1.0)

 - v1.0 2020.07.16 배포

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_설계(10)_공통코드-ER Diagram, Class Diagram

흠.. 어제 장비관리 Class Diagram을 올리면서 생각했지만,

공통코드 부분의 ER Diagram이 어떻게 설계가 되었는지 설명한적이 없는것 같더라구요. (장비관리 ER Diagram)

그래서 공통코드쪽만 설계가 어떻게 되었는지, 그리고 하루밖에 지나지도 않았지만, Class Diagram도 추가된 부분이 있어서 그 부분을 설명해볼까 합니다.

공통코드의 ER Diagram 및 Class Diagram(VO)

음.. Class Diagram이라해봤자 table에 맞춰 변경된 VO(Value Object)정도긴 하지만 조금 추가가 필요할 것 같아서 수정했습니다.

각 컬럼별로 설명을 하자면,

 - 코드 ID : 기본키로 잡았으며, 기본키니만큼 중복을 허용치 않습니다. 기존 size를 5로 잡았는데, 코드를 사용할 게시판의 종류에 따라서 이 키가 길어질 수 있어서 그냥 15로 늘렸습니다. (명쾌ㅋㅋㅋ)

 - 부모 코드 ID : 부모 코드 ID를 입력해줍니다. 코드가 어디에 소속이 되는지를 나타내기 위함입니다.

 - 코드 명 : 사용할 코드의 명칭입니다. 유저에게 보여지는 부분입니다.

 - 언어 ID : 외국어도 지원할 생각이기 때문에 들어갔습니다. 지금 생각으로는 한국어, 영어, 일본어는 지원예정입니다.

 - 사용 여부 : 이는 관리자의 판단으로 사용할 수 있는 부분입니다. 사용을 하지 않는 경우 값을 N(0)으로 변경하면 유저에게는 보여지지 않습니다.

 - 등록일자 : 등록한 날짜가 저장됩니다. 혹시 모를 상황(??)을 생각해서 등록자까지 관리하려했는데.. 괜히 일만 커질것같아 (귀찮아서... 원래 등록일자도 관리하지 않을려했...) 추가하지는 않았습니다. 등록자는 추후 필요하겠다 싶을 경우 넣을 예정입니다. (DB에서 컬럼 빼는건 문제가 되지만 추가하는 정도야 뭐...)

이해가 어려우신 경우 이미지의 좌측 하단 예시를 보시면 조금은 파악이 편할 수 있습니다.

버전정보 (v1.0)

 - v1.0 2020.07.15 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

[애드센스] 무효트래픽에 의한 광고게재 제한을 겪어보다.

흠.. 별건 아니었는데, 20년 7월 1일부터 시작해서 무효트래픽에 의한 광고게재 제한을 받았습니다. (7월의 시작부터!)

취미로 붙여본거고, 수익은 기대하지도 않다보니 큰 문제는 아니지만, 왜 이런 문제가 나는지는 참 궁금하더라구요.

그나저나 저는 광고게재 제한을 당한지도 모르고 '왜 광고가 안뜨지?' 하며 이것저것 눌러댔었어요;; (당황한 나머지 바로 위 경고창도 못보고 ㅋㅋ;;)

덕분에 블로그 관리할때는 몰랐는데 막상 제가 쓴 글을 보다보니 컨텐츠 내의 엄청난 광고가;;;;;;

(아마 안나오는 이유를 알아보겠다고 이것저것 테스트하면서 컨텐츠 내 광고게재를 누른것같아요 ㅋㅋ;;)

광고게재 제한 종료는 어제인 7월 14일로 2주간 광고게재 제한이 진행이 되었었습니다.

솔직히 제가 제 컨텐츠 확인은 해도 광고를 클릭하지는 않다보니;;;

뭔가 문제가 있을까 싶기도했지만, 그나마 큰 문제 없이 끝나서 다행이라면 다행이네요.

뭐 그 2주간 저의 무효트래픽을 막기위한 행동이라면.. 구글 애널리틱스에 예외IP 등록해준 정도? (저는 보통 기존에 작성한 제 컨텐츠 확인하면서 글을 쓰기 때문에 그런 문제였나 싶어서 등록해보았습니다.)

그리고, 그냥 평소처럼 꾸준히 게시글을 업로드한거 말고는 없었습니다.

(그냥 관심을 가지지 않...)

솔직히 뭐가 문제였는지는 아직도 잘 모르겠지만;; 뭐, 잘 해결되서 다행인 것 같습니다.

Project.다원 Ensemble_설계(9)_장비관리-Class Diagram

휴.. 밥먹고나서 샤워하고 부지런히 만들기시작해서 드디어 끝났습니다! (지금시각 1시 4분)

후반부로 갈수록 졸림이 심해져서;; 겨우겨우 참고 마무리했네요 ㅋㅋㅋ;

오늘은 개발전에 거의 마지막으로 Class Diagram을 작성하였습니다.

음.. Sequence Diagram도 작성을 하면 좋을 것 같은데.. 일단 개발진행하면서 작성을 할까 생각은 하고 있습니다.

아직 워낙 해야할일이 많아서 말이죠;;

설계문서가 일단은 마무리가 된 이상 데이터를 저장하기 위한 DB 구축, 개발 세팅(Spring설치 및 MVC모델 구축 등등) 아직 갈길이 멉니다 ㅋㅋㅋ..

추후 Class Diagram은 변경되는 내용이 많을 것 같아 Reverse Engineering을 통해 어느부분이 변경되었는지 비교해보고 오답을 비교(???)하는 시간을 가져볼까 합니다. (오답이라기보다는 왜 변경되었는지 등등)

Class Diagram은 잘만 설계가 되어있다면 개발자 입장에서는 개발할 시간을 엄청나게 줄여줍니다.

그만큼 설계가 어려운면이 이런 부분이 아닐까 싶네요.

문제는 개발자는 Class Diagram을 참조는 하되, 무조건적인 신뢰를 하면 안된다는 것입니다.

설계자도 사람이니만큼 분명 설계서상으로 개발을 진행하다보면 로직상 구현이 불가능할 수 있는 부분이 있을테니까요.

물론, 이런 설계를 자세하고 명확하게 하는 설계자의 설계문서는 신뢰성이 높아지게 되겠지만,

그런 신뢰의 부분은 아무래도 경험과 개개인의 생각의 다름에서 일어나는 문제가 많다보니 문서만을 참조하는 것 보다는 설계자와 개발자간의 커뮤니케이션이 지속적으로 이루어지면서 개발이 진행되어야합니다. 

아래는 이번에 설계된 Class Diagram입니다. 총 3개의 Class Daigram이 나왔습니다.

* Spring MVC 패턴을 기반으로 두고 설계를 진행했습니다.

장비관리 - Class Diagram (1/3)

하나씩 설명을 하겠습니다.

 - EquipmentRestController : 클래스명과 같이 장비관리의 RestController입니다. 여기서 EquipmentService를 통해 장비정보와 장비 상태 Mapper(EquipmentMapper, EquipStatMapper)에 접근을 하여 데이터를 가져오거나 입력합니다. (쉽게 설명하면 버튼의 Event들의 로직)

 - EquipmentController : 장비관리의 Controller입니다.

 - EquipmentService : 장비 관련 Mapper들에 접근하여 DB의 CRUD 작업을 요청합니다.

 - EquipmentMapper : 장비 정보 Mapper입니다. 직접적으로 DB와 연동되어 주로 장비 정보 관련 작업을 진행합니다.

 - EquipStatMapper : 장비 상태 Mapper입니다. 직접적으로 DB와 연동되어 주로 장비 상태 관련 작업을 진행합니다.

 - FileMapper : 파일 관리 Mapper입니다. 파일은 업로드시 서버스토리지에 저장이 되며, 파일명이나 저장위치등의 파일 정보만 DB에 저장이 됩니다. (FTP 방식) Mapper에서는 DB에 연동되어 CRUD만 작업합니다.

 - Callback 객체 : 이건 제가 자주사용하는 요청에 따른 결과 객체입니다. 보통의 데이터도 해당 Callback객체를 이용해 Wrapping하여 결과를 보여줄 예정입니다. (이는 지금은 크게 신경쓰지 않으셔도 될 것 같습니다. 이 부분은 제가 좀 더 커스텀을 하려고 하는데, 이유는 보안적인 요소를 좀 더 강화해볼까 합니다.)

장비관리 - Class Diagram (2/3)

 - MainController : 메인 페이지를 보여주기 위한 Controller입니다. 

 - CommonRestController : 모든 페이지에서 사용가능한 공통적 RestController입니다. 현재 Code, File을 Common형식으로 보고 있습니다.

 - CommonService : 공통적인 Mapper(CodeMapper, FileMapper)들에 접근하여 CRUD를 요청합니다.

 - FileMapper : 파일 관리 Mapper입니다. 파일은 업로드시 서버스토리지에 저장이 되며, 파일명이나 저장위치등의 파일 정보만 DB에 저장이 됩니다. (FTP 방식) Mapper에서는 DB에 연동되어 CRUD만 작업합니다.

 - CodeMapper : 코드 Mapper입니다. DB에 직접적으로 연동되어 코드의 CRUD를 작업합니다.

 - ProjectRestController : 프로젝트 정보를 가져오기 위한 RestController입니다. 여기서는 설계가 마무리되지 않았지만, 개발에 지장이 없도록 projectId및 projectNm을 가져올 수 있도록하여 테스트를 진행할 예정입니다.

 - EmployeeRestController : 사원 정보를 가져오기 위한 RestController입니다. ProjectRestController와 동일하게 userId와 userNm컬럼 정보만 가져와 개발에 지장이 없도록 할 예정입니다.

장비관리 - Class Diagram (3/3)

여기서는 VO(Value Object)의 Class Diagram을 보여줍니다. (해당 Class Diagram이 어렵게 느껴지신다면 이전에 제가 설계한 ER Diagram과 비교하면서 확인해보세요! 전혀 어렵지 않습니다!)

 - File : [파일], 파일테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - Code : [공통코드], 공통코드테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - EquipStatus : [상태 정보], 상태정보테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

 - Equipment : [장비 정보], 장비정보테이블의 컬럼을 담을 변수를 가지고 있으며, 각 변수의 getter/setter를 가지고있습니다.

1시 4분에 게시글쓰기 시작했는데 벌써 1시 53분이네요 ㅠㅠ;

이미지로 뜨고 올려놓고 설명을 적다보니 틀린부분이 몇몇 보여서 바로 수정하고 다시 업로드하고 그런 반복적인 작업이 있다보니 시간이 걸려버렸습니다. 아무래도 사람이 만들었다보니.. (심지어 졸면서.. 졸음설계?!)

별거 안한거같은데 벌써 정리된 설계문서(PPT)는 34장이네요;;;

이제부터는 본격적으로 개발에 들어가면 될 것 같습니다.

위에서 언급한것처럼 Sequence Diagram의 경우 개발을 진행하면서 작업을 해볼까합니다.

그리고 개발을 진행하면서 발생한 문제나 그 문제를 어떻게 해결했는지 등도 작성을 해볼까합니다.

오늘도 고생많으셨고, 항상 긴 글 읽어주시느라 감사할따름입니다.

편안한 밤 되시기를 바랍니다.

버전정보 (v1.0)

 - v1.0 2020.07.15 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

[Swift5] 특정 View만 화면 회전 (UINavigationController)

아까 공부하러 간다고 말씀을 드렸습니다만.. 오늘의 공부는 바로 iOS(Xcode-Swift)공부였습니다. ㅋㅋㅋ

iOS개발을 하다보면 가끔 특정 View에서만 화면을 회전해야하는 경우가 있습니다.

예를들어 가로->세로->가로로 하나의 화면을 세로로 보여야한다던가,

세로->가로->세로 등의 화면으로 보여줘야한다는 등 특정한 요구가 있는 경우가 있습니다.

그런 경우 코드로 어떻게 처리를 하는지를 알아보겠습니다.

특히 제가 사용하는 소스의 경우 UINavigationController가 적용된 UIViewController에서 강제적으로 화면을 회전시키는 소스입니다.

뭐, 다른 방법이 있을 수 있으나..(supportedInterfaceOrientations를 이용해 변경을 해보려했는데 잘 되지 않더군요. 저의 방법이 잘못된거일지도 모르겠지만, 대략적인 느낌은 전역으로 지정된 UINavigationController 혹은 제가 커스텀한 CustomUIViewController가 override된 supportedInterfaceOrientations를 무시하는 것 같았습니다.)

한동안 삽질을 하던 저는 이 방법을 통해 해결하였습니다.

(더 좋은 방법이 있다면 알려주시면 감사하겠습니다! 감사히 배우겠습니다!!)

우선 이 코드를 이해하기 위해서는 viewWillAppear 함수와 viewWillDisappear 함수에 대해 대강 이해하고 계셔야합니다.

이 함수들을 이해하기 위해서는 View Controller의 생명주기에 대해서 알고 계셔야 이해가 쉬운데요.

이 부분은 나중에 다시한번 다루도록 하겠습니다. (... 시간관계상)

간단히 말하면 viewWillAppear 함수와 viewWillDisappear 함수는 뷰의 생명주기에 있어 뷰가 나타날때, 뷰가 사라질때 사용(Override)하는 함수입니다. (짤막..)

네.. 지금은 뷰의 생명주기를 알려드리는 시간은 아니니 대강 그렇다는것만 이해하시면 그나마 이해하시는데 큰 문제는 없을겁니다.

바로 소스를 보시죠

화면을 시작할 때 회전시키기 (가로 회전 혹은 세로 회전)

override func viewWillAppear(_ animated: Bool) {

  // 화면 회전하기 (가로 회전)
  let orientation = UIInterfaceOrientation.landscapeRight.rawValue
  
  // 세로로 회전 (주석제거)
  // let orientation = UIInterfaceOrientation.portrait.rawValue

  UIDevice.current.setValue(orientation, forKey: "orientation")

  UINavigationController.attemptRotationToDeviceOrientation()

}

화면이 종료될 때 원상복귀시키기 (세로->가로->세로 혹은 가로->세로->가로)

override func viewWillDisappear(_ animated: Bool) {
  // 기존 세로에서 가로로 변경했었다면 다시 세로로 원상복구
  let orientation = UIInterfaceOrientation.portrait.rawValue

  // 기존 가로에서 세로로 변경했었다면 다시 가로로 원상복구 (주석제거)
  // let orientation = UIInterfaceOrientation.landscapeRight.rawValue
  
  UIDevice.current.setValue(orientation, forKey: "orientation")

  UINavigationController.attemptRotationToDeviceOrientation()

}

보시면 크게 어려운 건 없습니다.

세로모드 혹은 가로모드의 값을 orientation 변수에 담아서

UIDevice 클래스에 접근하여 Value, Key 형태로 저장해줍니다.

그리고 attemptRotationToDeviceOrientation함수에서 새로운 인터페이스 방향을 수동으로 적용해줍니다.

UIDevice - Use a UIDevice object to get information about the device such as assigned name, device model, and operating-system name and version.

대충 UIDevice 객체는 디바이스의 정보를 가져오는 용도로 사용할 수 있다는 모양입니다.

=> 그 정보로는 이름, 모델명, os 이름, 버전 등

출처 : developer.apple.com (https://developer.apple.com/documentation/uikit/uidevice)

다들 아시다시피 UINavigationController 클래스도 UIViewController를 상속하여 만들어진 클래스입니다.

그러다보니 UINavgiationController만의 함수가 아닌 상속되어진 UIViewController에도 있는것으로 보입니다.

단지 제 생각이지만, 제가 supportedInterfaceOrientations 함수를 사용함에 있어서 계속해서 실패한 까닭은 이러한 상속여부에 따라 UIViewController에서는 Override가 적용이 불가하지 않았나 싶네요. (쉽게말해 무시)

UINavigationController.attemptRotationToDeviceOrientation - If your view controller does this, when those conditions change, your app should call this class method. The system immediately attempts to rotate to the new orientation.

대충 ViewController에서 상태의 변경이 필요한 경우 해당 메소드를 부르면 사용자가 원하는 새로운 방향으로 즉각적으로 회전을 시도한다는 모양입니다.

출처 : developer.apple.com (https://developer.apple.com/documentation/uikit/uiviewcontroller/1621400-attemptrotationtodeviceorientati)

버전정보 (v1.0)

 - v1.0 2020.07.14 배포

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Karzin

abbeea@naver.com

프로젝트 개발 모형 : 폭포수 모델, 애자일 방법(XP방법론)

제가 작업하고 있는 개인 프로젝트(Project.다원 ERP) 개발모형은 거의 폭포수 모델을 베이스로 두고있다고 보셔도 될 것 같습니다.

흠.. 거의 반절 재미삼아 취미(???)로 만드는 프로젝트라서 다른분들이 보시기에는 많이 부족하겠지만, 시간이 괜찮으시다면 한번쯤 쭉 읽어보시는것도 괜찮을겁니다! (아마...?ㅠㅠ)

사실 고객도 저이고, 개발자도 저인 이상 어느정도 제 머릿속에 정립된 시스템은 바뀔일이 없다보니 거의 빠꾸는 없겠지요.. 다만, 개발하다가 막히는 부분이라던가, 문제가 생겨 바뀔수밖에 없는 부분에 대해서는 로직이 바뀔뿐이지 보이는 UX/UI상에는 크게 바뀌는 부분은 없을겁니다.

그렇다면 제가 베이스로 두는 개발모형 폭포수 모델은 무엇일까요?

제가 느끼는 특징은 이렇습니다.

 * 확고하게 정립된 프로젝트(계획, 분석, 설계가 고객에게는 확고하게 정리가 된 상태 - 이렇게 만들 것이다!) 

 - 앞에서부터 차례대로 나아가는 모델

 - 노빠꾸 모델

 - 프로젝트의 철저한 문서화 (앞으로 철저하게 하겠습니다..ㅠㅠ)

사실 이는 확고하게 정립된 프로젝트 즉, 제 자신이 생각하는 틀에서 벗어나지 않기 때문에 폭포수모델을 사용할 수 있었습니다.

뭐.. 확고하게 정립된 프로젝트라고해서 보통의 프로젝트에서 사용하지 않는건 아닙니다.

기본적으로 일반적인 프로젝트에서도 폭포수 모델은 많이 사용되기는 합니다.

고객과의 커뮤니케이션을 통해 미리 분석을 하고, 분석된 자료들을 토대로 설계를 확정지어버리는 것이죠.

설계까지 확정만 되었다면, 다음으로는 개발을 진행합니다. 개발이 마무리되면 이제 테스트를 하고 배포가 끝나고나면 유지보수가 마지막 단계이겠지요.

이걸 머릿속에 기억하시고 아래 이미지를 보시면 이해하기가 편합니다.

아래는 폭포수 모델의 구조입니다.

여기서 한가지! 개발자에게 있어 가장 행복한건 역시 잘 짜여진 설계 문서이겠죠. 확고한 프로젝트의 설계자료는 개발자에게 있어서 굉장한 도움입니다.

그도 그럴게 버튼에 입혀질 디자인이 바뀌더라도 그 디자인의 원본 Structure인 Button은 바뀌지 않으니까요!

이 부분을 설명하기 위해서는 당연하게도 설계가 되어 있겠지만, Wireframe이나 화면설계단에서는 이미 이것은 Button이라는게 확고하게 잡혀 있을 것입니다.

그렇기에 개발자 입장에서는 Button을 만들어놓고 그 위에 어떤 디자인을 입히든 문제가 되지 않는 다는거죠.

Button의 위치, 글자 혹은 이미지는 그대로지만, 그 아래 디자인을 입히는건 어쩌면 개발자에겐 어렵지 않은 일이 될겁니다. (물론 상황에 따라 이미지를 바꾸는게 어려운 상황이 있기도 합니다.)

하지만 문제는 여기서 일어납니다. 바로 설계문서가 바뀌어버리는 경우가 있습니다.

물론 이 설계문서가 바뀌는건 계획단계-분석단계-설계단계까지는 그나마 문제가 적을 수 있으나,

문제는 개발에 들어가서부터 문제가 하나 둘 터지기 시작됩니다.

예를 들어 개발자는 디자인(버튼의 스킨)을 바꾸는건 쉬울지는 몰라도, 설계문서의 UX나 화면설계서가 크게 바뀌는 경우 그 구조 차체를 새로 만들어야하는 문제가 생길 수 있습니다.

이는 결코 작은 문제가 아닙니다. 개발자는 변경된 설계로 인해 지금까지 쌓아 올린 모든걸 새로 쌓아올려야하는 위험한 도박이 될 수 있습니다.

이런 경우에는 폭포수모델과 조금 방식이 다른 애자일 방법론을 사용해야하는 경우가 있습니다.

애자일 방식의 하나인 XP(익스트림 프로그래밍)방법론처럼 개발자 개개인의 역량에 맡긴채로 고객과 계속 소통을 해가면서 진행을 해가는 방법입니다.

수시로 변경이 되어가는 고객의 요구사항을 맞춰가며 팀원과의 대화를 통해 문서보다는 어느정도 개발이 진행된 시스템을 먼저 보여주는 형식입니다. 여기서 개발이 진행된 시스템은 프로토타입이라고 봐도 문제가 없을정도의 퀄리티가 있는(높은) 시스템입니다.

쉽게 말하면 프로토타입을 마구 찍어내면서 고객에게 모두 보여고 또 고객이 원하는 요구사항에 맞추어 프로토타입을 변경해가며 완료되어가는 시스템을 보여주는 것이죠.

아래는 애자일 방식의 구조입니다.

그만큼 고객과 개발자간 서로의 커뮤니케이션이 가장 중요한 개발론이기도 합니다.

애자일 방식의 특징으로는

 - 중요한 커뮤니케이션

 - 요구사항의 변동에 유연하고 그만큼 빠른 대처가 가능

여기서 잠시 한가지! 애자일에 대한 예시를 생각해보다보니 좋은 예시가 떠올랐습니다.

그 좋은 예시로 설명을 든다면! 개인적으로는 가장 적합한 프로젝트로는 R&D가 적합하지 않나 싶습니다.

사실 R&D는 요구사항이 계속해서 바뀌는 프로젝트 중 하나입니다. 

진행을 하다보니 시스템의 구조가 틀어져버린다거나, 아무래도 새로운 요구가 들어가야한다던가 여러가지 이유로 계속해서 변동에 유연해져야하는 경우가 많이 발생하죠. 특히 연구가 진행이 되고 있는 상태라면 그 연구에 맞춰지기 위해 요구도 계속해서 변동하는게 R&D라고 생각하고 있습니다.

그렇기에 애자일방법론(XP방법론)을 사용해서 고객과의 끊임없는 커뮤니케이션을 통해 Prototype을 만들어내고 테스트함을 반복함으로써 고객에게 만족도가 높은 시스템에 가까워지는 방법이라고 생각합니다.

폭포수 모델 이야기를 꺼내다가 잠시동안 애자일 방법론을 이야기해봤지만, 저는 보통 두가지를 다 경험해가면서 진행을 하고 있습니다.

어떤때는 개발보다 분석과 설계를 통한 문서화를, 어떤때는 문서보다는 개발이 앞서서 진행이 되어 PM과 PL과 소통해가며 프로토타입을 최단시간으로 또 최상의 퀄리티를 내기위해 노력하기도 하죠.

다만 이런 방식을 택하기 위해서는 위에서 말한것처럼 계획을 철저히 지켜나가는 '노빠꾸' 폭포수 모델이 굉장히 좋아보일 수 있으나.. 제 생각으로는 어느정도 규모가 있는 프로젝트에서는 폭포수 모델이, 규모가 적고 투입되는 인원이 적어지는 프로젝트에서는 애자일 모델이 가장 적합하다고 생각합니다. (위에서 말했던 R&D와 같은 타입)

이유는 규모가 있는 프로젝트(투입인력이 많고 프로젝트가 큰 경우)의 경우 어느정도 규모가 있는 만큼 고객의 요구사항이 어느정도 정립이 되어 있다고 보여집니다. 그런 경우 철저한 계획을 수립하고 수립된 계획대로 요구에 맞춘 분석, 설계를 진행하여 알맞은 결과를 내어주는게 필요하다고 생각을 하고 있습니다.

반면 규모가 적은 프로젝트(투입인력이 적고 프로젝트가 상대적으로 작다 싶을때)의 경우 고객과 팀원간의 커뮤니케이션을 통해 정립이 덜 된 프로젝트를 눈치껏(?) 빠르게 만들어주는게 중요하다고 보여지기 때문입니다.

그만큼 애자일의 경우 (여기서는 XP방법론을 예시로 들어보겠지만), 고객 - (PM, PL) - 팀원들간의 커뮤니케이션이 제일 중요하게 부각이 되는게 그 이유중 하나입니다.

실제로 프로젝트 진행시에도 상황에 따라서(규모 혹은 요구사항 등) 폭포수나 XP방법론을 사용하고 있습니다.

위에서 적은 내용은 저의 생각일 뿐이고 어느 하나가 더 좋다고도 할 수 없는 방법론들이지만, 현재 자신의 팀원이 처한 상황에서 가장 효율좋은 방법을 찾아내는게 중요하지 않을까 싶습니다.

PM, PL분들 모두 고생많으시고 멋지십니다! 화이팅입니다! (갑자기???)

물론 개발자들도 말이죠!ㅎㅎㅎ

흠흠.. 그냥 제가 만드는 프로젝트는 폭포수 모델을 베이스로 두고 있고, 폭포수 모델은 이런겁니다! 라는걸 적으려했는데.. 또 길어졌네요. 항상 이럽니다ㅠㅠㅠ 뭔 말이 이렇게 많냐 싶으시겠네요.. ㅎㅎ... 그래서 그냥 적당히 끊었습니다. ( 사실 더 주저리주저리 적어 나갈순 있는데.. 다들 졸리실겁니다.. 그 마음 다 압니다ㅠㅠ 밥먹을시간만 되면 꼭 잠 다 깨다가도 교장선생님의 말씀이 이어지면 졸리는 그... 뭔가모를 그런 분위기.. 저도 다 경험해봤거든요 ㅋㅋㅋㅋㅋㅋㅋ)

오늘은 그냥 제가 사용중인 프로젝트의 개발 모형에 대해서 잠깐이나마(???) 설명하는 시간을 가졌습니다. 

물론 제가 틀린부분도 있을 겁니다. (아직 많이많이 부족해서..ㅠㅠ) 이런부분들은 지적해주시면 바로바로 공부해서 수정하도록 하겠습니다!

이제 슬슬 샤워하고 Class Diagram이나 작성해봐야겠네요 ㅋㅋㅋ

는 샤워하면서 아 일단 쓴거 그냥 다 쓸껄 아쉬워하면서 생각만하다가 나오자마자 에자일방식 구조랑 내용을 좀 추가해뒀습니다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이빨닦으면서도 이런거 생각하고 있는 나는....(절래절래)ㅋㅋㅋㅋㅋㅋㅋㅋ

+ 음.. 생각해보니 내일 오전부터 중요한 회의가 있었네요. 오늘은 Class Diagram보다는 내일 오전에 있을 회의에 졸지 않기 위해 일찍 공부하고 마무리해서 조금 일찍 취침을 해야겠군요! (변명이지만 이래서 프로젝트 WBS(일정관리)를 작성하지 않았습니다 ㅠㅠ 워낙 스케쥴에 변동이 많다보니...)

버전정보 (v1.2)

 - v1.0 2020.07.13 배포

 - v1.1 2020.07.13 애자일 방식 구조 및 내용 추가, 오타 수정

 - v1.2 2020.07.13 내용 수정

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(0)

사전준비

Class Diagram을 만들기 전에 사전작업으로 개발을 위한 준비를 시작했습니다.

개발시 필요한 IDE 및 컴포넌트들을 다운받는 것이었는데, 생각보다 양이 많더라구요 ㅋㅋ;;

라이센스 관련 부분은 Project.다원ERP_개발 정보(개발언어, 장비, 예정내역)에도 올려놨으니 참고하시면 좋을 것 같습니다.

기존에 DB는 DBeaver에서 개발을 진행하려 했었는데, 요즘에는 Visual Studio Code에서 되는 듯 하더라구요. 테스트는 해봐야겠지만, 큰 문제가 없다면 Visual Studio Code에서 작업을 하려합니다.

여기서 팁아닌 팁인데, 개인적인 생각이지만 eclipse를 프로젝트별로 하나씩 나누어놓으면 편리합니다. 

eclipse를 전역으로 사용하면 프로젝트에 따라서 설정을 변경해줘야 하는 귀찮음이 있지만,

이렇게 나누어두면 프로젝트별로 설정을 따로 적용을 하고 또 프로젝트끼리 충돌 일어날 일도 거의 없다보니 저는 프로젝트별로 따로 사용중에 있습니다.

또 추후 USB등을 통해 파일을 움직여야할때라던가 굉장히 간편해요. 적용된 설정을 그대로 따른 복사물이 생기는거다보니 설정같은것도 기존에 되어있던 그대로 사용하게 되서 개발PC에서의 갭차이가 별로 나지를 않습니다.

말이 또 샜는데..ㅋㅋㅋㅋ

component 폴더 내부에는

 - bootstrap (4.5.0)

 - jquery (3.5.1)

 - Toast UI (각 컴포넌트 별 버전 상이)

가 들어있으며,

추후 테스트용으로 QRCode관련 js파일이 하나 생길것으로 보입니다.

현재 유력한 후보로는

http://jeromeetienne.github.io/jquery-qrcode/

MIT License라서 라이센스 문제도 크게 없어보이고, 사용하기도 어렵지는 않을 것으로 보입니다.

조금 아쉬운 부분으로는, 예전에는 Google Charts API쪽에서 지원을 했었으나 지금은 없어진 모양입니다. (아래 링크)

https://developers.google.com/chart/infographics/docs/qr_codes

Google에서 지원하는 만큼 어느정도 안정성은 확보되었을 것 같았는데.. 지원이 끝났다면 어쩔수 없죠.

MIT License의 qrcode 소스를 테스트해보고

문제없다 판단이 된다면 적용을 하는걸로 마무리하겠습니다.

이제 Class Diagram만 적당히 나와준다면 바로 개발에 들어가도 문제는 없겠네요.

단지 Diagram을 만드는게 손이 많이 갈뿐이라..ㅠㅠ

나 자신을 위해서라도 설계 문서를 만드는건 좋은일일텐데 손이 많이가는 만큼 여러모로 힘드네요 ㅠㅠ

다음엔 Class Diagram을 가지고 오겠습니다.

버전정보 (v1.0)

 - v1.0 2020.07.13 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 LikeKeyboard_개발내용

옛~~~날 학부시절 자료들을 찾아보니 만들어놓은 자료들이 꽤나 많아서 이것저것 찾아보다가!!!

원격 키보드 틀을 잡아 놓은 적이 있었더라구요.

분명 학부시절 (아마 방학때 였던듯)에도 만들려고 했는데 졸업작품이다 시험이다 여러모로 밀려서..ㅠㅠ

그러고보니 이름도 생각을 해놨었더라구요.(학부시절에 나는 시험말고 이런짓만 하고 있었던 것인가...)

아마 이름은 지금 보니 그냥저냥 나쁘지 않은 듯 하여 그대로 가볼까 합니다.

Project.다원 원격키보드 : LikeKeyboard (라키)

아마 이렇게 지은 이름은 키보드 같이! 라는 식으로 지은 것 같습니다 ㅋㅋ (맞는지는 그시절 나에게 물어야..)

이제야 생각나지만, 아마 이게 Project.다원의 가장 첫번째로 혼자 만든 기획-분석-설계-개발 시스템이었을겁니다. (미완성으로 끝났지만)

만든지도 오래됬고, 그때 이후로 컴퓨터 폴더 구석탱이에만 남아있었으니 (아마 학부시절 폴더들 쫙 까보면 별별거(혼자서 만든 기획, 분석, 설계, 개발 등등) 다 나올겁니다 ㅋㅋㅋㅋㅋ) 간만에 학부시절 아이템(?)들이나 구경해보자 한게 어쩌면 득이되었네요. 오늘도 이렇게 몇년전의 자신을 떠올리며 용기얻고갑니다 ㅋㅋㅋㅋㅋㅋ

말이 좀 옆으로 샜지만, 오늘은 많은 걸 다룰건 아니고,

예전버전 기획서를 조~끔 리메이크해서 다시 작성해봤습니다. ㅋ_ㅋ

리메이크 전과 후를 비교해가면서 보시죠. (정말 별 작업은 안했습니다. ㅋㅋ;;)

예전버전의 Project.다원 원격키보드 - LikeKeyboard

아마 이게 학부시절에 스타트 끊었던 Project.다원이었을겁니다.

학부시절이니까 지금으로부터.. 음... 4년전? 5년전? 쯤? 될겁니다. (상황에 따라 6년 전?)

그때부터 생각해뒀던건데.. 아마 위에서도 언급했다시피 편입하고 모든 과목을 전공으로 꽉 채워서 들어야만했고, 공부도 공부지만 2년 내에 졸업작품을 마무리해야한다는 사명감? 같은게 있어서 정신없어서 틈틈히 만든다는게 그때문에 아마 못했을겁니다.

이 기획서를 조금 잘 만져서 활용하자 싶어서 다시금 만질만질(???)해놨습니다.

웃긴건 누가 내 자신 아니랄까봐 그때도 나눔스퀘어Bold체를 사용했다는게... (소름)

새로운 버전의 기획서에 들어갈 LikeKeyboard

바뀐건 별거 없습니다.

'다' 라고 적혀있던 로고는 한글로 '다원'으로 변경이 되었고,

'Project Dawon'에서 'Project.다원'으로 변경되었습니다.

사실 '다원' 부분에 기존에 적혀있던 '다'라는 글자는 다원의 첫글자만 따서 넣어둔거였는데.. 너무 촌스러워서 (...)

Project Dawon의 경우에도 순 우리말로 했으니 그 의미와 본질을 생각해서 'Dawon'이 아닌 '다원'이 맞다고 생각해 변경했습니다.

그리고 중요한 #2

이건 Project.다원의 2번째 개발 시스템이라는 거죠.

원래는 #1인 이유가 학부시절 처음으로 개인 프로젝트를 만들었던거라.. (비공식, Private)

지금은 공식으로 게시글도 올리고, 이제는 #1으로는 ERP Ensemble이 있으니 #2로 변경하였습니다.

LikeKeyboard - 개발 내용 v1

흠.. 보면 아시겠지만 그때도 단색과, 미니멀리즘? 비스무래한 저만의 디자인을 고집했었습니다.

지금도 생각나지만 도대체 저런 PPT양식은 어디서 구해오니? 라고 교수님께 들었을때 제가 직접 만듭니다 라며 패기있게 말을 했었던 생각이 나네요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

(믿거나말거나 교수님도 굉장히 맘에 들어하셨습니다.)

특히 저는 글자크기를 최대한 키우는걸 좋아하는데, 이유는 의외로 프레젠테이션을 띄워놓으면 안보인다고 하시는 분들이 많아요. 그래서 글자를 최대한 키울 수 있도록 노력합니다.

옛날 이 디자인 그대로 갈까 하다가, 아무래도 정성도 있고하니까 바꾸자해서 바꿨습니다.

(예전의 나의 느낌과는 다른 느낌으로!)

** Computer과 Android 픽토그램은 오픈된 이미지 소스를 이용했었습니다. 다만, 해당 소소의 출처가 명확하게 파악이 되질않아 사각도형에 img label로 대처를 하였고, 아래 개발내용v2에서는 변경을 하였습니다.

LikeKeyboard - 개발 내용 v2

음.. 그냥 바꿨습니다 많이는 안바꾸고 뭐랄까 템플릿만 쪼오끔 바뀐정도?

자, 여기서 개발내용을 잠깐 설명하겠습니다.(갑자기?)

개발 내용을 자세히 보시면 Android폰이 서버 역할을, Computer이 클라이언트 역할을 하도록 잡혀있는데, 이는 오류가 아닌 제대로된 내용이 맞습니다.

왜 이렇게 했느냐? 학부시절의 저는 Android폰으로도 충분히 서버 역할이 가능하다 생각했었고,(지금의 폰성능을 보면 그이상도 가능하지않을까 싶네요) 그렇기에 실험적인 요소로 Android폰을 서버로 돌리려고 했었습니다.

뭐.. 그렇게 중요한건 아니지만, 아마 이 부분은 추후 Android폰에서 제어할 클라이언트들을 관리하려고 하지 않았을까 싶습니다.

그래서 실험적요소도 재밌고 뭔가 또 즐거운게 생길 것 같아서(??? 두근두근 ???????)

그대로 가기로 했습니다. (씬남!!)

** v1에서는 학부시절에 찾았던 오픈된 이미지를 사용했었으나, 해당 출처가 명확하지 않아 제거를 하고 변경했습니다. 

마지막으로 그시절 Project.다원의 로고

이건 기획서와는 조금 관련이 없을지도 모르겠지만,

저 학부시절 Project.다원의 로고였습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ

지금도 어디선가 사용했었고, 나쁘지 않아서 그대로 긁어왔네요 ㅋㅋㅋㅋ

저 디자인이 그때거였구나 ㅋㅋㅋ 재밌네요 ㅋㅋㅋㅋㅋㅋㅋ

아마 특별히 문제되지 않는 이상은 이대로 진행될 것 같습니다.

아무래도 학부시절 저의 폴더들은 노다지인 것 같습니다.

언제 한번 기회봐서 제가 작업한 졸업작품이나 과제하면서 만들었던 설계서 같은 것도 보여드리면 좋겠는데, 다음기회를 노려보도록 하죠. (언젠가는..)

버전정보 (v1.0)

 - v1.0 2020.07.13 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com