Karzin Lab

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

Wireframe&화면설계서(1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

화면설계서 - 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)_장비관리 프로세스 정의

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

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

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

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

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

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

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

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

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

사진활용도 힘들다보니 엑셀 하나의 크기가 몇십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)

 - 장비관리 Wireframe

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

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

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

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

추가적인 예정으로는 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

다원 원격 마우스 분석 / 설계 (1).

이번 분석 / 설계에는 가장 기본적인 내용인 

개발 동기, 개발 내용, 개발 목표에 대해 작성이 되었습니다.

스마트폰은 계속해서 진화를 해가고 있습니다.

덕분에 우리들은 새로운 모델에 익숙해지는데에 많은 시간을 쏟기도 하고 있습니다.

사실 급격히 진화해가는 모습은 굉장히 좋지만, 여기서 안타까운 점이 몇몇 생기곤 합니다.

그 중 저는 사용 후 남아버린 스마트폰에 대한 안타까움을 해결하고 싶었습니다.

분명 비싸게 준 스마트폰일텐데 유용한 재활용 방법은 없을까 해서 고민하게 되었습니다.

그리고 문뜩 집에서 남아 굴러다니는 스마트폰을 컴퓨터의 마우스로 활용하는 방법은 어떨까란 생각이 들어 프로젝트를 진행하게 되었습니다.

앞서 보셨던 컨셉의 내용처럼 스마트폰(어플)과 컴퓨터를 연결하여 스마트폰에서 컴퓨터의 마우스를 원격으로 조작하는 방식입니다.

전제 조건으로는 공유기를 사용하여 스마트폰과 컴퓨터가 연결이 된다는 점이며,

기본적으로 통신은 wifi 소켓통신을 이용할 예정입니다.

본 어플은 다음의 세가지 기능을 지원할 예정입니다.

 1. 노트북의 마우스패드 형식 (트랙패드)

   - 가장 널리 사용하는 해당 방법은 최대한 노트북의 마우스 패드와 비슷한 형식을 취할 예정입니다.

 2. 조이스틱 형식

   - 조이스틱 형식을 이용하여 몇몇 게임에 있어서는 스마트폰을 이용한 원격 게이밍이 가능하도록 할 예정입니다.

 3. 자이로 센서를 활용한 형식 

   - 닌텐도 Wii와 비슷하게 스마트폰을 흔들거나 이동시키면 이동하는 형식입니다. 

저의 기본적인 개발 목표는 언제나 코딩능력의 향상과 코딩시 틀에 갖힌 사고보다는 창의력을 앞서 새로운 코드를 짜는 것을 목표로 하고있습니다.

쉽게 말해 공부가 프로젝트를 진행함에 있어 저의 가장 큰 목표입니다.

그래도 그 중 해당 어플 개발에 있어서는 높은 정확성과, 끊김없는 통신을 목표로 두고 개발해 나갈 예정입니다.

물론, 쉽다고 할 수 없는 개발 내용들이지만, 조금씩이라도 개발을 해 나가며 최대한의 완성도를 낼 수 있도록 노력할 예정입니다.

다음시간엔 분석/설계(2)에서 뵙겠습니다.

감사합니다.

오늘은 분석 2번째 시간을 가져보겠습니다.

사실 이번시간에는 저번시간에 미리 말씀드린대로 오픈되어있는 ERP를 검색해서 해당 소스들을 분석해 보려 했습니다...만, 제 안 좋은 습관 중 하나가 아직 답도 안잡혀있으면서 답을 먼저 보려고 한다는 점입니다.

항상 답을 먼저 보고나면 흥미를 잃고 그 이후에는 정해진 답이라는 틀에 갇혀 다른 답을 못낸다는 점입니다.

분명 공부를 하기로 했지만, 너무 답에 연연하지 않고 제가 생각하는 답을 찾아서 가는 형식을 취하기로 했습니다.

