03. 소프트웨어 개발 방법론

프로세스

프로세스란? )
일이 처리되는 과정이나 공정. 즉, 주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 일련의 절차. 프로세스를 따르면 목적을 달성할 수 있다.

 

프로세스의 목적 )

이전에 얻은 노하우를 전달하면 시행착오가 감소하며 빠르게 적응할 수 있다. 프로세스는 일종의 가이드 역할인 것이다.

 

소프트웨어 개발에서의 프로세스)

직업(개발할때 일을 수행하는 작은 단위) 순서의 집합+제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동을 말한다.

좁게는 SW 제품을 개발할 때 필요한 절차이자 사용자의 요구사항을 구현하기 위한 활동을 말하고, 넓게는 절차, 구조, 방법, 도구, 참여자 등 개발 목적을 이루는데 필요한 통합적인 수단을 뜻한다.

 

 

 

소프트웨어 공학이 다루는 일반적인 주제

• 방법) 소프트웨어 제작에 사용하는 기법이나 절차. ex) 구조적 분석, 객체지향 분석
• 도구) 자동화된 시스템. ex) 설계 도구, 프로그래밍 도구, 테스트 도구
• 프로세스) 도구와 기법을 사용하여 작업하는 순서. ex) unified process, extreme programming
• 패러다임) 접근방법 또는 스타일. ex) 구조적 방법론, 객체지향 방법론

 

 

소프트웨어 프로세스 모델 = 개발 방법론 = 패러다임 = 생명주기 모형

정의) SW를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념으로, 개발 계획 수립부터 최종 폐기때까지의 전 과정을 다룬다.

목적) 고품질의 소프트웨어 제품 생산하는 것.

역할)

 -프로젝트의 기본 골격을 세워준다

 -일정 계획을 세울 수 있다

 -개발비용, 시간을 산정하고 분배할 수 있다

 -참여자들의 의사소통의 기준을 정할 수 있다

 -용어의 표준화를 가능하게 할 수 있다

 -개발 진행상황을 명확하게 파악할 수 있다

 -단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있다

 

 

 

소프트웨어개발 방법론

• 소프트웨어 개발에 대한 각 직업 단계를 체계적으로(방법, 도구 등을 이용) 정리한 작업 수행(개발 프로세스)의 표준 규범
• 높은 품질의 소프트웨어 시스템을 체계적으로 만들기 위해 필요한 개발 방법, 개발 환경 및 관리에 대한 틀을 설정함
• 방법론 = 방법(=노하우) + 지식과 경험
• 패러다임은 프로젝트의 성격, 소요시간, 방법과 도구에 의해 선정되며 개발 방법, 환경, 관리를 포함함
• 대표적으로 폭포수 모형, 원형 모형, 나선형 모형, 4세대 기법이 있음

 

1. 주먹구구식 모델

• Build and fix, code and fix 모델을 말하며, 빌드 후 원하는게 아니면 고치는 방식이다. 방법론이 없는 경우다. 따라서 가이드라인이나 프로세스도 없다.
• 개발자 한명이 단시간에 마칠 수 있는 경우에 적합하다.
• 정해진 개발순서나 단계별로 문서화된 것이 없어서 관리와 유지보수가 힘들다.
• 프로젝트 전체 범위를 알 수 없다.
• 일을 효과적으로 나눠서 개발할 수 없으며 프로젝트 진행 상황을 파악할 수 없다.
• 지속적인 수정으로 인해 프로그램의 구조가 나빠져 수정이 어려워진다.

1. 첫번째 버전의 코드를 작성하여 제품을 완성한다
2. 작성된 코드에 문제가 있으면 수정한다
3. 문제가 없으면 사용한다

 

2. 폭포수 모델(Waterfall Model) = 선형 순차적 모델(Linear Sequential) = 고전적 생명주기 모델(Classic life cycle)

