Make your root ♔

2) 애플리케이션 통합 테스트하기 •통합 테스트 소프트웨어 각 모듈간의 인터페이스 관련 오류 및 결함을 찾아내기 위한 체계적인 테스트 기법 -> 목적 : 단위 테스트가 끝난 모듈 또는 컴포넌트 단위의 프로그램이 실제 단계에서 제시한 애플리케이션과 동일한 구조와 기능으로 구현된 것인지 확인하는 것 -> 수행방법 : 비점증적인 빅뱅방식은 모든 컴포넌트를 사전에 통합하여 전체 프로그램을 한꺼번에 테스트 하는 것 -> 점증적인 방법은 상향적 통합과 하향식 통합 방식으로 구분 - 하향식 통합(Top Down) : 메인 제어 모듈(프로그램)로부터 아래 방향으로 제어의 경로를 따라 이동, 통합되는 하위 모듈과 최하위 모듈은 '깊이-우선' 또는 '너비-우선' 방식으로 통합 -> 아직 완성되지 않은 하위 제어모듈 및 모..

1) 애플리케이션 테스트케이스 설계하기 - 애플리케이션 테스트 케이스 작성 - 소프트웨어 테스트 : 소프트웨어의 결함을 적극적으로 찾아내는 활동 -> 테스트 : 알려지지 않은 에러의 발견, 시스템 내부 관련자, 외부의 제3자 -> 디버깅 : 이미 알고 있는 에러의 수정, 에러의 정확한 위치 파악, 에러 타입 식별, 에러 수정 -> 시스템 내부 관련자 - 소프트웨어 테스트 필요성 오류 발견 관점 오류 예방 관점 품질 향상 관점 * V모델 - 소프트웨어 테스트의 기본 원칙 - 테스팅은 개발 초기에 시작 : 소프트웨어 개발 생명 주기의 각 단계에 맞춰 전략적으로 접근하는 것을 고려하라는 의미 - 테스팅은 결함이 존재함을 밝히는 활동 : 결함이 발견 되지 않아도 결함이 없다고 증명할 수 없음 - 완벽한 테스팅은..

2) UI 설계하기 - UI 흐름 설계 업무의 흐름이나 업무 수행과 관련된 일련의 클릭에 의한 화면의 위치와 흐름을 흐름도 형식으로 표현하는 활동 -> 한 가지의 업무를 수행하는데 필요한 화면과 일련의 흐름을 이해시킴 -> 화면의 용도를 이해시킴 - UI 흐름 설계 수행 절차 - 업무 흐름 분석 - 화면에 표현되어야 할 기능 정의 시스템 입력 시스템 풀력 어떤 데이터를 저장할 건지 어떤 연산을 수행할지 - 업무 흐름을 기반으로 화면 흐름 정의 -> 각 단위 화면 간의 선후행 분석 -> 각 화면 간의 흐름을 정의 - 기능 분석을 통해 공통적으로 필요한 기능 및 양식 정의 - UI 상세 설계 - UI 요구사항 확인 - UI 구조 설계 -> UI 요구사항들과 UI 프로토타입에 기준해 UI 구조 설계 - 메뉴 ..

1) UI 요구사항 확인하기 •화면 설계의 개요 - 화면(User Interface) 사람과 시스템 사이의 접점 -> 사용자와 각각의 시스템 사이의 정보 채널 -> 화면 설계 : 상호 정보 교환의 방법을 체계화하여 설계하고 디자인하는 작업 - 화면 설계의 방향 사용자 중심 단순한 설계 현명한 색상 사용 일관성 유지 사용자 경험 지식화 지속적인 테스트 및 반복 - 설계 원칙 직관성 유효성 학습성 유연성 - UI의 유형 명령어 방식 : 명령어 암기 필요 메뉴 방식 : 기억보다 인식에 의존하는 방식 자연언어 이용 방식 : 자연 언어의 모호성이 혼동을 가져올 수 있음 윔프 포인터와 클릭 - 화면 설계의 수행 절차 - UI 스타일 가이드 작성 디자이너 또는 개발자들이 각각 웹사이트의 다른 부분들을 맡아서 일을 할..

