소프트웨어 개발의 모든 것 - SRS, 폭포수 모델

 

소프트웨어 개발의 모든 것 국내도서 저자 : 김익환,전규현 출판 : 페가수스 2010.06.01 상세보기

01. 요약

 ◎ SRS : SRS를 흔히 요구사항 명세서, 기능 명세서라고 부르기도 하는데, 사실상 SRS를 대신해서 사용하기에는 불충분하다. SRS는 흔히 생각하는 기능 명세보다 훨씬 많은 다양한 정보를 체계적으로 담고 있다. 따라서 SRS라는 용어 그대로 사용하는 것이 좋다. 

◎ 소프트웨어의 생애주기 : 소프트웨어의 생애주기란 소프트웨어 탄생에서 소멸까지의 모든 활동을 말한다. 대부분의 사람들이 생애주기에 대한 고민 없이 소프트웨어 개발을 진행하고 있다. 그러나 각각의 소프트웨어 프로젝트에 맞는 적합한 생애주기를 선택해야만 소프트웨어 프로젝트를 보다 효율적으로 진행할 수 있다.

 

◎ 폭포수 모델 : 폭포수 모델은 모든 생애주기 모델의 근본이다. 순수한 폭포수 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 한다. 폭포수 모델은 제품의 스펙이 거의 바뀌지 않거나 안정성이 아주 중요한 프로젝트에 적용될 수 있다. 

◎ 반복 모델 : 반복 모델은 소프트웨어 프로젝트를 원활하게 진행하기 위해 여러 번에 걸쳐 개발 공정을 반복하여 수행한다. 한 번에 모든 공정을 완벽하게 하는 것이 아니라 반복적이고 점진적으로 진행하기 때문에, 요구사항이 점점 명확해지고 개발팀이 기술 및 요구사항에 익숙해져서 우수한 소프트웨어를 개발하는데 도움이 된다. 

◎ 사시미 모델 : 사시미 모델은 폭포수 모델의 변형된 형태로 각 단계의 상당 부분을 중첩하여 진행하는 모델이다. 

◎ 발전적 프로토타이핑 모델 : 발전적 프로토타이핑 모델은 프로젝트를 진행하면서 점점 제품의 개념을 잡아가는 모델이다.

◎ SRS를 흔히 요구사항 명세서, 기능 명세서라고 부르기도 하는데, 사실상 SRS를 대신해서 사용하기에는 불충분하다. SRS는 흔히 생각하는 기능 명세보다 훨씬 많은 다양한 정보를 체계적으로 담고 있다. 따라서 SRS라는 용어 그대로 사용하는 게 좋다. 잘못 번역해서 사용하면 기존에 회사에서 사용하고 있던 비슷한 문서들에 대한 선입관으로 인해서 의사소통에 왜곡이 생긴다. 

◎ 소프트웨어의 생애주기란 소프트웨어 탄생에서 소멸까지의 모든 활동을 말한다. 대부분의 사람들이 생애주기에 대한 고민 없이 소프트웨어 개발을 진행하고 있다. 그러나 각각의 소프트웨어 프로젝트에 맞는 적합한 생애주기를 선택해야만 소프트웨어 프로젝트를 보다 효율적으로 진행할 수 있다. 

◎ 폭포수 모델은 모든 생애주기 모델의 근본이다. 순수한 폭포수 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 한다. 폭포를 거슬러 올라가는 것은 원칙적으로 불가능하다. 폭포수 모델은 제품의 스펙이 거의 바뀌지 않거나 안정성이 아주 중요한 프로젝트에 적용될 수 있다. 

◎ 폭포수 모델에서는 소프트웨어 개발의 전 공정을 한번에 완벽하게 처리하지 않을 경우 문제가 생긴다. 막상 제품을 완성하고 테스트를 하는 시점에 분석, 설계, 구현 단계의 문제가 한꺼번에 나타나서, 이전의 오류를 수정하기 전까지 진행이 어렵게 된다. 

