[정처기] 소프트웨어 구축 II - 소프트웨어 구현, 소프트웨어 테스트, 소프트웨어 유지 보수 etc.

소프트웨어 생명 주기(Sofrware Development Life Cycle, SDLC)
①프로젝트 계획 ▶︎ ②요구 분석 ▶︎ ③설계 ▶︎ ④구현 ▶︎ ⑤테스트 ▶︎ ⑥유지 보수

④ 소프트웨어 구현

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

- 개발해야할 애플리케이션 일부분이 이미 내장된 클래스 라이브러리에 구현
- 동일 로직 반복 최소화 / 재사용성 확대 / 새산성 및 유지보수성 향상
→ 모듈화 / 재사용성 / 확장성 / 제어의 역흐름(프레임워크가 어플리케이션 흐름 제어)

• 스프링 프레임워크(Spring Framework)
  • JAVA 플랫폼을 위한 오픈 소스 경량형 프레임워크
  • 동적 웹 사이트 개발 / 전자정부 표준 프레임워크
• 전자정부 프레임워크
  • 우리나라 공공부문 정보화 사업 시 효율적인 정보 시스템 구출 지원 위해 필요한 기능/아키텍처를 제공
• 닷넷 프레임워크(.NET Framework)
  • MS에서 개발한 Windows 프로그램 개발
  • 공통 언어 런타임(CLR)이라는 가상 머신 상에서 작동

※ API(Application Programming Interface)
- 소프트웨어 간 인터페이스 (서로 다른 소프트웨어/서비스 간 상호 작용 용이)
- 운영체제 및 프로그래밍 언어의 기능을 프로그램에서 사용 가능하도록 구현
→ 개발 비용 저감 / 중복 작업 최소화 / 유지 관리 용이 / 비즈니스 확장

► 팬인(Fan-in): 자신을 사용하는 모듈 수 → 팬인이 높으면 재사용 측면 설계 우수 but, 단일 장애점 발생 가능성 높아 집중적인 관리/테스트 필요

► 팬아웃(Fan-out): 자신이 사용하는 모듈의 수 → 불필요한 호출 가능성 (단순화 필요)

■ 응집도(Cohesion)

- 개별 모듈이 독립적으로 기능으로 정의되어 있는 정도 / 응집도 ▲ → 품질 ▲

• 기능적(Function): 모듈 내부의 모든 기능 요소가 단일 문제와 연관되어 수행
• 순차적(Sequential): 모듈 내 출력 데이터를 다음 활동의 입력 데이터로 사용
• 통신적・교환적(Commuication): 동일한 입/출력을 사용하여 서로 다른 기능을 수행
• 절차적(Procedural): 모듈 내 구성 요소들이 다수 관련 기능을 순차적으로 수행
• 시간적(Temporal): 특정 시간 내 처리되는 기능을 모아 하나의 모듈로 작성
• 논리적(Logical): 유사한 성격의 처리 요소들로 하나의 모듈이 형성
• 우연적(Coincidental): 각 구성 요소들이 서로 관련없는 요소로만 구성

(높은 응집도) 기능적 ► 순차적 ► 통신적・교환적  ► 절차적 ► 시간적 ► 논리적 ► 우연적 (낮은 응집도)

■ 결합도(Coupling)

- 개별 모듈 간 상호 의존하는 정도 / 결합도 ▼ → 품질 ▲

• 내용(Content): 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조/수정
• 공통/공유(Common): 공유되는 공통 데이터를 여러 모듈이 사용(전역 변수 참조)
• 외부(External): 한 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조
• 제어(Control): 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계, 처리 대상 값뿐만 아니라 처리 방식의 제어 요소도 전달
• 스탬프(Stamp): 두 모듈이 동일한 자료 구조(배열, 오브젝트)를 조회, 자료 구조 및 포맷 변화 시 조회하고 있는 모든 모듈에 영향
• 자료(Data): 모듈 간의 인터페이스가 자료 요소로만 구성

(낮은 결합도) 자료 ► 스탬프 ► 제어  ► 외부 ► 공통/공유 ► 내용 (높은 결합도)

※ 모듈의 독립성: 모듈 간 과도한 상호작용을 막고 하나의 독립적 기능만을 수행 → 높은 독립성: 높은 응집도 / 낮은 결합도

■ 객체 지향(Object-oriented): 객체와 속성, 클래스와 멤버, 전체와 부분으로 나눠 분석

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

