정보처리기사, 실기 요약 정리 (1. 소프트웨어 구축)

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

 

프로젝트 계획 ► 요구 분석 ► 설계 ► 구현 ► 테스트 ► 유지보수

폭포수	선형 순차적 개발 / 고전적, 전통적 개발 모형 / 다시 전 단계로 되돌아가기 어려움
프로토타입	견본/시제품을 통해 최종 결과 예측 / 인터페이스 중심 / 요구사항 변경 용이
나선형	폭포수 + 프로토타입 + 위험 분석 기능 추가 / 점진적 개발 과정 반복 ★ 계획 수립 ► 위험 분석 ► 개발 및 검증 ► 고객 평가
★ 애자일	일정한 짧은 주기 반복하여 개발 진행 견본/시제품 존재 / 고객 소통, 상호작용 중시

 

하향식 설계

절차 지향 (순차적) / 최상위 컴포넌트 설계 후 하위 기능 부여

 

상향식 설계

객체 지향 / 최하위 모듈 먼저 설계 후 결합

인터페이스 구조 변경 시 모듈도 같이 변경이 필요하여 기능 추가가 어려움

* 컴포넌트(Component) : 명백한 역할을 가지며 재사용되는 모든 단위 / 인터페이스 통해 접근 가능

 

 

 

익스트럼 프로그래밍 (eXtreme Programming, XP)

고객의 요구사항을 유연하게 대응하기 위해 고객 참여와 신속한 개발 과정을 반복

 

[핵심 가치]

용기 / 단순성 / 의사소통 / 피드백 / 존중

 

[기본 원리]

전체 팀 / 소규모 릴리즈 / 테스트 주도 개발 / 계속적인 통합 / 공동 소유권 / 짝 프로그래밍 / 디자인 개선 / 애자일 방법론 활용

상식적 원리 및 경험 추구, 개발 문서보단 소스코드에 중점 (문서화 ✕)

 

---

► 프로젝트 계획

 

하향식 비용 산정 기법

전문가 감정 기법	조직 내 두명 이상의 전문가에게 비용 산정을 의회하는 기법 개인적 / 주관적 판단 가능
★ 델파이 기법	한 명의 조정자와 여러 전문가의 의견을 종합하여 선정 주관적 편견 보완

 

상향식 비용 산정 기법

프로젝트 세부 작업 단위 별로 비용 정산 후 전체 비용을 산정하는 방법

 

상향식 비용 산정 기법	내용
★ LOC (Source Line of Code)	코드 라인 총수 / 생산성 / 개발 참여 인원 등으로 계산	(낙관치 + 4*기대치 + 비관치) / 6
개발 단계별 인월 수	LOC 기법 보완 / 생명 주기 각 단계별로 산정
수학적 비용 산정
★ COCOMO	보헴 제안 / 원시 코드 라인 수 기반
	조직형 (Organic)	중, 소규모 SW용 / 5만 라인 이하
	반분리형 (Semi-detached)	30만 라인 이하의 트랜잭션 처리 시스템
	내장형 (Embedded)	30만 라인 이상의 최대형 규모 SW 관리
★ PUTNAM	노력의 분포를 이용한 비용 산정	자동화 추정 도구 : SLIM
★ Function Point (FP)	가중치 부여 후 합산하여 기능 점수 산출	자동화 추정 도구 : ESTIMACS

 

 

▷ 개발 일정 산정

 

WBS (Work Breakdown Structure)

프로젝트 목표 달성을 위한 활동과 업무를 세분화

 

네트워크 차트

PERT	프로젝트 작업 상호 관계를 네트워크로 표현 원 노드, 간선 으로 구성 (불확실한 상황)
CPM	미국 Dupont 회사에서 화학 공장 유지/관리를 위해 개발 노드 / 간선 / 박스 구성 간선의 흐름에 따라 작업 진행 (확실한 상황) 임계 경로 : 경로상 가장 오래 걸리는 시간

 

