종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다.
사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.
기법은 기법일 뿐입니다. 내용은 아니죠.
UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.
그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다.
잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.
따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다.
설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.
UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.
좋은 말씀이십니다.
답글삭제저도 설계를 최초 시작할때는 역시 볼펜과 종이를 가지고 시작합니다.
물론 사전 요구사항 분석은 기본이지요. 그리고 나서 전체적인 시스템 구조를 어떻게 가져가야 할까를 종이로 열심히 그림으로 그리죠^^! 툴을 잘 다룬다면 좋겠지만, 꼭 잘 다뤄야만 전문가인건 아니죠^^!
돌이아버님 안녕하세요. ^^
답글삭제연필이 좋으면 글을 더 잘 쓸 수 있다는 것과 비슷합니다. 물론 좋은 연필을 사용하면 전혀 나쁠 것은 없지만, 글을 잘 쓰기위해서는 좋은 연필을 사기보다는 책을 많이 읽고 글쓰는 법도 배우고 글도 많이 써봐야죠.
나는 UML을 애물단지로 취급한다. 디자인 단계에서의 그 필요성만큼 개발단계에서는 실질적인 도움을 주지 못하기 때문이다. UML은 문제영역에 대한 이해도를 높여주고 프로젝트 참여자들간의 의사소통에 구심점 역할을 한다는 것에는 많은 효용성이 있지만 실제 개발에 들어갔을 때에는 도움은 커녕 오히려 코드와 동기화 문제를 유발시킨다. UML도 버전이 있어서 발전하고 있다고는하나 버전까지 따져가면서 UML을 정확하게 그려내야할 프로젝트는 문서관리에 비중이 있..
답글삭제당연한 글인데 읽는 순간 많은 생각이 드네요.
답글삭제옛날 UML을 보고 감탄하고 그에 따라 볼려고 애쓰다보니.. 가장 핵심적인 면을 놓친것이 많았다 싶습니다.
사실 적용한다고 해놓고 막상 한건 -_- 문서만 UML 형식으로 만들곤 했지만 말입니다..
작은악마님 안녕하세요. 축구 좋아하는 어린이가 멋진 축구화 보고 황홀해하고 축구화 살려고 축구는 안하고 맨날 아르바이트 하는 격이죠. 축구화 신경안쓰고 맨날 연습했으면 훨씬 잘할 것을...
답글삭제UML전문가가 설계전문가? Ray님이 기분 상할지 모르지만, 나도 종종 내뱉는 넋두리를 풀어낸 글이다. 여기 120% 공감하는 말이 있다. 사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다. 기법은 기법일 뿐입니다. 내용은 아니죠. 거기에 더해서 혼란을 가중시키는 다양한 도구까지 있다. 수차례 내뱉은 말을 다른 사람 글로 본다. 잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를..
답글삭제다들 일정관리 어떻게 하고 있나 몇몇 회사분들게 물어보니
답글삭제"이것저것 다써봤지만 결국 비지오와 액셀 그리고 달력으로 돌아왔어 ㅎㅎㅎ"
이렇게 결론이 나더군요.
"툴이나 기법이 중요한게 아니고 사람이 중요하구나"
라는걸 다시 느낀것 같습니다.
안녕하세요. 당근천국님
답글삭제저도 왠만한 프로젝트 일정관리 아직도 엑셀로 합니다. ^^ 그게 더 나아요.