1. 소프트웨어 공학 - 3. 개발방법론

728x90

반응형

SMALL

3. 개발방법론

1. 나선형 모형

2. 하향식/상향식 설계

3. HIPO, V 모델, 애자일

4. XP 핵심가치

5. XP 12 실천 사항

6. 정형 기술 검토

---

소프트웨어 생명주기 (Software Life Cycle)

- 소프트웨어 제품의 개념 형성에서 시작하여 운용/유지보수에 이르기까지 변화의 모든 과정이다.

- 타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수

---

폭포수 모형(Waterfall Model)의 개요

선형 순차적 모델이라고도 하며 Boehm이 제시한 고전적 생명주기 모형으로, 소프트웨어 개발 과정의 각 단계가 순차적으로 진행되는 모형이다.

- 전통적인 방법이지만, 쉽고 간단한 방법이어서 현재에도 많이 쓰이고 있다.

---

1. 나선형 모형(Spiral Model) ☆

(컴퓨터 쪽에서 아인슈타인보다 유명한) Bohem이 제시하였으며, 반복적인 작업을 수행하는 점증적 생명주기 모형이다.

- 점증적 모형, 집중적 모형이라고도 하며 유지보수 과정이 필요 없다. 

- 소프트웨어 개발 중 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적이다.

- 나선을 따라서 돌아가면서 각 개발 순서를 반복하여 수행하는 점진적 방식으로 누락된 요구사항을 추가할 수 있다.

기존 폭포수모형은 계획하고 코딩해 버리지만 나선형은 계획수립 이후 위험분석을 한다.

내가 만들려고 하는 것이 문제가 있는지 없는지 1차적으로 본다.

 

나선형 모형의 개발 단계 (이 과정을 반복한다.)

1단계. 계획 수립

기능, 제약 등의 세부적 계획 단계이다.

 

2단계. 위험분석

위험 요소 분석 및 해결 방안 설정 단계이다.

 

3단계. 개발과 검증

기능 개발 및 검증 단계이다. 

 

4단계. 고객 평가 및 다음 단계 수립

결과물 평가 및 추후 단계 진행 여부를 결정하는 단계이다.

 

---

2. 하향식과 상향식 설계 ☆

하향식 설계

소프트웨어 설계 시 제일 상위에 있는 Main User Function에서 시작하여 기능을 하위 기능들로 나눠 가면서 설계하는 방식이다.

하향시 설계 예) 은행어플을 만들 때

Main Function은 이체 기능이다.

하위 기능은 조회, 문자 전송, 알림, 대출이율 안내, 등 부수적인 기능

 

 

상향식 설계

가장 기본적인 컴포넌트를 먼저 설계 한 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 방식이다. 

---

프로토타입 모형 (Prototype Model)의 개요

- 실제 개발될 시스템의 견본(Prototype)을 미리 만들어 최종 결과물을 예측하는 모형이다.

- 개발이 완료되고 나서 사용을 하면 문제점을 알 수 있는 폭포수 모형의 단점을 보완하기 위한 모형으로 요구사항을 충실 반영할 수 있다.

---

3. HIPO (Hierarchy Input Process Output) ☆

- 대표적인 하향식 소프트웨어 개발을 위한 문서화 도구이다.

- 입력, 처리, 출력으로 구성되는 시스템 분석 및 설계와 시스템 문서화용 기법이다. 

- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

- 보기 쉽고 이해하기 쉬우며 유지보수가 쉽다.

 

일반적으로 3가지로 구성된다.

1. 가시적 도표 (Visual Table of Contents)

전체적인 기능과 흐름을 보여주는 구조이다.

 

2. 총체적 다이어그램 (Dverview Diagram)

 

3. 세부적 다이어그램 (Detail Diagram)

 

HIPO - IT위키 (itwiki.kr)

---

3-1. V- 모델 ☆

1. 폭포수 모형에 시스템 검증과 테스트 작업을 강조 한 모델이다.

2. 세부적인 프로세스로 구성되어 있어서 신뢰도 높은 시스템 개발에 효과적이다.

3. 개발 단계의 작업을 확인하기 위해 테스트 작업을 수행한다.

4. 생명주기 초반부터 테스트 작업을 지원한다.

