소프트웨어 생명주기 (Life Cycle)
소프트웨어는 사람과 같이 생명주기를 가진다. 개발된 소프트웨어는 계속해서 변경되고, 새로운 기능이 추가되어 쓰이며 마침내 소멸에 이른다. 소프트웨어 프로젝트의 생명주기는 “요구분석 → 설계 → 구현 → 테스팅 → 유지보수”의 단계들을 거친다.
TIP!
소프트웨어 프로젝트의 생명주기는 “요구분석 → 설계 → 구현 → 테스팅 → 유지보수”의 단계를 거친다.
프로세스 (Process)
프로세스는 소프트웨어 시스템을 구축하기 위해 수행되는 작업의 단계로, 소프트웨어 개발에 관한 기술적, 관리적 이슈를 다루는 작업을 소프트웨어 프로세스라고 부른다. 프로세스는 여러 컴포넌트 프로세스로 구성된다. 각 컴포넌트 프로세스는 서로 다른 목적을 가지지만 서로 협력하여 전체 소프트웨어 공학의 목적을 만족시킨다.
프로세스 종류
개발 프로세스는 프로젝트에서 가장 중심으로 수행되는 프로세스로, “개발 프로세스”와 “괸리 프로세스”로 분류된다.
- `개발 프로세스`: 수행해야 할 개발 작업과 품질 보증 작업들이 해당된다.
- `관리 프로세스`: 비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업을 말한다.
이 프로세스들을 통해 프로젝트 엔지니어링 프로세스를 이룬다. 소프트웨어 프로세스는 동적인 요소이며, 새로운 기술과 도구를 도입하고 소프트웨어 개발에 대한 이해가 커지면서 수정되어야 한다.
프로세스 정의
프로젝트는 단계 별로 이루어지고, 이때 각 단계는 프로젝트의 목표를 만족시킬 수 있는 작업들로 정의되어야 한다. 프로세스는 비용을 줄이기 위해 그 단게에 유입되는 결함을 찾아내는데 초점을 두어야 한다.
각 단계의 결과를 검증해야 하기에 적당한 양의 단계로 분류해야 한다. 그리고 각 단계가 언제 시작되고 끝나는지, 각 단계의 진입 조건과 출구 조건을 다루어야 한다. 각 작업의 진입 조건은 그 전 단계의 종료 조건과 일관되어야 한다.
프로세스 특성
프로세스를 정의할 때, 그 프로세스가 사용하기 적합한지를 판단하는 기준은 다음과 같다.
- `예측 가능성`: 어떤 프로젝트 안의 프로세스의 결과가 프로젝트를 완성하기 전에 얼마나 정확하게 예측될 수 있다.
- `테스팅 & 유지보수 용이성`: 소프트웨어 개발에서는 테스팅과 유지보수에 가장 많은 노력과 비용이 들어가기에 테스팅과 유지보수에 드는 노력과 비용을 낮추도록 힘써야 한다.
- `변경 용이성`: 소프트웨어 개발에는 변경되는 것들이 많기에 수정하기 용이한 프로세스들로 구축하는 것이 소프트웨어 개발에 유리하다.
- `결함 제거 용이성`: 개발 각 단계에서 발생한 오류는 그 단계에서 수정되어야 하며, 오류 탐색과 수정은 소프트웨어 개발 전체 단계에 지속적인 프로세스가 되어야 한다.
프로세스 모델 (Process Model)
소프트웨어의 개발 프로세스 모델은 개발 단계를 단순화하여 표현한다. 각 모델은 특정 관점에서 나타낸 일반적인 프로세스의 유형이다. 프로세스 모델은 더 구체적인 프로세스를 생성하도록 변경하고 확정할 수 있다.
폭포수 모델 (Waterfall Model)
폭포수 모델은 가장 오래되고 널리 사용된 프로세스 모델로, 계획 단계에서 운영 및 유지보수 단계까지 각 프로세스를 위에서부터 순차적으로 수행하는 방식이다. 각 프로세스 사이에 결과물이 분명히 구분되며, 이전 작업으로 돌아가지 않고 폭포수가 위에서 흘러내리듯 선형적으로 작업이 수행된다.
따라서 폭포수 모델을 사용할 때는, “각 단계가 끝나고 나와야 할 결과물을 명확히 정의해야 한다.” 폭포수 모델의 장단점은 다음과 같다.
- (장점) 단순하고 이해하기 좋으며 각 단계가 명확하여 프로세스의 진행 상황을 관리하기 쉽다.
- (장점) 개발자가 비슷한 소프트웨어를 설계하고 개발하여 응용문제를 알거나 요구 사항이 명확한 대규모 시스템을 장기간 개발할 때 적합하다.
- (단점) 작업이 순차적으로 이루어지기에 이전 단계의 문제가 발견되지 않고 넘어가면 문제가 생긴다.
V 모델 (Verification Model)
V 모델은 폭포수 모델을 확장하여 만든 모델로, 분리된 프로그램들이 완성되면 단위 테스트를 통해 확인하고, 인터페이스에 대한 설계대로 구현되었는지 통합 테스트를 하여 올바로 작동하는지 확인하고, 시스템 테스트를 통해 전체 시스템이 제대로 동작하는지 확인하며, 마지막으로 사용자의 요구를 모두 반영하는지 인수 테스팅을 실시한다.
프로토타이핑 모델 (Prototyping Model)
프로토타이핑 모델은 요구 사항에 대한 피드백을 받기 위해 시스템을 실험적으로 만들고(프로토타입) 사용자에게 보여주고 평가를 받는 방법이다. 프로토타이핑은 소프트웨어의 일부를 구현하여 보여주며, 구현 단계에서 사용될 골격 코드가 될 수 있다. 이때, 프로토타입은 쓰고 버리는 일회용과 계속 발전시켜 나가는 진화형으로 나누어진다.
프로토타이핑 모델의 장단점은 다음과 같다.
- (장점) 문제점을 빨리 파악하여 요구 사항에 반영할 수 있고 정확한 기능 요구를 확정 지을 수 있다.
- (장점) 설계 시 기술적인 문제가 있으면 프로토타입을 만들어 타당성을 확인할 수 있다.
- (단점) 프로토타입 개발에 많은 비용이 들 수 있고, 프로토타입을 중심으로 요구가 정리되는 경우 문제가 생길 수 있다.
나선형 모델 (Spiral Model)
나선형 모델은 “목표, 방법, 제약 조건 결정”, “위험 요소 분석 및 해결”, “개발과 평가”, “다음 단계 계획”의 4가지 단계를 반복 순환하며 시스템을 확대시켜 나가는 방법이다. 재정적, 기술적 위험 부담이 큰 경우, 요구사항 및 아키텍쳐를 이해하기 어려운 경우 적합하다.
- 반복 주기가 시작될 때 소프트웨어의 목표와 제약 조건을 결정한다.
- 프로토타입을 만들며 위험을 분석하고 하나의 표준 개발 주기를 진행하여 소프트웨어를 구축한다.
- 소프트웨어를 구축하면 다음 주기를 준비하고 계획한다.
소프트웨어 개발 프로세스를 위험 관리 측면에서 보며, 프로젝트 초기에 실패 요인과 위험 요소를 찾아내어 대비하고자 한다. 나선형 모델의 장단점은 다음과 같다.
- (장점) 비선형적이며 반복적으로 개발이 진행되어 소프트웨어 품질을 높일 수 있다.
- (장점) 오류 수정과 앞 주기에서 이루어지는 변경에 유연하게 대처 가능하다.
- (단점) 싸이클을 잘 관리하는 것이 어렵다.
진화적 모델 (Evolutionary Model)
진화적 모델은 프로토타입을 개발하고 좋은 쪽으로 개선을 시키며 발전시키는 방법을 따른다. 진화적 모델에서는 초기 단계에 모든 요구 사항을 파악하여 확정할 필요가 없고, 시스템 개발 도중에 요구를 변경하기 쉽다. 진화적 모델에서 시스템을 발전시키는 두 가지 방법이 있다.
- `점증적 방법`: 시스템을 기능 별로 여러 개의 서브시스템으로 나누고 일부 기능만을 포함한 서브시스템을 배포하고 다음에 새로운 기능을 추가한다.
- `반복적 방법`: 시스템 전체 기능을 대상으로 하되 릴리스할 때마다 기능을 더 완벽히 개발하는 형태이다.
진화적 모델의 장단점은 다음과 같다.
- (장점) 몇 가지 기능이 부족해도 초기에 사용 교육을 할 수 있다.
- (장점) 이전에 없던 기능을 가진 스프트웨어에 대한 시장을 빨리 점유할 수 있다.
- (장점) 자주 릴리스하여 가동 중인 시스템에서 발생하는 예상 못한 문제를 신속하고 꾸준하게 고칠 수 있다.
- (단점) 프로젝트 관리가 상당히 복잡해지기에 소규모 프로젝트에 적합하지 않다.
- (단점) 반복적인 프로세스로 프로젝트의 끝이 보지 않을 수 있다. 이로 인해 프로젝트 실패 위험도 커진다.
- (단점) 프로젝트의 진행이 위험 분석에 크게 의존될 수 있다.
통합 프로세스 (Unified Process)
통합 프로세스는 여러 싸이클로 구성되고, 싸이클은 시스템을 출시하여 종결된다. 하나의 반복 과정은 “도입”, “정련”, “구축”, “전환” 4단계로 구성된다. 각 단계는 점검 일정으로 종류되고 관리자가 프로젝트에 대한 중요한 결정을 내린다. 각 4단계는 다음과 같다.
- `도입(Inception)`: 간단한 유스케이스 모델, 소프트웨어 구조, 프로젝트 계획을 작성한다. 도입 단계는 1~2회 정도 반복으로 도입 단계를 진행한다.
- `정련(Elaboration)`: 대부분의 유스케이스를 작성하고 아키텍쳐 설계를 나타내는 UML 다이어그램을 그린다.
- `구축(Construction)`: 남아 있는 유스케이스에 대해 구현하고 시스템에 통합한다.
- `전환(Transition)`: 시스템을 배치하고 베타 테스팅을 진행하며 결함 수정 및 기능 개선의 작업을 수행한다.
NOTE!
유스케이스 모델: 어떤 시스템이 개발될 것인지 나타내기 위해 비지니스 프로세스를 모델링한 것
통합 프로세스의 장단점은 다음과 같다.
- (장점) 방법론과 프로세스가 잘 문서화되고 쉽게 접할 수 있어 교육 받기 좋다.
- (장점) 요구 변경에 대한 리스크를 적극적으로 해결 가능하다.
- (장점) 반복적 개발 싸이클을 통해 통합을 위한 노력과 시간을 줄일 수 있다.
- (단점) 프로세스가 너무 복잡하여 전문가가 아니면 이해하기 어렵다
- (단점) 의사소통에 대한 자세한 가이드가 없고, 조직화되지 않은 개발로 완전하지 않은 소프트웨어 개발로 이어질 수 있다.
애자일 프로세스 (Agile Model)
애자일 프로세스는 프로젝트에 대한 피드백을 빨리 받고 방향을 평가하여 짧은 싸이클을 반복한다. 2~6주 사이의 짧은 주기로 개발을 반복해서 부분적인 기능을 완성시키고 시스템 전체를 완성시킨다. 애자일 프로세스의 중요한 특징은 다음과 같다.
- 형식적 문서보다 커뮤니케이션을 통해 프로젝트가 목표를 향하여 나아가게 한다.
- 사용자는 문서가 아니라 실행되는 소프트웨어를 통해 요구를 확인한다.
- 사용자의 요구는 비지니스 환경에 따라 프로젝트 중간에 바뀔 수 있다는 것을 고려한다.
- 짧은 주기 동안 요구정의에서 구현, 테스트를 이루며 각 반복 주기의 성찰 의견을 다음 계획에 포함한다.
애자일 프로세스의 장단점은 다음과 같다.
- (장점) 다른 프로세스 모델보다 소프트웨어 배포가 빨라 즉각적 피드백을 받을 수 있으며, 변화에 더 잘 적응하고 대응할 수 있다.
- (장점) 항상 최신 작업을 수행하기에 자원의 낭비가 적다.
- (장점) 문제와 결함을 더 빨리 감지하고 수정할 수 있다.
- (장점) 불필요한 문서화에 시간을 덜 쓰고, 비용이 저렴하기에 아이디어를 실험하고 테스트한다.
- (단점) 문서화가 등한시되기에 개발자의 성장 속도를 높이기 어렵다.
- (단점) 애자일 모델은 개발자와 고객이 지속적으로 상호 작용해야 하기에 많은 에너지와 시간을 소모한다.
- (단점) 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속 될 수 있다.
지원 프로세스 (Support Process)
소프트웨어 개발에 있어서는 개발 프로세스 뿐만 아니라 프로젝트 관리 프로세스, 형상 관리 프로세스, 품질 관리 프로세스 등 개발 전 과정에 필요한 다른 성격의 프로세스도 필요하다. 이를 “지원 프로세스”라고 한다.
관리 프로세스
관리 프로세스는 비용과 품질 목표를 달성하기 위해 관리하는 모든 작업을 말한다. 당연히 대규모 프로젝트를 성공시키기 위해서는 관리 프로세스가 필요하다. 관리 프로세스의 작업은 크게 다음의 세 가지로 분류된다.
- 계획: 프로젝트의 목적에 맞는 소프트웨어 개발 계획을 개발하는 것으로, 개발 작업이 시작되기 전에 작성되고 개발하면서도 변경된다.
- 모니터링: 개발하는 동안 수행하는 모든 작업이 프로젝트의 목적에 부합하는지, 개발이 계획대로 진척되는지 확인하기 위하여 데이터를 수집한다.
- 제어, 분석: 모니터링에 의하여 확인된 사실을 분석하고, 계획과 차이나는 부분을 조정한다.
품질 보증 프로세스
품질 보증 프로세스는 소프트웨어 프로젝트의 프로세스와 프로덕트에 대한 품질을 관리하고 향상시킨다. 크게 다음의 두 가지로 분류된다.
- 인스펙션 프로세스(Inspection Process): 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것으로, 적은 비용으로 조기에 결함을 찾아 생산성을 높인다.
- 프로세스 관리 프로세스: 프로세스 관리는 프로젝트 관리와 다르다. 프로세스 관리는 프로세스를 개선하여 생성된 결과의 품질과 생산성을 향상시키는 것으로, 프로젝트가 진행되는 기간을 초과하는 긴 시간 동안 이루어진다.
형상 관리 프로세스
형상 관리는 “소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것”으로, 소프트웨어 프로젝트에서는 변경이 빈번히 일어나기에 개발 중에 발생하는 변경을 체계적으로 컨트롤하는 것이 중요하다.
형상 관리는 높은 품질의 소프트웨어 프로덕트를 고객에게 납품하기 위해 필수적이다. 결국 프로젝트를 수행하는 동안 요구의 변경은 필연적인데, 프로젝트의 후반에 요구가 변경되면 프로젝트에 치명적이다.
개발 방법론 (Develope Methodology)
소프트웨어 개발 방법론이란 소프트웨어 프로세스의 각 작업을 어떻게 수행하는가를 정의한 것이다. 즉, 프로세스의 구현이 바로 방법론이다.
NOTE!
소프트웨어 개발 방법론: 소프트웨어 프로세스의 각 작업을 어떻게 수행하는가를 정의한 것
방법론은 프로세스가 구체적으로 구현된 것이고 소프트웨어 프로세스는 하나 이상의 방법론으로 구현될 수 있다.
구조적 방법론 (Structured Development Methodology)
구조적 분석 설계 방법론은 실세계의 문제를 “처리”라는 관점으로 모델링한다. 자료 흐름도를 사용하여 모델링을 하며, 각 노드는 외부 엔티티, 프로세스, 자료 저장소를 표현하고 자료 흐름 관계를 간선으로 나타낸다.
구조적 분석에서는 복잡한 문제를 쉽게 다루기 위해 분할 정복 원리를 적용한다. 시스템 전체를 프로세스로 보고 복잡한 프로세스를 단순한 프로세스로 분할하며 나간다. 계층의 말단 프로세스를 쉽게 구현할 수 있을 때까지 분할하는 것이다.
이때, 소프트웨어 모듈 사이의 구동 관계를 나타낼 때는 자료 흐름도가 적절하지 않다. 소프트웨어와 모듈 사이의 구동관계는 자료 흐름이 아니라 제어 흐름이기 때문이다. 따라서 구조적 설계는 자료 흐름도를 구조도로 변경한다. 구조도는 모듈 사이의 관계를 나타내는 그래프이다.
정보공학 방법론 (Information Engineering Methodology)
구조적 방법론에서 발생하는 기업 전체의 조망과 데이터 통합의 어려움을 극복하기 위해 정보공학 방법론이 고안되었다. 정보공학 방법론은 기업 전체나 기업의 주요부분을 계획, 분석, 설계 및 구축에 정형화된 기법들과 상호 연관성 있게 통합 및 적용하는 데이터 중심 방법론이다.
객체지향 방법론 (Object-Oriented Methodology)
객체지향 방법론은 실세계를 “객체”로 판단하고, 객체 사이의 상호작용은 모델링하는 방법이다. 객체지향 방법론은 대규모 시스템을 클래스로 “모듈화”하고 “캡슐화”하는 방법이다. 결국 객체지향 방법론에서는 주어진 작업을 수행하기 위해 협력하는 객체들의 모임이 바로 시스템이다.
객체지향 프로그래밍이 널리 퍼지며 다양한 방법론들이 나오게 되었는데, 서로 다른 방법론을 이용하여 개발된 시스템을 통합하고 유지보수하는 것은 비용도 많이 들고 효율적이지 않다. 이러한 문제들을 해결하기 위해 통합된 방법이 요구되었고 이를 통해 UML(Unified Modeling Language)와 UP(Unified Process)가 등장하게 되었다.
