[Software Engineering] CH2 : Software Process and Methodology Review

Key Takeaway Points

• 소프트웨어 프로세스는 활동의 단계 또는 소프트웨어 시스템을 구성하기 위해 수행해야 하는 것을 정의한다.
• 소프트웨어 방법론은 소프트웨어 프로세스의 단계 또는 활동을 수행하는 방법을 상세하게 설명한다. 방법론은 프로세스의 구현이다.
• 소프트웨어 개발은 소프트웨어 프로세스와 방법론을 필요로 한다.

실제 시스템 개발의 도전 과제를 극복하기 위해서는 시스템 개발에 대한 규율 있는 접근 방식이 필요하다. 이를 일반적으로 소프트웨어 프로세스라고 한다. 프로세스는 소프트웨어 시스템을 개발하기 위해 수행해야 할 활동을 명시하는 반면, 방법론은 프로세스의 활동을 수행하기 위한 단계와 방법을 정의한다. 즉, 방법론은 프로세스의 구현이다.

1. CHALLENGES OF SYSTEM DEVELOPMENT

먼저, 프로젝트 과제가 있다:
· 프로젝트 현실 1. 실제 프로젝트는 일정 및 예산 제약 조건을 충족해야 한다.

· 프로젝트 도전 1. 고객이 원하는 것이 무엇인지, 그리고 앞으로 몇 년 안에 어떤 일이 일어날 것인지에 대한 완전한 지식 없이 프로젝트 작업을 어떻게 계획, 일정, 관리할 것인가?

· 프로젝트 현실 2. 많은 시스템 개발 프로젝트는 여러 부서 또는 개발 팀의 협력을 필요로 한다. 예를 들어, 많은 대규모 임베디드 시스템은 하드웨어와 소프트웨어 구성 요소를 모두 포함하고, 소프트웨어 엔지니어링 부서가 하드웨어 부서와 협력하도록 요구한다.

· 프로젝트 도전 2. 부서와 팀에 작업을 분할하고 부서 간 찌그러진 조각을 할당하고, 다른 부서와 팀에서 생산된 구성 요소를 원활하게 통합할 수 있는 방법은 무엇인가?

· 프로젝트 현실 3. 다른 부서나 팀은 다른 개발 프로세스, 방법 및 도구를 사용할 수 있다. 부서나 팀이 다른 장소에 위치할 수도 있다.

· 프로젝트 도전 3. 부서와 팀 간의 적절한 의사 소통과 조정을 어떻게 보장할 수 있는가? 프로젝트 과제 외에도 제품에 대한 도전 과제가 있다.

· 시스템 리얼리티 1. 현실의 많은 시스템은 엄격한 실시간 제약 조건을 포함하여 많은 요구 사항과 제약 조건을 충족해야 한다. 예를 들어, 메일 처리 시스템은 수백 가지의 요구 사항과 제약 조건을 가지고 있다. 시간당 40,000개 이상의 우편물 혹은 초당 12개 이상의 우편물을 스캔하고 처리하는 것이 요구된다.

· 시스템 챌린지 1. 이러한 요건과 제약 조건이 충족되도록 하려면 어떻게 시스템을 개발해야 할까?

· 시스템 리얼리티 2. 요건과 제약 조건은 수시로 변경될 수 있다. 저자가 계약한 작은 프로젝트를 예로 들어보자. 고객의 변경 요청으로 인해 처음 3개월 동안 매주 요구사항이 변경되어야 했다.

· 시스템 챌린지 2. 종종 불가피하고 정확한 변화를 예측하는 것이 불가능한 변화에 대처하기 위해 프로세스와 제품을 어떻게 설계해야 하는가?

· 시스템 리얼리티 3. 시스템은 수년간 진화하면서 유지보수 문제를 일으킬 것이다. 예를 들어, 변화가 문서화되지 않거나 제대로 문서화되지 않으면 시스템의 변화는 버그를 유발할 뿐만 아니라 시스템의 구조를 악화시킬 수 있다. 이 모든 것들은 시스템을 점점 더 이해하고 테스트하며 유지보수하기 어렵게 만든다.

· 시스템 챌린지 3. 시스템의 나머지 부분에 큰 영향 없이 비교적 쉽고 간편하게 변화가 이루어질 수 있도록 시스템을 어떻게 설계하는가?

· 시스템 리얼리티 4. 시스템은 하드웨어와 소프트웨어 구성요소로 구성될 수 있고, 제3자 구성요소와 여러 구현 언어를 사용할 수 있으며, 서로 다른 장소에 위치한 여러 플랫폼과 기계에서 실행될 수 있다.

· 시스템 챌린지 4. 하드웨어, 플랫폼 및 구현의 특성을 숨기도록 시스템을 어떻게 설계하여 이러한 변화가 시스템의 나머지 부분에 영향을 미치지 않도록 하는가?

2. SOFTWARE PROCESS