간트 차트

각 작업의 시작/종류 일정을 막대 바 도표를 이용하여 표현

시간선 차트 (수평 막대 길이 = 작업 시간)

작업 경로는 표현 불가 / 계획 변화에 대한 적응성이 낮음

 

 

---

► 요구사항 분석

 

요구사항 유형

기능적 요구사항	실제 시스템 수행에 필요한 기능 관련 요구사항 ex. 금융 -> 조회/인출/입금/송금 등
비기능적 요구사항	성능, 보안, 품질, 안정성 등 실제 수행에 보조적인 요구사항 ex. 모든 화면이 3초 이내에 사용자에게 보여야한다.

 

요구사항 개발 프로세스  ★ 순서 중요

도출 / 추출	인터뷰, 질문, 브레인스토밍, 청취, 프로토타이핑, 유스케이스
분석	관찰, 개념 모델링, 정형 분석, 요구사항 정의 문서화
명세	문서화
확인 / 검증	검토

 

요구사항 분석 도구

요구사항 분석 CASE	★ SADT	SoftTech 사에서 개발 구조적 분석 및 설계 분석
	SREM	실시간 처리 SW 시스템에서 요구사항 명확한 기술 목적
	PSL/PSA	문제 기술 언어 및 요구사항 분석 보고서 출력
	TAGS	시스템 공학 방법 응용에 대한 자동 접근 방법
★ HIPO	하향식 설계 방식 가시적, 총체적, 세부적 다이어그램으로 구성 이해 쉽고 유지보수 간단

 

구조적 분석 모델

데이터/자료 흐름도 (DFD)	프로세스	O  원
	자료 흐름	→  화살표
	자료 저장소	ㅡ  평행선
	단말	☐  사각형
자료 사전 (DD)	정의	=	구성	+
	택일 / 선택	[]	설명 / 주석	**
	생략	()	반복	{}

 

객체지향 분석 모델

Booch	미시적, 거시적 개발 프로세스를 모두 사용
Jacobson	Use Case를 사용
Coad-Yourdon	E-R 다이어그램 사용
Wirfs-Brock	분석과 설계 구분 없으며 고객 명세서 평가 후 설계 작업까지 연속 수행
★ Rumbaugh	가장 일반적인 사용, 객체/동적/기능 모델로 구문
	객체 모델링	객체 다이어그램
	동적 모델링	상태 다이어그램
	기능 모델링	자료 흐름도(DFD)

 

요구사항 명세

정형 명세	수학적 원리
비정형 명세	자연어, 그림 중심

 

 

 

---

► 소프트웨어 설계

 

소프트웨어 설계 원리

분할과 정복	여러 개의 작은 서브 시스템으로 나눠서 각각을 완성
모듈화	모듈 크기 ▲ → 모듈 개수 ▼ → 모듈 간 통합 비용 ▼ (but, 모듈 당 개발 비용 ▲) 모듈 크기 ▼ → 모듈 개수 ▲ → 모듈 간 통합 비용 ▲
추상화	과정 추상화 데이터(자료) 추상화 제어 추상화
단계적 분해	하향식 설계 전략
정보 은닉	다른 모듈의 접근/변경 불가 / 독립적으로 수행 가능

 

아키텍처 패턴

