22.소프트웨어 공학 요약 Part_2

June 10, 2024 27 분 소요

1. 디자인 패턴

행위 패턴

행위 패턴의 개요

반복적으로 사용되는 객체의 상호작용을 패턴화한 것
클래스나 객체가 상호작용하는 방법과 책임을 분산하는 방법을 정의
메시지 교환과 관련된 것으로 객체 간의 행위나 알고리즘 등과 관련된 패턴

행위 패턴의 종류

strategy 패턴(포켓몬)
state 패턴(선풍기)

strategy 패턴

자주 바뀌는 것이 기능이라면?

메서드를 클래스로 바꾸고 <<interface>> 타입의 상속 구조를 만들어라

Strategy 패턴: 객체가 수행할 수 있는 행동들을 캡슐화하고, 이 행동을 동적으로 교환할 수 있게 해주는 패턴입니다. 예시와 함께 이해하고, 어떤 상황에서 적합한지를 학습해야 합니다.

예제 프로젝트 이해(포켓몬 예시)

이 프로젝트의 특성은 포켓몬의 종류가 자주 추가되고 삭제된다는 점
기술이 발전함에 따라 성능 개선을 위해 기능(공격, 패시브)이 수정되기도 하고 새로운 공격 기술이 추가

20240603150028

일반적인 클래스 설계

모든 포켓몬이 공통으로 가지는 공격/패시브 기술은 상위 클래스의 attack()과 passive() 메서드로 놓고 하위 클래스에서 상속

20240603150304

20240603152919

문제: 기능 변화

문제점

기술이 발전함에 따라 공격과 패시브 기술이 계속 교체되지만 이에 대한 해결책이 없음
클래스 설계 원칙 중 OCP(개방 폐쇄 원칙) 를 위반하는 것일 뿐 아니라 프로그램을 복잡하게 만듬

해결책

자주 바뀌는 것이 무엇인지 찾아 그들을 별도의 상속 구조로 만들어 사용
자주 바뀌는 것이 attack(), passive()이기 때문에 이들을 클래스로 만들고 상속 구조로 설계
추가되는 공격 기술을 하위 클래스에 계속 추가할 수 있음

strategy 패턴을 적용한 클래스 설계

20240603153402

포켓몬의 종류를 계속 추가/삭제할 수 있도록 Pokemon 클래스를 상위 클래스, 포켓몬 종류를 하위 클래스로 배치한 상속 구조로 설계
Pokemon 클래스에서 메서드로 구현한 패시브Passive를 별도의 상속 구조로 만들어 사용

20240603153504

state 패턴

State 패턴: 객체의 상태에 따라 객체의 행동을 변경할 수 있는 패턴으로, 상태를 객체화하여 관리합니다. 상태 전환 과정과 실제 적용 사례를 공부해야 합니다.

자주 바뀌는 것이 상태라면?
상태를 클래스로 바꾸고 <<interface>> 타입의 상속 구조를 만들어라

예제 프로젝트 이해

처음의 선풍기는 정지와 송풍 기능만 있는 것
정지 상태에서 ON 버튼을 누르면 송풍 상태로 변하고 송풍 상태에서 OFF 버튼을 누르면 정지 상태로 변한
선풍기의 바람 상태에 Sleep, 약풍, 중간풍, 강풍이 계속 추가될 것

20240616210544

문제: 상태 변화

문제점

ElecFan 클래스에서는 조건문(if ~ else if)을 사용했는데 이 코드만으로는 상태의 변화를 쉽게 읽을 수 없음
상태(추가, 삭제)가 바뀌면 on_button(), off_button() 메서드에 이를 반영해야 하므로 계속해서 코드 수정이 필요
클래스 설계 원칙 중 OCP(개방 폐쇄 원칙)를 위반하는 것일 뿐 아니라 프로그램을 복잡하게 만들어 유지보수를 어렵게 함

-> 클래스를 상속구조로 만든다. 필요할 때 마다 호출하게 끔 한다.

해결책

자주 바뀌는 것이 상태(송풍, 정지, 수면, 약풍, 중간풍, 강풍 등)이므로 조건문으로 처리하던 상태를 클래스로 변경
클래스를 상속 구조(인터페이스 포함) 형태로 만들어 하위 클래스에서 상태를 추가 및 삭제할 수 있도록 만듬

state 패턴을 적용한 클래스 설계 (상태클래스 설계 <자주 변화하는="" 상태="">)

state 패턴 구조의 설계는 상태의 추가, 삭제 시 ElectricFan 클래스에 영향을 주지 않음
상태의 변화는 모두 오른쪽(상태를 클래스로 분리)에서만 이루어짐

"자주 변화하는 상태"  - 키워드 중요!

20240616211002

20240616210732

state 패턴 정리

state 패턴은 자주 바뀌는 상태를 클래스로 만들고 이를 <<interface>> 타입의 상속 구조로 만듬
상태의 변경이 그 안에서만 이루어지게 하여 주 클래스에 미치는 영향을 최소화하도록 설계한 패턴!

자주 변화한다면 클래스로 만들고 <<interface>> 타입 상속구조도 생성

20240603154256

2. 구조 패턴

구조 패턴

구조 패턴의 개요

프로그램 내의 데이터나 인터페이스의 구조를 설계하는 데 많이 활용할 수 있음
클래스나 객체의 구성(합성)으로 더 큰 구조를 만들어야 할 때 유용한 디자인 패턴

구조 패턴의 종류

decorator 패턴 (토스트)
adapter 패턴 (무선이어폰)
composite 패턴
bridge 패턴
facade 패턴
flyweight 패턴
proxy 패턴

decorator 패턴

변경 X, 추가 O

Decorator 패턴: 객체의 동작을 확장하거나 변경하지 않고, 동적으로 새로운 책임을 추가할 수 있는 패턴입니다. 구체적인 예시와 함께 어떻게 활용되는지를 이해하고, 장단점을 비교할 준비가 필요합니다. (ex) 토스트)

기본 클래스를 조합해서 많은 클래스를 만들어야 한다면?
많은 클래스를 조용히 처리하라!

decorator 패턴의 개요

너무 많아질 수 있는 장식을 ‘조용히(?) 어떻게 처리하는가’를 설명하는 디자인 패턴
decorator 패턴은 장식이 주인공으로 여기서의 주인공은 꼭 있어야만 하는 존재가 아니고 장식처럼 없어도 되는 존재

예제 프로젝트 이해

토스트를 판매할 때 칼로리를 계산해 알려주는 토스트 가게가 있음
현재 판매하는 메뉴는 치즈 토스트, 야채 토스트, 햄 토스트로 3종류
앞으로 재료도 늘어날 것이고 재료를 혼합한 토스트 종류도 늘어날 예정
기본 재료를 조합해 만드는 토스트의 종류를 하위 클래스로 계속 추가할 수 있는 상속 구조로 만든다면 기본 재료가 추가될 때마다 그것을 조합해 만들어지는 토스트의 종류 (클래스)는 수십 가지로 늘어날 것