5. 코드뿐만 아니라 요구사항과 설계 결과도 테스트할 수 있어야 한다.

6. 폭포수 모형보다 반복과 재처리 과정이 명확하다.

7. 테스트 작업을 단계별로 구분하므로 책임이 명확 해진다.

 

v- 모델 과정

매 단계마다 테스트(검증 단계)를 한다.

1. 요구사항 분석을 가지고 테스트를 한다.

요구사항을 제대로 반영하였는지

 

2. 기능 명세 분석 -> 테스트

각각의 기능이 잘되는지

 

3. 설계 -> 테스트

설계가 잘 되었는지

 

4. 개발 -> 테스트

개발은 잘 되었는지

 

5. 단위 테스트 -> 테스트

코딩한 하나의 모듈을 테스트한다.

예) 은행어플

조회기능, 이체기능은 각각의 기능이다. 이것을 단위 모듈이라고 한다.

조회하는 거 테스트하고, 이체하는 거 테스트한다.

 

6. 통합 테스트 ->테스트

각각의 모듈 A, B,..

이 조회기능, 이체기능,.. 등을 통합하여 테스트한다.

 

7. 시스템 테스트 -> 테스트

컴퓨터에 설치를 해본다.

설치해서 제대로 동작하는지 본다. 

 

8. 인수 테스트 -> 테스트

고객이 원하는 기능인가를 본다.

---

3-2. 애자일(Agile) 개발 방법론 ☆

현재 많이 쓰고 있으며 특정 방법론이 아닌 소프트웨어를 빠르고 낭비 없이 제작하기 위해 고객과의 협업에 초점을 둔 것으로 소프트웨어 개발 중 설계 변경에 신속히 대응하여 요구사항을 수용할 수 있다.

절차와 도구보다 개인과 소통을 중요시하고 고객과의 피드백을 중요하게 생각한다.

 

소프트웨어가 잘 실행되는데 가치를 두며, 소프트웨어 배포 시차를 최소화할 수 있다.

짧은 릴리즈와 반복, 점증적 설계, 사용자 참여, 문서 최소화, 비공식적인 커뮤니케이션 변화

 

애자일

화살이 삐융 날아가는 것처럼, 민첩하고 빠른 것을 뜻한다.

 

대표적인 8가지 종류

1. 익스트림프로그래밍 (XP, eXtremeProgramming)

2. 스크럼(SCRUM)

3. 린(Lean)

4. DSDM (Dynamic System Development Method, 동적 시스템 개발 방법론)

5. FDD (Feature Driven Development, 기능 중심 개발)

6. Crystal 

7. ASD (Adaptive Software Development, 적응형 소프트웨어 개발 방법론)

8. DAD (Disciplined Agile Delivery, 학습 애자일 배포)

 

애자일 예) 은행에서 소프트웨어를 개발하고자 외주를 주면

전담 직원이 파견을 나가 모든 것을 확인한다. 

 

정치적으로 애자일 예) 미국 대사관

미국에서 일어나는 것을 국내 행정기관에서 다 하기 어려우니깐 미국 대사관이 존재하는 것이다.

 

Agile 선언문 ☆

1. 프로세스나 도구보다 개인과의 소통이 더 중요하다.

2. 완벽한 문서보다 실행되는 소프트웨어가 더 중요하다.

3. 계약 협상보다 고객과의 협업이 더 중요하다.

4. 계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.

---

애자일 개발 방법론 中 XP (extremeProgramming)

1999년 Kent Beck이 제안하였으며, 개발 단계 중 요구사항이 시시각각 변동이 심한 경우 적합한 방법론이다.

소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법

 

요구사항을 모두 정의해 놓고 작업을 진행하는 것이 아니라, 요구사항이 변경되는 것을 적용하는 방식으로 예측성보다는 적응성에 더 높은 가치를 부여한 방법이다.

- 고객의 참여와 개발 과정의 반복을 극대화하여 생산성을 향상하는 방법이다. 

- 요구에 맞는 양질의 소프트웨어를 신속하게 제공하는 것을 목표로 한다.

---

4. XP 핵심가치 ☆

1. 소통 (Communication)

개발자, 관리자, 고객 간의 원활한 소통을 지향한다.

 

