SW 개발 방법론

SW 개발 방법론 개요

SW 개발 방법론이란?

소프트웨어 시스템을 개발하는데 필요한 일련의 활동을 우리는 "소프트웨어 프로세스" 라고 부른다. 이는 아래와 같은 요소로 구성된다.

• 명세 : 시스템이 무엇을 해야하는지 정의한다.
• 설계 및 구현 : 시스템의 조직을 정의하고 시스템을 구현한다.
• 테스팅 : 고객이 원하는 것을 수행하는지 확인한다.
• 유지보수 : 변화하는 고객 요구에 대응해서 시스템을 변화시킨다.

소프트웨어 프로세스 모델. 즉, 개발방법론은 프로세스의 추상적인 표현이다. 특정 관점에서 프로세스에 대한 설명을 제공하는 것을 말한다.

SW 개발 방법론의 비교 포인트

현재 SW 산업에서는 여러 개발 방법론이 존재한다. 우리는 이 방법론들을 비교해보고 적절한 방법론을 사용해야하는데, 아래의 기준을 통해 비교를 할 수 있다.

• 주요 활동의 반복성 : 주요 활동을 반복하는지, 그리고 얼마나 자주 하는지를 고려해야한다.
• 수행가능 버전(MVP)의 출시 기간 : 수행가능한 버전인 MVP가 언제 나오는가에 대해 고려해야한다.
• 요구변경 수용 : 요구사항 변경이 들어오면 이를 얼마나 대응할 수 있는가를 고려해야한다.
• 개발 스케줄 관리 수월성 : 개발 일정을 얼마나 가시적으로 드러내는지 고려해야한다.

요즘과 같은 시대에는 AI의 역할이 크게 대두되는 추세인데, AI에게 일을 잘 시키기 위해서는 프롬프트를 잘 전달해줘야 한다. 이러한 AI 시대에 어떤 식으로 필요한 인력이 되어 스토리를 풀어나갈 것인지 생각해봐야 한다.

SW 개발 방법론의 종류

1.Waterfall 모델

Waterfall 모델은 위 그림처럼, 명확하고 순차적인 단계를 지닌다. 프로젝트가 시작해서 문제분석, 요구사항 명세 등을 거쳐 구현까지의 로직이 순차적으로 존재한다는 것이 특징이다.

waterfall 모델의 로직	waterfall의 비유연성

이러한 순차적 구조는 가장 치명적인 문제를 가지는데, 바로 비유연성 이다. 중간 절차에 대한 변경사항이 존재할 때, 이를 수행하는 것이 어렵다는 것이다. 이러한 점이 문제를 크게 발생시킨다.

이러한 Waterfall 모델은 요구사항이 명확한 경우에만 적용하기에 적합하다. 그래서 보통 Critical Project, 즉 국방과 같은 분야에서는 문서화와 인증이 필수적이므로 장기 프로젝트에서는 필연적으로 이 방법론을 선택하게 된다.

2.병렬적 개발 방법론

Waterfall 모델이 조금 변형된 스타일로, 같은 구조적 개발 방법론의 축에 들어간다. 계획, 문제 분석, 요구사항 명세는 순차적으로 진행하고, 이후의 개발은 subproject를 여러개를 동시에 실행시켜서 Prototype을 형성하는 방법론이다. 이 또한 요구사항이 명확한 경우에만 사용하는 것이 좋다.

3.Prototyping

진화적 프로토타이핑

빠르게 prototype을 만드는 것에 중심을 두고 개발하는 방식이다. 초기 개발 사양을 구성하고 이를 최종 시스템으로 수정 및 보완해서 확장하고 이를 통해 시스템을 개발하는 방식을 말한다. 요구사항이 명확하게 설정되지 않은 경우에 요구사항을 명확하게 하기 위해 사용하는 방법이다.

하지만 프로토타이핑 또한 단점이 분명하게 존재하는데, 초기 프로토타입에 래핑을 하는 것이기에 프로젝트가 다소 지저분해질 수 있고, 이 과정에서 복잡성이 증대한다는 것을 볼 수 있다.

Throwaway 프로토타이핑

위와 같은 문제를 해결하기 위해, Waterfall 모델을 적절히 섞은 프로토타이핑이라고 보면된다. 엄밀히 말하면 프로토타이핑의 목표는 시스템 요구사항을 이해하는 것이라고 볼 수 있다. 우리가 Waterfall 모델을 알아볼 때, 이 방법론은 요구사항이 명확해야한다고 했으니 둘을 잘 섞어본 것이다.

그래서 요구사항이 명확해질때까지 프로토타이핑을 사용하고 이후 Waterfall 모델을 이용해 개발하는 방식을 진행한다. 이를 통해 복잡성이 과도히 증대되는 것을 막을 수 있다.

