Software Process
소프트웨어 프로세스는 소프트웨어를 개발하는 과정을 말한다. 아주 많은 과정이 있지만 다음과 같은 요소들을 포함한다.
- Specification : 소프트웨어가 어떤 일을 해야하는지 정의한다.
- Design and implementation : 기본적인 시스템을 정의하고 시스템을 적용한다.
- Validation : 사용자의 요구사항을 수행하는지 확인한다.
- Evolution : 사용자의 추가 요구사항에 대해 반응할 수 있는지를 확인한다.
Software Process Model
소프트웨어 프로세스 모델은 누가, 무엇을, 언제, 어떻게 할 것인지를 정의하는 방법이다. 이를 통해 일, 방향, 역할 ,결과물 등을 관리하고 만들어내는 방법을 설정한다. 다른 말로 SDLC(SW Development Life-Cycle) model -> "SW생명주기모델"이라고도 불린다.
- Waterfall
- Increamental
- Evolutionary
- Spiral
- CBD(Component-Based Development)
- Iterative-Agile
- Iterative-RUP(Rational Unified Process)
이 중 Waterfall Model을 제외한 나머지는 Iterative Model이라고 부른다.
The Waterfall Model(폭포수 모델)
1960년도에 제안된 가장 클래식한 모델이다.
- Requirements definition : 요구사항 정리 -> 사용자의 요구사항을 정리하고 할 일을 정의한다.
- System and software design : 시스템과 소프트웨어 개발 -> 시스템과 소프트웨어를 어떻게 만들 것인지 디자인한다.
- Implementation and unit testing : 구현과 유닛 태스팅 -> 소프트웨어를 만들고 테스트한다.
- Intergration and system testing : 합치고 시스템 테스팅 -> 만든 소프트웨어들을 합치고 전체 테스트한다.
- Operation and maintenance : 유지보수 -> 끝난 시스템을 발매하고 유지보수한다.
폭포수 모델은 요구사항을 빠르게 정할 수 있다. 또한 일들이 순차적으로 진행되므로 주변 사람들과 같이 개발해 나갈 수 있다. 그러나 요구사항이 변경되면 처음으로 돌아가서 다시 만들어야 한다는 단점이 있다. 요구사항이 처음부터 제대로 정의되고 개발에 투여되는 사람들이 많은 큰 프로젝트에서 많이 사용한다.
The Incremental and Evolutionary Model
요구사항의 세세한 부분을 각자 구현하고 조금씩 병합하면서 만드는 모델이다. 요구사항을 처음부터 정하고 세세하게 나누어서 만들면 Incremental development고, 요구사항을 추상적으로 정하고 변하는 요구사항에 따라 그때그때 만들면 Evolutionary development다.
Incremental model은 필요한 기능에 따라 각각 독립적으로 소프트웨어를 만들기 때문에 필요한 기능간의 연결성이 많지 않을 때 주로 사용한다. 그렇게 만든 소프트웨어를 마지막에 합쳐서 최종 결과물을 낸다.
Evolutionary model은 기능간의 연결성이 많아 독립적으로 소프트웨어를 만들기 힘들 때 사용한다. 이전에 만든 모델은 일단 끝까지 만들고, 도중에 기능을 추가한 모델을 같이 만든다. 더 이상 추가할 것이 없는 모델을 최종결과물로 선택한다.
The Sprial Model
"risk analysis"가 들어간 모델으로, 각각의 과정이 시작하기 전에 리스크에 대한 분석을 하고 시작한다. 안전성이 중요한 모델을 만들 때 많이 사용한다.
CBD(Component-Based Development)
독립적으로 구현하고 테스팅까지 끝난 컴포넌트를 만든다. 안에를 보지 않고도 무엇을 하는지 이해가 되기 때문에, 이 컴포넌트를 필요한 곳에 사용하여 프로젝트를 만든다.
CBD는 software reuse, 다시 말해 소프트웨어를 다시 사용하는 것을 기본으로 하는 모델이다. 문제는 Software Pool에 컴포넌트들이 쌓여야 원하는 것을 사용할 수 있는데, 개발자들은 그럴 시간이 없다는 것이다. 남이 이해할 수 있는 코드를 만드는 것은 훨씬 어렵고, 이미 개발한 컴포넌트들을 좀 더 다듬을 시간이 부족했다. 또한 인터넷의 발달로 많은 해결방법들을 공유할 수 있게 되면서 기업에서 굳이 Software Pool을 만들 필요가 없어졌다. 앞과 같은 이유로 자주 사용되지는 못했다.
장점 : 안전성이 보장되어 있으므로 리스크를 줄이고, 비용 또한 줄일 수 있다. 역할에 맞는 컴포넌트들만 뽑아서 조합하므로 빠른 개발이 가능하다.
단점 : 기능을 고치고 싶을 때 컴포넌트를 수정하기 쉽지 않으므로 유지보수가 어렵다. 또한 내가 정확히 원하는 컴포넌트를 찾기 힘들거나 애초에 없을 수 있다.
The Iterative Model - Agile
에자일 모델은 그때그때의 요구사항에 맞춰서 빠르게 프로그래밍 하는 것으로, 빠른 구현과 좋은 대처 능력이라는 장점때문에 최근에 제일 많이 사용하는 모델 중 하나이다.
불필요한 문서 작성이나 요구 사항 명세서 등을 작성하지 않는다. 계속 수정되기 때문에 쓸모없는 작업들을 줄이고 코드 자체를 좋게 만드는 데 노력을 한다. 그렇게 만들어진 코드들은 누가 봐도 이해 가능하며, 다른 사람들이 편하게 사용할 수 있다.
또한 사용자(Client)들이 프로젝트에 상주하여 있다. 사용자들이 소프트웨어를 같이 만들기 때문에 변경사항에 민첩하게 반응할 수 있고 폭포수 모델같이 뒤로 돌아갈 필요가 없어진다.
Agile Manifesto(에자일의 마음가짐)
에자일은 폭포수 모델과 비교되는 특성들이 있다. 굵은 글씨는 에자일이고 취소선은 폭포수 모델이다.
- Individual over
processes and tools: 정해진 도구와 방법들을 쓰기보단 개개인에게 맡긴다 - Working software over
documentation: 문서화를 하기보단 코드를 깔끔하게 만든다. - Customer collaboration over
contract negotiation: 계약서를 만들기 보단 사용자와 협업한다. - Responding to change over
following a plan: 계획에 따라서 진행하기보단 변화에 따라 진행한다.
Rational Unified Process(RUP)
에자일의 장점이자 단점인 문서를 쓰지 않는다는 점은 개발과정을 줄일 수 있지만, 유지 보수(maintanance)가 힘들다. 이를 극복하기 위해 나온 것이 RUP다.
- 다음과 같은 특성을 가지고 있다.
- Iterative
- Risk-driven / Client-driven / Architecture-centric
- Use-Case-driven
- 과정과 구조가 잘 짜여진 소프트웨어 개발 방법이다,
- 4단계와 9개의 분야로 나눠진다.
- 개발 과정을 줄이면서도 구조가 짜여있어 유지보수가 가능하기 때문에 대부분 이 방법을 사용한다.
- Inc : Project Planning - 전체적으로 어떻게 해야할 지를 파악한다.
- Elaboration : Architecture, Client requirement - 구조를 짜고, 중요한 사용자 요구를 구현하여 골조를 잡는다.
- Construction : 안정적으로 골조를 잡으면 개발하는 과정을 거친다. 의존성이 낮은 부분부터 개발한다.
- Transition : 최종적으로 결과물을 내고 사용자가 쓸 수 있도록 한다.