소프트웨어 프로세스는 소프트웨어 시스템을 구성하기 위해 수행되는 일련의 활동 단계이다. 각 단계는 다른 단계로의 입력인 일부 산출물을 생성한다. 각 단계에는 진입 기준 세트와 퇴출 기준 세트가 있다.

3. MERITS AND PROBLEMS OF THE WATERFALL PROCESS

종래의 폭포 프로세스는 요구사항 분석, 설계, 구현, 테스트 및 유지보수와 같은 일련의 활동을 정의한다. 이 프로세스는 많은 회사에서 수십 년 동안 사용해 왔다. 이 프로세스의 문제점을 논의하기 전에, 이 프로세스에는 여러 가지 장점이 있음을 지적하는 것이 공정할 것이다.

이러한 장점은 이 프로세스가 소프트웨어 산업에서 여전히 사용 중인 이유를 설명한다.
첫째, 폭포 프로세스의 간단하고 직선적인 단계 시퀀스는 프로젝트 계획, 프로젝트 스케줄링 및 프로젝트 상태 추적을 크게 단순화한다. 이러한 의미에서, 이는 "예측 가능한" 프로세스로 간주된다.

둘째, 기능적 활동의 직선적인 시퀀스는 기능 지향적인 프로젝트 조직을 가능하게 한다. 이러한 조직에서, 기능 팀들은 요구사항 분석, 설계 및 구현과 같은 다양한 기능 영역에 특화되어 있다. 기능 팀들은 파이프라인 방식으로 프로젝트를 수행한다.

폭포 프로세스의 세 번째 장점은 단계적 접근 방식이 일부 크고 복잡하고 오래 지속되는 임베디드 시스템에 적절하다는 것이다.
이러한 시스템의 예로는 메일 정렬 및 라우팅 시스템, 프로세스 제어 시스템 및 기타 여러 유형의 컴퓨터화된 장비가 있다. 이러한 시스템은 하드웨어에서 생성된 수많은 이벤트에 응답하고, 엄청난 양의 수신 데이터를 처리하고, 하드웨어 장치의 동작을 제어해야 한다. 일반적으로 이러한 시스템의 기능 또는 요구사항은 장비 제조업체와 고객이 공동으로 정의한다. 많은 경우, 개발될 시스템은 기존 시스템의 기능, 성능 및 보안을 주요하게 향상시키는 것에 불과하다. 공급업체는 애플리케이션 및 고객이 원하는 것에 대한 경험과 좋은 지식을 가지고 있으므로 요구사항에 대한 주요 변경은 드물다. 구매 주문이 발행되면, 고객은 리뷰 및 프로토타입 시연에 참여하지만, 고객은 수락 테스트 단계까지 장비에 액세스할 수 없다. 단계적 접근 방식은 시스템이 안정적으로 실행되고 성능 및 타이밍 제약을 충족하는 것을 보장하기 위해 각 단계를 엄격하게 수행할 수 있게 한다.

폭포 프로세스에는 여러 가지 심각한 단점이 있다.

첫째, 단계 및 관련 마일스톤의 하나의 엄격한 시퀀스는 요구사항 변경에 대응하는 것을 어렵게 만든다. 그러나 비즈니스 경쟁 증가, 새로운 규정 또는 표준, 또는 모든 요구사항을 식별할 수 없는 것과 같은 많은 상황에서 요구사항 변경이 필요하다. 많은 애플리케이션의 경우, 요구사항이 오래 전에 식별되었고 비즈니스 요구사항이 극적으로 변경되었기 때문에 긴 개발 기간을 허용할 수 없다.

셋째, 사용자는 시스템이 출시될 때까지 피드백을 제공하는 실험을 할 수 없다. 경험에 따르면 조기 사용자 피드백은 비즈니스 요구사항 및 사용자 인터페이스 설계의 문제에 대한 잘못된 개념을 감지하는 데 도움이 된다.
또 다른 단점은 고객이 긴 개발 기간 동안 새로운 시스템의 혜택을 누릴 수 없다는 것이다.

마지막으로, 고객은 프로젝트가 취소될 경우 낮은 투자 수익의 위험을 받아들여야 한다. 즉, 설계 문서 및 부분 테스트된 코드는 투자 가치가 없다.

4. SOFTWARE DEVELOPMENT IS A WICKED PROBLEM

