Lecture 03: 소프트웨어 공학과 개발 프로세스 - 2

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

소프트웨어 개발 생명주기 모델

소프트웨어 개발 생명주기 모델

Plan and Document

• 선형 순차적 모델 ex) 폭포수 모델, V 모델
• 진화적 프로세스 모델 ex) 프로토타입 모델, 나선형 모델
• 단계적 개발 모델 ex) 점증적 개발 모델
• 일정 중심 설계 모델

No Document

• 주먹 구구식 모델
• 애자일 프로세스 모델

※ Document는 각각의 단계에서 만든 산출물로, 그 산출물을 보며 잘 됐는지 검토하는 용도이다. 하지만, 애자일 프로세스는 빠르게 사이클을 돌고 사용자와 적극적으로 만나고, 미팅을 자주하는 걸 목적으로 하다보니 속도가 생명이기에 Documnet를 만들지 않는다.

주먹 구구식 모델

주먹 구구식 모델

공식적인 가이드라인이나 프로세스가 없는 개발 방식으로,

증흥적 소프트웨어 (간단한 소프트웨어) 개발 또는 코딩과 수정 모델이다. (Build and fix 또는 Code and fix)

 

코드를 작성해 제품을 만든 후에 요구 분석, 설계, 유지보수에 대해 생각한다.

즉, 우선 제품을 완성한 뒤 코드에 문제가 있으면 수정하고 문제가 없으면 그대로 사용한다.

▶ 주먹 구구식 모델

 

※ 반려동물 집 집기로 비유할 수 있다.

 

장점

• 심플하다.

단점

• 정해진 개발 순서나 각 단계별로 문서화된 산출물이 없어, 관리 및 유지보수가 어렵다.
• 문제 범위를 정하지 않기에 프로젝트 전체 범위를 알 수 없고 좋은 아키텍처를 만들 수 없다. (소프트웨어 위기 파악 불가)
• 대규모 프로젝트에서는 불가능한 방식이다.
• 코딩을 먼저 하면 계속 수정할 가능성이 높아, 여러 번 수정하다 보면 가독성이 낮은 구조로 돼 수정이 어려워질  수 있다.

선형 순차적 모델 (폭포수 모델)

선형 순차적 모델 (Linear Sequential Model, 폭포수 모델)

일반적으로 폭포수 모델로 알려져 있다. (고전적 생명 주기)

 

이러한 폭포수 모델은 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델로, (이전 단계로 돌아갈 수 없음)

요구사항이 확정되어 변동이 없는 소규모 프로젝트에 적합하다.

 

계획, 요구분석, 설계, 구현, 테스트, 유지보수 단계가 하향식으로 진행되며,

단계의 종료마다 확실하게 작업을 종료하고, (이때 문서화 강조)

그 결과를 확인한 뒤 다음 단계로 내려간다. (각 단계가 다음 단계 시작 전에 끝나야 함)

▶ 선형 순차적 모델 (= 폭포수 모델)

 

1. 계획

• 다음 질문의 대답을 찾는 단계 ex) 예산? 기간? 몇 명 필요? 무엇이 잘못될 수 있는지? (위험 분석)
• 범위 정하기
• 산정 (Estimation) (돈, 법률적으로 문제가 없는지)
• 리스크 분석
• 일정 계획

2. 요구 분석

• 요구: 시스템이 가져야 할 능력(Capability)과 조건(Condition)
• What의 단계 (사용자 -> 무슨 기능 추가)
• 가장 중요하고 어려운 단계 (조그만 차이가 큰 오류를 범함)
• 결과물: 요구 분석서

▶ 요구 분석 때 잘못되면 계속 누적되어 나중엔 오류가 커질 수 밖에 없다.

▶ 요구 분석 예시

 

※ 요구사항은 위 그림처럼 많기에 다 읽을 수 없어, 이 use case diagram을 통해 체계화한다.

 

3. 설계

• How의 단계
• 솔루션에 집중 (요구 분석의 솔루션)
• 아키텍처 설계
• 데이터베이스 설계
• UI 설계
• 결과물: 설계서