물론, 제가 원하는 ERP가 추구하는 방향이 기존 ERP와는 많이 달라진다하더라도, 제 자신만의 답을 찾아볼까 했습니다.

(공부에 답이 없다고 생각합니다. 다만, 답이 없는 만큼 답이라고 해도 될 정도로 철저하게 하는게 맞다고 생각합니다.)

여담이 길어졌네요. 여담은 나중에~ 나중에~ 나중으로! 미루고!

오늘의 주제로 돌아가보도록 하겠습니다.

저는 ERP에 있어 가장 중요하다고 생각하는 부분은!

물론 돈(회계)이 가장 중요할 순 있겠지만, 저는 사람(인사)이라고 생각합니다.

사람관리가 잘 되는 회사여야만 회사가 잘 돌아간다는 거죠.

왜 이런 주제랑 다른것같은 이야기를 하느냐? 주제에 일치합니다!

저는 인사가 가장 먼저 개발이 이뤄져야하지 않을까 싶었습니다.

제가 생각하는 인사의 기본적인 정보(사원 기본 테이블)는 다음과 같습니다.

 - 사원 ID (고유해야함) [not null, key]

 - 사원 이름 (중복 가능 - 이름이 같은 사람은 분명 있습니다!) [not null]

 - 사원 생년월일 (중복 가능 - 생일 축하?) [not null]

 - 사원 입사일 (중복 가능 - 입사일로 부터 기간을 계산) [not null]

 - 사원 휴대폰 번호 (중복 불가) [null : 워라벨을 중시하는 현시점에서 연락은 하지 말도록 합시다!]

 - 사원 집 전화 번호 (중복 가능 : 부부일 수 있다. 룸메같이 같은 집에 살 수 있다.) [null : 집전화를 사용치 않는 경우 상정]

 - 사원 집 주소 (중복 가능 : 부부일 수 있다. 룸메같이 같은 집에 살 수 있다.) [null : 워라벨! yeah!]

 - 사원 최종 학력 (중복 가능) [null : 개인정보!]

두번째로 사원의 부서 직급 정보(사원 부서 직급 테이블)입니다. (지금은 인사만 분석하므로 부서, 직급테이블은 나중에 따로 언급하겠습니다.)

 - 사원 ID (고유해야함) [not null, key]

 - 부서 ID (중복 가능)

 - 직급 ID (중복 가능)

세번째로 로그인 권한 정보(사원 로그인 테이블)입니다.

 - 사원 ID (고유해야함) [not null, key]

 - 사원 passwd (보안설정되어있음.) [not null] * 패스워드 정보는 외부에서 볼 수 없습니다.

 - 사원 마지막 로그인 이력 (로그인시마다 업로드, 중복 가능) [not null - 첫 로그인 전이라면 0000년 00월 00일 00시 00분 00초 등으로 초기화]

 - 사원 마지막 로그아웃 이력 (로그아웃시마다 업로드, 중복 가능) [not null, 로그인 이력과 동일]

네번째로 사원 출퇴근 관리 이력(사원 출퇴근 관리 테이블(log))입니다. (야근을 파악 할 수 있습니다.)

 - 출퇴근 정보 (출근, 퇴근) [not null]

 - 날짜

 - 시간

 - 사원 ID

 - 부서 ID

다섯번째로 게시판 권한에 대한 정보(사원 게시판 권한 관리 테이블)입니다.

 - 사원 ID (고유해야함) [not null, 외래key]

 - 마스터 자격 (boolean, true인 경우 모든 게시판의 권한을 가지고 있습니다.) [not null(true or false)]

 - 시스템 관리 게시판 권한 ID (중복 가능) [not null]

 - 인적자원관리 게시판 권한 ID (중복 가능) [not null]

 - 기업 서비스 관리 게시판 권한 ID (중복 가능) [not null]

 - 프로젝트 관리 게시판 권한 ID (중복 가능) [not null]

 - 공급 사슬 관리 ID (중복 가능) [not null]

 - 고객 / 상품 관리 (중복 가능) [not null]

 - 재무 관리 (중복 가능) [not null]

 - 제조 관리 (중복 가능) [not null]