Layer	시스템을 계층으로 구분/구성하는 고전적 방식 (OSI 참조 모델)
Client-server	하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성 클라이언트와 서버는 요청/응답 제외 시 서로 독립적
Pipe-Filter	데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 후 데이터 전송 / 재사용 및 확장 용이 / 필터 컴포넌트 재배치 가능 단방향으로 흐르며, 필터 이동 시 오버헤드 발생 변환, 버퍼링, 동기화 적용
Model-View-Controller	모델 : 서브 시스템의 핵심 기능 및 데이터 보관 뷰 : 사용자에게 정보를 표시 컨트롤러 : 사용자로부터 받은 입력 처리 하나의 모델 대상 다수 뷰 생성 -> 대화형 애플리케이션에 적합
Master-slave	마스터에서 슬레이브 컴포넌트로 작업 분할/분리/배포 후 슬레이브에서 처리된 결과물을 다시 돌려받음 (병렬 컴퓨팅)
Broker	컴포넌트와 사용자를 연결 (분산 환경 시스템)
Peer-to-peer	피어를 한 컴포넌트로 산정 후 각 피어는 클라이언트가 될 수도, 서버가 될 수 도 있음 (멀티스레딩 방식)
Event-bus	소스가 특정 채널에 이벤트 메시지를 발행 시 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리함
Blackboard	컴포넌트들이 검색을 통해 블랙보드에서 원하는 데이터 찾음
Interpreter	특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계

 

 

UML

★ 구성 요소 : 사물, 관계, 다이어그렘

고객/개발자 간 원활한 의사소통을 위해 표준화한 대표적인 객체지향 모델링 언어

 

인터페이스 : 클래스/컴포넌트가 구현해야하는 오퍼레이션 세트를 정의하는 모델 요소

 

사물	구조(개념, 물리적 요소) / 행동 / 그룹 / 주해(부가적 설명, 제약 조건)
관계	연관 관계	2개 이상 사물이 서로 관련
	집합 관계	하나의 사물이 다른 사물에 포함 (전체-부분 관계)
	포함 관계	집합 관계 내 사물의 변화가 다른 사물에게 영향
	일반화 관계	한 사물이 다른 사물에 비해 일반/구체적인지 표현 한 클래스가 다른 클래스를 포함하는 상위 개념일 때
	의존 관계	사물 간 서로에게 영향을 주는 관계 한 클래스가 다른 클래스의 기능을 사용할 때
	실체화 관계	한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정 / 서로 그룹화 할 수 있는 관계
구조, 정적 다이어그램	클래스	클래스 사이의 관계 및 속성 표현
	객체	인스턴스를 객체와 객체 사이의 관계로 표현
	컴포넌트	구현 모델인 컴포넌트 간의 관계 표현
	배치	물리적 요소의 위치/구조 표현
	복합체 구조	클래스 및 컴포넌트의 복합체 내부 구조 표현
	패키지	UML의 다양한 모델 요소를 그룹하하여 묶음
행위, 동적 다이어그램	유스케이스	사용자의 요구를 분석
	시퀀스	시스템/객체들이 주고받는 메시지 표현
	커뮤니케이션	객체들이 주고받는 메시지와 객체 간의 연관 관계까지 표현
	상태	다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현
	활동	객체의 처리 로직 및 조건에 따른 처리의 흐름을 순서에 따라 표현
	타이밍	객체 상태 변화와 시간 제약 면시적으로 표현
	상호작용 개요	상호 작용 다이어그램 간 제어 흐름 표현

 

 

UI 설계

 

직관성, 유효성(사용자의 목적 달성), 학습성, 유연성

★ CLI(텍스트), GUI(그래픽), NUI(말/행동), VUI(음성), OUI(사물과 사용자 상호작용)

 

 

UI 설계 도구

Wireframe	기획 초기 단계에 대략적인 레이아웃을 설계
Story Board	최종적인 산출 문서
Prototype	와이어프레임 / 스토리보드에 인터랙션 적용 동적인 형태 모형
Mockup	실제 화면과 유사한 정적인 형태 모형
Use Case	사용자 측면 요구사항 및 목표를 다이어그램으로 표현

 

---

 

► 소프트웨어 구현

 

소프트웨어 개발 프레임워크

스프링 프레임워크	JAVA 플랫폼을 위한 오픈 소스 경량형 프레임워크
전자 정부 프레임워크	우리나라 공공부문 정보화 사업 시 효율적인 정보 시스템 구축 지원 위해 필요한 기능/아키텍처 제공
닷넷 프레임워크	MS에서 개발한 Windows 프로그램 개발

 