decorator 패턴의 적용

Decorator 패턴을 적용하면 식빵은 상속 구조를 사용
빵의 종류가 늘어나는 것에 대해서는 Toast라는 상위 클래스를 만들고 하위 클래스에 식빵의 종류를 둠
decorator 패턴은 재료를 기본 재료(햄, 치즈, 달걀, 야채)와 복합 재료로 나누는 것부터 시작
핵심은 혼합 재료의 숫자만큼 클래스를 만들지 않고 기본 재료만 가지고 해결하는 것
기본 재료는 하위 클래스에 놓고 상위 클래스에 ToppiongDecorator 라는 이름의 클래스를 만듬
혼합 재료는 기본 재료를 계속 늘려 나가는 방식으로 프로그래밍

Tost toast1 = new NormalBread();  ➊
tost1.addToping(new Chesse());    ➋ 
tost1.addToping(new Ham());       ➌
tost1.serve();                    ➍

➊ Toast 타입의 일반식빵인 toast1 객체를 생성 ➋ ‘치즈’를 인자로 갖는 addTopping()을 호출 ➌ ‘햄’을 인자로 갖는 addTopping()을 호출 ➍ server()를 호출해 지금까지 name에 들어간 이름과 누적된 칼로리를 출력

20240615154438

20240615154453

20240615160150

decorator 패턴 정리

객체지향 방법에서는 객체를 안정적으로 추가/삭제할 수 있는 방법으로 상속을 많이 활용
상속 구조는 상위 클래스와 하위 클래스 간에 강한 결합으로 묶이게 되고 객체를 동적으로 확장할 때는 구현하기 쉽지 않음
구성(합성)은 객체를 실행하는 도중에 동적으로 확장한다는 장점
무분별한 장식의 추가로 인해 객체가 복잡해질 수 있다

<장점>
- 안정적으로 추가/삭제(상속) 
- 구성(합성)은 객체를 실행하는 도중 동적으로 확장

<단점>
- 상속구조는 상위, 하위 클래스간 강한 결합, 객체 동적 확장
-> 구현하기 쉽지 않다.
-> 무분별한 장식의 추가로 인해 객체가 복잡해질 수 있다 

adapter 패턴

Adapter 패턴: 인터페이스 호환성이 없는 클래스들을 함께 동작할 수 있도록 변환해 주는 패턴으로, 어떤 상황에서 필요한지와 실제 적용 방법을 학습해야 합니다.

구매한 컴포넌트가 맞지 않아 바로 사용할 수 없다면?
apdapter를 만들어 사용하라!

adapter 패턴의 개요

adapter의 의미: ‘접속 소켓’, ‘확장 카드’, ‘(물건을 다른 것에) 맞추어 붙이다’, ‘맞추다’
호환되지 않는 두 인터페이스를 작동시킬 수 있도록 만든 인터페이스 (버즈-에어팟)
adapter 패턴은 다음 두 가지 형태로 사용
- 클래스 adapter 패턴: 상속을 이용한 어댑터 패턴
- 인스턴스 adapter 패턴: 위임을 이용한 어댑터 패턴

예제 프로젝트의 이해

삼성 휴대전화에 무선 이어폰 Buds 대신 애플의 무선 이어폰 (Airpods)을 사용할 수 있도록 하는 것
두 이어폰의 기능은 재생과 멈춤으로 한정
Buds는 재생 기능에 play(), 멈춤 기능에 stop() 메서드를 사용
Airpods은 재생 기능에 playing(), 멈춤 기능에 stopping() 메서드를 사용

같은 기능이지만 동작할 수 있게 메서드가 다름

20240615160406

adapter 패턴의 적용

<<<interface>> 타입의 AirPodsInterface 클래스를 정의하고 그 메서드는 Buds에서 사용하는 play(), stop() 메서드와 같게 함
어댑터로 AirPodsAdapter 클래스를 만듬
AirPods 클래스로부터 상속을 받지만 AirPodsInterface 클래스로 인터페이스 구현으로 이루어졌기 때문에 자바에서 가능
어댑터
- 인터페이스
  - 기능

어댑터-인터페이스-기능

3. 생성 패턴

생성 패턴

생성 패턴의 개요

객체의 생성과 참조 과정을 추상화해 특정 객체의 생성 과정을 분리
누가 언제 변경하더라도 전체 시스템에 미치는 영향을 최소화하도록 만들어줌
코드의 유연성을 높일 수 있고 유지관리를 쉽게 만듬

생성 패턴의 종류

factory method 패턴 (게임서버)
singleton 패턴 (커피머신)
prototype 패턴
builder 패턴
abstract factory 패턴

factory method 패턴

Factory 패턴: 객체를 생성하는 인터페이스를 정의하고, 이를 구현 클래스가 결정하게 하는 패턴입니다. 다양한 Factory 구현 방식과 함께 어떤 상황에서 사용하는 것이 유리한지를 공부해야 합니다.

객체 생성을 직접 하지 않고 누군가에게 맡기고 싶다면?
factory method 패턴을 생각해보라

factory method 패턴의 개요

객체지향 언어를 사용하면 클래스에서 다른 클래스의 새로운 객체를 만들 때 두 클래스 사이에는 의존 관계가 발생
서로 간에 강한 결합을 이루게 되고 변경에 따른 영향을 받아 코드의 유연한 확장이나 변경 같은 유지보수를 어렵게 만듬
필요한 객체를 클래스에서 생성하지 말고 객체 생성만 전문으로 하는 클래스를 만들어 객체 생성을 모두 생성해 해결

factory method 패턴의 단계

1단계: 객체 생성을 담당하는 factory 클래스를 만들어 그곳에서 객체를 생성
2단계: 객체를 생성할 수 있는 메서드를 만들어 그 메서드가 factory 클래스 역할을 하도록 함 factory 클래스는 삭제

예제 프로젝트 이해

게임 서버는 게임의 종류가 늘어날 때마다 추가
하나의 게임을 선택하면 게임 서버는 ‘정상 연결’ 메시지와 함께 게임명, 게임 버전, ‘게임 실행 준비 완료’ 메시지를 화면에 띄움
추후에는 게임 서버도 국가별로 별도로 둘 예정이며 게임도 그 나라의 특성에 맞는 게임으로 수정할 예정

일반적인 클래스 설계

factory method 패턴을 사용하지 않는 경우

20240615161439

일반적인 클래스 설계

게임이 계속 추가되면 그때마다 GameServer 클래스를 수정해야함
클래스 설계 원칙 중 OCP(개방 폐쇄 원칙) 위반이고 디자인 패턴의 취지와 맞지 않음
객체 내부에서 다른 객체를 생성하면 객체 사이에 의존 관계가 발생

