프로젝트 개발 모형 : 폭포수 모델, 애자일 방법(XP방법론)
제가 작업하고 있는 개인 프로젝트(Project.다원 ERP) 개발모형은 거의 폭포수 모델을 베이스로 두고있다고 보셔도 될 것 같습니다.
흠.. 거의 반절 재미삼아 취미(???)로 만드는 프로젝트라서 다른분들이 보시기에는 많이 부족하겠지만, 시간이 괜찮으시다면 한번쯤 쭉 읽어보시는것도 괜찮을겁니다! (아마...?ㅠㅠ)
Project.다원ERP_개발 정보(개발언어, 장비, 예정내역)
다원ERP_개발 정보 (개발언어, 장비, 예정내역) Project Infomation Project Name : 다원ERP 기획 : Karzin 분석 : Karzin 설계 : Karzin 개발 : Karzin 디자인 : Karzin 유지보수 : Karzin 개발 정보 Develop Lan..
karzin.tistory.com
사실 고객도 저이고, 개발자도 저인 이상 어느정도 제 머릿속에 정립된 시스템은 바뀔일이 없다보니 거의 빠꾸는 없겠지요.. 다만, 개발하다가 막히는 부분이라던가, 문제가 생겨 바뀔수밖에 없는 부분에 대해서는 로직이 바뀔뿐이지 보이는 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
'컴퓨터 이야기 > 분석 및 설계' 카테고리의 다른 글
| 기획&설계 - 시스템 설계를 위한 기획, 기획과 설계는 밀접한 관계가 있다. (1) | 2021.01.02 |
|---|---|
| Wireframe - 백문이 불여일견 (0) | 2020.07.28 |
| Persona - 효율적인 UX디자인을 위한 시작 (0) | 2020.07.07 |
| [언어분석] 자전거를 이용한 언어의 이해!_1-1 (0) | 2018.09.09 |
| [언어분석] 자전거를 이용한 언어의 이해!_프롤로그 (0) | 2018.09.08 |
