깔끔하게 휴식을 마치고 와서 그런지 그나마 머리가 말끔해져서 오늘은 Wireframe을 소개해볼까 합니다. (?! 갑자기 ?!)
사실 제가 쓰는 이런 설계단의 문서들은 어려워하시거나 모르시는 분들이 많을 수 있습니다.
개발을 진행하시는 분들은 문서를 받아서 볼 수 있겠지만, 보기보다는 그냥 고객의 설명이나 상급 개발자의 설명만 듣고(회의 등) 변경된 내용으로 진행하는 경우가 많은 것 같더라구요.
그만큼 폭포수 모형보다도 애자일 방식을 택하는 기업도 많다는 의미이기도 하구요. (Prototype 만들고 수정하고 반복적인..)
사실 이 설계라는게 생각보다 시간도 잡아먹는거기도하고, 개발자에게 대충 '대략적인 혹은 완성된 UI' 그림만 던져주면 된다! 이런 부분이 없지않아 있어서 개발자는 그 대략적이거나 완성된 UI를 시작으로 개발-수정작업을 거쳐 완성본을 만드는 경우가 많은 것 같습니다. (ㅠㅠ)
저는 개인적으로 이런 부분들을 보완하고자 제가 개발하면서 개인적으로 만드는 문서들이기 때문에 어려워하시거나 잘 모르시는 분들도 많은 것 같습니다.
(사실 잘 찾아보면 소프트웨어 공학적인 부분에서 많은 내용을 찾아볼 수 있지만.. 개발 문서가 우선이다보니..)
근데 웃긴 사실은 이런 문서를 미리 만들어 두면 몇번의 수정만 거치면 완료 보고서 제출시에 편리해진다는 점이 장점이있습니다. (우려먹기? ㅋㅋㅋ)
또 설계서가 있는 만큼 개발을 진행해야하는 사람들에게도 이렇게 개발을 해야한다! 라는 프로젝트 개발 가이드 라인이 잡히다보니 같이 개발하는 동료나 후배들에게 입아프게 말할 필요도 많이 줄어 만족도는 꽤나 높은 편입니다. (개인적으로는 말이죠 ㅋㅋ)
물론 이해가 안되는 부분은 커뮤니케이션을 진행해야하지만 말이죠 ㅎ
음.. 벌써부터 말이 너무 많네요. 이런 주저리 거리는 부분은 본론에 들어가서 추가적으로 하도록 하고! 지금! 바로! 본론으로 들어가보겠습니다.
Wireframe?
Wireframe...? 그게.. 뭐예요...?
협업 중에 있어서도 Wireframe의 존재를 잘 모르시는 분들은 생각보다 많습니다.
그만큼 분석 및 설계시에 화면설계로 바로 넘어가는 경우는 많아도, Wireframe을 잡고 넘어가는 경우는 생각보다 드물기 때문에(ㅠ..ㅠ) 이런 경우가 생각보다 많이 발생하는 것 같습니다.
음.. 화면설계가 나오면 그나마 낫긴하지만, 이보다 더 심각한건 Wireframe이 확정되지 않은 상태에서 바로 디자인을 진행하는 경우는 생각보다 여러모로 힘들어집니다. (이러한 경우 Wireframe이 불안정하다보니, 바로 디자인을 시작하는 경우 여러번의 디자인 변경을 체험할 수 있습니다... 심한경우에는 서로의 이해관계가 통하지 않아 만족도가 낮은 완성본이 나올 가능성도 있습니다.ㅠㅠㅠ)
이런 경우 UI를 디자인 하는 디자이너, UI 목업이나 화면설계서만 보고 개발을 진행하던 개발자는 날마다 다크써클이 생겨나기 일쑤입니다. ㅇ_ㅇ;;;
이런 변경을 초기에 잡는 방법 중 하나가 개인적으로는 Wireframe이라 생각합니다.
그래서 Wireframe이 무엇이죠?
우선 어려운 내용들 다 접어두고 쉽게 설명하자면 기본 설계를 위한 '뼈대'입니다.
Wireframe을 잡아주면 거기에 쌓아 올리는 디자인적 요소든 개발적 요소든 어느정도 기본적인 '뼈대'가 잡혀있기 때문에 이후 구조적인 요소에서는 큰 변동사항이 거의 없어지게 됩니다.
사실 그 내면을 들여다보면 기획적인 요소가 조금 섞여있을 수 있는데, 이는 프로젝트의 제작을 원하는 사람의 생각을 '명확'하게 해주는 작업이기 때문에 그럴겁니다.
이 '명확'해진 '뼈대'위에 *구조물을 쌓아올리는 작업이 바로 디자이너와 개발자의 협업을 통한 분석-설계-개발이 진행 되는 거죠.
그만큼 Wireframe을 잡는건 굉장히 어려운 작업이기도 하지만, 한번 확실하게 잡아진 Wireframe 하나만 있으면, 이후 분석 설계 디자인 등은 굉장히 편리하고 빠르게 넘어갈 수 있습니다.
음.. 이렇게 말로만 하면 어려우니까 이쯤에서 비장의 카드 이미지를 넣어봐야겠네요.
직접 보시죠!
백문이 불여일견
백번 듣는거보다 한번 보시죠!
Wireframe (장비 관리 - 장비 등록)
장비관리 Wireframe, 만든이 : Karzin
위 이미지는 제가 Project.다원 Ensemble을 진행하면서 그렸던 Wireframe입니다. (참고 링크)
사실 여기에는 제 개인적인 개발적 요소들이 들어가기도 했는데(Component의 종류), 이 문서 하나로 기획을 했던 저의 아이디어를 종합하고, 어떤식으로 개발을 해나가야할지 미리 '뼈대'가 잡아지고, 이렇게 진행을 해야겠다는 정보가 그림 하나로 완성이 된겁니다.
'뼈대'가 어느정도 작업이 완료되었다면, 이제 화면설계서가 굉장히 빠르게 나올 수 있는데, 이 화면설계서까지 나오면 사실 개발자에게 있어 이런 확정된(화먼설계서) 내용을 만드는 작업만큼 쉬운일은 또 없을겁니다.
그럼 Wireframe을 토대로 만들어진 화면설계서를 잠깐 구경을 해보실까요?
화면설계서(장비 관리 - 장비 등록)
장비관리 화면설계서, 만든이 : Karzin
화면설계서를 어떻게보면 한단계 위의 Wireframe과 비교를 해보면 크게 변경된 내용은 없어보입니다.
하지만 좀 더 그 내부를 살펴보면 Button Component는 '등록'이라는 text가지정되어 변경되었거나, 이외에도 각 Component들의 사용의 예시를 보여줌으로써 개발자는 Wireframe과 비교를 해가며 알맞는 개발 Component를 선택하여 개발해 나갈 수 있게 해주는 것을 알 수 있습니다.
사실 이런 부분들이 제 입맛대로 바꾼 부분이 있어 조금 변칙적일 수는 있으나, 저의 경우 'Wireframe'단에서는 어떠한 Component를 사용할지 명확하게 뼈대를 잡아주고, 이후 해당 화면에 DB를 연동했을 때 어떤식으로 화면에 보일것인지를(뿌려줄 것인지를) '화면설계서'를 통해서 보일 수 있게 화면설계서를 마치 Prototype인 마냥 설계를 진행하는데, 이렇게 해주면 좋은점이 개발자 입장에서는 이 정도의 설계서만 있으면 이후에는 걱정없이 개발에만 집중할 수 있다는 점입니다.
물론 제가 진행중인 개인 프로젝트에서는 Wireframe과 화면설계서만으로 개발을 진행하지만 이는 기본적으로 Bootstrap을 사용함으로써 어느정도 디자인 단계를 보완할 수 있는 부분이라서 그런거기도하지만, 사실 여러가지 따지자면 디자인도 들어갈테고, Diagram같은 좀 더 개발의 기초를 잡아주는 부분도 있을 수 있으나, 이러한 부분들은 디자이너나 개발자간에 서로 협업(커뮤니케이션)을 하며 어떠한 디자인을 어떠한 로직으로써 어떻게 구현을 할지 머릿속에 상상하며 그려가야하는 작업이라고 생각하기 때문에, 자세한 언급은 삼가했습니다. (또 주저리주저리 말만 길어져서 다들 졸리게됩니다 ㅠㅠ)
이처럼 Wireframe을 한번 그려두면 자신의 생각을 남들에게 명확하게 전달할 수 있기 때문에 좀 더 자신이 원하는 프로젝트로 진행이 될 수 있는데, 물론 아쉬운 부분이 생길수 없다는 보장은 못하지만(기술적 요소 등으로 Wireframe대로의 개발이 힘든 경우 등등), 서로간 계속되는 커뮤니케이션을 통해 보완을 해나간다면 마지막에는 기획물에 걸맞는 마음에 드는 결과물을 뽑아낼 수 있습니다.
그만큼 Wireframe 자체가 굉장히 중요하기도 하구요.
* 위에서도 언급했지만(개발적 요소-Component의 종류), 항상 그렇듯 저는 제 개인적인 입맛대로 문서작성을 진행하기에 기존 Wireframe보다 변칙적인 부분이 많을 수 있습니다.
* 이는 제가 좀더 개발자의 측면에서 바라보는 부분들과 개인적인 경험들을 토대로 변칙적인 부분으로써 발전한거이므로 양해부탁드립니다 ㅠ
그럼 Wireframe은 누가 만들어야 하나요??
이쯤오면 궁금해질겁니다. Wireframe은 매우 어려워보이는데 누가 만들어야할까요?
그 내면을 깊이 파고들면 Wireframe은 기획적인 요소가 많이 들어가 있기 때문에 기획자가 만들면 기획자가 원하는 굉장히 고퀄리티의 결과물을 뽑을 수 있을겁니다.
하지만, 생각보다 Wireframe을 쉽게 보기란 힘들 수 있는데요, 저는 생각합니다. 이럴때는 바로 유비무환(有備無患)이라는 사자성어가 있습니다.
그냥 누가 되었든 미리 준비해두시고 confirm을 받아야할 담당자에게 보여주는겁니다!
'우리는 지난 회의를 통해 이렇게 뼈대를 잡았으며, 때문에 담당자님께 이대로 진행해도 될지에 대해 confirm을 요청합니다. 맘에 드신다면 이대로 분석-설계-개발이 진행될 것입니다.' 라고요!
사실 이러한 경우에는 대체적으로 담당자에게도 아직 확고한 '뼈대'가 없거나, 어떻게 만들어야할지를 모르는 경우가 대다수입니다. 이럴때 이런식으로 만드려 하는데 진행해도 괜찮을까요? 라고 연락이 오는 만큼 반가운일은 특히나 없을겁니다.
분명 담당자는 확인을 하고 자신이 생각한(그려본) 내용과 비교를 해가며 어느정도의 피드백과 커뮤니케이션이 오가다보면 확고하게 '뼈대'가 잡혀나갈겁니다.
그만큼 커뮤니케이션에 시간이 많이 걸릴수도 있지만, 이런 확실한 '뼈대'가 완성되는 순간에는 분명 담당자에게 있어서는 굉장히 좋은 결과물로 남을 것입니다.
Wirframe의 장단점
마지막으로 Wireframe을 사용함으로써의 장단점을 한번 보시죠!
음.. 우선 단점부터 이야기해보겠습니다.
- 시간적 Cost
- 명확함의 어려움
하나씩 잡고 설명을 해보자면
첫번째로 시간적인 비용이 있습니다.
기획자-디자이너-개발자 간 서로의 커뮤니케이션으로 인해 잃을 수 있는 시간적인 비용을 말하는건데, 사실 이는 명확한 Wireframe의 설계로 분석/설계 단계에서 더 많은 시간적인 비용을 절약할 수 있어 어찌보면 양날의 검같은 존재입니다. 사실 이러한 부분은 제가 생각하고 경험하기로는 중간의 PM역할이 가장 중요하다고 생각을 하는데요, 커뮤니케이션의 중간에 서서 시간의 비용을 최대한 절약할 수 있는 방법을 숙련된 자신의 경험 등을 사용해 저울질해가며 작업을 원활하게 진행을 해주는 부분으로, 앞서 이야기 나온것처럼 경험에서 우러러 나오는 부분이 아닐까 생각하고 있습니다.
그만큼 분석/설계단계에서의 작업이 더뎌진다면 개발은 더더욱이 미뤄지게 될테니 시간적인 요소를 꼭 체크해가면서 커뮤니케이션을 하는게 가장 중요하지 않을까 합니다.
두번째로는 명확함의 어려움이 있습니다.
사실 명확하다는 말처럼 또 어려운게 어딨을까 싶네요. 말이 명확하다일뿐이지 보는 시각에 따라 명확하지 않음은 분명이 나타날테니 말이죠. 이러한 부분의 해결은 사실상 위에서 말한 커뮤니케이션을 통해 해결을 해나가는 방법밖에는 없다고 생각합니다. 분명 기획-디자인-개발- 등등 여러 관점에서의 시점은 각각 다르니까요.
그럼 이번에는 장점을 이야기해보도록 하겠습니다.
- 시간적 Cost
- 이후 작업이 용이 (스무스)
- 인력의 최적화
- 백문이 불여일견
첫번째 시간적인 비용부터 설명해보자면, 위의 단점처럼 장점과 단점이 될 수 있는 양날의 검인 부분입니다.
그만큼 잘 저울질해가면서 최상의 시간적 비용을 들이고 원하는 프로젝트로 이끌어가는 방법을 찾아가야하는게 최우선이라 보여집니다. 이런 부분은 어쩔수 없이 저에게는 부족한 경험에서 우러러나오는 부분이기 떄문에, 결국 조율은 경험자에게 유리할 수 있다 보여집니다.
두번째로는 이후의 작업이 용이(스무스)해진다는 부분입니다.
잘 만들어둔 Wireframe만 있다면, 이후 분석/설계문서는 기획의 의도가 정확하게 파악이 되었기 때문에 스무스하게 작업이 진행이 된다는 겁니다. 또 그만큼 잘 제작이 되었다면 개발까지도 큰 이슈없이 진행이 될거고, 빠른 Prototype이 나옴으로써 기획을 한 담당자도 검토를 통해 개발진등은 어느정도의 기간내 수용가능한 기능 변경이나 디자인 변경까지도 가능하다는 장점이 있을 수 있습니다. 물론 이런 기능이나 디자인의 변경에 한해서는 민감한 부분이 많이 있어서 변경에 대한 작업진행시에는 어느정도 서로의 커뮤니케이션을 통한 이해관계가 꼭 필요하겠지만 말이죠.
세번째는 인력의 최적화입니다.
인력이 많다면 분명 개발은 빠르게 진행될 수 있겠지만, 그렇다고해서 오버해서 넣을 필요는 없는 프로젝트가 많을텐데요, 이러한 경우 개발을 위한 설계문서가 제대로 잡힌다면 인력의 최적화 또한 이루어지게 됩니다. 해당 부분도 사실 경험자가 필요한 부분이긴 한데, 미리 각 인력의 시간당 개발 진행도를 미리 파악하고 알아둘 필요가 있고, 어느정도 파악이 된 경우 설계문서에 맞춘 각 개발인력을 최적화해서 배치할 수 있어 개발 인력을 정말 최적으로 부려(??)먹을 수 있습니다. 경험자가 필요한 만큼 이는 PL이나 PM의 역할이 중요한데, 그만큼 자신이 관리하는 인력의 실력등을 미리 파악하는 시간이 필요할 것입니다.
네번째로 백문이 불여일견입니다!
사실 이걸 저는 큰 장점으로 뽑고는 있는데, 이는 기획자의 의도를 백번의 말보다도 한번의 Wireframe으로써 상대방을 이해시킬 수 있다는 부분입니다. 우리는 커뮤니케이션을 진행할 때 항상 문제시 되는 부분은 서로 다른 성격의 사람들을 '이해'시켜야한다는 부분일겁니다. 자신의 의도를 명확하게 알려주고 상대를 이해시킴으로써 더 좋은 퀄리티의 프로젝트 완성물을 탄생시키는 것이죠. 사실 이러한 부분은 쉬운부분이 아닌만큼 굉장히 중요한 부분으로 자리잡고 있는데, 백번의 말보다 한번의 Wireframe으로 해결이 된다면? 이처럼 좋은 해결방법은 또 없을겁니다. (물론 이런 부분은 Wireframe의 완성도나, 추가적인 커뮤니케이션이 있을 수 있으나, 여러번의 커뮤니케이션을 최소화할 수 있는 좋은 방법이라고는 생각합니다.)
이처럼 우리에게 당장 필요한건 개발도 중요하지만, 분석/설계를 제대로 할줄 아는 기술도 중요하다고 생각합니다.
오늘은 Wireframe에 대해서 잠깐(???) 설명하는 시간을 가져봤는데, 좀 더 이미지를 많이 넣어서 졸음 방지를 해드릴껄(???) 하는 글이네요.
슬슬 졸음이 몰려올 시간일거라 오늘은 이쯤에서 마무리를 하도록 하겠습니다~
쓰면서도 알았지만 말 진짜 많이썼네요.
누가보려나 싶을정도로요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
글을 읽어보시는 분들에게 큰 도움이 되려나 모르겠지만 되었으면 좋겠네요.
음.. 그래도 개인적인 경험과 공부를 토대로 작성을 하다보니 프로그램쪽으로 진출하는 새내기들에게는 조금이나마 유익한 글이 되지 않을까 싶습니다. 저 꼬꼬마때는 개발도 개발이지만, 기획단계부터 시작해서 분석이나 설계 등등 이런한 글을 읽어보고싶었는데, 없었어가지구.. Google에 'JAVA OOO만들기' 같은건 검색하면 쉽게 쉽게 나온다지만, 이런 기획부터 설계관련 이야기를 풀어놓은곳이 (제가 찾아봤을땐) 없었거든요.ㅠㅠ 제가 가진 경험과 공부한 내용들을 토대로 짜집기해서 머릿속에 나온거라 많은 부분 부족할 수 있지만, 한번쯤 읽어보시면 유익할거라 생각듭니다.
혹시 수정해야할 부분이라던가 있으면 댓글이나 메일주시면 확인해서 수정해두도록하겠습니다.
물론 질문도 항상 받고 있구요~
그럼 오늘 하루도 고생 많으셨습니다!
버전정보 (v1.1)
- v1.0 2020.07.28 배포
- v1.1 2020.07.28 장점에 새로운 항목 추가
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
휴.. 밥먹고나서 샤워하고 부지런히 만들기시작해서 드디어 끝났습니다! (지금시각 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)
장비관리 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)
장비관리 - Class Diagram (2/3)
- MainController : 메인 페이지를 보여주기 위한 Controller입니다.
- CommonRestController : 모든 페이지에서 사용가능한 공통적 RestController입니다. 현재 Code, File을 Common형식으로 보고 있습니다.
사실 고객도 저이고, 개발자도 저인 이상 어느정도 제 머릿속에 정립된 시스템은 바뀔일이 없다보니 거의 빠꾸는 없겠지요.. 다만, 개발하다가 막히는 부분이라던가, 문제가 생겨 바뀔수밖에 없는 부분에 대해서는 로직이 바뀔뿐이지 보이는 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.다원 원격키보드 : LikeKeyboard (라키)
아마 이렇게 지은 이름은 키보드 같이! 라는 식으로 지은 것 같습니다 ㅋㅋ (맞는지는 그시절 나에게 물어야..)
이제야 생각나지만, 아마 이게 Project.다원의 가장 첫번째로 혼자 만든 기획-분석-설계-개발 시스템이었을겁니다. (미완성으로 끝났지만)
만든지도 오래됬고, 그때 이후로 컴퓨터 폴더 구석탱이에만 남아있었으니 (아마 학부시절 폴더들 쫙 까보면 별별거(혼자서 만든 기획, 분석, 설계, 개발 등등) 다 나올겁니다 ㅋㅋㅋㅋㅋ) 간만에 학부시절 아이템(?)들이나 구경해보자 한게 어쩌면 득이되었네요. 오늘도 이렇게 몇년전의 자신을 떠올리며 용기얻고갑니다 ㅋㅋㅋㅋㅋㅋ
말이 좀 옆으로 샜지만, 오늘은 많은 걸 다룰건 아니고,
예전버전 기획서를 조~끔 리메이크해서 다시 작성해봤습니다. ㅋ_ㅋ
리메이크 전과 후를 비교해가면서 보시죠. (정말 별 작업은 안했습니다. ㅋㅋ;;)
예전버전의 Project.다원 원격키보드 - LikeKeyboard
예전버전 LikeKeyboard
아마 이게 학부시절에 스타트 끊었던 Project.다원이었을겁니다.
학부시절이니까 지금으로부터.. 음... 4년전? 5년전? 쯤? 될겁니다. (상황에 따라 6년 전?)
그때부터 생각해뒀던건데.. 아마 위에서도 언급했다시피 편입하고 모든 과목을 전공으로 꽉 채워서 들어야만했고, 공부도 공부지만 2년 내에 졸업작품을 마무리해야한다는 사명감? 같은게 있어서 정신없어서 틈틈히 만든다는게 그때문에 아마 못했을겁니다.
이 기획서를 조금 잘 만져서 활용하자 싶어서 다시금 만질만질(???)해놨습니다.
웃긴건 누가 내 자신 아니랄까봐 그때도 나눔스퀘어Bold체를 사용했다는게... (소름)
새로운 버전의 기획서에 들어갈 LikeKeyboard
새로운 LikeKeyboard
바뀐건 별거 없습니다.
'다' 라고 적혀있던 로고는 한글로 '다원'으로 변경이 되었고,
'Project Dawon'에서 'Project.다원'으로 변경되었습니다.
사실 '다원' 부분에 기존에 적혀있던 '다'라는 글자는 다원의 첫글자만 따서 넣어둔거였는데.. 너무 촌스러워서 (...)
Project Dawon의 경우에도 순 우리말로 했으니그 의미와 본질을 생각해서 'Dawon'이 아닌 '다원'이 맞다고 생각해 변경했습니다.
그리고 중요한 #2
이건 Project.다원의 2번째 개발 시스템이라는 거죠.
원래는 #1인 이유가 학부시절 처음으로 개인 프로젝트를 만들었던거라.. (비공식, Private)
지금은 공식으로 게시글도 올리고, 이제는 #1으로는 ERP Ensemble이 있으니 #2로 변경하였습니다.
LikeKeyboard - 개발 내용 v1
LikeKeyboard - 개발 내용 v1
흠.. 보면 아시겠지만 그때도 단색과, 미니멀리즘? 비스무래한 저만의 디자인을 고집했었습니다.
지금도 생각나지만 도대체 저런 PPT양식은 어디서 구해오니? 라고 교수님께 들었을때 제가 직접 만듭니다 라며 패기있게 말을 했었던 생각이 나네요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
(믿거나말거나 교수님도 굉장히 맘에 들어하셨습니다.)
특히 저는 글자크기를 최대한 키우는걸 좋아하는데, 이유는 의외로 프레젠테이션을 띄워놓으면 안보인다고 하시는 분들이 많아요. 그래서 글자를 최대한 키울 수 있도록 노력합니다.
옛날 이 디자인 그대로 갈까 하다가, 아무래도 정성도 있고하니까 바꾸자해서 바꿨습니다.
(예전의 나의 느낌과는 다른 느낌으로!)
** Computer과 Android 픽토그램은 오픈된 이미지 소스를 이용했었습니다. 다만, 해당 소소의 출처가 명확하게 파악이 되질않아 사각도형에 img label로 대처를 하였고, 아래 개발내용v2에서는 변경을 하였습니다.
LikeKeyboard - 개발 내용 v2
LikeKeyboard - 개발 내용 v2
음.. 그냥 바꿨습니다 많이는 안바꾸고 뭐랄까 템플릿만 쪼오끔 바뀐정도?
자, 여기서 개발내용을 잠깐 설명하겠습니다.(갑자기?)
개발 내용을 자세히 보시면 Android폰이 서버 역할을, Computer이 클라이언트 역할을 하도록 잡혀있는데, 이는 오류가 아닌 제대로된 내용이 맞습니다.
왜 이렇게 했느냐? 학부시절의 저는 Android폰으로도 충분히 서버 역할이 가능하다 생각했었고,(지금의 폰성능을 보면 그이상도 가능하지않을까 싶네요) 그렇기에 실험적인 요소로 Android폰을 서버로 돌리려고 했었습니다.
뭐.. 그렇게 중요한건 아니지만, 아마 이 부분은 추후 Android폰에서 제어할 클라이언트들을 관리하려고 하지 않았을까 싶습니다.
그래서 실험적요소도 재밌고 뭔가 또 즐거운게 생길 것 같아서(??? 두근두근 ???????)
그대로 가기로 했습니다. (씬남!!)
** v1에서는 학부시절에 찾았던 오픈된 이미지를 사용했었으나, 해당 출처가 명확하지 않아 제거를 하고 변경했습니다.
마지막으로 그시절 Project.다원의 로고
Project.다원
이건 기획서와는 조금 관련이 없을지도 모르겠지만,
저 학부시절 Project.다원의 로고였습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ
지금도 어디선가 사용했었고, 나쁘지 않아서 그대로 긁어왔네요 ㅋㅋㅋㅋ
저 디자인이 그때거였구나 ㅋㅋㅋ 재밌네요 ㅋㅋㅋㅋㅋㅋㅋ
아마 특별히 문제되지 않는 이상은 이대로 진행될 것 같습니다.
아무래도 학부시절 저의 폴더들은 노다지인 것 같습니다.
언제 한번 기회봐서 제가 작업한 졸업작품이나 과제하면서 만들었던 설계서 같은 것도 보여드리면 좋겠는데, 다음기회를 노려보도록 하죠. (언젠가는..)
버전정보 (v1.0)
- v1.0 2020.07.13 배포
* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.
* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.
* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.
* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.
* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.
Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등
그래서 빠르게! 오늘 할 수 있는 부분만 정리하고 일찍 잠 좀(...) 자려고 합니다! (그러는 지금 시간은 0시 4분...)
아마 오늘 한 부분은 졸면서, 또 일단 주먹구구식으로 한 부분도 있어서 추후 변경될 부분이 많이 있을 것 같습니다.
무엇보다 이것저것 요구사항이 늘어지다보니 타협이 잘 안되더라구요. (자신이 자신한테 많은 요구사항을 던지다니..)
그래도 개발을 진행하기 위해서는 미뤄지면 안된다는 생각에 후딱 정리해보았습니다.
Wireframe (장비관리-장비목록)
Wireframe (장비관리 - 장비목록)
이 프로젝트에서의 저의 역할은 아무래도 기획자인 동시에 설계자이고 개발자이기 때문에 요구사항을 제가 직접 밀어(?) 넣을 수 있습니다. 그렇다보니, 장비 목록을 오픈마켓들과 같은 느낌으로 이미지와 정보를 한 눈에 볼 수 있는 화면을 요구사항으로 생각하게 되었습니다. 그래서 설계시에도 많은 고려를 했구요.
지금 Wireframe만 보고는 조금 판단이 어려울 수 있으나, 아래 화면설계서를 보시면 어딘가 살짝 오픈마켓과 같은 느낌을 받을 수 있을 것 같습니다.
화면설계서 - PC (장비관리-장비목록)
화면설계서 - PC (장비관리-장비목록)
이제 설명 3번을 눈으로 보고 있다보면 오픈마켓의 화면과 비슷한 느낌을 받으실 수 있습니다.
이로써 장비를 관리하는 관리자 입장에서는 어떤 장비인지 이미지를 통해 확실하게 확인을 할 수 있지 않을까 싶습니다.
또 각 상태별로 이미지를 신호등 색으로 보여줌으로써 어떠한 상태인지도 확인이 가능하게 하도록 생각중입니다.
추가적인 부분이지만, 아마 detail한 규격이나 사용용도도 Tooltip 형식등을 통하여 확인을 할 수 있도록 하려고 생각중입니다.
다만, 현재 화면설계서와 앞으로 나올 디자인된 UI와의 갭이 생길 수 있어 이 부분은 추후 다시한번 고려해볼 생각입니다.
화면설계서 - Mobile (장비관리-장비목록)
화면설계서 - Mobile (장비관리-장비목록)
마지막으로 모바일버전의 장비목록입니다.
여기서는 상태가 안보이는 모습으로 보이는데, 모바일로 볼 수 있는 정보는 PC보다는 적게 만들어볼까 합니다.
(PC보다는 적은양의 정보 - 대신 중요한 정보는 더 부각되어 볼 수 있도록)
어차피 목록은 목록일뿐 더 detail한 정보가 보고 싶다면 큰 화면으로 볼 수 있는 PC나 상세정보페이지에서 봐야하는게 맞다고 생각하고 있습니다.
어쩌면 PC와 Mobile에 차이를 두고 정보의 양을 제한한다는 점은 조금 위험한 생각일 수 있으나, 보이는 화면의 크기가 다르고, 물리적인 제약이 따를 수 밖에 없는 만큼 고려하고 있는 부분입니다.
