소프트웨어 생명주기 모델

소프트웨어 생명주기 모델

• 주먹구구식 개발 모델(빅뱅 모델)
• 폭포수(Waterfall) 모델
• 프로토타입(Prototype) 모델
• 나선형 모델
• UP, Unified Process
• XP (Agile)

 

2. 폭포수(Waterfall) 모델

• 개발 프로젝트의 기본적인 모델이자 가장 많이 사용되고 있는 모델
• 각 단계는 '요구사항 분석 - 설계 - 구현 - 테스팅 - 유지보수' 다.
• 각 단계마다 요구하는 활동, 조건, 산출물이 모두 만들어져야지만 다음 단계로 넘어갈 수 있다.
• 폭포수가 밑에서 위로 흐르지 않는 거처럼, 이 모델도 다시 이전 단계로 되돌아가는 것은 매우 어렵다.
• 장점
  • 각 단계별로 정형화된 접근
  • 체계화된 문서화
  • 프로젝트 진행의 명확성 (전체 공조의 이해가 용이)
• 단점
  • 앞 단계 일정이 지연될 시, 다음 단계도 모두 대기상태 (병행이 불가능)
  • 고객과 사용자는 실제 동작되는 시스템을 개발 후반부에 가야 볼 수 있음, 내 요구사항이 제대로 구현되었는지확인하는 과정이 늦음
  • 요구사항 확인에 많은 시간이 소요되어 고객의 불만이 높아질 수 있음
  • 개발 중에 발생하는 새로운 요구사항을 반영하기가 매우 어려움
  • 오류 및 누락사항없이 다음 단계로 진행해야 하는데 현실적으로 매우 어려움

 

3. 프로토타입 모델

• 실제 개발 전, 모형을 만들어 사용자의 요구사항과 일치하는지에 대한 검증 후 다음 과정을 진행함
• 예를 들어, 아파트의 모델하우스라 생각하면 이해하기 쉽다. 구조 및 인테리어를 확인하는 단계가 포함되어 있음
• 단계는 '요구사항 정의 - 프로토타입 설계 및 개발 - 고객 피드백 - 요구사항 수정 및 반복 - 고객 만족 시, 실제 개발 진행
• 프로토타입을 폐기시킨 후 처음부터 다시 개발하는 경우도 있고 만들어 놓은 프로토타입을 그대로 발전시켜 제품으로 만드는 경우도 있다.
• 개발 초기에 고객의 요구사항이 명확하지 않을 때, 고객의 요구사항을 완전하게 파악하기 위한 목적으로 사용된다.
• 장점
  • 사용자의 요구사항에 대해 원활한 의사소통이 가능하다.
  • 폭포수는 처음부터 모든 요구사항이 완벽해야 한다면, 프로토타입은 조금 느슨해도 수정 과정을 거치며 점진적으로 요구사항을 완성해 나갈 수도 있음
• 단점
  • 프로토타입은 어차피 껍데기 일 뿐이다. 제대로 된 성능평가, 품질평가가 이루어지기 어렵다.
  • 고객은 프로토타입이 SW의 완성이라 착각할 수 있다. 거의 다 완성되었다고 생각했는데 이제부터 새로 다시 만들기 시작한다? 오해가 생길 수 있음

 

폭포수와 프로토타입은 기본적으로 순차적 모델이다. 순차가 아닌 점증적으로 시스템이 개발되는 모델로는 나선형, UP, XP가 있다.

 

4. 점진적 모델

물론, 초기에 요구사항이 모두 파악되면 좋을 것이다. 그렇지만, 실제로는 이것이 매우 힘들다. 시스템의 체계를 이해하지 못하는 사용자의 요구사항은 명확하지 않을 수 있다. 따라서, 현실적인 문제를 해결하기 위해서 취하는 모델이다.

 

1. 나선형 모델

• 단계는 '계획 및 정의 - 위험분석 - 개발 - 고객평가' 로 크게 나누어진다.
  • 계획 및 정의: 어떤 소프트웨어를 개발할 것인가, 성능 및 품질의 목표는 어디인가 등을 계획하고 정의한다.
  • 위험 분석: 인력, 자원 등으로부터 생길 위험이 무엇인지? 회피할 수 있는 방안을 마련한다.
  • 개발 : 바로 개발하는 것이 아닌, 프로토타입을 만들고 피드백을 받으며 점진적으로 요구사항을 확정해 나간다.
