2022. 5. 13. 14:26ㆍMajor`/소프트웨어 공학
프로세스 & 방법론
"어떤 일을 하기 위한 특별한 방법 :: 단계나 작업으로 구성됨"
결국 소프트웨어에 대한 공학적 접근의 가장 핵심은 "프로세스"이다
결론적으로 프로세스란 소프트웨어를 개발하는 공정을 정의한 것이다
이렇게 정의된 작업들을 "어떤 순서로 어떤 방법으로 하는가"를 다루는 것이 방법론이다
프로세스 없이 무작정 개발을 시작하게 되면 "Code & Fix"가 반복된다
처음에는 개발속도가 빠르겠지만 나중에는 개발하는거보다 개발 시에 발생한 오류를 고치는데 더 시간을 많이 쓰게 될 것이다.
따라서 진도가 나아가지 못하고 정체될 것이다
Code & Fix는 다음과 같은 문제점을 발생시킨다
1. 고객들의 needs를 파악하거나 설계하는 작업의 중요성을 절대 모른다
2. 설계 작업없이 무작정 코딩과 수정을 반복하면 구조가 나빠진다
3. 결국 계획이 없기 때문에 목표 또한 없다
4. 체계적인 테스트 작업이나 QA 활동에 대한 필요성의 인식이 없다
이러한 문제점들은 소프트웨어 개발과 유지보수에 비용이 많이 들게 한다
당연한말로, 문제가 늦게 발견될수록 고치는 cost는 굉장히 커진다
| 프로세스 | 방법론 | |
| 특징 | - 단계적인 작업의 틀을 정의한 것 - 무엇을 하는가에 중점 (What) - 결과물의 표현에 대한 언급 X - 각 단계가 다른 방법론으로도 실현 가능 |
- 프로세스의 구체적 구현 - 어떻게 하는가에 중점 (How) - 결과물을 어떻게 표현하는지 표시 - 각 단계의 절차/기술/가이드라인을 제시 |
| 사례 | - 폭포수 프로세스 - 나선형 프로세스 - V 프로세스 - 프로토타이핑 프로세스 - 애자일 프로세스 |
- 구조적 분석 / 설계 방법론 - 객체지향 방법론 - 컴포넌트 - 애자일 방법론 |
소프트웨어 생명주기
소프트웨어를 개발한다는 것은 사실 집이나 빌딩을 짓는 "건축"과 유사하다
1. 요구사항 분석
일단 집을 지으려면 건축설계사가 집주인과 만나 어떤 집을 원하는지 "요구사항 분석"을 수행한다
여기서 집주인은 건물의 모양뿐만 아니라 {방이 몇개 필요하고, 각 방의 용도는 무엇이고, 어떠한 기능들을 할 수 있고 ....}를 요구할 것이다
이러한 고객들이 요구사항에 대해서 건축설계사는 먼저 분석을 수행할 것이다
2. 설계
고객의 요구사항을 분석하고 바로 집을 짓는것이 아니라 집을 짓기 위한 "설계도면"을 작성한다
이부분은 상식적으로 당연히 수행하는 작업이다.
설계를 안하고 집을 짓는다는 것은 말이 안되는 일이기 때문이다
소프트웨어 개발에서도 동일하다
소프트웨어를 개발하려면 당연히 먼저 인터페이스나 여러가지 요소들을 설계를 해야 한다
3. 구현
설계가 끝나면 이제 실제 "구현"에 들어간다
설계 작업까지는 실제 프로그램에 대한 언급은 하지 않고, 주로 기능과 UI와 DB등에 대해서 설계를 한다
결국 소프트웨어 기능과 컴포넌트의 상호 관계를 정확히 파악한 후 구현(프로그래밍)에 들어간다
4. 테스트
구현이 완료되면 "테스트"를 수행해야 한다
집을 다 지었다고 그 집에 바로 입주하는 것은 멍청한 일이다
왜냐하면 집을 다 지었다고 그 집에 문제점이 없는 것은 아니기 때문이다
불이 잘 켜지나, 물은 잘 나오나, 난방은 잘 되나, ....
물론 프로그래밍 관점에서는 위의 여러 모듈단위의 테스팅을 수행해야 한다
모듈단위의 테스팅이 끝나면 통합을 하고, 전체 시스템의 기능이 잘 작동되는지 원하는 성능이 잘 발휘되는지 통합 테스팅을 수행한다
5. 유지보수
테스트를 끝내고 시중에 소프트웨어를 내놓는다고 끝나는 것이 아니다. 가장 중요한 "유지보수"를 해야 한다
신이 아닌 이상, 미래를 예상하지 않는 이상 소프트웨어 개발만 한다고 해서 미래에 고객이 요구하는 변화에 대해서 예상하고 만들 수는 없다
출시 후, 소프트웨어에 에러는 발생하지 않는지 또는 고객들의 니즈가 변경됨에 따라서 개발된 소프트웨어를 업데이트 해야하는 것은 아닌지, ...
이러한 유지보수 단계가 굉장히 중요하다
프로세스
프로세스는 위에서 말했듯이 "소프트웨어 시스템을 구축하기 위해서 수행되는 작업의 단계"이다
소프트웨어를 개발하는 조직에서는 동시에 수행되는 여러 작업들이 존재한다
이러한 여러 작업들 가운데는 소프트웨어 개발에는 영향을 주지만, 실질적 소프트웨어 공학과는 관련이 없는 것들도 존재한다
- 비즈니스 프로세스
- 훈련 프로세스
- ...
프로세스 종류
▶ 개발 프로세스
수행해야 할 개발 작업과 QA 작업들의 이 개발 프로세스에 해당
▶ 프로젝트 관리 프로세스
비용, 품질, 기타 목표를 맞추기 위한 계획, 제어 작업을 의미
▶ 형상 관리 프로세스
변경을 관리해서 제품의 일관성을 유지하기 위한 프로세스
좋은 프로세스의 특성
1. 예측 가능성
어떤 프로젝트 안의 프로세스의 결과가 프로젝트를 완성하기 전에 얼마나 정확하게 예측될 수 있느냐는 것이다
비용을 예측하는 것을 예로 들어보자
어떠한 프로젝트 A는 이전에 이미 완료된 프로젝트 B와 거의 유사하다고 하자
이 때 프로젝트 B의 비용이 대략 100억원정도 들었다고 하면 프로젝트 A의 비용도 대략 100억원정도 들거라고 예측이 가능하다
여기서 프로세스가 예측 가능하다는 사실을 가정하고 있다
만약 예측 가능하지 않다면 유사 프로젝트에 대한 동일 비용 발생을 보장할 수 없다
2. 테스팅과 유지보수 용이성
일반적으로 소프트웨어 유지보수 비용은 개발 비용을 초과한다
따라서 소프트웨어 개발 비용 부분만 줄이는 것보다 전체 비용을 줄이려면 결국 유지보수에 대한 노력도 줄여야 한다
따라서 소프트웨어 개발에 가장 중요한 사항중 하나는 "유지보수가 쉬운 소프트웨어 만들기"이다
3. 변경 용이성
소프트웨어는 여러가지 이유로 변경된다. 소프트웨어의 변경은 필연적이다
고객의 요구사항의 변경으로 인한 수정은 당연시되고 있다
조직과 비즈니스가 변경된다면 이를 지원하는 소프트웨어도 당연히 변경되어야 한다
따라서 변경은 항상 일어나기 떄문에 변경을 쉽게 다룰 수 잇는 프로세스가 중요하다
4. 결함 제거 용이성
프로그래밍은 인간이 하기 때문에 언제 어디서든 결함이 발생할 수 있다
하지만 이러한 결함은 빨리 발견될수록 결함을 고치는 노력 & cost가 감소할 수 있다
일반적으로 요구분석 단계에서 발생한 오류를 고치는 것보다 테스팅 단계에서 수정하면 비용이 약 100배 정도 증가한다
폭포수 모델
폭포수 모델은 개발 과정을 {요구분석 - 설계 - 구현 - 테스트 - 운영/유지보수}로 나누고 위에서부터 순차적으로 진행되는 프로세스 모델이다
- 계획 완벽히 짜기 (검증 & 검증...)
- 요구분석 완벽하게 하기 (검증 & 검증...)
- 설계 완벽하게 하기 (검증 & 검증...)
- 구현 완벽하게 하기 (검증 & 검증...)
- 테스트 완벽하게 하기 (검증 & 검증...)
오른쪽 사진에서는 되돌아가는 것을 볼 수 있는데 폭포수 모델을 정의한 왼쪽 사진에서는 되돌아가는 것을 볼 수 없다
되돌아가는 것을 우리는 "피드백"이라고 한다
하지만 대부분의 심각한 오류는 "테스트"단계에서 발견이 되고 테스트단계에서 되돌리는 것은 사실상 의미가 없는 너무 늦은 발견이다
따라서 폭포수 모델에서 피드백이 아예 없는 것은 아니지만 사실상 무용지물이라고 할 수 있다
1. 계획수립
여기서는 고객의 요구조건, 시스템 환경 등을 고려해서 프로젝트 진행 여부를 판단하고 진행 결정이 최종적으로 나면 프로젝트의 전반적 계획 수립에 들어가게 된다
계획수립은 다음질문들의 대답을 찾는 단계이기도 하다
- How much will it cost?
- How long will it take?
- How many people will it take?
- What might go wrong?
"Why"라는 물음에 대한 단계이고, 여기서 가장 중요하게 생각해야 하는 개념이 ROI(Return Of Investment)이다
결국 소프트웨어 개발을 하는 궁극적 목표는 1) 소프트웨어 제품을 통해서 시장에서 가치를 인정받고 2) 얼마나 많은 사람들이 해당 소프트웨어를 사용하고 3) 그에 따른 이득은 얼마나 가져올 수 있는지이다
2. 요구사항 분석
"요구사항"이라는 것은 시스템이 가져아하는 능력&조건을 의미한다
따라서 Request된 요구사항을 분석해서 시스템에 어떠한 기능을 넣을 것인지 도출해내야 한다
결국 요구사항 분석은 "What"의 단계라고 할 수 있다
>> 요구사항 분석을 통한 결과물로는 SRS(Software Requirement Spec : 요구사항 분석서)가 도출되어야 한다
어떻게보면 "요구사항 분석 단계"는 가장 중요하다고 볼 수 있다
여기서 시스템의 여러가지 기능들을 정의하고 나중에 설계&구현&테스트를 할텐데 테스트단계에서 기능자체에 대한 잘못된 정의로 인한 오류가 발생했을 경우 그 시점에 요구사항을 변경하기에는 너무 리스크가 크다.
- 따라서 기능에 대한 결함은 최대한 빨리 발견해야 해결에 대한 cost가 훨씬 줄어들고 가급적이면 요구사항 분석에서 결함을 발견하자
그리고 폭포수 모델은 사실상 이전단계로의 feedback이 의미가 없는 프로세스 모델이다
3. 설계
요구사항 명세가 전달되면 "요구사항 명세를 준수하는 설계"에 들어가게 된다
설계는 "How"의 단계라고 할 수 있다
- 아키텍쳐 설계
- DB 설계
- UI 설계
- 상세 설계
>> 설계를 통한 결과물로는 SD(Software Design)가 도출되어야 한다
4. 구현
설계에 따른 실제 코딩을 통해서 소프트웨어를 만든다
여기서 코딩만 하는 것이 아니다 "단위 테스트 & 코드 검증"도 함께 진행된다
여기서 단위테스트란 모든 메소드에 대한 테스트 케이스를 통해서 정상적으로 메소드(단위)들이 잘 작동하는지 하나하나 따져보는 것이다
이렇게 코딩을 하면서 UnitTest도 거치기 때문에 사실상 이 단계를 "개발 & 단위테스트 단계"라고 부른다
그리고 프로젝트 규모가 커지면 구현단계는 설계/통합 단계와 합치기도 한다
- 전체 일정 줄이기 위해서
- 협력 작업이 필요하기 때문에
5. 테스트
구현한 소프트웨어를 점차 통합해가면서 테스트를 진행한다
- 통합은 주로 개발자가 담당하고, 테스트는 주로 QA팀이 담당한다
- 통합 테스트
모듈들을 통합시키며 진행하는 테스트
- 시스템 테스트
전체 시스템의 동작에 대한 검증을 하는 테스트
- 인수 테스트
고객이 현장에서 검증해보는 테스트
6. 운영/유지보수
운영과 유지보수에서는 "Migration"이라는 정책이 굉장히 중요하다
- 예전에 시스템이나 가져고있던 데이터들을 새로운 시스템에 잘 migratino하는 것
유지보수는 {결함 고치기 / 새 기능 추가 / 성능 추가}등의 작업이 존재한다
※ 특징
- 가장 오래되고 널리 사용된 개발 프로세스 모델
- 각 단계가 반드시 완료가 되어야 다음 단계로 넘어갈 수 있다
- 결과물에 대한 정의가 굉장히 중요하다
※ 장점
- 복잡성이 낮다
- 관리가 편하다
- 가장 오래되었기 때문에 사례가 많다
- 전체 과정을 그냥 순차적으로 진행하면 되기 때문에 이해가 쉽가
※ 단점
- 차례대로 진행되기 때문에 S/W가 굉장히 거대해진다
- 요구사항의 구체적 정의가 어렵다
- 나중에 발생하는 문제에 대한 대처가 힘들다
- 불필요한 문서 작성이 요구되고, 설계 & 코딩 & 테스팅 지연 가능성이 존재한다
- "프로토타입"이 없기 때문에 어떤 결과물이 나올지 예측하기 힘들고 중간에 프로젝트를 취소한다면 큰 손실이 초래될 수 있다
※ 폭포수 모델 적용 프로젝트 사례
- 응용분야를 잘 알고 있을 때
- 단순한 프로젝트
- 비전문가가 사용할 시스템 개발
- 산출물에 대한 명확한 정의가 필요한 사이트
- 초기에 정의한 요구사항 변경이 적은 프로젝트
V 모델
V 모델은 폭포수 모델 + 검증(테스트)을 강화한 모델이다
산출물 중심의 폭포수 모델과 달리, V 모델은 각 개발 단계를 검증하는 데 초점을 두었다
※ 장점
- 각 단계가 명확하기 때문에 프로세스의 진행 상황을 관리하기 쉽다
- 코드 생성 전 충분한 연구와 분석 단계의 시간이 주어진다
※ 단점
- 결국 V 모델은 폭포수 모델을 계승한 모델이다. 따라서 이전 단계의 문제가 발견되지 않고 넘어가는 경우가 존재할 수 있다.
- 작업이 순차적으로 이루어지기 때문에 돌아가서 작업을 취소하거나 다시 할 수 없다
- 전체 요구사항이 확정되지 않고 문서화되지 않는다면 설계 작업이 진행되지 않는다
- 프로세스 진행 과정에 변경될 경우 이를 수용할 수 없다
- 결국 테스트 작업은 시스템이 완성된 후에 시작된다
프로토타이핑 모델
프로토타입이란 실제 생산에 앞서 "미리 한번 제작해보는 샘플"이라고 볼 수 있다
요구사항에 대한 피드백을 받기 위해서 이러한 프로토타입을 실험삼아 만들어서 고객들에게 보여주고 평가하게 하는 방법이다
프로토타입은 한번 쓰고 버릴수도(일회용) 있고 아니면 제작한 프로토타입을 계속 발전(진화형)시킬 수도 있다
결국 프로토타입은 고객들의 요구를 명확히 이해하고 확장시키기 위한 목적도 있지만, 개발자의 문제 이해와 기술적 능력을 확인하기 위한 목적도 있다
※ 장점
- 프로토타입은 기능은 부족할 수 있어도 초기에 고객들에게 보여줌으로써 기능이 어떻게 구현될 것인지 미리 확인할 수 있게 해주고, 부족한 부분은 "피드백" 반영이 가능하기 때문에 의사소통 도구로 활용 가능
- 반복된 요구사항 정의를 통해서 사용자의 요구를 충분히 반영할 수 있다
- 프로토타입을 통해서 완성품을 예측할 수 있다
- 빠른 개발을 요구하는 분야에 적합하다
- 개발자입장에서 "내가 진짜 이 소프트웨어를 만들 수 있는 능력이 았는가"를 확인할 수 있다
※ 단점
- 반복적 개발은 결국 투입 인력과 비용 산정의 어려움에 직면할 수 있다
- 중간 산출물 생성의 어려움이 존재한다
- 불명확한 개발 범위로 인해서 개발 종료 및 목표의 불확실성이 존재한다
- 고객이 프로토타입을 완성에 가까운 제품으로 오인해서 불필요하고 과도한 요구를 할 수 있다
나선형 모델
나선형 모델은 다음 4가지 단계를 반복 순환하면서 시스템을 확대시켜 나가는 방법이다
1. 목표, 방법, 제약 조건 결정
2. 위험 요소 분석 및 해결
3. 개발과 평가
4. 다음 단계의 계획
결국 나선형 모델의 가장 큰 특징은 대부분의 다른 모델에서 간과하는 "위험을 분석"한다는 점이다
반복 주기가 시작될 때 소프트웨어의 목표와 제약 조건을 결정한다.
다음 단계는 프로토타입을 만들면서 위험을 분석하고 다음에는 하나의 표준 개발 주기를 진행하며 소프트웨어를 구축한다.
끝으로 다음 주기에 대한 준비와 계획이 이루어진다.
※ 장점
- 사전 위험 분석을 통해서 갑자기 돌출될 위험요소가 감소된다. 이것은 다른말로 프로젝트 중단 확률이 감소한다
- 사용자 평가에 의한 개발방식에 따라서 요구가 충분히 반영된 제품을 만들고 사용자의 불만은 감소될 것이다
※ 단점
- 반복적 개발에 의한 프로젝트 기간 연장의 가능성 존재
- 반복 횟수의 증가에 따른 프로젝트 관리의 어려움
- 위험 관리가 굉장히 중요하고, 그에 따른 위험 전문가가 필요하다
진화적 모델
폭포수 모델의 경우 단계를 거슬러 올라가기 부적합하고 요구사항의 변화가 수시로 발생하기 때문에 이를 해결하기 위해 나온 모델이 "진화적 모델"이다
진화적 모델은 한마디로 일단 내놓고 버전을 업그레이드 한다고 볼 수 있다
1. 일단 가장 먼저 시스템의 핵심 부분에 대한 기능이 명확하고 개발 효과도 좋은 부분을 우선적으로 개발한다
2. (1)에서 만든 시스템을 사용자들의 피드백을 통해서 계속 개선해나간다
이렇게 진화적 모델은 시스템을 여러번의 cycle에 나누어 개발하기 때문에 초기 단계에 모든 요구 사항을 파악해서 확정할 필요가 없다.
또한 시스템 개발 도중에 요구사항을 추가/변경하기도 편리하기 때문에 위험도가 높은 새로운 기술도 적용할 수 있고, 개발과 테스트를 반복함으로써 위험을 줄일 수 있다
※ 장점
- 몇가지 기능이 부족하더라도 일단 사용 및 교육이 가능하다
- 사용자의 요구를 빠르게 반영할 수 있다
- 새로운 기능을 가진 소프트웨어에 대한 시장을 빨리 형성할 수 있다
※ 단점
- 프로젝트 관리가 복잡하기 때문에 큰 프로젝트에 부적합하다
- 끝이 보이지 않을 수 있어서 결국 실패할 가능성이 있다
- 프로젝트의 진행이 위험분석에 크게 의존하게 된다
애자일(Agile) 프로세스
폭포수 모델같은 초기 프로세스 모델은 개발 중 고객의 변경 요청을 처리하고 통합하는 데 많은 시간과 노력이 필요했다
애자일 모델은 프로젝트에 대한 피드백을 최대한 빨리 받고 방향을 평가해서 짧은 사이클을 반복하는 방법이다
애자일 모델을 사용하면 2 ~ 6주간의 짧은 주기(스프린트)로 개발을 반복해서 부분적 기능을 완성시킨다.
짧은 기간의 개발 사이클을 반복하며 실행되는 소프트웨어를 개발해서 단계적으로 시스템 전체를 완성시킨다.
고객들은 실행되는 소프트웨어를 개발 초기에도 사용해보고 확인할 수 있다
결국 요구사항의 변경과 오류를 최대한 빨리 수용할 수 있는 장점이 있다.
애자일 모델은 다음과 같은 가치를 중요하게 생각한다
1. 형식적 문서보다는 커뮤니케이션을 통해서 프로젝트가 목표를 향하여 나아가게 한다
2. 사용자는 문서가 아닌 실행되는 소프트웨어를 통해서 요구를 확인
3. 사용자의 요구는 비즈니스 환경에 따라 프로젝트 중간에 바뀔 수 있다는 것을 고려한다
4. 짧은 주기 동안 요구정의에서 구현, 테스트까지 이루어지며 각 반복 주기의 반성 의견을 다음 계획에 포함시킨다.
...
애자일 소프트웨어 개발 선언
애자일 소프트웨어 개발 선언 우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게
agilemanifesto.org
애자일 모델 중 대표적인 것은 "익스트림 프로그래밍(XP)" & "스크럼(Scrum)"이 있다
익스트림 프로그래밍 (eXtreme Programming)
"프로그램에 집중하면서 설계는 최소한으로 해보자"
XP는 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 애자일 방법이다.
시스템을 자주 통합하고 빌드하는 것이 좋다면 XP에서는 매일 빌드하는 것을 원칙으로 삼고 있다
1. 사용자 스토리
긴 요구사항 문서를 통해서 기능을 정의하는 것이 아니라 간단한 사용자 스토리를 작성한다.
사용자 스토리에는 각 기능의 비즈니스 가치와 우선순위를 정한 것이다
2. 매일 빌드와 통합
실행되는 시스템을 항상 준비하기 위해서 개발한 것을 매일 빌드하고 통합한다
3. 테스트 주도 개발 (TDD : Test-Driven Development)
코딩에 앞서 먼저 요구사항을 검증하는 테스트 시나리오를 작성한다.
다음은 테스트 시나리오를 통과하기 위한 최소한의 코드를 생성한다
마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다
4. 페어 프로그래밍
두명의 프로그래머가 하나의 컴퓨터를 공유하면서 한 사람은 코딩을 하고 다른 한 사람은 확인하면서 개발하는 방식이다
프로그램을 수시로 검토해서 품질을 높일 수 있고, 짝을 이루면 프로그램에 대한 지식을 공유하여 문제 해결 시간을 단축할 수 있는 장점이 있다
하지만 페어 프로그래밍의 단점은 두명의 개발자가 생각하는 로직이 너무 다르면 통합하기가 힘들고, 개발자의 성향에 따라 혼자 개발하는 것이 더 효율적인 개발자가 존재할 수 있다
스크럼 (Scrum)
개발팀이 함께 일하는데 도움이 되는 방법이다.
개발 팀원 모두가 함께 소통하고 협력하여 짧은 주기를 반복하며 소프트웨어를 개발하는 작법, 역할, 결과물의 집합체이다
스크럼은 계속 변경되는 요구에 잘 적응하는 애자일 원리를 잘 따르고 있다
프로젝트가 시작될 때 전체를 알지 못하지만 할 일(백로그)를 정하고 여기에 우선순위를 부여한다
짧은 주기(스프린트)를 반복하여 출시주기를 단축하며 팀과 사용자가 지속적으로 소통하고 의견을 반영(스크럼 미팅)하여 시스템을 향상시킨다
가장 큰 스크럼의 특징은 매일 15분간 하는 스크럼 회의이다. 이 회의에서 팀 구성원은 서로의 진도를 확인하고 상호 이해를 증진한다
그리고 스크럼 스프린트가 끝날 때 회고를 한다는 것이다. 이러한 회의를 통해서 팀의 능력과 시스템을 향상시킬 수 있다
※ 장점
- 다른 프로세스 모델보다 소프트웨어를 빠르게 배포할 수 있어서 고객이 그 가치를 얻을 수 있다
- 최종 결과물뿐만 아니라 요구 처리 시간이 적어서 즉각적인 피드백을 받을 수 있다. 결국 변화에 더 잘 적응하고 빠르게 대응할 수 있는 장점이 있다
- 항상 최신 작업을 수행하기 때문에 자원의 낭비가 적다
- 문제와 결함을 더 빨리 감지하고 수정할 수 있다
- 계층적 관료주의와 불필요한 문서화 등에 시간을 덜 쓴다. 또한, 비용이 저렴하므로 아이디어를 실험하고 테스트 할 수 있다
※ 단점
- 문서화가 등한시되어서 새로 들어온 신입 개발자가 개발 속도를 높이기 힘들 수 있다
- 애자일 모델은 개발자와 고객이 지속적으로 상호 작용해야 하므로 모든 사람에게 더 많은 시간과 에너지를 요구한다
- 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속될 수 있다
- UI 및 아키텍처 관점에서 전체적인 디자인이 부족해서 제품을 완성시키기 위한 작업이 더 많이 드는 문제가 발생할 수 있다
