은둔형 공학자

인수 테스트(Acceptance Test) 

정의 

사용자측 관점에서 소프트웨어가 요구를 충족시키는가를 평가 

종류 

확인 테스트,  알파 테스트&베타 테스트 , 설치 테스트 

인수 테스트(Acceptance Test) 

종류 

확인 테스트(Validation Test) 

개발 집단이 사용자 집단을 대신하여 검토회(Review, Inspection, Walkthrough) 등 일정한 방법을 사용하면서 품질보증에 임하는 것 

알파(Alpha) 테스트와 베타(Beta) 테스트 

알파 테스트 

특정 사용자들에 의해 개발자의 입장에서 테스트를 실행 

베타 테스트 

선정된 여러 사용자들이 자신들의 사용환경에서 일정기간 사용해 보면서 문제점들을 기록하고 추후에 반영될 수 있도록 개발조직에게 통보해 주는 형식을 취함 

설치 테스트 

 소프트웨어기능상의 오류를 발견하기 위해서 하는 시험이 아님 

 소프트웨어를 사용자환경에 맞도록 설치하는 과정에서 나타날 수 있는 결함을 발견하기 위해서 하는 테스트 

최적화(Optimization) 

개념 

효율적인 체계를 위한 조정으로서 체계가 가져야 할 선행 조건을 만족시킨 후 효율성을 고려하여 이루어져야 함 

기본 원칙 

효율적인 체계를 구현하는 것보다 구현된 체계를 효율적으로 개선하는 것에 더 중점 1 

최대의 응집도, 최소의 결합도 유지 등의 단순성(Simplicity)을 추구 2 

성능 평가에서 문제가 되었을 경우에만 시스템을 최적화  3 

최적화할 가치가 있다고 판단되는 부분만을 개선  4 

수행절차 

체계의 성능 평가 

시스템의 성능을 평가함으로써 해당되는 최약점(Hot-spot)을 인식하여 최적화 

– 최적화가 가장 필요한 정확한 위치를 측정하여 특정  코드를 삽입 

시스템 조정 

시스템이 비효율적으로 작동되는 부분을 찾아낸 후 최적화할 기법을 결정 

– 개선에 필요한 방법과 비용 및 효과를 정리하고 가능한 한 시스템 전체의 구조는 그대로 유지 

재평가, 재개선의 반복 

적용 대상 

물리적 입출력, 인터페이스의 내역  1 

중간 파일, 버퍼의 수 및 크기, 블로킹 요소, 파일의 접근 방법 

모듈의 알고리즘  2 

프로그램 언어  3 

가상 기억 장치(Virtual Memory)의 운영 연구, 페이지 폴트 (Page Fault) 고려 4 

loop문의 내부 분석  5 

Perform, Macro의 사용  6 

언어의 특성 연구 및 컴파일러의 상세 내역  7 

운영 체제의 연구  8 

정적 분석 도구(Static Analysis Tool) 

코드 분석 도구 

원시 코드의 문법적 적합성을 자동으로 평가하여 잘못된 문장을 표기 

구조 검사 도구 

원시코드의 그래프를 생성하여 논리 흐름을 보여주고 구조적인 결함이 있는지 체크 

데이터 분석 도구 

 원시 코드에 정의된 데이터 구조, 데이터 선언,  컴포넌트 인터페이스를 검사 

 잘못된 링크나 데이터 정의의 충돌, 잘못된 데이터의 사용 등을 발견 

순서 검사 도구 

이벤트의 순서 체크 

-  잘못된 순서로 코딩되어 있다면 이벤트를 지적 

동적 분석 도구(Dynamic Analysis Tool) 

프로그램이 수행되는 동안 이벤트의 상태를 파악하기 위하여 특정한 변수나 조건의 스냅샷(Snapshot)을 생성 

테스트 케이스 생성 도구 

자료 흐름도 

 원시 프로그램을 입력받아 파싱한 후 자료 흐름도를 작성 

 Define-use 관계 

 찾으려는 변수에 영향을 주는 요소들을 모아 테스트 경로를 구동시키는 입력 값들을 찾아냄  

기능 테스트  

주어진 기능을 구동시키는 모든 가능한 상태를 파악하여 이에 대한 입력을 작성 

입력 도메인 분석 

원시코드의 내부를 참조하지 않음 

입력 변수가 가질 수 있는 값의 도메인 분석 

랜덤 테스트  

입력 값을 무작위로 추출 

시스템의 신뢰성 분석에 사용 

테스트 실행 도구 

캡처 및 리플레이 

 테스트 계획에 표시된 테스트 데이터를 자동으로 입력하고 실행 과정에 발생하는 화면이나 인쇄되는 결과를 캡처 

 예상되는 결과와 비교 

 예상되는 결과와 차이를 보일 경우 테스트 프로그래머에게 보고 

 오류를 발견하고 수정한 후 고치는 작업이 바르게 되었는지 확인하는 데 유용 

자동적으로 스텁과 드라이버를 생성하는 도구  

자동 테스트 환경 

테스트 수행 도구들이 테스트 환경으로 통합되어 제공  

테스트 드라이버(Test Driver) 

 시스템 및 시스템 컴포넌트를 시험하는 환경의 일부분으로 시험을 지원하는 목적하에 생성된 코드와 데이터 

 테스트 드라이버는 테스트할 소프트웨어 또는 시스템을 제어하고 동작시키는 데 사용되는 도구들 

– 예 : 순차적으로 실행되는 프로그램이나 명령들의 목록이  담긴 "배치파일” 

테스트 스텁(Test Stub) 

특정 시스템 컴포넌트의 개발이 완료되지 않은 상황에서도 필요한 시험을 진행하기 위해 생성된 더미 컴포넌트 

– 예 : 프린터 등과 같은 외부장비를 테스트할 때 PC에서  보내는 신호를 확인하는 용도로 해당 장비를  대신하여 스텁을 구성하여 사용 

스텁은 테스트하는 소프트웨어 또는 시스템을 제어하거나 조작하지 않는다는 점에서 본질적으로 테스트 드라이버와는 반대되는 개념 

테스트 데이터 생성기(Test Data Generators) 

프로그램이 어느 특정한 형태로 동작하도록 사용자의 테스트 데이터 선택을 도와줌 

테스트 검증기(Test Verifiers) 

테스트 대상의 제어 구조에 관련된 내부 테스트 적용 범위를 측정하여 품질 보증 부서에 그 적용 값 보고 

테스트 이용기(Test Harness) 

후보가 되는 프로그램을 테스트 환경에 높음

거기에 입력 데이터 전송 

스텁에 의해 종속 모듈의 시뮬레이터를 쉽게 하여 테스트 처리 지원 

출력 비교기(Output Comparators) 

프로그램의 출력을 이전 출력과 비교하여 그들의 차이를 결정 

테스트의 정의와 목적 

정의 

프로그램의 버그를 찾아내는 것 

목적 

요구 사항의 만족도 및 예상 결과와 설계 결과와의 차이점을 테스트하기 위해 시스템을 실행 평가하는 일 1 

소프트웨어의 품질을 측정하는 일  2 

오류를 발견하기 위해 프로그램이나 시스템을 수행하는 일  3 

테스트의 종류 

기본 단위 테스팅(Unit Testing) 

독립적인 환경에서 하나의 모듈만을 테스트하는 것 

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

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

통합 테스팅(Integration Testing) 

시스템 모듈 간의 상호 인터페이스에 대한 테스트 

 하향식 테스트(Top-down Test) 

 상향식 테스트(Bottom-up Test) 

 샌드위치 테스트(Sandwich Test) 

 빅뱅 테스트(Big Bang Test) 

시스템 테스팅(System Testing) 

초기의 목적에 시스템이 부합하는지에 대한 테스팅 

모의 환경 또는 실제 환경에서 행해질 수 있음 

테스팅 검토(Testing Overview) 

프로그램이 실제로 구현할 수 있는 완전한 준비가 되었는가를 결정하는 것 

통합 테스트(Integration Testing) 

개념 

인터페이스와 관련된 오류를 발견해내는 테스트를 수행하는 것과 동시에 프로그램 구조를 구현하는 체계적인 기법 

종류 

시스템을 구성하는 여러 모듈을 어떤 순서로 결합하여 테스트할 것이냐에 따라 구분  

빅뱅 통합 

개요 

 각 모듈을 개별적으로 단위 테스트 

 상호 간의 인터페이스에 대하여는 고려하지 않음 

 모든 모듈의 단위 테스트가 끝난 시점에서 한꺼번에 결합 

 대규모 시스템에서는 비효율적 

– 한꺼번에 결합하여 프로그램을 테스트하여 이상한 결과가 생기는 경우 어느 모듈이 원인인가를 파악하기 어려움 

→ 모든 모듈 조사 필수 

 소규모적인 프로그램에서 모듈 구조가 잘 설계되어 인터페이스가 번잡하지 않을 경우 사용 

하향식 통합 

개요 

 상위 모듈로부터 하위 모듈을 향하여 수행하는 테스트 

 시스템을 구성하는 모듈의 실현 순서에 대하여 충분하게 들여다 볼 수 있음 

 유사한 시스템 개발의 경험이 있는 개발팀에서 많이 실시하는 전략 

 기능 모듈이 구조화되고, 계층 순으로 개발하는 프로세스가 잘 관리된 시스템 개발에서 많이 채용 

 하위 모듈을 호출하는 상위 모듈이 먼저 테스트되므로 별도의 테스트 드라이버 프로그램 작성 불필요 

스텁(Stub) 

 상위 모듈의 테스트 단계에서는 하위 모듈이 개발 중이던가 또는 테스트에 미착수의 상태에 있기 때문에 상위 모듈에 대하여 데이터와 제어를 주고 받는 가짜 하위 모듈 

 테스트 중의 상위 모듈로부터 데이터를 받아서 체크하기도 하고, 상위 모듈과의 인터페이스가 매칭되면 실행 방법은 관계 없음 

장단점 

장점 

 구조화된 모듈의 구축 순서에 따라서 테스트가 실시 

 개발의 조기 단계에서부터 테스트 이루어짐 

 시스템에 커다란 영향을 주는 상위 모듈 사이의 테스트가 먼저 이루어져서 테스트 범위가 단계적으로 내려가므로 테스트 확인하기 쉬움 

 드라이버와 비교해서 스텁 쪽이 작성하기 쉬움 

단점 

 시스템 전체의 성능이나 기능의 실현성에서 중심이 되는 모듈이 하위에 존재하는 경우에는 그 단계까지 테스트가 진행되지 않으면 확인 불가 

 충분히 테스트된 모듈을 부품으로서 사용하는 경우에 상위 모듈과 부품과의 사이에 인터페이스가 준비되지 않을 경우는 새로운 부품을 개발해야 되는지의 판단이 지연 

상향식 통합 

개요 

 계층화된 모듈 구조의 하위 모듈로부터 상위 모듈을 향하여 테스트를 실시하는 방법 

 개발하는 시스템 가운데 실제로 실현 가능한지 여부를 확인하는 일이 곤란한 불확실한 요소를 포함하는 경우에 자주 취하는 전략 

테스트 드라이버 

가짜 상위 모듈 

 테스트를 실시하는 데에는 테스트가 끝난 하위 모듈을 호출하는 상위 모듈을 준비할 필요 

 상위 모듈은 개발 중이던가 테스트가 착수되지 않았기 때문에 사용할 수 없음 

 상위 모듈 대신 하위 모듈을 호출하여 아규먼트를 끄집어 내는 가짜의 상위 모듈을 테스트용으로 작성 

역할

– 하위 모듈의 호출 환경의 설정 

– 하위 모듈의 호출 제어 

– 하위 모듈에의 데이터 전달 

– 하위 모듈로부터 데이터 수취 

장단점 

장점 

 하위 모듈의 개발을 테스트까지 독립적이며 또한 병행하여 실시 

 충분히 테스트된 부품으로써 모듈을 많이 사용하는 경우에는 부품의 조합 방법을 확인하고 나서 테스트 실시 

단점 

 테스트를 개시할 때까지 하위 모듈 사이의 인터페이스가 확인되지 않음 