폭포수 과정의 문제는 사악한 문제에 대한 이론과 밀접한 관련이 있다. 사악한 문제는 여러 사악한 문제의 속성이나 줄여서 사악한 속성을 나타낸다. 이러한 속성들은 사악한 문제가 풀기 어렵다는 것을 의미한다. 이에 비해 수학적 방정식 체계 해결, 체스 두는 프로그램 개발, 컴파일러 구성, 연산 연구와 같은 길들여진 문제는 좋은 속성을 나타낸다. 불행하게도 응용 소프트웨어 개발은 일반적으로 사악한 문제이다.
방정식 체계를 푸는 것과 같은 길들여진 문제의 경우 문제는 명확한 공식을 갖는다. 사양과 솔루션은 분리될 수 있다. 방정식 체계는 사양이고, 변수에 값을 할당하는 것이 솔루션이다. 이것은 많은 응용 소프트웨어 개발 프로젝트에 대해 사실이 아니다. 예를 들어, 요구 사항 사양이 실제 요구 사항을 지정하지 않을 수 있다. 이것이 제공된 시스템이 사용자의 기대에 미치지 못하기 때문에 많은 프로젝트가 실패하는 이유이다. 프로토타입은 실제 요구 사항을 식별하는 데 도움이 되도록 구성되는 경우가 많다. 이 경우, 프로토타입은 특성뿐만 아니라 구현 방법을 지정하기 때문에 사양과 구현 모두이다. 방정식 체계를 푸는 단계의 수는 유한하다. 각 단계에는 가능한 이동 수가 제한된다. 소프트웨어 설계의 경우에는 그렇지 않으며, 가능한 설계 대안의 수는 설계자의 지식과 창의성에 의해서만 제한된다. 방정식 체계를 푸는 과정은 해결책을 찾으면 중단된다.

그러나 소프트웨어 프로젝트는 팀이 시간, 돈, 인내심이 부족하기 때문에 종료된다. 방정식 체계의 해결책은 즉각적이고 객관적으로 옳고 그름으로 평가될 수 있다.
그러나 소프트웨어 시스템은 좋은 것과 나쁜 것의 관점에서만 평가될 수 있고 그 판단은 평가자의 지식, 경험, 개인의 선호도에 따라 좌우되는 경우가 많다. 이에 비해 많은 소프트웨어 시스템은 평생 테스트 대상이 된다.

길들여진 문제의 해결책은 비슷한 문제를 해결하도록 조정될 수 있지만 응용 소프트웨어 개발 프로젝트는 모두 독특하다. 응용 소프트웨어가 제조가 아니라 개발되거나 맞춤형으로 만들어지는 이유도 여기에 있다. 소프트웨어 개발은 과학적인 과정이 아니다. 다시 말해 많은 결정이 과학적인 것이 아니라 정치적, 경제적으로 내려진다.

예를 들어, 길들여진 문제를 구현하고, 사용하고, 유지하는 것이 더 경제적이기 때문에 최적의 알고리즘 대신 길들여진 알고리즘을 선택한다. 때로는 특정 프로그래밍 언어나 DBMS를 사용하는 선택이 정치적인 결정이 되기도 한다. 저자가 개발 계약한 한 프로젝트에서 클라이언트는 벤더와 좋지 않은 경험을 했다는 이유로 특정 제품을 사용하지 말라고 요청했다. 마지막으로 그리고 중요한 것은 소프트웨어 오류로 인해 수백만 달러의 재산 피해와 인명 피해가 발생할 수 있다는 점이다. 따라서 소프트웨어 개발자는 잘못될 권리가 없다. 길들여진 문제는 이 속성을 공유하지 않는다- 결과가 잘못되면 소프트웨어 개발자는 다시 시도하기만 하면 된다.

5. SOFTWARE PROCESS MODELS

폭포수 프로세스의 문제들로 인해 연구자들과 기금 지원 기관들은 소프트웨어 개발의 사악한 속성들을 고려한 더 나은 프로세스를 찾게 되었다. 대부분의 모델은 엄격하게 순차적인 활동 프로세스가 아닌 반복적인 프로세스를 채택한다.

5.1. Prototyping Process

프로토타이핑 프로세스 모델은 새로 구성된 소프트웨어 시스템과 사용자의 기대 사이의 불일치, 시간 및 예산 제약 내에서 능력을 제공해야 하는 과제를 인식한다. 그 해결책으로 시스템의 프로토타입이 구성되고 요구 사항을 획득하고 검증하는 데 사용된다. 프로토타입은 설계 검증뿐만 아니라 타당성 연구에도 사용된다.

프로토타입은 매우 간단하거나 매우 정교할 수 있다. 간단한 프로토타입은 시스템이 사용자와 어떻게 상호 작용하는지 설명하기 위해 외관과 느낌, 일련의 스크린 샷만 보여준다. 정교한 프로토타입은 시스템 기능의 많은 부분을 구현할 수 있다.
프로토타입은 일반적으로 일회용 프로토타입과 진화용 프로토타입으로 분류된다. 일회용 프로토타입은 목적에 맞게 신속하고 경제적으로 구성된다.
일회용 프로토타입은 구현이 올바른 결과를 산출하는지 확인하기 위한 참조 구현으로 단위 또는 통합 테스트에서 재사용될 수 있다. 더 나아가 시스템이 출시되기 전에 사용자를 교육하는 데 사용될 수 있다.

5.2. Evolutionary Process

프로토타입은 설계 아이디어의 요구사항 획득, 요구사항 검증, 타당성 조사 및 검증에 도움을 준다. 그러나 일회용 프로토타입은 많은 노력이 낭비된다. 이는 대규모 실시간 임베디드 시스템의 타당성 조사 및 설계 검증을 위해 정교한 프로토타입이 필요한 경우에 해당된다.