public SuperMario supermario = new SuperMario();
public Tetris tetris = new Tetris();

new는 컴파일 과정에서 객체를 생성하고 이를 메모리에 할당하는 역할
위에서는 supermario 객체를 생성하고 tetris 객체를 생성
다른 게임이 추가되면 마찬가지로 new를 사용해 객체를 생성할 것

factory method 패턴을 적용한 클래스 설계 - 1단계

20240615162053 20240615162114

게임의 종류는 Games라는 추상 클래스의 하위 클래스에 위치
새로운 게임 하나가 추가되면 GameServerFactory 클래스에서 객체를 생성하고 if 문에 추가
게임의 추가/삭제에 따른 변화가 GameServer에 영향을 미치지 않음

20240615162141

factory method 패턴을 적용한 클래스 설계 - 2단계

GameServer를 계속 추가할 수 있도록 KRGameServer와 JPGameServer로 GameServer를 확장
국가별 특성에 맞게 약간 수정한 KRSupermario, KRTetris, JPSupermario, JPTetris를 추가해 Games를 확장

1단계와의 차이점

① GameServer 확장을 고려한 상속 구조 ② 나라별 game 증가를 고려한 상속 구조 ③ GameServerFactory 클래스가 사라짐

20240615163601

factory method 패턴 정리

1단계: new를 사용하지 않고 객체를 생성하려면 객체를 생성할 수 있는 클래스를 만들어 모든 객체를 생성하도록 위임
2단계: factory 클래스의 역할(객체 생성)을 하나의 메서드를 상위 클래스에 만들어 그 메서드가 하도록 하고 이 메서드의 구현은 하위 클래스에게 위임

singleton 패턴

Singleton 패턴: 오직 하나의 인스턴스만을 갖도록 보장하며, 전역적으로 접근 가능한 인스턴스를 제공하는 패턴입니다. 다양한 구현 방법과 사용 사례를 학습하고, 멀티스레드 환경에서의 안전성 문제에 대비해야 합니다.

객체를 오직 1개만 만들어야 한다면?
singleton 패턴을 생각해보라!

singleton 패턴의 개요

의도적으로 단 하나의 객체만 생성하도록 하는 경우 사용
객체가 프로그램 내에서 오직 하나만 생성되도록 보장
객체를 하나만 생성해 사용하면 유용한 곳으로는 스레드 풀, 캐시, 로그 기록용 객체 등이 있음

예) 커피머신

일반적으로 작성하던 코드와 다른 점

1) 생성자가 private으로 선언 2) 객체를 생성할 때 static으로 선언

20240615163845

singleton 패턴을 사용하지 않은 일반 프로그램

실행을 해보면 객체가 3개 만들어지고 예상한 결과를 얻을 수 있지만 이는 운영체제의 병행 제어 장치의 영향 때문

20240615163859

singleton 패턴을 사용하지 않은 일반 프로그램 - Thread 사용

3명의 사용자가 원하는 음료를 내리고 완성된 것이 섞여 있고 결과가 다름
목적은 객체가 오직 1개만 생성되고 다른 사용자가 그것을 참조하도록 하는 것이므로 문제가 있음

20240615163945

singleton 패턴을 사용한 프로그램 - Thread 사용, 동기화 비사용

1) 생성자가 객체를 한 번만 생성하고 외부로부터 생성자를 호출할 수 없게 만듬 - EspressoMachine 클래스에서 생성자의 접근 제어자를 private으로 선언 2) 클래스 타입을 static(정적), private으로 선언 - 자신의 클래스 타입을 static(정적)으로 선언하고 외부에서 값을 변경하지 못하도록 private으로 선언 3) getInstance( ) 를 사용 - getInstance()를 만들어 사용하도록 함 - 외부에서는 EspressoMachine 클래스의 객체를 얻기 위해 getInstance()를 호출해 사용할 수밖에 없음

단점 - 스레드를 사용해 실행 결과를 보니 결과가 섞여서 출력

20240616213445

해결하기 위해 getInstance() 메서드를 동기화

20240616213514

singleton 패턴을 사용한 프로그램 - Thread 제거, 동기화 사용

① 생성자를 private으로 선언 ② 객체 생성을 static으로 선언 ③ getInstance()를 만들어 외부에서 사용하도록 함 ④ getInstance() 메서드를 동기화

singleton 패턴을 사용한 프로그램 (객체 생성을 처음부터)

synchronized 사용은 두 thread가 getInstance() 메서드를 동시에 실행시키는 것을 방지
동기화를 하면 속도가 떨어지는 문제가 발생하므로 public static EspressoMachine getInstance()처럼 처음부터 생성하여 해결
속도가 중요하지 않다면 public synchronized static EspressoMachine getInstance()처럼 getInstance() 메서드를 동기화해 메서드의 동시 실행을 막음

singleton 패턴을 사용한 프로그램 - DCL 사용

DCL을 구현하는 방법은 volatile을 사용

20240615164420

4. 구현

주요 표준 코딩 규칙(변수 선언, 상수에 관한 규칙, 수식과 문장에 관한 규칙 등)

표준 코딩 규칙의 필요성

표준화된 규칙의 예시

20240615170316

주요 표준 코딩 규칙

명칭에 관한 규칙

명칭은 31자 이내로 정한다

나쁜 예	좋은 예
int abcdefghijklmnopqrstuvwxyabcdef = 0;	int sum = 0;

변수명과 함수명은 다르게 사용한다

개발자가 코딩 중에 혼란스러울 수 있어 변수명과 함수명은 별도의 이름으로 구별

나쁜 예	좋은 예
int num;	int num;
int sum = 0;	int sum = 0;
int sum();	int getSum()

명칭의 규칙을 따른다

다른 프로그래밍 언어와 명칭이 호환되도록 특수 문자는 _(언더바)만 사용하고, 다음의 대소 문자 사용 규칙을 따름

매크로명 : _ 및 대문자 사용
상수명 : _ 및 대문자 사용
변수명 : 소문자로 시작
함수명 : 소문자로 시작, 첫 번째 단어는 동사(get, ..)로 작성
포인터명 : 참조하는 변수명의 첫 글자는 대문자 사용

나쁜 예	설명	좋은 예	설명
int num$sum = 0;	허용되지 않는 특수 문자 사용	int num sum = 0;	허용된 특수 문자 사용
`#define size 10`	매크로명에 소문자 사용	`#define SIZE 10`	매크로명에 대문자 사용
const int hight = 20;	상수명에 소문자 사용	const int HIGHT = 20;	상수명에 대문자 사용
int Sum = 0;	변수명이 대문자로 시작	int sum = 0;	변수명이 소문자로 시작
int Data(){}	함수명이 대문자로 시작, 동사로 시작X	int getData(){}	함수명이 소문자로 시작. 동사로 시작