2. 단순성 (Simplicity)

부가적 기능 또는 미사용 구조와 알고리즘은 배제한다.

 

3. 피드백 (Feedback)

소프트웨어 개발에서 변화는 불가피하다. 이러한 변화는 지속적 테스트와 통합, 반복적 결함 수정 등 빠르게 피드백한다.

 

4. 용기 (Courage)

고객 요구사항 변화에 능동적으로 대응한다.

 

5. 존중 (Respect)

개발 팀원 간의 상호 존중을 기본으로 한다.

---

XP Process

XP Process

User Strories

일종의 요구사항으로 UML의 유즈케이스와 같은 목적으로 생성되나 형식이 없고 고객에 의해 작성된다는 것이 다르다.

 

Release Planning 

몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것으로 부분/전체 개발 완료 시점에 대한 일정을 수립한다.

 

Iteration

하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다. (4주가 넘어가지 않도록 한다.)

반복(Iteration) 진행 중 새로운 스토리가 추가될 때 진행 중 반복이나 다음 반복에 추가될 수 있다.

 

Acceptance Test

사용자 스토리에 작성된 요구사항을 확인하여 고객이 직접 테스트한다. 완료 후 다음 반복을 진행한다.

고객이 이건 아니 다하면 다시 Iteration 한다.

맞다 하면 다음 단계로 

 

Small Release

릴리즈 단위를 기능별로 세분화해서 고객의 반응을 기능별로 확인한다.

 

Spike☆

어려운 요구사항, 잠재적 솔루션을 고려하기 위해서 작성한 간단한 프로그램을 이야기한다.

---

5. XP의 12가지 실천 사항(Practice) ☆

구분 : Fine Scale Feed-Back (피드백)

1. Pair Program-ming (짝 프로그래밍)

- 두 사람이 짝이 되어 한 사람은 코딩을 다른 사람은 검사를 수행하는 방식이다.

- 코드에 대한 책임을 공유하고, 비형식적인 검토를 수행할 수 있다.

- 코드 개선을 위한 리팩토링을 장려하며, 생산성이 떨어지지 않는다.

 

2. Planning Game

게임처럼 선수와 규칙, 목표를 두고 기획에 임한다.

 

3. Test Driven Develop-ment

실제 코드를 작성하기 전에 단위 테스트부터 작성 및 수행하며, 이를 기반으로 코드를 작성한다.

 

4. Whole Team

(하나의 팀) 개발 효율을 위해 고객을 프로젝트 팀원으로 상주시킨다.

 

 

구분: Continuous Process (연속)

5. Continuous Integration (지속적인 통합)

상시 빌드 및 배포를 할 수 있는 상태로 유지한다.

 

6. Design Improvement

기능 변경 없이 중복성/복잡성 제거, 커뮤니케이션 향상, 단순화. 유연성 등을 위한 재구성을 수행한다.

 

7. Small Releases

짧은 주기로 잦은 릴리즈를 함으로써 고객이 변경사항을 볼 수 있게 한다.

 

 

 

구분: Shared Understand-ing (공유)

8. Coding Standards

소스 코드 작성 포맷과 규칙들을 표준화된 관례에 따라 작성한다.

 

9. Collective Code Ownerahip (공동 코드 소유권)

시스템에 있는 소스 코드는 팀의 모든 프로그래머가 누구든지 언제라도 수정할 수 있다.

 

10. Simple Design

가능한 가장 간결한 디자인 상태를 유지한다.

 

11. System Metaphor

최종적으로 개발되어야 할 시스템의 구조를 기술한다.

 

 

 

구분: Programmer Welfare

12. Sustainable Pace

일주일에 40시간 이상 작업 금지, 2주 연속 오버타임을 금지한다.

 

---

효과적인 프로젝트 관리를 위한 3대 요소

1. 사람(People) - 인적 자원

2. 문제(Problem) - 문제 인식

3. 프로세스(Process) - 작업 계획

 

어떤 문제가 있으면 그 문제를 처리하기 위한 과정과 사람들이 포함되는 것을 3P라고 한다.

---

6. 정형 기술 검토 지침 사항 (FTR) ☆