– 시스템을 구성하는 상위 모듈 사이의 인터페이스 조정은 테스트 맨 끝에 수행 

– 상위 모듈의 테스트 단계에서 인터페이스 사이에 결함이 발견되면 그 영향은 하위 모듈 전체로 파급 

 테스트 드라이버의 작성에 추가로 노력과 비용 필요 

시스템 테스팅(System Testing) 

정의 

기능, 성능, 스트레스, 보안, 용량, 사용용이성, 복구, 신뢰성, 호환성 등등 여러 유형 시험들의 집합 

외부 기능 테스트(Function Test) 

정의 

소프트웨어에 대한 외부로부터의 시각에서 요구분석 단계에서 정의된 외부명세(External Specification)의 충족성을 테스트 

내부 기능 테스트(Facility Test) 

정의 

사용자의 상세 기능 요구를 요구명세서의 문장 한 줄 한 줄 하나를 짚어가며 테스트 

부피 테스트(Volume Test) 

정의 

소프트웨어로 하여금 상당량의 데이터를 처리해 보도록 여건을 조성하는 것 

스트레스 테스트(Stress Test) 

정의 

 소프트웨어에게 다양한 스트레스를 가해 보는 것 

 민감성 테스트(Sensitivity Test)라고 불리기도 함 

성능 테스트(Performance Test)  

정의 

소프트웨어의 효율성을 진단하는 것 

– 응답속도(Response Time) 

– 처리량(Throughput) 

– 처리속도(Traffic) 등 

보안 테스트(Security Test) 

정의 

 불법적인 소프트웨어 사용을 방지하는 테스트 

 자체의 보안체계(security mechanism)가 완벽한가 살피는 것 

사용용이성 테스트(Usability Test) 

정의 

인간공학적(Human Factors)인 시각에서 테스트해 보는 것 

사용성 테스트의 질문 예 

 사용자 인터페이스가 사용자들의 지적 수준, 교육, 환경과 적절한가? 

 소프트웨어의 출력이 의미 있고, 용어의 남용이 없고 횡설수설하지 않도록 꾸며졌나? 

 에러 메시지가 간단명료하며 이해하기 쉬운가? 

 문법, 형식, 스타일, 약어 사용 등에 일관성과 통일성을 갖추었나? 

 온라인 은행시스템처럼 정확성이 매우 중요할 때 구좌번호와 고객성명을 동시에 출력시키는 등 충분한 중복성이 제공되고 있는가? 

 필요 이상의 선택을 부여하여 사용상 혼란을 초래하지는 않는가? 

 입력을 받아들이는 순간 그 사실을 인정하는 증거를 출력하는가? 

 사용이 쉬운가? 예를 들어, 필요 이상의 마우스클릭이나 키보드의 시프트 키를 눌러야 하지는 않는가? 

기억장치 테스트(Storage Test) 

정의 

소프트웨어가 요구하는 주기억장치와 보조기억장치의 일정요량의 활용도를 테스트 

호환성 테스트(Compatibility Test) 

정의 

 많은 소프트웨어들은 철저하게 새롭기보다는 이미 사용 중인 소프트웨어의 대체용일 가능성이 높음  

 기존 소프트웨어와 호환성을 따져보는 것 

설치용이성 테스트(Installability Test) 

정의 

소프트웨어의 설치 절차는 예상외로 복잡할 수 있으므로 설치절차를 따라가며 그 타당성 및 용이성을 평가 

신뢰성 테스트(Reliability Test) 

정의 

소프트웨어가 오류를 발생시키고 고장(Failure)을 내는 정도를 테스트 

복구 테스트(Recovery Test) 

정의 

소프트웨어가 자체결함이나 하드웨어 고장 또는 데이터의 오류로부터 어떻게 회복하느냐를 평가하는 것 

구성 테스트(Configuration Test)  

정의 

시스템 테스트의 모든 가능한 구성에 대비하는 것은 현실적으로 어렵겠으나, 가능한 한 다양한 기종이나 구성 하에서 테스트해보는 것 

보수용이성 테스트(Serviceability Test) 

정의 

고장진단, 보수절차 및 문서 유지 보수 단계에서의 작용을 얼마나 용이하도록 하고 있는가를 테스트 

1. 컴포넌트 기반 개발 

동향 

소프트웨어의 재사용성과 빠른 생산성, 품질 향상을 위한 방법으로 확산 

컴포넌트 간의 조립에 의한 새로운 어플리케이션과 시스템 개발로 확장 발전 

시스템 개발은 코드 작성 대신에 기존 소프트웨어 컴포넌트를 조립하는 것으로 대체 

종류 

EJB 

J2EE 안에서 기업용 비즈니스 어플리케이션을 개발하고 운용하기 위한 서버 측 컴포넌트 모델 

– 한번 개발되면 재컴파일이나 소스 코드 수정 없이 다른 EJB 어플리케이션 플랫폼에서도 그대로 재사용 가능 

CORBA 

언어 독립적이나 사용하기 어려움 

COM+ 

MS사에 너무 종속적인 문제점 

전망 

 향후 EJB 컴포넌트 모델에 의해 개발 배포된 컴포넌트 (ejb.jar 파일) 증가 예상 

 Dll로 만들어진 컴포넌트들을 조립하여 큰 단위의 소프트웨어 시스템을 개발하는 데 초점 

컴포넌트 기반 소프트웨어 개발 

현재 소프트웨어 개발의 문제점 

 품질 관리의 어려움 

 저 생산성 

 높은 개발 비용 

 제어상의 어려움을 야기 

컴포넌트 기반 소프트웨어 개발 방법(CBD) 등장 

 적합한 Off-The-Shelf 컴포넌트를 선택하여 개발하고, 잘 정의된 소프트웨어 아키텍처를 조립하는 소프트웨어 시스템 개념에 기반 

 상업적인 컴포넌트(COTS)는 다른 플랫폼과 다른 언어를 사용하여 서로 다른 개발자에 의해 개발 가능 

 개발 비용과 판매 시간을 감소시키고, 소프트웨어 시스템의 전체 품질, 신뢰성과 유지보수성 개선시킴 

컴포넌트의 중요 특징 

 독립적이며, Clear Function을 완료하는 시스템의 대체 가능한 부분 

 잘 정의된 구조의 문법 

 인터페이스에 의해 다른 컴포넌트와 상호 통신 

 컴포넌트 기반 소프트웨어 시스템이 정확하고 효과적으로 실행될 수 있음을 보증하기 위해, 시스템 구조는 가장 중요한 요인 

 계층화되어 있고, 모듈러 아키텍처로 구성 

컴포넌트 기반 소프트웨어 시스템 아키텍처 

최상위 계층      비즈니스를 지원하는 어플리케이션 시스템 

두 번째 계층     어플리케이션 도메인이나 특별한 비즈니스에서 사용 중인 컴포넌트로 구성 

세 번째 계층     일반적인 소프트웨어와 엔티티를 위한 인터페이스로 구성된 Cross-Business 미들 웨어 컴포넌트 

최하위 계층      기본적인 운영체제나 하드웨어와 관련된 인터페이스인 기본 컴포넌트 포함 

컴포넌트 기반 소프트웨어 개발 생명주기 

요구사항 분석(Requirements Analysis)  1 

소프트웨어 구조 선택, 구성, 분석, 평가(Software Architecture Selection, Construction, Analysis and Evaluation) 2 

컴포넌트 식별과 주문제작 (Component Identification and Customization) 3 

시스템 통합(System Integration)  4 

시스템 테스팅(System Testing)  5 

소프트웨어 유지 보수(Software Maintenance)  6 

컴포넌트 식별, 주문제작, 통합의 중요 부분 

 컴포넌트를 평가하기 위해 사용될 수 있는 기능성과 품질 요구사항에 기반한 후보 COTS 컴포넌트 평가 

 새로운 컴포넌트 기반 소프트웨어 시스템으로 통합된 후 변경되는 후보 COTS 컴포넌트의 주문 제작, 통합은 목적 소프트웨어 시스템의 다양한 컴포넌트 사이에서 대등 관계와 상호통신을 제공하기 위한 방법의 중요한 결과만 

COTS(Commercial, Off-The-Shelf) 

완성품으로 일반 대중에게 판매, 대여 또는 권한을 부여할 수 있는 컴퓨터 소프트웨어나 하드웨어, 기술 또는 컴퓨터 제품 

장점 

개발비용과 소요시간을 절약 

단점 

제3자가 되는 컴포넌트 벤더에 의존성이 커짐 

컴포넌트 요구사항 분석 

 컴포넌트에 대한 요구사항을 관리, 확인, 문서화하고 이해하고 발견하는 프로세스 

 목적 

– 컴포넌트와 연관된 인터페이스와 플랫폼, 프로그래밍 언어를 보다 잘 인식할 수 있는 컴포넌트와 관련된 요구사항을 만드는 것 

 오래된 시스템을 변경하거나 새로 개발하기 위한 사용자나 고객의 요구에 의해 시작 

 요구사항 수집과 정의, 요구사항 분석, 컴포넌트 모델링, 요구사항 확인의 네 단계로 구성 

컴포넌트 개발 

 보다 나은 기능성, 다중 인터페이스와 관련된 높은 품질 컴포넌트를 위한 요구사항을 분석하는 프로세스 

 목적 

– 융통성 있는 인터페이스, 잘 정의된 행위, 예상되는 결과와 연결되어 있는 요구사항을 만족하는 최종 컴포넌트 생성 

 실행, 기능 테스팅, 신뢰성 테스팅, 개발 문서의 네 가지 절차로 구성 

 입력  

– 컴포넌트 요구사항 문서 

 출력  

– 컴포넌트 증명과 시스템 유지 보수를 위해 준비되는 컴포넌트와 문서  

컴포넌트 증명 

컴포넌트 외부 발주 

계약자의 작업을 회계 감사하고, 컴포넌트 아웃 소싱 계약 관리 

컴포넌트 선택 

기능성과 신뢰성에 대한 요구사항과 일치하는 컴포넌트를 선택 

컴포넌트 테스팅 

높은 품질, 신뢰성과 관련된 시스템 요구 사항을 만족하는지 점검하고, 후보 컴포넌트를 테스트 · 선택 · 아웃 소싱하기 위한 것 

목적 

컴포넌트가 만족스러운 품질과 신뢰성과 관련된 요구사항을 만족하는지 확인 

관리 정책 

 컴포넌트 아웃 소싱은 소프트웨어 계약 관리자에 의해 요구 

 모든 후보 컴포넌트는 모든 알려진 결함을 제거하기 위해 테스트 

 테스팅은 목적 환경이나 모의 실험된 환경에서 이루어짐 

 입력 

-  컴포넌트 개발 문서 

 출력 

-  시스템 유지 보수를 위한 테스팅 문서 

컴포넌트 주문제작 

 명확한 요구 사항을 위한 컴포넌트 변경 

 특별한 플랫폼상에서 컴포넌트를 동작시키기 위해 필요한 변화 

 더 나은 수행과 품질을 가지기 위해 컴포넌트를 갱신 

 목적 

– 다른 컴포넌트와 협력하고, 특별한 환경에서 사용되어질 수 있는 개발된 컴포넌트를 위해 필요에 따라 변경 

 모든 컴포넌트는 동작 가능한 시스템에서의 요구사항이나 다른 컴포넌트와 관련된 인터페이스 요구사항과  연관되게 제작 

– 입력 

→ 시스템 요구사항, 컴포넌트 요구사항, 컴포넌트 개발문서 

– 출력 

→ 제작된 컴포넌트, 시스템 통합과 시스템 유지보수에 대한 문서 

시스템 아키텍처 설계 

 컴포넌트 기반 시스템이 소프트웨어 구조를 생성, 선택, 평가하는 프로세스 

 목적 

– 사용자 요구사항을 수집하고, 시스템 명세를 정의하고, 적당한 시스템 구조를 선택하고, 플랫폼이나 프로그래밍 언어 같은 실행하는 데 필요한 세부사항을 결정 

 시스템 요구사항 수집, 분석, 시스템 구조 설계, 시스템 명세로 구성 

 출력 

– 통합을 위한 시스템 명세 문서, 시스템 테스팅 부분과 유지보수 부분을 위한 시스템 요구사항 