• 가장 처음으로 출현한 모델이며, 순차적으로 접근하는 방법이다.
• 하향식 접근 방법을 사용하여 높은 추상화 단계(머리로 상상)에서 낮은 추상화 단계(점점 구체적으로 상상)로 옮겨가는 모델이다.
• 요구사항 분석, 설계, 구현, 시험 및 유지보수의 순서로 시스템의 개발이 이루어진다.
• 단계가 끝날때 마다 과정의 끝(승인)을 알리고 다음 단계를 진행한다. 이전 단계로 돌아갈 수 없다. 따라서 여러 과정을 동시에 할 수 없다.
• 새로운 요구나 경험을 설계에 반영하기 어렵다.
• 단계별 정의가 분명하고 산출물이 명확하다.
• 피드백이 하나도 없는건 아니다. 피드백하기 친절한 모델이 아닐뿐.
• 장점: 관리가 쉽고 문서가 체계적이다. 요구사항 변화가 적은 프로그램에 적합하다.
• 단점: 피드백이 발상하면 순차적인 흐름을 따라가기 어렵다. 요구사항을 초기에 구체적으로 기술하기 어렵다. 작동하는 시스템에 프로젝트 후반부에 나오므로 중요한 문제점이 그때서야 발견된다.

1. 계획
2. 요구사항 분석 (요구사항 명세서를 결과물로 도출)
3. 설계 (설계 문서를 결과물로 도출)
4. 구현 (프로그램을 결과물로 도출)
5. 시험 (제품 오류를 발견하고 수정하는 과정으로 품질보증 활동의 중요한 일부분)
6. 유지보수 (수정 유지보수, 적응 유지보수, 기능추가 유지보수, 관리 유지보수)

 

 

3. 원형(Prototyping) 패러다임 = 진화적 프로세스모델 

-등장 배경

 고객이 원하는 목표를 어떻게 만족시킬지 모르는 경우가 있다. 사용자 스스로 원하는게 뭔지 구체적으로 모르거나 요구 가 어떻게 변경될지 모르는 경우가 있다. 엔지니어가 고객의 요구를 불완전하게 이해하는 경우가 있다.

위와 같은 폭포수 모델의 단점을 보완하기 위해 프로토 타입을 만들어 보여주는 원형 패러다임 방식이 생겨났다.

-프로토 타입이란?

간단한 시제품을 뜻하는 것으로, 아파트의 모델하우스같은 역할을 한다.

-원형 패러다임의 용도와 장점

• 개발 초기에 사용자의 피드백을 얻어낼 수 있다
• 사용자의 요구사항을 구체적으로 규명할 수 있다 (요구사항 명세화)
• 요구사항이 불명확하여 불안정한 상황일때 프로젝트를 쉽게 제어 관리할 수 있다
• 개발자와 사용자의 오해가 규명된다
• 생각하지 못했던 기능과 서비스가 발견된다
• 가능성과 유용성을 관리자에게 보여줄 수 있다
• 사용자에게 완제품이 배달되기 전에 사용자를 교육 훈련시키는데 사용된다
• 사용자가 실제로 사용하기까지의 시간을 줄여준다
• 시스템 테스트에 들어가는 노력을 줄여준다
• 시스템 테스트에 연속적으로 사용될 수 있다

-원형 패러다임의 한계

• 시스템의 극한 상황등에 대한 성능 평가가 어렵다
• 시제품에서 완제품이 되는데에 많은 변화가 있을 수 있다
• 완제품이 어떨 것이라는 오해를 불러올 수 있다
• 시제품을 여러번 만들어야하는 경우 반복적 개발을 통한 투입 인력 및 비용 산정이 어렵다
• 중간 산출물 정의가 난해하여 관리가 어렵다

1. 요구사항 분석
2. 시제품 설계
3. 시제품 개발 (완제품 개발X / 입출력을 통해 사용자가 요구하는 것 확인)
4. 고객의 시제품 평가 (프로토타입 평가 → 추가 및 수정 요구 → 프로토타입 개발 → 프로토타입 평가... 반복)
5. 시제품 정제 (고객의 요구사항을 만족시킬때까지 계속)
6. 완제품 생산 (원형을 버리고 새 시스템을 개발해야된다면, 폭포수 모델이나 4세대 기법을 따라야한다)

 

 

4. 나선형(Spiral) 패러다임

• 폭포수 모델과 원형 패러다임의 장점+위험 분석
• 개발중에 생기는 위험을 관리하고 최소화하는 것이 목적임. 점진적이다.
• 위험 요소의 예시
  -빈번히 변경되는 요구사항
  -팀원들의 경험 부족
  -결속력이 떨어지는 팀워크
  -프로젝트 관리 부족
• 4단계의 나선
  1. 계획 및 정의 (시스템 목표에 대한 차선책이 고려됨)
  2. 위험 분석 (초기 요구사항에 근거하여 위험이 규명됨 / 프로젝트를 계속할건지(GO), 중단할건지(No-Go)를 결정함)
  3. 개발 (어떤 패러다임을 적용할지 개발 모델을 결정)
  4. 고객 평가 (고객 평가에 의해 다음 결과물 계획)

 

