[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 02 - Project Planning

1편을 못봤다면

[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서

 

 

 

Project Planning (프로젝트 계획)

소프트웨어 공학의 유명한 말이 있다.

 

"No Silver Bullet"

 

은탄(=sliver bullet)은 서구에서 악마, 늑대인간을 잡기 위해 쓰는 무기로 인식되었다. 은탄이 있으면 악마든 뭐든간에 다 때려잡을 수 있다는 소리다. 마치 원펀맨 주먹마냥 한 번에 해결할 수 있는 무기라고 생각하면 된다.

No silver Bullet 이란 말은 모든 프로젝트에 적용할 수 있는 해결책이 없다는 것을 의미한다. 각각의 프로젝트가 가지고 있는 특성이 다르고 시간, 인력 등과 같이 주어진 조건도 다르므로 어느 한 가지 방법만으로 접근하면 안된다.

여러 가지 방법을 통해 소프트웨어를 만들어야 한다.

 

 

1 Waterfall Model vs Iterative Model

방법론은 크게 두 가지로 나뉜다.

 

첫 번째는 Waterfall Model이다.

폭포수는 한 번 떨어지면 올라갈 수 없다

폭포수는 한 번 떨어지면 돌아가지 않는 것처럼 처음부터 차근차근 단계를 지켜나가는 것을 말한다.

아까 말한 6단계에서 Project Planning을 제외한 5단계를 순서에 맞춰 진행한다.

한 단계가 끝나면 이전 단계로 돌아가지 않는다.

 

WaterfallModel을 적용하는 소프트웨어들은 플랫폼 앱처럼 소비자의 니즈를 맞춰서 소프트웨어 개발하는 것이 아닌 처음부터 확실한 목표를 가지고 있다. 주로 요구사항(=Requirement)이 초기에 확정되고 큰 프로젝트를 진행할 때 사용한다. 예를 들어 우주 탐사선이나 하이패스 같은 곳에 사용되는 소프트웨어들은 그 목적과 기능이 확실하고 규모가 큰 곳에서 주로 사용하는 방법론이다.

 

 

두번째는 Iterative Model(=Agile)이다.

무한 반복

애자일이라고도 하는데 한 번쯤 들어본 용어일 것이다.

만족된 버전이 나올 때까지 소프트웨어 공학 5단계를 계속 반복해서 진행하는 것이다.

 

엄밀히 말하면 애자일은 Iterative Model에 있는 방법론 중 하나이다.

애자일 자체만 사용하지는 않고 다른 개발 방법론에 끼워서 사용하는데 요즘은 그냥 퉁쳐서 애자일이라고 부르는 경우가 많다.

 

애자일 말고도 Incremental Model, Evolutionary Model, Rational United Process, Component-base Development 등 여러가지 방법들이 있다. 여기에 Waterfall Model도 Iterative Model에 속한다. Waterfall Model을 반복해서 사용하면 그게 Iterative Model 속 Waterfall Model 이다. 

 

Iterative Model의 경우 우선 결과물(=프로토타입)이 빨리 나온다. Iterative 1번 할 때마다 결과물이 나온다.  waterfall Model의 결과물에 비하면 매우 빈약하지만 이 결과물에 따라 향후 계획을 수립할 수 있다. 하루가 멀다하고 바뀌는 시장에 바로 바로 반응할 수 있다.

 

 

 

+애자일에 관하여

애자일에 대해 엄밀히 따지자면 애자일 방법론이랑 애자일 개발 방법론은 다르다.

 

애자일 방법론은 Iterative Model 중 하나로써 소프트웨어 공학 5단계를 계속 반복하는 것을 말한다.

개발 기간이 딱 정해져 있는 것은 아니고 Iterative 주기에 따라 달라진다.

기획자와 함께 정리한 요구사항들(Requirements) 을 바탕으로 코딩을 하고, 유지/보수를 위해 기존처럼 문서를 작성한다. (문서는 swift 공식문서 같은 걸 생각하면 된다.)

 

이에 반해 애자일 개발 방법론은 개발을 오지게 반복하는 것이다. 

가장 유명하고 강력한게 XP(Extreme Programming) 이다.

이 XP를 사용할 경우 약 2주마다 결과물을 만들어내야 한다.

이렇게 시간이 촉박하다 보니 문서적는 시간도 아까워서 문서도 작성을 하지 않는다.

문서가 없으니 나중에 수정할 때 힘들 것이다. 이 때문에 지속적으로 리팩토링을 하며 코드의 단순함을 유지시켜주어야 한다.

이렇게 빠르게 결과물이 나오면 유저 입장에서는 좋다. 하지만 개발자 입장에서는 죽어나는 그런 개발방법론이다.

 

 

 

 

2 절차지향 프로그래밍(SASD) & 객체지향 프로그래밍(OOAD)

어떤 프로그램을 만드느냐에 따라 사용하는 프로그래밍 언어도 달라지고 그에 따라 프로그래밍 방식도 달라진다.

C 를 사용한다면 절차지향 프로그래밍을 할 것이다.

Java, C++, C#, Python 같이 요즘 사용하는 언어 대부분이 객체지향언어이다. (자바민국)

대부분은 객체지향 프로그래밍을 한다고 생각하면 된다.

 

C++ 도 객체지향에 속하긴 하지만 C의 포인터를 그대로 사용하기 때문에 어떻게 사용하느냐에 따라 두 군데 모두 속한다고 말할 수 있다. 물론 대부분 객체지향 프로그래밍에 사용한다.

 

 

 

 

 

3 개발 필독서

출처 : yes24

방법론

클린 애자일 - 로버트 C.마틴 링크

함께 자리기 - 김창준 링크

 

객체지향 방법론

객체지향의 사실과 오해 - 조영호 링크

오브젝트 (코드로 이해하는 객체지향 설계) - 조영호 링크

 

객체지향 방법론과 관련된 책들의 경우, 프로그래밍 언어 문법을 배울때 읽으면 이해도 잘 안되고 기억에 잘 남지도 않는다. 어느정도 코딩을 해보고 어떤식으로 코드를 설계하면 더 좋은 프로그램을 만들 수 있을까 고민할 때 읽어보는 것이 더 유익하고 정신건강에도 이롭다.

 

 

 

다음 편 보기

[개발 / 필독서 ] 소프트웨어 공학으로 보는 개발자 필독서 03