API : 소프트웨어 간 인터페이스

 

팬인(Fan-in) : 자신을 사용하는 모듈의 수  ↓ 

팬아웃(Fan-out) : 자신이 사용하는 모듈의 수  ↑ 

 

 

 

응집도

응집도 ▲ → 품질 ▲

 

우리 논 시절 통닭 순살 기가막혔는데 

응집도 ▼ 응집도 ▲	우연적	각 요소들이 서로 관련 없는 요소로만 구성
	논리적	유사한 성격의 처리 요소들로 하나의 모듈이 형성
	시간적	특정 시간 내 처리되는 기능을 모아 하나의 모듈로 작성
	절차적	모듈 내 구성 요소들이 다수 관련 기능을 순차적으로 수행
	통신적	동일한 입/출력을 사용하여 서로 다른 기능을 수행
	순차적	모듈 내 출력 데이터를 다음 활동의 입력 데이터로 사용
	기능적	모듈 내부의 모든 기능 요소가 단일 문제와 연관되어 수행

 

 

결합도

결합도 ▼ → 품질 ▲

 

내게 공부하라고 하지 마요 제가 스트레스 받자나요

결합도 ▲ 결합도 ▼	내용	한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조/수정
	공통/공유	공유되는 공통 데이터를 여러 모듈이 사용
	외부	한 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조
	제어	한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계
	스탬프	두 모듈이 동일한 자료 구조(배열, 오브젝트)를 조회
	자료	모듈 간의 인터페이스가 자료 요소로만 구성

 

 

 

객체지향

객체	고유 식별자 / 하나의 독립된 존재 상태 = 객체가 가질 수 있는 조건, 속성 값에 의해 정의
클래스	공통 속성과 연산을 갖는 객체들의 집합 / 데이터 추상화 단위 인스턴스 : 클래스에 속한 각각의 객체 Operation : 클래스의 동작 / 객체에 대해 적용될 메서드 정의
캡슐화	데이터와 데이터 처리 함수를 하나로 묶음 외부 접근 제한 결합도 낮음 / 재사용 용이 / 인터페이스 단순 / 오류 파급효과 낮음
상속	상위 클래스의 속성과 연산을 하위 클래스가 물려받는 것 다중 상속 : 단일 클래스가 두 개 이상의 클래스로부터 상속
다형성	하나의 메시지에 각 객체 별 고유 특성에 따라 여러 형태의 응답

 

 

오버라이딩(Overriding) : 상위 클래스로부터 상속받은 메서드를 하위 클래스에서 재정의

                                         - 단, 메서드 이름 / 매개변수 / 반환 타입이 동일해야함.

오버로딩(Overloading) : 메서드 이름은 동일하나 매개 변수 개수 또는 타입을 다르게 지정

 

 

★ 객체지향 설계 5대 원칙 (SOLID)

단일 책임 원칙	SRP	모든 클래스/객체는 하나의 책임만 완전한 캡슐화
개방 폐쇄의 원칙	OCP	확장은 Open, 수정은 Close
리스코프 교체 원칙	LSP	상위 클래스의 행동 규약을 하위 클래스가 위반하면 안된다
인터페이스 분리 원칙	ISP	클라이언트가 비사용 메서드에 의존하지 않아야한다.
의존성 역전 원칙	DIP	의존 관계 수립 시 변화하기 어려운 것에 의존해야한다.

 

 

 

디자인 패턴(GoF)

서버 시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델

 

생성 패턴 / 구조 패턴 / 행위 패턴

 

★ 어느 패턴인지 구분

