소프트웨어 개발 방법론

 

소프트웨어 시스템을 개발하거나 유지 보수할 목적으로 수행되는 활동 일체 또는 절차를 의미한다. 

 

회사 내부의 개발 조직은 적당한 프로세스 모델을 보유하고 진행한다. 

 

프로세스 모델이 존재하는 경우 전체 프로세스 이해에 도움을 주며 방법이 구조화되고 자원 사용에 대한 사전 계획 및 통제가 가능하며 시스템 개발 과정을 추적하고 관리할 수 있다.

 

프로세스 모델을 선택 시 고려 사항

 

- 조직마다 프로세스 모델이 다름

- 프로젝트 유형에 따라 적절한 모델이 다름

- 대형 시스템의 경우 부분마다 다른 프로세스 모델이 적용될 수 있음

 

 

소프트웨어 공학은 카네기 멜론 대학의 연구소 홈페이지에 있는 모토와 구글의 정의는 다음과 같다.

The right softwere, delivered defect free, on t ime and on cost, every time The system of applying of an engineering discipline to the design, implementation and maintenace of sotrware systems.

 

이는 애자일 선언 사이트에 나오는 원칙과 유사하다.

결국 고객을 만족시키기 위한 모든 노력에서 파생된 학문이고 이는 컴퓨터 과학에서 나오는 모든 것들을 실제 생활에 적용하기 위한 것이 소프트웨어 공학이다.

 

 

1. 폭포수 모델

 

선형 순차 모델, 고전적 소프트웨어 생명 주기라고도 한다.

기본적으로 각 단계는 병행 수행되지 않고 거슬러 반복되지 않으며 한 방향으로 진행됨.

실제로 수정을 위한 재작업을 위해 앞 단계로의 피드백이 불가피하다.

 

다음 순서를 따른다.

1. 타당성 조사
   조직 측면, 경제적, 기술적, 운영의 타당성을 판단한다. 즉 투입 비용 대비 이익을 평가하는 단계이다.
   
   
2. 요구 분석과 명세
   시스템의 목적과 범위를 정하는 부분으로 요구사항 명세서를 만드는 부분이다. 
   요구사항 명세서는 정확하고 완전해야 한다.
   
   
3. 설계와 명세
   요구사항 명세서를 통해 설계를 하는 단계이다. 
   아키텍처 설계, 인터페이스 설계, 프로그램 설계를 진행한다. 
   
   
4. 코딩 및 단위 테스트
   설계를 통해 프로그램으로 작성하는 단계이며 구현된 모듈이 명세서를 만족하는지 테스트하여야 한다.
   이 경우 조직의 코딩 표준, 테스트 절차를 준수해야 한다.
   
   
5. 통합과 시스템 테스트
   모듈을 통합하여 점증적으로 시스템을 구축해 나가며 통합과 테스트 작업은 점증적 방식을 따른다.
   모든 작업이 끝난 이후 최종적으로 완성된 시스템이 요구사항을 만족하는지 테스트한다.
   
   소프트웨어 개발 현장에서 알파테스트를 진행한 후 대개 베타 버전을 릴리스 한다. 이경우는 일반 소프트웨어의 경우이며 주문형으로 커스텀 소프트웨어인 경우 개발자 플랫폼에서 실제 사용 환경을 구성한 후 테스트를 진행한 후 고객 사이에 제품의 인수에 대한 동의가 이루어질 때까지 반복 수행된다.
   
   
6. 인도
   클라이언트에게 완성된 시스템을 인도한다.
   
   
7. 유지보수
   소프트웨어가 폐기되기 전까지 일어나는 수정 및 보안 활동을 의미한다.

 

 

장점

 

선형 모델로 매우 단순하고 이해가 쉽다. 단계가 분리되어 있어 단계별로 정형화된 접근 방법과 체계적인 문서화가 가능하고 프로젝트 진행 상황을 명확히 알 수 있다.

 

단점

 

실제로 단순함이 개발 방법에는 매우 도움이 되지만 폭포수 모델 같은 경우 가장 큰 문제가 존재하는데 바로 요구사항 수립이다. 

 

고객의 요구사항은 개발 도중에도 변경될 가능성이 매우 크며, 하나의 단계가 잘못된 경우 연쇄적으로 모든 단계를 다시 해야 하는 경우가 빈번하게 발생한다. 이는 변경을 수용하기 매우 어려운 구조를 가졌다고 할 수 있다.

