여러분이 사용하는 개발 방법은?

geekforum의 이미지

최근 소프트웨어 개발 프로젝트도 표준화된 공정에 의해 생산되고 있는듯 합니다. OMG에서는 RUP를 표준으로 정했다더군요. 그런데 개발방법론이라는 것이 개념적으로는 이해할 수 있지만 개발에 도입하려고 하면 수많은 걸림돌이 있는듯 합니다. Rational사에서도 RUP의 세부 공정에 대해서는 정해진게 없다더군요. 이러한 부분은 전적으로 프로젝트 매니저에 의해서 결정이 된다고 합니다. 그래서 프로젝트 매니저는 경험이 정말 중요하더군요.

한사람이 모든 경험을 다 해볼 수는 없겠지요. 그래서 서로 개발공정의 도입에서 겪었던 경험이나, 그 공정의 장단점과 어려웠던 점을 한번 이야기 해보는 것도 좋겠다 생각합니다.

개발공정:
분석,설계언어:
case tool:

댓글

익명 사용자의 이미지

자신만이 알수 있는 엉터리 알고리즘..
주석하나 없는 알고리즘에 치를 떨었습니다..

역시 개발보다는 디버깅과 보수가 더 힘들더구만요..
특히나 남덜이 개발해논 프로젝트 라면....

주석은 어떤식으로 어느 깊이까지... 라는 어느 한가지 분명한 틀이라도 있어야 할 듯 합니다.

php 에 골머리 썩고 있는... 고양시 촌부

익명 사용자의 이미지

남들이 이해하기 쉬운 코딩 방법론 제 1조 1항이...
"주석을 가능한한 많이 붙여라.." 라고들 하던데요.. ^^;

주석같은 경우는 일부러 안붙이는 경우도 있고, 음... 저 같은 경우는 소스를 배포할 상황이 생기면 일부러 주석을 빼 버리고 배포하는 경우도 있습니다. 물론 "너도 고생해봐라..." 하는 생각이 전혀 없다면 거짓말이겠지만, 정말 그 생각 뿐이라면 소스 공개조차도 하지 않겠죠.. 아무리 허접한 코드라고 해도 그게 꼭 필요한 사람에게는 반갑고 유용한 코드가 될 수도 있는데...

문제는 제 경우 주석을 지우는 큰 이유가.. "쪽 팔려서" 입니다. 제가 만든 코드의 주석은 대부분 이런식이거든요... ^^;
혼자 잘난척하고, 말도 안되는 글 써놓고... 때론 욕도 있고.. 별에별 잡소리가 다 들어가 있어서... 켜켜

for(loop=0;loop<10;loop++)//루프 돌린아잉~~~
{
vSum += loop; //으와 이런 굉장한 논리가 !! 오오 놀라워라..
}//요기서 루프 끝났다 캬캬
//흠냐 아무리 생각해봐도 이 알고리즘 죽인다. 이것이 세상에 알려지면
//난 분명 노벨상 받을꺼야..

그런데, 정작 제가 만든 프로그램의 소스에도 이해하기 어렵고 중요한 코드가 쓰여진 곳에는 주석이 안붙어 있는것을 많이 보게 되고 그때문에 제가 저한테 욕을 한 적이 한두번이 아닙니다.

정말 복잡하고 어려운 코딩을 머리 싸메고 하다보면 주석 써 넣을 여유가 별로 없는지... 이유는 아직도 잘 모르겠지만... 그렇더군요... 주석이 주절주절 붙어 있는건 누구라도 척보면 이해할 수 있는 그런 쉬운 코드에나 붙어 있더군요...

이거 고쳐야 하는데.. 쩝쩝...

익명 사용자의 이미지

개발이란 ?

참으로 답하기가 힘들군요.

저도 개발을 한지가 장난이 아닌데...

프리로 여기저기서 일해봤지만 좋은 개발 방법론을

가지고 개발하는 회사는 보지 못했습니다(대기업 SI포함).

뭐랄까... 자신의 회사에서 사용하는 개발 방법론에 약간의

