개발방법론 그리고 요구공학

개발 방법론은 여러가지가 있다. 개발을 어떻게 할 것인가의 문제인데, 과거 전통적인 방법론은 폭포수 방법론이였다. 폭포가 떨어지듯 순차적으로 개발을 진행하는 것이다. 

기획 - 분석, 설계 - 개발 - 테스트 
이 순서는 전통적인 개발의 순서이다. 어떤 것을 만들지 고민하고, 인터페이스라든가 기능을 설계하고, 해당하는 기능을 만들고 테스트하는 것이다. 이 방법이 많이 변하였고, 어떤 것이 맞다기 보다는 방법론의 변화에 대한 이해가 필요하다.

방법론은 정답이라는 개념이 아니라 좋은 것을 선택하는 문제이다. 건축이라면 아마도 설계도를 그리는 것이 공정상에 가장 중요할지 모른다. 설계가 잘못되었다면 아무리 건축물을 열심히 지어도 붕괴의 위험이나 잘못을 돌이킬 수 없기 때문이다. 시스템 개발에 대해서도 기획, 분석, 설계 단이 매우 중요하다. 그리고 이 공정에서 명확하고 치밀하게 만드는 것이 나중에 오류를 줄일 수 있고, 출시 이후 잠재된 문제를 제거할 수 있다. 초기 단계에서 오류를 잡아내는 것이 나중 단계에서 오류를 잡았을 때보다 비용을 줄일수 있다. 거꾸로 말해서 나중 단계로 갈수록 비용이 그것을 조치하는 비용이 크게 올라간다. 예를 들면 초기 설계를 잘못했는데 바로 잡지 못한다면 개발을 하여 만드는 중에 또는 테스트 중에 발견을 하게 되면 시간 소요가 길어지고, 심지어는 개발을 다시 해야 하는 부분이 생길 수 있다. 그리고 심지어는 출시 이후에 오류를 발견하게 되면 회수를 해야 하거나 다시 배포를 해야 하거나 다시 설치를 해야 하기때문에 이 비용은 고객의 신뢰도를 포함해서 심각해질 수가 있다. 그러기에 최소한 테스트 단계에서라도 문제에 대해서는 모두 조치를 해야 한다 .

절차적 방법론으로 개발을 하다가 방법론이 바뀐 이유는 소프트웨어는 수정이 가능하기 때문이라는 점이다. 건축물에 대한 구축 방법로는 예나 지금이나 절차를 엄밀하게 준수할 것이다. 설계를 하고 건축 중에 다시 설계를 해서 바꾼다든가 하는 점은 심간한 결함 외에 건축물의 디자인을 바꾼다든지 내부 설계를 바꾸는 것은 굉장히 어려운 일이 될 것이다. 그런데, 소프트웨어는 사실 비용이 많이 늘어나는 것은 맞지만, 변경이 불가능한 것은 아니다. 심지어는 출시 하루 전에도 기능을 넣거나 빼기도 한다. 변경이 장점이 될 수도 있지만, 큰 리스트를 줄 수 있어서 치명적인 단점이기도 한다.

대표적인 개발 방법이 스피럴이나 프로토타입 개발 방법론이다. 스피럴은 나선형인데, 이것은 여러번 폭포수를 반복하면서 개발의 완성도나 구축을 수행하는 관점이다. 스피럴을 통해서 한번에 완벽한 설계를 해야 하는 부담을 덜고, 보완을 할 수 있는 장점이 있다. 프로토 타입은 최근 앱이나 서비스 개발시 많이 이용되고 있는데, 요구사항을 듣고, 핵심적인 기능을 위주로 개발을 한다. 요구사항을 완벽하게 다 담을 필요가 없이 어떤 모양일지 어떤 느낌일지 핵심 기능 위주로 개발을 하고, 그 이후에 방향을 추가로 잡는 것이다. 프로토타입을 만들어봄으로써 어떤 느낌일지를 더 확실하게 알고, 추가 진행함으로써 완성 후에 다시 만드는 리스크를 줄일 수 있다. 물론 명확하게 개발 기간을 얼마다라고 잡기가 힘든면이 있다. 하지만 지금과 같이 요구사항이 빠르게 변화되고, 시장에 반응이 민감할 때에는 좋은 방법이 될 수 있다.
기본적인 기능만 탑재한 앱을 시장에 배포하고, 그리고 사용자들로 하여금 댓글이라든가 반응을 보고, 방향을 정하고, 추가적인 기능을 넣는 것이다. 이렇게 하면 빠르게 사용자들의 반응도 볼 수 있고, 초기 유저들을 통해서 발전시킬 방법을 모색할 수도 있다. 그리고 긴 기간동안 개발함으로써 대응이 늦어질 수 있는 단점도 해소할 수 있다. 그래서 운영을 하면서 기능을 추가하는 방법도 있기때문에 이러한 방법로는 최근 서비스를 하고 있는 곳에서 많이 사용되어지고 있다.

소프트웨어의 개발 방법론은 정해졌다기 보다는 적절한 방법을 찾는 것이다. 테일러링이라고 해서 기존 개발 방법론 중에서 필요한 것들 위주로 발췌 해서 사용할 수도 있다. 이렇듯 현재 개발하고 있는 것과 맞는 적절한 것을 취하는 것이 중요하다.

요구공학이란?
말그대로 요구사항을 기준으로 하는 개발 방법론이다. 시스템을 구축할 때는 그 시발점이 고객의 요구로부터 시작된다. 어떨 때는 고객의 요구를 예측하거나 추측해서 개발을 하기도 한다. 고객의 요구는 시스템 구현과 밀접한 관계가 있다. 엄청나게 빠르고 정밀한 시스템을 만든다고 하여도 사용자가 필요 없으면 그만이다. 과거 기업에서 사용하는 시스템을 만들 때는 더욱 그러했다. 업무를 명확하게 이해해야하고 그 업무에 맞게 시스템을 구현해야 한다. 이것이 요구공학이다. 이것은 기업용 시스템을 구축하는 곳에서 시작되었지만, 실은 현재의 대부분의 서비스나 앱등을 만들때도 이것이 근간이 된다. 사람들이 필요로 하는 것을 생각하는 것, 이것이 시스템 개발의 시작이다. 아무리 유용할 것 같은 물건도 유용하게 사용할 사람이 없다면 그것은 그냥 신기한 물건이 될 뿐이다. 거꾸로 사람들이 필요로 하는 것을 정확히 파악해서 만들어둔다면 그것은 요긴하여서 많은 사람들이 사용하는 프로그램이 될 수 있다.