Project.다원 Ensemble_설계(5)_장비관리-장비등록

Wireframe&화면설계서(1)


역시 저는 설계하다보면 괜한거 하나하나까지 꼼꼼히 따져가면서 하게되네요;;; 역시 귀찮은 성격,,,(?!?!?)

아니나다를까 설계를 하다보니 또 늦어졌습니다. ㅋㅋㅋ..

오늘은 앞에 게시글 쓰고 바로 설계 진행했는데.. 벌써 1시 22분..

아무래도 저도 직장인이고, 제가 해야할 공부도 산더미같다보니 블로그 관리는 새벽 2시 이전까지만 하기로 했습니다!

(근데 벌써 1시 23분이 지나가고 있...)

그래서 지금까지 한 부분이 마침 장비등록부분이라서 진행된 부분까지만을 업로드 하겠습니다.


Wireframe (장비관리 - 장비등록)

Wireframe (장비관리 - 장비등록)

Wireframe은 보통 화면설계서보다 이런식의 화면구조다 라는걸 잡아주는거라고 저는 생각하고 있습니다.

개인적으로는 이게 있으면 어느정도 고객(혹은 설계자)의 생각을 파악할 수 있어 개발자 입장에서는 굉장히 편하게 설계-개발이 진행된다고 생각하고 있습니다.

뭐.. 보통은 보기가 어렵다는게... (ㅠㅠ)

이유는 아래 화면설계서를 보면서 말씀드리겠습니다.


화면설계서 - PC (장비관리 - 장비등록)

화면설계서 - PC (장비관리 - 장비등록)

자, 우선! 화면설계서를 유심히 보시면 Wireframe과 큰 차이가 없다는것을 확인할 수 있습니다.

큰 차이가 있다면 실 데이터가 들어갔고, 그만큼 뼈대가 확실히 잡혔다는 느낌을 받으실겁니다.

그리고 저의 경우 화면설계서에 연동될 데이터베이스의 정보를 함께 넣어주는데 이게 있으면 개발하는 입장(내가 되거나, 혹은 같이 일할 상대)에서는 어떤 데이터가 연동되면 좋을지 머릿속에 더 정리가 잘 되는 편이라서 넣고 있습니다.

사실 설명은 큰 의미는 없지만, input과 select와 같은 상자 외에 유저가 사용함에 있어 이건뭘까? 싶은 부분에 설명을 넣어주면 개발자 입장에서도 '이런 ux구나'라고 쉽게 판단이 되어 최대한 자세히 작성은 하려고 노력합니다. 

뭐.. 화면설계서야 이미 설명등이 있다보니 어느걸 설명해드려야할지는 모르겠네요 ㅎㅎ

 

마지막으로 뜬금없지만 여기서 눈치가 빠르신분들은 양식이 바뀌었다는 걸 느끼실겁니다!

예! 맞습니다. 양식을 바꿨습니다.

좀 더 한눈에 보기 편하게 하려고 PPT의 구조를 바꾸기 위해 설계를 해서(...) 화면설계서 양식을 또 만들어 보았습니다.

(이정도면 설계광일지도... 아님 그냥 변태거나..) (!?!?!?!?!?!?)


화면설계서 - Mobile (장비 관리 - 장비 등록)

화면설계서 - Mobile (장비관리 - 장비등록)

단, Wireframe은 이런식의 화면이 이루어질 것이다 라면, 화면설계서는 detail해야합니다.

더 많은 것을 보여주고, 개발함에 있어 부족함이 없이 설계를 해야합니다.

Wireframe이 보여지지 않는 부분이 있다고 하더라도 화면설계서는 그 이상의 모든 부분을 전부 설계해줘야합니다.

그래야 개발이 가능하니까요.

(의외로 개발자는 작은 새장은 보더라도 하늘을 보지 못하는 경우가 많아서.. - 제 개인 경험입니다 ㅎ..)

 

자, 모바일의 경우 Web에서 접속하면 저런 모양일겁니다.

하지만, 추후 Application으로 개발이 진행되면 또 새로운 화면설계서가 나오겠죠.

그때는 Android나 iOS의 이쁜 플랫디자인이 나올 것 같습니다.

 


워낙 말이 많은 성격이다보니 이것저것 다 설명을 하고는 싶지만, 제 자신과의 약속은 지켜야죠! (글 쓰다 보니 1시 44분)

다음시간은 지금시간에 끝내지못한 Wireframe과 화면설계서를 계속 진행할 것 같습니다. (아직 3개 더 남았습니다..)

저는 보통 분석/설계는 설계하는 사람이 많이 늦어지면 개발하는 사람도 그만큼 늦어지거나 부담을 많이 갖기 때문에 미루지를 않는데.. ㅠㅠ

회사도 있고, 저도 공부를 하는 입장이고, 또 사람이다보니 잠은 자야겠고.. 여러모로 아쉽긴 하네요 ㅠㅠㅠ

(어찌됬든 분석/설계/개발 다 제가 하지만..ㅋㅋㅋ)

오늘도 고생 많으셨습니다~

 

 

버전정보 (v1.1)

 - v1.0 2020.07.08 배포

 - v1.1 2020.07.08 문장 수정

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com



 


Persona - 효율적인 UX디자인을 위한 시작


저는 학부시절 소프트웨어 공학을 굉장히 좋아했었습니다.

뭐.. 이전부터 멍때리는 시간이 있으면 무언갈 분석하거나 그려가면서 설계하는게 취미(??)이긴 했는데