주먹구구식을 결합해서 사용하는 정도...

그렇지만 개발이란 무에서 유를 창조하는 예술작업이라 생각합니다.

개발을 시작하고 언제부터인가 결과 위주보다는 내가 새로운

무엇인가를 만든다는 마음으로 개발을 하게되었고... 그 시점

이후로 저도 많은 개발 방법론에 관해서 보고 적용도 해보고...

그렇지만 위에서 많은 분들이 언근한것 처럼...

어떤 방법론을 적용해서 해야 하는지를 지금도 찾고 있습니다.

저의 짧은 생각으로 충실한 이론 + 많은 경험에서 얻어진

자신만의 개발 방법론을 만들어서 꾸준히 연구 개발해서 하나의

작품으로 만드는게 가장 좋은 개발 방법이 아닐까 생각합니다.

그렇기 위해선 많은 연구와 경험이 필요합니다.

고로 개발자는 너무 힘든 직업이 아닐까 생각합니다.

새로운 것을 개발한다는 것은 쉬운게 없는게 아닐까요 ?

......?

정규현의 이미지

XP권장!

RUP는 너무 복잡하고 학습에 많은 시일이 소요됩니다.
그리고 대형 프로젝트가 아니면 RUP의 점진적 반복은 적합하지
않습니다.

XP는 Extreme Programming의 약자로
일단 직관적이고, 쉽게 이해할 수 있으며,
복잡한 이론이 없습니다.

대우정보시스템의 경우 단기 프로젝트에 XP를 사용하고
있는것으로 알고 있습니다.

익명 사용자의 이미지

음.. 글쎄요...

방법론은 하나의 교과서일 뿐이라고 생각합니다.
저역시 7여년 동안 개발을 해 보았는데...
이렇게 생각합니다..

방법론 = 교과서(이론),
개발 = 이론 + 경험

즉, 요리책에 나와 있는 방법대로 해도 요리의 맛은 다 틀립니다.
사람이 하는 일이라 똑같은 요리책으로 배웠건만 맛을 다 틀리죠..
개발 역시 그와 동일합니다.

즉, 요리하는 원하는 사람이 어떤 것을 원하며, 그것을 만족하게 만들기 위해 필요한 것은 어떤 것인가 하는 것이죠...

저의 짧은 경험에 비추어 보면 이렇습니다..

1. 프로젝트 수주
2. 업무 범위 확정 및 업무 파악 ( 장단점, 보완점 등...)
주요 항목 정리
3. 아키텍쳐 구상
4. 벤치 마크 ( 주요 항목중 하나 또는 일부 )
5. 성능 검증 및 문제점 파악

이 시점에서 거의 대부분의 시스템의 기반을 잡습니다.
물론 장난이 아니게 힘들죠...성능문제나 그외의 업무 파악미비등으로 인해서...

6. 아키텍쳐 보완 및 최종 아키텍쳐 확정
7. 각 파트별 상세 업무 파악
8. 기반 시스템에 기초한 표준안 제시
9. 개발
10. 테스트 및 벤치마크 , 시스템 튜닝 (H/W, S/W, N/W )
11. 시스템 오픈

이렇습니다...

익명 사용자의 이미지

1. 프로젝트를 맡는다.
{
2. 눕는다. 혹은 앉는다. 그리고 생각을 한다. --;
3. 계속 생각을 한다. 퇴근하는 길에서도 생각을 한다.
4. 종이에 적는다. 또 적는다. 또 적는다.
5. 고객분들께 이야기 한다. 요구사항을 점검한다.
6. 코딩한다. 테스트한다. 속도가 안난다. 젠장 --;
}while( 6. != 0 )

여린칼날_의 이미지

프로젝트를 하면 분석 및 설계 단계를 거치게 됩니다.

그런데, 분석 및 설계 단계, 특히 분석 단계는 많은 고객들이 아주아주 싫어하는 단계입니다. 현재 상황을 분석을 하면 "놀고있네."라는 단어로 일축해 버리기 일쑤입니다.