- 오버라이딩(Overriding): 상위클래스로부터 상속받은 메서드를 하위클래스에서 재정의 → 단, 메서드 이름 / 매개변수 / 반환 타입은 동일해야 함
- 오버로딩(Overloading): 메서드 이름은 동일하나 매개변수 개수 또는 타입을 다르게 지정

※ 객체지향 설계 5대 원칙(SOLID)
- 단일 책임 원칙(SRP, Sigle Responsibility Principle) → 모든 클래스/객체는 하나의 책임만 / 완전한 캡슐화
- 개발 페쇄의 원칙(OCP, Open Closed Principle) → 확장에는 Open하고, 수정에는 Close
- 리스코프 교체 원칙(LSP, Liskov Substitution Principle) → 상위 클래스의 행동 규약을 하위 클래스가 위반하면 안됨
- 인터페이스 분리 원칙(ISP, Interface Segregation Principle) → 클라이언트가 비사용 메서드에 의존하지 않아야 함
- 의존성 역전 원칙(DIP, Dependency Inversion Principle) → 의존 관계 수립 시 변화하기 어려운 것(추상성이 높은 상위 클래스)에 의존해야 함

■ 디자인 패턴: GoF(Gang of Four) 처음 제안하여 구제화

- 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델
- 객체 지향 프로그래밍 설계 시 자주 발생하는 문제에 대한 반복적 해결 방법

[ 생성 패턴 ]

• Abstract Factory: 구체적인 클래스에 의존하지 않고, 서로 연관되거나 의존적인 객체들이 조합된 인터페이스 제공
• Builder: 객체 생성 단계를 캡슐화/분리하여 객체를 조립하여 생성 → 동일한 객체 생성 절차에서 서로 다른 표현 결과를 제공
• Factory Method: 상위 클래스에서 객체 생성 인터페이스를 정의하지만, 인스턴스를 만드는 클래스는 서브 클래스에서 결정하도록 분리
• Prototype: 원본/원형 객체를 복제하는 방식으로 객체 생성
• Singleton: 클래스에서 하나의 객체만 생성 가능하며, 해당 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조는 불가
  
  

[ 구조 패턴 ]

• Adaptor: 비호환 인터페이스에 호환성 부여하도록 변환
• Bridge: 구현부에서 추상층을 분리 후 가가 독립적으로 변형/확장 가능
• Composite: 트리 구조로 부분/전체 계층 표현, 복합/단일 객체를 구분없이 사용
• Decorator: 상속 사용없이 객체 간 결합을 통해 객체 기능을 동적으로 추가/확장
• Facade: 상위에 인터페이스 구성하여 서브클래스의 기능을 복잡하게 표현하지 않고 단순한 인터페이스로 구현
• Flyweight: 인스턴스를 공유하여 메모리 절약(클래스 경량화)
• Proxy: 접근이 힘든 객체를 연결하는 인터페이스 역할(대리 객체 수행)
  
  

[ 행위 패턴 ] 

• Chain of Responsibility: 처리가능한 객체가 둘 이상 존재하여 한 객체 내 처리 불가 시 다음 객체로 이관
• Comman: 요청 명령어들을 추상/구체 클래스로 분리 후 단순화/캡슐화
• Interpreter: 언어에 문법 표현 정의
• Iterator: 접근이 빈번한 객테에 동일 인터페이스 사용
• Mediator: 객체들간 복잡한 상호작용을 캡슐화하여 객체로 정의 후 중재
• Memento: 객체를 이전의 특정 시점의 상태로 저장하고 복원(캡슐화 유지)
• Observer: 한 객체 상태 변화 시 상속되어 있는 객체들에 변화 전달
• State: 객체의 상태에 따라 동일한 동작을 다르게 처리
• Strategy: 동일 계열 알고리즘을 개별적으로 캡슐화하여 상호 교환
• Template Method: 여러 클래스에서 공통 사용 메서드를 상위 클래스에서 정의하고, 하위 클래스마다 다르게 구현해야하는 세부 사항을 개별 구현
• Visitor: 각 클래스 데이터 구조로부터 처리/연산 기능을 분리하여 별도의 클래스를 만들고, 해당 클래스 메서드가 각 클래스를 돌아다니며 특정 작업을 수행 → 객체 구조 변경X / 새로운 연산 기능만 추가

 

⑤ 소프트웨어 테스트

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

