본문 바로가기

정보처리기사

소프트웨어 생명 주기

소프트웨어 생명 주기

 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것이다. 대표적인 소프트웨어 생명 주기 모형에는 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형 등이 있다.

 

1. 폭포수 모형(Waterfall Model)

 폭포수 모형은 이름 그대로 폭포에서 한번 떨어진 물은 거슬러 올라갈 수 없듯이 SW 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 다음 단계로 나아가는 모형이다.(실제로 피드백 통해 이전 단계를 수정하긴 하지만 프로세스 자체가 유연함이 부족하여 되돌리기 늦는 경우가 많다.)

가장 오래되고 폭넓게 사용된 고전적 생명 주기 모형이다. 두 개 이상의 과정이 병행하여 수행되지 않는다.

프로세스의 각 단계는 아래와 같다.

 

출처 : http://uncaose.tistory.com/549

 

2. 프로토타입 모형(Prototype Model, 원형 모형)

 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다. 견본품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다. 견본품 제작은 시스템의 일부 혹은 전체 모형을 만드는 과정으로서 요구된 SW를 구현하는데 이는 추후 구현 단계에서 사용될 골격 코드가 된다. 소프트웨어 개발이 완료된 시점에서 오류가 발견되는 폭포수 모형의 단점을 보완하기 위한 모형이다. 

 

출처 : https://yimma.tistory.com/?page=19

 단, 프로토타입과는 갭이 있는 결과물이 나올 수도 있으며 단기간으로 개발해야 하기 때문에 코드의 효율성이나 간결성등이 떨어질 수 있다는 단점이 있다.

 

3. 나선형 모형

 폭포수 모형과 프로토타입 모형의 장점에 '위험 분석 기능'을 추가한 모형이다. 나선을 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것으로, 점진적 모형이라고도 한다. SW 개발 도중 발생할 수 있는 위험을 관리하고 최소화하는 것이 포인트다.

점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 유지보수 과정이 필요 없다. 또한 대규모 시스템의 소프트웨어 개발에 적절하다.

폭포수 모형과 프로토타입 모형에 비해 최신의 모델이다.

출처 : https://yimma.tistory.com/98?category=227748

 

4. 애자일 모형(Agile Model)

 '민첩한', '기민한'이라는 의미로, 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다. 특정 개발 방법론이 정해진 것은 아니고 고객과의 소통에 초점을 맞춘 방법론을 통칭한다. 대표적인 예로는 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM, DAD 등이 있다.

 

 아래는 대표적인 애자일 방식인 스크럼 방식의 개발 프로세스이다.

 

출처: https://post.naver.com/viewer/postView.nhn?volumeNo=16807486&memberNo=25828090

 실제 면접에서도 여러 번 질문을 받았을만큼 아직도 많은 기업들이 관심을 갖고 도입하는 분위기인거 같다. 가볍고 개인의 역량을 최대화 시키기 위한 모델로서 효율성에 온전히 초점을 맞춘 느낌이다. 주로 고전적 생명 주기 모형의 대표주자 폭포수 모델과 많이 비교 된다.

 

구분 폭포수 모형 애자일
새로운 요구사항 반영 어려움 지속적으로 반영
고객과의 의사소통 적음 지속적임
테스트 마지막에 모든 기능을 테스트 반복되는 일정 주기가 끝날 때마다 테스트
개발 중심 계획, 문서(메뉴얼) 고객

 

4-1. 스크럼(Scrum) 기법

 스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말한다. 스크럼은 이처럼 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어이다.

 

 - 스크럼 구성원

   스크럼의 구성원은 크게 제품 책임자, 스크럼 마스터, 개발팀 세 가지이다.

 

   # 제품 책임자   : 이해관계자들 중 개발될 제품에 대한 이해도가 가장 높은 사람으로 선정한다. 이해관계자들의 의견                           을 종합하여 제품에 대한 요구사항을 작성하는 주체이다. 백로그를 작성하고 주기적으로 요구사항의

                         우선순위를 갱신한다.

                        *백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록.

 

   # 스크럼 마스터 : 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 한다.

                          통제를 한다는건 아니다. 일일 스크럼 회의를 주관하고 진행 사항을 점검, 개발 도중 발생한 장애 

                          요소를 공론화 시킨다.

 

   # 개발팀           : 제품 책임자, 스크럼 마스터를 제외한 나머지 모든 팀원들. 개발자 외에도 디자이너, 테스터 등의

                           제품 개발에 참여하는 모든 사람이 대상이다. 보통 최대 인원은 7~8명이 적당하다.

 

 

 - 스크럼 개발 프로세스 