하지만, SI 형태의 프로젝트든, 패키지 개발 프로젝트든, 패키지 도입 프로젝트든, 어떤 프로젝트든 간에 프로젝트에는 목표가 설정되어야 한다고 생각합니다. 아주 구체적인 목표가요.

목표가 설정되면, 그 목표를 이루기 위해서 필요한 것이 어떠한 것들인지가 명시되어야 합니다. 그런데, 그 목표를 이루기 위해 어떠한 것들이 필요한지를 정의하기 위해서는 현재 상황의 분석이 필수불가결한 요소가 되는 것입니다.

예전에 제가 했던 말이고, 여기서 또 듣게 되는 말일지도 모르겠지만, "그러나, 맨땅에 헤딩하는 프로젝트도 있습니다. 그런 경우에는 분석을 어떻게 하지요?" 라는 말이 나올 수도 있습니다. 하지만, 그런 경우에도 분석은 수행되어야 합니다. 그래서 이미 있는 부분들을 최대한 활용할 수 있는 방안을 모색하여야 합니다. 이 업계에서 일을 하다 보면 "진정한" 맨땅에 헤딩이란 거의 없었습니다. 어느 조직이든 간에, 인프라를 어느 정도는 가지고 있고, 인프라가 없어도 사람은 가지고 있는 법입니다. - 말이 딴데로 새는것 같군요. :) 어쨌든 -

그럼 현재 상황을 어떻게 분석하는가? 현재 상황에서 무엇을 분석하여야 하는가에 대한 질문이 또 나오게 됩니다. 막연히 현재 업무가 어떻게 흘러가고 있는지를 분석한다. 현재 조직이 어떤식으로 되어있는지를 분석한다... 라기 보다는, 제 생각에 분석 항목은, 위에서 정의한 "큰 목표"를 달성하기 위해서 필요한 것들이 어떤 것인지, 그리고 그렇게 필요한 것들을 어떻게 달성할 것인지에 대한 전략을 세우는 데 필요한 항목들 - 그것이 되어야 한다고 생각합니다.

그 항목들이 무엇입니까? 라고 묻는다면, "그 항목은 각각의 전문가들이 가지고 있어야 합니다." 라고 대답하겠습니다. 쇼핑몰을 만드는 데 전문가라면 쇼핑몰을 보다 좋게 만들기 위해서 어떤 것들이 되어야 하며, 그것을 되게 하려면 어떤 것들이 필요하며, 쇼핑몰의 평가는 무엇을 기준으로 한다라는 자신의 "안" 을 가지고 있을 것입니다. 자신이 포탈의 전문가라면, 포탈에 대해서, 지식관리의 전문가라면, 지식관리에 대해서, 시스템 관리의 전문가라면 시스템 관리에 대해서 ... 라는 것이죠.

작금의 문제점은 프로젝트의 초기 단계에서 Vision, Goal, Objectives, Strategy 를 세울 수 있는 사람이 없다는 것입니다. 가끔 비전같은 것 - 뜬구릅 잡는 식으로 큰 목표를 잡는 것 - 을 세우는 경우는 있습니다만, 목표(Goal), 세부목표 및 필요사항(Objectives)을 세우는 경우는 거의 없었습니다.

필요사항과 전략이 없으면 사령관과 특수부대원들만으로 전쟁을 한다는 것과 같은 이치입니다. 어떠한 전략적 요소도 없이 싸우는 것은 거의 자살행위이지요. 옛날의 산적떼들도 어떤놈이 지나가면 덥치고, 아니면 안덥친다. 포졸들 달려오면 어느길 어느길 막고, 여의치 않은 경우는 어디로 도망간다. 싸그리 죽인다, 혹은 돈만 뺏는다 등의 작전은 가지고 있었을 겁니다. 이와 요즘 이런거 없이 프로젝트 하는 거 보면 조선시대 산적떼보다 불쌍하다는 거죠. 비유가 좀 과격한지는 모르겠지만...