그런시간을 많이 주어주는 소프트웨어 공학은 저에게 있어 즐거움 중 하나였지요.

 

오늘은 분석/설계 단계에서 사용할 수 있는 Persona(퍼소나 혹은 페르소나)에 대해서 적어볼까 합니다.

어쩌면 가장 즐거운 시간이 되겠네요.


Persona?

우선 Persona가 무엇인지에 대한 궁금증이 있을겁니다.

Persona는 쉽게 말해 나의 시스템을 사용해 줄 가상의 사용자라고 생각하시면 될 것 같습니다.

우리는 개발을 하다보면 분석/설계 단계에서 실 사용자가 될 고객들과 인터뷰를 하게됩니다.

이 인터뷰를 토대로 고객이 원하는 정보를 모아 새로운 요구사항 분석서(기술서)를 작성하기도 합니다.

하지만, 실 사용자와 인터뷰가 어렵거나, 인터뷰를 해야할 사용자가 너무 많거나 하는 경우와

실 사용자와 인터뷰를 하기 전 사전 정보 조사로 Persona를 사용하면 효과적입니다.

사전 정보조사를 통해 Persona를 생성을 하면 인터뷰시 조율이 더 편리할 수 있다는 점을 노리는겁니다.

가상의 사용자를 통해 미리 만나본 고객은 이러한 요구를 가지고 있으며, 이런 요구를 어떠한식으로 답을 해줄 수 있는지를 미리 예측을 해보다보면 실제 인터뷰시에도 많은 부분 도움이 된다는 것입니다.


효과적인 Persona

그렇다면 효과적으로 Persona의 구축방법은 무엇일까요?

위에서 말했다시피 Persona는 분석/설계단계에서 고객과의 조율이나, 수 많은 사용자를 상대로 인터뷰를 할 수 없는 경우에 사용한다고 말했습니다.

자, 우리는 위 문장에서 답을 찾을 수 있습니다.

쉽게 생각하면 실 인터뷰를 진행할 고객과 비슷한 Persona를 만드는 것입니다!

또는 수 많은 사용자들 중 많이 사용을 할 사용자분들을 타겟팅하거나, 특정 사용자(시스템을 사용할 신규 유입자나, 사용이 불편하실 수 있는 사용자분들)분들을 만들어 인터뷰하는것입니다.


Persona를 이루는 항목들

그렇다면 Persona가 만들어지기 위한 항목들은 무엇이 있을까요?

예를 들어 실사용자와 인터뷰를 한다고 합시다.

우리는 실사용자와의 인터뷰에서 다음과 같은 항목을 얻을 수 있습니다.

 - 사용자의 프로필 (외형, 이름, 연령대, 성별, 직장, 직급, 성격 등)

 - 사용자가 시스템을 사용할 이유

 - 시스템에 바라는 점 (신규)

 - 기존 시스템과 비교해 현 시스템에 바라는 점 (업그레이드 시)

 - 시스템의 장단점

위는 실사용자와의 인터뷰를 통해 얻을 수 있는 항목들입니다.

그럼 Persona는? 맞습니다. 실사용자처럼 생각을 하고 가상의 사용자를 만드는거기 때문에 위와 동일한 항목들을 가집니다.

다만 우리가 저기서 얻지 못한다면 외형이 있을 수 있으나, 이 외형은 가상의 인물을 토대로 하는 것 이기 때문에 저작권이 없는 사진을 가져다가 작성을 하면 됩니다.

 


Persona의 예시

우선 인터뷰를 위한 시작입니다.

자, 우리가 여기 사용자를 위한 ERP를 만들었다고 칩시다.

사용자는 이 신규 ERP를 사용하면서 나오는 피드백을 줄것입니다.

(이미지는 저작권 등의 문제로 제가 만든 픽토그램으로 대체하였습니다.)

 

 

Persona1

 

 - 이름 : 전하윤

 - 나이 : 26

 - 성별 : 여성

 - 직급 : 사원

 - 부서 : 인사과

 - 성격 : 꼼꼼하고 매사에 정직하게 임함, 다만 가끔씩 빼먹는게 있음.

 - 사용자는 회사에서 인사담당을 하고 있어 ERP의 인사관리 시스템을 사용해야함

 - 시스템에 바라는점 : 

  -> UI가 깔끔했으면 좋겠고, 사용시 많은 부분 편리했으면 좋겠습니다.

  -> 가끔씩 인사등록시에 필요한 정보를 빼먹는 경우가 있는데 이런 부분들을 조금 정리해서 빼먹지 않게 해주세요.

 - 사용 후 장점 : 

  -> UI가 너무 깔끔해 보는 즐거움이 있었습니다.

  -> 인사 등록 시 꼭 필요한 필드를 다르게 보여줌으로써 저도 편리하지만, 신규 직원이 들어와도 알기 편해서 너무나 좋습니다.

 - 사용 후 단점 :

  -> 여전히 프로세스의 어려움이 있습니다.

 

 