진화 프로세스 모델은 프로토타입이 진화하도록 함으로써 이 문제를 해결하는 것을 목표로 한다.

일련의 예비 요구사항에 따라 구성된 초기 프로토타입을 사용자가 실험할 수 있도록 한다. 사용자의 피드백은 프로토타입을 진화시키는 데 사용된다.
이 프로세스는 더 이상의 확장이 필요하지 않을 때까지 반복된다.
이러한 이유로 진화 프로토타입 제작 프로세스 모델이라고도 한다.
프로토타입이 일회용 프로토타입이 아니기 때문에 운영 기능성과 필요한 견고성을 가지고 구성된다.

진화 프로세스는 시스템 작업을 통해 정확한 요구사항과 알고리즘을 발견해야 하는 탐색적 유형의 프로젝트에 가장 적합하다.
지능형 시스템, 유전자 시퀀싱과 같이 알려지지 않은 것을 발견하는 것을 목표로 하는 연구 소프트웨어뿐만 아니라 환경과 적극적으로 상호 작용하는 임베디드 시스템을 포함하여 많은 실제 프로젝트가 이 범주에 속한다.
진화 프로세스는 예측 가능한 진행 일정이 필요한 프로젝트에는 적합하지 않다.

5.3. Spiral Process

나선형의 각 사이클은 개발 중인 시스템의 특정 측면, 예를 들어 기능성, 성능 또는 품질을 향상시키는 것을 목표로 한다. 이러한 의미에서, 시스템은 모델이 나선형 사이클을 반복함에 따라 점진적으로 진화한다.

나선형의 각 사이클은 다음 단계 중 일부를 선택적으로 실행한다:

1. 현재 사이클에 대한 목표, 대안 및 제약 조건(나선형의 북서쪽 모서리)을 결정한다. 이 단계에서는 목표, 목표를 달성하기 위한 대안적 접근 방식 및 충족해야 하는 제약 조건을 식별한다. 프로젝트 위험 항목을 식별하고 우선순위를 정한다.

2. 대안을 평가하고, 위험(나선형의 북동쪽 모서리)을 식별하고 해결한다. 제약 조건 내에서 목표를 달성하기 위한 대안을 평가한다. 목표를 달성하지 못할 경우의 위험을 식별하고 위험을 해결할 수 있는 방법을 개발한다. 위험 해결을 위한 기술로는 프로토타이핑, 시뮬레이션, 모델링 및 벤치마킹이 있다.

위험 분석 및 해결 결과에 따라 다음 단계는 다음 단계 중 하나일 수 있다:

· 남은 위험이 있는 경우 다음 단계는 남서쪽 모서리, 즉 다음 단계의 프로토타이핑을 계획한 다음 새로운 프로토타이핑 사이클이 될 것이다.
· 이전 사이클에서 알려진 주요 위험이 해결되었다면 모델의 남동쪽 모서리에서 보는 바와 같이 후속 단계는 폭포처럼 진행될 수 있다.
· 이전 라운드에서 생산된 프로토타입이 운영 가능하고 최종 시스템으로 진화할 수 있을 정도로 견고하다면, 후속 단계는 진화 프로토타이핑 모델에서와 같이 프로토타입을 확장하여 사용한다. 즉, 북동쪽 모서리의 오른쪽을 향해 진행한다.

3. 다음 레벨 시스템(남동쪽 모서리)을 개발하고 검증한다.

4. 다음 단계(남서쪽 모서리)를 계획한다. 새로운 이니셔티브 또는 계속 프로젝트에 대해 이 단계는 요구 사항, 라이프 사이클 활동, 다음 단계의 통합 및 테스트 계획을 정의한다.

5.4. The Unified Process

합리적 통합 프로세스 또는 통합 프로세스(UP)는 일련의 사이클로 구성된다.
각 사이클은 시스템의 릴리스로 끝난다. 각 사이클은 여러 번의 반복을 갖는다.

반복은 Inception, Elaboration, Construction 및 Transition 4단계로 그룹화된다. 각 단계는 주요 마일스톤으로 끝난다. 각 단계는 프로젝트를 계속하거나 종료할 것으로 관리자가 중요한 프로젝트 결정을 내린다.

각 반복은 요구사항 분석, 설계, 구현 및 테스트를 포함한 일련의 워크플로우 활동을 거친다.

Inception. 처음 한 번 또는 두 번의 반복이 시작 단계를 구성한다. 이 단계는 단순화된 사용 사례 모델, 잠정적인 소프트웨어 아키텍처 및 프로젝트 계획을 생성한다. 간단한 용어로 사용 사례는 시스템이 개발되는 애플리케이션의 비즈니스 프로세스를 모델링한다. 동사-명사구가 사용 사례를 설명하는 데 사용된다. 예를 들어, 예치금, 인출금 및 수표 잔액은 자동화기기(ATM)의 사용 사례이다. 사용 사례 모델은 소프트웨어 시스템의 가장 중요한 사용 사례를 포함한다.