포인터 변수명은 앞에 p를 붙인다

나쁜 예	좋은 예
int a = 0;	int a, sum = 0;
int *sum += a;	int *pSum = a;

명칭에 관한 규칙

소스 파일 하나는 200줄 이내로 작성한다

200줄이상: 문맥을 파악 및 파일 관리가 어렵고, 유지보수의 효율성이 저하

한 줄의 길이는 80자 이내로 작성한다

한 줄이 너무 길면 가독성이 떨어짐

함수의 내용은 70줄 이내로 작성한다

함수의 크기는 한 화면에 전체 내용이 보일 수 있도록 70줄 이내로 작성
함수가 너무 길어 화면이 분할되면 가독성이 떨어져 문맥을 파악하기가 어려움

여는 중괄호 { 는 문장의 끝에, 닫는 중괄호 }는 문장의 시작에 둔다

나쁜 예	좋은 예
if(a > b) { printf(“YES) }	if(a > b) { printf(“YES”) }

하나의 문장을 2줄로 작성하는 경우 다음 규칙을 따른다

80자가 넘어 쉼표(,) 가 오면 다음 문자는 새 줄로 시작
둘째 줄의 시작은 다음의 좋은 예처럼 이전 줄의 표현식과 같게 함

나쁜 예	좋은 예
int a = k(parameter A, parameter B, parameter C)	int a = k(parameter_A, prameter_B, parameter_C)

수준이 동일한 문장은 시작 위치를 맞춘다

수준이 같은 문장은 동일하게 들여쓰기를 하는 것이 좋음

나쁜 예	좋은 예
if(a > b) { x = a + b; return x; }	if(a > b) { x = a + b; return x; }

주석에 관한 규칙

코드의 첫 주석에는 다음 내용을 담는다

최초 작성자
최초 작성일
최초 변경일
목적
개정 이력(변경자, 변경 일자, 변경 내용)
저작권

메서드 정의 앞에 다음 내용을 주석으로 추가하고 시작한다

목적 : 함수의 용도(목적)
매개변수 : 함수의 인자로 사용되는 변수에 대한 설명
반환 값 : 함수의 결과 값에 대한 설명
변경 이력 : 함수를 변경한 변경자, 변경 일자, 변경 내용

원시 코드와 주석을 명확히 구분한다

원시 코드와 주석이 명확히 구별될 수 있도록 공백(또는 탭)을 두고 주석을 작성해야 눈에 잘 들어옴

원시 코드와 주석이 일치하게 한다

처음에는 원시 코드를 작성하면서 주석을 달아 서로 일치하지만 시간이 지나 원시 코드가 변경된다면 주석이 어긋나게 됨
주로 다음 내용을 주석으로 달고 원시 코드에 맞춰 계속 함
- 함수 인자에 대한 설명
- 복잡한 논리식
- 간단하지 않은 자료구조

변수 선언 및 자료형에 관한 규칙

용도가 같은 변수는 한 줄에 작성한다

용도가 같은 변수는 여러 줄로 쓰지 말고, 한 줄로 작성

나쁜 예	좋은 예
int a = 0; int b = 0;	int a = 0, int b =0;

필요한 변수만 선언한다

불필요한 변수는 개발자에게 혼란을 주어 이해하기 어렵게 만듬

나쁜 예	좋은 예
int a = 0; // a 변수를 사용하지 않는데 선언함	int a = 0; // a 변수 사용 functA(a);

배열 선언 시 요소 수를 명시하거나 초기화한다

배열 선언 시 배열의 요소 수를 알 수 있게 명확히 표시하거나 초기화를 통해 작성

나쁜 예	좋은 예
int score[ ];	int scrore[5]; int score[ ] = {1, 4, 7, 9, 10};

배열을 초기화할 때는 중괄호를 적절히 사용한다

중괄호를 적절히 사용하지 않으면 원시 코드의 가독성이 떨어져 초기화 값을 혼동할 수 있음

나쁜 예	좋은 예
int score[2][2] = {1, 4, 7, 9};	int score[2][2] = { {1,4}, {7,9} };

지역 변수는 선언 시 초기화한다

초기화를 하지 않으면 쓰레기 값으로 초기화될 수 있음

나쁜 예	좋은 예
int a; // 초기화 안 됨	int a = 0; // 초기화됨

부호 없는 자료형은 끝에 u를 붙인다

나쁜 예	좋은 예
`#define MIN 20;`	`$define MIN 10u;`

포인터 변수에 주소나 정수 값을 저장할 때는 자료형이 일치해야 한다

나쁜 예	좋은 예
int *pKim;	int *pKim;
char chi = ‘SU’;	int chi = ‘5’;
pKim = `χ`	pKim = `χ`

비트 필드는 unsigned/signed int형으로만 선언한다

만약 비트 필드를 다른 자료형으로 선언하면 동작이 정의되지 않아 원치 않은 결과를 얻을 수 있음

나쁜 예	좋은 예
struct st { char a : 2; unsigned int b : 3; };	struct st { unsigned int a : 2; unsigned int b : 3; }

상수에 관한 규칙

8진수는 사용하지 않는다

8진수로 표현하면 가독이 떨어짐

나쁜 예	좋은 예
int octal = 0377; // 8진수 표현	int hexa = 0xFF; // 16진수 표현 int chi = 10; // 10진수 표현

숫자 리터럴은 const 변수를 사용한다(C 언어의 경우)

원시 코드에 직접 표현(하드 코딩)한 숫자 리터럴은 그 의미를 파악하기 어렵게 함
값을 변경할 수 없는 const 변수 사용

나쁜 예	좋은 예
`int tri area = 10*5/2;` (삼각형 면적 = 밑변x높이/2)	const int base line = 10; const int hight = 5; int tri area = base line x hight / 2

상수는 부호 있는 자료형을 사용하고 부호 없는 자료형을 사용할 때는 u를 붙인다

나쁜 예	좋은 예
`#define SIZE 20;`	`#define SIZE 20u;`

수식에 관한 규칙

단항 연산자의 바른 표기

단항 연산자(++, –)는 피연산자와 붙여 써야 피연산자가 어떤 것인지 금방 알 수 있음

나쁜 예	좋은 예
a ++	a++

이항 연산자의 바른 표기

이항 연산자(+, -, *, /)는 전후에 공백을 넣어야 연산자와 피연산자가 명확히 구분되고 가독성도 높아짐
(dot) 연산자는 제외

나쁜 예	좋은 예
a=b+c+d;	a = b + c + d;

삼항 연산자의 바른 표기

삼항 연산자(?:)는 알아보기 쉽게 맨 앞의 수식을 괄호(( ))로 묶어줌

