요구사항 확인 | 소프트웨어 개발 방법론

01. 요구사항 확인

Chapter 01. 소프트웨어 개발 방법론

 
 

1. 소프트웨어 개발 방법론 ⭐⭐⭐

(1) 소프트웨어 생명주기 모델 (SLDC; Software Development Life Cycle) 

- 소프트웨어 생명주기는 시스템 요구분석부터 유지보수까지 전 공정을 체계화한 절차
- 시스템 개발부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떤 순서를 밟는지 작업 프로세스 모델화
 

⚠️ 소프트웨어 개발 생명주기
요구사항 수집/분석, 설계, 구현(코딩), 테스트, 유지보수까지의 생명주기를 가진다
→ 해당 생명주기 동안 최상 품질 유지를 위해 단계를 나눈 것이 생명주기 모델

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

 
✅ 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수
 

• 요구사항 분석

- 다양한 이해관계자의 요구사항 상충을 고려하여 신제품이나 변경 제품에 부합하는 요구와 조건을 결정하는 단계
- 개발 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계 
 
▶ 기능 요구사항 / 비기능 요구사항
 

• 설계

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

• 구현

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

• 테스트

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

• 유지보수

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

[2] 소프트웨어 생명주기 모델 종류

 

• 폭포수 모델 (Waterfall Model)

- 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후, 다음 단계로 넘어가는 모델
- 모형 적용 경험과 성공 사례가 많음
- 단계별 정의와 산출물 명확
 
▶ 절차 : 타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수
 
 

• 프로토타이핑 모델 (Prototyping Model)

- 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객 피드백 반영하여 소프트웨어 만들어가는 모델 
 

• 나선형 모델 (Spiral Model)

- 시스템 개발 시 위험 최소화를 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
 
▶ 절차 : 계획 및 정의 > 위험 분석 > 개발 > 고객 평가
 

• 반복적 모델 (Iteration Model)

- 구축대상을 나눠 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델
- 사용자 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델
 

📌 소프트웨어 생명주기 모델 종류

※ 폭프나반 : 폭포수 모델 / 프로토타이핑 모델 / 나선형 모델 / 반복적 모델

 

※ 가장 오래된 모델은 폭포수 모델이며 선형 순차적 모형으로 고전적 생명주기 모형이라고도 함

 

📌 나선형 모델 절차

※ 계위개고 : 계획 및 정의 > 위험 분석 > 개발 > 고객 평가

→ 닭고기(계) 위와 개고기가 맛있는 집

 
 
 
✔ 소프트웨어 생명주기 모델 간 비교

구분	폭포수 모델	프로토타이핑 모델	나선형 모델	반복적 모델
절차도	⑴ 요구사항 분석  ⑵ 설계 ⑶ 구현 ⑷ 테스트	⑴ 요구사항 분석 ⑵ 프로토타입 개발 ⑶ 프로토타입 평가 ⑷ 구현 ⑸ 테스트	⑴ 계획 및 정의 ⑵ 위험분석 ⑶ 개발 ⑷ 고객 평가	개발 대상 ▷ 분석 > 설계 > 구현 ▷ 분석 > 설계 > 구현 ▷ 분석 > 설계 > 구현
특징	순차적 접근	프로토타입  개발	위험분석, 반복 개발	증분방식으로 병행 개발
장점	이해가 용이 관리가 편리	요구분석 용이 타당성 검증 가능	위험성 감소와 변경에 유연한 대처	병행 개발로 인한 일정 단축 가능
단점	요구사항 변경이 어려움	프로토타입 폐기에 따른 비용 증가	단계 반복에 따른 관리 어려움	병행 개발에 따른 관리 비용 증가

 

※ '위험 감소' 단어가 들어가면 나선형 모델

 
 
 

---

 

 

(2) 소프트웨어 개발 방법론 (Software Development Methodology)