시스템 통합 

 설계된 시스템 구조하의 전체 시스템에서 선택된 프로세스를 조립하는 프로세스 

 목적 

– 선택된 컴포넌트에 의해 구성된 최종 시스템 

– 통합, 테스팅, 컴포넌트 변경과 재통합 단계로 구성 

– 입력 

→ 시스템 요구사항 문서와 시스템 구조 

– 출력 

→ 시스템 테스팅 부분을 위해 준비된 최종 시스템과 시스템 유지 보수를 위한 문서 

시스템 테스팅 

시스템을 평가하는 프로세스 

 명확한 요구사항을 만족하는 시스템인지 확인 

 시스템 실행에서 결함 확인 

목적 

요구사항과 일치하여 선택된 컴포넌트에 의해 통합된 최종 시스템 

기능 테스팅과 신뢰성 테스팅 포함 

 테스팅 전략 선택, 시스템 테스팅, 사용자가 선택한  테스팅으로 구성 

 입력 

- 컴포넌트 개발과 시스템 통합으로부터의 문서 

 출력 

- 시스템 유지 보수를 위한 테스팅 문서 

시스템 유지 보수 

 소프트웨어를 효과적으로 사용하기 위해 요구되는 유지보수 활동과 서비스를 제공하는 프로세스 

 목적 

– 변화된 환경에서 시스템을 적응시키고, 소프트웨어 수행이나 다른 속성을 개선시키고 결함을 제거하여 말단 사용자에게 효과적인 생산물과 서비스를 제공 

 시스템 유지 보수는 지원 전략과 문제 관리를 결정 

 출력 

– 시스템 수명 주기를 위한 시스템 테스팅 부분을 위해 제시되는 새로운 버전 

코드검사의 개념 

개념 

 소프트웨어 공학의 기본 개념은 검사(Inspection)에 기초하고 있으며, 검사는 품질 문제를 개인에 의지하지 않고 조직적으로 해결하려는 노력이라 볼 수 있음 

 프로그래밍에 소요되는 비용 중 가장 핵심적인 부분은 오류를 찾아내고, 이를 고치는 것 

 코드 검사(Code Inspection)는 소프트웨어의 오류를 발견하여 제거함으로써 높은 품질의 소프트웨어를 얻기 위한 활동 중의 하나이며, 프로그램을 만든 후 이에 대한 검사를 수행하는 것 

 코드 검사는 소프트웨어 개발 과정에서 요구되는 공식 기술검토 중의 하나로 코드에 대한 시험 이전에 이루어지며, 이를 위한 검사 팀(Inspection Team)이 만들어져 코드에 관한 결함과 요구사항과 표준에 따라 프로그래밍이 이루어졌는지 조사하는 것   

 코드 검사는 단위시험(Unit Test) 이전이나 이후에 이루어짐  

 코드 검사는 공식적인 기술 검토인 만큼 잘 정의되어 있는 순서와 방법에 의해 이루어져야 하며 조심스럽게 진행 

 여러 사람들이 다른 사람이 만든 프로그램에 대한 지식을 공유할 수 있고, 함께 좋은 품질의 시스템을 개발한다는 공감대를 형성하는데 기여 

 프로그램 스타일을 표준화할 수 있으며, 코드가 개발 과정에서 나오는 문서로서 인식될 수 있게 함 

 현재 많은 소프트웨어 개발 조직에서 코드 검사를 소프트웨어 개발 라이프 사이클에 포함시켜 소프트웨어를 개발하고 있으며, 코드 검사는 품질 보증 활동(SQA: Software Quality Assurance)의 일부로 인식 

 코드 검사를 수행하는 것은 프로그램 개발도 개인에 의해 이루어지는 것이 아니라 조직에 의해 이루어짐을 보여주는 것이라 할 수 있음  

 코드 검사를 성공적으로 수행하기 위해 이를 수행하는 구성원은 코드 검사에 요구되는 훈련과 교육을 받아야 함 

 코드 검사를 위해 사전에 각 참여자의 역할이 주어짐 

- 참여자들은 검사할 코드에 대해 미리 조사해 와야 하며 검사 결과는 품질 관리와 추후 관리를 위해 문서로 기록되어야 함 

 코드에 대한 검사는 프로젝트와 관계가 있는 동료 프로그래머들에 의해 수행되는 것이 일반적이며, 관리자들이 참석하지 않는 것이 바람직함 

 코드 검사 또한 신중하게 이루어져야 하며 코드 자체에 대한 기술적인 검토만 이루어져야 함  

 코드 검사는 공식적인 기술 검토회 중의 하나로 인식  

- 따라서 검사를 위한 체계적인 틀이 만들어져야 하고 참여자는 이를 숙지하여 검사에 임해야 함 

 코드 검사를 위한 계획이 수립되어야 하고, 그 결과가 통계적인 자료로 수집되어 관리자에게 보고됨 

코드검사 계획 

 새로 만들어지는 코드는 검사대상이 되고, 새로운 기능이 추가되거나 많은 변화가 가해진 코드는 검사 대상이 됨  

 일반적으로 코드 검사의 필요성이 느껴지면 이를 수행할 수 있음 

 검사해야 할 코드가 결정되면 코드를 만든 사람은 코드 검사 조정자에게 통보  

 조정자와 코드를 만든 저자가 검사할 팀을 선정하며, 코드 검사는 최소한도의 인원으로 수행되어야 함 

 검사 팀은 4 - 7명이 적당하며, 낭독자(Reader), 사회자(Moderator), 검사자(Inspector), 기록자(Recorder)와 프로그램을 만든 저자(Author)로 역할을 분담 

검사 팀의 구성 

저자(author)             코드를 만든 사람으로 코드에 대한 정보를 제공하고 문제점에 대한 답변을 할 수 있음 

사회자(moderator)     코드 검사를 진행하는 의장이며 코드 검사에서 중심 역할을 수행 

낭독자(reader)          코드를 한 줄씩 또는 한 절씩 읽어나가며 이를 해석 

기록자(recorder)         검토 도중 문제점이나 오류를 기록하며 이를 요약하여 회의록을 만들고 그 결과를 배포 

검사자(inspector)         검사자는 사전에 코드에 대해 구체적으로 검사하고 검토회 진행 중에도 이를 수행 

코드검사 진행 

 제품의 개발 과정과 절차를 향상시키는 것이 품질과 생산성을 높이는 가장 효율적인 방법  

 개발 절차는 품질에 가장 큰 영향을 미치는 것으로 알려져 있으며, 품질 문제의 85%는 개발 과정과 직접적인 연관성을 가지고 있다고 알려져 있음 

 참여자들은 검토회를 하기 이전 코드를 읽고 의문점과 문제점을 파악하여야 함  

 코드 검사는 오류를 지적하는 것이지 그 해결 방법을 찾으려는 것이 아니며, 최소한도의 시간이 소요되도록 함 

 코드 검사는 일반적으로 4 - 5명이 팀이 되어 수행할 수 있고, 시간을 절약해야 하는 경우라면 일 대 일(One-To-One) 검사도 생각해볼 수 있음  

 다른 사람이 만든 코드를 검토하는 것은 매우 민감한 사항임 

 코드 검토를 통해 업무의 상승효과를 얻을 수 있도록 하여야 함 

- 이를 위해 코드 검토는 기술적인 것(코드)에만 국한되어야 하며 조심스럽게 진행되어야 함  

 검토가 끝난 후 검토한 내용에 대해 다시 거론하는 것은 바람직하지 않음 

코드의 오류 유형(Type) 

데이터 오류(DA: Data Error) 

데이터가 다루어지는데 발생하는 오류로 데이터 유형 정의, 변수 선언, 매개 변수에서 나타나는 오류  

문서 오류(DC: Documentation Error) 

프로그램 구성요소인 선언 부분, 서브루틴, 모듈에 대한 적합하지 않은 주석, 잘못되거나 불필요한 주석을 의미 

기능 오류(FN: Function Error) 

서브루틴이나 블록이 잘못된 것(What)을 수행하는 오류 

논리 오류(LO: Logic Error) 

서브루틴이나 블록이 수행하는 방법(How)이 잘못되어 있는 오류 

성능 오류(PF: Performance Error) 

프로그램을 수행하며 요구되는 효율성(성능)을 만족시키지 못하는 오류 

표준 오류(ST: Standard Error) 

과정이나 표현이 표준에 의해 이루어지지 않은 경우 

기타(OT: Error) 

문법적인 오류, 사람의 개성이 포함된 경우 등 앞의 유형으로 설명하기 힘든  불투명하고 애매모호한 오류를 나타냄 

코드 검사 사후 검토 

 코드 저자는 코드 검사에서 나타난 오류와 문제점을 수정하여 이를 코드 검사 사회자에게 검사를 받음 

- 이는 추후에 새로 나타나는 오류를 줄이고 더 이상의 오류가   발생하지 않도록 하는데 그 목적이 있음  

 일반적으로 코드 검사의 결과를 관리자들이 개인의 업무 수행 능력에 대한 평가로 사용되는 것은 바람직하지 않음 

- 이유는 코드 검사가 적은 비용으로 보다 자유스러운 분위기 속에서 이루어질 수 있도록 하기 위함  

프로그래밍(Programming)의 개념 

개념 

소프트웨어 개발 과정에서 프로그래밍은 설계의 연장 

상세 설계가 끝난 후 프로그래밍(코딩)에 들어가며, 프로그래밍은 설계 명세서에 나타난 결과를 더욱 구체화시켜 컴퓨터가 이해할 수 있는 모습으로 바꾸는 것

컴퓨터가 이해할 수 있는 언어로 표현한다는 뜻 

프로그래밍 언어 - 컴퓨터가 이해할 수 있는 언어 

코딩은 설계의 자연스러운 결과 

설계가 제대로 이루어지면 프로그래밍은 기계적으로 이루어진다고 볼 수 있음 

프로그래밍 언어는 인간과 컴퓨터 사이의 통신 또는 대화 수단으로 사용되는 컴퓨터 언어 

지금까지 수백 종의 프로그래밍 언어가 개발되어 사용됨 

현재도 기계어, 어셈블리어, 고급언어 등 다양한 언어들이 사용 

소프트웨어 품질과 유지보수에 영향을 끼침 

프로그래밍언어의 세대별 분류 

1세대 언어 

1950년 전후, 기계어 또는 어셈블리 언어 

2세대 언어 

1950년대 후반, 최초의 고급언어인 FORTRAN, COBOL 등 등장 

3세대 언어 

구조적 프로그래밍을 지원하는 언어인 ALGOL, PASCAL, Smalltalk, C, C++ 등의 등장 

4세대 언어 

수행하는 과정을 프로그래밍하기 보다는 의도하는 결과물을 선언하는 비절차적 언어 (Non-Procedural Languages)의 등장 

비 절차식 언어(Non-Procedural Languages) 

구체적인 알고리즘을 명시할 필요가 없음 

추상화 수준을 높일 수 있음 

쉽게 프로그래밍할 수 있음 

비 절차 언어 

관계형 데이터베이스의 질의어인 SQL (Structured Query Language), PROLOG 등을 들 수 있음 

SQL 질의어 예 

추상화 수준을 높일 수 있음 

예 - SELECT AVG(SALARY) 

      FROM EMPLYEE 

      WHERE DNAME = 'RESEARCH' 

2. 개발원리 및 단계 

코딩 원리 

코딩 작업 

각 모듈에 대한 원시코드를 작성 

모듈 안에 포함된 오류를 검출하는 단계 

코딩 원칙 

설계를 철저히 반영 

원시코드는 간단 명료하도록 함 

디버깅이 쉽게함 

시험이 용이 

수정이 간편 

코딩 

정의 

분리하여 구현할 수 있는 작은 단위를 프로그래밍하는 작업 

모듈 안의 함수 작성              절차적 방법 

개별 메소드의 프로그래밍       객체지향 방법 

목표 

설계 명세에 나타낸 요구를 만족하는 프로그램을 작성 

요구분석서, 아키텍처 설계서 참조 

오류가 적은 품질 좋은 프로그램 작성 

원리와 가이드 준수  