나쁜 예	좋은 예
a > b ? x: -x;	(a > b) ? x: -x;

증강 연산자의 바른 표기

증강연산자는 다른 줄에 써야 혼란을 초랳지 않고, 가독성을 높일 수 있음

나쁜 예	좋은 예
sum = kor + (++eng);	++eng; sum = kor + eng;

연산자가 3개 이상인 경우의 바른 표기

연산자가 3개 이상일 경우에는 우선순위를 쉽게 알 수 있도록 괄호로 묶어주는 것이 좋다

나쁜 예	좋은 예
if(a == 0&&b == 0)	if((a == 0) && (b == 0))

sizeof 인자의 바른 표기

수식을 sizeof 함수의 인자에 사용하지 않음

나쁜 예	좋은 예
sizeof(a = b + c)	sizeof(a)

문장에 관한 규칙

switch 문에서 case 문을 빠져나오기 위해 break 문을 사용한다

break 문이 없을 때는 다음 case 문으로 제어가 넘어간다는 사실을 주석으로 달아 주면 프로그램을 이해하는 데 도움이 됨

나쁜 예	좋은 예
case 1: statements case 2: ~~	case 1: statements // break 문이 case 2로 넘어감 case 2: ~~

switch 문에서 case 문이 다 끝나면 default 문을 넣어주어야 한다

만족하는 case 문이 없을 때 마지막 default 문에서 후속 처리를 해주기 위해서 default 문을 넣어줌

나쁜 예	좋은 예
case 1: statements break; case 2: statements break;	case 1: statements break; case 2: statements break; default;

goto 문을 사용하지 않는다

goto 문은 프로그램의 흐름을 복잡하게 만드는 주범이므로 가능하면 사용을 하지 않음

for 문을 제어하는 수식에 실수 값을 사용하지 않는다

for 문의 제어 인자로 실수 값 대신 정수 값을 사용하는 것이 좋음

나쁜 예	좋은 예
float i = 1.1 for(i = 1.1; i < 2.5; i = i + 0.1)	int i = 1 for(i = 1; i < 8; i = i++)

for 문을 제어하는 수치 변수의 바른 사용

계산에 사용하면 반복 횟수를 예측할 수 없게 되니 원래의 용도로만 사용해야 함

나쁜 예	좋은 예
int i = 0, j = 10 for(i = 0; i < 10; ++) i = i + j;	int i = 0, j = 10 for(i = 0, j = 10; i < j; i++, j++)

break 문은 가능하면 한 번만 사용한다

반복문에서 반복 중단을 위한 break 문을 여기저기에서 사용하면 프로그램의 동작을 예측하기가 어려움

나쁜 예	좋은 예
// 반복을 중단하기 위해 여러 번 break 문 사용 int i = 0; while(1){ if(i == 0){ break; } else if(i == 20){ break; } }	int i = 0; while(1){ if(i == 0) \|\| (i == 20){ break; } …. }

if ~ else 문의 끝은 else 문으로 종료한다

else 문으로 종료하지 않으면 문법적 오류는 아니지만 처리가 누락되어 원하는 결과가 나오지 않을 수 있음

나쁜 예	좋은 예
int score; char grade; printf(“점수 입력:”); scanf(“%d”, &score); if(score >= 70) printf(“PASS”);	int score; char grade; printf(“점수 입력:”); scanf(“%d”, &score); if(score >= 70) printf(“PASS”); else printf(“failure”);

5. 테스트

테스트 절차 및 계획: 테스트 목표와 전략을 설정하는 방법을 이해합니다.

테스트 절차 및 계획

테스트 절차

20240522140907

테스트 계획

테스트 목표를 정의하고, 테스트 대상 및 범위를 결정하며, 테스트 계획서를 작성하고 검토

20240522140937

테스트 목표 정의

테스트 대상 및 범위 결정

테스트 계획서 작성 및 검토

테스트의 목적, 담당 인원, 테스트 전략과 접근 방법 수립, 필요한 자원 및 자원 확보 일정, 실시할 테스트의 종류, 적용할 테스트 기법, 일정 등에 관한 정보를 기록
테스트 설계 기법을 정의하고, 도출된 테스트 케이스에 입력 값으로 사용 할 원시 데이터를 작성 20240522141304

테스트 케이스 설계 기법 정의

테스트 케이스 도출

원시 데이터 작성

결정된 테스트 케이스를 수행하기 위해 필요한 원시 데이터를 작성

테스트 실행 및 측정

테스트 환경을 구축하고 도출된 테스트 케이스를 이용해 테스트를 실시하고 테스트 실행 결과를 문서화

20240522141526

테스트 환경 구축

테스트 실행 및 측정

정의된 테스트 케이스를 실행하고 실행 결과를 측정
테스트가 끝나면 계획 대비 결과를 비교·분석하고 테스트 결과에 대한 보고서를 작성 20240522142140
테스트 결과 분석
테스트 활동을 통해 얻은 결과 값과 테스트 계획 단계에서 목표한 값을 비교
예정된 테스트 품질 목표가 달성되었는지를 비교·분석

보고서 작성 테스트 결과

분석을 기반으로 테스트 결과 보고서를 작성
테스트 보고서에는 테스트를 수행한 결과와 테스트를 수행하는 데 사용된 방법 등을 기술
결과에 따른 평가와 권고 사항도 기술

오류 추적 및 수정

테스트 결과 어디에서, 어떤 종류의 오류가 발생했는지 확인하고 수정 20240522144629

오류 수정 계획

테스트 결과 보고서를 기반으로 오류가 발생한 위치를 찾아냄
오류 수정 우선순위를 결 정해 오류 제거 계획을 설립

오류 수정

수정된 내용 검토

수정된 코드를 검토한 후 오류 수정 결과 보고서를 작성

프로그램 실행 여부에 따른 테스트

동적 테스트와 정적 테스트의 차이를 이해하고, 각 테스트 유형의 적절한 사용 사례를 공부합니다.

정적 테스트

자동차 수리시 보닛을 열어 부품 상태는 괜찮은지, 나사가 잘 조여 있는지 등을 면밀히 살펴보고 고장 난 곳을 찾음

20240616215000

정적 테스트: 그림처럼 프로그램을 실행하지 않고 코드를 검토하며 오류를 찾는 방법

동적 테스트

직접 주행하면서 엔진 소리가 필요 이상으로 크지는 않은지, RPM 수가 정상 수치보다 높게 올라가는지 확인
핸들의 떨림 현상이나 브레이크를 밞았을 때 밀리는 정도를 체크해 고장의 원인을 찾음

20240616215050

•동적 테스트: 그림처럼 프로그램을 실행하면서 찾는 경우

정적 테스트