•알고리즘 특정 문제를 해결하기 위한 일련의 순차적 계산 혹은 풀이 절차 - 알고리즘의 기본 절차 구조 순차구조(Sequence) : 직선형, 시작부터 마지막까지 순차적으로 진행 선택구조(Selection) : 분기형, 조건에 따라 실행 내용, 순서 달라짐 반복구조(Repition) : 조건을 만족할 때까지 일정 내용 반복 실행 * 수열 알고리즘 -> 1+2+3+ ... +99+100 까지 구하기 int i=0, sum=0; do { i++; sum+=i; } while(i>100); System.out.println(sum); -> 1-2+3-4+5-6+ ... +99-100 구하기 -> 스위치 변수(mode) 이용 int i=0, sum=0, mode=0; do { i++; if(mode==0){ s..

3) 서버 프로그램 구현하기 •프로그램 구현 절차 -> MVC 기반 구조 - DTO/VO 구현 DTO(Data Transfer Object)는 프로그램에서 유통되는 데이터를 객체화한 것 -> 데이터 값을 설정하고 조회하는 getter, setter 외에 비즈니스 로직을 가지지 않음 VO(Value Object)는 DTO와 비슷하나 데이터의 값을 변경할 수 없음 - SQL 구현 - DAO 구현 DAO(Data Acess Object)는 데이터베이스에 접근하여 데이터를 생성, 조회, 수정 삭제하는 역할을 담당함 -> 특정 타입의 데이터베이스나 다른 영속성 매커니즘에 추상 인터페이스를 제공하는 객체 -> 비즈니스 로직과 데이터베이스 접근 로직을 분리하기 위해 사용 - Service 구현 사용자의 요청에 따라 ..

1) 개발 환경 구축하기 - 개발과 품질 관리에 대한 요구사항을 분석하여 형상 관리 서버, 테스트 서버, 빌드 서버를 결정 -> 구현 도구, 테스트 도구, 형상 관리 도구, 빌드 도구 등 설계 - IDE(Integrated Development Environment) 통합 개발 환경, 프로그램 개발에 관련된 모든 작업을 하나의 프로그램에서 처리하는 환경을 제공하는 소프트웨어 -> Eclipse, Visual Studio, Atom - 형상관리 도구 -> Git, CVS, SVN 등 - 빌드 도구 -> Maven, Ant, Gradle 등 - 서버 개발 프레임워크를 활용한 개발 환경 구축 개발 프레임워크는 재사용 가능한 라이브러리와 애플리케이션 인터페이스, 설정 정보 뿐만 아니라 개발과 운영을 지원하는 도..

3) 내외부 연계 모듈 구현하기 •연계 모듈 구현 환경 구성과 개발 - EAI/ESB 방식 -> DBMS의 트리거를 JAVA와 같은 프로그램 언어를 사용함 -> 응용 애플리케이션으로 구현 or 연계 테이블을 연계 파일로 변경 -> 연계 데이터 처리를 위해 테이블 방식 또는 파일 방식으로 운용 -> 전송이나 전송 이력을 기록하는 기능을 구현할 필요 없음 -> 데이터 변환, 운영 DB에 반영 시 발생하는 데이터 오류에 대한 사항을 기록 모듈 구현 -> 기존 연계를 위한 DB가 운영중인 경우 연계 목적에 따라 분리한 연계 사용자 계정 생성 운영 DB의 사용자와 연계를 위한 사용자는 생성되는 스키마의 목적이 다르므로 물리적 및 논리적으로 분리하여 관리 -> 연계를 위한 테이블 생성 : 연계 테이블, 로그 테이블..