생성 패턴	Abstract Factory	구체적인 클래스에 의존하지 않고, 서로 연관되거나 의존적인 객체들이 조합된 인터페이스 제공 - interface
	Builder	객체 생성 단계를 캡슐화/분리하여 객체를 조립하여 생성 -Lombok @Builder
	Factory Method	상위 클래스에서 객체 생성 인터페이스를 정의하지만, 인터페이스를 만드는 클래스는 서브 클래스에서 결정하도록 분리
	Prototype	원본/원형 객체를 복제하는 방식으로 객체를 생성 - new
	Singleton	클래스에서 하나의 객체만 생성 가능하며, 해당 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조는 불가
구조 패턴	Adaptor	비호환 인터페이스에 호환성 부여하도록 변환
	Bridge	구현부에서 추상층을 분리 후 독립적으로 변형/확장 가능
	Composite	트리 구조로 부분/전체 계층 표현, 복합/단일 객체를 구분없이 사용
	Decorator	상속 사용없이 객체 간 결합을 통해 객체 기능을 동적으로 추가/확장
	Facade	상위에 인터페이스 구성하여 서브 클래스의 기능을 복잡하게 표현하지 않고 단순한 인터페이스로 구현
	Flyweight	인터페이스를 공유하여 메모리 절약(클래스 경량화)
	Proxy	접근이 힘든 객체를 연결하는 인터페이스 역할 (대리 객체 수행)
행위 패턴	Chain of Responsibilty	처리 가능한 객체가 둘 이상 존재하여 한 객체 내 처리 불가 시 다음 객체로 이관
	Command	요청 명령어들을 추상/구체 클래스로 분리 후 단순화/캡슐화
	Interpreter	언어에 문법 표현 정의
	Iterator	접근이 빈번한 객체에 대해 동일 인터페이스 사용
	Mediator	객체들간 복잡한 상호작용을 캡슐화하여 객체로 정의 후 중재
	Memento	객체를 이전의 특정 시점의 상태로 저장하고 복원 (캡슐화 유지)
	Observer	한 객체 상태 변화 시 상속되어 있는 객체들에 변화 전달
	State	객체의 상태에 따라 동일한 동작을 다르게 처리
	Strategy	동일 계열 알고리즘을 개별적으로 캡슐화하여 상호 교환
	Template Method	여러 클래스에서 공통 사용 메서드를 상위 클래스에서 정의하고, 하위 클래스마다 다르게 구현해야하는 세부 사항을 개별 구현
	Visitor	각 클래스 데이터 구조로부터 처리/연산 기능을 분리하여 별도의 클래스를 만들고, 해당 클래스 메서드가 각 클래스를 돌아다니며 특정 작업을 수행 → 객체 구조 변경 X / 새로운 연산 기능만 추가

 

 

---

▶︎ 소프트웨어 테스트

 

애플리케이션 테스트 기본 원리

파레토(Pareto) 법칙	20%의 모듈에서 전체 결함 80% 발생
살충제 패러독스 (Pesticide Paradox)	동일한 테스트 케이스에 의한 반복 테스트는 새로운 버그 발견 X
오류-부재의 궤변 (Error-Free Paradox)	결함이 없다 해도 사용자의 요구사항 미충족 시 품질 저하
Brooks의 법칙	지연되는 프로젝트에 인력 추가 투입 시 더 지연

 

 

 

애플리케이션 테스트 분류

 

1. 프로그램 실행 여부

정적 테스트	프로그램 실행 X / 명세서, 소스코드만 분석 ex. 동료 검토, 워크 스루, 인스펙션, 코드검사
동적 테스트	프로그램 실행 후 오류 검사 ex. 화이트/블랙 테스트

 

2. 테스트 기반 테스트

명세 기반	ex. 동등 분할 / 경계값 분석 (블랙박스)
구조 기반	SW 내부 구조 흐름에 따라 ex. 구문 기반 / 결정 기반 / 조건 기반 (화이트 박스)
경험 기반	테스터의 경험을 기반으로 수행 ex. 에러 추정, 체크 리스트, 탐색적 테스팅

 

3. 목적 기반 테스트

