분석/설계와 개발의 분리는 가능한가요?

inforide의 이미지

최근에 대형 프로젝트 하나가 끝났는 데

소위 얘기하는 공정분리라는 형식으로
분석/설계자와 개발자를 분리하는 형식으로 프로젝트가 수행되었습니다.

문제는 분석/설계자가 설계작업이 끝나고 대부분 철수하고
그 자리를 개발자가 채웠는 데

개발사 입장에서는 분석/설계와 개발이 분리된 성공적인 프로젝트로 생각했지만(프로젝트 PM께서 포상을 받았다고 합니다.)
고객사 입장에서는 프로젝트가 분리되면서 업무가 제대로 이뤄지지 않았다고 판단합니다.
(이 프로젝트는 예정보다 8개월정도가 늦게 오픈되었습니다.)

공정분리가 가능하면 소위 얘기하는
원격에서도 개발이 가능하고, 즉 분석/설계는 국내에서 하고
개발은 해외에서 하는 것도 가능할 듯 한데요.

과연 우리 업계에 이것이 가능한 작업형태일까요?

plustag의 이미지

개발사 입장에서는 성공적이라 생각할 수도 있지만(분석/설계단계 산출물로 곧바로 개발에 들어가는데 차질이 없는 경우)
고객사 입장에서는 설계공정 이후 개발공정에 추가설계를 하고 싶은데 못하니까 업무가 제대로 안되었다고 말할 수도 있습니다.
그게 지금까지 우리나라에서 일반적(?) 진행되는 형태라
고객사 입장에서 분석/설계 단계에 모든 요건을 내지 않거나 못한다면 개발에 가서 태클을 걸 공산이 99%입니다.

공정분리에 대해서는 다른 곳에서도 많은 논의가 되고 있는것으로 아는데 자세한 상황은 저도 모릅니다.(혹시 아시는 분 동향이라도 좀..)

IT프로젝트를 건축프로젝트와 비교하는 경우도 있는데 얼마전에 건축관련 다큐(인천대교였나? 다리면 토목이겠죠..)에서
설계/공사일정을 병행해가는 방식으로 공기를 단축했다는 이야길 들었습니다. 건축쪽에서는 흔한 일이 아니었나본데
이런 일들을 볼 때 분리 혹은 병행 뭐가 정답이라고는 말할 수 없을듯 합니다.

그래도 여러 방안/방법들이 나와서 뭔가 발전적인 모습이 보여야되는데 이쪽은 그런게 안보여서 안타까울 따름입니다.

누구냐 넌?

구라파덕의 이미지

몇가지 조건을 전제로 하면 가능합니다.

분석/설계 하는 사람이 개발을 이해 하고 있어야 함(잘할 필요는 없음)
최상위 개발자는 분석/설계된 결과물을 이해 할 수 있는 능력이 있어야 함
분석/설계된 결과물에 대해 감리가 가능한 인력이 있어야 함

FIFO의 이미지

.

red10won의 이미지

설계후 개발과 테스트중 나온 고객 요구사항이

기존 로직과 설계에 잘 흡수되는지 봐야됩니다..

설계자체를 뜯어고칠정도의 요구사항이라면 (DB구조같은)
설계가 잘못 되었다기 보다는
이런 요구사항을 왜 설계전에 나오지 않았는지를 고민해 봐야되는 문제입니다.

개발후 고객요구사항이 적으면 적을수록
고객의 입장에서는 쓸마한 프로그램이 되는게 아닐까요?

codepage의 이미지

정확하게 정의해서 주면
못할 개발자가 얼마나 될까요?
그렇게 정의해서 주지 못하면서 개발자가 몸으로 떼워야 되니까 문제가 되는 거죠.
솔직히 개발 스팩이 분명한데 개발자는 그 스팩대로 코딩만 하면 되지
그렇게 되지 못하니까 수백명 투입하는 프로젝트에서 수백*수백배의 혼란만 가중되는 것이 아닌지요?

oomymy의 이미지

저는 개인적으로 소프트웨어를 만드는 작업은 건설 보다는 미술작업에 비유하는 것이 더 맞다고 봅니다.