▶ 아키텍처 설계

▶ UI 설계

 

4. 구현 (코딩)

• 'Do it'의 단계

5. 테스트

• 모듈(함수)을 통합하면서 점진적으로 테스트 (테스트 순서: 작은 함수 테스트 -> 전체 코드 테스트)
• 코딩은 개발자가 주로 담당 / 테스트는 테스트팀이 따로 담당

※ 작은 것부터 테스트하고 점차 전체로 확장하는 이유는, 전체에서 오류가 발생을 하면 어디에서 오류가 발생하였는지 알 수 없기 때문이다. 

 

6. 유지보수

• 결함을 고침
• 새 기능(요구사항) 추가
• 성능 추가

특징

• 순서적: 각 단계 사이에 중복이나 상호작용이 없다.
• 각 단계의 결과는 다음 단계가 시작되기 전에 점검한다.
• 단순하거나 응용 분야를 잘 알고 있는 (노하우) 경우 적합하다. (한 번의 과정, 비전문가가 사용할 시스템 개발에 적합)

※ 소프트웨어 개발 생명 주기의 가장 기본적인 모델이다.

 

장점

• 절차가 단순하여 이해하기 쉽다. (초보자도 쉽게 적용 가능)
• 단계별 진척상황에 대한 관리가 용이하다.
• 각 단계별 산출물이 명확하여, 체계적으로 문서화할 수 있다.

단점

• 각 단계는 이전 단계가 완료되어야 수행되기에 각 단계에서 사용자의 요구사항을 반영할 수 없다. (요구분석 단계는 제외)    ex) 설계 단계: 요구사항 정의서가 나와야 시작한다.
• 각 단계 결과물이 완벽한 수준이 되어야 다음 단계에 오류를 넘겨주지 않는데, 앞 단계가 지나치게 강조되면 코딩, 테스트가   지연될 수 있다.
• 사용자가 중간에 가시적인 결과를 볼 수 없기에 상상으로만 요구 분석을 해야 하기에, 테스트 후 새로운 요구 사항이 생길 수 밖에 없는데, 이때 사용자의 수정 요구 사항을 반영하기 위해 시간과 비용이 많이 든다. (가장 큰 문제)
• 최근의 소프트웨어 개발은 요구사항이 끊임없이 변화하기에, 최근에는 폭포수 모델은 거의 사용되지 않는다.

선형 순차적 모델 - V 모델

선형 순차적 모델  - V 모델

폭포수 단계와 동일한데, 여기에 테스트 단계를 추가한 폭포수 모델의 변형으로,

각 개발 단계를 검증하는데 초점을 맞춰 오류를 줄일 수 있다. (vs. 폭포수 모델은 산출물 중심)

 

따라서 신뢰성이 높이 요구되는 분야에 적용할 수 있다.

▶ V 모델

• 단위 테스트: 각 모듈이나 함수가 개별적으로 잘 작동하는지 확인하는 소단위 테스트
• 통합 테스트: 여러 모듈이나 함수가 함께 연결될 때 아키텍처에 문제가 없는지 확인하는 테스트 (인터페이스 확인)
• 시스템 테스트: 완성된 시스템이 사용자의 요구사항에 맞게 작동하는지 확인하는 테스트
• 인수 테스트: 최종 제품을 실제 검증하는 테스트

장점

각 개발 단계를 검증에 초점을 맞춰 오류를 줄일 수 있다. (테스트가 많음)

신뢰성이 높이 요구되는 분야에 적용 가능하다.

 

단점

폭포수 모델과 유사하게 각 단계가 반복되지 않아 변경을 다루기 쉽지 않다.

폭포수 모델과 유사하게 테스트 작업이 프로젝트 후반(코딩이 완료된 후)에 시작이 된다.

진화적 프로세스 모델

진화적 프로세스 모델

폭포수 모델은 단계를 거슬러 올라가 작업하는 것이 쉽지 않다는 단점이 있었는데, (사용자의 새로운 요구사항 받아들일 수 없음)