코딩 작업의 순서 

원시코드를 같은 스타일로 만들기 위한 코딩 표준 작성  1 

아키텍처 설계 결과를 근거로 프레임워크 패키지와 응용 패키지를 구분 2 

요구사항과 상세설계를 반영하여 메소드 코딩 

인스펙션(Inspection)   3 

검증 또는 검사 

클래스 단위로 테스트  4 

통합을 위하여 릴리스  5 

구조적 프로그래밍 

원시코드정의 

프로그램의 제어흐름을 선형화시켜 논리구조를 명백하게 하려는 코딩 규율 

구조적 프로그램 

세가지 제어구조(순차, 선택, 반복)로 무조건적 Goto에 의한 복잡한 제어흐름을 방지 

제어구조가 하향식 

Stepwise Refinement를 이용한 프로그래밍 

Proper Program 

단일입구, 단일 출구 

모든 노드는 입구에서 도달할 수 있는 경로가 있어야 함 

모든 노드는 출구에서 도달할 수 있는 경로가 있어야 함 

정보은닉 

용도 

일반적으로 어떤 정보에 대하여 제한된 방법으로만 사용 

예 - 회계 원장(차변, 대변, 잔고확인) 

→모든 차변을 더하여 대변의 합으로 나누는 것과 같은 오퍼레이션은 적용되지 않음 

자료구조 

정의 

내부의 정의가 시스템의 다른 부분으로부터 감추어져 있어야 함 

장점 

결합도를 줄이고 시스템의 유지보수를 쉽게 만듦 

데이터를 관리하는 관점과 데이터를 사용하는 관점을 분리할 수 있음 

언어자체의 메커니즘 

모듈 선택 

구현 활동의 첫 단계 

모듈들이 구현될 순서를 결정하는 것이며, 특히 어느 모듈이 다음에 구현될 것인가를 결정하는 것 

모듈 선택 작업은 두 개의 기본적 가정을 기초로 한 단순한 결정 과정  

첫 번째 가정 - 시스템이 점차적으로 코드화되고, 통합되어 테스트되는 것 

두 번째 가정 - 가정은 시스템이 하향식으로 개발되는 것 

→ 계층 구조의 상위 모듈들을 하위 모듈들보다 먼저 코드화하고 통합할 것 

모듈의 코드화 

이 단계에서는 코드(Code)가 작성되며, 이 단계의 입력은 전 단계에서 만들어진 모듈 명세서\

골격 구조 시험 단계 

 이 단계는 모듈 시험과 시스템 통합을 동시에 수행하는 활동 

 전 단계에서 작성된 코드화된 모듈은 이미 만들어진 부분 시스템과 합쳐져서 시스템이 시험됨 

프로그래밍 표준 

개념 

옷을 입는 스타일이 사람마다 다르듯이 프로그래밍 스타일도 사람마다 다름 

좋은 프로그래밍 스타일이 어떤 것이라는 정의를 내리는 것은 쉽지 않음  

좋은 프로그램이란 일반적으로 단순하고 명확하여 그 내용을 쉽게 파악할 수 있도록 만들어진 것을 일컬음 

코드는 간결하며 명확하고 이해하기 쉽도록 쓰여져야 함 

프로그램에 대한 가이드라인과 표준을 제시하는 것은 프로그램에 대한 관리를 용이하게 하고 생산성을 높이려는데 그 목적이 있음 

코드의 문서화 

개념 

프로그램이 만들어진 후 설계 명세서를 참조하지 않고도 모듈의 기능을 쉽게 이해될 수 있어야 함  

변수 이름, 레이블 이름을 정할 때도 직접적이며 정직한 이름을 사용해야 함 

식별자 이름의 선정은 프로그램을 이해하는데 중요한 역할을 함 

예 - AREA = LENGTH * HEIGHT 

프로그램 내부에 포함되는 문서 형태를 '주석문(Comments)'이라 함 

주석문은 한국어나 영어 등 우리가 사용하는 언어를 이용하여 기술 

주석문 

모듈의 목적을 기술하는 목적문 

인터페이스에 대한 기술 

호출 표본 

모든 인수에 대한 설명 

모든 종속 모듈 목록 

중요 변수들과 이들의 사용 한계, 제한 등을 포함하는 중요 정보들  

개발 역사 

모듈 설계자(Author)의 이름 

검토자의 이름과 검토 날짜 

수정 일자와 수정에 대한 설명 

가이드라인 

변수, 구조체, 함수 등은 그 의미를 알기 쉬운 이름을 사용하거나 주석을 통하여 선언 시 그 목적을 분명히 알 수 있도록 해야 함 

주석은 코드와 명확히 구분되어 눈에 잘 띄어야 함 

주석은 코드에 대한 정확한 설명을 해야 하나, 명백한 코드에 대한 재 설명은 필요 없음 

함수의 이름과 그 인자 사이에 연관관계를 명확하게 해야 함 

함수의 인자는 선언 시 인자에 대한 설명(주석)이 있어야 함  

쉽게 이해되지 않는 논리식이나 자료구조에 대한 설명(주석)이 있어야 함 

코드의 간결성 

개념 

공백을 이용하여 실행문 그룹과 주석을 명확히 구분 

편집의 편의를 위해 탭 키를 일관성 있게 사용 

복잡한 논리식과 산술식은 괄호와 줄 맞추기(Indentation)를 통해 명확하게 표현하고, 상호 관련이 있는 것 사이에는 밑줄을 그어 표현함 

두 개의 피 연산자를 갖는 산술연산자나 논리연산자의 경우에는 연산자와 피 연산자 사이를 한 칸 띄움 

단일 피 연산자를 갖는 연산자와 피 연산자 사이에는 공백이 있어서는 안 됨 

함수 이름과 시작하는 괄호 사이에는 공백이 있어서는 안 됨 

예약어(Reserved Keyword) 뒤에는 공백 

한 줄에 오직 한 문장만 코딩 

빈 줄을 사용하여 선언 부와 구현 부를 구별 

중괄호를 사용하는 방법에는 두 가지 방법이 있음 

제어문과 같은 줄에 쓰는 방법과 다음 줄에 쓰는 방법이 있음 

 제어문과 같은 줄에 쓰는 방법 

 제어문의 다음 줄에 쓰는 방법 

개념 

while (foobar != 20) 

{ 

  …… 

} 

while (foobar != 20){ 

  …… 

} 

프로그래머는 같은 Source 파일 내에서 두 가지 방법을 혼용하지만 않는다면 어떤 방식을 사용해도 상관없음 

복잡하고 긴 복합문장으로 이루어진 제어문 블록이나 함수블록의 처음과 끝을 명확히 알 수 있어야 함 

내장된 함수와 매크로를 사용 

불필요하게 사용자 정의 함수(기능이 중복되는)를 만들지 않도록 내장함수나 매크로의 기능을 익히는 것이 중요 

호환성을 극대화 하기 위해 C의 비표준적인 특성을 사용하지 말 것 

C 문법을 재정의하기 위해서 전 처리기(Preprocessor)를 사용하지 말 것  

구조체 멤버에 접근할 때 포인터(*)가 필요하지 않다면 사용하지 말 것 

예 - 가능하면 -> 연산자를 이용하는 대신 연산자를 이용 

잘 알려진 한도 값(예, 버퍼 크기)의 경우, 모듈의 시작 부분에 선언하는 것이 바람직함 

전역변수나 상수 정의를 할 경우 찾기 쉽도록 코딩  

선언 부와 구현 부를 분리하고, 많은 양의 변수나 상수를 정의할 경우 알파벳 순서대로 할 것 

코드의 명확성 

조건문에는 반드시 예외사항까지도 처리되어야 함 

함수를 만들 때 고려사항 

 함수의 길이가 너무 길거나 지나치게 짧지는 않은지 여부 

 인자의 수가 지나치게 많지는 않은지 여부 

 그 함수의 목적이 충분히 범용적이고, 명확한 목적을 갖고 있는지 여부 

 효율적인 해결책이 될 수 있는지 여부 

다음과 같은 구성은 피해야 함 

if(condition) 

  ;   /* ie. a null statement */ 

else  

  statement; 

if (!condition) 

         statement 

단순한 코드의 반복을 피하고 코드를 간단히 하기 위해 프로그램에 알맞는 프로그램 구조와 자료구조를 선택 

"#define"에 의해 정의된 상수는 대문자로 쓰고, 불분명한 상수는 "#define"을 사용하여 정의 

동적으로 변하는 자료를 사용하지 말고 Sizeof 연산자나 #define된 상수를 사용하여 자료 크기를 미리 정할 것 

비정적인(Nonstatic) 변수가 NULL 이나 0으로 초기화 되어 있다고 생각하지 말 것 

효율성을 높이기 위한 해결책을 만들었다면 코드를 바꾸기 전에 Time Command를 사용하고 그 코드의 시간 복잡도(Time Complexity)를 측정 

효율적인 해결책을 문서화할 것 

"?:" 연산자를 주의 깊게 사용하라. 가능하다면 If.... Then.... Else....를 사용하는 것이 명확 

If.... Then.... Else....를 사용하는 것이 명확 

다중 출구를 갖는 Loop를 주의해서 사용할 것  

Break Statement 가 Loop 종결 조건에 합해질 수 있는가? 

Continue Statement를 주의해서 사용 

Continue Statement에 의해 실행되어지지 않는 어떤 코드를 실행하기 위해 If Statement를 사용할 수 있는가를 생각 

공동으로 사용되는 변수를 분리해서 사용하지 말고 구조체를 이용 

예 - struct tn  

      char npa[4]; 

      char nnx[5]; 

               ;) 

이렇게 관리하는 것이 서로 다른 변수를 사용하는 것보다 Loop 등에서 편리하게 이용 

정적인 함수를 사용하고, 전역변수(Global Variable)는 피해야 함 

 이렇게 함으로써 작성된 함수나 변수가 다른 목적으로 다른 프로그램에서 이용될 때 유용하게 쓰일 수 있음 

 변수의 범위를 제한해두는 것도 좋은 프로그래밍 방법 

변수의 범위를 제한해두는 것도 좋은 프로그래밍 방법 

객체지향 프로그래밍 

개념 

우리 주위의 많은 문제들이 객체를 중심으로한 구조를 가지고 있으며, 객체들 사이의 관계 및 계층 구조로 이루어져 있음 

객체지향 언어는 이러한 관점을 나타내는 추상화 과정인 객체지향 분석과 객체지향 설계의 과정을 거쳐 나타난 결과를 작동하는 시스템의 모습으로 보여주는 도구라고 할 수 있음 

결국 객체지향 언어를 잘 사용하기 위해서는 개념적인 측면에서부터 실제 동작 과정에 이르기까지 다양한 부분을 이해하지 않으면 안됨 

객체지향 언어에서 제공하는 의미와 동작 원리를 정확히 이해하여야만 객체지향 언어로 구현하였을 때 시스템이 원하는 대로 동작할 뿐만 아니라 객체지향 시스템에서 얻을 수 있는 많은 이점 

예 – 재 사용성, 확장성, 유지보수성 등 

예를 들어 객체지향 언어인 C++ 언어를 단순히 C 언어의 확장이라고 해석할 것이 아니라 객체지향에서 요구되는 근본적인 개념을 이해하고 객체지향적으로 문제를 보는 눈이 있을 때 원하는 객체지향 시스템이 만들어짐 

객체지향 언어는 객체지향에서 나타나는 개념들인 객체, 클래스, 캡슐화, 상속, 다형성 등을 지원 

객체지향 언어로는 Smalltalk, C 언어를 확장한 C++, Eiffel, Flavors, Object Pascal 등이 있음 

프로그래밍 스타일 

스타일 

어떤 작업이나 선택에서 일관된 유형 

- 예 : 패션 스타일 

프로그래밍 스타일 

간결하고 읽기 쉬운 코드 

문형 구조, 원시 코드의 편집 상태 등에 따라 가독성이 달라짐 

설계에 의하여 좌우됨 

모듈화 - 높은 응집력, 낮은 결합도 

명명 원칙 

의미 있게 작성 

--잘못된 예시----------------------------------------------------