• 장점: 사전 위험 분석을 통한 돌출 위험요소를 감소시켜 프로젝트 중단 확률이 낮아짐 / 사용자의 불만 감소
• 단점: 반복적 개발에 의해 프로젝트 기간이 연장될 수 있음 / 반복 회수의 증가에 따라 프로젝트 관리가 어려워짐 / 위험 전문가가 필요하여 부담이 됨 / 따라서, 많은 고객을 상대로 하는 상업용 제품에 적용하기 어려움 / 많이 사용되지않아 충분한 검증을 거치지 못했음
• 재정적, 기술적으로 위험 부담이 큰 경우 또는 요구 사항이나 아키텍처 이해가 어려운 경우에 적합하다.
  ex) 초고속 정보통신망 개발, 대형 사업

객체지향 소프트웨어 개발 방법론은 원형 패러다임과 나선형 패러다임 등 점진적인 시스템 개발을 가능하게 하는 우수기법이다.

 

 

5. 4세대 기법

• 자동화 도구들을 이용하여 요구사항 명세서로부터 실행코드를 자동으로 생성할 수 있게 해주는 방법.
• 현재 4GT 도구들은 고급 언어를 실행코드로 바꾸어줄만큼 정교하지 못하다.
• 이러한 고급언어의 모호성을 해결하기 위해 형식 규격 언어로 표현하려는 노력을 하고 있다. 
  형식 규격 언어를 사용하면 명세서를 해석하고 이해하는데 정확성을 기할 수 있으며 개발과정을 자동화할 수 있다.
  ex) EER 모델로 만들어진 명세서에서 데이터베이스의 코드가 생성
• 한계점: 아직 성능이 뛰어나지않고 불필요한 많은 양의 코드를 생성하고 유지보수가 어려움 / 대규모 소프트웨어 개발에서는 분석, 설계하는데 더 많은 시간이 필요함(활용도 낮음) / 하지만 많은 응용분야에 사용될 것으로 예상됨

 

 

6. 에자일 프로세스 모델 ↔ 폭포수 모델 (애자일이 추구하는 것, 실천법 종류 알아두기)

-이전 개발의 문제

• 개발 환경이 지속적으로 변화하여 변화에 맞는 개발방법의 필요성이 대두됐다.
• 팀원들이 개발에만 전념할 수 있도록 좋은 환경을 만들어줘야한다.

-등장 배경

• SW 개발 환경의 변화: 결과물 배포시기가 중요해짐 / 개발 생산성이 저하됨
• 기존 방법론의 한계: 문서와 절차 위주의 방법론은 변화에 대응하기 어려움 / 개발자의 개발능력 차이가 불안정함
• 폭포수 모델은 불명확하고 사용자의 요구사항이 변화하면 문제가 발생했다. 또한 개발된 모듈을 통합하기 어렵고 충분히 테스트하기 어려워서 SW품질이 하락했다.

-애자일 선언문

• 경량방법론 지지자들이 모여 공동으로 추구하는 가치를 발표함 (에자일의 사전적 의미는 '가볍다')
• 프로세스와 도구보다는 개인과의 상호작용을 중시한다 (ex) '메뉴얼이 이래서 어쩔 수 없어요' (X))
• 포괄적인 문서보다는 동작하는 소프트웨어를 중시한다
• 계약 협상보다는 고객과의 협력을 중시한다
• 계획의 수행보다는 변화에 대응하는 것에 집중한다
  ∴ 더 나은 의사소통, 지속적인 변화 관리, 우선순위 따지기, 반복적이고 점진적 (나선형과 비슷하나 나선형보다 가벼움. 위험이라는 말이 나오면 나선형)

-애자일 방법론

• 필요한 요구를 바로 더하고 수정하는 코드중심의 점진적 개발 방법으로, "고객에게 최고의 가치를 가장 빨리 전달"한다는 철학을 가진 경량 방법론이다.
• 변화에 신속히 대처하기 위해 이터레이션(iteration)을 쓴다.
• 반복적 개발을 통해 잦은 출시를 목표로 한다.
  프로토 타입 개발 → 사용자 확인 → 일부 기능 사용