Elaboration. 정교화 단계는 다음 몇 번의 반복으로 구성된다. 이 단계 동안, 대부분의 사용 사례가 지정되고 아키텍처 설계를 나타내는 UML 다이어그램이 생성된다. 소프트웨어 시스템의 가장 중요한 사용 사례가 설계 및 구현된다.

Construction. 구축 단계 동안, 나머지 사용 사례는 반복적으로 개발되고 시스템에 통합된다. 시스템은 대상 환경에 점진적으로 설치될 수 있다.

Transition. 전환 단계 동안, 소프트웨어 시스템을 배포하기 위한 활동이 수행된다. 여기에는 사용자 교육, 베타 테스트, 결함 수정 및 기능 향상이 포함된다.

UP은 사용 사례를 식별하는 데 중점을 두고 시스템을 개발하고 배포하기 위한 반복을 계획하는 데 사용한다. 이러한 의미에서 UP은 Use case driven이라는 특징을 갖는다.

UP은 생애주기 초기에 시스템의 아키텍처나 전체적인 구조를 결정하고, 이를 소프트웨어 시스템의 개발을 안내하는 데 사용한다. 이러한 이유로 UP은 아키텍처 중심적이라고 한다. UP의 다른 두 가지 특징은 시스템이 반복적이고 점진적으로 개발되고 배치되기 때문에 반복적이고 점진적이라는 점이다.

5.7. Agile Processes

애자일 프로세스는 팀워크, 사용자와의 공동 응용 프로그램 개발, 변화를 위한 설계, 짧은 반복에서 작은 증분의 신속한 개발과 빈번한 전달을 강조한다.

Agile Manifesto

1. 애자일은 프로세스 및 도구에 대한 개인과 상호 작용을 중요시한다.
   기존의 계획 중심적 관행은 소프트웨어 프로젝트의 성공을 위해 좋은 소프트웨어 프로세스가 필수적이라고 믿는다. 하나의 통념은 "소프트웨어 품질은 소프트웨어 프로세스만큼 좋다"이다. 통념이 여전히 장점이 있지만, 경험에 의하면 팀워크뿐만 아니라 팀원들의 능력이 더 중요하다. 결국 소프트웨어 프로세스를 수행하는 것은 팀원들이다. 팀원들이 설계하는 방법을 모르거나 서로 효과적으로 의사소통을 하지 못한다면 결과는 좋지 않을 것이다. 기존 관행은 도구 사용에 상당한 비중을 둔다. 이러한 이유로 많은 기업들이 개발 도구와 환경에 막대한 투자를 한다. 일부 도구는 훌륭하고 의도한 문제를 해결한다. 그러나 이것들은 방법을 아는 적절한 사람들만 수행할 수 있다. UML 다이어그램 편집기는 소프트웨어 엔지니어가 OO 설계를 수행하는 방법을 모르더라도 도움이 되지 않는다. 편집기가 멋지게 보이는 UML 다이어그램을 작성하지만 반드시 좋은 설계는 아니다. 애자일 방법은 기존 관행과 달리 개인과 팀 작업에 가치를 둔다.
   소프트웨어는 개념적인 제품이고 개발 활동은 매우 지적이기 때문이다. 팀원들이 함께 소프트웨어 제품을 공동으로 구축해야 한다면, 프로젝트의 성공에 팀원들이 상호 작용하고 공동 노력에 기여할 수 있는 능력은 필수적이다. 소프트웨어 프로세스와 도구도 물론 중요하지만, 개인과 상호 작용은 필수적이다.