Persona2

 - 이름 : 김수현

 - 나이 : 48

 - 성별 : 남성

 - 부서 : 홍보부

 - 직급 : 부장

 - 성격 : 무엇이든 문서를 남겨야 편하다는 생각을 가짐, 항상 직원들을 생각함

 - 사용자는 회사에서 출장을 자주 다니며, 출장정보의 등록등을 위해 ERP 시스템을 사용해야함.

 - 시스템에 바라는 점 : 

  -> 나의 권한이 미치는 직원들의 출장정보를 수시로 볼 수 있으면 좋겠습니다.

  -> 결재된 문서들을 워드형태의 문서로 다운받을 수 있으면 좋을 것 같습니다.

  -> 단순히 이쁜 디자인보다 사용의 편리성을 원합니다.

  -> 요즘 트랜드에 맞춰 핸드폰이나 태블릿에서도 사용할 수 있었으면 좋겠습니다.

 - 사용 후 장점 : 

  -> 결재된 문서를 워드형태의 문서로 다운받을 수 있어 너무나 좋습니다.

 - 사용 후 단점 :

  -> 이쁘지만 편리한지 모르겠습니다.

 


Persona Worst Case

모든 Persona가 유효한 것만은 아닙니다.

간혹 시스템을 사용하지도 않거나 전혀 상관없을 법한 가상의 인물을 만들어 인터뷰를 하는 경우가 있습니다.

우리는 이런 경우를 피해야만 합니다.

왜일까요? 물어볼 필요도 없이 의미없는 행위이기 때문입니다.

시스템을 사용하지도 않을 사람의 인터뷰를 받아 어떠한 의미가 있을까요?

예시로 다음은 Worst Case에 대한 Persona를 보여드리겠습니다.

 

Persona3

 - 이름 : 박중헌

 - 나이 : 900살

 - 성별 : 남성

 - 부서 : 국자감

 - 직급 : 간신

 - 성격 : 집착이 강함, 죠스바를 좋아함.

 - 사용자는 도망을 자주 다니며, 요령있게 보기싫은 자들을 피해다님.

 - 시스템에 바라는 점 : 

  -> 내 손으로 시스템을 만들고 키워 이 세상을 내 시스템의 발 아래, 그 시스템을 발 아래, 그리하여 천하를 내 시스템 아래 둘 것이다. (?!?!!!)

  -> 테마 색상은 보라색으로 하거라

 - 사용 후 장점 :

  -> 그게 딱 그 시스템의 가치이다. (대략 만족하셨다고..)

 - 사용 후 단점 : 

  -> 파국이다. (버그가 많다고..)

 

뭐, 위는 엄청 극단적인 예이긴 하지만, 조금 와닿으면 좋겠다는 생각으로 예시를 들어봤습니다.

 


학부시절에 배웠고, 그걸 활용하고 있는 지금으로써는 한번쯤 정리하자는 생각을 가지고는 있었으나,

바쁘다는 핑계만 들이대고 많이 늦어져버린건아닌가 싶습니다. (누가 늦었다 생각했을때가 빠른법이라고 말했습...)

후..

그래도 박중헌은 조금 극단적인 예시는 아닌가 싶기는 한데..ㅋㅋㅋ

한번쯤 웃고가세요. 긴 글 읽으면 졸리기도 하고.

 

 

버전정보 (v1.1)

 - v1.0 2020.07.07 배포

 - v1.1 2020.07.08 오타 수정

 

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

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

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

 

Karzin

abbeea@naver.com

 


Project.다원 Ensemble_설계(4)_장비관리 Wireframe(0) (SiteMap 추가!)


오늘은 약속대로 ER-Diagram의 다음 작업인 Wireframe입니다!

음.. 11시에 시작은 했는데 (집 도착해서 밥먹고 씻고 준비하면 대략 이런시간..ㅋ) 아마 12시는 넘어서(내일) 업로드 될 것 같네요.ㅠㅠ 아쉽..

 

Mobile에 대한 Wireframe은 많이들 하지만 WebSite는 하는걸 본적이 없다! 하시는 분들 있을 수 있어요.

그 이유 중 하나는 WebSite가 아무래도 조금은 개발하기가 쉽고, 변경이 빠르기 때문은 아닐까 싶습니다. (뭐.. 이건 생각에 따라 다를지도 모르겠네요.) 추가로 아마 포화상태인 시장도 있다고 생각은 합니다.

느낌은 Mobile은 한번 fix되면 그 이후는 변경이 어렵다고 생각을 한다면, WebSite의 경우 조금 고객과 소통을하며 변경이 많이 일어난다는 느낌입니다.

뭐.. 이건 각자 경험에 따라 다르겠지만, 보통 Mobile의 경우 한번 fix된 Wireframe을 토대로 UI를 그리고 개발을 시작하는 느낌입니다. (음.. 글쎄요.. 이 부분은 느끼는 분들에 따라 다르지 않을까 싶습니다만..)

뭐 추가로 말한것처럼 포화상태인 시장도 한 몫을 하긴 하죠. 워낙 WebSite를 템플릿을 미리 구축한 회사들이 빠르게 개발을 진행해주는 만큼 사용자는 Wireframe보다는 대화를 하며 fix를 시키는 방향으로 나아가는건 아닌가 싶습니다.

 

다만 이는 조금은 기획쪽에 카테고리가 더 들어간다는 생각은 합니다.

이유는 사용자가 원하는 유저 인터페이스(UI)의 기능을 기획자는 어떻게 담을것이고, 어떻게 자신의 내공을 축적시키는지에 따라 Wireframe만으로도 충분한 프로토를 전달할 수 있다는 점에서입니다.

 

여기서 어? 당신! 개발자 아냐? 왜 기획을 해! 라는 말씀 나올수도 있는데, 기획도 개발의 일부라 생각합니다. (저만의 생각일지도 모르겠지만..)

