소프트웨어 개발 방법론

목차

1. 소프트웨어 생명주기 모델
2. 소프트웨어 생명주기 모델 프로세스
3. 소프트웨어 개발 프로세스 모델 종류

 

 

소프트웨어 생명주기 모델

소프트웨어 생명주기(SDLC; Software Development Life Cycle) 모델 개념
소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다
시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것이다

 

 

 

소프트웨어 생명주기 모델 프로세스

요구사항 분석
다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계
ex) 기능 요구사항, 비기능 요구사항

 

설계
시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계
ex) 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

 

구현
설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계
프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계
ex) 인터페이스 개발, 자료 구조 개발, 오류 처리

 

테스트 
시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
ex) 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

 

유지보수
시스템이 인수되고 설치된 후 일어나는 모든 활동
ex) 예방, 완전, 교정, 적응 유지보수

 

 

소프트웨어 개발 프로세스 모델 종류

폭포수 모델(waterfall model)

소프트웨어의 개발 과정을 요구분석, 설계, 구현, 통합, 운영 및 유지보수의 단계로 구분하여 순차적으로

진행하는 프로세스 모델 주요 특징으로는 가장 오래되고 널리 사용된 프로세스 모델이란 것이고

통합적으로 크고 복잡하며 장기간 지속되는 프로젝트에 사용하는 것이 적합하다.

 

단점

• 불필요한 문서들의 작성이 요구되어 설계와 코딩 및 테스팅 지연 가능성이 있다.
• 이미 구현 단계가 진행되고 있다면 요구에 대한 변경 수용이 어렵다.
• 프로토타입이 없기 때문에 최종 결과가 나오기 전까지는 어떤 결과물이 나올지 모른다.

 

프로토타이핑 모델

프로토타입은 대량 생산에 앞서 미리 제작해 보는 원형 또는 시제품으로 제작물의 모형이라는 뜻이다.

빠른 개발 요구하는 분야에 적합하고  반복된 요구사항 정의를 통해 사용자 요구가 충분히 반영된 요구 명세서를

작성할 수 있다.

 

단점

• 프로토타이핑 과정에 대한 통제 및 관리의 어려움이 있다.
• 반복적 개발을 통한 투입인력 및 비용 산정의 어려움이 있다.
• 불명확한 개발 범위로 인해 개발 종료 및 목표의 불확실성이 존재한다.

 

 

나선형 모델

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

이로써 실패의 위험을 줄이고 테스트에 용이하게 만들면서 피드백이 가능하다.

 

단점

• 반복적 개발에 의한 프로젝트 기간 연장의 가능성
• 반복 회수의 증가에 따른 프로젝트 관리의 어려움
• 위험관리의 중요성에 따른 비용 발생

 

 

애자일 모델

애자일은 날렵한, 민첩하다는 뜻으로 고객의 요구에 민첩하게 대응하고 그때그때 주어진

문제를 풀어나가는 방법론을 말한다.

 

 

애자일 4가지 주요 특성 및 개발 방법

 

• 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
• 작동하는 소프트웨어가 포괄적인 문서보다 우선
• 고객과의 협업이 계약 협상보다 우선
• 변화에 대응하는 것이 계획을 따르는 것보다 우선

 

1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통해 변화하는 요구사항을 수용한다.
2. 고객이 결정한 사항을 가장 우선으로 시행, 개발자 개인의 가치보다 팀의 목표를 우선으로 한다.
3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
4. 주기적으로 제품 시현을 하고 고객으로부터 피드백을 받는다.
5. 프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용 절감을 목표로 한다.

 

 

스크럼

애자일 방법론을 적용한 가장 많이 사용되는 개발 프로세스이다. 원래 럭비 경기에서 사용되던 용어인데, 반칙으로 인해 경기가 중단됐을 때 쓰는 대형을 의미한다. 즉, 소프트웨어 측면에서 팀이라는 단어가 주는 의미를 적용시키고, 효율적인 성과를 얻기 위한 방식을 의미한다고 해석할 수 있다.

 

 

1. 제품 기능 목록 작성
개발할 제품에 대한 요구사항 목록을 작성한다. 우선순위가 매겨진, 사용자의 요구사항 목록이라고 할 수 있다. 개발 중에 수정이 가능하기는 하지만 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않는 것이 원칙이다.

2. 스프린트 Backlog
스프린트란 각각의 목표에 도달하기 위해 필요한 작업 목록이다.
세부적으로 어떤 것을 구현해야 하는지
작업자는 누구인지
예상 작업 시간은 얼마나 걸릴지를 작성한다.
이를 통해서 개발이 어떻게 진행되고 있는지 상황 파악이 가능하다

 

3. 스프린트
스프린트란 이름이 붙여진 이유는 그 의미 때문이다. 스프린트의 단계부터 작은 단위의 개발 업무를 단기간 내에 전력질주해서 개발한다. 한 달 동안의 큰 계획을 3~5일 단위로 반복 주기를 정했다면, 이것이 스크럼에서 스프린트에 해당한다. 이 주기가 회의를 통해 결정되면 (보통 2~4주) 목표와 내용이 개발 도중에 바뀌지 않아야 하고, 팀원들 동의없이 바꿀 수 없어야 한다.

4. 일일 스크럼 회의
모든 팀원이 참석하여 매일, 짧게(15분) 진행 상황을 점검한다. 한 사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점을 이야기한다. 완료된 세부 작업 항목을 스프린트 현황판에서 업데이트시킨다.

5. 제품 완성 및 스프린트 검토 회의
모든 스프린트 주기가 끝나면 제품 기능 목록에서 작성한 제품들이 완성된다. 최종 제품이 나오면 고객들 앞에서 시연을 통한 스프린트 검토 회의를 진행한다. 이 때 고객의 요구사항에 얼마나 부합했는지, 개선점 및 피드백이 있는지 확인한다.

6. 스프린트 회고
스프린트에서 수행한 활동과 개발한 것을 되돌아보며 개선점이나 규칙 및 표준을 잘 준수했는지 검토한다. 팀의 단점보다는 강점과 장점을 찾아 더 극대화하는데 초점을 둔다.

 

스크럼의 장단점

장점

• 스프린트마다 생산되는 실행 가능한 제품을 통해 사용자와 의견을 나눌 수 있다
• 회의를 통해 팀원들간 신속한 협조와 조율이 가능하다
• 자신의 일정을 직접 발표함으로써 업무 집중 환경을 조성할 수 있다.
• 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 변화 시도가 용이하다

단점

• 스프린트마다 테스트 제품을 만들어야 하기 때문에 추가 작업 시간이 필요하다.
• 15분 회의 시간을 지키기 어렵다. 그만큼 작업 시간이 또 줄어든다.
• 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평가에는 미약하다.