2. 애자일은 포괄적인 문서화보다 작동하는 소프트웨어를 중요시한다.
   수년 또는 수십 년 동안, 기업들은 분석 및 설계 문서를 준비하는 데 엄청난 노력을 기울인다. 이는 부분적으로는 표준 감사 때문이기도 하고, 부분적으로는 "좋은 소프트웨어는 좋은 설계 문서화에서 나오고, 좋은 설계 문서화는 좋은 분석 모델에서 나온다"는 믿음 때문이기도 하다. 이러한 믿음은 사실이지만 부분적으로만 그렇다. 많은 소프트웨어 엔지니어들은 어떤 경우에는 코드가 작성되고 테스트될 때까지 실제 요구 사항 또는 설계가 작동하는지 여부를 결정하는 것이 불가능하다는 것을 경험했다. 이러한 경우에, 포괄적인 문서화는 작동하는 해결책이 발견된 것 같은 착각을 일으키기 때문에 도움이 되지 않고 해로울 수 있다. 포괄적인 문서화는 코딩 및 테스트에 사용할 수 있는 시간이 적다는 것을 의미하기도 하는데, 이러한 경우에는 실제 요구 사항과 필요한 설계를 식별하는 유일한 수단이다. 예를 들어, 대기업의 재고를 최적화하는 소프트웨어를 생각해 보자. 재고는 지난 수십 년 동안 다양한 직원이 작성한 수백만 개의 항목에 대한 텍스트 설명으로 구성된다. 수많은 인수 및 합병 활동은 항목, 항목의 범주, 설명 형식 및 스타일의 수를 상당히 증가시킨다. 소프트웨어는 재고 설명을 처리하는 데 필요하다. 목표는 재고를 단순화하고 재고 비용을 줄이는 것이다. 소프트웨어에 대한 요구 사항은 분명히 소프트웨어가 이 목표를 달성하기 위해 할 수 있는 일이다. 그러나 소프트웨어를 구현하지 않으면 소프트웨어가 무엇을 달성할 수 있는지 아무도 정확히 알 수 없다. 이는 사악한 문제의 예로, 사양과 구현이 분리될 수 없다. 소프트웨어를 구현할 필요 없이 요구 사항이 어떻게든 식별되었다고 가정해 보자. 그러면 데이터 구조 및 알고리즘의 설계는 알고리즘이 작동하는지, 어느 정도까지 작동하는지를 알기가 매우 어렵기 때문에 큰 과제이다. 재고 설명의 다양성, 불일치, 불완전한 항목, 오타 및 축약어 변형으로 인한 것이다. 시행착오 접근 방식이 더 적절해 보인다. 애자일 방법은 작동 소프트웨어가 최종 결과이기 때문에 작동 소프트웨어를 중요시한다. 결국, 개발팀은 작동 소프트웨어를 고객에게 전달해야 한다. 소프트웨어 시스템이 요구하는 기능을 전달하는지 확인하기 위해 작동 소프트웨어만 테스트할 수 있다. 이러한 의미에서 작동 소프트웨어가 요구 사항이며, 그 반대도 마찬가지이다. 위에서 논의한 재고 설명 분류 프로젝트가 이를 잘 보여준다. 그러나 이러한 논의가 애자일 방법이 분석 및 설계를 원하지 않는다는 결론으로 이어져서는 안 된다. 이와 반대로 애자일 방법은 분석 및 설계 모델을 구성한다. 그럼에도 불구하고 애자일 원칙은 문제를 이해하고 설계 아이디어를 전달하는 데 도움이 될 수 있을 정도의 모델링만 옹호할 뿐 그 이상은 아니다.

3. 애자일은 계약 협상에 대한 고객의 협업을 중요시한다.
   기존 프로세스에는 고객이 원하는 것이 무엇인지 식별하기 위해 계약 협상 단계가 포함된다. 그러면 요구 사항 사양이 생성되고 계약의 일부가 된다. 개발 과정에서 고객은 몇 가지 설계 검토 및 수락 테스트에 참여할 뿐이다. 고객과 함께 이루어져야 하는 많은 중요한 설계 결정은 개발팀에 의해 이루어진다. 개발팀이 기술적 의사결정은 잘 하지만 고객을 위해 의사결정을 내릴 지식과 배경을 가지고 있지 않을 수 있다. 예를 들어, 하나 이상의 DBMS를 지원해야 하는 요구사항은 어떤 DBMS를 지원해야 하는지를 명시하지 않을 수 있다. 기술적으로 팀은 어떤 DBMS가 가장 우수하고 지원해야 하는지 알 수 있다. 그러나 고객은 다른 요소들을 더 중요하게 생각할 수 있다. 여기에는 DBMS의 유형을 유지하는 IT 직원의 능력, 이러한 시스템을 도입하는 데 드는 비용, 기존 시스템과의 호환성이 포함된다. 개발팀이 고객을 위해 이러한 의사결정을 내린다면 결과적인 시스템은 고객의 비즈니스 요구사항을 충족시키지 못할 수 있다. 프로젝트의 성공을 위해서는 고객 협업이 필수적이다. 팀과 고객 간의 의사소통과 상호 이해를 향상시킨다. 의사소통의 향상은 실제 요구사항을 식별하고 요구사항이 잘못 이해될 가능성을 줄이는데 도움이 된다. 상호 이해는 위험 공유를 의미하므로 프로젝트 실패 확률을 줄여준다. 많은 프로젝트에서 시스템의 정확한 결과, 설계 결정 또는 알고리즘은 예측하기 어렵거나 불가능하다. 이러한 경우에 고객 협업은 매우 중요하다. 상호 이해는 개발팀이 고객의 비즈니스 영역, 운영, 과제 및 우선순위를 잘 이해하고 있음을 의미한다. 이는 팀이 고객의 비즈니스 요구사항을 충족시키기 위해 시스템을 설계하고 구현할 수 있도록 한다. 상호 이해는 또한 고객이 비즈니스 솔루션을 구현할 수 있는 수단을 제공하는 기술의 한계를 이해한다는 것을 의미하며, 기술만으로는 비즈니스 문제를 해결할 수 없다. 고객은 개발팀의 한계를 이해할 필요가 있으며, 이는 저자의 다음 경험에서 알 수 있다. 한 고객은 저자가 이것이 불가능하다고 지적했음에도 불구하고 한 달 안에 중간 크기의 소프트웨어 제품을 생산해야 한다고 주장했다. 시간 부족뿐만 아니라 자격을 갖춘 개발자의 부족도 또 다른 과제였다. 6개월이 지난 지금도 팀은 제공하지 못했고, 프로젝트는 실패했다. 이 이야기에서 고객은 한 달 안에 시스템을 원했지만, 시스템이 완전히 새로운 일련의 혁신적인 비즈니스 아이디어를 구현해야 했기 때문에 이 요구를 충족시킬 수 있는 팀은 없었다. 고객과의 협업은 프로젝트를 구할 수도 있다. 예를 들어, 양 당사자는 서로의 우선 순위와 한계를 이해하고 혁신적인 기능을 점진적으로 실행하기 위한 현실적인 애자일 개발 계획을 수립할 수 있다.