그래서 저는 기획을 위한 기획 관련 서적도 읽어보고, 설계를 위한 소프트웨어 공학, 그리고 좀 더 다방면으로 바라보기 위한 안목을 기르려 노력하고 있습니다. 어플 한가지를 보고 사용할때에도 여러면에서 이 디자인은 이런면에서 좀 아쉽고, 유저 인터페이스(UI)부분에서 이런 부분이 아쉬우며, 이런건 이렇게 바뀌었으면 좋겠다라는 재밌는 생각들을 하곤 합니다.

 


 

또 별 이상한 소리를 내기 시작했으니, 다시 한번 오늘의 주제대로 장비관리 Wireframe의 설계를 시작하겠습니다.

우선 Wireframe을 보기 전에 장비관리의 SiteMap을 한번 보도록 합시다.

한 화면에 다 담으려하다보니 아무래도 너무 복잡해질 것 같다는 생각에 결국에는 SiteMap을 설계하게 되었습니다.

SiteMap 설계하는 김에 그냥 URL도 같이 설계했습니다.

SiteMap 

SiteMap과 URL 설계

위에 SiteMap을 보면 장비 등록과 목록을 나눴습니다. 나누게 된 이유를 우선 말씀드리자면, 한가지 경우를 상정했습니다. 바로 Mobile이죠. 저는 Ensemble의 모든 개발은 PC뿐이 아닌 Mobile도 대응이 되도록 설계를 하고 개발을 하려합니다. 때문에 Mobile에서 편리하게 바로 장비등록만 할 수 있도록 생각을 했습니다.

(뭐,.. 추후에 장비관리 application을 만들면 되지만, application이 지원되지 않는 예전 폰 혹은 태블릿이라던가에서는 웹사이트 접속을 통해 모바일의 지원을 할 예정입니다.)

특이사항으로 상태변경이 점선인 이유는 바로 Modal이기 때문입니다.

기본 장비 상세정보에서는 Log등의 정보도 보여줄 예정이지만, 상태변경시에는 Modal로 숨겨져 있던 창을 열어 컨트롤을 할 수 있도록 할 예정입니다.

(참고로 이 모든 기능은 계속해서 언급했다시피 application에서도 지원을 할 예정입니다.)

 

자, 이번엔 기다리시던 Wireframe의 시간입니다!

Wireframe - 메뉴구성

Wireframe - 메뉴구성

에구.. 메뉴구성 하나에 너무 몰두해버렸네요.

11시에 자리에 앉아 설계만 잡는다는게 게시글에 말 주저리쓰고 SiteMap 설계하고 Wireframe-메뉴구성 딸랑하나..

아무래도 시간이 시간인 만큼(현재 시각 오전 1시 44분)

2편을 준비해야겠습니다.

(내일 회사갈 준비도 있고, 개인적인 공부시간도 또 필요하다보니.. 잠은 보통 3시~4시 잡니다 ㅋㅋㅋㅋ 기상은 8시.ㅋ)

 

아무래도 저의 나쁜부분이네요 한개 설계할때 집중해서 파고드는게 ㅋㅋㅋ

얼른얼른 쳐내고 다음 부분으로 넘어가야하는데 마음에 들때까지 가지고 있다보니..ㅋㅋㅋㅋㅋ

다음 Wireframe_2에서는 오늘 못한 장비 등록, 장비 목록, 장비 상세, 상태 변경을 다뤄보겠습니다.

 

그리고 그 다음 컨텐츠는 아마 화면설계서가 될 것 같아요.

화면설계서는 아무래도 Wireframe과는 조금 다르다보니 어떤부분이 다른지를 나타낼 수 있을 것 같습니다.

(사실 자세한 설명이 들어가는거 빼고는 별 다른게 없어 보이는 게...)

 

 

버전정보 (v1.2)

 - v1.0 2020.07.07 배포

 - v1.1 2020.07.07 내용 수정 (오타)

 - v1.2 2020.07.08 제목 수정 (Wireframe(1) -> Wireframe(0))

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com




[20200706] 아침부터 운이 따르지 않는..ㅠㅠ


오늘은 아침부터 운이 따르지를 않네요 ㅠㅠ

여느때처럼 자전거로 출근을 했는데...

 

신발 신은 상태로 밟아도 큰일날 것 같은 비쥬얼..(진짜 큰일나지요..)

 

거의 도착할때쯤 자전거 뒷바퀴가 뭔가 이상한 느낌이 나더니

도착하고나서 보니 아예 터져버린 바퀴..

이정도면 펑크패치보다는 튜브를 바꿔줘야할판입니다.

액땜이라고 생각은 하려는데 좀 너무한건 아닌가 싶네요.

다치진 않아서 다행이라 생각해야죠.

 

아.. 그나저나.. 저거 고치려면 튜브사야하고.. 휴일날 공구들고 회사가지고와서 고치고..

언제다하지.....ㅠ

5월에 다쳐서 돈이 좀 들었는데.. 7월은 튜브구입하느라 또 돈날리게 생겼네요 ㅋㅋㅋ (얼마안하지만..)

 

한동안 자전거로 출퇴근은 못할것같네요 ㅠㅠ

 

 

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

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

 

Karzin

abbeea@naver.com

 


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


어제 장비관리 프로세스를 작성을 하고, 머릿속에 있는동안 얼른 정리해버리자 해서 ER-Diagram을 작성했습니다.

ER-Diagram의 작성은 여느때처럼 PPT를 이용하였습니다.

미리 말씀드리지만, 개발중에 해당 설계문서는 어떤 사유로든 변경이 될 수 있습니다.