게다가, 프로젝트가 프로젝트인 이유는 자원과 시간이 한정되어 있기 때문입니다. 자원과 시간이 한정되어 있는 상태에서 명확한 목표가 없이 앞으로만 가라고 하는 것은 사람들 일렬로 세워두고 계속 운동장을 돌게 하다가 모든 사람들이 지쳐서 쓰러지면 그만 뛰라고 하는 것과 마찬가지입니다. 끝이 보이지 않는 괴로운 형벌이지요.

어쨌든, 제 생각을 정리하면 다음과 같습니다.
프로젝트 수행 전에, (혹은 개발 전에) 는 설계 외에 다음과 같은 업무가 필요합니다.
* Vision 의 정의
* 프로젝트의 최종 목표의 정의(Goal)
* 프로젝트 세부목표 및 필요사항 정의(Objectives)
* 전략 수립( Strategy )
- 프로젝트 결과물의 도입 및 목표 실현을 위한 전략
- 프로젝트 수행 전략

그 외에도 많겠지만, 일단은 줄이죠. 좋은 하루 되세요.

모두들 좋은 하루 되세요~

익명 사용자의 이미지

프로세스에는 완벽이라는 단어를 사용할 수 없을 듯 합니다.

어디까지나 일하는 순서와 관리하는 방법에 대해서 그리고 나와야할
문서에 대하여 작성해 놓았다고 해도 괜찮으리라 생각됩니다.

기존에 자신해 해오던 방식을 버리고 새로운 방법론을 접하고
적용시킨다는 것이 쉽지 않으리라 생각됩니다.
이것은 잘못되었다고 봅니다.

개인적인 생각이기는 하지만 지금까지 자신이 해오던 방법을 일단
정형화 시키고, 이를 조금씩 다듬어 가는 과정을 가지는 방법을
가지는 것이 좋을 듯합니다.

제가 느끼는 것은 우리나라의 개발자(?)들은 많은 단계를 말로서
해결한다는데 문제가 있다고 생각되어집니다.
이를 문서화 하는 작업부터가 필요하다고 생각되어집니다.

이름하여 4단계정도로 나누고들 있죠.
1. 요구분석
2. 분석
3. 설계
4. 구현 및 배치
(물론 여러가지 방식의 차이로 단계는 줄여지거나 늘어날 수 도 있습니다.)

이러한 단계를 지키면서, 각 단계의 결과물에 대해서 생각해보고 정리해보는 것이 중요할것이라고 생각됩니다. 그러나 많은 단계가 말로 끝이나고 머리속에 정리를 하고자 하기 때문에나중의 문제가 발생할 수 있다는 것이죠.
특히 객체지향 방법론적인 관점에서 보자면 설계의 오류로 이어질 수도 있다는 것입니다.

제일 좋은 프로세스(방법론)이라는 것은 존재하지 않습니다.
물론 RUP, Fusion, MSF와 같은 프로세스는 각 회사에서 가지는 경험을 적은것이지 모든 문제를 해결할 수 있는 프로세스가 아니라는 것을 명심해야 한다고 생각됩니다.
어디까지나 자신에게 맞는 프로세스 개발하기 위해 노력해야 한다는 것이죠.

이쯤에서 이글을 마무리 하고자 합니다.
자신에 맞는 방법론을 개발하기 위해 노력해야한다는 것입니다
CMM이라는 유명한 프로세스 모델을 참조하여 스스로에게 맞는 방법을 만들어가는 과정을 가져보시는 것도 좋을 듯 합니다.

PS. 또 생각나면 적도록 하겠습니다.

익명 사용자의 이미지

1. 회사에서 이미 구축해 놓은 방법론을 쓴다.
2. 자신이 가지고 있는 (이미 경험으로 만들어 놓았거나, 새로 시도하려는) 방법론을 이용한다.

UML은 말 그대로 표현 방법일 뿐입니다. 그나마 저는 이것이 직관적이라고 생각되질 않아, 개념 설계엔 마인드 멥 방식을 이용하고, 로직엔 주로 순서도를 이용하며, 펑션 등 세부 설정엔 표를 이용한 서술형 방식을 이용합니다.