회복	인위적 결험 부여 후 정상으로 회복되는 과정 확인
안전	외부 불법 침입으로 부터 시스템을 보호할 수 있는지 확인
강도	과부하 시 SW 정상 구동 여부 확인
성능	실시간 성능 및 전체적인 효율성 진단 (응답 시간, 업무 처리량)
구조	SW 내부 논리적 경로 및 소스 코드 복잡도 평가
회귀	변경 또는 수정된 코드에 새로운 결함이 없음을 확인
병행	변경 및 기존 SW에 동일한 데이터 입력 후 결과 비교

 

4. 시각(관점) 기반 테스트

검증	개발자의 시각에서 제품의 생산 과정 테스트 ex. 단위 / 통합 / 시스템 테스트
확인	사용자의 시각에서 생산된 제품의 결과 테스트 ex. 인수 테스트 (알파 / 베타)

 

 

 

화이트박스 테스트

모듈 안의 내용 직접 볼수 있으며, 내부의 논리적인 모든 경로를 테스트 - ★ 논리적 경로 점검

 

검증 기준 커버리지

구문 커버리지 Statement	모든 명령문을 적어도 한 번 수행
결정(분기) 커버리지 Branch	전체 결정문이 적어도 한 번은 참/거짓 결과 수행
조건 커버리지 Condition	결정 명령문 내의 각 개별 조건식이 적어도 한 번은 참/거짓 결과 수행
조건/결정 커버리지 Condition/Decision	전체 조건식뿐만 아니라 개별 조건식도 참 한 번 이상, 거짓 한 번 이상 결과 수행
변경 조건/결정 커버리지 MC/DC	각 개별 조건식이 독립적으로 전체 조건식의 결과에 영향
다중 조건 커버리지 Multiple Condition	결정 포인트 내 모든 개별 조건식의 모든 가능한 논리적 조합을 고려하여 100% 커버리지 보장

 

화이트 박스 테스트 종류

기초 경로 검사 Base Path Testing	동적 테스트
제어 구조 검사 Control Structure Testing	조건 검사
	루프 검사
	자료 흐름 검사

 

 

 

블랙박스 테스트 - ★ 기능 테스트

 

블랙박스 테스트 종류

동치 분할 검사 Equivalence Partition	입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 진행
경계값 검사 Boundary Value	입력 조건의 경계값을 테스트 케이스로 선정
원인-효과 그래프 검사 Cause-Effect Graphing	입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성이 높은 테스트 케이스 선정
오류 예측 검사 Error Guessing	과거 경험이나 확인자의 감각으로 테스트 진행
비교 검사 Comparison	여러 버전의 프로그램에 동일한 결과가 출력되는지 확인

 

요구사항 검증

동료 검토	작성자가 내용 설명 후 동료들이 결함 검토
워크 스루	요구사항 명세서 미리 배포 후 짧은 검토 회의 진행
인스펙션	작성자 제외한 다른 전문가들이 결함 검토

 

소프트웨어 생명주기 V-모델

 

 

 

 

개발 단계에 따른 애플리케이션 테스트

단위 테스트	최소 단위(모듈/컴포넌트) 기반 테스트
통합 테스트	하향식	깊이 우선 / 넓이 우선 스텁(Stub)
	상향식	클러스터(Cluster)와 드라이버(Driver) 사용
시스템 테스트	기능적 및 비기능적 테스트 구분
인수 테스트	알파 테스트	사용자가 개발자와 함께 확인
	베타 테스트	개발자 없이 여러 명의 사용자가 검증

 

 

 

테스트 관련 기타 용어