이는 개발하면서 문제가 있을법한 로직을 제거하거나, 조금 더 다듬어 나가면서 생길 수 있는 수정으로 확정이 아님을 미리 말씀드립니다.

 

설명은 다이어그램이 우선 보여져야할 것 같아 그림을 먼저 보시고 설명을 하겠습니다.

장비 관리 ER-Diagram

장비 관리 ER-Diagram 작성자 Karzin

 

공통코드, 사원정보, 프로젝트 정보 테이블의 경우 아직 설계중인 단계이다보니 PK수준으로만 잡아두었습니다.

이 부분의 경우 추후 변경될 가능성이 굉장히 높습니다.

 

우선 왼쪽부터 오른쪽으로 천천히 훑어 나가겠습니다.


상태 정보

상태 정보는 장비의 상태를 계속해서 업데이트 해나가기 위한 테이블입니다.

해당 테이블은 추후 사용 가능성이 있어 일단 테이블의 PK를 장비 정보 테이블의 관리코드 PK로 통일하지 않았습니다.

또한 상태정보도 계속해서 변경이 가능하며, 상태 정보는 공통코드로 등록된 정보를 토대로 불러올 예정입니다.

(수리, 불용, 사용중 등)

일자는 변경된 일자를 나타냅니다.

추가로 상태정보 테이블에서는 담당자(사용자)가 변경되거나 관리자(유지보수)가 변경이 되어도 변경된 이력은 계속해서 남길 예정입니다.

변경 사유등도 상태정보로 남겨서 왜 변경이 되었는지 남기기 위함입니다.


장비 정보

장비 정보는 기본적인 장비의 정보를 나타냅니다.

장비 명, 모델 명, 제조사, 규격, 사용용도 등..

특히 규격과 사용용도는 TEXT타입으로 두어 규격이 바뀌더라도(예를들어 PC의 경우 램이 바뀐다던가의 업그레이드가 있을 수 있으므로) 수정이 가능하도록 하였고, 사용 용도 또한 어떤 용도로 사용할것인지 길게 작성하도록 TEXT타입으로 했습니다.

특이사항 컬럼은 음.. 그냥 특이사항 있으면 적으면 좋겠다 싶은 생각에 넣어보긴했는데, 굳이 사용은 안할거같으면 추후 제거예정입니다.

프로젝트는 현 장비가 프로젝트에 귀속이 되어있는 경우를 생각했습니다.

예를들어 장비를 한 프로젝트를 위해서만 구입을 했고, 프로젝트가 끝나면 불용처리를 해야하는 등의 특수한 경우라던가, 그냥 평범하게 프로젝트에서 쓸거다 싶은경우만으로도 프로젝트를 연결하여 어떤 프로젝트를 위한 장비인가를 나타내기 위함입니다.

파일의 경우 1:다로써 하나의 장비에 사진이 10장이든 20장이든 100장이든(그런경우는 드물겠지만) 등록을 할 수 있도록 하였습니다.

장비 정보에 등록되는 상태 정보는 항상 1:다로써 Log형식으로 쌓여나갈 것입니다.

그리고 구입 정보를 나눠 둔 이유는 다른쪽 문서에서 사용될 가능성이 있어 빼두었습니다. (구매 증빙자료등의 자료를 활용하기 위함)

구분과 분류는 장비의 카테고리를 나타낸다 보시면 될 것 같습니다.

구분은 하드웨어인지, 소프트웨어인지 기타인지를 나타낼 것이며

분류는 장비를 나누기 위한 대 분류라고 보시면 될 것 같습니다. (예로 모니터, 데스크탑, 서버, 워크스테이션 등)


구입정보

위에서 언급했다시피 구입정보는 추후 다른 문서에서 사용될 가능성이 높아 빼두었습니다.

구입년도를 빼 둔 이유는 구입년도로 필터링을 조금 더 빠르게 해볼까 해서 빼두었..(어려운건 아닌데 java나 javascript상에서 년도만 나눠서 보여주기 귀찮았습..(ㅡ,.ㅡ) )

구입일자, 구입처, 가격, 수량 이 모든 컬럼들은 기본적인 구입정보를 나타내며,

특이사항으로 구매증빙자료 = 파일 ID를 나타냅니다.

구매 증빙자료는 PDF, 이미지, HWP, DOC 등등 어떠한 구매 자료를 저장이 가능하도록 대응할 예정입니다.

(추후 실험적 요소로써 웹상에서도 PDF, HWP 등을 바로 열어 볼 수 있도록 할까 합니다. - 물론 괜찮은 opensource가 있다면..)

추가로 결제정보 ID는 나중에 결제된 문서의 ID를 연동할 예정입니다. (현재는 설계 시작도 못해둔 상태)


파일

해당 테이블은 공통적인 요소로 여러 부분에서 사용할 예정입니다.

공통코드등의 테이블은 뒷전인데 왜 파일테이블은 설계가 되었냐고 물어보신다면,

파일은 당장 사용할 예정이고, 공통코드는 text형식으로 입력을 해두고 추후에 컬럼타입을 바꾼다던가 하는 방식을 취해도 되기 때문입니다. (결코 귀찮은게 아니라 다 생각이 있어서 그렇게 한겁니...)

이름, 위치, 크기, 확장자, 등록일자는 크게 설명할 부분은 없을 것 같고,

한가지 특이사항이라면 사용유무입니다.

사용유무는 삭제를 했는지, 아니면 기본 저장상태인지를 나타낼 예정입니다.

