프로그램보다 설계가 중요하다고 하는데, 여러분은 프로그램 설계작업(문서 등)를 어떻게 하십니까? 막막하군요.
경력 3년동안 SI업체에서 일 하다가 겨우 벗어날 수 있는 기회가 생겼습니다.
음, 솔루션개발업체에 대해서 이유없는 환상때문에 옮길 예정입니다.
물론 근무환경 및 대우도 지금보다 좋아집니다.
이 회사에서 한가지 과제를 내 주었는데요. 저에게는 너무 어렵게 생각되어집니다.
어떤 과제에 대해서 기본, 상세... 설계서를 작성하라고 합니다. 코딩 및 소스는 없어도 괜찮다고 하네요.
기본설계와 상세설계를 쓰는 방법을 잘 모르겠습니다.
여태까지 한 바로는 요구분석하고(뭘 해야하는지 알아야하기때문에) 종이에 간단히 구상하고 코딩 하면서 또 구상했습니다.
수정사항은 당연히 생기는 것이라고 생각하면서 수정할 때 수정하더라도 일단 만들고 보자였습니다. 요구사항 추가 기능 변경 등.
수정하면서도, 제가 만들어 놓고도, 시간이 가면 갈수록 갈아엎고싶다고 생각한 적이 한두번이 아니었죠;;;
문서를 작성한 것은 함수기능 하나하나 설명하는 상세한 설계가 전부였고,
그것도 먼저 만들어 놓은 소스를 보면서 한글로 그대로 옮겨놓은 것이 전부였습니다.
풀어놓은 것도 아니고 해석하듯이 그대로. ( 실제 도움은 안됩니다. 소스를 보는거랑 같으니까요.)
특별히 문서 서식이 있었던 것도 아니었습니다.
이러다보니 설계라는 말에 겁이 덜컥납니다. 무슨 말을, 어떻게, 뭘 써야할지 깜깜하군요.
차라리 프로그램을 짜서 잘 돌아가는 것을 보여달라고 하는 것이 백배 쉽게 하겠군요.
코딩 못해도 설계는 가능하다고 하는데, 저는 어째 설계가 더 부담이 되는군요.
3년이나 지나놓고도 기본,상세설계조차 구분을 못하고 있다니 부끄럽네요.
프로그램만 만들줄 알면 되는줄 알았는데...
한국에서 일하면 설계서 제대로 쓰는 곳 하나 없다고 들었는데, 여러분들은 어떠신가요?
어떻게 작성하는게 좋을지 감이 안잡히는군요, 저와 같은 고민을 해보신 적은 없으신가요?
문득, 여러분들은 공정과정을 착실히 진행하면서 프로젝트를 하시는지 궁금합니다.
기본, 상세설계서 쓰는 요령이나 조언을 부탁드립니다. 아울러 도움이 되는 책이라도 부탁드립니다.
당장 사 볼 결심을 한 책은 Code Complete 입니다.
추기:
어설프게 과제를 축약해 놓아서 혼선이 생긴 것같아 삭제했습니다. 설계작성에 대해 효과적인 방법을 묻고 싶었습니다.
답변 주신분들께 감사드립니다.
저랑 비슷한 경험을
저랑 비슷한 경험을 하시네요....
무엇을 만들어야 하는지는 알겠는데, 어떻게 만들어야 할지를 모르겠습니다.
저도 같은 조언을 부탁드립니다.
---------------------------------
제일 왼쪽이 저입니다 :)
---------------------------------
제일 왼쪽이 저입니다 :)
오픈되어있는 개발
오픈되어있는 개발 방법론을 따라서 거기서 작성하라고 하는
문서를 양식에 맞춰서 작성하는 연습을 하시면 됩니다.
마르미 방법론이라고 검색해서 찾아보십시오. 좀 SI 틱 하기는
하지만, 어차피 방법론이라는 것이 다 거기서 거기니까요...
대부분의 큰회사들이 갖고 있는 개발 방법론도 대동 소이 합니다.
요구사항을 받는 것까지는 해보셨다고 한다면, 그 다음에 단계로
인터페이스항목정의하고, 데이터 모델링(논리)하고, 개발해야할 프로그램
목록 확정하고, 데이터코드 설계하고, Physical Modeling하고, 테이블
설계하고, 화면 정의하고, Funcution에 맞춰 사양서 만들면 설계가
끝나죠. 웹기반이라면 웹화면 설계등도 화면 정의 단계에서 수행하면
되겠지요.
잘 정의된 '양식'에 맞춰서 내용을 채우는 것이 가장 빠른 방법입니다.
설계서(보통 프로그램 사양서라고하죠)를 만들고 나면 그 다음 부터
코딩은 코더 들에게 하청~~
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
한 3년..
한 3년.. 설계 하다 보면
코딩이 하기 귀찮아 지죠.. ㅎㅎㅎ
자기 자신에게 맞추세요.
입사가 임박하신 듯 한데 지금 새삼 책을 읽는다고 실무에 적용할 수 있을거라고 보긴 힘들고요.
자기 자신에게 맞추세요. 내가 이걸 보면 개발을 할 수 있겠다 하는 내용으로 쓰십시오.
여지껏 본인이 보시던게 함수 나열한거면 그렇게 하시고 ERD를 그리셨으면 ERD를 그리시고요.
서버에 보내는 데이터의 내용이 무엇인가요? 그게 구체적으로 도출가능하면 도출하는 과정을 쓰시고요. 그리고 ERD나 Class 도출이 가능하겠죠.
만약 주어진 내용만으로 그게 곤란한 상태면 일단 처리 과정을 먼저 생각하면서 플로우차트나 이런걸 먼저 써 보시고요.
이렇게 정적 설계를 하거나 동적 설계를 하거나간에 결국은 양쪽 다 어느정도 진행하게 될 거고요.
둘 다 어느정도 동시에 진행해야 하지만 굳이 따지자면 보통은 정적 설계를 조금 우선적으로 생각하는게 보통입니다.
여하튼 데이터와 알고리즘이 구체적으로 정리가 되고 나면 그걸 보고 코딩을 할 수 있겠죠.
그리고 화면 설계는 이러한 정적/동적 설계 개념과는 약간 별개로 생각하는게 보통입니다. 일단 지금은 논외인것 같네요.
기본 설계와 상세 설계의 구분을 한다면
기본 설계 단계에서는 시스템이나 구현을 어떻게 할건가의 문제는 일단 뒤로 미룬 상태에서 논리적인 전개를 검증하는 거고
상세 설계 단계에서는 실제 구현 수준에 가까운 수준까지 세분화해서 각각의 내용이나 역할을 정확히 쓰는 겁니다.
기본 설계 단계에서 하는 일을 예를 들자면
주민등록번호가 몇자리 수고 각각의 값에 어떤 제약 사항이 있는지 하는 것은 시스템이나 구현과 상관없이 원래 그런 조건이 있는거죠.
그렇다면 주민등록번호를 입력하면 이런 제약 사항을 검증하기 위한 Check를 하고 그 다음 Input SQL을 호출하거나 그래야겠죠.
이런 사항은 실제 구현 방법과 상관없이 설계를 할 수 있는거고요.
이 수준에서 일단 전체적으로 시나리오를 다 잡아본 후 하나하나 그게 말이 되나 안되나 검사를 해 보는 겁니다.
그래서 일단 구현 방법은 둘째치고 완전히 말이 되는 시나리오가 됐다 그러면 그게 기본 설계를 완성한거고요.
그 다음엔 실제 구현을 염두에 두고 앞에서 Check나 Input SQL 같은데 해당되는 함수나 그런걸 구체적으로 구현 방법을 생각해봐서
예상되는 문제점을 실제 구현 전에 생각을 해 보고 하나 하나 해결책을 찾으면서 정리를 하는 겁니다.
상세 설계의 핵심은 실제 맨땅에 헤딩을 해 보기 전에 머리로 먼저 생각하는 겁니다.
이를테면 주민등록번호를 입력받는데 메모리를 할당했습니다. 그러면 어디선가 이걸 죽여야 되겠죠.
걍 코딩하기 전에 죽이는건 어디서 어떻게 할건가를 먼저 생각부터 합니다. 그래서 아 이게 아니구나 싶으면 설계서에서 고치죠.
역시 이렇게 하면 말이 되겠다고 확신이 되면 상세 설계가 완성했다고 할 수 있겠죠.
처음에는 설계 단계를 거쳐도 검증이 잘 되지 않고 시간만 낭비하는 것처럼 느낄 수도 있지만
결국은 설계 단계에서 점점 더 많은 검증을 할 수 있고 결과적으로 닭질을 안하게 돼서 시간이 단축됩니다.
시간도 단축되지만 코딩을 시작하는 단계에서 성공 가능성에 대한 확신을 얻을 수 있다는게 중요하죠. 개발 시간도 예측 가능해지고요.
너무 뻔한 설명을 드린 것 같긴 한데요. 여하튼 중요한건 어떤 내용, 어떤 형식이든 본인이 코딩하는데 확실히 도움을 줄 수 있는 내용을 만드시라는 겁니다.
좋은 결과 거두시길.
그냥 data import랑 sync
그냥 data import랑 sync 정도 하는데 무슨 설계가 필요한가 싶군요. 아무리 C라도 코딩에 1시간 넘게 걸릴 일은 아닌 듯 한데...
설계를 기본 설계, 상세 설계 이런 식으로 분류해서 하는 것보다는 필요할 때 딱 필요한 만큼만 하는 게 좋습니다. 어쨋든 사용자를 만족시키는 것은(돈 주는 사람을 만족시키는 게 아니라-_-) 설계가 아니라 실행되는 프로그램이니까요.
설계를 잘하는 방법을 배우는 것보다 설계를 적게 하면서 좋은 프로그램을 만드는 방법을 배워보시는 것은 어떨까요?
허걱;;;
딴지일지 모르겠지만... 아무리 코딩을 잘 하셔도 '1시간'이야 더 걸리지 않겠습니까... '1시간'이라니 허걱~~~
보시믄 일단 CSV 변환이 있는데 이건 라이브러리를 구해다 쓴다 치고,
네트웍 프로그래밍을 해야 하는데 이것도 라이브러리를 구해다 쓴다 치고 (그래도 오류 처리는...)
서버에서 변경된 내용이 있으믄 다시 전송을 해 주고 클라이언트도 이걸 확인해서 보여주라는 이야기 같은데
서버가 안 복잡해지려면 클라이언트가 딱 하나만 있다고 하더라도 (흠... 대체 그럴 일이? 여하튼 클라이언트가 여러개면 훨씬 복잡해지겠죠...)
여하튼 그럼 보내는거 받는거 둘다 돌아가야 하는데...
흠... 이건 클라이언트의 데이터베이스를 사용자가 개입해서 갱신한다는건지 자동인지 영 그러네요.
일단 서버로부터 갱신된 데이터를 받는것도 있지만 클라이언트쪽에서 갱신되는 경우도 있으니 사용자가 자료를 갱신한다고 보고요.
(뭐 꼭 사용자가 사람이 아니라 다른 프로그램일수도 있겠지요.)
사용자가 프로그램이 블록되어도 입력될때까지 기다려주고 그러지 않는다면 멀티쓰레드를 쓰던가 그래야 할거 같고 큐잉도 해야겠지요...
사용자가 착한 사람이라고 하더라도 입력 도중에 서버에서 데이터가 날아올 수도 있으니 그럴 때의 처리는 생각 좀 해봐야겠네요...
글구 서로 갱신해주는게 뺑뺑이를 돌지 않도록 해야 할거구요...
저라면 최최최소 하루;;;
돌은 살살 던져 주세요 ㅎㅎ
머 제 얘기는 모든
머 제 얘기는 모든 가능한 예외 상황을 다 고려해서 식스 시그마급 availability를 확보하면서 1시간 안에 만들 수 있다!라는 건 물론 아니구요. 과제 설명이 비문이라 오해의 소지가 있긴 하지만 몇 가지 가정을 한다면 tracer bullet보다 조금 높은 퀄리티 정도(?)의 product는 1시간 안에 만들 수 있지 않나 하는 것입니다.
과제 설명이 애매하긴 하지만 대략 클라이언트에서 변하는 내용을 서버로 보내고 또 서버에서 변하는 내용을 현 클라이언트에서 받아오는 것인 듯 합니다. 이게 주기적으로 호출되며 덤으로 CSV로 import를 할 수 있다... 그럼 서버가 DB니까 큐잉은 DB가 할 꺼고 예외 처리는 그냥 에러 메시지 하나 띡 내도 별 문제 없겠죠. 싱크할 때도 DB끼리 싱크니까 단순히 update 시간 기준으로 하면 되는 상황 같구요. 그렇게 보면 다음 정도의 모듈이 필요한데...
* CSV 파싱 모듈
* 서버 DB API
* 클라이언트 DB API
* 싱크 모듈
* 주기적으로 싱크 모듈을 호출하는 쓰레드
여기서 위에 세 개는 이미 돌아다니는 라이브러리가 있을 테니까 그대로 쓰면 될 테니 직접 코딩하는 건 싱크 관련 로직과 쓰레드로 주기적으로 호출하는 것, 그리고 라이브러리 갖다 쓰는 코드 정도가 되겠죠. UI에 대한 제약은 없지만 GUI 클라이언트라면 UI 디자이너로 뚝딱 만들면 오래 걸릴 일은 아닐 테구요.
당장 저보고 C로 해보라고 한다면 C를 놓은지 오래되었기 때문에 빌드 세팅하는데만 한참 삽질할 가능성도 좀 있습니다만-_- 요즘 메인 언어로 쓰는 파이썬이나, 아니면 한 때 밥 벌어먹고 살았던 자바로 한다면 30분 안에도 가능하지 않을까..하는 낙관적인 예측을 해 봅니다. 딱히 언어별 생산성의 차이가 두드러질 상황은 아닌 듯 해서 숙련된 C 프로그래머라면 1시간 정도에 해내지 않을까 하는 것이죠.
블로그를 4시간 만에 만들 수는 있지만 블로그를 4시간 만에 만들 수는 없잖아요? 그런 의미로 생각해 주시면 감사하겠습니다.
써놓고 보니 저보고
써놓고 보니 저보고 설계하라면 딱 이 정도로 써놓고 설계 끝~~ 해버릴 것 같군요-_-a 모듈 리스팅 다섯 줄만 있어도 코딩으로 고고씽~
일단 python으로
일단 python으로 구현하는거 자체가 설계 아닐까 싶은데요. ^_^ 한 20-30분 정도면 가능할거 같은데요.
그리고 나서 속도 필요한 부분 하나씩 C로 바꿔가면 될거 같은데요..
흔히 기본 설계에
흔히 기본 설계에 많이 쓰이는 양식은 DFD입니다. 프로세스 중심으로 들어오고 나가는 데이타의 흐름을 그리는 양식입니다. 깊이는 보통 3단계 정도로 구분해서 top to bottom으로 그려나갑니다. 링크의 예를 보시면 이해가 쉬울 겁니다.
http://softwareengineeringnotes.blogspot.com/2007/07/dfd-example.html
DFD에서는 누가 무엇을 무슨 데이타를 가지고 하느냐(1)만 정리가 되고, 언제 어떻게 하는지(2)의 자세한 것은 빠져있습니다. (2)의 부분은 구현 언어에 따라 다른 종류의 양식을 쓰는 것이 보통인데, C언어로 구현을 한다면 쉽게 접할 수 있는 UML Diagram 중 '언제'는 Sequence Diagram을, '어떻게"는 Activity Diagram을 참고해서 pseudo 코드 정도 수준에서 양식을 그리면 상세 설계에 대응한다고 생각합니다.
설계는 쉽게 플로우챠트를 그리는 것의 확장입니다. 그림 상 블록에 들어가는 표현의 깊이가 전체 그림에서 높고 낮음의 차이가 없게 그릴 수 있도록 몇 번 연습을 하시면 어려울 것 없습니다.
명백한
명백한 사실:
프로그램보다 설계가 돈이 됩니다.
코딩이야 중국이나 베트남 코더 시켜도 아웃풋 나와..라고 오너들은 생각하고 있습니다.
문득 몇달 전의 일이
문득 몇달 전의 일이 생각납니다...
어떤 사이트를 고칠 일이 있어서 이전 작업한 사람에게 ERD좀 봅시다 했더니 ERD가 뭐죠?라고 묻더군요. 설명을 해줬더니 그런건 없다고 하더군요. 그 사이트의 DB의 테이블은 field01~99까지 있는 식이었습니다. OTZ...
----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com
----
먼저 알게 된 것을 알려주는 것은 즐거운 일이다!
http://hangulee.springnote.com
http://hangulee.egloos.com
저도
여기 계신분들과 같은 경우인지는 모르겠습니다만
전 연구 할때 통신 시뮬레이터 같은걸 프로그램으로 짜는데
여기에 여러가지 요소가 들어가면 장난 아니게 복잡해집니다.
사실 설계가 처음에 명확하게 그려지면 프로그램은 그 설계도 보고
수월하게 할 수 있는데 어떤 부분에서 어떤 파라미터를 어느 함수로 넘겨야할지
첨에는 모르겠더군요. 결국은 trial and error 방식으로 하나 하나 해보고
되면 되는거고 안되면 이쪽에서 저쪽으로 연결을 바꿔주는 식으로 해서
시스템을 짜내긴 했습니다. 근데 그렇게 하니 프로그램 돌리는데
연산 시간도 장난아니게 오래 걸리고 시스템에 조금 변화를 줄려면
첨부터 이짓을 다시 해야하더라고요.
이번에 그 프로젝트 하면서 설계의 중요성을 뼈저리게 느꼈습니다.
p.s 그나마 혼자 할때는 저 방식이 통제가 되는데 여러 사람이서
같이 프로그램을 짠다면 trial and error 방식으로 가는건
회사 망하는 지름길 인거 같습니다.