[S/W Engineering] Chapter 01_소프트웨어 공학과 개발 프로세스

Chapter 01_ 소프트웨어 공학과 개발 프로세스

 

“프로그램”이란?

- 프로그래밍한 원시 코드(source code)

 

“소프트웨어”의 “정의”

- 프로그램(코드)을 비롯해 개발 과정에서 생성되는 모든 산출물과 각 단계에서 만들어지는 문서와 사용자 매뉴얼 등 (자료 구조, 데이터베이스 구조, 테스트 결과 등)

 

“소프트웨어”의 “특징”

- 제조가 아닌 개발

((소프트웨어 개발 과정은 제조와 달리 개인 능력에 따라 차이가 큼. ))

- 소모가 아닌 품질 저하

(( 하드웨어와 달리 소프트웨어는 닳지 않으며 시간이 지나도 고장 빈도가 높지 않음. 사용 시작 단계부터 사용자의 요구가 계속 발생))

 

소프트웨어 공학의 학문적 정의

품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획을 세우고, 개발하며, 유지 및 관리하는 전 과정에서 공학, 과학 및 수학적 원리와 방법을 적용해 필요한 이론과 기술 및 도구들에 관해 연구하는 학문

 

소프트웨어 개발 생명 주기 (소프트웨어를 만들기 위해 일어나는 일련의 과정)

계획 => 분석 => 설계 => 구현 => 테스트 => 유지보수

 

“프로세스”란?

흔히 일을 처리하는 과정 또는 순서

주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 일련의 절차

---

소프트웨어 개발 프로세스의 “의미”

- 좁은 의미 : 소프트웨어 제품을 개발할 때 필요한 절차나 과정

- 넓은 의미 : 작업을 수행하는 데 필요한 방법과 도구를 비롯해 개발과 관련된 절차를 따라 작업을 수행하는 참여자 포함

---

소프트웨어 개발 프로세스의 “정의”

- 소프트웨어 개발 프로세스 모델은 소프트웨어를 어떻게 개발할 것인가에 대한 전체 흐름을 체계화한 개념

- 개발 계획 수립부터 최종 폐기까지의 전 과정을 순차적으로 다룸

---

소프트웨어 개발 프로세스의 “목적”

- 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의

- 고품질의 소프트웨어 제품을 만드는 것이 목적

---

소프트웨어 개발 프로세스의 “역할”

- 프로젝트에 대한 전체적인 기본 골격을 세워 일정 계획을 수립할 수 있고, 개발 비용 산정뿐 아니라 여러 자원을 산정하고 분배할 수 있음

- 참여자 간에 의사소통의 기준을 정할 수 있고 용어의 표준화를 가능하게 함

- 개발 진행 상황도 명확히 파악할 수 있고 각 단계별로 생성되는 문서를 포함한 산출물을 활용해 검토할 수 있게 함

---

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

- 주먹구구식 모델

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

- V모델

- 진화적 프로세스 모델

- 프로토타입 모델

- 나선형 모델

- 단계적 개발 모델

- 통합 프로세스 모델

- 애자일 프로세스 모델

---

{ 주먹구구식 모델 }

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

- 즉흥적 소프트웨어 개발(수정) 모델이라고도 함.

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

 

{ 주먹구구식 모델의 단점 }

- 관리 및 유지보수가 매우 어려움(정해진 개발 순서나 단계별 문서화된 산출물이 없기 때문)

- 프로젝트 전체 범위를 알 수 없으며, 좋은 아키텍처를 만들 수 없음.

- 개발자가 일을 효과적으로 나눌 수 없음.

- 프로젝트 진척 상황을 거의 파악할 수 없음.

- 수정을 반복하면서 가독성이 낮아짐 => 수정이 어려워짐.

---

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

- 선형 순차적 모델 폭포에서 물이 떨어지듯이 다음 단계로 넘어가는 모델(고전적 생명 주기)