if (a < 65) { // What property does 'a' describe?  

     y = 65 - a; // What is being calculated here?  

  }  

  else {  

     y = 0;  

  }  

--바른 예시----------------------------------------------------

if (age < RETIREMENT_AGE) {  

   yearToRetirement = RETIREMENT_AGE - age;  

}  

else {  

   yearToRetirement = 0;  

}  

이름만 보아도 무엇인지(클래스, 멤버함수, 상수 등) 알 수 있게 작성 

이름 만들기 

원칙

단어 붙이기  1  

예 - cylinderLength 

클래스 이름은 대문자로 시작  2 

변수 이름은 소문자로 시작  3 

상수 이름은 모두 대문자로  4 

예 - MAX_NAME_LENGTH 

Static Final을 사용     5 

예 - static final String  XML_DOCUMENT = ‘text/XML”; 

데이터의 이름은 Underline  6 

예 - _timeOfDay 

타입 이름 

클래스와 인터페이스 이름의 첫 글자는 대문자 

public class PrintStream 

      extends FilterOutputStream { 

      … 

   } 

   public interface ActionListener 

      extends EventListener { 

      … 

 } 

메소드 이름 

첫 단어는 소문자, 연속되는 단어의 첫 글자는 대문자 

class MyImage extends Image { 

      public MyImage() { 

         … 

      } 

      public void flush() {  

         … 

      } 

      public Image getScaledInstance() { 

         … 

      } 

} 

메뉴 방식

특징 

가장 널리 사용 

초보자나 중급 사용자에게 적합한 방식 

선택방법 

 선택사양의 이름 

 키보드 입력 

 마우스나 아이콘 사용 

 터치스크린 사용 등의 다양한 방법 

단일화면 메뉴 방식 

하나의 작업을 수행함에 있어 그 기능의 모든 경우가 하나의 화면상에 보이며, 선택이 끝나면 그 선택된 메뉴를 실행하고 

메뉴가 없어지거나 입력된 내용이 소거하는 방식 

다중화면 메뉴 방식 

 선택 가능한 화면을 여러 화면에 걸쳐서 보여주고, 선택하면 메뉴가 없어지거나 다음 화면으로 넘어가는 방식 

 유사한 내용별로 분류하여 계층형 구조로 설계 

풀다운(Pull-down) 메뉴 또는 팝업(Pop-up) 메뉴 

화면의 상단에 메뉴의 제목을 보여주고, 커서나 마우스를 이동시켜서 원하는 기능의 항목을 선택 

장단점 

장점 

 각 명령어를 알 필요가 없음 

 오타 가능성의 최소화 

 소프트웨어 오류 발생 가능성 없음 

 메뉴 자체가 도움말 기능 제공 

 초보자나 중급자에게 적합한 방식 

단점 

 논리적 표현의 어려움 

 숙달된 사용자에게는 비효율

 복잡한 구조의 명령 체계 표현의 어려움 

 일정 속도 이상의 빠른 처리 불가능 

 대량의 자료 입력 곤란 

메뉴 화면 설계 시 일반적인 지침 

작업의 의미를 효과적으로 표현하는 메뉴 구조를 사용  1 

구조의 깊이보다는 폭을 중시  2 

도형, 숫자, 제목 등을 보여줌  3 

논리적인 분류  4 

일관성 있는 메뉴 항목 순서  5 

관련 있는 것, 자주 사용하는 것 

의미 있는 이름을 사용  6 

간략한 키워드로 시작하는 항목을 형성  7 

문법, 배열, 용어 사용 등의 일관성을 유지  8 

분기(Skip)나 지름길을 허용  9 

이전 메뉴나 초기 메뉴로 복귀를 허용  10 

온라인 도움말, 반응시간, 출력속도, 화면크기 등을 고려  11 

양식 채움 방식 

특징 

자료의 입력이 많은 경우 필요한 인터페이스 방식 

화면에 미리 입력해야 할 자료 항목의 이름, 위치 및 길이를 표시 

사용자는 커서를 움직여 원하는 자료를 양식에 입력 

설계 시 고려사항 

입력 영역의 길이를 밑줄이나 역상으로 표시  1 

고정된 형식의 자료 입력을 위해서 형식을 미리 보임  2 

숫자의 입력 시 나타나는 위치를 조정  3 

정확한 입력을 요하는 항목은 주의 표시  4 

예 - 실명확인 

커서가 위치한 항목에 관한 도움말을 보여주면 오류를 줄일 수 있음  5 

커서의 이동을 쉽게 함  6 

오류 정정의 기능이 항목 단위나 레코드 단위로 이루어져야 함  7 

입력 시 오류가 발생되면, 메시지를 항목마다 표시  8 

오류 입력 시 경고음이나 깜박임 기능을 사용  9 

실행 전에 입력된 자료를 확인하고 수정할 수 있게 함  10 

장단점 

장점 

 사용자에게 친숙함을 줌 

 중급자에게 적합한 방식 

 한 번에 모든 일을 처리할 수 있음 

단점 

 항목의 형식, 키보드 사용법, 항목의 내용 및 의미를 습득해야 함 

 화면을 많이 차지 

 함축된 항목이름을 이해해야 함 

명령어 방식 

특징 

명령어 방식은 프로그래밍 언어와 같이 정형적 언어(Formal Language)로서 사용자가 키보드를 통하여 문자나 부호로 

구성된 명령어를 입력하여 수행하는 방식 

MS-DOS에서 사용하는 각종 명령어나 UNIX 시스템의 vi 편집 등 

장단점 

장점 

 키보드만으로도 처리가 가능 

 명령어 처리의 구현 방식이 쉬움 

 조합하면 복잡한 명령의 처리 가능 

 사용자 정의 매크로의 사용이 용이 

 유연성이 있음 

단점 

 명령어 사용을 위한 교육이 필요 

 마우스 사용이 불가능 

 오류가 발생할 가능성이 높음 

 오류의 수정이 어려움 

 도움말 기능, 오류 메시지 제공이 어려움 

 초보자가 사용하기 어려움 

설계 시 주의사항 

명령어의 수를 가능한 작게 구성  1 

유사한 기능에 대하여 다른 명령어를 가진 것은 없는가? 

명령어는 의미가 있고 구별되는 의미를 가져야 함  2 

약자가 사용되더라도 일관성 유지  3 

명령어나 약자 사용이 동일한 기능을 가져야 함  4 

명령어 문법 구조에 일관성 유지  5 

초보자를 위해서 문법규칙을 프롬프트로 안내  6 

직접 조작 방식 

특징 

 사용자에게 아이콘과 같이 간략화된 작업 환경을 보여 주고, 사용자가 객체를 직접 조작함으로써 원하는 작업을 

수행하는 방법 

 화면과 선택 기구로 구성 

- 화면에 아이콘을 사용하여 작업 환경을 보여주고, 선택 기구로 명령 

장단점 

장점 

 초보자도 배우기 쉽고 사용이 용이 

 화면 단위로 대화가 가능 

 정보 출력의 그래픽화가 용이 

 오류 수정이 용이 

 주관적인 만족도가 높음 

단점 

 아이콘의 설계가 어려움 

 설계가 잘못된 경우 사용에 혼란이 발생 

 표준화된 방법이 없음 

설계 시 주의사항 

아이콘의 이해가 쉬워야 함  1 

잘못된 유추가 발생하지 않도록 주의   2 

사용자층의 관습에 따름    3 

아이콘은 알맞은 목적에 사용   4 

아이콘에 의한 상호작용은 신중하게 설계  5 

입출력 설계 

개요 

입출력 양식은 입력의 효율성과 유용성에 큰 영향 

GIGO(Garbage-In-Garbage-Out) 

입력 양식이 잘못 설계되면 입력 오류를 범하기 쉽고 그 결과 쓰레기를 낳게 됨 

특징 

소프트웨어가 자료를 받아들이는 기본수단 

인간공학적이어야 하고 입력상의 오류는 사전에 방지할 수 있는 장치를 제공 

원칙 

입력의 자동화 

자료의 원천문서와 입력양식과의 관계 

입력오류의 검증 

입력 정보의 설계 순서 

입력 정보의 목적을 정의  1 

입력 정보의 수집 방법을 정의  2 

입력 정보의 매체화 방식을 선택  3 

입력 정보의 투입에 관한 사항을 정의  4 

입력 정보의 내용을 설계  5 

입력 양식 설계용 도구

구체적인 지침 

 의미 있는 단어를 사용 

- 컴퓨터 전문용어는 가능한 피함 

 입력 방법 및 내용을 잘 전달  

 논리적 분류와 순서를 잘 구성  

 보기 좋은 형태로 꾸밈 

 잘 알려진 필드 이름을 설정 

 일관성 있는 용어를 사용   

 편리한 커서 이동 

 필드 자료의 입력상 오류를 찾아줌 

 잘못된 입력은 에러 메시지로 도와줌 

 선택 필드는 선택되었음을 확실히 나타날 수 있게 함 

 도움말 기능을 충분히 제공 

출력 설계 

특징 

소프트웨어의 수행 목적은 사용자가 원하는 출력물을 얻고자 함 

판독의 용이성을 위해 다음과 같은 사항을 고려 

 출력매체의 종류 

 논리적 연결성 

 위치 및 배열의 중요성 

 여백의 중요성 

 즉각 반응 

출력 정보의 설계 순서 

출력 정보의 목적을 정의  1 

출력 정보 분배에 관한 설계  2 

출력 정보 매체화에 관한 설계  3 

출력 정보 내용에 관한 설계  4 

UI  

범위 

사용자 인터페이스 

User Friendliness  

다양한 출력장치 

입출력양식  

UI와 대화형 설계 

사용자 인터페이스가 시스템의 질에 미치는 영향 

효율성의 증가  

만약 시스템이 좋은 인간 공학 설계를 가지고 있고,  

사용자가 수행하는 방법이 시스템의 인터페이스와 

일치한다면, 사용자는 작업을 효율적으로 수행 

생산력의 개선  

좋은 인터페이스는 사용자를 혼란 시키지 않고,  

그가 수행하는 작업에 집중 

에러의 감소  

“사람 에러”라 불리는 대부분의 에러는 잘못된 사용자 인터페이스가 원인 

– 사용자 에러를 줄일 수 있는 것처럼 모순, 애매함 등도 피할 수 있음 

훈련의 감소  

 잘못된 사용자 인터페이스는 배우기가 쉽지 않음 

 잘 설계된 사용자 인터페이스는 사용자를 격려하고 적당한 모델을 생성 

사용자 수용의 증가 

사용자는 인터페이스가 잘 설계된 시스템을 선호 

– 그런 시스템은 정보를 찾기 쉽고, 사용하기 편한 형태로 정보를 제공 

사용자 인터페이스(User Interface) 

스크린의 계층, 윈도우즈, 또는 시스템의 구조 또는 응용에서 계층이나 쉘을 의미 

사용자와 시스템 사이의 의사소통을 중계하는 입출력 장치와 대화형 언어체계 

미국무성의 인간 공학(Human Engineering) 설계 목표 

 사용자의 직무 수행 요건의 충족 

 사용 기술, 인력, 교육 기간의 최소화 

 사용자와 기계가 어우러지는 시스템의 신뢰성 충족 

 시스템 내부, 그리고 시스템 간의 설계 표준 준수 

사용자 분석의 필요성 

사용자 인터페이스를 설계할 때, 중요하고도 어려운 문제는 사용자의 다양성 

나이, 성별, 신체조건, 교육 정도, 문화 및 기술적 배경, 동기, 목적, 개인성 등을 이해 

사용자 유형 

초보자(Novice User) 

 시스템의 문법지식(Syntax Knowledge)이 없고, 응용 소프트웨어의 의미지식(Semantic Knowledge)도 없는 사용자 

 이런 사용자를 위한 시스템은 기능을 실행시키기 위한 명령어나 행동을 최소화 

 사용 중간에 사용자에게 시스템의 상태를 알려주고 되묻는 과정이 필요 

 오류 메시지를 자세하고 친절하게 제공함으로써 초보자의 사용 오류 발생을 최소화 