이러한 폭포수 모델의 단점 해결을 위해 등장하였다. (등장배경)

 

때문에, 주로 요구분석 단계를 고려한 모델이라고 할 수 있다.

 

현실에선 새로운 요구가 수시로 발생하는데,

진화적 프로세스 모델은 개발 과정 중 새로운 요구가 발생해도 이에 민첩하게 대응할 수 있는 방법이다.

 

ex) 총 쏘는 기능(기존 요구사항)에 추가로 총 던지는 기능(새로운 요구사항)을 추가해 주세요.

 

모델 단계

1. 초기의 사용자 요구에 따라 초기 버전의 프로토타입 개발

2. 이를 바탕으로 나타나는 가상의 결과 화면을 관찰

3. 변경된 요구 사항을 반영/추가해 지속적인 프로토타입 개선 (프로토타입 모델)

4. 추가로 프로토타입에 위험 분석 단계 추가가 가능 (나선형 모델)

▶ 진화적 프로세스 모델

 

※ 프로토타입: 대량 생산에 앞서 미리 제작해 보는 원형 또는 시제품

진화적 프로세스 모델 - 프로토타입 모델

진화적 프로세스 모델 - 프로토타입 모델

사용자의 요구사항을 충분히 분석할 목적으로 개발된 모델로, (사용자 중심 모델)

시스템의 일부분을 시험적으로 구현하고,사용자의 피드백을 받아 다시 요구사항에 반영하는 과정을 반복하는 개발 모델이다.

 

하지만, 프로토타입 모델은 설계 이후의 과정에서는 반복이 이루어지지 않는다.

 

▶ 프로토타입 모델

 

주의할 점

• 프로토타입은 완전한 설계가 중요한 것이 아니라, 사용자와 대화할 수 있는 수준의 설계가 필요한 것이다.
• 입출력 화면을 통해 사용자 인터페이스 중심으로 설계를 진행한다.
• 완전히 동작하는 완제품을 개발하는 것이 아니다.
• 출력 결과를 통해 사용자가 원하는 것인지 확인한다.

장점

• 사용자의 요구가 지속적으로 발생하는 경우에 적합하다.
• 프로토타입은 기능이 부족하더라도 가시적이기 때문에 의사소통 도구로 활용이 가능하다.
• 프로토타입 사용을 통해 완성품의 예측이 가능하다.
• 사용자의 요구가 충분히 반영되어 최종 제품이 나오므로, 유지보수에 필요한 노력과 시간을 많이 줄일 수 있다.

단점

• 반복적인 개발 단계로 인해 필요한 투입 인력과 비용산정이 어렵다.
• 개발자 입장에서 프로토타이핑 과정을 관리/통제가 어렵고, 개발 범위가 명확하지가 않아 언제 종료될지 모른다.
• 사용자 입장에서 오해, 기대심리를 유발할 수 있다.

※ 프로토타입: 더미 소프트웨어로, 실행 가능한 소프트웨어가 아닌 인풋, 아웃풋 개념만 있는 가시적인 결과물일 뿐이다.

프로토타입 모델 vs. 폭포수 모델

요구사항 정의 분석

• 폭포수 모델: 요구사항을 완전하게 명세한 후 다음 단계로 넘어 감
• 프로토타입 모델: 다양한 요구사항을 반복적으로 수용하여 완성도를 높여 최종 프로토타입을 개발

프로토타입 설계 및 개발

• 폭포수 모델: 완성된 요구사항을 바탕으로 설계 및 개발
• 프로토타입 모델: 완제품을 보여주는 것이 아니라, 출력 결과가 사용자가 원하는 것인지 보여주기 위해 설계 및 개발

사용자에 의한 평가

• 폭포수 모델: 테스트 과정에서 평가가 이루어지지 않음
• 프로토타입 모델: 반복된 프로토타입을 기반으로 평가가 이루어짐 (요구분석 때)

※ 프로토타입 모델과 폭포수 모델의 공통점으론, 요구 분석이 끝난 후 설계로 넘어가면 다시 돌아올 수 없다는 점이 있다.