테스트 시나리오	적용/동작 순서에 따라 여러 테스트 케이스를 묶은 집합
테스트 오라클	테스트 결과의 참/거짓 판단 위해 사전에 정의된 참 값을 대입
	참 오라클(True)	모든 테스트 케이스의 입력값에 기대 결과 제공
	샘플링 오라클(Sampling)	특정 테스트 케이스 입력값에 기대 결과 제공
	추정 오라클(Heuristic)	특정 테스트 케이스 입력값에 기대 결과 제공    + 나머지 입력값에 대해선 추정 결과 제공
	일관성 오라클(Consistent)	테스트 케이스의 수행 전/후의 결과값 동일 여부 확인

 

 

 

테스트 하네스

테스트 드라이버 Test Driver	시험 대상의 하위 모듈 호출 → 상향식 통합 테스트에서 사용
테스트 스텁 Test Stub	제어 모듈이 호출하는 하위 모듈의 역할 단순 수행 → 하향식 통합 테스트에 사용
테스트 슈트 Test Suites	시스템에 사용되는 테스트 케이스의 집합(컴포넌트 / 모듈)
테스트 케이스 Test Case	사용자의 요구사항 준수 여부 확인 위해 설계된 테스트 항목 명세서 (입력값, 실행 조건, 기대 결과 등)
테스트 스크럽트 Test Script	자동화된 테스트 실행 절차에 대한 명세서
목 오브젝트 Test Mock Object	사용자의 행위 조건부 입력 시 계획된 행위를 수행하는 객체

 

 

 

---

► 소프트웨어 유지 보수

 

애플리케이션 성능 개선

코드 스멜 (Code Smell)	소스 코드 내 존재하는 잠재적 문제점
★ 스파게티 코드	소스코드 로직이 복잡하게 얽혀있는 구조
★ 외계인 코드	오래되어 유지보수가 어려운 코드

 

클린 코드 작성 원칙 : 가독성 / 단순성 / 의존성 배제 / 중복성 최소화 / 추상화

 

소스 코드 품질 분석 도구

정적 분석 도구	프로그램 실행 없이 코딩 표준/스타일/결함 등을 분석
동적 분석 도구	프로그램 실행 하여 코드 내 메모리 누수 및 스레드 결함 발견

 

 

 

소프트웨어 형상 관리 (SCM : Software Configuration Management)

개발 과정에서 SW 변경사항을 관리하기 위해 인련의 활동

 

형상 관리 역할 : 배포본 관리 용이 / 불필요한 소스 수정 제한 / 여러 개발자 동시 개발

형상 식별	관리 대상에 이름/번호 부여 후 계층 구조로 구분
형상 통제	식별된 형상 항목에 대한 변경 요구 검토
형상 감사	기준선의 무결성 평가 위해 확인/검증/검열 과정 진행
형상 기록	형상 식별/통제/감사 작업 결과를 기록/관리하고 보고서 작성

 

소프트웨어 버전 관리 도구

공유 폴더	클라이언트/서버	분산 저장소
공유 폴더애 복사	서버에서 버전 일괄 관리	원격 → 지역 저장소
RCS, SCCS, PVCS, QVCS	CVS, SVN, CVSNT, CMBC	Git, GNU arch, DCVS, Bitkeeper, Basaar

 

★ 형상 관리 도구

CVS	서버/클라이언트 구성, 다수의 인원이 동시 버전 관리 가능
SVN	CVS 개선 툴 / 모든 개발은 trunk 디텍터리에서 수행
Git	서버(원격) 저장소와 개발자(지역) 저장소가 독립적

 

 

 

ISO 12207 - 소프트웨어 관련 생명주기

기본 생명주기	획득, 공급, 개발, 운영, 유지보수 프로세스
지원 생명주기	문서화, 형상관리, 품질 보증, 검증, 확인, 합동 검토, 감사
조직 생명주기	관리, 기반 구조, 개선, 교육 훈련

 

 

 

CMMI : SW 개발 조직의 업무 능력 평가 모델

1. 초기	프로세스 X
2. 관리	규칙화 프로세스
3. 정의	표준화 프로세스
4. 정량적 관리	예측 가능 프로세스
5. 최적화	지속 개선 프로세스