능숙하지 못한 사용자(Knowledgeable, Intermittent user) 

 응용 소프트웨어에 대한 상당한 의미지식(Semantic Knowledge)이 있으나, 인터페이스 사용에 필요한 

문법정보를 상대적으로 적게 기억하고 있는 사용자 

 여러 종류의 시스템을 조금씩 사용한 경험이 있는 사용자 

 명령어, 메뉴 및 용어를 쉽고 일관성 있게 제공 

 약간의 지식으로 자신도 모르게 시스템에 손상을 줄 수도 있으므로, 시스템의 중요한 기능에 대해서는 접근이나 사용을 제한 

 도움말 기능은 이들에게 매우 유용한 역할 

전문가(Knowledgeable, Frequent User) 

 의미지식(Semantic Knowledge)과 문법지식(Syntax Knowledge)이 상당하여 상호작용 방식에 단축키나 

줄임법을 추구하는 사용자 

 종류의 시스템을 많이 사용한 경험이 있어서, 기능과 명령어를 잘 알고 있는 사용자 

 시스템이 제공하는 구차한 메시지 설명이나 진입단계가 많은 것을 싫어하고, 신속한 처리 속도와 메뉴의 

지름길을 원함 

 컴퓨터 시스템을 자주 사용하기 때문에 기억하기 좋고 약어가 가능한 명령이나 기능키 등을 사용 

세 가지 연관된 원칙이 존재 

인간 속성 

 사람이 어떻게 감지하고, 배우고, 기억하고, 생각하고, 느끼는지에 대한 심리학적 접근으로 인간을 관찰 

 사람이 어떻게 함께 작업하고, 작업환경이 사람의 작업에 어떤 영향을 끼치는지에 대한 조직과 문화에 관심 

 관련된 분야는 심리학, 인류학, 그리고 민족지학 등 

예술적인 설계 

 인터페이스의 중요한 요소를 사용자에게 어떻게 부각시킬지에 초점 

 한 사건의 즉각적인 감지뿐 아니라 복잡한 전체 상태와 과정의 즉각적인 이해 

인간 공학 

 인간특성과 가공물 사이의 관계 

 물리적 툴이나 복합 시스템, 조직 그리고 절차와 같은 인공물과 인간 사이의 적응을 허용하는 방법과 기술을 발전 

 정보 시스템과 상호 작용하는 인간 정보 처리의 특징에 주로 초점을 맞추는 한 분야로 발전 

상호 작용에 대한 설계지침 

사용자의 경험이나 형태에 관계없이 사용자와 시스템 사이의 

상호작용에 대한 설계지침 

일관성을 유지  1 

사용자 인터페이스에서 사용하는 용어, 문법, 화면 설계 등은 통일 

의미 있는 피드백(Feedback)을 제공  2 

시스템이 작동되면 사용자는 시스템의 반응에 순응하나,  시스템에 잘못된 명령어를 보내면 시스템은 오류 반응을 보임 

삭제와 종료와 같이 중요한 활동을 처리하기 전에는 다시 한번 확인을 요청 3 

시스템에 지시한 것은 언제든지 바꾸기 쉬워야 함  4 

수행 중에 기억해야 하는 정보의 양을 가능하면 줄이는 것이 좋음 5 

키보드를 통한 입력과 마우스 움직임을 최소화하고 효율성을 높이는 것이 좋음 6 

실수에 관대할 것  7 

사용자가 잘못했을 때 그에 대처하는 인터페이스 기능을 추가하여 사용자가 올바르게 시스템과 대화할 수 있도록 하는 것이 좋음 

기능에 따라 메뉴들을 분류하고, 화면의 내용을 단순하게 설계  8 

한 화면에 포함하는 내용이 너무 많지 않게 하는 것이 좋음 

도움말 기능을 제공  9 

간단한 동사구를 사용하는 명령어를 사용  10 

출력의 원칙  

S. Smith와 J. Smith[SM86]가 제시 

자료 출력의 일관성(Consistency of Data Display)   1 

사용자 정보 이해의 효율성(Efficient Information Assimilation)   2 

암기력의 최소화(Minimal Memory Load)   3 

입력과의 호환성(Compatibility with Data Entry)   4 

출력조작의 편의성(Flexibility for User Control)  5 

자료 입력을 위한 대표적인 설계지침 

입력 작업의 일관성(Consistency of Data Input)   1 

최소의 입력 작업 노력(Minimal Effort for Input)   2 

입력을 위한 암기의 최소화(Minimal Memory Load)   3 

출력과의 호환성(Compatibility with Data Display)   4 

입력의 편의성(Flexibility for User Input)  5 

화면설계

특징 

개발자는 사용자의 입장에서 사용자 편의를 고려하여 설계 

대부분의 화면 설계는 그래픽 사용자 인터페이스(Graphic User Interface : GUI) 방법을 사용 

주의사항 

 사용자의 특성을 기억하고 있어야 함  

 한 화면에 너무 많은 항목이 표시되어 복잡해지지 않도록 함  

 논리적으로 관련된 항목들의 구별이 용이해야 함 

 너무 많은 글꼴이나 색상 등은 피하는 것이 좋음 

 중요한 항목의 배치에 유의 

 다양한 정렬 방법을 사용하여 정보를 조직적으로 표현 

 다중 화면의 경우, 화면 사이의 일관성을 유지  

 이해하기 쉽고 사용자가 일상에서 사용하는 용어를 주로 사용 

 다양한 실험을 통해 최선의 화면을 설계  

인터페이스 개발과정 

요구사항 분석 

 사용자 인터페이스와 사용자의 요구사항은 매우 밀접한 관계 

 사용자가 보아야 할 데이터, 상태의 변화, 기능 수행 등을 포함하는 사용자의 요구사항이 사용자 인터페이스에 모두 

반영되어야 함 

따라서 사용자 인터페이스에 대한 논의는 분석 단계에서부터 이루어지는 것이 일반적 

요구사항 명세서 

요구사항 명세서에 기본 사용자 매뉴얼(Preliminary User Manual)을 포함시킬 수 있음 

–이때 매뉴얼의 사용자가 누구인가 규명하고, 사람과 시스템 사이의 인터페이스에 대한 정보를 기술 

–메뉴 구조, 스크린, 보고서 형식 등 

인적요소 

사용자에 대한 분석 

사용자 인터페이스를 잘 설계하려면 사용자(인간) 분석이 필요 

좋은 시스템의 사용자 인터페이스 설계 

 인적요소(Human Factor) 

 인간의 사물에 대한 인식 방법 

 시각적인 지각 능력 

 연역 또는 귀납적인 추론 능력 

 인간 사회와 조직 등을 연구해야 함 

나이, 성, 직업, 교육, 문화, 피부 색깔 등에 따라 전형적인 특성이 있을 수 있음  

인식모델 

인식(Cognition) 

사물을 이해하고 지식을 얻는 과정 

이해, 기억, 추리, 기능의 파악, 새로운 아이디어의 창출 등 

HCI(Human Computer Interface)의 주요한 목적 

인간과 컴퓨터 간의 지식 교환 방법을 제시하여,  

인간이 컴퓨터와 대화하는 모습을 밝혀내고 개선 방법을 제시하는 것 

사람이 정보를 처리하는 단계 

확장모델 

사회적 및 조직적인 요소 

인간의 정보에 대한 이해 

사회적 환경을 바탕으로 함 

사회 환경에서 배우고, 듣고, 본 모든 정보를 두뇌에 저장한 후 이를 바탕으로 인식을 수행 

문화의 차이 

사회적 환경 및 습관에 대한 요소를 최대한 활용해야 함 

예 - 붉은 색깔에 대한 이해와 반응은 서로 다름 

사용자 인터페이스의 조직적 요소 

컴퓨터 시스템은 인간을 위한 것 

조직이 업무를 능률적으로 수행하도록 지원 

사용자가 조직에서 수행하는 역할은 다양 

역할을 고려하여 사용자 인터페이스를 설계 

사용자의 기술 수준 

수준 높은 기술자 vs 초보자 

컴퓨터 전공인 사용자 vs 일반 사용자 

1. 객체지향 모델링 

객체지향 모델링의 시작 

실세계를 객체지향으로 모델링 

 실세계의 개념구조를 그대로 소프트웨어 구조로 바꾸고 싶다는 요구에 부응 

 객체지향 모델링 다이어그램은 실세계를 모델링할 수 있도록 개발되었음 

객체와 클래스, 정적 구조도 

객체지향의 기초개념 

객체와 클래스 

 책 

- 소프트웨어 공학 

 각 개념은 우리가 속한 세상에 대한 이해 혹은 중요한 사상 

 개념이 적용된 사물을 객체라 함 

 객체는 실체일 수도 있고, 추상적인 것일 수도 있음 

객체는 클래스를 구체화한 것 -> Instantiation (인스턴스 생성) 

클래스 

정의 

개념을 분해하여 정리해놓은 것 

클래스의 속성

 그 클래스의 객체가 가지는 성질 

 클래스의 조작(연산), 그 객체의 행동(Behavior) 및 다른 객체에 대하여 제공하는 서비스 

객체 

객체의 특성 

그 클래스에 정의된 속성(Attribute)과 조작(Operation)을 가짐 

상태(State)와 생명주기(Life-cycle)을 가짐 

UML에서는 상태도를 사용하여 객체의 상태와 생명주기를 표현 

연관 클래스 

필요성 

객체는 상태를 가지게 되는데, 보통의 링크는 상태를 가지지 않음 

연관을 클래스로서 정의할 필요가 있는 것은 그 연관의 링크 상태를 갖는 경우 

두 가지 클래스의 연관이 상태를 표시하는 동사로 표시되는 경우에 사용 

UML(Unified Modeling Language) 

모델링 과정과 모델링 언어 제안 

모델링 과정(Modeling Process) - 객체지향으로 분석하고 설계하는 프로세스 

모델링 언어(Modeling Language) - 설계를 표현할 때 사용하는 그래픽 심볼 

UML 탄생 

1997년 OMG 