• 전통적인 개발 방법은 중간에 동작하는 SW가 없다. 하지만 반복적 점진적 개발 방법은 최소한의 기능을 가지고 동작하는 SW가 있다.
• 형식이라기보다는 마음가짐이고, 프로세스 중심이 아닌 사람 중심이며, 사람들 사이의 참여와 소통에 관한 문제이다. 실천하는 것이 아닌 하나의 패러다임이라고 볼 수 있다. 애자일 방법론을 실천하는 툴은 따로 있다. (ex) XP)
• 장점: 소프트웨어 개발 프로젝트의 낮은 성공률때문에 보다 빠른 프로토타입의 중요성이 점점 높아지고 있고, 릴리즈 주기(개발 동안에 동작 가능한 프로그램이 항상 나와야함)도 점점 짧아지고 있어 애자일 개발 방법론의 프로세스와 가치에 부합된다. / 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며 들어가는 비용과 위험도도 낮다.
• 도입의 어려움: 아직 성공사례가 많지 않음 / 팀원들은 개발 프로세스에 적응하기 위해 소프트웨어공학, 객체지향  기술을 숙달해야함 / 고객의 역할이 기존 방법들에 비해 늘어났지만 고객의 참여를 이끌어내기 힘듦

-XP

• 애자일 개발 방법론 중 가장 많이 알려진 방법
• 매우 가볍고 실용성을 강조함
• '고객에게 최고의 가치를 가장 빨리 전달'한다는 목표를 가짐
• 의사소통, 단순함, 피드백, 용기, 존중 등 5가지 가치에 기초함 (이런건 시험에 안 나옴)
• 주요 키워드) 테스트 주도 개발(TDD), 일일 빌드(=개발속도를 빨리. 날마다 통합 빌드가 하나씩 나옴), 지속적인 통합
• XP의 12가지 실천 항목 중 눈여겨봐야할 것
  - 분석/설계 단계의 On-Site Customer: 개발 효율성을 위해 고객을 프로젝트에 상주시킴. ex) 계속 물어보기
  - 구현 단계의 Refectoring: 프로그램의 중복/복잡성 제거. 가독성이 좋아짐
  - 구현 단계의 Pair Programming: 두 사람이 함께 프로그래밍(driver/ partner)
  - 테스트 단계의 TDD 테스트 주도적 개발: 코어 기능을 우선적으로 개발할 수 있음
• XP 익스트림 프로그래밍
  - 사용자 스토리
  - 매일 빌드와 통합
  - 테스트 주도 개발 (TDD)
  - 페어 프로그래밍

 

 

사용자 스토리

•  계획 단계에 해당. 사용자 스토리를 만들어 고객과 직접 대면하며 이야기한다.
• 메모 한장으로 사용자 요구 사항을 정리하며 디테일한게 좋다. '사용자' '목표' '가치' '설명' '가정과 추정'의 내용이 들어가야한다.
• Card(카드), Conversation(대화), Confirmation(인수테스트)와 같은 요소로 이루어져있다. 스토리 카드에는 우선순위, 추정 구현시간, 스토리 등의 내용이 들어가있다. 스토리 카드는 작업(업무)들로 분해되고, 각 작업은 구현의 기본 단위이다.
• ex) 인터넷 쇼핑몰를 예로 들어보면 관리자는 카테고리를 새로 등록하거나 수정, 삭제한다 / 회원은 상품을 장바구니에 담거나 삭제한다
• 주의할 점은 스토리와 테스트를 헷갈리지 말아야한다. 스토리는 '회원은 각 카테고리의 상품을 조회한다' 와 같은 것이고, 테스트는 '임의의 시점에서 조회중인 카테고리의 상위 카테고리 목록을 조회할 수 있어야한다' 와 같은 것이다.

테스트

• 테스트와 관련된 활동은 프로젝트의 시작에서부터 요구사항 분석 단계까지 지속된다
• 테스트를 작성하는 작업은 요구사항을 밝히는 고객과 함께 협동하여 수행한다
• 테스터와 개발자는 적대적 관계가 아닌 협력 관계를 유지해야한다
• 프로그램을 작게 나누어 테스트를 자주 수행한다
• 작성 시점과 목적:
  - 고객과 개발자가 스토리에 대해 토론하는 과정에서 도출된 세부사항을 기록하기 위해
  - 스토리의 구현을 시작하기 전 개발자가 스토리를 명확하게 이해하고자 할 때
  - 프로그래밍 중 또는 그 이후라도 스토리에 필요한 새 테스트를 발견할 때