출처: Jeff sutherland, The Scrum papers: Nut, Bolts, and Origins of an Agile Framework

   # 제품 백로그 : 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록이다. 개발 과정에서 새롭게

                       도출되는 요구사항으로 인해 지속적으로 업데이트 된다.

 

   # 스프린트 계획 회의 : 단일 스프린트에서 수행할 작업을 대상으로단기 일정을 수립하는 것이다. 요구사항을

                       태스크(Task) 단위로 분할한 후 개발자들에게 할당하고 개발자별로 수행할 작업 목록인 스프린트

                       백로그를 작성한다. 

 

   # 스프린트 : 실제 개발 작업을 진행하는 과정. 보통 2 ~ 4주 정도의 기간 내에서 진행한다. 스프린트 백로그에 작성된

                       태스크를 대상으로 작업 시간을 추정한 후 개발 담당자에게 할당한다. 개발 담당자는 태스크를 할 일, 

                       진행 중, 완료의 상태로 구분한다.

 

   # 일일 스크럼 회의 : 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검한다.(생각보다

                        5분 이라는 시간을 맞추는 것을 중요시 한다!) 회의는 보통 서서(...) 진행하며, 남은 작업 시간을

                        소멸 차트(Burn-down Chart)에 표시한다. 스크럼 마스터는 장애 요소를 해결하도록 돕는다.

   

   # 스프린트 검토 회의 : 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 고객을 포함한 참석자 앞에서 테스팅

                        을 수행한다. 스프린트의 한 주당 한 시간 내에서 진행한다. 피드백을 반영하여 백로그를 수정한다.

 

   # 스프린트 회고 : 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지 피드백을 진행한다.

 

 

4-2. XP(eXtreme Programming) 기법

 XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법이다. 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 SW를 빠르게 개발하는 것을 목적으로 한다. 그 유명한 TDD가 XP의 주요 실천 방법 중 하나이다.

 

 - XP의 5가지 핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백

                                 (Feedback)

 

용기
(Courage)
고객의 요구사항 변화에 능동적인 대처
단순성
(Simplicity)
부가적 기능, 사용되지 않는 구조와 알고리즘 배제
커뮤니케이션
(Communication)
개발자, 관리자, 고객 간의 원활한 의사소통
피드백
(Feedback)
지속적인 테스트와 반복적 결함 수정, 빠른 피드백
존중
(Respect)
모든 프로젝트 관리자는 팀원의 기여를 존중

 

 - 개발 프로세스

출처 : http://blog.skby.net/xp-extreme-programming/

   # 사용자 스토리(User Story) : 고객의 요구사항을 간단한 시나리오로 표현한 것. 내용은 기능 단위로 구성하며,

                         필요한 경우 간단한 테스트 사항도 기재한다.

 

   # 릴리즈 계획 수립 : 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것. 부분 혹은 전체 개발

                         완료 시점에 대한 일정을 수립한다. 

 

   # 스파이크(Spike) : 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한

                         프로그램이다. 처리할 문제 외의 다른 조건은 모두 무시한다.

 

   # 이터레이션 : 하나의 릴리즈를 더 세분화 한 단위. 일반적으로 1~3주 정도의 기간으로 진행된다.

 

   # 승인 검사 : 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분 완료 제품이 구현되면 수행하는 테스트. 테스트

                         도중 발생한 오류사항들은 다음 이터레이션에 포함한다. 테스트 완료 후 다음 이터레이션을 진행.

 

   # 소규모 릴리즈 : 릴리즈를 소규모로 진행하여 고객의 반응을 기능 별로 확인한다. 계획된 릴리즈 기간 동안

                         이터레이션이 모두 완료되면 고객에게 최종 테스트를 수행한 후 최종 결과물을 고객에게 전달한다. 

'정보처리기사' 카테고리의 다른 글

요구사항 정의  (0) 2020.07.31