프로그램 코드를 실행하지 않고 여러 참여자가 모여 소프트웨어 개발 중에 생성되는 모든 명세나 코드를 검토해서
실패보다는 결함을 찾아내는 방법

실패보다는 결함을 찾아낸다.

20240616215119

비정형방법

기술적 검토방법
- 개별 검토, 동료 검토, 검토 회의
관리적 검토방법
- 소프트웨어 검사, 감사
비공식 검토
공식 검토

공식 검토 수행절차

20240616215228

검토회의 수행: 본 회의에서 참석자들은 발견한 결함 내용과 결함의 처리 방법 등을 정리하고 문서로 작성

검토회의

•개발자가 소집한 전문가들에 의해 개발자의 작업을 검토 •3~5명 정도의 전문가(프로젝트 팀장, 다른 개발자, 품질 보증단장)들이 절차에 따라 평가 •설계 문서들이 고객의 요구 사항을 정확히 명시하고 있는지 여부, 작업 진척 상황 등 확인

소프트웨어 검사 (공식검토)

20240616215425

설계와 구현시 소프트웨어 검사 (설계 검사 / 원시 코드 검사)

명세 기반 테스트와 구현기반 테스트 구분

동적 테스트

명세 기반 테스트(블랙박스 테스트)

•의사는 몸속을 직접 열어 확인하는 것이 아니라 다양한 의료 장비를 통해 병의 원인을 찾음 •입력 값에 대한 예상 출력 값을 정해놓고 그대로 결과가 나오는지를 체크

신텍스 기법

•문법을 정해놓고 적합/부적합 입력 값에 따른 예상 결과가 제대로 나오는지 테스트

동등 분할 기법

•각 영역에 해당하는 입력 값을 넣고 예상되는 출력 값이 나오는지 실제 값과 비교

경계 값 분석 기법

경계에 있는 값을 테스트 데이터로 생성하여 테스트하는 방법

구현 기반 테스트

•위장 내시경 검사, 조직 배양 검사, 개복해서 어느 부위에 어떤 이상이 생겼는지 확인하며 병을 진단 •입력 데이터를 가지고 실행 상태를 추적함으로써 오류를 찾아내기 때문에 동적 테스트 부류에 속함 •프로그램 내부에서 사용되는 변수나 서브루틴 등의 오류를 찾기 위해 프로그램 코드의 내부 구조를 테스트 설계의 기반으로 사용

화이트박스 테스트 절차

코드의 내부구조와 동작을 검증하는 방법 -> 테스트 데이터를 생성

① 테스트 데이터 적합성 기준을 선정한다.

② 테스트 데이터를 생성한다. •테스트 데이터 적합성 기준을 근거로 한 가지 방법이 결정되면 명세나 원시 코드를 분석해 선정된 기준을 만족하는 입력 데이터를 만듬

③ 테스트를 실행한다. (테스트 방법) •문장 검증 기준 •분기 검증 기준 •조건 검증 기준 •분기/조건 검증 기준 •다중 조건 검증 기준 •기본 경로 테스트

테스트 분류

단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트, 회귀테스트 등 각 테스트의 목적과 적용 시점, 특징을 이해하며, 소프트웨어 품질 보증에 기여하는 방법을 학습합니다.

단위 테스트

단위 테스트(모듈 테스트)

•프로그램의 기본 단위인 모듈을 테스트 •구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 요구분석명세서대로 정확히 구현되었는지 테스트 •개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트 •한 모듈을 테스트하려면 그 모듈과 직접 관련된 상위 모듈과 하위 모듈까지 모두 존재해야 함

드라이버와 스텁

•테스트 드라이버: 상위 모듈의 역할을 하는 가상의 모듈, 테스트할 모듈을 호출하는 역할 •스텁: 하위 모듈의 역할을 하는 가상의 모듈, 테스트할 모듈이 호출할 때 인자를 통해 받은 값을 가지고 수행한 후 그 결과를 테스트할 모듈에 넘겨주는 역할 •드라이버와 스텁 모듈은 테스트할 때 필요한 기능만 제공할 수 있도록 단순하게 구현

20240616220204

단위 테스트 수행 후 발견되는 오류

•잘못 사용한 자료형 •잘못된 논리 연산자 •알고리즘 오류에 따른 원치 않는 결과 •틀린 계산 수식에 의한 잘못된 결과 •탈출구가 없는 반복문의 사용

통합 테스트

통합 테스트의 개요 (오류찾기)

•단위 테스트가 끝난 모듈을 통합하는 과정에서 발생할 수 있는 오류를 찾는 테스트 •‘모듈 간의 상호작용이 정상적으로 수행되는가’ 테스트 •모듈 사이의 인터페이스 오류는 없는지, 모듈이 올바르게 연계되어 동작하고 있는지 체크

모듈 통합 방법에 따른 분류

•한꺼번에 하는 방법: big-bang 테스트 •점진적으로 하는 방법: 하향식 기법, 상향식 기법

•Big-bang 테스트

•단위 테스트가 끝난 모듈을 한꺼번에 결합해 테스트를 수행하는 방식 •이 방법은 소규모 프로그램이나 프로그램의 일부를 대상으로 하는 경우가 많고 그만큼 절차가 간단하고 쉬움 •한꺼번에 통합하면 오류가 발생했을 때 어떤 모듈에서 오류가 존재하고 또 그 원인이 무엇인지 찾기가 매우 어려움

시스템 테스트

시스템 테스트의 개요

•시스템 전체가 정상적으로 작동하는지를 체크

•사용자에게 개발된 시스템을 전달하기 전에 개발자가 진행하는 마지막 테스트

•실제 사용 환경과 유사하게 테스트 환경을 만들고 요구 분석 명세서에 명시한 기능적, 비기능적 요구 사항을 충족하는지 테스트 (실제 사용 환경과 유사하게 테스트 환경을 만들기) •주로 부하를 주는 상황에서 수행하고, 비기능적 테스트를 중심으로 수행

인수 테스트

인수 테스트의 개요

•시스템이 예상대로 동작하는지 확인하고, 요구사항에 맞는지 확신하기 위해 하는 테스트 •시스템을 인수하기 전 요구분석명세서에 명시된 대로 모두 충족시키는지 사용자가 테스트 •인수 테스트가 끝나면 사용자는 인수를 승낙한 것 •시스템이 사용자에게 정상적으로 인수되면 프로젝트는 종료 •인수 테스트 시 인수 테스트 계획서는 사용자가 직접 작성하거나, 개발자가 작성한 것을 사용자가 승인

회귀 테스트

확정 테스트

•원시 코드의 결함을 수정한 후 제대로 수정되었는지 확인하는 테스트

회귀 테스트

•한 모듈의 수정이 다른 부분에 영향을 끼칠 수도 있다고 생각하여 수정된 모듈뿐 아니라 관련된 모듈까지 문제가 없는지 테스트 •한 모듈의 수정이 다른 부분에 미치는 영향을 최소화하기 위해 필요