쉽게 생각해서 팀회의라고 생각하면 된다.

이 기능에 대해서 우리가 한번 토론해 보자. 회의실에 들어갈 때 어떤 마음으로 들어가야 되느냐에 대한 것이다.

1. 의제와 그 범위를 유지하라 (시간 길어질까 봐)

2. 참가자의 수를 제한하라 (이해관계자 외에는 들어오지 마라 쓸데없는 개꾼들어오면 대화가 산으로 간다.)

3. 각 체크 리스트를 작성하고, 자원과 시간 일정을 할당하라 (예) 한 시간 내에 끝내야 돼)

4. 개발자가 아닌 제품의 검토에 집중하라 

5. 논쟁과 반박을 제한하라. * 검토 과정과 결과를 재검토하라. (치고받고 말싸움하지 말아라)

---

문제풀이

 

1. 프로토타입을 지속적으로 발전시켜 최종 소프트웨어 개발까지 이르는 개발 방법으로 위험관리가 중심인 소프트웨어 생명주기 모형은?

나선형 모형

 

2. HIPO(Hierarchy Input Process Output)에 대한 설명으로 거리가 먼 것은?

① 상향식 소프트웨어 개발을 위한 문서화 도구이다.

② HIPO 차트 종류에는 가시적 도표, 총체적 도표, 세부적 도표가 있다.

③ 기능과 자료의 의존 관계를 동시에 표현할 수 있다.

④ 보기 쉽고 이해하기 쉽다.

 

1번

HIPO는 대표적인 하향식 기법이다.

 

3. 애자일 기법에 대한 설명으로 맞지 않는 것은?

① 절차와 도구보다 개인과 소통을 중요하게 생각한다.

② 계획에 중점을 두어 변경 대응이 난해하다.

③ 소프트웨어가 잘 실행되는데 가치를 둔다.

④ 고객과의 피드백을 중요하게 생각한다.

 

2번

계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.

 

4. 소프트웨어 생명주기 모형 중 고전적 생명주기 모형으로 순차적 모델이라고도 하며, 타당성 검토, 계획, 요구사항 분석, 구현, 테스트, 유지보수의 단계를 통해 소프트웨어를 개발하는 모형은?

① 폭포수 모형

② 애자일 모형

③ 컴포넌트 기반 방법론 

④ 6GT 모형

 

1번 

 

 

5. 애자일 개발 방법론이 아닌 것은?

① 스크럼(Scrum)

② 익스트림 프로그래밍 (XP : eXtreme Programming) 

③ 기능 주도 개발 (FDD : Feature Driven Development)

④ 하둡 (Hadoop)

 

4번

데이터 베이스 분석 도구이다.

 

1. XP(eXtreme Programming) 프로세스 단계 중에서 다음이 설명하는 단계명은 무엇인지 쓰시오.

- 하나의 릴리즈를 세분화한 단위이며 1~3주 단위로 진행된다.

- 반복(Iteration) 진행 중 새로운 스토리가 추가될 경우 진행 중 반복이나 다음 반복에 추가될 수 있다.

 

Iteration

 

2. 소프트웨어 프로젝트 관리를 효과적으로 수행하는데 필요한 3P에 해당하지 않는 것은?

① People

② Problem

③ Process

④ Possibility

 

4번

 

3. XP (eXtreme Programming)의 기본 원리로 볼 수 없는 것은?

① Linear Sequential Method

② Pair Programming

③ Collective Ownership

④ Continuous Integration

 

1번

 

4. XP (eXtreme Programming)의 5가지 가치로 거리가 뭔 것은?

① 용기

② 의사소통

③ 정형 분석

④ 피드백

 

4번

 

5. 애자일(Agile) 프로세스 모델에 대한 설명으로 틀린 것은?

① 변화에 대한 대응보다는 자세한 계획을 중심으로 소프트웨어를 개발한다. 

② 프로세스와 도구 중심이 아닌 개개인과의 상호소통을 통해 의견을 수렴한다.

③ 협상과 계약보다는 고객과의 협력을 중시한다.

④ 문서 중심이 아닌. 실행 가능한 소프트웨어를 중시한다.

 

1번

계획을 따르는 것보다 변경에 대한 응답이 더 중요하다.

---