4. 애자일은 계획을 따르는 동안 변화에 대응하는 것을 중요시한다.
   기존 관행은 변화에 비용이 많이 들기 때문에 "변화 통제"를 강조한다. 요구 사항 사양과 같은 인공물이 완성되면 이후의 변화는 엄격한 변화 통제 프로세스를 거쳐야 한다. 그 프로세스는 팀이 변화 요청에 대응하는 것을 방해한다. 애자일 방법론은 계획을 따르는 동안 변화에 대응하는 것을 중요시한다. 오늘날 급변하는 세상에서 모든 비즈니스는 생존하거나 성장하기 위해 비즈니스 조건의 변화에 신속하게 대응해야 한다. 따라서 소프트웨어로의 변화는 불가피하다. 인터넷 기술의 발전은 기업이 웹 애플리케이션을 빠르고 자주 업데이트해야 할 뿐만 아니라 가능성도 있다. 편리하고 계획 중심적인 관행의 유연성은 이러한 애플리케이션의 요구를 충족시킬 수 없다.

Agile Princicple

1. 적극적인 사용자 참여는 필수적이다.
   많은 애자일 방법에 의해 적극적인 사용자 참여가 요구된다. 이는 실제 요구 사항을 식별하는 것이 많은 소프트웨어 개발 프로젝트에서 가장 어려운 부분이기 때문이다. 기존의 접근 방식은 요구 사항 분석에 전체 개발 노력의 15%-25%를 사용한다. 그들은 요구 사항을 동결하기 위해 엄격한 변경 제어를 구현한다. 이것들은 문제를 해결하는 것으로 보이지 않는다. 시간이나 노력의 부족이 아니다. 인간이 개발 프로세스의 초기 단계에서 실제 요구 사항을 알 수 없는 것이다. 더욱이 세상은 변화하고 있으므로 요구 사항은 진화해야 한다. 적극적인 사용자 참여는 사용자 커뮤니티의 대표자가 개발 팀과 필요에 따라 밀접하고 자주 상호 작용하는 것을 의미한다. 예를 들어, 잘 아는 두 명의 사용자 대표자가 프로젝트에 할당된다. 그들은 팀에 머물며 일하거나 일주일에 몇 번씩 정기적으로 팀을 방문한다. 이러한 배치는 팀과 사용자 간의 의사 소통과 이해를 크게 향상시킨다. 이는 차례로 요구 사항 오개념이 조기에 수정되고 사용자의 피드백이 적절하고 시기적절하게 처리되며 시스템에 대한 의사 결정이 사용자와 함께 이루어지도록 한다. 이 모든 것은 실제 요구 사항이 식별되고 우선 순위가 지정되며 시스템이 사용자의 기대에 맞게 구축됨을 의미한다.

2. 팀은 의사 결정을 내릴 수 있는 권한을 부여받아야 한다.
   애자일 개발은 개인과 프로세스 및 도구에 대한 상호 작용을 중시한다. 이 원칙은 이를 실현한다. 즉, 팀 구성원이 의사 결정을 내리고 책임과 소유권을 갖도록 요구되고 권장된다. 이를 수행할 수 있기 위해서는 팀 구성원이 팀으로 작업하고 프로젝트 전반에 걸쳐 서로 및 사용자와 상호 작용할 것이 요구된다.

3. 요구 사항은 진화하지만 시간 척도는 고정되어 있다.
   요구 사항을 동결하는 기존의 접근 방식과 달리 민첩한 프로세스는 변화를 환영하도록 설계되었다. 이 원칙은 작업 범위는 요구 사항 변경에 대처하도록 진화하도록 허용되지만 합의된 시간 프레임과 예산은 고정되어 있음을 의미한다. 이는 새로운 요구 사항이나 수정된 요구 사항은 다른 요구 사항의 비용으로 수용된다는 것을 의미한다. 즉, 추가적인 노력은 미션 크리티컬하지 않은 다른 요구 사항을 포기함으로써 보상된다.