• 해당 단계가 1회만으로 끝나는 것이 아닌, 나선형으로 돌면서 진화되는 모습을 띄고있다.
• Boehm이 제안한 것으로 폭포수와 프로토타입 모델의 장점을 수용하고 이에 더해 위험분석을 더한 모델이다.
•  처음하는 프로젝트 또는 규모가 굉장히 크고 복잡한 프로젝트에 적합하다.
• 다른 일반적 모델과는 달리, 위험 분석을 매우 강조하는 모델이다.
• 가장 현실적인 모델이지만 비교적 최신 기법이라 널리 사용되지는 않는다.
• 장점
  • 프로젝트 모든단계에서 기술적인 위험을 직접 고려할 수 있어서, 사전에 위험을 최소화 및 제어할 수 있다.
  • 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 반영할 수 있고 정밀하며 유지보수가 필요하지 않다.
• 단점
  • 위험분석을 할 수 있는 지식 및 전문자가 없다면 나선형 모델을 적용하기 매우 어려울 수 있다.
  • 모든 단계가 점진적으로 진화되기 때문에, 각 단계가 명확하게 구분되어 있지 않다. 이로 인해 프로젝트 관리가 상대적으로 어려울 수 있다.
  • 위험성 평가에 크게 의존하기에 발견하지 못하면 문제가 발생한다.

 

2. Agile 모델

• 문서나 관리보다는 코드개발에 더욱 가치를 둔다.
• 전체적인 개발 프로세스 및 일정 계획에는 무리가 있을 수 있다.
• 소규모 프로젝트를 지원한다.
• 비즈니스 라이프 사이클을 단축시키는 데에 큰 역할을 할 수 있다.

 

1. XP(eXtreme Process)

• 사용자의 요구사항이 수시로 변경하는 데에서 부터 비롯되는 위기 및 비용을 일정하게 유지하기 위한 것으로 나온 모델이다.
• 사용자, 관리자, 개발자에 대한 역할 및 권한에 대해 아래와 같은 4가지 가치를 중시한다.
  • 의사소통 : 고객과 개발자들 간의 의사소통을 적극적으로 하라
  • 단순성 : 처음부터 너무 큰 그림 그리지 말자. 눈 앞에 닥친 소규모 기능에 집중하고 큰 문제는 추후에 고민하라
  • 피드백 : 고객-사용자, 개발자-개발자 간의 피드백을 두려워 말라
  • 용기 : 고객이 요구하는 것은 그때 그때 적시에 반영하라.
• 기존에 나온 소프트웨어 이념과는 조금 다르게 느껴진다. 기존 이념은 '초기에 요구사항을 모두 도출하고 수정은 적게 하라' 라면, 애자일에선 '어떤 요구사항이든 고객이 원하면 용기있게 수용하라'다. 

 

2. 스크럼(Scrum)