이러한 prototyping 방식은 속도에 의미를 가진다. 대부분의 경우 갑과 을의 관계에서 개발을 진행하고 그러다보니 프로토타입이 빠르게 나올수록 갑의 이해도가 정립되면서 요구사항의 품질이 올라가는 효과를 볼 수 있다.

Incremental(점진적) 개발

기능에 대한 increment(증분)을 미리 나누어 두고 개발을 하는 방식을 말하고, 사용자 요구사항에 우선순위를 부여해서 그 순위에 맞춰서 작업하는 방식이다. 해당 요구사항은 고정하고 이후 증분에서 요구사항을 계속 발전시키는 방식이다. 한마디로 전체 시스템을 필요한 여러 개의 기능 단위인 '증분(Increment)'으로 나누어 순차적으로 개발하는 방식이다.

기능을 빠르게 제공하고, 실패 위험을 감소시키며 우선순위에 따라 테스트가 많이 발생할 수 있다는 점에서 장점을 가지지만 개발이 빠르게 진행되어 매 버전마다 문서를 수정하는 것이 비효율적일 수 있고, 증분이 추가될 때 구조가 점점 지저분해지는 프로토타이핑의 특성이 단점으로 작용한다.

prototype과 거의 유사하지만 조금 더 체계적인 방식으로 이뤄진다. 그러다보니 위에서 말한 것처럼 prototype의 문제점도 똑같이 가진다. incremental 개발 방법은 객체 지향 개발 방법이고, 그에 따라서 적용되는 분야도 상황에 따라 바뀐다.

Unified Process

Unified Process(UP)는 기존의 구조적 방법론들과 다르게 객체 지향 방법론의 일종이다.

Booch Method, Jacobson's Objectory, OMT라는 방법론을 하나로 합친 방법론이 발표된다. UP는 적응가능한(adaptable) 방법론이다. 즉, 특정 정보 시스템의 특성에 맞게 수정해서 적용하는 방식이라는 것이다.

애자일 방법론

애자일 방법론은 사실상 오늘날 가장 주로 쓰이는 방법론으로 불린다. 단순하고 반복적인 개발을 강조하며, 아래의 표를 통해 애자일 개발의 원리를 확인할 수 있다.

애자일 방법론의 가장 핵심은 "타임 투 마켓"이다. 어떤 프로그램이나 서비스를 출시하고자할 때, 그 서비스의 완성도보다는 출시 시기가 더욱 중요한 요소이다. 품질이나 완성도를 후순위로 차치한 이후 빠르게 시장에 서비스나 제품을 출시하는 것을 최우선으로 스프린트를 컴팩트하게 가져가는 방법이다.

XP(Extreme Programming)

XP 방법은 반복적 및 점진적 방법을 이용해 정보 시스템 개발에서 이슈가 되는 새로운 접근법이다.

프로그래머는 먼저 Task에 대한 Test case를 생성해서 자동 테스트 환경을 구성하고 하나의 컴퓨터에서 파트너와 함께 동시 작업한다. 이 모든 테스트 케이스를 올바르게 작동할 때까지 구현하고 이가 마무리되면 끝내는 방식을 택한다. 이때 한 컴퓨터로 동시에 작업한다는 의미는 한명이 코딩하고 한명은 뒤에서 같이 보면서 작업하는 것을 말한다.

XP의 방식을 택하려면 기본적으로 중급 이상의 시니어급 프로그래머가 되어야한다. 그리고 Customer를 한명 넣어서 운영된다. 로직을 보면 하루 단위로 개발 버전을 수정하고 업데이트를 해 나가고, Customer가 개발 버전을 검증하고 피드백을 주는 방식으로 운영된다.

MS의 사례

우리는 MS를 한번 주목할 필요가 있다. MS는 에러가 발생함에 크게 개이치 않는다. 애자일 방법론의 기조에 맞게 제품을 만들고 시장이 필요로 하는 시점에 완성도가 낮아도 일단 출시하여 이후 제품을 보강해 나가는 것이다. 이러다보니 MS가 독특한 점이 있는데, 보통은 갑과 을이 존재하는 프로젝트가 대부분이지만 MS의 경우에는 갑이 명확하게 존재하지 않는다. 어찌보면 대중이 그 갑의 위치로 들어갈 수도 있다고 본다. 결론적으로 MS가 가지는 포인트는 "time to market"이다.

애자일 방법론은 기존의 방법론들이 절차를 중시하며 흐름을 이어간 것과 다르게 사람을 중심으로 개인의 업무 프로세스를 보장해주는 방법론이다. 에러가 발생하면 수정하고 다시 테스팅하는 과정을 거치며 스프린트를 아주 잘게 쪼개서 업무를 이어간다. 이렇게 이어가다보면 코드가 스파게티 코드가 되고, 이를 정리해주는 것이 '리팩토링'이다. 리팩토링을 통해서 기존의 코드를 수정한다. 다만 리팩토링의 특징은 기능을 추가하거나 더 새로운 기술을 넣는 것이 아니라, 서비스 자체는 큰 변화가 없다는 것이다.