진화적 프로세스 모델 - 나선형 모델

진화적 프로세스 모델 - 나선형 모델

시스템 개발시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델로,

대규모 프로젝트, 국책사업 및 위험 부담이 큰 시스템 개발에 적합하다.

 

진행 순서: 요구분석 -> 위험분석 -> 개발 -> 평가

 

※ 프로토타입 모델은 사용자의 요구를 그대로 받지만, 나선형 모델은 사용자의 요구를 정말 들어줘도 되느냐 하는 위험분석을 통해 들어줘도 된다/안 된다, 이런 식의 판단을 한다.

▶ 나선형 모델

 

1. 요구분석

• 고객의 요구사항 분석 및 타당성 검토, 프로젝트 수행 여부 결정
• 각 단계에 대한 목표 수립, 이때 목표는 본 cycle 안에서 완수되고 새로운 cycle이 진행되면 변경되는 목표임

2. 위험분석

• 프로젝트 진행시 고객 요구사항을 기반으로 예측되는 위험 사항에 대해 분석
• 위험 사항 ex) 개발자의 이직, 요구사항 변경, 개발 기간의 부족, 개발비의 초과

3. 개발

• 위험 분석 완료 후, 구축하려고 하는 시스템과 개발 환경에 맞는 개발 모델 선택

4. 평가

• 사용자 평가 단계는 중요한 단계
• 고객이 평가 후, 추가 반복에 대한 여부를 결정
• 고객의 추가 및 수정 요청 반영

장점

• 위험 분석 단계가 존재하기에, 개발 후반에 갑작스럽게 발생하는 위험으로 인해 프로젝트가 중단되는 사태가 비교적 적다.
• 사용자 요구를 충분히 반영한다.
• 반복적인 개발 및 테스트로 강인성이 향상된다.
• 한 사이클에 추가 못한 기능은 다음 단계에서 추가가 가능하다.
• 대규모 시스템 개발에 적합하다. (Risk reduction 메커니즘)

단점

• 요구분석, 위험분석, 개발, 사용자 평가가 반복적으로 진행되기 때문에 프로젝트 기간이 길어질 수 있다.
• 반복 횟수가 많아질 수 있어 프로젝트 관리가 어렵다.
• 위험 관리가 중요한 만큼, 위험 관리 전문가가 필요하다.

단계적 개발 모델

단계적 개발 모델

개발자가 먼저 릴리즈1을 개발하고 사용자에게 제공하여 이를 사용하게 한다.

이렇게 사용자가 릴리즈1을 사용하는 동안 개발자는 릴리즈 2를 개발한다. (사용자 중 모델보다 개발자 친화적)

 

단계적 개발 모델은 이런 식으로 개발과 사용을 병행하는 과정을 반복하는 모델로,

개발 사이클이 짧은 환경에 적합하다. (빠른 시간에 출시해야 이윤에 직결)

 

ex) 업데이트

▶ 단계적 개발 모델

단계적 개발 모델 - 점증적 개발 모델

단계적 개발 모델 - 점증적 개발 모델 (Incremental)

점증적 개발 모델은 중요하다고 생각되는 부분부터 개발하고 개발 범위를 점차 늘려가는 방식으로,

요구 분석 명세서에 명시된 시스템 전체를 서브(Sub) 시스템으로 분할하고,

이러한 서브 시스템을 단계적으로(점증적으로) 하나씩 릴리즈해 완성하는 방법이다.

 

ex) 유저 간 대결 기능 / 좋은 선수 추가 기능 / 나만의 선수 육성 기능

 

장점

• 몇가지 기능이 부족해도 초기에 사용 가능하다.
• 사용자의 요구를 빠르게 반영할 수 있다.
• 한꺼번에 많은 비용을 들이지 않아도 된다.
• 완전히 새로운 시스템 전체를 한 번에 주었을 때 조직이 받는 충격을 완화할 수 있다. (인터페이스 문제)
• 이미 사용하고 있는 서브 시스템이 있어, 어떤 유형으로 개발해야 하는지 잘 알 수 있다.