또한 시스템의 동작을 매우 나중에 확인할 수 있고 문서화에 대한 비용이 매우 크다. 

 

 

(실제로 SI사업은 폭포수 모델을 따르는 경우가 있다. 실제 개발이 완성된 후 배포를 한 경우에 사용자의 요구사항이 추가적으로 들어오는 경우가 많고 이경우 변경을 수용하기가 매우 어려운 점이 있다.

그리고 사업 기간도 짧고 그 와중에 문서에 대한 요구가 많아 실제 개발할 수 있는 기간이 길지 않다. 

 

개발자들에겐 충분한 고민을 통해 문제없는 프로그램을 개발할 의무가 있고 단지 동작되는 코드가 아닌 완벽한 프로그램을 만들기 위해 노력에는 반드시 시간이 투자되어야 한다.  

 

이는 충분한 피드백을 통한 설계 및 코드 리뷰를 통해 조직이 이후에도 유지 보수하기 쉽게 만들어야 하고 유연해야 하고 확장도 쉬워야 하는 시스템을 만들어야 하지만 짧은 시간과 많은 업무에서는 이를 완벽히 이행하기  어려운 경우가 많아 엎어진 프로젝트가 상당히 많다. 
)

 

만약 객체지향 설계가 잘되어 있고 유연함과 확장성을 가지고 있다면 상관없겠지만 사용자의 요구사항이 도메인 개념을 흔들어버리는 경우가 많기에 이는 현대에 들어서 잘 사용되지 않는 모델이다. 

 

 

2. 반복 진화형 모델

 

 요구사항은 개발 도중에도 변화고 개발 후에도 변한다. 이를 실제로 겪었고 나는 반드시 인지하고 있다. 

 

반복 진화형 모델은 불안정한 요구사항을 통해 초기 버전을 만들고 요구사항을 정제하여 새로운 버전을 개발하는 작업을 반복하여 시스템을 완성해가는 방식이다.

 

장점

 

요구사항이 불안정한 경우에 초기 버전을 만들기 쉬우며 점차적으로 명확한 요구사항을 도출하게 된다.

 

단점

 

빠르게 개발하여 프로토타입을 통해 진화를 할 수 있지만 개발 비용을 예상할 수 없고 소프트웨어의 잦은 수정 작업은 소프트웨어 구조에 악영향을 준다. 이를 통해 유지보수성이 현저히 낮아질 수 있다.

 

 

3. 프로토타이핑 방법

 

 이전 서울창업 허브에 갔을 때 몇몇 스타트업이 이 방법을 통해 사용자의 피드백을 빠르게 얻어 보완하는 식으로 앱을 개발하는 것을 본 적이 있다.

 

일반적으로 사용자는 소프트웨어의 입출력과 처리 기능을 자세히 요구하지 못한다. 개발자도 알고리즘의 효율성, 플랫폼의 호환성을 100% 확신하지 못한다.  따라서 빠르게 계획, 설계, 프로토타입을 만들어서 피드백을 받아 요구사항을 분명히 해나갈 수 있는 방법이다. 

 

프로토타이핑 종류

• throwaway prototyping
  프로토타입을 고객과의 의사소통 수단으로만 사용하는 경우이고 요구가 확인되면 프로토타입을 버리고 새로 개발에 착수한다. 
  
  
• evolution prototyping
  잘 알고 있는 부분부터 시작하여 계속적으로 발전시켜 완제품을 만드는 방법

 

장점

 

- 프로젝트의 실현 가능성, 개발 가능성을 판단하기 쉽고 사용자 간 의사소통이 명확해지기에 요구사항을 완전하게 만들기 쉽다. 

 

- 시스템을 미리 체험하게 함으로써 사용자 교육 효과도 존재하고 개발 단계에서 유지보수가 일어나는 효과가 있다.

 

단점

 

 - 문서화가 힘들며 진척 사항을 제어하기 힘들어진다.

 

 

4. 애자일 

애자일 소프트웨어 개발은 90년대 중반에 기존의 방법론에 반하여 일어났다.  가볍고, 기민한(agile) 개발 철학을 바탕으로 한 RAD나 XP를 필두로 해서 애자일 동맹을 구성했다. 

 

애자일 방법론이 추구하는 가치는 다음과 같다.

 