- 테스트는 기본적으로 결함이 존재함을 밝히는 것 (무결함을 증명할 수는 없음) → 완벽한 테스트는 근원적으로 불가능 (무한 경로, 무한 입력 불가)
- 결함 집중: 파레토(Pareto) 법칙, 20%의 모듈에서 전체 결함 80%  발생
- 살충제 패러독스: 동일한 테스트 케이스에 의한 반복 테스트는 새로운 버그 발견 X
- 오류-부재의 궤변: 결함이 없다 해도 사용자의 요구사항 미충족 시 품질 저하
- Brooks의 법칙: 지연되는 프로젝트에 인력 추가 투입 시 더 지연

■ 애플리케이션 테스트 분류

① 프로그램 실행 여부

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

② 테스트 기반 테스트

• 명세 기반: 사용자의 요구사항에 대해 명세를 빠짐없이 테스트 케이스로 구현하는지 확인
  • ex. 동등 분할 / 경계값 분석 (블랙박스)
• 구조 기반: SW 내부 논리 흐름에 따라 테스트 케이스 작성/확인
  • ex. 구문 기반 / 결정 기반 / 조건 기반 (화이트박스)
• 경험 기반: 테스트의 경험을 기반으로 수행
  • ex. 에러 추정, 체크리스트, 탐색적 테스팅

③ 목적 기반 테스트

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

④ 시각(관점) 기반 테스트

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

■ 화이트박스 테스트 (White Box Test)

- 모듈 안의 내용(작동) 직접 볼 수 있으며, 내부의 논리적인 모든 경로를 테스트
- 소스 코드의 모든 문장을 한 번 이상 수행 / 논리적 경로 점검 (선택, 반복 수행)
- 테스트 데이터 선택하기 위해 검증 기준 커버리지(Coverage) 정함

[ 화이트박스 테스트 검증 기준 ]

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

[ 화이트박스 테스트 종류 ]

• 기초 경로 검사(Base Path Testing)
  • 대표적 화이트박스 테스트 기법 (동적 테스트)
  • 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법
  • 측정 결과는 실행 경로의 기초를 정의하는 지침으로 사용
• 제어 구조 검사(Control Structure Testing)
  • 조건 검사: 프로그램 모듈 내 논리적 조건 테스트
  • 루프 검사: 프로그램 반복(Loop) 구조 테스트
  • 자료 흐름 검사: 변수의 정의와 변수 사용의 위치 테스트
    
    

■ 블랙박스 테스트 (Black Box Test)

- 모듈 내부의 내용 알 수 없음 / 소프트웨어 인터페이스에서 실시되는 테스트
- SW 각 기능이 완전히 작동되는 것을 입증하는 테스트로 '기능 테스트' 라고 함

[ 블랙박스 테스트 종류 ]

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

■ 요구사항 검증(Requirements Verification)

- 실제로 고객이 원하는 시스템을 제대로 정의했는지 점검하는 과정
- 시스템 개발 완료 후 문제 발생 시 막대한 재작업 비용 발생하기에 검증 중요 (실제 요구사항 반영 여부 / 문서 상 요구사항이 서로 상충되지 않는지 점검)
① 동료 검토(Peer review): 작성자가 내용 설명 후 동료들이 결함 검토
② 워크 스루(Walk through): 요구사항 명세서 미리 배포 후 짧은 검토 회의 진행
③ 인스펙션(Inspection): 작성자 제외한 다른 전문가들이 결함 검토

※ 검증 체크리스트: 기능성(Functionality) / 완전성(Completeness) / 일관성(Consistency) / 명확성(Unambiguity) / 검증 가능성(Verifiability) / 추적 가능성(Traceability) / 변경 용이성(Easily Changeable)

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

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

① 단위 테스트(Unit test): 최소 단위(모듈 - 소프트웨어를 이루는 기본 단위(독립적 기능)/컴포넌트) 기반 테스트, 주로 구조 기반 테스트 진행 / 기능성 테스트 최우선

② 통합 테스트(Integration test): 인터페이스 간 시스템이 정상 실행되는지 확인
- 단위 테스트 후 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법

• 하항식(Top-down)
  • 상위 모듈에서 하위 모듈 방향으로 통합
  • 깊이 우선(Depth first) 통합법 / 넓이 우선(Breadth first) 통합법
  • 초기부터 사용자에게 시스템 구조 보여줌
  • 스텁(Stub): 모듈의 기능을 단순히 수행하는 도구(시험용 모듈)
• 상향식(Bottom-up)
  • 하위 모듈에서 상위 모듈 방향으로 통합
  • 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster)와 드라이버(Driver) 사용

