[DSW] 소프트웨어 공학에서 프로세스는 무엇일까

Software Process는 비슷한 개념을 가지는 여러 가지 용어와 혼용되어서 사용된다. 

예를 들면, Software Life Cycle, Software Development Methodology 또는 Software Method 같이. 

그런데 사실 여기서 함정은 많은 사람들이 Methodology와 Method에 대해 착각하여 둘을 섞어서 사용하고 있다는 점인데,

엄밀히 말하면 Methodology는 Method의 집합이고 어떤 방법이 아니라 방법을 위한 방법? 방법론이다. 

이 기준에서 Methodology가 프로세스에 좀 더 적합하다는 생각이 들었다.

우리가 건물을 한 눈에 보기 위해 모형을 만들거나, 실제 상황을 쉽게 설명하기 위해 그림을 그리거나 실제 세계를 모델로 만드는 일들이 일상생활에서도 많이 존재한다.

실제 세계를 모델로 만드는 과정이 '모델링'이고, 우리는 이 과정을 '추상화 한다' 고 말한다. 

그렇지만 실제를 모델로 추상화 하는 과정은 많은 것을 생략하고 단순하게 만들게 되는데 특히나 어떤 관점에서 보느냐에 따라 다양한 모델이 나올 수 있다. 즉, 하나의 모델로는 실세계를 온전히 바라볼 수 없다는 얘기다. 이 문제는 잠시 뒤로 하고,

그런데 모델 얘기를 하는 이유가 뭘까? 소프트웨어 프로세스에도 모델링이 필요할까? 

프로세스에 모델링이 필요하다는 말은 굉장히 생소하게 들린다. 하지만 이렇게 비교를 하면 또 당연하게 들릴수도 있다.

건물에서 모델은 건물 모형이다.

어떤 상황에 대한 모델은 그림이라고 하자.

프로세스에 대한 모델은 바로 '문서'다.

우리는 문서를 통해서 프로세스를 모델화한다. 이 문서에 들어가는 대표적인 내용은 Product (결과물), Role (사람의 역할), Pre-&Post-Condition (이전, 이후 상황) 이다. 

물론 프로세스 자체에 너무 집중하면 안된다. 중요한 건 만들고자 하는 것이니까.

하지만 프로세스를 적용함으로써 결과물의 품질을 보장할 수 있다. 특히 안정성에 대해 적절한 조취를 취하고 있다는 것을 입증해야 하는 경우 프로세스가 있다면 그것을 따르고 있다는 것을 보이는 것으로 어느 정도 입증 가능하기 때문에 정말 중요하다고 할 수 있다.

현재 대표적인 소프트웨어 프로세스의 방법은 크게 다음과 같은 카테고리로 나뉜다.

Waterfall, 폭포수

70년대 초반에서 80년대 초반까지 가장 적합하다고 인식되어져 왔다.

기본적으로 전 단계가 끝나지 않으면 다음 단계를 진행할 수 없다. (변화하기 힘들다)

Incremental, 점진적 

80년부터 나왔지만 현재 대세. 변화 적응력이 뛰어나고 사용자 피드백을 받기 쉽지만 폭포수에 비해 사람에 대한 의존도가 높다.

점점 더해져 갈수록 degrade되는 경향

Agile, 애자일

Software는 Art다!

뒤로 갈 수록 나온 햇수가 짧고, 진보적인 느낌이 강한 방법이다. 그렇다고 최근으로 올 수록 더 좋아졌다는 것은 아니고, 소프트웨어의 특징에 따라 제각각 장단점을 가진다.

소프트웨어 공학에서 정말 지긋지긋하게 듣는 실버불렛이 없다는 말은 이런 데서 또 나오게 된다.