• 럭비 경기에서 팀이라는 단어가 주는 의미를 개발팀에도 적용하여 효울적인 성과를 얻기 위해서 따왔다.
• 회의를 통해 '스프린트'라는 개발 주기를 정한 뒤, 이 개발 주기마다 회의때 정했던 계획들을 구현한다. 하나의 스프린트가 끝날 때마다 스프린트 검토 회의를 통해 생산된 프로토타입에 대한 피드백을 받으며 더 나은 결과물을 구현해낼 수 있다.
• 단계는 '기능 목록 작성 - 스프린트 백로그 - 스프린트 - 일일 회의 - 제품완성 및 스프린트 검토 - 스프린트 회고'
  • 기능 목록 작성: 고객과 지속적으로 소통하면서 요구사항 목록 작성하고 우선순위 선정, 한번 결정하였다 하여 확정되는 것이 아니라 개발 중 수정이 가능하지만, 일반적으로 한 주기가 끝날 때까지 기능 목록을 수정하지는 않는다.
  • 스프린트 백로그: 각 스프린트에 도달하기 위해 개발해야 할 작업 목록을 작성한다. 이를 통해 개발의 진척상황을 파악할 수 있으며 이 목록 하나하나가 개발 완료되면 스프린트 주기가 완성되는 것이다.
    • 구현해야 할 세부적인 내용
    • 작업자
    • 예상 작업 시간
  • 스프린트: 작은단위의 개발업무를 단기간 내에 전력질주하여 개발한다는 뜻이다. 예를 들어, 한달동안 풀 30개의 문제를 5일에 5개씩 푸는 것으로 계획했으면, '5일'이란 주기가 반복되며 문제를 풀어나가는 것이다. 이 주기를 스프린트라 칭한다.
    • 이 기간은 계획회의를 통해 결정하는데, 보통 2-4주 정도로 짧게 수행된다.
    • 주기가 결정되면 개발 팀은 팀원 역량에 맞게 스프린트에 배정된 작업을 중간에 멈추는 일 없이 전력질주 해서 끝내야 한다. 그러려면 결정된 스프린트의 목표와 내용이 개발 도중에 바뀌지 않아야 하고 그 누구도 팀원의 동의없이는 바꿀 수 없다는 원칙을 지켜야 한다.
  • 일일 스크럼 회의: 이 회의는 스프린트 기간에 하는 회의로, 여러 특징을 가지고 있는데 아래와 같다.
    • 매일, 서서, 약속된 시간에, 짧게(15분), 진행상황만 점검한다.
    • 모든 팀원이 참석하며 한 사람씩 어제 한일과 오늘 할 일, 그리고 문제점을 이야기한다.
    • 완료된 세부 작업항목을 완료상태로 옮겨 스프린트 현황판을 업데이트 한다.
    • 개별 팀원에 대한 진척상태를 확인하고, 그 날 남은 작업량을 소멸차트에 표시한다.
  • 제품완성 및 스프린트 검토
    • 모든 스프린트 주기가 끝나면 제품이 완성된다.
    • 최종 제품이 완성되면, 스프린트 검토회의라는 것을 한다.
    • 이는 최종제품이 처음 계획한(고객이 요구한) 사항과 얼마나 일치하는지 고객 포함 참석자들 앞에서 시연한다.
    • 그리고 개선할 점 등에 대해 피드백을 받는다.
  • 스프린트 회고
    • 그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아보고 개선점을 찾아나간다.
    • 팀이 정한 규칙이나 표준을 잘 준수했는지를 검토한다.
    • 단점을 찾기보다는 강점을 찾아 극대화하는 데에 주안점을 둔다.
    • 문제에 대한 해결방안을 찾는 회의가 아니기 때문에 문제를 확인하고 기록하는 정도로만 진행한다.
    • 추정 속도와 실제 속도를 비교하고 차이가 크면 이유를 분석한다.
    • 프로세스 품질은 측정하지 않는다.
• 장점
  • 스프린트 마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있다.
  • 일일회의를 함으로써 팀원 간 신속한 협조와 조율이 가능하다.
  • 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다.
  • 다른 개발 방법론에 비해 단순하고 실천 지향적이다.
  • 스크럼 마스터(팀원들에게 업무를 배분해주는 사람)는 개별 팀원이 목표 달성에 집중할 수 있도록 팀의 문제를 해결한다.
  • 프로젝트 진행현황을 볼 수 있어 신속하게 목표와 결과 추정이 가능하며 목표에 맞게 변화를 시도할 수 있다.
• 단점
  • 스프린트가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 한다. 추가적인 시간이 필요하다.
  • 일일 회의를 15분 안에 마쳐야 한다. 
  • 투입 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어려움
  • 회고에서 품질을 평가하지 않기 때문에 프로세스 품질 평가 불가하다.

 

 

폭포수, 프로토타입, 나선형, 애자일 등의 모델을 살펴보았지만 사실 무엇하나 정답이라고 꼽을 수는 없다.

각 회사의 특징에 맞게 환경요소를 고려하여 모델 중 가장 적합한 하나를 선택해내는 것이 중요한 능력이며 해당 모델을 100% 수용하는 것보단 조금씩 사정에 맞게 커스터마이징 하여 맞춰나가는 과정도 필요하다.