개인과 상호 의사소통이 프로세스나 도구보다 우선하며 동작하는 소프트웨어가 포괄적인 문서보다 우선하며 고객과의 협력이 계약 협상보다 우선하며 변화에 반응하는 것이 계획을 준수하는 것보다 우선한다.

 

 

변화를 수용하고, 협업을 강조하며, 제품의 빠른 인도를 강조하는 반복적 개발 방법이다. 

이는 문서화 작업보다 코드를 강조한다. 문서보다 소프트웨어 자체를 중요시한다. 

기존의 개발 프로세스는 설계 기간이 길며 재작업 시 오버헤드가 크다는 생각이다. 따라서 환경의 빠른 변화에 대응하고 빠른 인도가 중요하는 생각이다.

어차피 요구사항은 변경되기에 이것에 대응하는 것이 현실적인 방법이라고 제안하는 것이다. 

 

현재 애자일에 참여 중인 방법론들은 다음과 같다.

• Extreme Programming
• Scrum
• DSDM
• Agile ICONIX
• Crystal Clear
• Aglie documentation

대개 개발 팀원을 구할 때 Agile이나 XP같은 철학으로 팀을 운영하는 모습이 많은 것 같다.

5. 익스트림 프로그래밍

 

켄트 백이 만든 방법론으로 기존 개발 방법론은 위에서 아래로 진행하는 반면 XP 방법론은 아래부터 위로 향하는 습성을 갖고 있다.  XP에서 얘기하는 내용을 보면 방법론이라기보다는 개발자 개인 및 팀원 간의 습관이라고 보는 것도 무리가 없다.

XP는 대표적인 애자일 방법의 하나로 good practices를 적극적으로 적용할 것을 요청한다.

작고 빈번한 릴리스를 통해 빠른 피드백을 얻고 지속적으로 개선한다.

프로세스 중심이 아닌 사람 중심의 작업과 짝 프로그래밍을 통해 실현할 수 있다고 한다. 

단순한 설계와 TDD를 권장한다. 

코드의 품질 개선을 위해 리팩터링을 강력히 권고한다. 이는 애자일의 원칙에 좀 더 가까운 것 같다.

 

6. 테스트 선행 개발 

 

테스트 케이스를 먼저 작성하고 이것을 통과하는 코드를 만드는 방법이다.  다만 이는 매우 높은 지식수준을 요구한다. 

객체지향을 사용한 프로그램을 만든다고 할 때 TDD는 설계를 매번 검사하는데 이 설계가 객체지향스러운지 검토해야 하며 디자인 패턴을 통해 손쉽게 확장할도 있어야 하며 확장 가능성에 대해 빠른 사고를 통해 테스트를 진행해야 한다. 

따라서 매우 높은 소프트웨어 지식을 가진 시니어 개발자가 필요하다는 전제가 존재한다. 

 

TDD는 태스크 별로 테스트 케이스를 만들고 요구사항은 스토리카드로 스토리 카드는 태스크로 분해한다. 이는 요구사항과 코드와의 관계가 명확해진다. 

 

통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류가 유입되지 않도록 하는데 이는 기존 테스트 케이스를 재사용함으로써 가능하다.

 

추가적으로 스크럼( 프로젝트 관리 프레임워크), V-모델, 점증적 진화 모델 RUP, CBD 등등이 존재한다.

 

다만 어떤 방법은 절대 사용하면 안 되고 이것만 사용해야 한다는 방법론은 존재하지 않는다. 

 

각 프로젝트에 맞게 선택하는 것이 능력이고 폭포수의 단점이 상당해도 폭포수 이후에 나온 방법론들도 폭포수의 개념을 차용해서 출발한 것들이 상당수이기 때문이다.

 

개발을 시작하면서 느낀 점은 단순히 어떻게 하면 동작되는 코드를 작성하는 것이 전부가 아니라는 느낌을 굉장히 쎄게받았다.

지식이 개발에 한정돼있는 것이 아닌 세상에서 무엇을 추구하고 원하고 있는지를 파악해야 하고 사용자들의 니즈를 만족할만한 프로그램을 만들기 위해서 여러 분야를 공부하고 학습해야 한다는 것이다. 

 

그리고 사실 이러한 개발 프로세스가 프로젝트에 비대한 영향을 끼친다고 생각하지 않는다.