블랙박스 테스트 / 화이트 박스 테스트
1. 블랙박스 테스트
- 개념: 어떤 소프트웨어를 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 테스트
- 종류: 동등 분할 테스트 / 경계 값 분석 테스트 / 결정 테이블 테스트 / 상태전이 테스트 / 유스케이스 테스트 / 분류트리 테스트 / 페어와이즈 테스트
2. 화이트 박스 테스트
- 개념: 응용 프로그램의 내부 구조와 동작을 검사하는 테스트
- 종류: 제어구조 테스트, 루프 테스트, 구문 기반, 결정 기반, 조건 기반, 조건/결정 기반, 변경조건/결정 기반, 다중조건 기반 커버리지 테스트
[ISO/IEC 9126의 소프트웨어 품질 특성]
품질 특성 | 설명 |
기능성 (Functionality) |
소프트웨어가 특정 조건에서 사용될 때, 명시된 요구와 내재된 요구를 만족하는 기능을 제공하는 소프트웨어 제품의 능력 품질 부특성에는 적합성, 정확성, 상호운용성, 보안성, 준수성 등이 있음 |
신뢰성 (Reliability) |
명세된 조건에서 사용될 때, 성능 수준을 유지할 수 있는 소프트웨어 제품의 능력 - 옳고 일관된 결과를 얻기 위하여 요구된 기능을 수행할 수 있는 정도이고, 주어진 시간동안 주어진 기능을 오류 없이 수행하는 정도 품질 부특성에는 성숙성, 결함허용성, 회복성, 준수성 등이 있음 |
사용성 (Usability) |
명시된 조건에서 사용될 경우, 사용자에 의해 이해되고, 학습되고, 사용되고 선호될 수 있는 소프트웨어 제품의 능력을 말함 품질 부특성에는 이해성, 학습성, 운용성, 친밀성, 준수성 등이 있음 |
효율성 (Efficiency) |
명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 소프트웨어 제품의 능력을 말함 품질 부특성에는 시간반응성, 자원효율성, 준수성 등이 있음 |
유지보수성 (Maintainability) |
소프트웨어 제품이 변경되는 능력 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 혹은 개작 등이 포함 품질 부특성에는 분석성, 변경성, 안정성, 시험성, 준수성 등이 있음 |
이식성 (Portability) |
한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어 제품의 능력 품질 부특성에는 적응성, 설치성, 공존성, 대체성, 준수성 등이 있음 |
두음: 기신사효유이
재사용
분류 | 설명 |
함수와 객체 재사용 | 클래스나 함수 단위로 구현된 소스코드를 재사용 |
컴포넌트 재사용 | 컴포넌트 단위로 재사용하며 컴포넌트의 인터페이스를 통해 통신 |
애플리케이션 재사용 | 공통된 기능을 제공하도록 구현된 애플리케이션과의 통신으로 기능을 공유하여 재사용한다. |
인공지능, 기계학습, 딥러닝
1. 인공지능(AI; Artificial Intelligence)
- 인공지능이란 인간의 지적능력을 인공적으로 구현하여 컴퓨터가 인간의 지능적인 행동과 사고를 모방할 수 있도록 하는 소프트웨어이다.
2. 기계학습(Machine Learning)
- 기계학습은 인공지능의 분야 중 하나로, 인간의 학습 능력과 같은 기능을 컴퓨터에서 실현하고자 하는 기술이다.
- 환경과의 상호작용에 기반한 경험적인 데이터로부터 스스로 성능을 향상시키는 시스템을 연구하는 기술이다
3. 딥러닝(Deep Learning)
- 딥러닝은 사람의 개입이 필요한 기존의 지도학습(supervised learning)에 보다 능동적인 비지도학습(unsupervised)이 결합되어 컴퓨터가 마치 사람처럼 스스로 학습할 수 있는 인공지능 기술이다.
침투테스트 절차
정찰->탐색->접근권한취득->액세스유지->추적방지
TCP(Transmission Control Protocol) 개념
전송계층에 위치하면서 근거리 통신망이나 인트라넷, 인터넷에 연결된 컴퓨터에서 실행되는 프로그램간에 일련의 옥텟을 안정적으로 순서대로, 에러 없이 교환할 수 있게 해 주는 프로토콜 입니다
TCP 특징으로는 신뢰성보장, 연결지향, 흐름제어, 혼잡제어등이 있습니다
지역성
시간지역성
처음에 참조된 기억장소가 가까운 미래에도 계속 참조될 가능성이 높음
예) 순환, 부 프로그램, 스택 등
공간지역성
어떤 기억 장소 하나가 참조되었을 때, 그 근처의 기억 장소가 계속 참조될 가능성이 높음
예) 순차적 코드의 실행
선점형 스케줄링
라스다다
라운드로빈 (Round Robin)
SRT (Shortest Remaining Time First)
다단계 큐 (Multi Level Queue)
다단계 피드백 큐 (Multi Level Feedback Queue)
내외부 송수신 연계 기술 유형
링컨에제하소
EAI (Enterprise Application Integration) 개별 유형 설명 문제
포인트 투 포인트(Point-to-point): 가장 기초적인 애플리케이션 통합방법으로 1:1 단순 통합 방식이다.
허브 앤 스포크(Hub & Spoke): 단일한 접점의 허브 시스템을 통하여 데이터를 전송하는 중앙 집중식 방식이다.
메시지 버스(Message Bus): 애플리케이션 사이 미들웨어(버스)를 두어 연계하는 미들웨어 통합 방식이다.
하이브리드(Hybrid): 그룹 내는 허브 앤 스포크 방식을 사용하고, 그룹 간에는 메시지 버스 방식을 사용하는 통합 방식이다.
비용산정모델
상향식 모델은 세부적인 요구사항과 기능에 따라 필요한 비용을 산정하는 방식입니다. 상향식 모델에는 LOC(Line of code), MM(Man Month), COCOMO, Putnam, FP(Function Point)이 있습니다
하향식 모델은 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식입니다. 하향식 모델에는 델파이, 전문가 기법이 있습니다
[파티션(Partition)의 종류]
1. 파티션 개념
- 대용량의 테이블을 파티션(Partition)이라는 보다 작은 논리적인 단위로 나눔으로써 성능 저하 방지 및 관리를 상대적으로 보다 용이하게 하고자 하는 개념이다.
2. 파티션의 종류
- 레인지 파티셔닝
- 해시 파티셔닝
- 리스트 파티셔닝
- 컴포지트 파티셔닝
객체지향 설계 원칙
1. 객체지향 설계 원칙의 개념: 사물 또는 개념을 객체라는 단위로 표현하는 방법으로 객체간에 메시지를 주고받는 형태로 시스템 구성하여 코드를 좀더 유지보수하기 쉽고, 유연하고, 확장하기 쉽게 만들기 위한 설계 원칙
2. 객체지향 설계 원칙
가. 단일 책임의 원칙(Single Responsibility Principle): 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙
나. 개방 폐쇄 원칙(Open Close Principle): 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙
다. 리스코프 치환의 원칙(Liskov Substitution Principle): 자식 클래스(서브 타입)는 언제나 자신의 부모 클래스(기반 타입)를 대체한다는 원칙
라. 인터페이스 분리의 원칙(Interface Segregation Principle): 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
마. 의존성 역전의 원칙(Dependency Inversion Principle): 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙
동시성 제어 기법
락킹(Locking)기법
2단계 락킹(2Phase Locking)기법
낙관적 검증 기법
타임스탬프 순서(Timestamp ordering) 기법
다중버전 동시성제어(MVCC) 기법
데이터 타입의 유형
불문문 정부배
1. 불린 타입(Boolean type): 조건이 참(TRUE)인지 거짓(FALSE)인지 판단하고자 할 때 사용
2. 문자 타입(Char type): 문자 하나를 저장하고자 할 때 사용
3. 문자열 타입(String type): 나열된 여러 개의 문자를 저장하고자 할 때 사용
4. 정수 타입(Int type): 정숫값을 저장하고자 할 때 사용
5. 부동 소수점 타입(Float type): 소수점을 포함하는 실숫값을 저장하고자 할 때 사용
6. 배열 타입(Array type): 여러 데이터를 하나로 묶어서 저장하고자 할 때 사용
스토리지 장치 구성 방식
1. DAS (Direct Attached Storage)
- 하드 디스크와 같은 데이터 저장 장치를 호스트 버스 어댑터(HBA)에 직접 연결하는 방식이다.
2. NAS (Network Attached Storage)
- 서버와 저장 장치를 네트워크로 연결하는 방식으로, 구성 설정이 간편하며 별도의 운영 체제를 가진 서버 한 곳에서 파일을 관리하기 때문에 서버 간에 스토리지 및 파일 공유가 용이하다.
3. SAN (Storage Area Network)
- 서버와 스토리지를 광케이블 및 광 채널 스위치를 통해 근거리 네트워크 환경을 구성하여 빠른 속도로 데이터를 처리할 수 있으며 고가용성, 고성능, 융통성, 확장성을 보장하고 데이터를 블록(Block) 단위로 관리하는 기술이다.
플랫폼 성능 분석 기법
1. 플랫폼(Platform)의 개념: 애플리케이션을 구동시키는 데 필요한 하드웨어와 소프트웨어의 결합으로, 동일 플랫폼 내에서는 상호 호환이 가능하도록 만들어진 결합체이자 구축 환경이다.
2. 플랫폼 성능 특성 분석 기법
가. 사용자 인터뷰: 현행 플랫폼 사용자 인터뷰를 통해 속도의 적정성 확인(인터뷰 결과서)
나. 성능 테스트: 현행 플랫폼을 대상으로 성능, 부하 테스트를 수행(성능 테스트 결과서, 부하 테스트 결과서)
다. 산출물 점검: 현재 플랫폼과 유사한 타사 제품의 성능 자료 등을 분석(벤치마킹 테스트 결과서)
태그
뷰(View)의 속성
1. REPLACE: 뷰가 이미 존재하는 경우 재생성
2. FORCE: 기본 테이블의 존재 여부에 관계 없이 뷰 생성
3. NOFORCE: 기본 테이블이 존재할 때만 뷰 생성
4. WITH CHECK OPTION: 서브 쿼리 내의 조건을 만족하는 행만 변경
5. WITH READ ONLY: 데이터 조작어(DML) 작업 불가
소프트웨어 아키텍처 프레임워크 구성요소
1. 아키텍처 명세서: 아키텍처를 기록하기 위한 산출물들
2. 이해관계자: 시스템 개발에 관련된 모든 사람과 조직
3. 관심사: 시스템에 대해 이해관계자들의 서로 다른 의견과 목표
4. 관점: 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식
5. 뷰: 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현
6. 근거: 아키텍처 결정 근거
스크립트 언어
1. 스크립트 언어(Script Language) 개념
- 소스 코드를 컴파일(Compile)하지 않고도 실행할 수 있는 프로그래밍 언어이다.
- 응용 프로그램과 독립하여 사용되고 일반적으로 응용 프로그램의 언어와 다른 언어로 사용되어 최종사용자가 응용 프로그램의 동작을 사용자의 요구에 맞게 수행할 수 있도록 해준다.
2. 스크립트 언어 종류: PHP, 펄(Perl), 파이썬(Python), 자바스크립트(Javascript)
트랜잭션의 특성
구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 체계적인 분석 방법론
- 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
데이터 모델 품질 검증 기준
정완일 최일활
정확성, 완전성, 일관성, 준수성, 활용성, 최산성
서비스 공격
① TearDrop
- IP 패킷의 재조합 과정에서 잘못된 fragment offset 정보로 인해 수신시스템이 문제를 발생하도록 만드는 Dos 공격이다.
- 공격자는 IP fragment offset값을 서로 중첩되도록 조작하여 전송하고 이를 수신한 시스템이 재조합하는 과정에서 오류가 발생, 시스템의 기능을 마비시키는 공격 방식이다.
② Smishing (SMS phishing, 스미싱)
- 스미싱은 SMS(문자메시지)와 피싱(Phising)의 합성어이다.
- 문자메시지를 이용하여 신뢰할 수 있는 사람 또는 기업이 보낸 것처럼 가장하여 개인비밀정보를 요구하거나 휴대폰 소액 결제를 유도하는 피싱 공격(사이버 사기)이다.
③ Qshing (큐싱)
- 큐알 코드(QR코드)와 피싱(Phising)의 합성어이다.
- 스마트폰을 이용하여 금융 업무를 처리하는 사용자에게 인증 등이 필요한 것처럼 속여 QR코드(Quick Response Code)를 통해 악성 앱을 내려받도록 유도, 금융 정보 등을 빼내는 피싱 공격(사이버 사기)이다.
- 최근 제로페이 확산에 따라 피해가 증가하고 있다.
④ Smurfing
- ICMP Echo Request 메시지(Ping 요청)의 송신자 주소(IP)를 희생자의 주소(IP)로 스푸핑한 후 이를 증폭 네트워크에 직접 브로드캐스트(Directed Broadcast)하여 외부의 ICMP Echo Reply(Ping 응답)를 발생시켜 희생자에게 대량의 트래픽을 발생시키는 Dos 공격이다.
교착상태
* 교착상태(Dead Lock)의 정의
- 다중프로세싱 환경에서 두개 이상의 프로세스가 특정 자원 할당을 무한정 대기하는 상태
* 교착상태의 발생조건 (발생의 필요 충분 조건)
- 상호배제 (Mutual Exclusive) : 프로세스가 자원을 배타적으로 점유하여 다른 프로세스가 그 자원을 사용할 수 없음
- 점유와 대기 (Block & Wait) : 한 프로세스가 자원을 점유하고 있으면서 또 다른 자원을 요청하여 대기하고 있는 상태
- 비선점 (Non Preemption) : 한 프로세스가 점유한 자원에 대해 다른 프로세스가 선점할 수 없고, 오직 점유한 프로세스만이 해제 가능
- 환형대기 (Circular wait): 두 개 이상의 프로세스간 자원의 점유와 대기가 하나의 원형을 구성한 상태
* 교착상태의 해결방안
- 예방 (Prevention) : 상호배제를 제외한 나머지 교착 상태 발생조건을 위배(부정)하는 방안 - 점유 자원 해제 후 새 자원 요청
- 회피 (Avoidance) : 안전한 상태를 유지할 수 있는 요구만 수락(프로세스별 자원 최대요구량 확보) - Banker’s Algorithm(은행가 알고리즘), Wait-die, wound-wait
- 발견 (Detection) : 시스템의 상태를 감시 알고리즘 통해 교착상태 검사 - 자원할당 그래프, Wait for Graph
- 회복 (Recovery) : Deadlock 이 없어질 때까지 프로세스를 순차적으로 Kill 하여 제거, 희생자 선택해야 하고 기아상태 발생 - 프로세스 Kill, 자원선점
가능
알파테스트 / 베타테스트 (인수테스트)
* 알파테스트
- 개발하는 조직 내에서 잠재적인 고객에 의해 수행되는 테스트
- 개발자 환경에서 사용자가 수행하는 테스트
- 공장 인수 테스트(Factory acceptance test)라고도 함
* 베타테스트
- 실제 업무 현장에 있는 인원(사용자, 잠재적인 고객)에 의해서 수행되는 테스트
- 실제 사용 환경에서 진행하는 테스트
- 일정 수의 사용자가 테스트 후 피드백을 함
- 필드 테스트라고 하고, 사이트 인수 테스트(Site acceptance testing)이라고도 함
* Tripwire
- 크래커가 침입하여 시스템에 백도어를 만들어 놓거나 설정 파일을 변경해 놓았을 때 이러한 사실을 알 수 있게 분색해 주는 강력한 도구다.
- Tripwire은 시스템 내의 지정한 중요한 디렉토리와 파일에 대한 데이터베이스를 생성한 후에 Tripwire를 실행할 때 새로 생성된 데이터 베이스와 비교하여 그 차이점을 보고해 줌으로써 시스템 관리자가 시스템 내에서 어떠한 변화가 있는지 감지할 수 있게 해주는 도구다.
네트워크 분석 도구?
* Ping
- Ping 명령은 인터넷으로 접속하려는 원격 호스트가 정상적으로 운영되고 있는지를 확인하는 진단 목적으로 사용하는 명령어이다.
* tcpdump
- 네트워크 인터페이스를 거치는 패키의 내용을 출력해주는 프로그램이다.
- 스니핑 도구의 일종으로 자신의 컴퓨터로 들어오는 모든 패킷의 내용을 도청할 수 있으며, 공격자에 대한 추적 및 공격 유형 분석을 위한 패킷 분석 시 활용할 수 있는 도구이다.
* tracert
- 목적지까지의 데이터 도달여부를 확인하는 도구이다.
* Cron
- 특정한 시간에 또는 특정 시간 마다 어떤 작업을 자동으로 수행하게 해주고 싶을 때 사용하는 명령어이다.
- Cron은 특정한 시간에 특정한 작업을 수행하게 해주는 스케줄링 역할을 한다.
* 백도어 탐지기법
1. 현재 동작중인 프로세스 및 열린 포트 확인
2. Setuid 파일 검사
3. 백신 및 백도어 탐지 툴을 이용하여 확인
4. 무결성 검사
5. 로그 분석
자료사전 기호
* UML 스테레오 타입(Stereotype)의 개념
- UML 의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 매커니즘.
- 형태는 기존의 UML 의 요소를 그대로 사용하나 내부의미는 다른 목적으로 사용하도록 확장
- '<< >>' 길러멧(guillemet) 기호를 사용하여 표현
* UML 스테레오 타입의 유형
- <<include>> : 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계. 반드시 실행
- <<extend>> : 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고 그렇지 않을 수도 있는 확장관계
- <<interface>> : 모든 메소드가 추상메소드이며 바로 인스턴스를 만들수 없는 클래스, 추상메소드와 상수만으로 구성된 클래스
- <<entity>> : 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스, 유스케이스 처리흐름이 수행되는 과정에서 기억 장치에 저
장되어야 할 정보를 표현하는 클래스
- <<boundary>> : 시스템과 외부와의 경계에 걸쳐 있는 클래스, 시스템 주변 환경과 시스템 내부간의 커뮤니케이션을 담당
- <<control>> : 어떤 특정 객체에 연관되지 않은 기능을 모델링, 여러 Entity 클래스의 오퍼레이션과 계산 수행, Boundary 클래스로의 결과 리턴 등의 Behavior 들로 구성된 기능
- <<enumeration>> : 열거형 타입 클래스
객체지향 분석 방법론
Coad와 Yourdon 방법
E-R다이어그램을사용하여 객체의 행위를 모델링하며, 객체식별, 구조 식별, 주체 정의, 속성 및 관계정의, 서비스 정의 등의 과정으로 구성
Wirfs-Brock 방법
분석과 설계간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법
Rumbaugh 방법
가장 일반적으로 사용되는 방법으로 분석 활동을 객체모델, 동적모델, 기능 모델로 나누어 수행하는 방법
Booch 방법
미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석방법
Jacobson 방법
Use Case를 강조하여 사용하는 분석방법
법칙
1. 브룩스의 법칙(Brooks' law)
- 이 법칙은 프레더릭 브룩스가 자신의 1975년 저서 《맨먼스 미신》 (The Mythical Man-Month)에서 "지체되는 소프트웨어 개발 프로젝트에 인력을 추가하는 것은 개발을 늦출 뿐이다"라고 주장한 법칙이다.
- 인력이 추가되서 개발 생산성이 향상되지 않고, 오히려 그 인력때문에 방해된다는 의미 내포
2. 요르돈의 법칙(Yourdon's Law)
- SW 개발 초기 체계적인 분석 및 설계가 수행되지 못하면 그 결과가 프로젝트 후반에 영향을 미치게 되어 비용이 커진다는 법칙(snowball effect, 눈덩이 법칙)
3. 파레토 법칙( Pareto principle), 80 대 20 법칙
- 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상'을 가르키는 말이다.
- 소프트웨어 테스트 원리 중 20%의 모듈에서 80%의 결함이 발견된다는 "결함집중"의 원리를 내포하고 있다.
4. 롱테일 법칙(Long Tail)
- 사소해 보이는 80%의 다수가 20%의 소수 핵심보다도 뛰어난 가치를 창출해낸다는 이론
- 파레토 법칙의 반대 이론
5과목 용어
* BCP(Business continuity Planning)
- 기업이 재해/재난으로부터 타격을 입은 뒤 업무를 어떻게 복구하는지에 대한 계획
- 전산의 단순복구 뿐 아니라 고객 비즈니스의 지속성을 보장
- BCP를 통해서 재해예방, 대응 및 복구, 운영 및 유지관리, 모의훈련을 함
* DRS(Disaster Recovery System)
- 재해/재난 시 서비스 연속성 보장을 위해 메인 센터와 분리되어 동일 역할을 하는 재해 복구 시스템
* RTO(Recovery Time Objective)
- 재해 복구 목표 시간
- 업무 중단 시점부터 복구되어 가동될 때 까지 목표 시간
- 재해 복구 목표 시간은 중요한 서비스일수록 짧아야 합니다.
- 예: 은행에서 계좌 이체 서비스 장애 발생 시 1분 이내 복구
* RPO(Recovery Point Objective)
- 재해 복구 목표 시점
- 재해 발생시 데이터 손실을 수용할 수 있는 손실 허용 시점
- 예: 특정백업시점 데이터 복구, 전일 마감 백업 시점 복구
UI 시나리오 문서의 작성 요건
가. 완전성(Complete)
- UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 가능한 한 상세하게 기술한다.
- 시스템 기능보다 사용자의 태스크에 초점을 맞춰 기술한다.
나. 일관성(Consistent)
- 서비스에 대한 목표, 시스템 및 사용자의 요구사항이 일관성이 있어야 하고, 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성한다.
다. 이해성(Understandable)
- 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명해야 하고, 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않아야 한다.
라. 가독성(Readable)
- 문서를 쉽게 읽을 수 있어야 하고(문서 템플릿과 타이포그래피), 표준화된 템플릿을 작성하여 적용한다.
- 버전의 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 하고, 시각적인 효과를 위한 하이라이팅은 일관성 있게 활용한다.
마. 수정 용이성(Modifiable)
- 쉽게 변경이 가능해야 하고, 수정 또는 개선 사항을 시나리오에 반영함에 있어 쉽게 적용할 수 있어야 한다.
- 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 한다.
바. 추적 용이성(Traceable)
- 쉽게 추적이 가능해야 하고, 변경 사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 한다.
* UI 시나리오 문서 작성의 요건: 완일이가 추수(완일이가 추수했음) -> 완전성, 일관성, 이해성, 가독성, 추적 용이성, 수정 용이성
'자격증 > 정보처리기사' 카테고리의 다른 글
2020 정처기 실기 약술형 대비 (1) | 2020.10.17 |
---|---|
2020 정보처리기사 실기 기출 예상 (0) | 2020.10.16 |
2020-06-06 5과목 기출 정리 - A형 (0) | 2020.08.16 |
2020-06-06 4과목 기출 정리 - A형 (0) | 2020.08.14 |