- 소프트웨어 공학의 대명사로 여겨질 만큼 초기에 개발된 전통적인 모델

- 표준 프로세스를 정해 소프트웨어를 순차적으로 개발

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

- 각 단계의 끝마다 확실하게 마무리하여 결과 확인 후 다음 단계 진행

- (요구사항) 분석단계가 끝나면 “요구 분석 명세서” 작성.

- 명세서를 기준으로 사용자에게 이상 유무를 확인받고 다음 단계로 진행

 

{ 폭포수 모델의 장점 }

- 관리가 용이, 체계적으로 문서화 가능.

- 요구사항의 변화가 적은 프로젝트에 적합.

 

{ 폭포수 모델의 단점 }

- 각 단계는 이전 단계가 완료되어야만 수행 가능.

- 각 단계의 결과물이 완벽한 수준이어야 다음 단계에 오류를 넘겨주지 않음

- 사용자가 중간에 가시적인 결과를 볼 수 없음.

---

{ V모델 }

- 폭포수 모델의 변형. (테스트 단계를 추가)

- 산출물 중심인 폭포수 모델과 달리 V모델은 각 개발 단계 검증 중심(오류를 줄일 수 있음)

- “구현”을 중심으로 좌측은 분석.설계 단계, 우측은 테스트. (V모양)

---

{ 진화적 프로세스 모델 }

- 폭포수 모델과 달리 요구사항의 변화가 많아도 민첩하게 대응 가능

- 초기 사용자 요구에 따라 가상으로 실행되는 초기 버전의 프로토타입 작성

- 사용자는 UI(User Interface) 중심의 화면과 실행 후 가상의 결과 화면 확인

- 변경된 요구사항 반영 => 2차 프로토타입 생성 => 사용자에게 보여줌. 이 과정을 반복.

---

{ 프로토타입 모델 }

- 정식 절차에 따라 완전한 소프트웨어를 만들기 전에 사용자의 요구대로 모형을 먼저 만들고, 사용자와 의사소통하는 도구로 활용.

- 프로토타이핑? : 프로토 타입을 만드는 것.

- 사용자는 1차 프로토타입을 보면서 추가/수정 요구. 개발자는 요구를 수용하여 2차 프로토타입 제작.

 

{ 프로토타입 모델의 장점 }

- 프로토타입이 개발자와 사용자 간의 의사소통 도구로 사용되어 구체적이고 원활하게 대화가 가능.

- 요구사항을 여러 번 반복하는 과정을 통해 사용자의 요구가 충분히 반영된 요구 분석 명세서를 만들 수 있음.

- 사용자의 요구가 충분히 반영되므로 유지보수가 원활.

 

{ 프로토타입 모델의 단점 }

- 반복적인 소프트웨어 개발 단계로 인해 투입 인력, 비용 산정이 어려움.

- 프로토타입만 보고 결과가 곧 나올 것으로 사용자가 착각할 수 있음.

- 중간 점검을 할 수 없음(산출물 X) => 프로토타이핑 과정을 관리.통제하기 어려움.

- 개발 범위가 명확하지 않아 개발 목표, 종료 시점이 불명확해질 수 있음.

---

{ 나선형 모델 }

- 폭포수 모형의 장점 + 프로토타입 모형의 장점 + 위험 분석 기능 추가.

- 시스템을 개발하면서 생기는 위험을 최소화하기 위해 나선 모양으로 돌면서 점진적 개발

{ 나선형 모델의 개발 절차 }

① 계획 및 요구분석 ② 위험 분석 ③ 개발 및 검증 ④ 사용자 평가

[ 개발하기 전 위험 분석을 하여 예방 대책을 세움. 마지막은 사용자 평가. ]

 

{ 나선형 모델의 장점 }

- 위험을 먼저 의식하고 개발 => 프로젝트 중단 등의 위험성이 비교적 적음