4. 높은 수준의 요구 사항 캡처; 가볍고 시각적.
   민첩한 개발은 포괄적인 문서화보다 작업 소프트웨어를 중요하게 생각한다. 결국, 결론은 분석 및 설계 문서화가 아니라 운영 시스템을 전달하는 것이다. 이를 달성하기 위해 민첩한 방법은 사용자 이야기, 기능 또는 작은 크기의 스토리 카드에 작성된 사용 사례로 요구 사항을 거의 캡처하지 않는다. 이는 스토리보드 또는 스크린샷, 스케치 또는 기타 시각적 수단을 사용하여 시각화되어 사용자가 시스템과 어떻게 상호 작용하는지 보여준다. 이러한 기술은 무거운 문서화를 피하고 스토리 카드와 스토리보드를 공유하고 조작하기 쉽기 때문에 요구 사항을 변경하고 트레이드오프하는 것을 쉽게 만든다.

5. 점진적으로 작은 릴리스를 개발하고 반복해라.
   애자일 프로젝트는 사용 사례, 사용자 이야기 또는 특징을 반복적으로 전달하기 위해 시스템을 아주 작은 크기로 개발하고 배포한다. 이 배열은 한 번에 여러 개의 텍스처를 가지며 사용자가 피드백을 제공하는 것이 더 쉽고 작은 증분은 프로젝트 실패의 위험을 줄인다.

6. 소프트웨어 제품의 빈번한 제공에 집중해라.
   애자일 프로세스는 소프트웨어 시스템을 작은 증분으로 자주 제공한다는 점에서 나선형 프로세스 및 통합 프로세서와 다르다. 서로 다른 애자일 방법은 매일에서 3개월에 이르는 서로 다른 반복 길이를 제안한다. 예를 들어, 동적 시스템 개발 방법(DSDM)은 2~6주를 제안하는 반면 극한 프로그래밍(XP)은 1~4주를 사용한다. 스크럼의 반복은 스프린트라고 하며 일반적으로 30일로 설정한다.

7. 다음 단계로 넘어가기 전에 각 기능을 완료해라.
   이 원리는 각 기능이 다음 단계로 넘어가기 전에 100% 구현되고 철저하게 테스트해야 함을 의미한다. 여기서 해결해야 할 문제는 기능이 철저히 테스트되었는지 어떻게 알 수 있는가 하는 것이다. 테스트 기반 개발(TDD) 및 테스트 커버리지 기준은 솔루션을 제공한다. TDD는 각 기능에 대한 테스트를 구현하기 전에 작성해야 함을 요구한다.

8. 80-20 규칙을 적용해라.
   이 규칙은 작업 또는 결과의 80%가 시스템 기능의 20%에 의해 생성된다는 믿음에 기초한다. 따라서 작업 또는 결과의 80%를 산출할 요구사항 중 20%에 우선순위를 부여해야 한다. 이 원칙은 개발 팀에게 고객과 사용자에게 그러한 요구사항을 파악하고 우선순위를 정하도록 지시하도록 조언한다. 이 규칙은 팀원들에게 최종 추가 마일과 관련된 수익 감소를 상기시키기도 한다. 이는 좋은 기능, 실제로 필요하지 않은 성능 최적화 등에 적용된다. 예를 들어, 더 간단한 알고리즘이 처리할 데이터만큼 충분히 빠르면 최적의 알고리즘은 추가적인 구현 노력을 할 가치가 없을 수 있다.

9. 테스트는 프로젝트 라이프 사이클 전체에 걸쳐 통합되며, 조기에 그리고 자주 테스트된다.
   이 원칙과 5-7 원칙은 상호 보완적이다. 즉, 테스트는 시스템의 완전히 구현된 작은 증분을 자주 전달하는 데 필수적인 부분이다. 자바 클래스 단위 테스트 및 회귀 테스트 도구인 JUnit와 같은 테스트 도구는 이 원칙을 뒷받침한다. 이러한 도구를 사용하면 프로그래머는 테스트할 기능을 호출하는 방법과 테스트 결과를 평가하는 방법을 지정해야 한다. 이 도구는 테스트를 생성하고, 테스트를 실행하고, 테스트 결과를 자동으로 확인한다. 테스트는 원하는 만큼 자주 실행될 수 있다.

10. 모든 이해관계자 간의 협업 및 협력적 접근은 필수적이다.
    기존의 접근 방식은 요구사항을 개발팀에 전달하기 위해 포괄적인 문서화에 의존한다. 민첩한 프로젝트는 요구사항을 높은 수준과 가벼운 무게로 포착한다. 따라서 개발팀과 고객 대표 및 사용자 간의 협업 및 협력이 필수적이다. 당사자는 서로를 이해하고 라이프 사이클 전체에 걸쳐 협력하여 요구사항을 파악하고 진화해야 한다. 새로운 시스템은 사용자의 업무 습관 및 성과를 크게 변화시키거나 영향을 미칠 수 있기 때문에 프로젝트의 성공을 위해서는 팀과 사용자 간의 협업 및 협력이 필수적이다.