사원 게시판 권한 관리 테이블의 경우 각 게시판 별로 더 쪼개둘 생각입니다.

이런 경우를 상정해 보고 있어 나눴습니다._(모든 인원은 자신의 휴가 관리를 할 수 있으나, 충원이나, 급여관리와 같은 정보는 인사과 혹은 회계과가 아니면 볼 수 없게 하기 위함입니다.)

혹은 읽기 권한이 필요하지만, 쓰기 권한은 필요하지 않은 경우. (높은 직급의 개발자가 아닌사람은 프로젝트 관리에서 쓰기권한이 필요하지 않습니다. 읽기 권한을 통해 프로젝트를 확인할 수 있습니다.)

- 시스템 관리 게시판 권한 ID (고유해야함) [not null, 외래key]

- 사용자 관리 권한 (읽기, 쓰기)

- 시스템 관리 권한 (읽기, 쓰기)

- 환경설정 권한 (읽기, 쓰기)

동일하기 인적자원관리 권한

 - 인적 자원 관리 게시판 권한 ID (고유해야함) [not null, 외래key]

 - 충원(인사관리)

 - 혜택

 - 급여관리

...

등등...

위처럼 게시판마다 권한 ID를 부여하는 이유는 사원 A와 사원 B가 같은 게시판에서 같은 권한을 가지는 경우

같은 게시판 권한 ID를 부여하여 관리하기 용이하기 위함입니다.

마지막으로 사원의 급여 정보 (사원 급여 테이블) 입니다.

 - 연봉 협상일 (기본key (사원 ID와 합쳐 기본key))

 - 사원 ID (기본key (연봉 협상일과 합쳐 기본key))

 - 연봉 정보

 - 기본 월급 정보 (연봉 / 12)

 - 세금 정보

 - 실 수령 월급 정보 (기본 월급 정보 - 세금 정보)

 - 인센티브

 - 추가금액 (야근 등)

연봉협상일 + 사원ID를 기본 키로 한 이유는 기존 연봉협상일에서 현재 연봉협상까지 연마다 쌓여가면서 사원의 연봉이 얼마씩 올랐는지 파악을 가능하게 했습니다.

특히 이렇게 하는 이유중 하나는, 특별히 어느 한사람이 한사람몫 이상의 일을 할 경우, 또 경험자인 경우에 어느정도 씩 추가적인 연봉의 협상이 이뤄졌는지 파악이 가능하게 하기 위함입니다.

아직까지도 파악해야할 부분이 많이 남아있습니다.

실제로 위 정보들중에서는 더 추가해야할 부분도, 빠져야할 부분도 있다고 생각이 듭니다.

계속해서 분석을 통해서 더 다듬어 나갈 예정입니다.

다음은 설계(2)에서 뵙도록 하겠습니다.

설계(2)에서는 ER-다이어그램을 제작하여 기본적인 인사정보의 DB 정보를 살펴보도록 하겠습니다.

>> 문의 등의 정보 제공은 댓글을 달아 주세요.

버전정보

 - v1.0 2018.09.17 배포

 - v1.1 2020.06.12 다원ERP -> Project.다원ERP로 변경

저는 2년제 대학(컴퓨터정보과)을 졸업하고 4년제 대학(컴퓨터공학과)에 편입하여 현재 대학원(컴퓨터과학)에 다니고 있습니다.

현재진행형으로 5년간 컴퓨터 관련을 다니다 보니 프로그래밍언어를 어렵다고만 생각하는 분들이 많은 것 같아 아쉬운 나머지 게시글을 작성하게 되었습니다.

처음 대학에 들어오면 프로그래밍 언어에 대해 여러가지를 공부를 하게 됩니다.

C언어, C++, 자바, 자료구조 등등..