나아가 테스팅을 하는 관점에서는 이 방식을 TDD라는 이름으로 이해할 수 있는데 TDD란 Test-Driven Development로, 실제 코드를 작성하기 전에 실패하는 단위 테스트를 먼저 작성하고, 이를 통과한 최소한의 코드를 구현해 리팩토링을 반복하는 과정을 말한다.

Plan-driven vs agile specification

---

요구사항 분석

요구사항 분석의 목표

요구사항 분석은 제안된 시스템이 무엇을 수행하는지를 정의한 것이며, 어떻게를 정의하는 것은 아니다. 명확히 말하면 "What"을 정의하는 것이라 볼 수 있다. 어떻게는 설계 단계에서 정의 한다.

요구사항 명세의 구성요소

요구사항 명세의 구성요소로는 아래의 3가지로 나뉘는데, 앞의 2개는 우리가 흔히 생각하는 요구사항의 명세이다. 무엇을 수행하는지, 어떤 특성을 가지는지 이것은 프로젝트에서 반드시 다루어야하는 내용이라고 볼 수 있다.

하지만 그보다 선행되게 생각해야하는 부분이 있는데, 그것이 도메인의 기본적인 상식이다. 내가 하고자하는 프로젝트가 포함된 도메인에 대해서 기본적인 지식을 가지지 않으면 큰 어려움을 가질 수 있다.

기능적 & 비기능적 요구사항

요구사항은 크게 두가지로 나뉘는데, 기능적 요구사항, 비기능적 요구사항으로 나뉜다.

기능적 요구사항

기능적 요구사항은 시스템이 제공해야하는 서비스 명세서로 특정 입력이 발생하면 이에 대한 반응을 어떻게 할 것이고, 특정 상황에서 시스템이 어떻게 작동하는지 등의 서비스의 기능적인 요소를 포함하는 내용이다.

비기능적 요구사항

비기능적 요구사항은 서비스의 기능이 아닌 개발 프로세스의 제약, 표준 등의 시스템이 제공하는 서비스나 기능의 제약사항들을 말하고, 개별 기능이나 특정 컴포넌트가 아닌 전체 시스템에 적용되는 속성들을 기술한다.

요구사항 명세서 작성법

요구사항 명세서는 다음과 같은 방법으로 작성할 수 있다.

자연어 명세

자연어 문장으로 명세를 작성하는 방식을 이야기한다. 가장 직관적이고 표현하기가 용이하기 때문에 보편적으로 사용하고 고객 또한 요구사항을 쉽게 이해할 수 있다. 하지만 이 표기법은 몇가지 문제점이 존재한다.

• 명확성 부족 : 정확도를 높이면 문서를 읽거나 이해하기가 어려워진다.
• 요구사항 혼동 : 기능적, 비기능적 요구상항이 혼재되는 경향이 있다.
• 요구사항 합병 : 여러가지 요구사항을 함께 묶어 하나로 표현할 수 있다.

구조적 명세

작성자의 표현 자유가 제한되고 요구사항을 표준방식으로 작성하도록 하고 임베디드 제어 시스템에 대한 요구사항에는 적합하나 정보 시스템의 요구사항 작성에는 매우 엄격하다.

UML-based System Modeling

UML 방식의 장점은 Customer가 딱 보고 무슨 이야기인지 이해할 수 있다는 점이다.

Use Case 분석

고객 요구사항에 대한 분석, 개발 시스템의 범위를 정의한 것으로, 요구사항을 그래픽 다이어그램 및 시나리오 방식으로 기술하는 형태다. 시스템 관점에서 외부 상호작용의 적절정을 검증하고 수행 시나리오로서 acceptance test에 활용된다.

• Use Case
  use case는 actor 관점에서 관찰 가능한 연속적인 행위의 집합을 기술한 것이다.
• Actor
  시스템과 상호작용하는 외부 에이전트가 수행하는 역할을 말하고, 하나의 외부 에이전트가 여러 역할을 수행할 수 있다.

Use Case 예시	Use Case 설명 기술

Use Case 간의 관계

Use Case 간에는 관계가 존재한다.

• 포함 관계 << include >>
  여러 Use Case들이 공통적인 행위를 하는 경우, 공통 행위를 따로 나타내고 이를 포함하도록 하는 것이다.
• 확장 관계 << extend >>
  하나의 Use Case의 확장점에서 추가적인 행위를 추가해 다른 Use Case로 변형한 것이다.

요구사항 명세서와 테스팅

요구분석 단계에서 요구사항 명세서에 명시된 기능적 및 비기능적 요구사항에 대한 Test Plan을 수립한다. Test Case 작성 과정을 통해 요구사항의 일관성 및 완전성을 검사한다.

이번 포스트에서는 여러 방법론들과 요구사항 명세에 대한 부분을 알아보았다.