- 소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
- 소프트웨어를 하나의 생명체로 간주, 소프트웨어 개발 시작부터 시스템 사용하지 않는 과정까지 전 과정을 형상화한 방법론
 
 

 [1] 소프트웨어 개발 방법론 종류 

 

• 구조적 방법론 (Structured Development)

- 전체 시스템을 기능에 따라 나눠 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
- 프로세스 중심의 하향식 방법론
- 구조적 프로그래밍 표현을 위해 나씨-슈나이더만 (Nassi-Shneiderman) 차트 사용
 

➕ 나씨-슈나이더만 차트 특징

 

- 논리 기술에 중점을 둔 도형식 표현 방법

- 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현

- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합

 

• 정보공학 방법론 (Information Engineering Development)

- 정보시스템 개발에 필요한 관리 절차와 작업 기법 체계화한 방법론
- 개발주기 이용해 대형 프로젝트 수행하는 체계적 방법론
 

• 객체 지향 방법론 (Object-Oriented Development)

- '객체' 기본 단위로 시스템 분석 및 설계하는 방법론 
- 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
- 객체, 클래스, 메시지 사용
 

• 컴포넌트 기반 방법론 (CBD; Component Based Development)

- 소프트웨어 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 개발 기간 단축으로 인한 생산성 향상
- 새로운 기능 추가 쉬움 (확장성)
- 소프트웨어 재사용 가능
 

• 애자일 방법론 (Agile Development)

- 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템 개발할 수 있는 신속 적응적 경량 개발 방법론
- 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론
 

• 제품 계열 방법론 (Product Line Development)

- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어를 작성하는 데 유용한 방법론
 

📌 컴포넌트 (Component)
- 모듈화된 소프트웨어 시스템 구성 요소

 
 

[3] 애자일(Agile)

 

 

2020년 2회 
- 애자일 방법론은 절차보다 사람 중심으로 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 개발 기간이 짧고 신속
- 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아 유동적 개발 가능

애자일 방법론 개념도

 

※ 애자일 방법론은 필기, 실기 단골 문제로 출제되는 빈출 토픽!!
 
핵심 키워드 :  '유연하고 빠르게 개발하는 방법론' 
애자일 방법론 유형 기억하기!! : XP, 스크럼(SCRUM) 린(Lean) 등 

 
 

• 애자일 방법론 등장 배경

애자일 방법론은 기존 개발 방법론의 한계 극복 목적으로 등장

 

✔  소프트웨어 개발 환경의 변화 

• 소프트웨어 개발 트렌드가 모바일 환경으로 변화 
• 시장 적시성과 잦은 배포 중요성 부각

✔ 기존 개발 방법론의 한계

• 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움
• 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가 

 

• 애자일 방법론의 유형 - 2020년 3회

1. XP (eXtreme Programming)

 

- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

- 1~3주의 반복(Iteration) 개발주기

- 5가지 가치와 12개 실천항목 존재

 

• XP의 5가지 가치

① 용기(Courage) 

: 용기를 가지고 자신감 있게 개발

→ 코드 작성 전 테스트, 빠르게 피드백, 테스트에 부합하지 못한 코드 리팩토링할 수 있는 용기

 

② 단순성(Simplicity)

: 필요한 것만 하고 그 이상의 것들은 하지 않음

 

③ 의사소통(Communication)

: 개발자, 관리자, 고객 간 원활한 소통

 

④ 피드백(Feedback)

: 의사소통에 대한 빠른 피드백

 

⑤ 존중(Respect)

: 팀원 간 상호 존중

 

• XP의 12가지 기본 원리

① 짝 프로그래밍 (Pair Programming)

: 개발자 둘이서 짝으로 코딩

 

② 공동 코드 소유 (Collective Ownership)

: 시스템에 있는 코드 누구든지 언제라도 수정 가능

 

③ 지속적 통합 (CI; Continuous Integration)

: 매일 여러 번 소프트웨어 통합하고 빌드해야 한다는 원리

 

④ 계획 세우기 (Planning Process)