개발방법론은 자신이, 혹은 마음 맞는 사람들과 함께 스스로 구축해 나가는 것이 가장 좋다고 생각됩니다. (물론, 문서 포멧도 나름대로 정의해서 점차 체계적으로 만들어 가구요)

익명 사용자의 이미지

XP 씁니다.

익명 사용자의 이미지

그게 뭐에요?

익명 사용자의 이미지

익명 사용자의 이미지

내가 사용하는 방법은..
일단 코딩합니다..
하다가 생각나는거 이러케 저러케 마구 끼워 넣습니다..

몇개넣고나서 컴팔합니다.
에러 뜹니다..
에러 잡습니다..
에러 안잡히면 왜 안잡히는지..졸라 뒤집니다..
그러다가 에러를 고치기위해서 에러나는부분만 간단히
테스트합니다..

에러 고치면 다시 코딩합니다..
하다가 또 고칩니다..

이렇게 하는게 혼자할때는 편하지만..
여럿이 할때는 힘들더군요..

사고가 순차적이다 보니까..

익명 사용자의 이미지

UML이 좋다고들 하죠.. ^_^;
1년 정도 스터디를 했답니다.

결국.. Rose 나 이런것 대신에..
Power Point로 그리고 있긴 하지만 말입니다요.. ^^;;

익명 사용자의 이미지

방법론에 대해 가장 단순한 표현은 객체지향적이냐..
아니면 절차적이냐로 나눌수가 있을 겁니다.

객체지향일 경우 객체지향 언어를 선택하고
또한 그에 마땅한 설계툴이 있어야 되겠죠..

아마 이때 사용되는 설계 툴이 UML 이겠죠..

익명 사용자의 이미지

UML은 방법론은 아닙니다.
단순히 UML은 의미를 가지는 그림일 뿐입니다

방법론이라는 것은
UML과 같은 그래픽 표기법과
일의 진행을 관리할 수 있는 프로세스를 가져야 합니다.

그러므로 UML은 방법론이 아니라 방법론을 지원하기 위한
표기법일 뿐입니다.

익명 사용자의 이미지

UML은 Modeling 한 구조를 표현할 때 사용하는 언어 또는 방법 이기는 합니다만..

Unified Software Developing Process 라는 방법론도 있는디유.. ^^;

그넘이 UML 하고 한 세트 입니다.

익명 사용자의 이미지

잘...적당히...

익명 사용자의 이미지

아니! OMG에서 RUP를 표준으로 정했다는 말은 틀린듯 합니다.
그렇게 되면 다른 프로세스를 가진 회사들이 가만히 있지 않았을 텐데...
그렇게 되면 정보통신소식지들에 기사가 나왔을 테고...

방법론이라고 말하는 프로세스들은 크게 관리 프로세스와 개발 프로세스로 두가지로 나누어집니다.
제목 만으로 이해할 수 있을 것으로 생각되는 군요...

개발 프로세스는 개개인이 조금씩 다르게 되지요.
그리고 혼자서 개발할때는 특별히 어떠한 프로세스를 따른다는 것이 의미가 없을 때도 있으리라 생각됩니다.

방법론이라고 놓고 보니 너무 많은 부분을 설명해야 한다는 생각이 드는 군요.

혹시 다음에 또 글을 작성하게 된다면 조금 더 작성해보지요...

익명 사용자의 이미지

개발 방법에는 주먹 구구식 개발 방법이 아주 짱입니다.

익명 사용자의 이미지

당신의 앞날에 무궁한 발전이 있기를
묵념

익명 사용자의 이미지

히히
위 두 글 읽고 배꼽잡았습니다.

한가지는 유머있는 말이었다는 생각이고,
다른 한가지는 정말 진정한 개발자가 없다라는 생각을 표현했을 수도 있습니다.
너무 깊게 생각했나요~!
아뭇튼 정말 도움이 되는 글 많이 올라와서 좋습니다.
저에게 큰 힘이 됩니다.
글쓴이들에게 모두 ^^ 꾸벅~!

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.