OMG(http://www.omg.org)에서 UML 발표 

광범위 응용 분야에서 사용 

데이터베이스 설계 표현 

실시간 시스템 등 

시스템 개발 모형 

기능적 모형(Functional Model)  

사용자 측면에서 본 시스템 기능을 나타내며 UML에서는 사용사례 다이어그램으로 표현 

객체 모형(Object Model) 

객체, 속성, 연관 관계, 오퍼레이션에 의하여 시스템의 구조를 나타내며 UML에서는 클래스 다이어그램으로 표현 

동적 모형(Dynamic Model) 

 시스템의 내부 동작을 나타냄 

 UML에서는 순서 다이어그램, 상태 다이어그램, 액티비티 다이어그램으로 표현 

 순서 다이어그램은 객체들 사이의 메시지 교환을 나타내는 반면, 상태 다이어그램은 하나의 객체가 가질 

수 있는 상태와 상태의 변화에 의하여 동작을 나타냄  

UML의 다이어그램 

사용사례 

클래스 

순서 

상태 

액티비티 다이어그램 

클래스, 속성, 오퍼레이션 

표현 

클래스 심볼 

세 부분의 박스 형태 

객체 

객체는 클래스와 같은 형태로 나타내며 객체의 이름을 먼저 쓰고 어떤 타입의 클래스에 속하는지 표시 

외부 투명성(Visibility)을 위한 심볼 

+ 

 public으로 선언 

 외부 접근 가능 

- 

 private으로 선언 

 외부 사용 불가능 

#  

 상속된 클래스에서만 제한적으로 사용 가능 

인스턴스가 없는 추상 클래스나 구현이 없는 오퍼레이션 

이름과 함께 {abstract} 표시 

사용사례 다이어그램 

정의 

“순서 있는 액션의 집합을 기술한 것으로 액터에게 혜택이 있는 결과를 제공하여야 함” (UML User Guide) 

목적 

시스템의 외부 기능을 나타냄 

사용자의 요구를 추출하고 분석 

구성요소 

사용사례(Use Case) 

액터에게 보이는 시스템의 기능, 외부동작 

액터(Actor) 

시스템과 상호작용하는 외부 엔티티(사람이나 다른 시스템, 하드웨어)로서 이름과 설명 필요 

통신 

액터와 사용사례가 정보를 교환 

의미 

시스템의 범위를 정함 

사용사례 기술 

스크립트 형태, 자연어 사용 

클래스 다이어그램 

정의 

 시스템을 구성하는 클래스의 구조를 나타냄 

 객체들의 공통 구조와 동작들을 추상화한 것  

목적 

시스템을 구현할 때 어떤 클래스가 필요한지 클래스 사이의 관계를 나타냄 

구성요소 

객체 

클래스 

속성 

오퍼레이션 

연관관계  

의미 

클래스 다이어그램은 객체지향 프로그램의 골격(클래스 정의)을 나타냄 

클래스 다이어그램의 표현 

연관관계(Association) 

 클래스 사이의 관계 

 링크로 나타냄 

- 선으로 표현 

역할(Role) 

연관관계 표시 선분 끝에 역할을 표시 

- has, exist, rent 

다중도(Multiplicity) 

 숫자로 표현 

 연관된 링크의 개수 

 * 는 다수(Many)를 의미 

전체부분 관계(Aggregation) 

 전체 개념의 클래스 

- Directory 

 부분 개념의 클래스 

- File 

 일대 다인 경우가 많음, 다이아몬드로 표시 

일반화 

 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의 관계 

 공통속성과 오퍼레이션을 사용하기 위하여 상속 개념으로 클래스를 구성하는 것 

정의 

시스템 동작을 정형화하고 객체들의 메시지 교환을 시각화  

목적 

참여객체(Participating Object)를 추가로 찾아내기 위하여 객체 사이에 일어나는 상호작용을 파악 

구성요소 

액터 

왼쪽 

객체 

메시지 

이름있는 화살표 

수직선 

시간의 흐름 

의미 

클래스가 가져야 할 오퍼레이션을 파악하는 데 사용됨 

객체들 사이의 통신 패턴 

사용사례의 이벤트 흐름을 나타냄 

상태 다이어그램 

정의 

 객체가 갖는 여러 상태와 상태 사이의 전환을 표현 

 상태란 객체가 만족하는 조건  

목적 

단일 객체의 동작을 나타냄 

객체의 상태 변화를 점검하며 빠진 오퍼레이션 점검 

솔루션 도메인 객체를 표현 

구성요소 

원 

객체의 상태 

화살표 

전환(Transition) 

의미 

외부사건의 결과로 일어나는 단일 객체의 상태 변화에 초점 

객체의 동작을 구체화 

액티비티 다이어그램 

액티비티 

 시스템에서 수행되는 작업 

- 오퍼레이션의 집합 

 클래스의 메소드 

액티비티 다이어그램 

시스템을 액티비티로 표현한 것 

액션 상태인 상태 다이어그램 

액티비티와 천이 사이의 제어흐름 

구성요소 

원 

액티비티 

화살표 

트랜지션 

- 다른 액티비티로 전환 

동기 막대 

제어흐름 동기화 

 다이아몬드 

선택분기 

시작, 종료

외향천이 

액션상태 

액션상태의 이름은 동작이 일어남을 의미 

1. 객체지향의 개념 

재래식 방법과 비교 

재래식 방법 

 기능중심 

 변경의 파급효과 큼 

객체지향 방법 

자료와 관련 함수의 결합 

객체 

정의 

소프트웨어 모듈(객체) = 자료구조 + 함수  

속성 

상태  

능력  

연산(Operation)을  수행할 수 있는 능력 

정체성 

구별 가능성 

객체 인스턴스 

객체 인스턴스(Instance) = 객체  

특징 

비슷한 객체의 구조와 행동은 공통 클래스로 선언 

클래스(Class) vs 인스턴스 (Instance) 

개념 비교 

객체의 타입(Object Type) : 클래스 

클래스에 속하는 개개의 객체 : 인스턴스 

클래스의 속성(Attribute) 

예 - 직원 클래스 

클래스의 의의 

클래스는 객체들이 갖는 속성과 적용 연산을 정의하고 있는 틀(Templet) 

Employee         Hong_kildong(); 

Employee*       Hone_kildong = new Emplyoee(); 

캡슐화(Encapsulation) 

캡슐화의 정의 

관련된 항목을 모아서 캡슐을 씌움 

추상화의 수단 

세부사항은 차후에 생각 

정보은닉(Information Hiding) 

외부의 직접적 접근 불가, 일종의 블랙박스 

구현에 따라 선택 가능 

문법 

 Public 

 Private 

 Protected 

객체 사이의 관계 

객체는 일반적으로 상호작용하여 동작 

객체에 있는 서비스를 호출하면 두 객체는 관계가 맺어져야 함 

상호작용할 필요가 있는지 찾아내는 작업이 필요 

연관 

서로 상대의 존재를 알 수 있도록 관련이 맺어진 것 

서로 알고 접근 가능하게 하는 방법은 여러 가지가 있음 

집합 관계 

전체 개념과 부분 개념 사이의 관계 

격납의 의미 

예 - 디스크 □ 트랙 □ 섹터 

상속(Inheritance) 

의미 

상위 클래스의 속성과 연산을 물려 받음 

슈퍼클래스(Superclass), 서브클래스(Subclass) 

예 - 직원 → 슈퍼클래스 

관리자 → 서브클래스 

복수상속 (Multiple Inheritance) 

두 개 이상의 슈퍼클래스에서 상속 받음 

다형성(Polymorphism) 

정의 

여러 형태를 가지고 있음 = 여러 형태를 받아들일 수 있음 

특징 

같은 이름의 메시지를 다른 객체나 서브클래스에서 호출 

예 - getarea() 를 도형의 모양이 달라도 호출 

메소드 

특정한 클래스를 위하여 오퍼레이션을 구현 

하나 이상의 메소드를 가진 오퍼레이션  

매개변수나 객체가 속한 클래스의 이름으로 구분 

왜 객체지향 방법인가? 

객체지향의 장점 

소프트웨어 위기   1 

시스템을 쉽게 구축할 수 있는 방법  2 

– 문제를 정확히 해결 

– 적절한 작업 

– 유지보수 가능 

– 확장 가능 

– 재사용 가능 

응용문제를 더 쉽게 인식  3 

구현이 덜 복잡해짐  4 

분석과 구현 사이의 차이가 적음  6 

자료구조와 함수의 결합이 자연스러움  5 

의사교환이 효과적인 비주얼 모델링  7 

모델링 과정에 사용자와 개발자 사이에 공통으로 이해할 수 있는 용어와 개념 8 

객체모델을 이해하기 위하여 꼭 프로그래머일 필요 없음  9 

비용의 절감  10 

객체는 이런 장점이 있지만 모든 것을 자동으로 제공하지는 않음

객체지향의 특징 

모형의 적합성 

 객체중심 모형은 우리의 사고 방식과 유사 

 뚜렷하게 구별되는 객체로 나누고 객체들의 메시지 패싱이모여 프로그램이 됨 

재사용 용이 

 Openness, Closeness를 다 갖춘 재사용 단위 

 상속(Inheritance), 다형성(Polymorphism) 

Time – to – Market 

 종래의 폭포수모형은 단계가 길고 문서 작업이 많음 

 클래스의 재사용과 확장에 의한 빠른 개발이 가능 

설계와 프로그램의 매핑 

개발 각 단계의 전환이 자연스럽고 신속 

객체지향 분석과 설계 과정 

분석과 설계 

 요구를 사용 사례로 정리하고 사용 사례 다이어그램을 작성 

 클래스 후보를 찾아내고 개념적인 객체 모형 작성 

 사용 사례를 기초하여 순서 다이어그램을 작성 

 클래스의 속성, 오퍼레이션 및 클래스 사이의 관계를 찾아 객체모형을 완성 

 상태 다이어그램이나 액티비티 다이어그램 등 다른 다이어그램을 추가하여 UML 모형을 완성 

 서브 시스템을 파악하고 전체 시스템 구조를 설계 

 적당한 객체를 찾아내거나 커스텀화 또는 객체를 새로 설계 

객체지향 개발 

특징 

반복 및 점증적 개발 프로세스를 사용 

설계와 구현 작업 사이에 공통의 개념들을 사용하기 때문에 전환이 용이 

Coad / Yourdon법 

사고법, 표기방법이 가장 간결 

초보자 지향형 

Booch법 

도큐먼트 작성에 있어서 관점을 자세하게 규정 

객체지향의 특징을 설계공정에 최대한 반영 

초보자 부적합 

OMT(Object-Modeling Technique)법 

가장 형평성이 우수 

초보자부터 베테랑까지 이용가능, CASE와 연동도 충실 

1. 복잡도 

개요 

복잡도 

 문제를 푸는 데 걸리는 시간을 언급할 때 복잡도를 사용 

 복잡도 측정 시 길이, if문의 수, 모듈 사이의 정보의 흐름 등과 같은 시스템의 속성으로 측정 

 소프트웨어 시스템의 속성들의 유형 

- Intra-Modular Attribute 

  → 개별적인 모듈의 속성들 

- Inter-Modular Attribute 

  → 의존성을 가지는 모듈의 집합으로써 보여지는 시스템의 속성들 

복잡도 측정 

Halstead’s 방법(Software Science) 

 코드의 라인 수(LOC)를 세는 것 

 소프트웨어의 연산자(Operators)와 오퍼랜드(Operands)의 수를 사용 

 기본 4개의 엔터티 정의 

McCabe’s 순환복잡도(Cyclomatic Complexity) 

 프로그램의 제어의 흐름을 그래픽으로 표시 기반 

 하나의 절차 그래프 또는 하나의 메인 프로그램은 오직 하나의 출발점과 끝점을 가지고 있다고 가정 

 각 노드는 출발 노드로부터 도달될 수 있고, 끝 노드도 각 노드에서 도달될 수 있음 

- 이 경우, 그래프는 연결되어 있음 

 만약 프로그램이 메인 프로그램과 하나 또는 그 이상의 프로시저로 구성되었다면 

- 그때 제어 그래프는 각 프로시저와 메인 프로그램과 함께 여러 개의 연결 요소를 가지고 있음 

McCabe’s 순환복잡도(Cyclomatic Complexity) 

 프로그램의 구성요소의 순환복잡도에 대해 최대 10까지 제한 

 복잡도 측정 규준은 테스팅할 때 적용 

그 이외의 복잡도 측정 규준(Suffer)의 공통점 

 The Time in Man-month, 코드의 라인 수, Task의 크기에 달려있음 

 이런 것들은 모듈의 최적화된 코드를 결정 

 모듈 속에 있을 수 있는 에러를 추정 

 소프트웨어의 비용 산출 시 사용 

설계 평가 기준 

모듈의 크기 

소규모 시스템 

함수, 서브루틴 

대규모 시스템 

독립 프로그램 

- 하나의 수행 파일 

모듈 응집력(Module Cohesion) 

모듈 안의 요소들이 강한 응집력을 갖도록 설계 

모듈 결합도(Module Coupling) 

다른 모듈과의 결합도가 약한 모듈이 되도록 설계 

설계 요령(Design Heuristics) 

구조적 설계(Structured Design) 

개념 

시스템을 이루는 모듈의 구조를 파악하는 방법 

모듈 분해의 계층적, 인터페이스 지향적 접근 

시스템 구조도(Structure Chart) 

시스템 구조도의 도출 

시스템을 모듈 단위로 분할 

모듈의 계층적 구성 

모듈 사이의 입출력 인터페이스 

모듈의 이름과 기능 

자료의 변환 흐름(Transformation Flow) 

변환 분석 

자료 흐름도를 입력 흐름, 변환센터, 출력 흐름으로 분할하는 과정 

변환 분석방법 

자료흐름도에서 입력 자료 흐름과 출력 자료 흐름을  파악   1 

중앙 변환 부분을 식별  2 

변환 중심부를 축으로 최상위 구조(First-cut) 작성  3 

각 모듈의 하위 구조도 같은 방법으로 분석  4 

설계 기준을 적용하여 수정, 최적화  5 

다섯 가지 구조 

저장소 구조(Repository Architecture) 

서브 시스템들이 단일 중앙 저장소의 자료를 접근하고 변경 

MVC(Model View Controller) 구조 

 모델, 뷰, 제어구조라는 세 가지 다른 서브 시스템으로 구성 

 모델 서브 시스템 

- 도메인의 지식을 저장, 보관 

 뷰 서브 시스템 

- 사용자에게 보여주는 시스템 

 제어 서브 시스템 

- 사용자와의 상호 작용 관리  

클라이언트 / 서버 구조 

 서버 

- 클라이언트라는 서브 시스템에게 서비스를 제공 

 클라이언트 

- 사용자와 대화 

계층 구조 

 시스템이 계층적으로 분할 

 각 서브 시스템이 하나의 계층이 되어 하위층이 제공하는 서비스를 상위층의 서브 시스템이 사용 

파이프 필터 구조 

 서브 시스템이 입력 데이터를 받아 처리하고,  결과를 다른 시스템에 보냄 

 서브 시스템을 필터라 하고, 서브 시스템 사이의 관계를 파이프라 함 

설계 문서화 

정의 

 시스템의 목표 및 주요 기능에 대한 서술 

 요구분석에 의한 시스템 구조의 명세 

– 자료구조(파일 또는 DB 구조) 

– 모듈 설계 

– 알고리즘 설계 

– 시스템 구조 등 

자료구조 설계 

정의 

사용되어지는 데이터(자료)에 대한 명세 

 명세내용 

파일이름 

자료를 보관할 파일(또는 DB)의 이름 

파일종류 

자료의 보관 형태 

자료이름 

자료형 

자릿수 등 

모듈 명세서 

개요 

 모듈의 세부처리 기능을 기술한 내역 

 시스템 구조도의 박스에 표현되지 않은 자세한 알고리즘을 기술 

 모듈의 내부 자료에 대한 설명을 포함 

 프로그램 구조도와 함께 시스템의 동작 상태를 예측할 수 있는 근거 제공 

알고리즘 설계 

상세설계의 표현 

설계의 표현과 코딩이 용이할 것 

수행이 가능할 것 

유지보수가 용이할 것 

모듈 명세화 기법 

흐름도(Flow Chart) 

N-S 도표(Nassi-Schneiderman Chart) 

의사 코드(Pseudo Code) 

의사 결정표(Decision Table) 

의사 결정도(Decision Diagram) 

PDL(Program Design Language) 

상태천이도(State Transition Diagram) 

행위도(Action Diagram) 

알고리즘 설계 

N-S 도표(Nassi-Schneiderman Chart) 

논리 기술의 기본 형태인 순차, 선택, 반복의 표현을 박스로 표현 

NS - 도표의 표현 규칙 

 도표는 항상 사각형 

 도표의 제어흐름은 위에서 아래로 

 수평으로 그어진 줄은 항상 평행 

 빈 박스 - Null Statement 

 모든 사각형은 다시 하나의 N - S도표 

장단점 

장점 

 구조적 프로그램 

 배우기 쉽고, 읽기 쉬우며 원시 코드로 전환이 쉬움 

 프로그램의 구조를 쉽게 파악할 수 있음 

 프로그램의 복잡도, 제어구조를 한눈에 볼 수 있음 

단점 

 도표를 그려야 하는 불편함 

 수정이 용이하지 않음 

의사코드(Pseudo Code) 

 모듈의 입출력 자료, 내부 자료, 수행 절차 등을 알고리즘의 형태로 기술 

 실제 프로그램과 유사하나 특정 프로그래밍 언어에 독립적 

 전문적 용어의 사용은 가능하지만 프로그래머의 고유한 스타일이나 특성이 무시될 수 있음 

 의사 코드를 쓰는 방식이 다를 수 있으므로 한 프로젝트 안에서 표준을 만들 필요가 있음 

ex)