반복 모델은 소프트웨어 프로젝트를 원활하게 진행하기 위해 여러 번에 걸쳐 개발 공정을 반복하여 수행한다. 한 번에 모든 공정을 완벽하게 하는 것이 아니라 각 공정을 반복적이고 점진적으로 진행하기 때문에, 요구사항이 점점 명확해지고 개발팀이 기술 및 요구사항에 익숙해져서 우수한 소프트웨어를 개발하는데 도움이 된다. 반복 모델은 작은 폭포수 모델을 반복하는 것과 유사하다. 각 반복 주기마다 시연 가능한 제품을 릴리즈하는 과정을 반복하면서 제품이 점진적으로 향상된다. 

◎ 폭포수 모델과 같은 기존의 거대 방법론에서는 무엇을 개발해야 하는가를 발견하는 과정이 바로 요구분석단계이다. 그런 모델에서는 요구분석한 결과를 가지고 테스트 케이스를 만드는 것이 정상적인 프로세스인데 익스트림 프로그래밍 모델에서는 그 반대로 테스트 케이스가 바로 요구사항을 반영한다. 즉, 요구분석의 결과가 바로 테스트를 깨뜨리지 않는다는 원칙하에 개발이 진행된다. 이것이 바로 테스트 우선 개발이다. 

◎ 어떤 개발방법론을 채택하느냐에 상관없이 모든 개발은 명시적이든 아니든 여러 단계를 거쳐서 진행된다. 하지만 많은 소프트웨어 회사들이 프로젝트 단계 없이 진행한다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한 번의 테스트를 통해 제품을 완성하려고 한다. 이를 빅뱅 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지고 모른다는 기대감으로 일을 중구난방으로 진행하는 것이다. 하지만 이는 전혀 근거가 없는 생각이며,  테스트를 한 번에 끝낸다고 프로젝트가 더 빨리 끝나지는 않는다. 이 방법은 테스트 기간 내내 불끄기모드로 혼란에 휩싸이게 만들고, 테스트가 언제 끝날지 도저히 예측할 수 없으며, 일정 기간 내에 품질이 얼마나 향상될 수 있을지 추측조차 하기 어렵다. 

◎ 프로젝트의 각 단계에 따라서 투입되는 인력이 달라진다. 흔히 저지르는 실수 중 하나가 프로젝트가 시작되자마자 모든 프로젝트 인력을 한꺼번에 투입해 놓고 프로젝트가 끝날 때까지 그 인원으로 계속 진행하는 경우이다. 각 단계별로 필요한 인력과 인원 수가 달라지는데 프로젝트 추기부터 많은 인원이 투입되면, 별로 할 일이 없게 된다, 그렇게 되면 요구분석이 완료되지도 않은 시점에 특별한 계획도 없이 이것저것 코딩도 해보고 설계도 해보고 계획없이 여기저기 손대기 시작한다. 가장 비효율적인 경우가 처음부터 끝까지 같은 사람이 요구분석도 하고 설계도 하고 구현도 하고 심지어는 테스트까지 하는 경우다. 이는 전문성 없이 컴포넌트 주인 구조로 움직이는 아마추어적인 회사다. 

◎ 많은 소프트웨어 프로젝트들이 요구분석이나 테스트 기간을 너무 짧게 잡고, 구현 기간에 많은 시간을 할애하곤 한다. 이렇게 되면 요구분석이 불완전한 상태에서 설계, 구현을 하기 때문에, 결국 구현 도중에 요구사항과 설계가 개발자 임의대로 계속 정해진게 된다. 요구분석에 미리 충분한 시간을 할애해야 설계, 구현 기간에 혼동이 적어지고, 프로젝트가 효과적으로 진행된다. 

 

02. 다음 중 '일단 짜보고 고치기'에 대한 설명 중 옳지 않은 것은 무엇인가?

 1)    이 방법은 개발자들이 잘 쓰지 않는다.

   빠른 시간안에 가시적인 결과물이 나온다.

   이 방법으로 개발된 소프트웨어는 많은 위험이 잠재되어 있다.

   일정을 산정하기 어렵다.

 

 

 

---

 

 

 

 

03. 다음이 설명하는 것은 무엇인가?

 (         )이란 출시를 하기 위한 제조 준비가 완료되었다는 의미이다. 개발팀은 제품을 만들었으니, CD로 굽든 홈페이지에 올리든 해서 배포하면 되는 것이다. 개발팀의 역할은 (        )까지 이고 그 이후 절차는 마케팅이나 릴리즈팀과 같은 다른 부서의 역할이다.

   구현

   요구분석

3)    RTM

   GA