단점

• 처음 설계할 때부터 이후에 개발할 다른 서브 시스템과의 연관성을 고려해야 한다.
• 이미 개발된 서브 시스템과 통합시 어려움을 겪을 수 있다.

일정 중심 설계 모델

일정 중심 설계 모델

사용자의 요구에 대해 우선 순위를 정하고 이를 기초로 사이클을 계획한다. (설계, 코딩, 테스트)

 

초기 단계에는 중요한 기능들을 설계, 구현함으로써 시스템 골격을 만든다.

그리고 상대적으로 덜 중요한 기능을 나중에 진행한다. (일정 조정 가능)

 

※ 앞에서 단계적 개발 모델은 우선순위라는 개념이 없지만, 일정 중심 설계 모델은 우선순위라는 개념이 있다.

▶ 일정 중심 설계 모델

 

장점

• 소프트웨어 제품 출시 날짜가 매우 중요한 경우에 유리하다.
• 사용자의 요구사항에 우선 순위 지정이 가능하다.
• 목표 일정을 달성할 수 있을지 불확실할 때 유용하다. (우선순위에 따라 진행)

단점

• 낮은 우선순위를 분석하기 위한 시간 낭비 가능성이 있다. (우선순위가 낮아 출시에 포함되지 않을 기능을 분석/설계)
• 우선순위가 낮은 업무는 미개발될 수 있다.

애자일 프로세스 모델

애자일 프로세스 모델

애자일 (Agile): 민첩한, 날렵한

 

진화적 프로세스 모델의 장점을 살리면서 요구사항의 변화를 주기적으로 수용하여 반복적으로 개발하는 모델로,

고객의 요구에 민첩하게 대응하고, 그때그때 주어지는 문제를 풀어나가는 방법론이다. (빠르게 소통)

 

때문에 최근 많은 회사들이 채택하고 있는 모델 중 하나이다.

▶ 애자일 프로세스 모델

 

※ Sprint: 하나의 cycle(주기)로, 일반적으로 한 달이 소요된다. 

 

목표

• 프로세스 중심이 아닌, 개개인과의 상호 소통을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시 (속도가 생명이기 때문)
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시

즉, 애자일 프로세스 모델은 고객과의 협업, 단시간에 고객이 작동시킬 수 있는 소프트웨어, 환경과 요구사항 변화에 빠르고 능동적으로 대처하는 것에 중점을 두고 있다.

 

장점

• 반복 주기(스프린트)마다 제품이 생성되기 때문에, 사용자와 의견을 충분히 나눌 수 있다.
• 프로젝트 계획에 걸리는 시간을 최소화할 수 있다.
• 점진적으로 테스트할 수 있기 때문에 버그를 쉽고 빠르게 발견할 수 있다.
• 계획 혹은 기능에 대한 수정과 변경에 유연하게 대처가 가능하다.
• 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있다.

단점

• 스프린트마다 실행/테스트가 가능한 산출물이 만들어져야 한다.
• 빈번한 수정으로 개발시 개발 인력들의 피로도가 높다.
• 불완전하고 예측 불가능한 요소(비용, 시간)를 지닌 채 진행할 수 있다.
• 애자일 프로세스 모델이 추구하는 잦은 소통과 미팅은 대형 프로젝트에 적합하지 않은 평가를 받는다.

폭포수 모델 vs. 애자일 프로세스 모델

폭포수 모델

• 계획, 프로세스, 프로젝트 관리, 문서에 중점

애자일 프로세스 모델

• 고객과의 협업, 빠른 시간 안에 고객이 작동해볼 수 있는 소프트웨어, 환경과 고객의 변화에 능동적으로 대처하는 것을 강조하며 실행 가능한 소프트웨어에 중점

▶ Waterfall vs Agile

 

※ 폭포수 모델은 하나의 큰 사이클의 기간이 1년, 이런 식이고, 애자일 프로세스 모델은 하나의 작은 사이클이 1달을 주기로 반복되기에 문서를 만들 시간이 없다.