Module 주급계산(고용자 레코드; 주급총액) 

   Assume  

  1<급여형태<3 

  0<주간 근무 시간<100 

   End Assume 

   Define 

  Rate: Real  /* 시간 당 급료 */ 

   Endefine 

   If (급여형태=1) Then  Rate=4.2 

   Elseif (급여 형태=2) Then Rate=6.0 

   Else  Rate=9.0 

   Endif 

   Select Using (주간근무시간) From 

  Case (1-40): 주급총액=주간근무시간*Rate 

  Case (41-50): 주급총액=(주간근무시간*Rate)*0.5 

  Case (51-99): 주급총액=(주간근무시간*Rate)*1.0 

   Endselect 

End Module   

사용자 인터페이스(User Interface) 

설계 

사용자 분석 

대화설계 원리 

메뉴 선택 

양식 채움(Form-Fill) 인터페이스 

명령어 방식 

직접 조작 

화면 설계 시 주의 사항 

중요성 

초기의 컴퓨터 -> 알고리즘이 중요 

     최근의 컴퓨터 -> 사용자의 입장이 중요  

평가 기준 

배우기 쉬움  

속도  

사용 중 오류의 빈도 

사용자의 만족  

사용법의 유지  

시스템의 최종 사용자에 대한 지식 

나이, 인원 

컴퓨터에 대한 기본 지식, 동기 

사용자의 부류 

다양한 사용자 부류 

 초보자 

 능숙하지 못한 사용자 

 전문가 

1. 일정 계획(Scheduling) 

일정 계획 

정의 

개발 프로세스를 이루는 소작업(Activity)을 파악하고 순서와 일정을 정하는 작업 

• 개발 모형 결정 

• 소작업, 산출물, 이정표 설정 

작업 순서 

다섯 가지 순서 

작업분해(Work Breakdown Structure)  1 

CPM 네트워크 작성  2 

최소 소요 기간을 구함  3 

소요 MM, 기간 산정하여 CPM 수정  4 

간트 차트로 그림  5 

작업 분해 

정의 

프로젝트 완성에 필요한 Activity를 찾아냄 

구조(Work Breakdown Structure) 

계층적 구조 

목표를 단계(Phases), 활동(Activities), 작업(Tasks) 등 계층적으로 분류 

WBS 

의미 

 순서적, 계층적으로도 표현 

 WBS는 간단한 전체적인 프로젝트의 윤곽을 보여주며 간트 차트에서 활동(Activity)이나 작업의 기준 

 WBS에서 프로젝트 관리자는 소단위 작업에 대한 작업 소요일을 측정  

 작업기간을 측정할 때 소비시간(Elapsed Time) 개념을 이해하는 것이 중요 

 소비 시간은 두 가지 중요한 인간적인 요소(People Factor)를 고려 

효율성(Efficiency)   평균 작업 생산성을 75%로 생각 

Interruptions  생각 못했던 요소를 10 ~  50%로 생각 

시간예측 

100% 효율성과 인터럽트가 없는 경우에 10시간으로 완성시킬 수 있는 작업이 있다고 가정하고, 또한 75% 

효율과 15% Interrupt가 있는 경우를 고려해보자.

실제 작업에 걸리는 시간을 측정하면 다음과 같이 15.7 시간이 필요함 

작업시간 측정하는 일반적인 방법 

측정 방법 종류 

OD, PD, ED를 측정하는 방법 

세 가지 방법 

Decomposition 

프로젝트를 가장 작은 소단위 작업으로 나누어서 과거의 경험을 바탕으로 측정하는 방법 

COCOMO 

하나의 모델을 기준으로 측정하는 것으로 이전의 프로젝트 기간을 중심으로 새로운 프로젝트의 기간을 

정하는 방법 

Function Point 

입력 수, 출력 수, 질의(Query) 수, 외부 인터페이스 수 등을 이용하여 FP(Function Point)를 계산하는 방법 

CP / M(Critical Path / Method) 

개념 

최소의 비용으로 최대의 효과를 위한 방법 

-시간과 비용을 고려해서 최적화하는 방법 

장점 

관리자의 일정 계획 수립에 도움 

프로젝트 안에 포함된 작업 사이의 관계 

병행 작업 계획 

일정 시뮬레이션 

일정 점검, 관리 

임계경로 분석 

프로젝트 8개의 작업으로 구성 

각각의 작업은 가장 최적의 기간이 설정 

프로젝트의 작업은 3가지 경로로 분류 가능

임계경로 분석 

C, F, G는 전체일정에 영향을 주지 않는 일정에서 조합 가능

PERT와 Gannt Chart 

정의와 특징 

PERT 차트 

• 프로젝트의 작업들과 작업들 사이의 관계를 그래프로 표현한 네트워크 모델 

• 작업들이 계획되기 전에 작업들 사이의 의존관계를 보여주기 위해 개발 

간트 차트 

• 작업의 병행 처리 과정을 인식시켜 주는 장점을 가지고 있음 

조직구성 

조직구성의 유형 

1. 프로젝트별 조직 (Project Format) 

2. 기능별 조직 (Function Format) 

3. 행렬식 조직 (Matrix Format) 

프로젝트별 조직(Project Format) 

특징 

 새 프로젝트가 발생하면 구성되는 조직 

 중소 규모의 프로젝트에 적합 

 프로젝트 관리자가 중심이 되어 강한 동료의식과 공동 책임감이 고취 

 조직상의 제도나 제약을 적게 받기 때문에 조직의 동기성 및 환경 적응성을 높일 수 있음

기능별 조직(Function Format) 

특징 

관리자가 소속된 요원들의 일을 전문화하고, 각 부분별 

관리자가 지휘 감독 

장단점 

장점 

 분석, 설계, 구현, 테스트, 유지보수 각 단계에 전문화가 필요 

 기능별 조직은 관리자가 소속된 요원들의 일을 전문화하고 부분별로 관리자가 개발자들을 지휘 감독 

 전문가들의 지식, 기술, 경험을 보다 효과적으로 활용 

 전문가들은 자신의 능력을 최대한 발휘할 수 있는 환경을 제공받음 

 대형 프로젝트에 적합 

단점 

 의사전달 방식에서 규정된 문서화방법을 사용 

 의견 불일치의 경우 많은 혼란을 가져올 수 있고, 서로의 의사에 대한 중재자가 필요 

행렬식 조직(Matrix Format) 

특징 

 프로젝트별 조직과 기능별 조직의 장점을 취하여 구성 

 각 개발자는 기능별 전문 분야 내에서만 활용하되, 프로젝트팀의 구성원으로서도 활용하는 절충식 구조 

 개발자는 기능 조직에 소속되어 일정기간 프로젝트 조직에 파견 나가는 형태 

장단점 

장점 

 협동적으로 노력하기 때문에 기능별로 전문가들의 시야를 넓혀주고 혁신을 촉진 

 시간, 비용, 인력 등의 프로젝트별 배정에 있어서 균형 유지 가능 

단점 

 관리 비용이 증가 

 조직 내의 긴장해소, 조직 간의 균형유지, 프로젝트 수행상의 시간과 비용의 균형을 유지하는 데 노력이 필요 

3. 개발비용 산정 

소프트웨어 개발 비용 예측 

예측 방법 

정확한 비용 예측은 매우 어려움 

 알려지지 않은 요소가 산재 

 원가의 계산이 어려움 

과거의 데이터가 필요 

단계적 비용 산정 방법도 사용 

예산 

예산 산정 방법 

인건비 

MM(인원 / 월)을 기초 

경비 

여비, 인쇄비, 재료비, 회의비, 공공요금 

간접 경비 

Overhead  

비용 

비용에 영향을 주는 요소 

제품의 크기 

제품의 크기가 커짐에 따라 기하급수로 늘어남 

제품의 복잡도 

응용 : 개발지원 : 시스템 = 1 : 3 : 9 

프로그래머의 자질 

 코딩, 디버깅의 능력차 

 프로그래밍 언어, 응용 친숙도 

요구되는 신뢰도 수준 

기술 수준 

개발 장비, 도구, 조직능력, 관리, 방법론 숙달 

남은 시간 

Putnam 

 “프로젝트의 노력은 남은 개발 기간의 4제곱에 반비례” 

COCOMO(Constructive Cost Model) 방법 

Boehm이 개발 

ex)

 CAD 시스템 

 예상 규모 - 33360LOC 

PM = 3.0*(KDSI)**1.12 = 3.0*(33.3)**1.12 = 152MM 

TDEV = 2.5*(PM)**0.35 = 2.5*(152)**0.35 = 14.5M 

N = E/D = 152/14.5 ~ 11명