: 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지 알려주어야 한다는 원리 

 

⑤ 작은 릴리즈(Small Release)

: 작은 시스템 먼저 만들고, 짧은 단위로 업데이트한다는 원리

 

⑥ 메타포어(Metaphor)

: 공통적 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리

 

⑦ 간단한 디자인(Simple Design)

: 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리

 

⑧ 테스트 기반 개발 (TDD; Test Driven Development)

: 작성해야 하는 프로그램에 대한 테스트 먼저 수행하고 테스트 통과할 수 있도록 실제 프로그램 코드 작성한다는 원리

 

⑨ 리팩토링(Refactoring)

: 프로그램 기능 바꾸지 않으면서 중복제거, 단순화 등을 통해 시스템을 재구성한다는 원리

 

⑩ 40시간 작업(40-Hour Work)

: 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상 일하지 말아야 한다는 원리

 

⑪ 고객 상주(On Site Customer)

: 개발자의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리

 

⑫ 코드 표준(Cording Standard)

: 효과적 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리

 

※ XP 기본원리 중 TDD와 리팩토링은 단답형으로 출제될 수 있으니 개념 잘 알아둘 것!!

 

 

2. 스크럼 (SCRUM)

 

- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

 

① 백로그(Backlog)

제품과 프로젝트에 대한 요구사항

 

② 스프린트(Sprint)

2~4주의 짧은 개발 기간의 반복적 수행으로 개발품질 향상

 

③ 스크럼 미팅(Scrum Meeting)

매일 15분 정도 미팅, To-Do List 계획 수립

데일리 미팅(Daily Meeting)이라고도 함

 

④ 스크럼 마스터(Scrum Master)

프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람

 

⑤ 스프린트 회고(Spring Retrospective)

스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록

해당 스프린트가 끝난 시점이나 일정 주기로 시행

 

⑥ 번 다운 차트(Burn Down Chart)

남아있는 백로그 대비 시간 그래픽적으로 표현한 차트

보통 백로그는 수직축에, 시간은 수평축에 위치

 

📌스크럼(Scrum)
- 스크럼 프로세스는 백로그 나눈 후에 스크림 팀 구성
- 스프린트 회의 거쳐 2~4주 단위의 스프린트 수행
- 수행 중 매일 스크럼 미팅 수행
- 스프린트 끝난 후에 스프린트 회고 수행

 

 

3. 린(LEAN)

- 도요타 린 시스템 품질 기법 소프트웨어 개발 프로세스에 적용해서 낭비 요소 제거하여 품질 향상시킨 방법론

- JIT(Just in Time), 칸반(Kanban) 보드 사용

 

 

• 애자일과 전통적 방법론 비교

비교 대상	애자일 방법론	전통적 방법론
계획 수립	유동적 범위 설정	확정적 범위 설정
업무 수행	팀 중심 업무 수행	관리자 주도적 명령과 통제 개인 단위 업무 수행
개발 / 검증	반복 주기 단위로 소프트웨어 개발/검증	분석 / 설계 / 구현 / 테스트 순차적으로 수행
팀 관리	업무 몰입, 팀 평가	경쟁, 개별 평가
문서화	문서화보다 코드 강조	상세한 문서화 강조
성공 요소	고객 가치 전달	계획 / 일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입, 나선형

 

 

---

 

(3) 객체 지향 (Object Oriented) 분석 방법론

객체 지향은 실세계 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법

 

[1] 객체 지향 구성요소

 

1. 클래스(Class)

• 특정 개체 내에 있는 변수와 메서드를 정의하는 일종의 틀 
• 객체 지향 프로그래밍에서 데이터 추상화하는 단위
• 하나 이상의 유사 객체들을 묶어 하나의 공통된 특성 표현
• 속성은 변수의 형태로, 행위는 메서드 형태로 선언

2. 객체(Object)

• 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상
• 클래스에서 정의한 것을 토대로 메모리에 할당됨
• 객체마다 각각의 상태와 식별성 가짐