유저가 삭제를 한 경우 DB에서는 이력으로 남지만, 스토리지에서는 해당 데이터는 제거됩니다.

이는 세팅에 따라 제거도 하지 않을 수 있기도 하구요. 혹은 15일등 특정 기간을 걸어 삭제 후 15일이 지나면 스토리지에서는 제거가 된다던가의 형식을 취할겁니다.

이렇게 한 이유는 가끔씩 잘못 삭제를 해놓고 "이전 파일이 필요한데.." 싶은 분들이 간혹 있더라구요. 

물리적으로 제거가 된다면 나중가서는 복구하기는 어려우니 말이죠.

 


 

이 글 작성한다고 11시가 좀 안되서 시작한거같은데.. 벌써 11시 53분이네요;;

(사실 작성은 한 11시 40분쯤 끝났는데, 작성된 게시글을 한번 더 보고 수정할거 수정하고 배포하려고 시간이 걸렸습니다..ㅎ...)

이제 ER-Diagram이 나왔으니 다음 시간은 Wireframe차례입니다!

그리고 그 다음은 바로 개발이 될지 Class-Diagram을 작성할지 모르겠네요.

 

 

버전정보 (v1.0)

 - v1.0 2020.07.05 배포

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com





[Swift5] 버튼에 라운드 주기 (버튼 둥글게)


개발을 하다보면 버튼에 간단한 디자인을 입혀야하는 경우가 있습니다.

 

그중 버튼의 꼭짓점부분을 둥글게 해달라는 (라운드처리) 이야기가 간혹 있는데, 이럴때 사용하는 방법입니다.

 

기본 버튼에 라운드를 주는 방법은 쉽습니다.

UIButton.layer.cornerRadius = 8

 

일반적으로 생성한 버튼의 모습

 

아래는 소스입니다.

@IBOutlet weak var btn_info: UIButton!

override func viewDidLoad() {
	super.viewDidLoad()

	//버튼의 라운드 처리
	btn_info.layer.cornerRadius = 8

}

 