6. 품질

SW 품질의 정의와 목표

소프트웨어 품질의 다양한 측면을 이해하고, 품질 향상을 위한 전략을 학습합니다.

품질과 소프트웨어 품질

품질

•물건이 얼마나 좋은지, 나쁜지를 나타내는 정도 •품질은 모든 제품에서 가장 중요한 요소이며, 소프트웨어 제품도 예외는 아님

하드웨어 품질

•사용자의 요구 사항을 규격서에 서술하고, 이 규격서대로 만들면 큰 문제가 없다. •만든 제품이 규격서대로 작동하는지 테스트하는 것도 비교적 용이 •개발된 제품이 규격서대로 만들어지면 사용자가 만족할 만한, 품질이 좋은 하드웨어

소프트웨어 품질

•소프트웨어는 하드웨어의 규격서에 해당하는 사용자 요구분석명세서가 있음 •하드웨어의 규격서보다 소프트웨어의 요구분석명세서를 작성하는 것이 훨씬 어려움

(HW) 규격서 < (SW) 요구분석명세서

•품질 좋은 소프트웨어: 프로그램에 결함이 없고 사용자의 요구를 정의한 요구분석명세서대로 만든 소프트웨어

20240616221112

20240616221143

개발 프로세스 평가 -> 개발 과정의 각 단계마다 평가

ISO/IEC 14598 모델

ISO/IEC 14598의 특성 (다른 평가자 동일 기준, 동일 결과)

•반복성: 특정 제품을 동일한 평가자(기관)가 동일 기준을 적용해 평가했을 때 동일한 결과가 나와야 함 •재생산성: 특정 제품을 다른 평가자(기관)가 동일 기준을 적용해 평가했을 때 동일한 결과가 나와야 함 •공정성: 평가가 특정한 결과를 내기 위해 불공정한 편견이 없어야 함 •객관성: 평가는 주관적 판단을 최소화하고 객관적 자료를 근거로 해야 함 •ISO/IEC 9126 표준 준수: ISO/IEC 9126에 규정한 표준을 준수 •규정하지 않는 내용: 품질 평가의 측정 기술, 측정 결과의 해석 방법 등은 규정하고 있지 않음

20240616221434

CMMI 의 개념과 특징

능력 성숙도 모델 통합에 대해 학습하고, 소프트웨어 프로세스 개선에 필요한 지식을 습득합니다.

표준 프로세스의 필요성

•표준 프로세스 •소프트웨어 개발에서 레시피, 하나의 매뉴얼, 내비게이션과 같은 역할 •조직원들이 우왕좌왕 해매는 시간을 줄여주고 생산성을 높임 •기준과 목표, 방향을 제시해주기 때문에 업무 처리 프로세스가 명확하고 계획적이며 결과를 충분히 예측할 수 있음

CMMI

CMMI(Capability Maturity Model Integration) •조직의 프로세스 개선을 위해 개발 •기업에 표준 프로세스를 만들 수 있는 지침을 제시하고, 그 기준을 제시

능력 성숙도 통합 모델

CMMI 모델의 특징

•프로세스 표준화의 기준과 방향을 제시하므로 조직 프로세스에 대한 측정 뿐 아니라 평가 지표로도 활용할 수 있음 •능력을 평가하거나 성숙도를 평가할 수 있음 •C(능력), M(성숙도), M(모델), I(통합) 의 의미

Capability(능력)

•능력: 개발 목표(주어진 기간, 정해진 비용, 고품질 등)를 달성할 수 있는 힘 •능력이 없는 조직은 개발 목표를 달성하지 못함

Maturity(성숙도)

•성숙(사전적 의미): ‘생물의 발육이 완전히 이루어짐’, ‘몸과 마음이 자라서 어른스럽게 됨’, ‘경험이나 습관을 쌓아 익숙해짐 •성숙도가 높은 조직은 책임감이 있는 조직 •개발 과정에서 객관적이고 정량적인 근거에 따라 프로세스가 측정되고 지속적인 개선이 이루어짐

능력은 좋지만 성숙도가 높지 않다면 전부 발휘할 수 없을 것

Model(모델)

•일반적으로 알고 있는 모델의 의미와 약간 달라, 프로세스를 검사하는 의미로 사용 •기준(수행지침) 대로 하고 있는지, 그렇지 않은지를 검사 •무엇을 해야할지 수행 지침을 통해서 알려주지만 구체적으로 어떻게 할지는 조직의 역량에 달림

Integration(통합)

•여러 가지 프로세스의 기준을 하나로 통합했다는 의미 •소프트웨어 개발 생명주기의 각 단계를 통합한 모델이라는 의미

단계적 표현 방법의 성숙 단계

20240616222044

품질 관리

품질 관리, 품질 통제, 품질 보증의 차이와 각 활동이 소프트웨어 품질에 미치는 영향을 학습합니다.

품질 관리

개발의 각 단계에서 일어나는 모든 활동과 활동 중에 생성되는 여러 산출물을 통제하고 보증해 품질을 관리하기 위한 활동 크게 통제와 보증으로 구분

품질 통제

•품질 절차와 표준을 개발자들이 준수하도록 프로세스를 정의하고 규정을 만드는 것 •소프트웨어를 개발하고 운영하며 유지보수하는 과정에서 사용자의 요구사항을 만족할 수 있는 품질 좋은 소프트웨어를 만들기 위함

품질 보증

•품질 보증의 정의: IEEE •개발된 소프트웨어가 사용자의 요구를 만족시킨다는 것을 보장하는 데 필요한 계획적이고 체계적인 활동 •개발된 소프트웨어가 기술적인 요구 사항과 일치하는가를 적절하게 확인하는 데 필요한 체계적이고도 계획적인 유형의 활동 •소프트웨어의 결함을 줄여 품질 좋은 소프트웨어를 만들기 위해, 사용자가 요구하는 품질 수준을 파악하고 이를 어떻게 달성할 수 있는지를 정의하는 개발 단계 전역에 걸친 체계적인 작업

-> 결합은 낮추고, 요구하는 품질 수준을 파악함

품질 보증

품질 보증 활동의 기대 효과

•개발 체계 및 품질 환경 적립 •명확한 요구 사항 정립 및 검토와 개발 기법의 표준화로 프로그램의 이해도 증진 •문서 작성의 표준화 유도와 품질 정보의 체계적 관리로 유사 문제점 재발 방지 •개발 시스템 품질 향상 •개발 초기 단계에서 문제점 발견 및 보완 •객관적 품질 평가로 사용성 증대

품질 보증 활동의 문제점

•품질 보증에 대한 인식이 부족 •품질 요원을 중요시하지 않는 시각에 따라 경험 많은 품질 보증 요원이 부족 •품질 보증에 대한 제도의 표준화와 절차 확립이 부족