2) 연계 매커니즘 구성하기 - 연계 매커니즘 송신 시스템 + (중계 서버) + 수신 시스템 -> 연계 데이터는 인터페이스 테이블 또는 파일로 생성 -> 중계 서버 배치 의사 결정 포인트 : 보안 품질 특성이 중요하거나 송신시스템과 수신시스템이 위치한 네트워크가 상이한 경우 배치 - 연계 방식 -> 직접 연계 : 중간 매개체 없이 구성 -> 연계 및 통합 구현 단순, 시스템 간 결합도가 높아 변경에 민감 -> 간접 연계 : 중간 매개체 활용 -> 다양한 환경에 대해 연계 및 통합 가능, 시스템 간 인터페이스 변경시 장애나 오류 없이 서비스 가능, 연계 아키텍처 및 매커니즘이 복잡, 중간 매개체로 인해 성능에 영향 - 연계 데이터 추출 및 생성 -> 운영 DB에서 연계 데이터를 추출하고 생성 -> 응용 시..

1) 연계 데이터 구성하기 - 연계 요구사항 분석 - 분석 문서 : 시스템 구성도, 응용 애플리케이션 구성, 테이블 정의서, 코드 정의서 - 분석 및 정의 기법/도구 : 인터뷰, 체크리스트, 설문조사, 델파이조사, 연계 솔루션 비교 * 델파이 조사 : 시스템 아키텍처/ 연계 전문가에게 자문 * 연계 솔루션 : EAI, ESP, OPEN API 등 - 통합 구현의 개념도 : 시스템 아키텍처 구성, 솔루션 방식, 송수신 모듈 구현 방법 등에 따라 다양함 * 송수신 방식은 직접연계 방식과 간접연계 방식으로 구분 * 직접 연계(점대점 방식, Point to point) : DB Link, JDBC, API 등 * 간접 연계 : EAI, ESB, 소켓 등 - 통합 구현 구성 - 송신 시스템과 송신 모듈 : 일반적..

2) 물리 데이터 저장소 설계 절차 •물리 스키마 설계 - ERD 변환 (논리 -> 물리) 엔티티 테이블 속성 컬럼 주 식별자 기본키 외래 식별자 외래키 관계 관계 관계의 카디널리티 관계의 카디널리티 관계의 참여도 관계의 참여도 - 엔티티 -> 테이블 변환 -> 일반화 관계는 3가지 타입으로 변환 -> 슈퍼 타입 기준 변환 : 엔티티의 서브 엔티티를 슈퍼 엔티티에 통합하여 하나의 테이블로 변환 -> 장점 : 데이터 액세스 용이, 수행속도 증가, 조인 감소, 복잡한 처리를 하나의 SQL로 통합하기 용이함 -> 단점 : 컬럼 및 블록 수 증가, 인덱스 크기 증가, 서브 타입 구분이 필요한 경우 발생 -> 서브 타입 기준 변환 : 슈퍼타입을 서브타입에 복제하여 하나의 테이블로 변환 -> 장점 : 단위 테이블 ..

1) 논리 데이터 저장소 확인하기 - 논리 데이터 저장소 확인 절차 -> 엔티티 및 속성 확인 엔티티의 누락/중복 확인 속성을 확인하여 물리 테이블의 컬럼으로 전환 가능한지 여부 확인 공통 코드 대상 확인 * 공통 코드 : 유형이 정해져 있는 속성으로 그 상태가 잘 변하지 않는 속성들 -> 관계 확인 : 엔티티간 관계와 정규화 수준 검토 •정규화(Normalization) 이상 현상의 원인이 되는 데이터 중복성을 제거 -> 데이터 무결성 보존 - 정규화의 원칙 무손실 분해 자료의 중복성 제거 분리의 원칙 - 제1정규형(1NF) 릴레이션 R의 모든 속성 값이 원자값을 가지는 릴레이션 - 제2정규형(2NF) 릴레이션 R이 제1정규형이고 기본키가 아닌 속성이 기본키에 완전 함수 종속일 때 R은 제2정규형을 만..

