> [!abstract] Introduction > 이번 글에서는 소프트웨어의 생명 주기*Life Cycle*에 대해 알아봅니다. # Life Cycle 소프트웨어의 생명 주기는 소프트웨어 제품을 개발하고, 운영하고, 유지보수하고, 최종적으로 폐기하는 전체 과정에서 수행되는 활동들의 순서를 기술한 것이다. 즉, 소프트웨어 제품의 개발부터 운영과 유지 및 보수, 그리고 폐기까지의 모든 과정을 통틀어 소프트웨어의 생명 주기라 부르는 셈이다. > [!info] Definition > software system or software product cycle initiated by a user need or a perceived customer need and terminated by discontinued use of the product or when the software is no longer available for use 소프트웨어의 생명 주기는 SDLC*Software Development Life Cycle*이라고도 부르는데, 운영과 유지보수의 중요성이 부각되지 않았던 시절에는 두가지 이름을 혼용하기도 했다. # Software Life Cycle Models 실제 소프트웨어 개발에서 사용된 생명 주기 모델에는 여러가지가 있다. 각 모델의 등장과 쇠퇴는 소프트웨어의 발전사와 맞물려 있고, 이에 따라 제품을 개발하는 과정도 계속 변해왔다. 시대순으로 소프트웨어 생명 주기 모델의 등장과 쇠퇴를 살펴보자. ## Code-and-fix model ![[CodeAndFix.png]] 소프트웨어 개발은 원래 매우 단순하게 이루어졌다. 개발 이전에 특별히 계획을 세운 것도 아니고, 디자인을 만든 것도 아니고, 요구사항이나 그런 것을 만들지도 않았다. 일단 뭔가 만든 다음 계속 수정하면서 제품을 완성했다. 후술할 모델들과 비교하면 진행 상황을 쉽고 빠르게 눈으로 확인할 수 있고 작은 규모의 프로젝트에 적합하지만, 그만큼 유지보수에 드는 비용이 높고 규모를 키울 수가 없다. ## Waterfall Model 그러다 1970년에 폭포 모델*Waterfall Model*이 등장했다. 이 모델은 큰 규모의 프로젝트를 다루기 위해 고안된 단계별 접근법으로, 요구사항*Requirements* -> 분석*Analysis* -> 디자인*Design* -> 구현*Coding/Implementation* -> 테스트*Testing* -> 운영*Operation/Deployment* -> 유지보수*Maintenance* 순서로 소프트웨어 제품을 개발하는 방식이다. ![[WaterfallModel.png]] 이 단계에서 가장 중요한 것 두가지는 구현보다 설계를 먼저 하는 것, 그리고 문서를 작성하고 단계를 지키는 것이다. 이 모델은 특성상 앞선 단계가 완벽하게 끝나야 다음 단계를 진행할 수 있기 때문에 중간중간 제대로 했는지, 제대로 끝냈는지 확인할 방법이 필요하다. 그래서 각 단계를 제대로 수행했다는 것을 문서로서 보여줘야 했고, 문서화와 절차가 강조되었다. 이 모델은 간단한 구조를 지니고 있어 이해하기 쉽고 각 단계마다 결과물이 명확하다. 경영 측면에서 관리하기도 편하고, 요구사항이 명확하고 위험이 낮은 소규모 프로젝트에 적합하다. 그러나 이 모델이 제대로 작동하기 위해서는 변경되지 않는 요구사항을 도출해야 하는데, 고객이 모든 요구사항을 명시적으로 미리 진술하기 어렵다.[^1] 작동하는 시스템이 생명 주기의 후반부에야 나와서, 소프트웨어 요구사항이 생명주기 후반부에 테스트된다. 만약 여기서 문제가 생긴다면? 이전 단계로 다시 거슬러 올라가야 한다. ## Prototyping Model 프로토타입 모델은 바로 그 문제를 해결하기 위해 등장했다. ![[PrototypingModel.png]] 고객은 기술적으로 이야기해주지 않는다. 보통 기술적으로 무엇이 가능하고 무엇이 불가능한지를 알지 못하고 무엇을 원하는지를 잘 모른다. 그래서 프로토타입 모델에서는 이게 맞는지 저게 맞는지 시제품을 미리 만들어보고 이를 통해 고객이 무엇을 원하는지 파악한다. 이렇게 만들어진 시제품을 Throw-away prototype이라 부르며, 점차 진화해가는 Evolutionary prototype과는 다른 종류다. 이렇게 시제품을 미리 던져보면 요구사항을 잘못 파악할 가능성도 줄어들고 정기적으로 가시적인 진척을 보여줄 수 있어 관리에도 도움이 되며, 조기에 제품을 홍보할 수도 있다. 하지만 불안정하거나 잘못 구현된 프로토타입이 종종 최종 제품이 되어버리기도 하고 광범위한 고객 협력이 필요하다. 또한 프로젝트가 얼마나 오래 지속될지 알 수 없고, 적절한 요구사항 분석, 설계, 고객 평가와 피드백이 없다면 쉽게 code-and-fix 모델로 퇴보할 수 있다. ## Incremental Model 프로토타입 모델에서 시스템이 생명 주기 후반부에 나온다는 단점을 보완하기 위해 점진적 모델*Incremental Model*이 등장했다. 이 모델은 폭포 모델과 기본적으로 같은 과정을 공유하지만, 몇가지 다른 점이 존재한다. ![[IncrementalModel.png]] 제품의 릴리즈는 한번에 이루어지지 않고, 여러 번의 증분*Increment*으로 이루어진다. 첫번째 릴리즈는 주로 기본적인 요구사항이 반영된 핵심 제품이고, 여기서 요구사항을 추가로 반영해가며 새로운 릴리즈를 계속 만든다. 각 릴리즈가 지켜야 할 요건 중 하나는 작동하는 제품을 전달하는 것이다. 각 릴리즈는 폭포 모델과 똑같이 요구사항, 디자인, 구현, 테스팅, 배포, 유지보수의 과정을 거치고, 시간에 따라 릴리즈의 기능과 특징이 점진적으로 증가한다. 그래서 점진적 모델은 사용자로부터 미리 피드백을 받을 수 있고 따라서 고객의 요구를 더 잘 충족시킬 수 있다. 또한 마감일까지 완전한 구현을 위한 인력이 없어도 제품을 개발할 수 있고, 증분을 통해 기술적 위험을 관리할 수도 있다. 하지만 문제는 어떤 요구사항이 추가될지 모른다는 것이다. 모든 릴리즈에 필요한 공통 기능을 찾기 어려울 수 있고, 새로운 릴리즈를 개발하는 동안 기존 릴리즈에 대한 유지보수가 필요하기 때문에, 유지보수에 투입되는 비용으로 인해 부하가 점점 추가되며 갈수록 마감 날짜에 쫓기게 된다. 그리고 기존의 릴리즈에 반영된 모든 수정과 업데이터가 현재 개발중인 버전과 통합돼야 하고, 특히 고정 비용 계약의 경우 시스템 개발 계약에 완전한 시스템 명세가 포함된 많은 조직의 조달 모델*Procurement Model*과 충돌할 수 있다. ## Evolutionary Model 점진적 모델을 통해 핵심적인 제품의 요구사항은 잘 파악해도 디테일이나 추가 기능이 정의되지 않는 문제가 있다. 그리고 폭포 모델이나 폭포 모델에 기반한 점진적 모델로는 시시각각 변하는 요구사항을 수용하기가 어렵다. 그래서 이 문제를 해결하기 위해 진화적 모델*Evolutionary Model*이 탄생했다. ### Evolutionary Prototyping Model 진화적 모델에 속하는 첫번째 유형은 진화적 프로토타입 모델*Evolutionary Prototyping Model*이다. 사용자는 각 사이클의 최종 단계에서 제품을 써보고 피드백을 제공할 수 있고 이 피드백은 다음 버전을 개발할 때 반영된다. ![[EvolutionaryPrototypingModel.png]] 시간이 흐르면서 고객은 제품이 자신의 요구사항을 점점 더 충족해가는 것을 확인할 수 있고, 개발자 입장에서는 시시각각 변하는 요구사항에 대응할 수 있다. 모든 작업은 쪼개져 있으며, 덕분에 요구사항을 중간에 바꿔도 기술적인 부담이 덜하다. 점차 더 나은 제품을 만든다는 것은 점진적 모델과 동일하나, 이 모델에서 다음 릴리즈의 목표는 현 릴리즈의 더 완전한 버전이라는 점이 다르다. ### Spiral Model 진화적 모델에 속하는 두번째 유형은 나선형 모델*Spiral Model*이다. 배리 보엠*Barry Boehm*이 1988에 제안한 위험 주도 프로세스 모델*Risk-driven Process Model*이며, 이는 곧 위험요소의 통제에 집중하며 프로젝트를 개발해간다는 것을 의미한다. ![[SpiralModel.png]] 목표 결정 -> 리스크 식별 및 해소 -> 차기 버전 개발 -> 리뷰 및 다음 버전을 위한 계획의 순환 구조를 이어가며 제품이 완성될 때까지 프로젝트의 규모를 점점 키워간다. 이 모델의 가장 큰 장점은 폭포 모델의 품질 보장과 프로토타입 모델의 유연함을 동시에 가지고 있다는 것이다. 요구사항이 불분명한 프로젝트를 개발할 때 일어나는 일들을 그대로 반영하고 있어 개발을 하는 입장에서도 잘 맞는다. 다만 리스크 분석 과정에서 기술 전문가의 참여가 반드시 필요하며, 복잡한 모델이라 모델에 대한 이해도가 대부분 낮으며, 따라서 유능한 전문 관리가 필요하고 그에 따른 경영 측면에서의 부담 또한 높은 편이다. ## Unified Software Development Process 통합 소프트웨어 개발 프로세스*Unified Software Developement Process*는 통합 프로세스*Unified Process*(이하 UP)라고도 불린다. UP는 단순한 프로세스가 아니라 조직과 프로젝트의 상황에 맞는 최적화가 필요한 프레임워크다. 프로세스 자체는 기본적으로 반복적이고 점진적인 개발 프로세스에 속하고, 프로젝트의 과정은 여러 페이즈로 구분된다. 전체 개발 사이클은 Inception -> Elaboration -> Construction -> Transition -> Production의 순서로 이어진다. ### Phases ![[ScheduleOrientedTermsInUP.png]] 여기서 페이즈 별로 여러 작업이 조금씩 겹칠 수 있다. Inception 페이즈에서는 대략적인 계획을 세운다. Elaboration 페이즈에서는 이전에 세웠던 계획을 구체적으로 만든다. 그 과정에서 핵심 아키텍쳐를 반복적으로 구현하고, 리스크를 구체적으로 파악하고, 대부분의 요구사항과 개발 범위를 파악한다. Construction 페이즈에서는 리스크가 낮고 개발하기 쉬운 나머지 컴포넌를 구현하고 배포할 준비를 한다. 마지막으로 Transition 페이즈에서는 베타 테스트를 하며 배포 직전 최종 점검을 한다. 그러고 나면 프로덕션 환경에서 사용하기 위한 최종 배포가 이루어진다. ### Disciplines ![[UPDisciplines.png]] UP에서 유스케이스 작성과 같은 업무 활동은 discipline이라는 활동의 모음으로 기술한다. 업무는 주제에 따라 분류되며, 이들을 묶어 discipline이라 부르는 것이다. Discipline과 Phase의 관계는 아래와 같다. 페이즈마다 하는 일이 조금씩 겹칠 수 있고, 같은 주제로 묶이는 일이라 해도 여러 페이즈에 걸쳐 수행될 수도 있다는 것을 확인할 수 있다. ![[DisciplinesAndPhases.png]] ## V Model 한편, 폭포 모델을 조금 다른 방식으로 보완한 모델도 있으니 바로 V 모델이다. V 모델은 폭포 모델의 변종으로, 소프트웨어 요구사항이 생명주기 후반부에 테스트된다는 문제를 해결하기 위해 기존의 폭포 모델에서 제품의 품질을 보증하기 위한 여러 활동을 과정의 중간에 끼워넣었다. ![[VModel.jpeg]] 위 다이어그램은 V 모델 전체를 표현하고 있는데, 왼쪽에는 문제 요구사항을 정제하는 과정이 있다. 요구사항 분석*Requirements Analysis*, 시스템 설계*System Design*, 아키텍쳐 설계*Architecture Design*, 모듈 설계*Module Design*, 코드 생성*Coding* 순으로 이어진다. 모델의 오른쪽에는 테스트를 수행하는 과정이 있는데, 단위 테스팅*Unit Testing*, 통합 테스팅*Integration Testing*, 시스템 테스팅*System Testing*, 인수 테스팅*Acceptance Testing* 순으로 올라간다. 각 개발 단계는 그에 맞는 폼질 보증 과정과 연결되며 개발 프로세스 중에 계속 테스트가 진행된다. ### V&V V 모델의 또다른 이름이 바로 V&V*Verification & Validation* 모델이다. 여기서 검증*Verification*과 확인*Validation*의 차이는 아래와 같다. > [!tip] Verification vs Validation > Verification: Are we building the product right? > Validation: Are we building the right product? 제품을 요구사항에 맞게 만들었는지를 따지는 것은 검증의 영역이고, 제품이 실제로 고객이 원하는대로 작동하는지를 따지는 것은 확인의 영역이다. --- # 츌처 - https://www.geeksforgeeks.org/software-engineering/software-engineering-prototyping-model/ - https://www.geeksforgeeks.org/software-engineering/software-engineering-evolutionary-model/ - https://www.geeksforgeeks.org/software-engineering/software-processes-in-software-engineering/#software-process-model - https://en.wikipedia.org/wiki/Unified_process - https://www.geeksforgeeks.org/software-engineering/software-engineering-sdlc-v-model/ - Larman, C. (2010) _Applying UML and patterns: an introduction to object oriented analysis and design and iterative development_. 3. ed., 13. print. Upper Saddle River, NJ: Prentice Hall PTR. - McConnell, S. (1996) _Rapid development: taming wild software schedules_. Redmond, Wash: Microsoft Press. [^1]: 단, 계약과 얽힌 문제로 인해 미리 계약을 맺고 솔루션 등을 개발하는 업체는 여전히 이 모델을 애용한다.