7. 프로젝트 관리

프로젝트 이해 - PM(일정) -> 사람(갈등), 적재재소 -> 위험 : PM은 일정관리와 위험관리를 잘해야한다
형상관리 - 버전관리 -> 감사할 때 이상없다 : 형상관리는 버전관리 이므로 잘 해놓는다면 감사 진행이 문제없다
유지보수 - 소프트웨어도 유지보수를 해야한다

형상 관리

소프트웨어 구성 요소의 버전 관리와 변경 관리 방법을 이해하고, 개발 프로세스의 효율성을 높이는 방법을 익힙니다.

버전

소프트웨어에서 버전: 개발 단계 또는 순서를 번호로 표시한 것

버전 관리

•여러 명이 함께 작성한 내용을 서로 공유하며 작업을 할 경우 •누군가는 이전 버전의 파일로 계속 작업을 한다면 잘못된 결과를 얻음 •요구사항이 자주 변경되는 현실에서 버전 관리가 잘 되어야만 정확한 결과를 도출 할 수 있음

20240616223840

형상 관리 (통합, 일치 보장)

형상 관리: 특정 항목의 변화에 대해 관리하면서 시스템의 통합과 일치를 보장하는 것

20240616223925

형상 식별 / 형상 통제 / 형상 상태 보고
- 형상관리란 형상을 식별하고 통제하여 상태를 보고한다.
  형상 감사
  
  •계획서 대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구사항에 맞도록 제대로 이루어졌는지 등을 확인 •단계별 베이스라인의 적정성과 무결성을 평가하고 승인 •형상 담당자가 실시하며 형상 감사 수행 전에 형상 관리 계획서 상에 형상 감사를 위한 계획이 수립되어 있어야 함

감사 내용

•승인된 변경 요청이 제대로 반영되었는지 검증 •승인되지 않은 내용이 혹시 반영되었는지 검증 •승인된 변경과 관련된 항목들이 갱신되었는지 검증

소프트웨어 유지보수 (수,적,기,예)

수정 유지보수, 적응적 유지보수, 기능 보강 유지보수, 예방 유지보수의 차이와 각각의 목적을 학습합니다.

•소프트웨어에도 유지보수의 개념이 필요함 •몇 년 사용한 후에 보완하는 경우도 있지만, 개발이 완료되어 사용하기 시작할 때부터 수리해야 하는 경우도 발생

20240616224108

수정 유지보수

개발 된 소프트웨어를 사용자가 인도받은 후 사용하면서 발견되는 오류를 잡는 것
개발 과정에서 미쳐 바로잡지 못한 오류를 유지보수 단계에서 해결하는 것

적응 유지보수

개발된 소프트웨어가 처음 설치된 곳에서 문제없이 실행하다가 환경이 바뀌어도 이에 맞도록 수정,보완해주는 것

기능 보강 유지보수

변경이 필요할 때 하게 되는 유지보수

예방 유지보수

미리 예상되거나 예측되는 오류를 찾아 수정하는 것

프로젝트 매니저의 역할

프로젝트 계획, 일정 관리, 리스크 관리 등을 통해 프로젝트를 성공적으로 이끌어가는 데 필요한 역량을 학습합니다.

PM은 일정관리와 위험관리를 잘해야한다

프로젝트 정의

일정 기간 동안 목표를 달성하기 위한 프로젝트의 특성과 관리 방법을 이해하고, 프로젝트 진행 전략을 세우는 방법을 학습합니다.

프로젝트의 정의

•미국 프로젝트관리협회(PMI): 유일한 제품이나 서비스를 만들기 위해 일정한 기간을 정해 놓고 수행하는 작업 -> 기간을 정해놓아야 한다.

프로젝트의 특징

한시성: 프로젝트는 일의 시작과 끝이 명확히 정해져 있다. 따라서 일이 다 완성되지 않았어도 기간이 되면 끝내야 함
유일성: 프로젝트는 기간이 종료되었을 때 세상에 유일한 인도물을 만들어 냄
참여자의 일시성: 프로젝트를 수행에는 인력이 필요하고 그 인력은 동시에 참여하고, 그 프로젝트가 종료되면 해체됨
한정된 자원: 프로젝트가 시작되면 그 프로젝트를 성공적으로 수행하기 위해 인력과 장비를 그 기간 동안에 배정함

프로젝트 매니저(PM)

•프로젝트를 수행하는 데도 총괄하는 책임자 •프로젝트 시작 시점부터 기획을 하고 설계를 함 •프로젝트에 참여하는 팀원들의 장점과 능력을 잘 파악해 적재적소에 배치해야 함 •고객과의 많은 대화를 통해 의견을 조율해야 함 •프로젝트가 시작되면 진행 상황을 늘 체크해야 하고 진척 관리도 해야 함 •프로젝트 수행 중 크고 작은 문제가 발생하면 해결책을 고민해야 하고, 책임감을 갖고 해결해야 함 •인력 관리를 통해 참여자들이 도중 하차하는 일이 없도록 하고, 충분히 의사소통할 수 있는 분위기를 조성해야 함 •개발 기간 내에 최종 결과물을 고객에게 인도할 수 있어야 함

프로젝트 관리

프로젝트관리지식체계(PMBOK)

프로젝트와 관련된 대표적인 문서로 작업의 표준

20240616223155 시작-> 기획-> 실행-> 통제 -> 실행 -> 기획 -> 종료

프로젝트 관리의 9가지 관점

프로젝트 통합 관리

프로젝트의 여러 요소를 적절하게 통합하기 위한 프로세스들로 구성

프로젝트 범위 관리

프로젝트를 성공적으로 완료하는데 필요한 모든 작업을 프로젝트에 포함하기 위해 요구되는 프로세스들로 구성

프로젝트 일정 관리

프로젝트를 주어진 기간 내에 완료하기 위해 요구되는 프로세스들로 구성

프로젝트 비용 관리

주어진 예산 범위 안에서 프로젝트를 완료하기 위해 요구되는 프로세스들로 구성

프로젝트 품질 관리

사용자의 품질 요구를 만족시키기 위해 요구되는 프로세스들로 구성

프로젝트 인적 자원 관리

참여 인력들에 대한 지원과 팀 환경을 만들어주는 프로세스

프로젝트 의사 소통 관리

이해관계자들 간의 메시지를 누구에게, 언제, 어떻게 보낼 것인가를 결정하고 관리

프로젝트 위험 관리

프로젝트의 위험을 식별,분석,대응하기 위해 요구되는 6개 프로세스들로 구성

프로젝트 조달 관리

조직의 외부에서 물품과 서비스를 조달하기 위해 요구되는 6개의 프로세스로 구성

Twitter Facebook LinkedIn