3. 메서드(Method)

• 클래스로부터 생성된 객체를 사용하는 방법
• 객체가 메시지를 받아 실행해야 할 객체의 구체적 연산
• 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산 기능

4. 메시지(Message)

• 객체 간 상호 작용하기 위한 수단
• 객체에게 어떤 행위하도록 지시하는 방법
• 객체 간 상호 작용은 메시지 통해 이루어짐
• 메시지는 객체에서 객체로 전달

5. 인스턴스(Instance)

• 객체 지향 기법에서 클래스 통해 만든 실제 실형 객체
• 클래스에 속한 각각의 객체
• 실제 메모리상에 할당

6. 속성(Property)

• 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별 정의
• 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값

 

※ 객체 지향 구성요소 중 클래스, 객체 개념 묻는 문제 자주 출제 !!

 

 

[2] 객체 지향 기법

 

1. 캡슐화(Encapsulation)

• 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계 만들고 필요 인터페이스만을 밖으로 드러내는 기법
• 결합도 낮아지고 재사용 용이
• 정보 은닉과 관계가 깊음
• 변경 발생 시 오류 파급 효과가 적음

2. 상속성(Inheritance)

• 상위 클래스 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법

3. 다형성(Polymorphism)

• 하나의 메시지에 대해 각 개체가 가지고 있는 고유 방법으로 응답할 수 있는 능력
• 상속받은 여러 개 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
• 오버로딩, 오버라이딩이 대표적

➕ 오버로딩(Overloading)

 

매개변수 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법

➕ 오버라이딩(Overriding)

 

상위 클래스에서 정의한 일반 메서드 구현을 하위 클래스에서 무시하고 재정의할 수 있는 기법

 

3. 추상화(Abstraction)

• 공통 성질을 추출하여 추상 클래스를 설정하는 기법

 

4. 정보 은닉(Information Hiding)

• 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술 
• 필요하지 않은 정보는 접근할 수 없도록 하여 한 모듈 또는 하부 시스템이 다른 모듈 구현에 영향 받지 않게 설계
• 모듈 사이 독립성 유지에 도움을 줌

 

5. 관계성(Relationship)

•  두 개 이상 엔티티 형에서 데이터 참조하는 관계 나타내는 기법
• 종류는 연관화, 분류화, 집단화, 일반화, 특수화가 있음

  ① 연관화(Association) 

   - is-member-of 관계

   - 클래스와 객체 참조 및 이용관계

   - 같은 계층에 속하는 클래스들 사이 상호 의존성 보여주는 비계층적 관계성 

 

  ② 집단화(Aggregation)

   - is part of 관계, part-whole 관계

   - 서로 관련 있는 여러 개 객체 묶어 한 개 상위 객체 만드는 특징 있음

   - 일반화와 달리 상위 클래스의 성질들이 하위 클래스로 상속되지는 않음

 

  ③ 분류화(Classification)

   - is-instance-of 관계

   - 공통 속성에 의해 정의된 객체 구성원들의 인스턴스

 

  ④ 일반화(Genralization)

   - is-a 관계

   - 클래스들 간 개념적 포함 관계

 

  ⑤ 특수화(Specialization)

   - is-a 관계

   - 상위 클래스 특성들을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고 자기 자신의 고유 특성을 갖는 관계

 

 

📌 객체 지향 기법

※ 캡상다추정관 : 캡슐화 / 상속성 / 다형성 / 추상화 / 정보 은닉 / 관계성

 

 

⚠️ 오버로딩(Overlading)과 오버라이딩(Overriding)의 차이점

 

1. 오버로딩 (Overloading)

 

void fn(int a);

void fn(char a);

void fn(int a, int b);

 

▶ 매개변수 유형과 개수를 다르게 하여 같은 이름의 메서드를 여러 개 가지는 기법

 

2. 오버라이딩 (Overriding)

 

class A{   void fn(int a);}class B : public A{   void fn(int a);}

 