- 사용자 평가가 반영된 반복적 개발 방식 => 사용자 불만이 적음

 

{ 나선형 모델의 단점 }

- 나선 모양의 점진적 개발(반복적) => 프로젝트 기간이 연장될 수 있음.

- 반복 횟수가 많아질수록 프로젝트 관리가 어려움

 

{ 단계적 개발 모델 }

- 개발자가 먼저 릴리스 1 개발 후 사용자에게 제공.

- 사용자가 릴리스 1을 사용하는 동안 릴리스 2 개발

- 개발과 사용을 병행하는 과정을 반복

- 릴리스 구성 방법에 따라 ( 점증적 / 반복적 ) 개발 방법으로 나뉨.

 

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

- 중요하다고 생각되는 부분부터 차례로 개발.

 

단계적 개발 모델 – 반복적 개발

- 초기에 시스템 전체를 일차적으로 개발 후 보강을 반복.

---

{ 애자일 프로세스 모델 }

- 고객의 요구에 민첩하게 대응, 그때그때 주어지는 문제를 풀어나가는 방법

- 가벼운 프로세스 방법론의 공통적인 특성을 정의

- 단계적 개발 모델과 비슷하지만, 더 빠른시간 안에 사용할 수 있도록 함.

 

{ 애자일의 기본 가치 }

- 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시

- 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시

- 계약과 협상 중심이 아닌, 고객과의 협력을 중시

- 계획 중심이 아닌, 변화에 대한 민첩한 대응(능동적 대처) 중시

---

{ XP 방식이란?(eXtreme Programming) }

- 애자일 프로세스 모델 中 하나.

- XP의 5가지 가치 : [ 의사소통 / 단순성 / 피드백 / 용기 / 존중 ]

---

{ UP 모형이란?(Unified Process) }

- UML. 객체 지향 분석 및 설계를 지원하기 위한 다이어그램.

- 소프트웨어 개발 단계를 시간의 흐름에 따라 [ 도입. 상세. 구축. 이행 ]으로 나눔.

- 사용자 요구 즉시 파악 가능

---

{ 스크럼 방식이란? }

- 애자일 프로세스 모델 中 하나.

- 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점

- 경험적 관리 기법 中 하나.

- 구체적인 프로세스를 명확하게 제시하지 않음.

 

{ 스크럼 방식의 진행 과정 }

제품 기능 목록 작성 – 사용자 스토리 산정

스프린트 계획 회의

스프린트 수행 – 일일 스크럼 회의, 스프린트 진척 관리(소멸 차트, 스프린트 현황판 사용)

스프린트 개발 완료 – 제품 기능 목록 작성

스프린트 완료 후 – 스프린트 검토 회의, 스프린트 회고

((스프린트 회고 : 단점보다는 강점을 찾아 극대화. 해결 방안을 찾지 않음. 단지 문제점 확인 및 기록.))

 

{ 스크럼 방식의 장점 }

- 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있음.

- 일일 회의를 통해 팀원들 간 신속한 협조와 조율이 가능

- 다른 개발 방법론에 비해 단순하고 실천 지향적

- 프로젝트의 진행 현황을 볼 수 있음 => 신속한 목표. 결과 추정 가능, 변화 시도 가능.

 

{ 스크럼 방식의 단점 }

- 일일 스크럼 회의 시간(15분)이 넘어가면 작업에 방해를 받을 수 있음.

- 프로세스 품질을 평가하지 않음 => 품질의 정도를 알 수 없음.

---

{ 테일러링이란?(Tailoring) }

- 프로젝트 상황 특성에 맞게 정의된 소프트웨어 개발 방법론 절차, 사용기법등을 [ 수정 및 보완 ]하는 작업.

- 테일러링의 내부적 요건(내부 기준) : 목표 환경, 요구사항, 프로젝트 규모, 보유 기술

- 테일러링의 외부적 요건(외부 기준) : 법적 제약사항, 표준 품질 기술