UIButton은 UIControl을 상속받으며, UIControl은 UIView를 상속받고 있습니다. (https://developer.apple.com/documentation/uikit/uibutton)

 

Apple Developer Documentation

 

developer.apple.com

특히 상속을 받는 UIView에는 멤버변수로 layer:CALayer를 가지고 있습니다. (https://developer.apple.com/documentation/uikit/uiview)

 

Apple Developer Documentation

 

developer.apple.com

이 layer변수에는 뷰에 그림을 그려줄때 필요한 핵심 애니메이션 정보를 가지고 있는데, 이 layer의 정보를 수정해줌으로 라운드 처리가 가능해지는겁니다.

 

소스를 통해 라운드가 적용된 버튼의 모습

 

위에서 설명한 layer변수를 이용하면 버튼의 색상, 타입지정, 이미지 등록 등 다양한 컨트롤이 가능한데, 이는 본 게시글의 제목의 성격이 달라지므로 다음에 설명하는 시간을 갖도록 하겠습니다.

 

 

버전정보 (v1.0)

 - v1.0 2020.07.02 배포

 

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

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

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

 

Karzin

abbeea@naver.com


Project.다원 Ensemble_분석(4)_장비관리 프로세스 정의

(등록, 수정, 불용처리)


저의 일을 줄이기 위해 가장 필요한것! 바로 장비관리입니다. (ㅎ...)

 

개발외에 하는 일은 없어보이지만(...) 회사의 장비도 관리하고 있는 저로써는 조금이라도 편한 방법을 원하기도 합니다.

 

회사의 장비는 엑셀을 이용해 정리하고 있습니다.

다만, 엑셀을 이용하는 만큼 제약도 어느정도 있고, 무엇보다 등록에 있어 서식의 통일이 생각보다 쉽게 되지 않는 문제 등이 있어 불편합니다.

 

바탕화면에 돌아다니는 장비현황

무엇보다 엑셀로 처리를 하면, 큰 문제는 가독성이 생각보다 나빠요.

물론 엑셀을 잘 활용하시는 분들에게 있어 편할지는 모르겠지만,

저는 셀로 표현되어 있는 엑셀은 그닥 좋아하지 않습니다. (눈이 아파서?)

워낙 빼곡히 저장이 되고, 검색을 하더라도 중복된 정보가 나오면 뭐가 뭔지 머리가 아파집니다.....

사진활용도 힘들다보니 엑셀 하나의 크기가 몇십MB단위가 되어버리는 경우도....

그런 경우가 되면 엑셀 프로그램이 죽기 시작합니다. (컴퓨터의 사양에 따라 엑셀이 뻗어버리거나, 간혹 열릴 수 있지만 느리다거나, 반응속도에 문제가 있다거나 등등)

 

그.래.서! 오늘은 이 엑셀파일을 처리(?)해버리기 위해 장비관리쪽 프로세스부터 시작해서 먼저 개발을 진행하려합니다.

그러기 위해서는 역시 분석이 필요하겠죠. 

 

분석 - 장비관리 프로세스 정의


장비 등록

장비를 구매하거나, 어떠한 일에 의해 (회사 인원에 의해 기부를 받는다거나..) 장비가 생기는 경우가 생기면 장비를 등록해주어야 합니다.

 

장비 등록 프로세스

 

등록을 위해서는 기본적으로 사용한 데이터 양식이 있지만, 저는 조금 추가하거나, 불필요한 부분은 제거하려고 합니다.

우선 제가 생각한 장비 등록에 기본적으로 필요한 데이터들입니다. (추후 ER-Diagram으로 변경)

 - 관리번호(관리코드) : 장비의 고유한 ID라고 보시면 됩니다. 저는 이걸 Primary Key로 생각하고있습니다.

   -> 자동 생성

 - 구분 : HW / SW / 기타

   -> Select Box, 기타인 경우 input 상자로 추가 생성

 - 분류 : PC / 모니터 / 서버 / 기타 등..

   -> Select Box, 기타인 경우 input 상자로 추가 생성

 - 구입 정보 (구입년도, 구입일자, 구입 처, 가격, 수량, 결제코드, 구매 증빙자료)

   -> 여기서 보이는 결제코드는 장비를 구입하는 경우 구입한 장비의 결제 문서를 등록하기 위한 코드입니다. (매칭용)

 - 장비 정보 (장비 명, 모델 명, 제조사, 규격)

   -> 규격은 장비의 정보를 상세하게 적을 수 있는 항목입니다.

 - 상태 : 사용 / 불용(사유, 일자, 등록 및 확인자) / 수리 / 기타 

   -> 사용상태는 사용중인 상태임을 나타내며, 불용상태는 폐기와 동일하다고 생각하고 있습니다. (폐기가 필요할 것 같으면 추후 추가예정)

   -> 불용시에는 불용(폐기) 사유, 불용(폐기) 일자, 불용(폐기) 등록자 및 확인자의 정보를 작성해야합니다. (하단 장비 불용 확인)

   -> 기타 상태로 변경하는 경우 input 상자에 상태를 지정할 수 있습니다.

   -> 상태는 이력을 포함합니다. (Log)

 - 사용자(담당자, 관리자)

   -> 추후 인사정보에 등록된 사용자 ID를 매핑 시키줄 예정입니다.

 - 사용 용도

 - 매칭 프로젝트 ID

   -> 특정 프로젝트를 위해 구입한 경우를 나타내기 위함입니다. 매칭될 프로젝트는 추후 프로젝트 관리 프로세스가 생성되면 추가될 예정입니다.

 - 장비 사진

 - 특이사항

   -> 혹시라도 장비에 대해 알아야하는 사항이 있으면 적기 위해 마련했습니다. 필요가 없다면 삭제될 예정입니다.

 


장비 불용

우리는 장비가 너무 오래되거나, 상태가 좋지 않은 경우 (예로 10년 된 회사의 데스크탑이 있을때, 너무 느려서 못쓴다거나) 장비를 불용처리 해야할 필요가 있습니다.

이때에는 단순히 불용처리만이 아닌, 장비의 상태와 불용처리를 하는 사유를 작성해야합니다.

다들 아시겠지만, 회사 입장에서는 장비 하나하나가 소중한 자산이기 때문에 수리해서 사용할 수 있는 상태의 장비는 불용처리보다는 수리를 하는게 더욱이 좋습니다. (저는 불용상태도 사용할수 있는건 수리해서 사용합니다 ㅋㅋㅋ)

 

장비 수리 (혹은 불용) 프로세스

위 프로세스에서는 단순히 불용처리를 하고 마무리를 하지만, 저 불용안에는 등록을 해주기 위한 몇가지 정보를 입력을 해야합니다.

아래는 장비 불용처리시 등록해야할 데이터입니다.

 - 사유

   -> 불용처리를 해야하는 사유를 상세히 작성합니다.

 - 일정

   -> 불용처리된 일자를 입력합니다.

 - 등록자

   -> 프로세스 상으로는 장비 관리(유지보수) 담당자입니다.

 - 확인자

   -> 프로세스 상으로는 장비 사용 담당자(사용자)입니다.

입력된 불용처리(사유, 일정) 정보는 확인자가 열람이 가능합니다.

 


 

장비관리 프로세스 분석은 이정도 선에서 마무리를 하고,

다음시간에는 설계를 해볼까합니다.

 

 - Project.다원ERP_설계(3)_장비관리 ER-Diagram (https://karzin.tistory.com/174)

 

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

Project.다원 Ensemble_설계(3)_장비관리 ER-Diagram 어제 장비관리 프로세스를 작성을 하고, 머릿속에 있는동안 얼른 정리해버리자 해서 ER-Diagram을 작성했습니다. ER-Diagram의 작성은 여느때처럼 PPT를 이�

karzin.tistory.com

 - 장비관리 Wireframe

   -> Project.다원ERP Ensemble_설계(4)_장비관리 Wireframe(0) (https://karzin.tistory.com/176?category=793727)

 

Project.다원 Ensemble_설계(4)_장비관리 Wireframe(0) (SiteMap 추가!)

Project.다원 Ensemble_설계(4)_장비관리 Wireframe(0) (SiteMap 추가!) 오늘은 약속대로 ER-Diagram의 다음 작업인 Wireframe입니다! 음.. 11시에 시작은 했는데 (집 도착해서 밥먹고 씻고 준비하면 대략 이런시..

karzin.tistory.com

   -> Project.다원ERP Ensemble_설계(5)_장비관리 Wireframe&화면설계서(1) (https://karzin.tistory.com/178?category=793727)

 

Project.다원 Ensemble_설계(5)_장비관리-장비등록 Wireframe&화면설계서(1)

Project.다원 Ensemble_설계(5)_장비관리-장비등록 Wireframe&화면설계서(1) 역시 저는 설계하다보면 괜한거 하나하나까지 꼼꼼히 따져가면서 하게되네요;;; 역시 귀찮은 성격,,,(?!?!?) 아니나다를까 설계�

karzin.tistory.com

   -> Project.다원ERP Ensemble_설계(6)_장비관리 Wireframe&화면설계서(2) (https://karzin.tistory.com/182?category=793727)

 

Project.다원 Ensemble_설계(6)_장비관리-장비목록 Wireframe&화면설계서(2)

Project.다원 Ensemble_설계(6)_장비관리-장비목록 Wireframe&화면설계서(2) 오늘은 낮에 커피를 한잔만 마셨더니 엄청 피곤하네요;; 아무래도 카페인이 부족한 모양입니다.ㅎ;; 그래서 빠르게! 오늘 할 ��

karzin.tistory.com

   -> Project.다원ERP Ensemble_설계(7)_장비관리 Wireframe&화면설계서(3) (https://karzin.tistory.com/183?category=793727)

 

Project.다원 Ensemble_설계(7)_장비관리-장비상세 Wireframe&화면설계서(3)

Project.다원 Ensemble_설계(7)_장비관리-장비상세 Wireframe&화면설계서(3) 계속해서 장비관리입니다! 앞으로 화면 1개만 더 나오면 끝나겠네요! 벌써 설계서 PPT가 27장이 되었네요 ㅋㅋㅋ 으아 ㅋㅋㅋ 2�

karzin.tistory.com

 

추가적인 예정으로는 Class-Diagram이나, 필요시 SITEMAP정도를 생각하고 있습니다.

SITEMAP의 경우 장비관리 프로세스가 커지면 SITE를 나눠서 생각할 필요가 있어지기 때문에 고려를 하고 있는 부분 중 하나인데, 이는 우선 설계가 마쳐지고 개발이 진행되면서 수정이 불가피한 경우에 추가가 될 것 같습니다.

 

오늘도 적당히 쓰겠다고 했는데 글이 굉장히 길어졌네요..

모두들 굿밤하시기 바랍니다.

 

전 또 공부를 하러..

 

 

버전정보 (v1.6)

 - v1.0 2020.07.04 배포

 - v1.1 2020.07.04 다음시간 정보 추가

 - v1.2 2020.07.04 단어 수정

 - v1.3 2020.07.05 데이터 정보 수정

 - v1.4 2020.07.05 ER-Diagram 링크 추가

 - v1.5 2020.07.08 Wireframe 링크 추가

 - v1.6 2020.07.10 Wireframe&화면설계서 링크 추가

 

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

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

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

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

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

 

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com

 


에러해결 : Windows SDK 버전 10.0을(를) 찾을 수 없습니다.

(MSB8036)


간만에 git에서 프로젝트를 가져와 빌드를 하니 다음과 같은 에러가 뜨고 있습니다.

 

에러가 엄청 잡힐겁니다. 아마도...

 

심각도 코드 설명
오류 MSB8036 Windows SDK 버전 10.0.xxxxx.x을(를) 찾을 수 없습니다. 필요한 버전의 Windows SDK를 설치하거나, 솔루션을 마우스 오른쪽 단추로 클릭하고 [솔루션 대상 변경]을 선택하거나 프로젝트 속성 페이지에서 SDK 버전을 변경하세요.

 

원인

에러 그대로 Windows SDK 버전 10.0.xxxxx.x를 찾을 수 없어 일어나는 문제입니다.

 

해결

 - 프로젝트에 세팅된 Windows SDK 버전을 변경해줍니다.

  -> 방법은 속성 -> 일반 -> Windows sdk 버전 : 10.0(최근 설치된 버전)으로 변경하시면 됩니다.

   1. 프로젝트 속성에 들어갑니다.

    - 방법은 3가지 있습니다.

      1) Alt + Enter

      2) 상단 메뉴에서 [프로젝트] -> 맨 아래 [속성]

      3) 솔루션 탐색기에 속성 버튼 클릭하기 (하단 이미지 참조)

 

빨간 박스안에 있는 속성 버튼을 클릭!

   2. 일반 속성의 Windows SDK 버전을 변경합니다. : 10.0(최근 설치된 버전)

 

Windows SDK 버전을 변경합니다.

   3. 하단의 적용 -> 확인 그리고 빌드

 

빌드 성공!

 

 * 만일 위 방법으로 해결이 안된다면, Windows SDK의 버전이 맞지 않아 생기는 문제일 수 있습니다.

  이 경우 우선 developer.microsoft.com/ko-kr/windows/downloads/windows-10-sdk/ 로 이동합니다

 

Windows 10 SDK - Windows 앱 개발

Windows 10 SDK Windows 10, 버전 2004용 Windows 10 SDK(10.0.19041.0)는 Windows 10 앱을 빌드하는 데 필요한 최신 헤더, 라이브러리, 메타데이터 및 도구를 제공합니다. 이 SDK를 사용하여 Windows 10, 버전 2004 및 이�

developer.microsoft.com

 -> 설치 관리자 다운로드 버튼 클릭합니다.

페이지로 이동 후 설치 관리자 다운로드 클릭

 

  -> 다운로드 된 파일을 실행 및 설치를 해주세요. (작성 시 Windows SDK 버전 : 10.0.19041.0)

  -> 설치가 완료되면 PC 재시작을 요청합니다.

  -> 재시작을 하시고 프로젝트를 실행시켜보세요!

 

버전정보 (v1.0)

 - v1.0 2020.07.03 배포

 

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

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

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

 

Karzin

abbeea@naver.com

 

+ Recent posts