▶ B 클래스는 A 클래스를 상속 받는다

    상위 클래스(부모 클래스)가 가지고 있는 메서드를 하위 클래스(자식 클래스)가 재정의해서 사용하는 기법 

 

 

[4] 객체 지향 설계 원칙(SOLID) - 2022년 2회

 

1. 단일 책임의 원칙 (SRP; Single Responsibility Principle)

• 하나의 클래스는 하나의 목적을 위해 생성
• 클래스가 제공하는 모든 서비스는 하나의 책임 수행에 집중되어 있어야 한다는 원칙
• 객체 지향 프로그래밍 5원칙 중 나머지 4원칙의 기초 원칙

 

2. 개방 폐쇄 원칙 (OCP; Open Close Principle)

• 소프트웨어 구성요소(컴포넌트, 클래스, 모듈, 함수) 는 확장에 열려 있고 변경에는 닫혀있어야 한다는 원칙 

 

3. 리스코프 치환의 원칙 (LSP; Liskov Substitution Principle)

• 서브 타입(상속받은 하위 클래스)은 어디서나 자신 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙

 

4. 인터페이스 분리의 원칙 (ISP; Interface Segregation Principle) 

• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
• 객체 설계 시 특정 기능에 대한 인터페이스는 그 기능과 상관없는 부분이 변해도 영향을 받지 않아야 한다는 원칙

5. 의존성 역전의 원칙 (DIP; Dependency Inversion Principle)

• 객체에서 어떤 클래스를 참조해서 사용하는 경우, 그 클래스를 직접 참조하는 것이 아니라 그 대상 상위 요소인 추상 클래스나 인터페이스로 참조하라는 원칙

 

📌 SOLID
S : 단일 책임의 원칙
O : 개방 폐쇄 원칙
L : 리스코프 치환의 원칙
I : 인터페이스 분리 원칙
D : 의존성 역전 원칙

 

 

 

[5] 객체 지향 분석(OOA; Object Oriented Analysis) 의 개념

 

- 사용자 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법

 

 

[6] 객체 지향 분석 방법론 종류

 

1. OOSE (Object Oriented Software Engineering) - 야콥슨(Jacobson)

• 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용하는 방법론
• 분석, 설계, 구현 단계로 구성
• 기능적 요구사항 중심의 시스템

 

2. OMT (Object Modeling Technology) - 럼바우(Rumbaugh)

• 그래픽 표기법 이용 소프트웨어 구성요소 모델링하는 방법론
• 분석 절차는 객체 모델링 > 동적 모델링 > 기능 모델링 순서 

   ① 객체 모델링 (Object Modeling)

    - 정보 모델링(Information Modeling)이라고도 함

    - 시스템에서 요구하는 객체 찾고 객체들 간 관계 정의하여 ER 다이어그램 만드는 과정까지의 모델링

    - 객체 다이어그램 활용하여 표현

 

   ② 동적 모델링 (Dynamic Modeling)

    - 시간 흐름 순서에 따라 객체들 사이 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링

    - 상태 다이어그램 활용하여 표현

 

   ③ 기능 모델링 (Functional Modeling, Function Modeling)

    - 프로세스들의 자료 흐름 중심으로 처리 과정 표현하는 모델링

    - 자료 흐름도(DFD) 활용하여 표현

 

 

3. OOD (Object Oriented Design) - 부치(Booch)

• 설계 문서화 강조하여 다이어그램 중심으로 개발하는 방법론
• 분석과 설계 분리가 불가능
• 분석하는 데 이용된 객체 모델 설계 시 적용

 

4. 코드-요든 (Coad-Yourdan) 방법론

• E-R 다이어그램 사용하여 객체 행위 모델링
• 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성되는 객체 지향 분석 방법

 

5. 워프-브록 (Wirfs-Brock) 방법론

• 분석과 설계 간 구분이 없고 고객 명세서 평가해서 설계 작업까지 연속적으로 수행하는 분석 방법