3) 분석 모델 확인하기 •UML(Unified Modeling Language) -> OMG(Object Management Group)에서 만든 객체지향 모델링 언어 -> 정보 시스템을 객체 지향으로 분석 설계 - 구성요소 뷰 : 모델화된 시스템의 서로 다른 모형 제공 다이어그램 : 뷰의 내용을 나타내기 위한 13가지 다이어그램 제공 모델요소 : 클래스, 속성, 오퍼레이션 일반적 체계 : 주석 정보와 의미 제공 - UML 다이어그램 종류 -> 요구사항 Use-Case : 사용자 입장에서 본 시스템의 행동을 표현, Use Case들은 시스템의 기능적인 요구를 정리 -> 정적 모델링 Class : 시스템 내 클래스들의 정적 구조를 표현, 속성과 동작으로 구성 Object : 클래스의 여러 오브젝트 인스턴..

2) 요구사항 확인하기 •요구사항 추출 및 분석 기법 -> 요구사항 추출 -> 요구사항 정의 -> 요구사항 분석 -> 요구사항 검증 -> 요구사항 영향도 분석 - 요구사항 추출 추상적 요구에 대한 관련 정보를 식별하고 수집하여 구체적 요구사항으로 표현하는 활동 -> 추출 기법 : 인터뷰, 설문, 워크샵, 브레인 스토밍, 스토리보드, 프로토타입핑, 롤플레잉 * 스토리보드 : 고객이 실제 시스템으로 오인 * 프로토타입핑 : 외부적으로 확인 할 수 있는 부분을 시연 -> 데모, 시뮬레이션 * 롤플레잉 : 개발자와 분석가가 기존 시스템을 실제 사용자 같이 수행함 - 요구사항 정의 프로젝트 영역별로 요구 내역을 구체화하여 정의하는 요구사항 정의서를 만듦 -> 요구사항은 기능 및 비기능으로 구분하여 상세 기술 ->..

1) 현행 시스템 파악 • 현행 시스템 분석을 위한 단계 1단계 : 현행 시스템 분석 현행 시스템 분석서 작성 (하드웨어 구성 -> 네트워크 구성 -> 현행 시스템 구성 장단점 분석 -> 개선 방안 도출) 고객 아카데미 요구사항 파악 2단계 : 목표시스템 아키텍처 선정 단계 목표 시스템 아키텍처 정의 (정의서 작성) 소프트웨어 아키텍처 정의서 작성 (아키텍처 스타일, 표준 패턴 정의 -> 시스템의 표준 연계 구조 정의 -> 소프트웨어 아키텍처 제약사항) 시스템 아키텍처 정의서 작성 (시스템 구성, 하드웨어 구성, 네트워크 구성, 소프트웨어 구성, 제약사항 기술) 이키텍처 평가 (유틸리티 트리를 작성하여 요구사항 간 상호 관계나 상충관계 파악 -> 아키텍처 평가 결과서 작성) 3단계 : 목표 시스템 개발 ..

실기 합격 후기 사실 정보처리기사 실기는 작년 8월에 합격했습니다. 근데 지금 글을 쓰는 이유를 물으신다면 자격증을 따고 학교 졸업 및 취업 준비를 하느라 여러가지 경황이 없었습니다. 2021년 연초에 입사하고 여러가지 적응아닌 적응을 하느라 이제와서 후기글을 올리게 되네요. 사실 정보처리기사 실기 시험을 작년에 두번을 보게 되었습니다. 첫번째는 무려 불합격... 분명히 NCS로 개편됬으니 개정된 책으로 공부하라 해서 그 책만 죽어라 팠는데 웬걸... 2019년도 필기 합격자를 배려하기 위해 개정 전 문제도 출제를 했다 하더군요, (그럼 미리 말을 해야 공부를 할거 아니냐;;) 결국 첫번째 시험은 거의 반을 모르는 문제로 55점으로 불합격.. 첫 실기 시험이라 어떻게 신청을 해야하는지 몰라 결국 안산까지..