③ 시스템 테스트(System test): 개발된 SW의 컴퓨터 시스템 내 작용여부 점검, 실제 사용 환경과 유사한 테스트 환경 ► 기능적(블랙박스) 및 비기능적(화이트박스) 테스트 구분

④ 인수 테스트(Acceptance test): 사용자의 요구사항 충족 여부 확인
- 알파 테스트: 통제된 환경에서 사용자가 개발자와 함께 확인
- 베타 테스트: 통제되지 않은 환경에서 개발자 없이 여러 명의 사용자가 검증

■ 테스트 관련 기타 용어

1) 테스트 시나리오: 테스트 케이스 적용/동작 순서에 따라 여러 테스트 케이스를 묶은 집합

2) 테스트 오라클: 테스트 결과의 참/거짓 판단을 위해 사전에 정의된 참 값을 대입

• 참 오라클(True): 모든 테스트 케이스의 입력값에 기대 결과 제공
• 샘플링 오라클(Sampling): 특정 테스트 케이스 입력값에 기대 결과 제공
• 추정 오라클(Heuristic): 특정 테스트 케이스 입력값에 기대 결과 제공 + 나머지 입력값에 대해선 추정 결과 제공
• 일관성 오라클(Consistent): 테스트 케이스의 수행 전/후의 결과값 동일 여부 확인
  
  

■ 테스트 하네스(Test harness)

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

 

⑥ 소프트웨어 유지 보수

■ 애플리케이션 성능 개선

- 성능 분석 지표: 처리량 / 응답 시간 / 경과 시간 / 자원 사용률
- 소스코드 최적화를 통한 코드 스멜 제거 후 품질 개선

※ 코드 스멜 (Code Smell): 소스코드 내 존재하는 잠재적 문제점
ex. 중복 코드 / 긴 메서드 / 큰 클래스 / 클래스 동시 수정
→ 스파게티 코드: 소스코드 로직이 복잡하게 얽혀있는 구조
→ 외계인 코드: 오래되어 유지보수 작업이 어려운 코드

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

▶︎ 소스 코드 품질 분석 도구

• 정적 분석 도구: 프로그램 실행 없이 코딩 표준/스타일/결함 등을 분석 → PMD, Checkstyle, SonarQube, Cppcheck, Ccm, Cobertura
• 동적 분석 도구: 프로그램 실행하여 코드 내 메모리 누수 및 스레드 결함 발견 → Avalanche, Valgrind, Valance
  
  

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

- 개발 과정에서 SW 변경사항을 관리하기 위한 일련의 활동 / 개발 전체 단계 적용
- 중요성: 변경사항 추적/통제, 무절제한 변경 방지, 개발 진행 이력 확인
- 형상 관리 역할: 배포본 관리 용이 / 불필요한 소스 수정 제한 / 여러 개발자 동시 개발

• 형상 식별: 관리 대상에 이름/번호 부여 후 계층 구조로 구분 → 수정/추적 용이
• 형상 통제: 식별된 형상 항목에 대한 변경 요구 검토 (기준선 반영될 수 있게)
• 형상 감사: 기준선(Base line)의 무결성 평가 위해 확인/검증/검열 과정 진행
• 형상 기록: 형상 식별/통제/감사 작업 결과를 기록/관리하고 보고서 작성

※ 제품 SW의 형상 관리 역할: 배포본 관리 유용 / 소스 수정 제한 / 동일 프로젝트에 대해 여러 개발자 참여 후 동시 개발 가능

■ 소프트웨어 버전 관리 도구

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

※ 형상관리 도구
- CVS: 서버/클라이언트 구성, 다수의 인원이 동시 버전 관리 가능
- SVN(Subversion): CVS 개선 툴 / 모든 개발은 trunk 디렉터리에서 수행 / Commit 수행 시 revision 1씩 증가
- Git: 서버(원격) 저장소와 개발자(지역) 저장소가 독립적 → Commit 실수 발생해도 서버에 영향 없음(분산된 P2P 모델)

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

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

■ CMMI(Capability Maturity Model Integration): SW 개발 조직의 업무 능력 평가 모델

1) 초기: 프로세스X - 작업자 능력에 따라 성공 여부 결정

2) 관리: 규칙화 프로세스 - 특정한 프로젝트 내의 프로젝트 정의/수행

3) 정의: 표준화 프로세스 - 조직의 표준 프로세스 활용 업무 수행

4) 정량적 관리: 예측 가능 프로세스 - 프로젝트 정량적 관리/통제

5) 최적화: 지속 개성 프로세스 - 프로세스 역량 향상 위한 지속적인 개선