프로토타입 모델 vs. 애자일 프로세스 모델

프로토타입 모델

• 요구사항을 매 단계마다 모두 반영하여 개발
• 실제 설계가 이루어진 후에 급격하게 생기는 요구사항은 반영하지 못함

애자일 프로세스 모델

• 스프린트 단위로 요구사항의 변화를 수용하면서 개발
• 구성원 간 검토를 거쳐 우선순위화 하여 개발, 우선순위가 낮은 것은 우선 반영하지 않을 수 있음

▶ 프로토타입 모델 vs 애자일 프로세스 모델

 

프로토타입 모델과 애자일 프로세스 모델 모두, 단계가 반복된다는 공통점이 있지만,

프로토타입 모델은 요구사항 내에서 새로운 요구를 계속 받으며 더미 소프트웨어로 가시적인  결과를 보여주는 것이 반복되고,

애자일 프로세스 모델은 요구사항 단계만이 아니라, 전체 단계를 반복한다.

 

때문에 프로토타입 모델은 설계 단계 이후엔 요구사항을 반영할 수 없다는 문제점이 있지만,

애자일 프로세스 모델은  전체 단계가 반복되기에 변화 수용 부분에서 장점이 있다.

 

또한 여기서, 프로토타입 모델은 잇풋 아웃품 개념만 있으나, 애자일 프로세스 모델은 실행 가능한 소프트웨어를 만든다.

물론, 둘 다 가시적인 결과를 보여준다는 점에서 비슷하다고 할 수 있다.

나선형 모델 vs. 애자일 프로세스 모델

나선형 모델

• 개발 프로세스 전체에서 위험 식별 및 완화를 강조 (애자일과 목적의 차이)
• 더 구조화되고 덜 유연(여전히 문서화 강조)하며 반복을 기반으로 하기에 불확실성이 높은 더욱 복잡한 프로젝트에 사용

애자일 프로세스 모델

• 지속적인 반복 및 피드백을 통해 이해 관계자에게 가치를 제공하는 것을 강조하기에 유연성과 응답성이 핵심인 작고 간단한 프로젝트에 사용

▶ 나선형 모델 vs 애자일 프로세스 모델

 

※ 애자일 프로세스 모델은 시간 부족으로 인 나선형 모델에 비해 위험분석 단계가 부족하다.

애자일 프로세스 모델 - 스크럼

스크럼(Scrum)

애자일 프로세스 모델 중 가장 대표적인 모델이다.

▶ 스크럼: 럭비에서 반칙이 있을 때, 양편 선수가 밀집하려 서로 팔을 꼭 끼고 뭉치는 일로, '팀(Team)'이라는 의미이다.

 

애자일 프로세스 모델 스크럼은 팀원들이 마치 하나처럼 움직이고 따라줘야 성공할 수 있는 프로세스이다.

▶ 스크럼 방식

 

방식

1. 제품 기능 목록 작성 (요구분석 -> 함수(기능))

• 요구사항 목록에 우선순위를 매겨 제품 기능 목록 작성

2. 스프린트 계획 회의

• 스프린트 구현 목록 작성 (기능 중 우선순위)
• 스프린트 개발 기간 추정

3. 스프린트 수행 (1~4주)

• 스프린트 개발
• 일일 스크럼 회의
• 스프린트 현황판 변경
• 소멸 차트 표 (소멸 차트: 남아 있는 일의 양이 줄어드는 것을 차트로 표현한 것)

4. 스프린트 개발 완료: 최종 제품

• 실행 가능한 최종 제품 생산

5. 스프린트 완료 후: 스프린트 검토 회의 및 회고

• 스프린트 검토 회의
• 스프린트 회고
• 두 번째 스프린트 계획 회의

모델이 많은 이유

모델이 많은 이유

• 모델의 올바른 선택은 프로젝트 상황과 요구에 좌우된다.
• 모델을 잘 선택하면 생산성이 높아진다.
• 경우에 따라서는 모델의 융합이 이루어지기도 한다. (최적의 효과를 위해)