그 이유는 개발단계에서 설계가 일부/상당부분 변경되는 일이 잦습니다. 개발을 진행하면서 구현물이 실체화되어 감에 따라 더 정교하고 견고한 설계가 나오는 일도 빈번하며, 또한 요구사항이 개발 단계에서도 새로 생기거나 변경되기도 합니다.

제 경험상 분석/설계와 개발은 분리될 수 있는 작업이 아닌, 서로 피드백을 주고 계속 반복되어야 하는 작업입니다.

그런 의미에서 소프트웨어 개발이라는 작업이란, 대략적인 스케치를 하고 색을 칠하면서 중간중간에 영감이 떠오를 때마다 작품을 수정하고 덧칠하고 하는 미술 작업과 훨씬 더 잘 맞는게 아닌가 싶습니다.

guybrush1의 이미지

동의 합니다. 유화랑 특히 비슷하다고 느꼈습니다.

drinkme의 이미지

개인적인 입장은
'설계와 개발이 가능하다'입니다.

말씀하신 '고객사의 불만'은 별개의 얘기입니다.
윗분이 말씀하신대로, 평가 주체가 누구냐에 따라 달라지는 얘기이니까요.

이런생각도 듭니다.
상당수의 회사나 프로젝트에서 보면,
단순히 경력이 많은 사람들이 '설계'를 하는 경우가 많은데,
국내 상당수 엔지니어(비하하려는 의도는 아닙니다)가 과거 '꽁수' 테크닉으로 일하던 시절에 하셨거나 시작하신 분들이 많아서
그 분들이 한 설계가 신뢰도가 있냐... 하는 것입니다.
'뭐... 이렇게 설계해 놓으면... 나중에 대충 진행이 되는거 같더라...'???
'detail한 요소는 설계에 일일이 감수하기 힘들다'...
그리고, 아직도 '문서화'를 힘들어하는 설계자들이 많은것 같습니다.

그리고,
솔직히 팀에 '문서보고 개발'할 수 있는 사람이 몇명이나 된다고 보시나요?
상당수의 IT 관련 문서들이 영어로 되어 있어서인지 몰라도,
computer를 배우기 시작하면서, '문서를 보는 것 보다... 아는 사람한테 물어보거나 내 지능으로 처리하는게 낫더라... 는 사람이 사실 좀 많습니다.
가령, man page봐도 나오는 standard library의 사용법을 묻는 질문이 여기 kldp에도 많습니다.
제 개인적인 경험이지만, 설계문서 제대로 안보고 코딩하면서 남탓하는 개발자 많이 봤습니다.

프로젝트와 엔지니어링과 그리고 우리가 하는 대부분의 일들은
'문서'(여러가지 형태가 있겠죠)로 정리가 완전히 되어야 한다고 봅니다. 물론 이상적이지만요.
내가 갑자기 이 프로젝트에서 없어져도, 인수인계니 뭐니 아는 문제가 없어야 합니다.
사표내고 나서, 한달두달동안 인수인계하라는 거 보면,
정말 이해가 안갑니다.

프로젝트가 잘 되었느냐 안되었느냐는,
사실 평가 기준도 좀 애매하고,
단순히 방법론이 아니라, 해당 팀 구조, 유지방법, 규모, 위치 등 다양한 변수에 따라 판이해 집니다.
개발 방법론이라는 것도 아주 많고... 그걸 적용하는 것도 PM 스타일일 수 있으니까요.
하지만,
저 개인적인 생각인 '설계'와 '개발'이 분리 가능하다. 입니다.

ps.
'니는 뭐 잘났냐'고 하는 분들 계실 지 모르겠는데,
저도 제가 말한 사람중에 하나입니다.

kukgini의 이미지

분석/설계/구현의 과정을 분리시켜 작업하는 것은 경우에 따라서 작업의 효율을 높일수도 있습니다.

단, 요구사항의 구체화정도,
개발기간,
만들어야 하는 시스템의 복잡도,
투입되는 인력의 경험과 수준,
팀의 규모등등이
공정분리에 적합한 수준이어야 겠지요.

성공과 실패여부는 가늠하는 잣대가 무었이냐에 따라 다르지 않을까요?

inforide의 이미지

