티스토리 뷰
저도 처음에는 프로그래밍 언어만 할 줄 알면 프로그램을 만들 수 있다고 생각했던 적이 있었습니다.
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^
하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.
바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..
흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.
물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.
특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.
프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.
다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.
즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..
이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.
앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..
"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..
설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..
코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.
테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...
마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..
기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.
중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.
[읽을만한 자료]
소프트웨어 개발 생명 주기의 이해
코딩보다 먼저 할 일 ‘분석과 설계’
설계도가 우선, 그 다음이 구현이다
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^
하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.
바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..
흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.
물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.
특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.
프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.
다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.
즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..
이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.
앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..
"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..
설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..
코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.
테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...
마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..
기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.
중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.
[읽을만한 자료]
소프트웨어 개발 생명 주기의 이해
코딩보다 먼저 할 일 ‘분석과 설계’
설계도가 우선, 그 다음이 구현이다
'컴퓨터공학 > 소프트웨어공학' 카테고리의 다른 글
기술 준비 단계를 나타내는 기술 성숙도(TRL)에 대해~ (1) | 2015.02.08 |
---|---|
소프트웨어공학의 3R(Reverse-Engineering, Re-Engineering, Re-Use)에 대하여 (0) | 2011.10.01 |
Agile 이야기 (0) | 2010.06.28 |
ITSM(IT Service Managment)에 대하여 (0) | 2010.06.25 |
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- Hadoop
- 자바스크립트
- HTML
- java
- 마케팅
- 분석
- 책
- 안드로이드
- 웹
- 아이폰
- 빅데이터
- XML
- 애플
- 통계
- ms
- r
- 도서
- 하둡
- 모바일
- 구글
- SCORM
- 디자인
- 맥
- fingra.ph
- 클라우드
- mysql
- 세미나
- 자바
- 프로젝트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
글 보관함