배울언어는 한개도 아니면서 자료구조, 분석/설계, 공학 등등 뭐가 이리도 많은지.

배우고 있는 지금도 어렵고 힘들지만, 정말 처음부터 어떤걸 배워야할지 망설여지더라구요.

그리고 처음으로 듣는 강의, 처음으로 뱉는말. "뭐가 이렇게 어려워!"

강의를 신청하고 처음듣는 강의는 어렵고 귀에는 들어오지도 않고, 내주시는 과제는 뭐가 그리 어려운지..

그저 한숨만 먼산만 바라보게 되는 상황이 일어나기 쉽상이었습니다.

저와 같은 분들을 위해서 조금이라도 도움이 되었으면 하는 게시글. 자전거를 이용한 언어의 이해. 시작합니다!

언어의 기초를 배우다 보면 클래스, 변수, 상수............

어렵기만한 언어를 자전거를 분석하고 만들어가며 조금이나마 쉽게 배워가도록 하겠습니다.

(개인적인 공부법이므로 다른 책들과는 많이 다를 수 있습니다. 질문은 댓글을 달아주세요.)

[이미지 출처 - karzin(직접제작)]

여기 자전거가 한대 있습니다.

이 자전거를 프로그래밍으로 구현하려면 뭐부터 시작해야할까요?

저는 역시 '분석'부터 시작할 것 같습니다.

분석은 프로그래밍을 시작하는데 있어 기초라고 저는 생각하고 있습니다.

자, 그럼 분석을 위해 자전거를 자세히 바라봅시다.

우리가 만들 자전거에는

운전을 위한 '손잡이'가 있고,

사용자가 앉기 위한 '안장'이 있고,

앞으로 나아가기 위한 두개의 '바퀴'가 있고,

사용자의 동력을 전달할 '페달'이 있고,

마지막으로 이 모든 부품들을 하나로 묶어주는 '바디(프레임)'이 있습니다. 

그리고 마지막으로 자전거를 앞뒤로 옮겨줄 동력원인 사람이 필요하겠죠.

이정도면 기초적인 프로그래밍을 위한 분석이 완료된 것 같습니다! 

과연 이 분석은 분석으로써는 몇점일까요?

글쎄요.. 그럼 다음으로 넘어가 볼까요?

[이미지 출처-karzin(직접제작)]

학부시절 프로그래밍언어를 공부하면서 초반부터 포기하는 친구들이 무척이나 많았습니다.

친구로써, 동기로써 너무나도 안타깝기만 했었습니다.

그래서 준비해보았습니다! 언어를 조금 이해하기 쉽게 풀어써보자고!

물론, 지금의 저도 그렇게 언어를 이해하지는 못했습니다. 

아직도 모르는 것 투성이고, 개발함에 있어 함수들의 검색은 필수로 하고 있는 수준이니까요.

그래도, 공부하는 블로그에서 나도 공부하고, 보고계신 모든 분들도 공부가 되면 좋겠다는 생각은 언제나 같습니다.

그래서 어려운 프로그래밍 언어를 조금이나마 어렵지 않게하는 게시글들을 주저리주저리 써볼까 합니다.

얼마나 많은 도움이 될까도 싶지만, 한번씩 읽어보시고 유익하셨다면 댓글 꼭 남겨주세요!

열심히 해보겠습니다!

분석 게시판을 만들었습니다.

원래 분석하는걸 좋아하다보니 학부시절에도 분석해서 설계하는걸 굉장히 좋아했었습니다.

사실 공지사항이라 하기는 조금 애매한 부류긴 하지만,

나눠놓는게 좋겠다 싶어서 나눠두었습니다! (무슨 의미가 있을진 모르겠지만, 나중을 위해,.,?)

조금 어이없다 싶은 분석부터 이런것도? 싶은 분석까지 여러가지 주제를 잡아서 분석을 해보고 싶어 만들었습니다.

많이 부족하겠지만, 많은 댓글 부탁드리겠습니다.

감사합니다.