"소스 코드는 곧 설계다" 란 글을 읽어 본적이 있었습니다.
내용의 골자는
건축에서처럼 설계를 하고 모형을 만들어 설계 자체를 검증하고 이를 통해서 설계를 수정보완해야 하는 데
소프트웨어 설계가 잘 되었는지를 검증하기 위한 가장 싼 방법은 직접 개발을 해 보는 것이다.
따라서 소프트웨어 설계는 개략적인 설계에 불과하며 개발과정을 통해서 계속 수정보완되어야 한다..

뭐 그런 식의 논리였습니다.

우리가 만약 요구사항은 항상 변경될 수 있다는 것을 기정사실화 한다면
(사실 제가 겪은 프로젝트중에서 설계단계 이후에 요구사항이 변경되지 않았던 프로젝트는 결코 한건도 없었습니다.)
oomymy께서 말씀하신 것처럼 설계와 개발을 분리할 수 없지 않나 하는 생각입니다.

또 우리가 개발될 내용을 정말 문서로써 적절히 잘 표현할 수 있느냐? 누가 읽어도 쉽계 이해하도록 ...
하는 문제가 있는 데 사실 이것도 어렵지 않나 하는 생각입니다.

고객측입장에서는
분석/설계를 할때 함께 공감대를 형성하서 이야기 했던 사람이 다른 개발자로 바뀌면서
업무내역을 계속해서 반복적으로 설명해야 하고

또한 분석/설계자의 경우 일정에 맞춰서 산출물만 작성하고 철수하면 됨으로
산출물의 질이 일정이 촉박할수록 현저히 떨어질수 밖에 없다는 문제도 있지 않을까 생각합니다.
- 이 산출물이 제대로 검증이 되지 않고, 결론이 내려지지 않은 건에 대해서는 "추후 협의"라는 식으로 comment만 달 수 밖에 없는 상황...

여하튼 원가절감이라는 이유로 많이 시도를 하고 있고 시도를 할 예정인 것 같습니다만
이러한 시도에 대해서 제 개인적으로는 회의적입니다.

jam02의 이미지

Code as Design: Three Essays by Jack W. Reeves
http://www.developerdotstar.com/mag/articles/reeves_design_main.html
아마 이 글일 것 입니다.

요지는 코딩이 설계인가? 생산인가?입니다.
답은 코딩도 설계라는 것입니다.

보통 건축설계도를 보고 그대로 건물을 지을 수 있지만,
같은 설계문서를 보고도 다른 프로그램이 나오는 것과 같은 원리입니다.

semmal의 이미지

업무적으로 동시 병행으로 분리가 된다면 가능하다고 봅니다. 적절한 대화만 있으면 되니까요.

하지만 시간적으로 분리가 된다면 불가능하다고 봅니다. 아니 가능은 하지만 성공적이지 못하겠죠.

예전에 짰던 걸 그대로 다시 짠다면 성공적으로 마칠 수 있겠지만, 예전에 짰던 걸 그대로 쓰려고 소프트웨어 "개발"하는 사람은 없으니까요.

프로그래밍이 제조업은 아니잖아요?
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

select99의 이미지

가능은합니다.

대신 더많은 비용이듭니다.

분석/설계 이후 개발비용이

분석설계 개발을 동일인혹은 동시에 같이 하는것보다 훨씬많이 듭니다.

제품의 질또한 떨어집니다.

위에누가 말했듯이.. 개발(구현)프로그래밍이란 마치 가보지못한길을 가는것과 같아서...

계획대로 되는일은 잘없습니다.

그계획을 억지수행을했을경우(많은경우 그럴려고합니다.) 결과물이 형편없어집니다.

또한 분석설계의 지식을 개발인력에게 재대로 이해시키는비용이 추가되는것으로 보아야 하기에 비용또한 더들어갈수 밖에 없습니다.

분석설계자의 50%가 남아 신규개발인력과함께 개발에 투입되고 다시 그인력의 대략50%가남아 신규유지보수인력과함께 운영에투입되는것이 바람직하다고 보는입장입니다.

FIFO의 이미지

분리가 가능해야만 합니다...라고 생각합니다
여기에 대한 저의 신조는 나중에 써보렵니다. 왠지 귀차니즘