테스트 주도 개발(TDD)
Test Driven Development의 약자로, 개발자가 만든 코드가 제대로 수행되는지 결과값을 통해 확인하는 방법. 프로그램을 먼저 만들고 테스트하는 것이 아닌, 테스트를 먼저 만들고 해당 테스트를 통과하는 프로그램을 짜는 것이다. 이와 같은 방법을 쓰는 이유는 코어 기능을 먼저 구현하고 잘 동작하는 깔끔한 코드를 얻기 위해서다.

 

리팩토링(refactoring)

• XP 실천법 용어이다.
• 소프트웨어 내부 구조를 바꿔 디자인과 기존 코드의 설계를 개선하는 기술이다. 코드를 쉽게 사용하고 이해할 수 있게 만든다.
• 프로그래머의 직감에 의존해 나쁜 코드(복사된 코드 로직, 긴 메서드, 긴 클래스, 많은 파라미터)를 파악해야한다. 따라서 숙련되지 않은 개발자에게 부담이 된다
• 잘못된 설계에서 나타나는 기술적 부채를 감소시켜 덜 짜증을 느끼며 일할 수 있는 환경을 조성한다
• 자신의 코드는 자신이 리팩토링하는게 좋다
• 리팩토링 하는 시기:
  - 새로운 함수를 추가할 때
  - 버그를 수정해야 할 때
  - 코드 리뷰를 수행할 때
• 리팩토링이 무의미한 경우:
  - 리팩토링을 실행해도 복구가 어려울 정도로 코드가 망가짐
  - 데드라인이 너무 가깝고 리팩토링하고 검증할 테스트 코드가 없는 경우
• 장점:
  - 리팩토링이 이루어지면 다른 개발자가 코드를 수정할때 이해도가 높아지며 개발 속도를 단축시킨다
  애자일 방법론에서는 코드 구현 작업의 일부분으로 취급하기 때문에 리팩토링을 위해 별도의 시간을 할애할 필요가 없다.
  - 짝 프로그래밍을 하는 경우 개발자들이 서로의 코드를 검토하며 검토자는 원작자 입장에서 객관적인 평가를 해주고 유용한 아이디어를 제안할 가능성이 높아 리팩토링 가능성이 높아진다.
• 단점:
  - 코드가 수정되면 모든 기능을 다시 테스트 해야한다.

시험 전에 좋은 코드 예시 살펴보기

 

 

7. 컴포넌트 기반(CBD) 개발 방법론

• 다른 컴포넌트를 결합하여 소프트웨어를 개발하는 것.
• ex) 회원가입 기능을 따로 구현하지 않고 카카오로 로그인하기 기능을 붙임
• 컴포넌트는 하나 이상의 프로그램들을 하나의 단위로 관리하는 패키지이고, 독립된 배포 단위를 가지고 있다. 명확하게 정의된 개방 인터페이스(컴포넌트를 연결하기 위한 표준 규약)를 제공하는 독립형 기능 패키지이다. 컴포넌트를 쓰면 소프트웨어를 쉽게 관리할 수 있고 교체, 재사용이 쉬워 개발 기간과 비용이 줄어든다.

 

 

 

 

소프트웨어 제작 방법의 공통점

• 시스템의 정의(definition) 단계: 요구사항 분석 과정. 사용자에게 무엇을 제공할건지. 사용자 관점, 시스템의 논리적 관점에서 정의한다.
• 시스템의 개발(development) 단계: 설계, 구현, 시험의 과정이다. 무엇을 어떻게 만족시킬지 규명. 엔지니어의 관점, 시스템의 물리적 관점에서 바라본다. ex) 어떻게 설계할지, 어떤 프로그래밍 언어를 사용할지
• 시스템의 유지보수(maintenance) 단계: 오류 수정, 환경 변화, 기능 향상 요구 등의 변화에 초점을 둠. 이에 따라 문서도 갱신한다. 수정적 유지보수, 적응적 유지보수, 완벽적 유지보수, 예방적 유지보수. 
• 참고로 이건 책마다 다르니 세개라는 것에 집착하지 말것. 다른 책에서는 네개, 다섯개가 적혀있을수도 있다.

 

 

 

소프트웨어 개발의 무질서 극복

• 무질서는 사용자의 관점(what)와 엔지니어의 관점(how to)을 구별하지 못하기 때문에 발생.
• 엔지니어의 관점보다 사용자의 관점에 우선순위를 두어야한다.
• 이를 극복하려면 충분한 분석, 구체적 목표, 사용자 동의가 필요하다.
• 구체적인 목표의 확립은 기술력 품질 향상뿐만 아니라 사용자 만족도도 증진시킨다.