소프트웨어 프로세스 모델이란
소프트웨어 프로세스
이전 포스트에서도 다루었지만 다시 이야기를 하자면, 소프트웨어 프로세스는 소프트웨어 시스템을 개발하기 위해 필요한 구조화된 활동들의 집합이다.
여러가지 종류의 소프트웨어 프로세스가 있지만 모두 아래의 요소들을 포함하고 있다.
- Specification
- Design and Implementation (Development)
- Validation (Testing)
- Evolution (Maintenance)
소프트웨어 프로세스 모델
소프트웨어 프로세스 모델은 어떤 프로세스의 대표적인 형태라고 할 수 있다.
Plan-driven processes VS Agile processes
프로세스 모델에는 크게 두가지 형태가 존재한다.
하나는 Plan-driven, 다른 하나는 Agile이다.
Plan-driven proecess
Plan-driven 프로세스 방식은 모든 프로세스 활동이 사전에 계획되어 있는 방식이다.
Plan-driven 프로세스 방식은 전체적인 계획이 존재하기 때문에 진행 상황이 계산할 수 있다. ▼
전체 계획중에 이 계획을 수행중이라면 각 계획이 끝나고 나온 문서를 통해 전체에서 어느정도 계획이 수행됐는지 알 수 있다.
즉, 시작할 때 계획을 전부 정하고 그 계획대로 진행하는 방식이다.
Agile process
Agile의 뜻은 ‘민첩한’이다.
이름 그대로 우직하게 하나의 방식을 밀고가기 보다 상황에 맞게 계획을 바꿀 수 있는 형태의 프로세스 모델이다.
Agile 프로세스 방식은 우선은 하나의 단계(incremental)만 계획한다.
하나의 단계만 개발을 한 후에 그 다음에 필요한 요소들을 계속해서 붙여나가는 방식의 개발이 진행된다.
Plan-driven과는 다르게 각 단계가 끝나고 문서가 체계적으로 나오지는 않는다.
그렇다고 문서를 작성하지 않아도 된다는 것이 아니다.
시스템은 여러 버전들이나 여러 단계들로 개발이 되며, 고객들의 요구나 변화에 대한 반영이 쉬운 편이다. ▼
"Agile은 문서를 작성하지 않아도 괜찮대. 귀찮으니까 우린 Agile하게 하자!"
반은 맞고 반은 완전히 틀린 이야기이다.
Agile 방식이 매 단계가 끝난 후에 문서가 Plan-driven만큼 나오지 않는 것은 맞다.
하지만 거기에는 하나의 전제가 있기 때문이다.
Agile 방식의 문서는 해당 개발에 참여한 개발자의 이해도로 대신되기 때문이다.
문서가 없는 대신 각 개발자들이 해당 소프트웨어에 대한 이해도가 굉장히 높다.
그렇기에 별도의 문서가 없어도 무엇을 어떻게 개발해야할 지 안다.
단순히 문서를 작성하기 싫어서 Agile 방식을 택했다면, 이는 좋지 못한 선택이라고 할 수 있다.
“둘을 섞은 것은 없나요?”
둘을 섞은 기법은 물론 존재하겠지만, 대체로 둘 중 한 쪽의 방법만을 사용하는 것이 아니라 양 쪽 다 사용하곤 한다.
시작할 때 계획을 전부 정하는것은 엄청나게 힘들것이다.
규모가 큰 프로젝트를 계획을 전부 정할 생각을 하면, 기획와 디자인만 몇 년을 하게 될 수도 있다.
하지만 그렇다고 프로젝트의 이해도만 믿고 프로젝트 전체를 Agile 방식으로 진행하다가 팀원이 교체되면 큰일이 나게 된다.
그렇기에 대체로 두 방식을 모두 적용하여 Plan-driven 방식과 Agile 방식의 단점을 서로 보완해준다.
사실 무엇보다도 소프트웨어 프로세스에는 맞고 틀리고가 없으니 선택은 자유다.
소프트웨어 프로세스 모델들
Waterfall model
Waterfall 모델은 앞의 과정이 완료되면 그 다음걸 제작하는 순차적인 방식의 모델이다.
정형화 되어있고 미리 모든걸 다 정해놓는다는 점에서 Plan-drive model의 형태라고 할 수 있다.
장점
Waterfall 모델은 매 단계에서 문서가 생성된다는 것이다.
코드 뿐만 아니라 System Document와 같은 것이 매 단계마다 작성이 된다는 것이다.
장점…인가?
하지만 문서가 작성이 되면 뭐가 좋은건지 싶을 수 있다.
내가 코드를 짰으니까 내가 그 코드에 대해서 모를리가 없는데, 그리고 나와 같이 코드를 짠 동료들도 그 코드에 대해서 모를 리 없을 것이라고 생각이 들 것이다.
"그러나 만약에 동료가 바뀐다면 어떻게 될까?"
단체에서 인원교체는 아주 흔한 일이다.
어제까지 같이 일했던 내 동료가 내일도, 모레도, 그리고 내년에도 같이 일하고 있을거라고 보장할 수는 없다.
그러면 새로운 인원이 들어오게 되고 그 사람에게 목표는 무엇인지, 지금까지 어느 정도를 했는지, 다음에 해야할 것이 무엇인지를 빠르게 알려줘야한다.
이런 점에서 문서가 있다면 이런 작업들이 굉장히 쉽게 진행이 될 수 있다.
이런 역할이 아니더라도 기존에 있던 멤버들의 프로젝트에 대한 이해도를 높일 수 있다.
단점
중간에 요구가 바뀌게 되면 다시 돌아갈 수 없다는 단점이 있다.
이미 회사, 단체는 첫번째로 들어온 요구사항에 대해 모든 계획을 꽤나 정교하고 유기적으로 짜놓았다.
그러나 요구사항이 바뀌게 되면 계획들이 유기적으로 짜여져있는 탓에 중간 부분의 계획 하나만 바꿔도 전체의 계획을 바꿔야할 수 있다.
이는 엄청난 손실을 야기할 수 있는 치명적인 단점이다.
만들던 것을 폐기하고 처음부터 다시 만들기에는 투자한 비용이 너무나도 클 수 있기 때문이다.
그러나 더 큰 문제는 요구가 바뀌는 것은 아주 흔하게 있는 일이라는 것이고, 기술적인 환경이 변하는 경우도 있다는 것이다.
요구가 바뀌는 것은 아무래도 개발자 농담 같은데서 어렴풋이 봤을 것이라고 생각한다.
"하지만 기술적인 환경이 변한다는 것은 무슨 이야기일까?"
가장 쉽게 이해할 수 있는 예시는 OS라고 생각한다.
요즘에는 권한 설정이 굉장히 세부적으로 바뀐 편이지만, 아주 찰나의 순간일 수 있겠지만, 몇년전만 해도 권한 설정이라는 항목 자체가 없었다.
이런 권한에 대해 전혀 생각하지 않고 개발을 했다가 OS의 업데이트로 권한 정책이나 파일 접근 정책이 바뀌게 되면 프로젝트를 재설계해야할 수도 있다.
또한 라이브러리의 업데이트와 프로그래밍 언어의 업데이트도 문제가 될 수 있을 것이다.
대체로 한 번 정한 버전을 그대로 사용하려는 편이지만, 현재의 버전에 문제가 발생하여 업데이트를 무조건 해야하는 경우라면 조금 난감할 수 있다.
적절한 사용
“그러면 Waterfall은 사용할 수 없는 프로세스 모델이 아닌가요? 도대체 어디서 사용하는거죠?”
확실히 위의 단점을 보면 Waterfall 모델은 일반적인 상황에서는 전혀 사용할 수 없는것 처럼 보인다.
그러나 Waterfall 모델은 요구사항이 확실할 때 사용할 수 있다.
사실 이건 말을 안해도 알 것이다. 요구사항이 바뀐다는 것이 문제라고 이야기를 했으니 말이다.
중요한건 언제 요구사항이 확실해지냐는 것이다.
1. 요구사항을 초반에 높은 이해도로 파악할 수 있는 경우
요구사항이 바뀌는 것도 문제지만, 두루뭉술하게 설명된 요구사항이나 불분명한 요구사항에서 몇가지 요소들을 놓치게 될 때도 있다.
고객의 요구사항 자체가 바뀐건 아니지만, 처음에 파악했던 요구사항에는 없는 내용이 추가되는 것이기에 Waterfall model에서는 곤란할 수 있다.
하지만 오히려 반대로 요구사항을 처음에 굉장히 높은 이해도로 파악하게 되면 고객이 추가하지 않는 한, 예상치 못한 요구사항이 등장하지는 않는다.
2. 변화가 거의 없는 경우
물리/자연 법칙과 같은 과학적 계산은 한 번 정해지면 바뀌는 일이 거의 없다.
변화가 없다는 것은 새로운 요구사항의 등장도 없다는 것이기에 이런 경우에 Waterfall model이 적절할 수 있다.
3. 여러 곳에서 거대한 규모의 시스템을 개발하는 경우
거대한 규모의 시스템을 한 소규모 팀에서 만드는 것은 영겁의 시간이 걸릴지도 모른다.
그래서 거대한 규모의 팀을 분할해서 개발을 하게 될 텐데, 요구사항이 수시로 바뀌게 되면 그 요구사항들이 전달이 제대로 안될 수도 있다.
그렇게 되면 시스템 개발에 큰 영향을 미치게 될 수 있기에 전체적인 개발을 정해놓은 Waterfall model이 적합하다.
Incremental development
가장 기초적인 단계부터 개발을 한 다음에 사용자들에게 공개한 뒤, 사용자들로부터 나온 의견들을 토대로 개선해나가는 방식이다.
개선한 프로그램은 새로운 버전으로 이름이 붙여져 나가게 된다.
즉, 초기버전 V1 을 만들고, 이후 V1.1, V1.2, … , V2.0 으로 계속해서 버전 업을 시키는 방식이다.
장점
Incremental development는 agile한 개발 방법으로 구현 사항들은 사용자들에 의해 진행이 된다.
사용자들이 시스템에 대해 사용하고 피드백하며 시스템의 개발이 진해잉 된다.
또한 명세에 대한 불확실성을 풀기 좋다.
제대로 명세되지 않은 모호한 부분들을 유저 피드백이나 점진적인 개발로 해결할 수 있다.
단점
하지만 Waterfall 모델과 같은 Plan-drvien 모델들과는 다르게 프로세스가 어느정도 진행되었는지 확인하기가 쉽지 않다.
보통 당장 앞, 그리고 다음 까지의 계획이 있을 뿐 전체 목표, 궁극적인 목표에 대한 것이 문서화되어있지 않기 때문에 현재 개발하는 부분이 전체에서 어느정도인지를 알기가 힘들다.
그리고 시스템이 사상누각이 될 수도 있다.
전체적인 시스템이 어떻게 될 지 계획을 짜고 들어간 게 아니라 유저들의 피드백과 필요한 기능들을 업데이트 해 나가기 때문에 안정성이 떨어질 수 있다.
심지어는 agile한 방법의 장점인 요구사항 변경이 나중에는 엄청난 비용 손실로 돌아올 수 있다.
구조가 제대로 받쳐주지 못하면 시스템을 하나 바꾸는데 엄청난 어려움과 비용이 들어갈 수 있다.
적절한 사용
그렇다면 Incremental development는 어디에 사용하는게 좋을까?
위의 단점을 최소한으로 작용하는 곳에서 사용하는게 좋다.
위의 단점은 구조를 잘 짜면 발생하지 않겠지만, 규모가 큰 프로젝트에서는 조심한다고만 해결이 되는게 아니기에 아무래도 큰 프로젝트에서 사용하기엔 힘들다.
그렇기에 소규모 혹은 중간규모의 시스템을 만들 때 적절하다.
"그렇다면 대규모 시스템에서는 아예 사용이 불가능한걸까?"
대규모 시스템 개발의 메인 방법으로 쓰기에는 무리가 있지만, 대규모 시스템의 확정이 제대로 되지 못한 부분이나 이해도가 부족한 부분에서 사용할 수도 있다.
전에 소프트웨어 프로세스 모델 글에서 언급했듯이 Plan-driven이나 Agile 둘 중 하나만을 계속해서 사용하지 않고 둘 다 사용할 수 있다는 것이 여기에 해당된다.
Integration and Configuration
재사용에 중점을 둔 방식으로 기존에 있는 컴포넌트나 어플리케이션들을 합치는 방식이다.
이미 있는 것들을 새로 만들지 않고 최대한 가져다 사용하기 때문에 기초적인 시스템을 만드는 시간을 최소한으로 할 수 있다.
최근에는 이런 재사용 방식이 굉장히 많이 사용된다고 한다.
장점
장점은 앞에서 이야기 한 대로 개발을 해야할 부분을 최소한으로 줄일 수 있다.
이는 어떻게 보면 프로그래밍 언어의 함수와 라이브러리를 사용하는 이유와도 같다.
개발이 최소한으로 줄면서 당연히 프로젝트 완성 속도도 빠르게 증가하게 되고, 사용자들에게 더 빠르게 배포할 수 있게 된다.
단점
재사용 요소들에 변화가 생기면 문제가 발생할 수도 있다.
재사용 요소들을 본인이 만든게 아니거나 팀에서 만든게 아니라면 요소에 문제가 생겼을 경우에는 시간이 굉장히 오래걸릴 수도 있다.
해당 요소의 문서가 아무리 잘 짜여져있다고 하더라도, 그 요소의 문서를 보면서 직접 고치는 것은 생각보다 시간이 많이 들어가게 된다.
또한 이렇게 재사용을 통해 개발 리소스를 줄이려고 한건데 오히려 재사용 요소를 고치는데 시간이 많이 들게 되면 재사용을 하게 되는 이유가 없어진다.
요구사항의 타협이 불가피하다.
웹 서비스와 같은 시스템에서 이 방식을 많이 쓰는데, 사용자들의 요구사항을 듣지않고 빠르게 개발해버렸을 때 나온 서비스는 사용자들에게 전혀 필요가 없는 서비스일 수 있다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 6. Agile (0) | 2024.01.21 |
|---|---|
| 5. Process Iteration (0) | 2024.01.21 |
| 4. Process Activities (0) | 2024.01.20 |
| 2. 소프트웨어 공학이란 (0) | 2024.01.19 |
| 1. 소프트웨어 공학 개요 (0) | 2024.01.18 |
