1. 소프트웨어 공학 개념
- 소프트웨어 공학 (1강)
- 소프트웨어 개발 방법론 (2강)
2. 프로젝트 계획 및 분석
- 프로젝트 계획 (3강)
- 요구사항 분석 (4강)
3. 소프트웨어 설계
- 소프트웨어 설계의 기본원칙 (5강)
- 소프트웨어 아키텍쳐 (6강)
- UML (7강)
4. 화면 설계
- UI 설계 (8강)
- UI 구현 (9강)
5. 서버 프로그램 구현
- 개발 환경 구축 (10강)
- 개발 프레임워크 (11강)
- 모듈 구현 (12강)
- 서버프로그램 구현 (13강)
- 배치프로그램 구현 (14강)
6. 인터페이스 구현
- 인터페이스 개요 및 설계서 확인 (15강)
- 인터페이스 기능구현 및 검증 (16강)
7. 객체지향 구현
- 객체지향 설계 (17강)
8. 애플리케이션 테스트 관리
- 애플리케이션 테스트케이스 설계 (18강)
- 애플리케이션 통합테스트 (19강)
- 애플리케이션 성능개선 (20강)
9. 소프트웨어 유지보수
- 소프트웨어 유지보수 (21강)
10. 제품 소프트웨어 패키징
- 국제표준 제품 품질특성 (22강)
- 제품소프트웨어 패키징 & 메뉴얼 작성 (23강)
1강. 소프트웨어 공학
ㅁ 소프트웨어 공학의 정의
- 품질 높은 소프트웨어를 효율적으로 개발하기 위한 학문
ㅁ 소프트웨어 공학의 3R
- 재공학, 재사용, 역공학
ㅁ 역공학(Reverse engineering)
- 이미 개발된 시스템을 분석하여 요구 분석서, 설계서 등의 문서를 추출하는 작업.
- 역공학은 재공학에 들어감.
- 소스코드를 보고 문서를 추출하는 과정.
ㅁ 재공학(Re-engineering):
- 유지보수의 생산성을 통해 소프트웨어의 위기를 해결하기 위한 방법
- 기존 sw를 폐기하지 않고, 기능을 개선하거나 새로운 소프트웨어로 재활용하는 공법.
- 재공학과 관련 있는건 예방 유지보수(Preventive Maintenance)
- 유지보수는 4가지가 있음. 수정보수 향상보수 예방보수 적응보수
ㅁ 재공학 과정
(1) 분석(Analysis) : 기존 소프트웨어의 명세서를 검토하여 재공학 대상을 선정.
(2) 재구성(Restructuring) : 소프트웨어의 구조를 개선하기 위해 코드를 재구성.
(3) 역공학(Reverse Engineering) : 소프트웨어의 소스코드를 분석하여 설계 수준을 도출. (문서가 없으니 만들자)
(4) 이관(Migration) : 기존 소프트웨어를 다른 운영체제, 프레임워크 등에서 사용할 수 있도록 변환.
ㅁ 재사용(Reuse)
- 이미 개발된 소프트웨어의 전체 또는 일부를 다시 사용하는 것을 의미한다.
ㅁ 재사용의 범위
- 함수와 객체 재사용 : 클래스나 함수 단위로 구현된 소스코드의 재사용
- 컴포넌트 재사용 : 독립적인 소프트웨어 컴포넌트 재사용 (함수와 객체보다 좀 더 큼)
- 애플리케이션 재사용 : 기존 애플리케이션 또는 그 일부를 새로운 소프트웨어 개발에 재사용 (쇼핑몰 만들어줘~)(소프트웨어, 프로그램)
ㅁ 재사용 방법
(1) 합성 중심(Composition Based, 블록 구성)
- 전자 칩과 같은 소프트웨어 부품, 즉 모듈을 만들어서 이를 조합하여 소프트웨어를 완성하는 방법.
(2) 생성 중심(Generation Based, 패턴 구성)
- 추상화된 형태의 명세를 구체화하여 프로그램을 만드는 방법.
ㅁ 소프트웨어 개발 단계
- 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
(1) 계획(Planning)
- 개발할 내용의 명확한 정의
- 개발 범위 결정
- 시스템 특성을 이해하여 비용 및 기간 예측 <- 비용 산정 방법(하, 상, 수), 일정은 wbs, pert/cpm, 임계경로, 간트차트
(2) 요구사항 분석(Requirements Analysis)
- 사용자의 머리 속에 있는걸 끄집어 내서 ~. 개발자한테 이렇게 개발해줘 해야 하니까.
- 고객 어쩌구, 요구사항 어쩌구
(3) 설계(Design)
- ~ 그림을 그린다(모델링). DFD라든지 ERD라든지.
- 시스템의 동작 방식 정의
- 요구사항 분석을 바탕으로 입력자료, 처리내용, 출력자료 등 정의
[설계 구분]
- 시스템 구조 설계 : 모듈 간의 관계와 구조 설계
- 프로그램 설계 : 각 모듈의 처리 절차나 알고리즘 설계
- 사용자 인터페이스 설계 : 사용자가 시스템을 사용하기 위해 보여지는 부분을 설계
(4) 구현(Development)
- 프로그래밍 언어를 사용하여 실제 프로그램 작성
- 코딩(실제로 개발하는 거), 디버깅(버그 잡는거), 단위 테스트 진행(정적 테스트, 동적 테스트. 내가 모듈을 만들었는데 잘 돌아가는지 소스코드를 보면서 정적 테스트를 할 수도 있고, 입력값을 넣어서 출력값이 잘 나오는지 동적 테스트 할 수도 있음. 다 만들고 테스트하는게 아니고 이만큼 만들고 테스트하고 이만큼 만들고 테스트하고 단위단위.)
(5) 테스트(Test) <- 여기까지가 실제 개발 단계
- 구현된 소프트웨어가 요구사항을 만족하는지 검사
- 실행 결과의 정확성 검증 및 평가
- 테스트 계획 및 결과서 작성
- 단위테스트, 통합테스트, 시스템테스트, 인수테스트. 단통시인.
(6) 유지보수(Maintenance)
- 사용 중 발견된 문제 수정, 새로운 기능 추가
- 소프트웨어의 지속적 개선
2강. 소프트웨어 개발 방법론
ㅁ 소프트웨어 개발 방법론 종류 <- 크게 2가지
(1) 구조적 방법론
- 절차지향적인 sw 개발 방법론 (하향식)
- 제한된 구조 안에서 코드를 생성하고 순차적으로 실행하는 방식
[구조적 방법론 기본 개발 과정]
- 요구사항 분석 -> 구조적 분석 -> 구조적 설계 -> 구조적 프로그래밍
[구조적 방법론 구성요소]
- DFD(데이터 흐름도) : 시스템 내의 데이터 흐름을 그래픽으로 표현
- DD(자료사전) : 시스템에서 사용되는 데이터의 세부 사항을 문서화
- Minispec(소단위 명세서) : 개별 모듈의 기능과 로직을 상세하기 기술
- STD(상태전이도) : 시스템의 상태 변화를 시각적으로 표현
(2) 정보공학 방법론 <- 기업 내에 있는걸 만드는 거. "기업 내부에 있는 데이터를 위한 거" 이것만알면됨
- 데이터 중심의 접근 방식
- 기업의 주요 부분을 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합하여 적용하는 방법론
[정보공학 방법론 기본 개발 과정] <- 얘도 걍 계획분석설계구현 이거라는 것만 알면 됨.
- 정보전략계획수립단계 -> 업무영역분석단계 -> 시스템 설계단계 -> 시스템 구축단계
(3) 객체지향 개발 방법론
- 현실 세계의 개체(Entity)를 속성(Attribute)과 매서드(Method)로 표현 (회원 / id, pw / 행동)
- 객체와 클래스 간의 관계를 식별하고 설계 모델로 변환 (상향식)
[특징] <- 개념만 잘 아세요
- 캡슐화 : 객체의 세부 구현을 숨기고 인터페이스만을 제공
- 정보은닉 : 객체 내부의 세부 사항을 외부로부터 숨김
- 상속 : 재사용과 확장성을 위해 상위 클래스의 속성과 메서드를 하위 클래스가 상속
- 다형성 : 하나의 인터페이스가 다양한 형태의 구현을 가질 수 있음
(오버로딩 - 메서드명은 같고 인자다름, 오버라이딩 - 상속받았을 때 자식이 재정의)
- 추상화 : 복잡한 현실 세계를 단순화하여 모델링
(추상화해서 하나를 여러군데서 씀)
[개발과정]
- 분석, 설계, 구현을 객체 중심으로 수행(똑같은데 객체중심)
(4) CBD(Component Based Development) 방법론 <- 회원 컴포넌트, 주문 컴포넌트 등을 가져와서 끼워 맞추는거
- 재사용 가능한 컴포넌트의 개발 또는 상용 컴포넌트를 조합하여 애플리케이션 개발
- 새로운 기능 추가가 용이한 확장성 제공
[특징] <- 특징만 기억하시면 될 거 같아요
- 확장성 : 새로운 컴포넌트 추가 및 기존 컴포넌트 수정 용이
- 생산성 및 품질 향상 : 이미 검증된 컴포넌트 사용으로 신뢰성 높음
- 유지보수 비용 최소화 : 개별 컴포넌트 수정이 전체 시스템에 미치는 영향 최소화
(5) 애자일 방법론 <- 고전 방법론이 변화에 민감하지 못했음. 문서보다 sw.
- 변화에 빠르고 유연하게 대응하는 개발 방식
- 소프트웨어 개발의 민첩성과 효율성 강조
[애자일 선언문] <- 외우는 거 아님. 애자일이 뭔지만 알아두시면 돼요.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 sw를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기를
- 왼쪽에 있는 것들도 가치가 있지만, 오른쪽에 있는 것들에 더 높은 가치를 둔다.
[애자일 방법론의 종류] <- XP와 SCRUM이 가장 중요. 나머지는 이런 종류가 있다.
- XP(eXtreme Programming) : 반복적이고 점진적인 개발을 강조 (의사소통, 단순성, 용기, 피드백, 존중)
- SCRUM : 유연하고 생상적인 프로젝트 관리 방식 (1~4주 정도의 스프린트 단위 안에 sw만들기. 매일 15분 회의)
- FDD(Feature-Driven Development) : 기능 중심의 반복적 개발 방식
- Crystal 방법론 : 프로젝트의 크기와 중요도에 따라 방법론을 조정
- Lean과 ASD는 뭔지 몰라도 됨.
ㅁ 소프트웨어 개발 모델
(1) 폭포수 모델(Waterfall Model) <- 특징 명확히
- 순차적 접근 : 개발 과정이 계획, 분석, 설계, 구현, 테스트, 운영의 순서로 진행된다.
- 단계별 검증 : 각 단계는 이전 단계가 완료된 후에 시작되며, 다음 단계로 넘어가기 전에 검증을 거친다.
- 병행 및 반복 진행의 부재 : 한 번 시작된 단계는 이전 단계로 돌아가거나 병행 진행이 허용되지 않는다.
- 경험 및 성공사례 : 소프트웨어 개발의 오래된 모델로, 다양한 성공 사례가 있다.
- 요구사항 변경의 어려움 : 초기에 설정된 요구사항을 나중에 변경하기 어렵다.
- 단계별 명확성 : 각 단계는 명확한 목표와 산출물을 가진다.
- 고객 피드백의 부족 : 개발 과정 중 고객의 피드백을 적극적으로 받기 어렵다.
- 유연성 부족 : 시장이나 기술의 변화에 빠르게 대응하기 어렵다.
(2) 프로토타이핑 모델(Prototyping Model) <- 시제품 만들고 고객과 계속 의사소통해서 시제품을 완제품으로.
- 고객이 요구하는 주요 기능을 프로토타입으로 먼저 구현하는 모델이다.
- 개발자는 프로토타입을 통해 소프트웨어의 모델을 만들어 요구사항을 명확히 한다.
- 개발된 프로토타입은 폐기되거나 재사용될 수 있다.
[순서] <- 큰 의미 없음
- 계획수립 -> 프로토타입 개발 -> 사용자 평가 -> 구현 -> 인수
[장점]
- 사용자의 요구사항을 충실히 반영할 수 있다.
- 사용자가 비교적 빠른 기간 내에 결과물을 평가할 수 있다.
- 오류를 초기에 발견하고 수정할 수 있다.
- 요구사항 변경이 용이하다.
[단점]
- 최종적으로 더 많은 시간과 비용이 소요될 수 있다.
- 사용자가 프로토타입을 실제 제품으로 오해할 수 있다.
- 문서화 과정이 소홀해질 수 있다.
- 폐기되는 프로토타입에 대한 비용이 발생할 수 있다.
(3) 나선형 모델(Sprial Model) <- 나선형 모델 써라 나올 수 있음.
- 폭포수 모델과 프로토타이핑 모델의 장점을 통합하고, 위험 분석을 추가하여 점증적으로 개발을 진행하는 모델
- 프로젝트 수행 시 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
- 대규모 프로젝트나 위험 부담이 큰 시스템 개발에 적합하다.
[순서] <- 중요
- 계획(및 요구분석) -> 위험분석 -> 개발 -> 사용자(고객) 평가
(4) RAD(Rapid Application Development) 모델
- 매우 빠른 개발 주기를 통해 소프트웨어를 신속하게 제공한다.
- 고급 소프트웨어 개발 도구와 CASE 도구를 활용하여 개발 효율성을 높인다.
(5) V 모형
- 개발의 각 단계에서 검증과 테스트를 중점적으로 진행한다.
- 개발 단계마다 해당하는 테스트 단계가 있어, 체계적인 품질 관리가 가능하다.
- 폭포수 모델인데 각 단계에서 테스트를 하는거임. 요구사항 변경 대응 어려움.
[단계별 테스트 유형] <- 단 통 시 인
- 단위 테스트 : 정적 테스트, 동적 테스트
- 통합 테스트 : 상향식 통합(드라이버-위에 뭐가 없으면), 하향식 통합(스텁-아래에 모듈이 없으면)
- 시스템 테스트 : 기능 테스트(사용자가 요구한 기능이 잘구현됐는지), 비기능 테스트(성능, 보안)
- 인수 테스트 : 알파 테스트(개발자와 사용자), 베타 테스트(사용자만)
(6) 4세대 기법(4th Generation Techniques)
- 요구사항 명세서를 기반으로 소프트웨어 코드를 자동으로 생성한다.
- 4세대 언어(4GL)와 같은 고급 프로그래밍 언어와 도구를 사용한다.
ㅁ 애자일(Agile) 방법론 <- 아래의 내용들이 지문으로 나오면 애자일 방법론을 쓰면 됨
- 신속하고 반복적인 작업을 통해 지속적으로 작동 가능한 소프트웨어를 개발하는 방식이다.
- 작은 구성요소를 빠르게 제공하고, 애자일 개발을 가능하게 하는 다양한 방법론의 집합을 가리킨다.
- 경량(Lightweight) 프로세스라고도 한다.
[애자일 방법론 종류]
(1) XP(eXtreme Programming)
- 문서보다는 코드를 중시하고, 5가지 핵심가치와 12개 실천 항목이 존재
- 개발을 세분화하여 1~3주의 반복으로 개발 진행 <- 스크럼도 그럼. 그래서 큰 특징은 아님.
[XP 5가지 핵심가치] <- 중요
- 의사소통 : 개발자, 관리자, 고객 간의 원활한 의사소통
- 단순성 : 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
- 용기 : 고객의 요구사항 변화에 능동적인 대처
- 피드백 : 의사소통에 따른 즉각적인 피드백
- 존중 : 개발자의 역량을 존중하고 충분한 권한과 권리를 부여
[12가지 실천사항] <- 실기엔 나오기 힘듦. 용어 정도만 기억해두시면 좋아요
- 짝 프로그래밍, 계획 세우기, 테스트 기반 개발, 고객 상주, 지속적인 통합, 코드 개선, 작은 릴리즈, 코딩 표준, 공동 코드 소유, 간단한 디자인, 시스템 메타포어, 작업시간 준수
(2) 스크럼(Scrum)
- 소프트웨어에 포함될 기능, 개선점에 대한 우선순위를 부여
- 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 작성
- 항상 팀 단위로 생각하고, 매일 15분 정도의 회의
[스크럼의 주요 개념]
- 제품 백로그(Product Backlog) : 개발할 제품에 대한 요구사항 목록 <- 어떤 제품을 만들건지
- 스프린트(Sprint) : 반복적인 개발 주기. 1~4주의 짧은 기간을 목표로 설정한다
- 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의
- 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
- 일일 스크럼 회의(Daily Scrum Meeting) : 날마다 진행되는 15분 정도의 미팅
- 실행 가능한 제품 : 스프린트의 결과로써 나오는 실행 가능한 제품 <- 스프린트 단위마다 나옴.
- 제품 책임자, 스크럼 마스터
- 백로그가 먼지만 잘 알아두세요. 백로그 라는건 기능 명세.
제품 백로그는 전체 제품(sw)에 대한 기능 명세.
제품 백로그, 스프린트 백로그 (스프린트 계획 회의에서 나온 만들어야 할 기능들)
(3) 그 외 애자일 방법론 <- 종류만 알면 된다. 중요한건 XP와 스크럼.
- 크리스털, FDD, ASD, 린(Lean)
ㅁ IT 서비스 관리 <- 말그대로 IT서비스 관리할때 이런걸 지켜라
(1) SLM(Service Level Management)
- 서비스 수준을 정량적으로 측정하고, 실적을 평가하여 미흡한 부분을 개선하는 관리 활동
- 서비스 품질의 지속적 개선을 통해 고객 만족도를 높이고, 서비스 제공의 효율성을 개선한다.
- SLM은 SLA에 명시된 기준을 기반으로 서비스 품질을 관리하고 개선한다.
(2) SLA(Service Level Agreement) <- SLM을 하기 위한 명세서.
- 소프트웨어 수요자와 공급자 간에 서비스 수준을 명시적으로 정의한 문서
- 구성 요소 : 업무 목표/범위, 성과 지표, 조정 절차 <- SLA를 기반으로 SLM을 한다. 이렇게만 알아두시면.
(3) ITSM(Information Technology Service Management) <- ITIL을 기반으로 함
- 최종 사용자를 위한 IT 서비스를 구현, 전달, 관리하는 일련의 정책과 관행 <- SLM과 비슷
- 최종 사용자의 요구와 비즈니스 목표에 무합하는 방식으로 IT 서비스를 제공한다.
(4) ITIL(IT Infrastructure Library)
- IT 서비스를 쉽게 제공하고 관리할 수 있는 가이드 또는 프레임워크
- ITSM을 실현하기 위한 도구나 방법을 제공
- IT 서비스 관리의 모범 사례를 포함하여 효과적인 IT 서비스 제공을 지원
3강. 프로젝트 계획
ㅁ 프로젝트 관리 <- 비용, 일정 관리
ㅁ 프로젝트 핵심 관리대상(3P)
- People, Problem, Process
ㅁ PMBOK(Project Management Body of Knowledge)
- PMI(Project Management Institute)에서 제작한 프로젝트 관리 프로세스 및 지식 체계
- PMI에서 만든 프로젝트 관리 방법론.
[단계]
(1) 1단계 : 프로젝트 착수
- 프로젝트의 광범위한 범위를 정하는 단계
(2) 2단계 : 프로젝트 계획
- 프로젝트의 세부 범위를 정의하고, 프로젝트 관리 계획을 만드는 단계
- 비용, 품질, 기간, 사용 가능한 자원이 포함됨.
(3) 3단계 : 프로젝트 실행
- 프로젝트의 개발과 완료가 이루어지는 단계
(4) 4단계 : 프로젝트 통제
- 계획 대비 목표의 진척 상황을 모니터링하고 성과를 측정하는 단계
(5) 5단계 : 프로젝트 종료
- 프로젝트가 요구사항을 만족하는지 검증하고, 고객으로부터 확인받는 단계
ㅁ 개발 비용산정 기법
- 하향식 산정 기법 : 전문가 (판단)기법, 델파이 기법
- 상향식 산정 기법 : 원시 코드 라인 수(LOC, Line Of Code)
- 수학적 산정 기법 : COCOMO 기법, PUTNAM 기법, FP(기능 점수) 기법
ㅁ 하향식 산정 기법(Top-Down)
- 과거 유사 경험을 바탕으로 회의를 통해 전체 프로젝트의 비용을 산정하는 방식
- 전문가 (판단)기법 : 조직 내 경험이 있는 전문가에게 비용 산정을 의뢰
- 델파이 기법 : 여러 전문가의 의견을 종합하여 판단
ㅁ 상향식 산정 기법(Bottom-Up)
- 프로젝트의 세부 작업 단위별로 비용을 산정한 후 이를 합산하여 전체 비용을 계산하는 방식 <- 몰라도 됨.
- 원시 코드 라인 수(LOC, Line Of Code) : 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 중간치(기대치)를 측정 후 예측치를 구하고, 이를 이용해 비용을 산정하는 기법. 추정 LOC : (낙관치 + 비관치 + 중간치X4) / 6
ㅁ 수학적 산정 기법
- COCOMO 기법 : 소프트웨어의 규모를 LOC(Line Of Code) 기반으로 예측하고, 소프트웨어 종류에 따라 비용 산정 공식에 적용하여 비용을 산정하는 모델
[개발유형]
조직형(Organic Mode) : 5만 라인 이하의 프로젝트, 일반 업무용 소프트웨어
반분리형(Semidetached Mode) : 30만 라인 이하의 프로젝트, 운영체제, DBMS 등
내장형(Embedded Mode) : 30만 라인 이상의 프로젝트, 미사일 유도 시스템, 신호기 제어 시스템 등
- PUTNAM 기법 : Rayleigh-Norden 곡선, SLIM이라는 자동화 추정 도구 사용.
- 기능 점수 기법(FP, Function Point) : 소프트웨어의 기능 개수를 기준으로 규모를 측정하는 기법.
ESTIMACS라는 자동화 추정 도구 사용.
데이터 기능(내부논리파일, 외부연계파일)과 트랜잭션 기능(외부입력, 외부출력, 외부조회) <- 내부X
ㅁ 개발 일정 산정
- sw 개발을 위해 필요한 작업을 정의하고, 이들 작업의 우선순위를 설정하여 전체 프로젝트 일정 계획을 수립한다.
[작업 순서] <- 중요
(1) 작업분해(WBS, Work Breakdown Structure)
- 전체 작업을 작은 단위로 분해한다.
(2) CPM 네트워크 작성
- Critical Path Method를 사용하여 작업 순서 및 의존성을 정의한다.
(3) 최소 소요 기간 계산 <- 임계경로(전체 공정 중 가장 오래걸리는 경로). 최대 기간이 최소 소요 기간이 됨.
- 각 작업에 필요한 최소 시간을 계산한다.
(4) 소요 Man-Month(M/M) 및 기간 산정 후 CPM 수정
- 작업에 필요한 인력 및 시간을 계산하여 CPM을 업데이트한다.
(5) 간트 차트(Gantt Chart)로 표현 <- 최종적으로 간트차트가 나옴. 가로막대 형태로 표현
- 프로젝트 일정을 시각적으로 표현한다.
ㅁ Network Chart(PERT/CPM) <- 옛날엔 PERT, CPM을 구분했는데 요즘엔 잘 구분 안하고 합침.
- 일의 전후관계를 고려해서 네트워크 차트를 만듦. PERT/CPM이란 걸 그린다.
- PERT : 불확실한 상황에 적합. 개발기간을 LOC로 예측함. 예측치 : (낙관치 + 비관치 + 중간치X4) / 6
- CPM : 확정적인 상황에 적합. 둘 다 시간 단축이 목적.
- PERT/CPM : 작업의 선/후행 관계를 고려하여 전체 작업의 완료 시간을 결정한다.
- 임계경로(Critical Path) : 프로젝트를 끝내기 위해 필요한 최소 소요 기간(경로상 가장 오래 걸리는 시간)
- 경로 3개가 나옴. 40일, 35일, 35일
- 임계 경로는 여유 기간이 없음. 늦은 착수일도 없음. 다른 경로는 여유 기간이 있음.
- 가장 빠른 착수일은 앞의 작업이 끝나자마자 바로 할 때
- 가장 늦은 착수일은 늦게 착수해도 임계경로에 맞출 수 있는 거. 빠른착수일+여유기간.
ㅁ 간트 차트(Gantt Chart)
- 프로젝트 일정 계획의 시각적 표현
- 일정 관리의 최종 산출물로 사용되며, 프로젝트의 시간 관리에 필수적인 도구
- 이 차트는 바(Bar) 형태로 표현되며 각 업무 또는 활동의 시작과 종료 시점을 그래픽으로 나타낸다.
- 각각의 업무나 활동을 개별적인 바로 표시하며, 바는 해당 업무의 시작과 종료 시점을 타나낸다.
4강. 요구사항 분석
ㅁ 요구사항 분석 <- 요구사항 명세서 나옴.
ㅁ 현행 시스템 분석(플랫폼 기능 분석)
- 플랫폼 : 다양한 응용 프로그램, 서비스 또는 기능이 구축되거나 실행되는 기반 또는 환경
- 플랫폼 기능 : 연결 기능, 비용 감소 기능, 브랜드 신뢰 기능, 커뮤니티 형성 <- 보기 중 골라라 할 수도.
- 플랫폼 종류 : 하드웨어 플랫폼, 소프트웨어 플랫폼, 서비스 플랫폼 <- 거의 안나옴.
- 플랫폼 유형 : 거래 플랫폼(Transaction), 생태계 플랫폼(ecosystem/innovation), 다면 플랫폼(Multi-Sided) <- 종류만.
ㅁCPND(Contents Platform Network Device)
- 컨텐츠를 플랫폼에 맞게 가공하고, 네트워크를 통해 사용자의 단말기로 서비스가 이루어짐을 표현하는 무선 인터넷 서비스의 가치사슬
ㅁ 현행 시스템 분석 <- 다 필요없고 종류만
- 운영체제 분석, 네트워크 분석, DBMS 분석
ㅁ 미들웨어(Middleware) 분석
- 양쪽을 연결하여 데이터를 주고받을 수 있도록 중간에서 매개 역할을 하는 소프트웨어
[미들웨어 종류] <- 많이 나옴. 다음 중 미들웨어의 종류가 아닌 것을 골라라.
- 원격 프로시저 호출(RPC, Remote Procedure Call) : 클라이언트가 원격에서 동작하는 프로시저를 호출
- 메시지 지향 미들웨어(MOM, Message Oriented Middleware) : 메시지는 저장소에 저장, 다른 업무를 지속할 수 있도록 하는 비동기식 미들웨어. 실시간 업문엔 부적합.
- ORB(Object Request Broker) : 객체지향 시스템에서 객체 및 서비스를 요청하고 전송할 수 있도록 지원하는 미들웨어
- DB 접속 미들웨어 : 애플리케이션과 데이터베이스 서버를 연결해 주는 미들웨어
- TP 모니터(Transaction Processing Monitor) <- 트랜잭션은 하나의 일처리 단위. 이걸 관리.
- 웹 애플리케이션 서버(WAS, Web Application Server) <- db와 서로 통신해서 동적인 컨텐츠를 생성하는 플랫폼 제공.
- 엔터프라이즈 서비스 버스(ESB, Enterprise Service Bus) <- 메시지 버스임. 기업들 간 공유하는 데이터를 유연하게 제공.
ㅁ 요구공학 <- 사용자의 머릿속에 있는 걸 끄집어 내야하는데 쉽지 않아서 정리한 학문.
- 소프트웨어의 요구사항을 식별(도출), 분석, 문서화하고 이를 관리하는 과정
[요구사항 개발 프로세스] <- 도분명확
(1) 도출(Elicitation)
- 사용자와 이해관계자들로부터 요구사항을 수집한다.
(2) 분석(Analysis)
- 수집된 요구사항 중에서 실현불가능, 불완전하거나 모호하고, 중복되거나 충돌하는 부분을 식별하여 수정한다.
- 구조적 분석 도구 : DFD(자료 흐름도), Data Dictionary(자료 사전), Mini-Spec(소단위 명세서), STD(상태 전이도), ERD(개체 관계도) <- 이런 것들로 그림을 그림
- 객체지향 분석 도구 : UML(Unified Modeling Language)
- 도메인 분석 : 도메인이란 요구사항의 배경이다. 도메인을 정의하는 것은 배경의 범위를 정하는것이 된다.
(도메인 : 환자관리 - 범위 : 접수, 처방, 청구) (도메인 : 조제 - 범위 : 약 보관, 약 조달)
※ 데이터베이스에서 도메인은 값의 범위.
(3) 명세(Specification)
- 분석된 요구사항은 명세서 형태로 정리한다. <- 문서화
- 정형 명세 기법(수학적 기호, 논리학), 비정형 명세 기법(자연어, 그림-다이어그램)
- 기능 요구사항(어떤 기능을 수행해야 하는지), 비기능 요구사항(성능, 보안, 가용성, 유지보수성)
(4) 확인(Validation)
- 분석가가 요구사항을 이해했는지 확인(Validation), 요구사항 문서가 일관성 있는지 검증(Verification).
ㅁ 요구사항 분석 기법 <- 종류
- 인터뷰(Interview), 브레인스토밍(Brainstorming), 원인-효과 다이어그램(Cause-Effect Diagram), 프로토타이핑(Prototyping), 사용 사례(Use Case), 요구사항 검토(Requirements Review)
ㅁ 요구사항 분석 도구
(1) 요구사항 분석 CASE(Computer Aided Software Engineering) 도구
- 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하는 도구
- 여기서만 쓰이는게 아니고 소프트웨어 개발 전반에 걸쳐 적용된다. (계획분석설계구현테스트유지보수)
- 상위 CASE : 생명 주기 전반부에 사용. 소프트웨어의 계획과 요구분석, 설계 단계를 지원한다.
- 하위 CASE : 생명 주기 후반부에 사용. 코드의 작성과 테스트, 문서화하는 과정을 지원한다.
- 통합 CASE : 생병 주기 전체 과정 지원. <- 이건 잘 안나옴.
(2) HIPO(Hierarchical Input Process Output) <- HIPO 차트라는 그림을 그림.
- 하향식 소프트웨어 개발을 위한 문서화 도구(구조적 방법론)
- 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 계층구조를 표현한 도표
- 분석 및 설계 도구로 사용된다.
- 체계적인 문서관리에 효율적이다.
- 기능과 자료의 의존관계를 명시할 수 있다.
[HIPO Chart 종류] <- 잘나옴.
ㅇ 가시적 도표(Visual Table of Content)
- 시스템의 전체적인 기능과 흐름을 보여주는 Tree(계층) 구조
- 가시적 도표에는 입력, 처리, 출력 없음
ㅇ 총체적 도표(Overview Diagram)
- 프로그램을 구성하는 기능을 기술한 것
- 입력, 처리, 출력에 대한 전반적인 정보 제공 <- 여기부터 입력, 처리, 출력 나옴.
ㅇ 세부적 도표(Detail Diagram)
- 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
ㅁ 요구사항 분석 모델링
- 모델링 : 복잡한 시스템을 이해하고 효과적으로 개발하기 위해 간단한 모델로 표현하는 과정. <- 그림(도식화)
[모델링 구분] <- 넘어가려다 그냥 읽음. 아예 의미 없진 않나 봄.
ㅇ 기능적 모델링
- 사용자 관점에서 시스템의 기능을 표현
- 사용 사례 다이어그램, 액티비티 다이어그램 등
ㅇ 정적 모델링
- 시스템의 구조를 클래스 단위로 표현
- 클래스 다이어그램
ㅇ 동적 모델링
- 시스템의 상호작용 및 동작을 표현
- 순서 다이어그램, 상태 다이어그램, 커뮤니케이션 다이어그램 등
[분석 모델의 종류]
ㅇ 구조적 분석 모델
- 시스템의 프로세스와 데이터 흐름을 중심으로 분석
ㅇ 객체지향 분석 모델
- 객체와 클래스를 중심으로 시스템을 분석
ㅇ 정보공학 분석 모델(데이터), 정형화 분석 모델(수학적) <- X
ㅁ 구조적 분석 모델
- 하향식 기능 분해 기법을 사용한다.
- 도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 분석 기법.
[구조적 분석 도구]
ㅇ 자료 흐름도(DFD, Data Flow Diagram) <- 객체지향에서도 쓸 수 있음.
- 시스템 내에서 자료가 어떻게 이동하고 처리되는지를 도형으로 나타내는 모델링 도구
- 자료 흐름 그래프 또는 버블 차트라고도 함
- 자료흐름도 구성요소 <- 기호 나옴
ㅇ 자료사전(DD, Data Dictionary)
- 자료 흐름도(DFD)에 기술된 모든 자료들에 대해 자세한 정의와 설명을 제공하는 중요한 도구이다.
- 기호 잘 나옴
- 자료사전 예시 나오면 아래로 쓸 수 있어야 함.
ㅇ 소단위 명세서(Mini-Specification)
- 자료 흐름도에서 각 처리가 수행하는 업무를 상세하게 작성하는 문서
- 프로세스 명세서라고도 한다.
- 처리 과정에서 어떤 일이 수행되는지 정의하고, 구체적인 작업 단계와 조건을 명시한다.
ㅇ 개체 관계도(ERD, Entity Relationship Diagram) <- db 표현할 때 많이 씀
- 시스템에서 처리되는 구조인 개체와 그 속성, 개체 간의 관계를 도식화하여 모델링하는 도구
ㅇ 상태 전이도(STD, State Transition Diagram)
- 시스템의 상태와 상태 간의 전이를 모델화하는 도구
- 시스템의 상태 변화를 보여준다.
ㅁ 객체지향 분석 모델
- 사용자 요구사항을 객체지향적 관점에서 분석하고 모델링한다.
- 관련된 모든 클래스, 그 속성과 연산, 그리고 객체 간의 관계를 포함한다.
[객체지향 분석 방법론] <- 중요
ㅇ Rumbaugh(럼바우) 방법
- 분석활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행. (순서 중요)
(1) 객체 모델링(Object Modeling) : 객체 다이어그램을 통해 시스템의 객체, 속성, 연산, 관계를 표현
(2) 동적 모델링(Dynamic Modeling) : 상태 다이어그램을 사용하여 시간에 따른 객체의 행동과 상호작용을 표현
(3) 기능 모델링(Functional Modeling) : DFD를 이용해 데이터 흐름과 처리 과정을 표현
ㅇ Booch(부치) 방법
- 미시적 및 거시적 개발 프로세스를 모두 사용
ㅇ Jacobson 방법
- Use case를 중심으로 한 분석 방법을 사용
ㅇ Coad와 Yourdon 방법
- E-R 다이어그램을 사용하여 객체의 행위를 모델링
ㅇ Wirfs-Brock 방법
- 분석과 설계의 구분 없이 연속적으로 작업을 수행
5강. 소프트웨어 설계의 기본원칙
ㅁ 분석에서 요구공학을 적용해서 사람들 머릿 속을 명세서로 만들고, 설계에서 모델링을 수행.
분석과 설계의 구분은 사실 없다. 모델링은 분석에서도 할 수 있고 설계에서도 할 수 있다.
ㅁ 소프트웨어 설계
요구사항 명세서 밑줄. 분석단계에서 나옴. 구체적인 설계서 밑줄. 그림을 그림. 외우는거 아님.
ㅁ 설계의 종류
상위 하위. case도구와 비슷. 상위는 전반적인거. 하위는 구현. 종류 외웡.
아키텍처는 전체적인 구조를 말함. 아키텍처는 ㄷ개로나눌 수 있음. 소프트 아키텍처 시스템 아키텍처. 소프트 아키텍처의 경우 전체적인 구조를 말하고, 시스템 아키텍처는 너네 시스템 어떻게 배치할거냐. 하드웨어 등.
데이터베이스 설계라고 보면 됨.
ㅁ 설계의 원리
분할과 정복. 설계에섬나 쓰이는거 아님. 구현에서도 쓰임.
추상화 기법. 종류 외우어야. 과정데이터제어. 추상화는 공통된 성질을 모아놓은 거다.
단계적 분해. 분할과정복과 비슷한데 설계에서만 쓰인다.
정보은닉. 외부에서 자료를 함부로 가져다 쓸 수 없게 한거. private으로 선언하고. public으로 get set 함수 만ㄷ름.
ㅁ 설계 모델링 원칙
- 너무 당연한거니까 안외우셔도 됨.
ㅁ 설계 모델링 유형 <- 2가지.
ㅁ 소프트웨어 설계 절차 및 유형
얘같은건 모르셔도 되ㅣ요.
근데 또 순서는 말하네.
설명은 필요없음. 설계절차는 큰 의미 없음.
협약에 의한 설계는 나올 수 있음. 선 결 불도.
설꼐를 할 때 협약에 의한 설계를 해야됨. 고객이 말한대로 해야한다는 거.
6강. 소프트웨어 아키텍처
ㅁ 소프트웨어 아키텍처란 이 소프트웨어의 전반적인 구조를 말함. 그 안에 시스템 아키텍처가 포함됨.
시스템 아키텍처는 물리적인 서버들의 구성이다.
ㅁ 개념 전반적인 구조란건ㅅ만 알면됨.
ㅁ 특징. 이것도 그냥. 관점 모형 관점이 다 다르니까 관점 모형을 제공해줘야한다. 관점에 따라 달리 표현해야한다.
특징 종류는 기억.
ㅁ 구성요소. 설명말고 종류 기억.
ㅁ 4+1
말그대로 뷰가 4개가 있다. 4개의 각각의 관점이 있고 이걸 아우를 수 있는 1개읭 관점이 있다. 가운데 동그라미가 유즈케이스 뷰라고 사용자 뷰를 얘기함.
프로세스 뷰. 2째줄은 그냥 읽어보심되는거고
배치 뷰. 여기서 시스템 아키텍처가 된다.
유즈케이스 뷰. 사용자 관점. 이게 전반적인 뷰들을 주도한다.
ㅁ 소프트웨어 아키텍처 품질속성
iso iec 911.6 만 제대로 알면 됨. 기신사효유이. 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성.
ㅁ 소프트웨어 아키텍처 패턴 . 옛날에 만든거 재활용한다.
개념 안나옴.
ㅁ 패턴의 중요성. 종류만.
ㅁ 패턴 종류.
계층화 패턴. 일긱는 하고. 이런 종류가 있다.
클라이언트-서버 패턴. 우리가 웹프로그램이할때가장많이씀. 클라이언트 답을 요청하는거. 서버 답을 주는 거. 네이버는 서버가 되고 네이버를 이용하느 ㄴ사람들이 클라이언트가 됨.
파이프필터패턴. 여기 일이 끝나면 당므을 ㅗ넘기고 다음을 ㅗ넘기고. 적용 필요 없다.
p2p. 컴퓨터와 컴퓨터가 이어지는거.
이벤트 버스 패턴. 카톡 공지사항. 어떤 이벤트를 발생시키면 다 수신하는거.
mvc. 모델은 db와 연관되어있음. 그래서 모델은 데이터들이 들어있느 ㄴ공간.
뷰는 사용자 화면단. 컨트롤러는 처리의 역할. 뷰->컨트롤러->모델->컨트로러->뷰
괄호안 다 밑줄. 대부분의 개발에서 mvc 씀. 뷰는 화면단 컨트롤러는 처리단 모델은 데이터.
블랙보드 패턴. 기능으 ㄴ상관없고. 적용은 밑줄 .적용이 뭐냐 하면 블랙보드 패턴.
7강. UML
ㅁ UML은 객체지향 언어에서 사용. 상향식.
ㅁ uml. 분석 설계하면서 그림을 그리는 언어.
모델링 언어 밑줄
ㅁ uml 특징. 기억해야됨.
가명구문 이 4가지 특징 알아야됨. 설며ㅓㅇ은 됐고 종류.
ㅁ UML 구성요소
UML의 구성요소 3가지 : 사물, 관계, 다이어그램
사물하고 사물이 관계를 맺게 되고, 이런 사물과 사물의 관계를 다이어그램으로 표현.
구조사물. 회원이다. 회원이라는 구조. 상품
행동사물. 행위들. 뭔가. 바뀌는 것들
그룹사물. 연과닝ㅆ는 것들을 묶어놓은거
주해사물. 주석같은거.
관계. 잘나옴.
1. 일반화관계 상속임. 일반화 실체화 둘 다 상속받는거 맞음. 일반화는 부모도 인스턴스 만들 수 있음. '상속'만 나오면 일반화. 실체화도 상속을 받는데 얘는 추상화된걸 받음. '구현', '오버라이딩'은 실체화관계.
3. 의존관계. 매우 짧은 시간만. ㅍ ㅣㄹ요할때만 쓰는거. 연관관계는 긴밀하고.
4. 실체화관계. 상위에 있는걸 구현하는거. 두번재줄. 한 객체가 아래꺼고 다른객체가 위에 꺼
5. 집약관계. 불고기 먹는ㄴ다고 저거 다 안사라짐. 책상은 뿌수면 다 사라짐.
ㅁ 다이어그램
다이어그램은 2가지로 나뉨. 구조 다이어그램과 행위 다이어그램.
구조 다이어그램은 회원이라 하면, 회원 안에 들어가있는 속성들, id, pw, 닉네임 등이 들어있는 구조를 나타내는 거고, 행위 다이어그램은 이 안에 있는 것들이 어떻게 변경이 되는지. 기능들이 어떻게 동작하는지, 상태값이 어떻게 바뀌는지. 시간의 흐름에 따라 어떻게 변경이되는지. 이런것들을 나타냄.
- 구조 다이어그램
클래스의 관계를 표현, 객체의 관계를 표현, 둘이 다른게 뭐냐. 구조는 하나지만 객체는 여럿이다. user 클래스를 만들어 놓고 u1, u2해서 여러개 쓰는거.
- 컴포넌트 다이어그램. 잘 안나옴.
- 복합체 구조. 잘 안나옴. 이것까진~.
- 패키지 다이어그램. 얜 관련성 있는것들을 묶어놓은거.
- 행위 다이어그램 유순커상활상타
유스케이스는 기능들을 말하는 거에요.
시간순서 밑줄.
객체간의관계와통신에중점 밑줄.
상태. 반응 동그라미.
uml 다이어그램, 디자인패턴, 국제표준 이런거는 시험 전에 정리해서 특징들만 정확히 알고 가심ㄴ 될거같아요.
시험용으로만 대비해주세요. 실무에서 필없. 실제론 유스케이스다이어그램이랑 클래스다이어그램만 거의 씀.
ㅁ 주요 다이어그램
- 클래스 다이어그램.
첫줄. 뭔말이냐. 속성은 회원 안에 id, pw, 닉네임 등이고 행동은 속성을 바꿀 수 있는 getID, setID이런거
속성, 행동 밑줄.
실제로 그림을 그려라 나오진 않음.
접근제한자는 나올 수 있음. 표기법 알아주세요.
- 유스케이스 다이어그램 관계들 나올수있으니 꼭 기억.
기능들을 명세하는거. 첫줄 몰라도 됨. 둘째 셋째 기능 밑줄.
<< 길러멧기호라함
extends 아님.
일반화관계. 여기도 상속이라 보심 돼요.
시퀀스다이어그래. 시간의흐름부터 쭉밑줄.
객체와 생명선. 이 객체의 수명. 얼마나 이어질지.
메시지의 표현. 정처기에서 이거까진 안나와요. 다이어그램의 종류와 특징들만.
8강. UI설계
ㅁ 이번 시간에는 설계쪽에서 화면설계를 하는 UI설계. 여러분이 보는 화면이 UI. 내가 보는 화면.
ㅁ UX는 사용자의 경험을 바탕으로 더 편리하세 디자인 하는걸 UX 디자인이라 함.
그걸 사용자에게 제공하는게 UI. UX는 기획자, 디자이너가 하는거.
ㅁ UI 개념
상호작용ㅇ르 가능하게 하는 밑줄.
둘째줄 외우는거아님.
셋째줄 쉽고부터 밑줄 .
넷째줄 외우는거 아님. 1~4 다 외우는거 아님. 이런게 뭐냐 햇을때 UI쓰면 됨.
ㅁ UX개념
모든것 밑줄. 편리한부터 밑줄.
ㅁ UI 유형 얘도 ㅏㄱ끔가다 나옴
CLI=CUI
ㅁ 요구사항은 기능 요구사항과 비기능 요구사하이 있음. 시험나왔었음.
ㅁ UI설계절차 외우는거아님. 예도 계분설구테유니까. 실기에서 나오기 힘듦.
1234 스킵.
5. html5는 HTML의 다음버전. 구조를 담당. CSS는 디자인 담당, JavaScript 동적인 효과를 낸다. 배너 휙휙 돌아가는거. 앞 둘은 정적(프론트엔드)
위 세개 밑줄.
반응형 디자인=화면크기에 반응하는거. 창 크기를 작게하면 구글 검색창이 그 화면 비율에 맞게 배치가 바뀜. 화면 크기에 반응한거. 적응형 디자인은 pc로 들어가면 늘리든 줄이든 똑같은 화면. 모바일은 모바일 화면. 두개 개발. 반응형은 무거워서 싫어.
ㅁ UI 설계 원칙 매우 중요
직관성, 유효성, 학습성, 유연성 너무너무 잘나옴.
ㅁ UI 설계 도구
- 와이어프레임. 손으로 그림을 그린다 해서 손그림.
초기설계도구밑줄. 러프라 보면 됨.
- 스토리보드sb. PPT로 함. 왼쪽엔 배치, 오른쪽엔 번호별로 설명.
- 프로토타입. 시제품. 어느정도 동작을 ㅏㅎ는거. 화면만 봐서는 답답하니까. 대략적으로 이런 동작.
- 목업. 정적디자인밑줄. 와이어프레임보다 구체적이며 정적디자인 하면 목업이라 알아두심 돼요.
- 유스케이스. 첫째줄. 기능위주.
다음중 UI설계도구에 해당하는 것들을 보기에서 차장쓰시오. 나올수있음. 종류들 기억.
ㅁ 감성공학
출제범위에 있긴한데 정처기에 나올만한 건 아님.
인간의 내면에 있는걸 끄집어내서 제품화시키는거. 내가 이런걸만들고싶어하는걸 제품화.
요소화 형상화 구현 생산. 두번 말하긴 했는데 나올만한 내용은 아님.
문화적감성. 메이드인차이나네?
1류. 제품에대한 이미지를 분석 밑줄. 이쁘게 만든느거죠.
2류는 문화적 감성. 3류는 정량화.
9강. UI 구현
ㅁ 레이아웃 개념
설명 이게 나오는건 아니고
작성방법.
설명은 필요없고 DIV, SPAN, TABLE을 이용한다.
시멘틱 태그. 검색에 잘 노출되려고 잘 긁어갈 수 있게 정리해놓은거. 헤더, 섹션 이렇게 나눠서 가져감.
ㅁ HTML5
구조에요.
마크업 언어(markup 言語, markup language)는 태그 등을 이용하여 문서나 데이터의 구조를 명기하는 언어의 한 가지이다. 구조 동그라미. 마크업 밑줄. 구조를 담당한다 뜨면 HTML쓸수있어ㅑㅇ함.
그래픽. 진짜그림그리는거.
HTML5 특징. 근데 이거까지 시험에 나올 내용은 아닌거같아요.
시멘틱 요소.
잘 긁어가려고 하는 거임. 검색의 효율성을 위해 하는거.
INPUT 요소 실무들에서도 알아두면 좋을거같아서 가지고 와봤어요.
ㅁ CSS
디자인 분리. 첫째줄만.
CSS3. CSS라는 것만알면됨. 둘째줄 셋째줄도 몰라도 됨. CSS라는건 디자인적 요소를 담고있다 이것만.
ㅁ 자바스크립트
자바와는 완전 다른 언어임.
웹브라우저. 파폭 크롬 웨일 다 됨. 서버에서도 됨.
ㅁ프레임워크
종류만 알아두심 되요.
싱글페이지어플리케이션 사이트 변경없이 ㄱ거기서 다 되는거.
아작스는 프레임웤은 아니에요 .예전부터 브라우저가 가지고 있는 통신기능.
동기라는 거는 내가 어떤 값을 요청하면 쟤가 답해줄때까지 난 아무것도 못하는거.
하얀페이지 로딩중은 동기적인거. 아작스 매우 중요 셤 여러번나옴
ㅁ UI 관련 용어
시험에 나올만한 것들은 아닌데 좀 실무에서 많이 써서 기억해두시면 좋을거같아요.
웹표준을 지키지 않으면 어떤 브라우저에선 동작을 하지 않음.
웹 접근성. 첫재줄만알면됨.
반응형웹. 크기에 맞춰 밑줄. 이것도 첫줄만.
인포그래픽. ? 누르면 정보창나옴.
내비게이션. 이런것들은 나올것들은 아니고. 내비게이션 자체가.
아코디언. 1 1-1 1-2 1-3 2 3 4 여기서 2누르면 1-아래것들이 다 접힘
입력필드. 이런것들은 나올거 아니고.
썸네일. 단순히 크기ㅡ WITDH와 HIEGIHT만 줄일게 아니라 용량까지 줄이는거.
레이블. ㅇ 남 ㅇ 여 여기서 레이블 안주면 꼭 동그라미 눌러야 함. 레이블 주면 글자 눌러도 체크됨.
이런것들은 나올 수 있겠죠. 대체 텍스트 웹 접근성 웹 호환성 웹 표준 플레이스 홀더라든지.
반응형 웹, 아코디언, 플레이스홀더 이런건 시험에 나오진 않음.
10강. 개발 환경 구축
ㅁ 어떤 환경을 이용해서 어떻게 개발을 하는지.
ㅁ 서버 환경 구축
개발을 할거면 환경을 구축해야 함. 개발자의 클라이언트 환경과 서버의 환경을 구축해야 함.
웹서버. 정적인거 담당. 자바스크립트는 동적인데 왜 여깄냐. 화면에 동적인걸 주는거지 이건 파일이다. 파일은 안 변함. 파일을 클라이언트에서 내려받고 클라이언트에서 변경이 되는거임. 2번째줄 필요없다ㅣ. 3번째 종류도 나올 수 있다. 다밑줄.( 파일을 보내줌. 이미지나 CSS 자바스크립트 등 파일.)
와스. 동적인거. 다 했음. 종류도. (DB와 연동해서 DB의 내용을 가지고 와서 사용자가 원하는 내용을 보내주는 역할 수행)
데이터베이스서버. 데이터를 모아놓는 서버.
로드밸런서. l4 장비. 로드밸런싱 역할을 수행함. 사용자들이 막 들어왓을때 어떤 서버로 분산시킬거냐가 로드밸런싱장비.
CDN. 컨텐츠를 분산배치한거.
ㅁ 시스템 아키텍처 고려사항
- 방금 여러가지 배치한게 시스템 아키텍처. 이걸 그림으로 그리면 시스템 아키텍처가 됨.
접근성인 ㅏ가용서이나 비슷한 말.
ㅁ 개발 소프트웨어 환경
개발 소프트웨어라는건 시스템 소프트웨어가 있고 응용 소프트웨어가 있음.
JMV. 윈도우 리눅스 유닉스 각각에 맞게 개발하지 말고 JAVA하나로 만들고 윈도우, 리눅스, ㄱ유닋에서 다 돌아가게 만들자. 2,3은 걍 일겅보셈.
웁서버. 웹서버도 사실 프로그램임. 아까 전의 웹서버는 웹서버 프로그램을 깐 하드웨어 컴퓨터가 되는 거고.
와스. 이것도 프로그램임. 와스 이 프로그램들을 설치한걸복 ㅗ 와스서버라고 하는 거임.
참고. 미들웨어 종류에 웹서버는 안들어감. 7가지는 알아야 됨. 시험- 웹서버 미들웨어로 보면 안됨.
- 요구사항 관리도구
고객의 요구사항을 머릿속에만 둠녀 잊어버리니까 그런것들을 적어놓은 게시판이다. 정말로.
2,3줄은 걍읽어보심되고. 요구사항 관리도구라는게 있다.
- 구현도구 .IDE 통합개발환경. 개발 에러체크 디비도보고 테스트도 하고.
- 테스트도구. 단통시인 하는거임.
- 형상관리 도구. 이건 너무너무 중요. 말 그대로 형상을 관리함. 내가 처음 만든건 A 형상 그 다음 만든건 A' A'' 버전업. 형상관리는 변경관리 버전관리를 다 포함함.변경, 버전별 밑줄
GIT은 분산 형상관리도구.
- 협업 도구. 이것도 너무 많아.
- 배포 도구. 내가 만든걸 보내주는거.
ㅁ IDE 도구의 개념
첫줄만 알면 됨
IDE 도구의 기능 이것도 읽어보심 되는거지 외울 필요 없어요.
IDE 도구의 종류. 종류만 알아두시면 돼요.
고려사항 종류만 알아두심 되러같아요.
ㅁ 협업 도구
협엄하느 ㄴ도구다. 개념은 다 읽어보세요.
SAAS. IAAS 장비를 지원해주는거 PAAS 개발하는 환경을 지원해주는거 SAAS 소프트웨어를 빌려쓰는거 구글 독스
내컴터에 엑셀없지만 구글웹으로 빌려쓰는거.
협업도구의 기능. 이것도 그냥 읽어보심되는거지 외울건없으ㅏㅁ.
ㅁ 협업도구의 분ㄹ 이것도 별 의미없어요. 음 종류만 외우면 될듯.
ㅁ 도입 프로세스 그냥 종류만 아렴ㄴ 될듯?
ㅁ 형상롼리 도구 너무너무 중요
여러 개발자가 하나으 ㅣ소스코드를 가지고 수정하고 올리고 그러기 때문에. 소스코드뿐만 아니라 문서도 형상관리 해줘야 함. 개념 첫줄은 알아야 함. 서술형 나올 수도.
- 필요성. 읽어보면 되는거지 외울 내용은 아니에요 .
- 변경/버전/형상. 변경이 제일 작은거. 그래서 형상관리는 변경관리와 버전관리를 다 포함함.
- 형상관리 대상. 돈 빼고 모든 것들. 이건 외우는게 아님.
- 형산관리 절차. 이거 너무 중요. 식통감기.
형상통제. 젱리 많이 나왔음 형상통제를 쓰시오? 형상통제에 대해 쓰시오?
후자인듯. 변경사항 요청이 오게되면 형상통제이ㅜ원회(CCB)의 승인을 통해 현재의 기준선에 반영한다.
ㅁ 버전관리도구 이제 좀 작은거 형상관리보다. 깃이라던지 CVS SVN
클라이언트/서버 방식은. 중앙집중식
종류만 알아두심 된다. 음. RCS SCCS도 외우어야하나.
CLEAR CASE부터는 이런것들이 있다 만 알면 됨. 종류만. 실제로 나오는건 CVS SVN GIT 이 세가지 가많이 나온다. 리누스 토발즈도 밑줄은 쳤음.
RCS 얘도 나올 내용은 아님. 종류만.
- 버전 관리 주요 용어
임포트. 최초 한번.
커밋=체크인
애드는 추가한거고 커밋은 수정.
업데이트. 내가 임 ㅣ체크아웃 받았는데 다른사람이 애드, 커밋한걸 받음.
체크아웃. 대빵 개발자가 올린걸 처음 한번 받는거.
머지. 파일을 합칠때도 쓴다.
ㅁ 빌드
빌드는 뭔갈 묶는거에요. 묶어가지고 사용자에게 배포하려고.
- 빌드 자동화 프로세스 <- 우리가 개발을해서 REPOSITORY에다가 모으는걸 지속적인 토압이라 함
그리고 이걸 사용자가 쓸수있게 계속 보내주는걸 지속적인 배포러ㅏ고함.
형상관리 서버에다가 지속적인 통합을 함. 개발자들이 수정한 것들을 지속적으로 통합.
그리고 CI서버가 형산관리서버에 ㅣㅇㅆ는 솟흐코드들을 긁어감.
빌드스크립트는 설명서임. 형상관리 서버에 있는 소스코드들을 어떻게 배치할건지, 외부 라이브러리는 어떤걸 썼는지. CI서버가 설명서를 보고 묶어요. 묶ㄷ어서 이걸 테스트 서버에도 보내고 실 서버에도 보내고 여기저기 보냄. 이 보내는걸 자동으로 해주는게 빌드 자동화 도구.
2)테스트 뭐 이런것들을 한다
(4) 빌드 자동화 도구 종류 가끔 가다 나옴
MAKE 첫줄만 읽음. 이런게 있다.
ANT XML의 설명서를 사용한다. 다 그냥 읽음.
MAVEN 다 읽음. 마지막은 거의 스킵.
젠킨스 자바 기반.
GRADLE. 이게 나와야 돼. 안드로이드 앱 개발뿐만 아니라 밑줄. 첫줄도 다 밑줄. 물론 다른데도 많이 쓰이지만 안드로이드 앱 개발에 주로 쓰인다.
11강. 개발 프레임워크
ㅁ 얘는 너무너무 중요해요. 맨땅에 해당하는게 아니라 기본적인 틀을 반제품 형태로 받아서 비즈니스 로직을 끼워맞추기 시작한거.
ㅁ 프레임 워크의 개념
- 첫줄. 프레임워크의 개념 하면 '아키텍처를 일반화하여 제공하는' 이거 빼고 쓰면 됨. 구성요소를 모아놓은 반제품 형태~
두세줄은 그냥 한번 읽어보심 되요.
- 특징. 다형성은 오버로딩 ㄹ오버라이딩 두가지가 있죠.
특징만 알아두세요.
ㅁ 프레임워크의 구분
-ORM 프레임워크. 종류만 알아두시면 돼요. 이거 종류 다 외워야되나봐.
-프론트엔드 프레임워크. 기본적인 CSS틀을 제공해주는거.
프레임워크는 구분해서 나오진 않으니까. 자바 프레임웤이 뭐고 자바스크립트 프레임워크가 뭐고 구분해서 출제가 된 적은 없음. 이런 프레임웤들이 있군 ㅏ정도만 알아두심 될거같아요. 전자정부 표준프레임웤의 기반이 된게 스프링임.
프론트엔드프렝미워크 3개말하면서 뭐 이런것들이 있구나 이렇게만 알아주세요.
ㅁ 라이브러리 기능, 3줄.구조 밑줄.
ㅁ API
프레임워크(전체적 구조)와 라이브러리(특정 기능)를 사용해서 API 형태로 개발을 함.
프레임워크와 라이브러리는 우리가 특정 언어로 만듦. 자바든 C든. API 형태로 만듦. 이유는?
이 API를 가지고 다른데서 이 데이터들을 사용할 수가 있다.
외부에서 이걸 호출해서 쓰려고. 요즘에느 ㄴ이런식으로 개발을 많이 함.
요즘 개발이 백엔드 프론트엔드 나뉘어졌기 때문에. 배겡ㄴ드는 화면을 손도 안대. 프론트엔드 개발자가 호출해서 데이터베이스에서 뭘 가져가서 화면에 뿌려주는거. 오 ㅐ이렇게 홰놨냐. 여기저기서 얘를 이용하라고.
풀스택개발은 프론트엔드백엔드 다 하는거같고. 자기는 API개발보다 풀스택 개발이 좋대.
풀스택형태로 개발을 했으면 다른데서 가져다 쓸 수 없음.
API의 특징은 그냥 한번 읽어보심 되고. API가 뭐다 API의 특징만 정확ㅎ ㅣ알고 계시면 돼요.
12강. 모듈 구현
ㅁ 개념
독립적 밑줄. 모듈의 독립성이 높아야 다른데서도 쓸 수 있음. 소프트웨어 공학의 목적이 재사용 재공학 역공학 이잫ㄴ아요.
-단위모듈수현시장점
그냥 읽어보시는거지 외우는거 아니에요.
-효과적인 모듈화
독립성 밑줄.
모듈은 하나의 기능을 수행하는게 이상적이고, 독립성이 높아야 한다.
독립성이 높기 위해서 결합도 응집도. 그리고 팬인 팬아웃.
나머진 그냥 읽어보면 됨.
(4) 전에 설계의 원칙하고 똑같음.
종류만 앎녀 됨.
ㅁ 결합도 유형
자 - 어떤 모듈을 호출할 때 값만 전달. 스 - 갑싱 아니라 자료 구조(배열, 포인터) 이런걸 전달. 제 = 제어 요소가 전달됨. 함수를 호출할 때 if(a)이런거. 외- 외부에 있는 변수 사용 공 - 전역변수를 이용할 때 내용 - 스파게티소스처럼 얽히섥힌거.
자 - b(x,y)에 1, 2를 줘서 그 함수 안의 연산 후 값만 전달
스 - b(*x,*y)해서 주소값을 받는다. b를 호출할때 b(&a, &b)이렇게 a와 b의 주속밧을 전달.
그래서 이런 결합도는 이론적인거 말고 소스코드를 갖다대면 기가막힌 문제가 되는데 그렇겐 안나오고 있음.
그래도 모르니까. 자료구조 배열 구조체 주소값 이런게 전달될 때 스탬프 결합도라 함
제 - b라는 함수 b(x, y)를 b(1, 2)해서 호출할 때 if(x>1) 어쩌구 else 이렇게 제어요소.
외 - 외부변수 사용. 익스턴 하면 외부변수로 선언이다. 외부결합도는 문제 내기가 쉽지 않음. 아마 소스코드 얘기하는듯.
공 - 전역변수. 위에 int a = 10; 하고 각 메소드별?로 a 쓸대
응집도.
통 - 동일한 입력고 ㅏ출력. 이거만 알면 돼요.
영어로도 알아두셔야 해요. 특징을 설명하고 해당하는 응집도나 결합도를 영어로 쓰라고 출제가 됨.
= 응집도나 결ㄹ합도 용어 설명 쓰라고 할 수도. 세부 응집, 결합도는?
ㅁ 공통모듈 구현수서
나올만한 내용은 아님. 자바에 특화된거라.
ㅁ 구현요소도 정처기에 나올건아님
dto나 vo는 데이터 덩어리라 보심 됨.
dao는 sql문을 호출할수 있는거
ㅁ 공통모듈구현요소
설명은 안나옴.
구현요소들 종류도.. 모르셔도 될거같아요.
ㅁ 공통모듈구현
요것도 마찬가지. 그냥 한번 보시면 되는건데.
ㅁ annotation 개념은 나올수있음.
종류. 설명은 이런게 있다. 이게 어노테이션이다. 주석이다.
어노테이션은 종류들만 기억해두시면 될거같아요.
13강. 서버프로그램 구현
ㅁ 요즘 개발은 F/E 개발, B/E 개발 나뉘어서 진행함. 예전에는 풀스택 개발이었는데 바뀜.
백엔드에선 무슨 일을 하느냐, WAS에 프로그램을 올리면 WAS랑 DB랑 같이 노는데 이 WAS에 올리는 것은 API 형태로 올린다. 프레임워크, 라이브러리를 이용해서 API형태로 만든다. 백엔드 개발자가 DB 연동해서 API 형태로 만들어 놓으면, 프론트엔드 개발자가 여깄는 것들을 호출해서(AJAX, 자바스크립트) 화면을 설계함.
요즘 개발이 이런식으로 됨. 보통 서버프로그램 구현이라 하면 백엔드 개발자가 하는 걸 말함.
ㅁ 업무 프로세스 개념, 구성요소. 나오는건 아님. 구성요소도 필기에서나 나올거.
ㅁ 서버 프로그램 구현
1줄. 실기에서 나올건 아님. 읽어보심 된다.
구현절차 그림도. 별로. MVC만 잘 알아두면 됨.
이렇게 분리를 한 거는 각각의 역할에서 내가 손대는 소스코드는 여기야 구분하려고 만든게 MVC 모델.
VIEW단은 보통 HTML 태그로 만듦. CONTROLLER는 DB를 호출. 그래서 어떤 값을 가져오거나 입력. 여기서 더하기빼기곱하기 등 함. 근데 이때 MODEL을 이용한다. MODEL을 이용해서 컨트롤러 단에서 데이터 덩어리를 만듦.
그리고 VIEW단. HTML을 긁어와가지고 그 위치에 맞는 데이터들을 딱딱 끼워넣는거야. 그리고 완성된 HTML(소스코드)를 사용자들에게 전달하는 과정이다.
ㅁ 구현요소. DTO VO 둘다 비슷하다. 데이터 덩어리다. 데이터를 담아둔 컨테이너다.
DAO.
구현요소들 이건 자바 스프링 개발할때나 필요한거지 지금 정처기에서 달달 외우실 필요는 없다.
ㅁ 프리젠테이션 계층. 뷰단이라고 보시면 돼요.
여러분이 보는 화면이 프리젠테이션 계층이 되는거다.
제어계층. 어떤 요청이 들어왔을 때 어디로 보낼건지 판단하는 역할.
비즈니스 로직 계층. 실제 비즈니스 로직을 담당.
MVC 모델의 계층 이거 다 필기에 나올만한 얘기래. MVC모델이라는 내용만 알아두심 될거같아요.
모델에선 DB관련된 얘기. 뷰에서는 화면단 얘기. 컨트롤러에선 이것들을 가지고 뭔가 비즈니스로직을 처리한다.
- 아 이런 계층들이 있구나. 이정도만 알아두심 되고 mvc모델만 정확히. 모델뷰컨트롤러라는게 있다.
ㅇ DBMS 접속기술
DML. DB에 값을 넣고 가져오고 갱신하고 삭제하고 그런거.
DBMS 접속기술. DBMS는 종류가 많음. 오라클 MYSQL, MSSQL 등. 근데 이 벤더사들이 다 자기네 DB에 접속할 때 어떤걸 써야하는지 핵심기술이라 공개하지 않고 다 다름. 그래서 하나에 맞춰서 개발하면 다른 벤더껀 쓰지 못하기 때문에 중간에 뭔갈 둔거임. ODBC, JDBC이런걸 둬서 여기에 명령을 내리면 이건 다른 벤더사들 DBMS와 다 호환됙 ㅔ만들어 놓은게 DBMS 접속기술.
- 종류 다 했음.
ㅁ ORM 프레임워크
객체지향 언어에서 여기 있는 DB를 쓸 때 내가 쿼리를 다 쓰거나 객체들을 다 선언하기 귀찮아서 만든거다.
개념 걍 그렇다. 서로 매핑시킨거에요.
ㅁ 장단점
얘도 사실 크게 나올건 없음.
그냥 ORM이 뭐다 그것만 알아두심 될거같아요.
- SQL Mapper
sql을 써서 단순하게 이 ㄴql을 썼으니까 여기다 담아 단순하게.
- OR Mapping
이게 orm이에요. 첫줄. 그니까 얘는 쿼리를 안쓰는거에요. 두줄. sql mapper랑 똑같음 이건.
이 둘을 종류를 구분할 필욘 없어요. 종류는 이런것들이 있다.
그냥 sql mapping이 있고 or mapping이라는게 있는데 or mapping같은 경우는 데이터베이스에ㅓㅅ 객체지향언어에서 쿼리를 안쓰고 코드를 이용해서 db에 있는걸 가져오거나 조작할 수 있게 한거. 이정도만 알아두심 되요.
ㅁ 시큐어 코딩
개발할 때 시큐어 코딩 해야 된다. OWASP라는 단체가 있는데 웹에서 일어나느 공격같은걸 연구하는 기관. OWASP TOP10이란걸 발표함. 이걸 가지고 우리나라 KISA라는 곳에서 이걸 기반으로 시큐어코딩 가이드를 만들었다. 개발자 하려면 한번은 봐야되는 거임. 이런 시큐어코딩 가이드를 보고 그거에 맞게 개발하는게 시큐어 코딩이다.
1 입력데이터 검증 및 표현 얘만 지키면 됨. 다른것들은 서버에 관련된 것들이라 확인할 수가 없어요.
ㅁ OWASP. 이게 뭐냐. OWAP다 시험 나왔었음.
ㅁ 시큐어코딩 가이드 KISA가 만든거.
여기에 여러가지 대분류와 소분류가 있는데 종류를 좀 기억해두셔야 해요.
ㅁ 시큐어코딩 가이드 항목
xss 자바스크리트 삽입하는 공격. 사용자의 쿠키정보등 탈취.
부적절한인가. 내가 로그인했는데 관리자권한
시간및상태. 설명 그냥 이렇다.
에러처리 그냥 이런 종류가 있구나. 알아두심 될거같아요.
시큐어코딩가이드의 경우 대분류에 어떤 내용들이 포함되어 있는지 종류들 기억. api 오용이다. 해놓고 이 api오용에 해당하는 보안약점 종류들을 아래 보기에서 골라 쓰시오. 이런식으로 나올 확률이 굉장히 높음.
14강. 배치프로그램 구현
ㅁ 배치는 실시간과 반대되는 개념. 실시간은 내가 어떤 요청을 하게 되면 그때 그때 나에게 답변을 주는 거. 배치는 모았다가 일처리를 하는 거.
안쓴건 다 읽은거임. 특별히 필요없다고 하지도 않고 강조도 안한.
ㅁ 배치 프로그램의 필수 요소 - 기억
ㅁ 스케줄 관리 - 어떤 명령을 수행할 때 내가 매번 들어가서 수행하라고 할 수 없으니까 자동으로 할 수 있또록 해놓은 거. 알람처럼. 가장 많이 쓰는건 크론탭.
-크론탭. 쿼츠 스케줄러는 초도 포함하는데 크론탭은 초 없음.
표 다 설명함.
?는 *과 비슷.
설정 예도. 계산식특강에서 한번 더.
- 스프링 뱃치도있고 쿼츠도 있는데 종류만 알아두심 돼요.
- 시험에 쿼츠는 안나오고 크론만 나옴.
ㅁ 배치 스케줄러 클래스 작성
- 필요없음.
15강. 인터페이스 개요 및 설계서 확인
ㅁ 인터페이스 시스템의 개념
이런게 나오진 않음. 인터페이스라는건 서로 데이터를 주고받는다. 이렇게만 알아두세요.
인터페이스라는건 어떤 두 시스템 간에 데이터를 주고받는 것.
ㅁ 송신시스템 - 이게 시험에 나옴. 뜬금없이. 송신, 중계, 수신 시스템. 그냥 용어만.
중계시스템은 없어도 됨.
- 단계별작업은 안나옴.
-중계서버 = 연계서버. 똑같은얘기.
ㅁ 연계 시스템 분류와 데이터 식별
- 얘도 안나옴. 업체마다 다 달라서. 대분류중뷴류소분류 이런식으로 구분을 보통하니까. 표준화가 안돼있어서 나올순 없음.
- 송수신 전문 구성 얘는 나올 수 있음. 그 위의 것들은 다 x. 공통부 개별부 종료부만.
ㅁ 인터페이스 설계서 확인
- 인터페이스 설계서같은 경우는, 사실 인터페이스 목록이란게 있어요. 정의서라는 것도 있고.
목록은 우리 시스템에서 사용하는 인터페이스 목록을 다 나열시킨거. 정의서는 목록에서 하나를 뽑아서 상세하게 써놓은거.
- 인터페이스 목록이라는게 있다 정도만. 주요항목은 나오기 힘듦.
- 인터페이스 정의서. 인터페이스 상세 설계서라고 함. 인터페이스 명세서라고도 함. 상세히 포함한다 밑줄. 주요항목 나오기 힘듦.
- 인터페이스 설계서 명세화. 문서로 만드는 거임. 시험 안나옴.
ㅁ 데이터 표준 확인
- 이것도 나올거 아님.
- 이건 나와요. 데이터 포맷은 Json, DB, XML, YAML 등 다양한 형태로 표현이 가능. 이런 것들 중에서 정하자.
- 이번 강의에서 나올만한건 없어요. 혹시 나온다면 전문 공통부, 개별부, 종료부 이정도. 송신, 중계, 수신 시스템.
인터페이스 목록과 인터페이스 정의서가 있다. 데이터가 왔다갔다 할 대 어떤 형태로 왔다갔다 하느냐. Json, DB, XML, YAML 등.
16강. 인터페이스 기능 구현 및 검증
ㅁ eai
- 기업의 어플리케이션들을 통합하는데 종류가 있음. 이 종류들을 꼬 ㄱ기억.
- 구축 유형 4가지 꼭 기억
ㅁ esb
- 개념 둘째줄 필요없.
- 서비스 중심 통합을 지향 밑줄. 구글 맵 api 받으니 종속성.
ㅁ 인터페이스 연계 기술
- 그럼 데이터들을 어떻게 왔다갔다 하게 할거냐. 여러 가지 방식이 있음.
- OpenAPI는 많은 사람들에게 공개한 거.
- 웹서비스는 3가지를 기억해둬야됨. WSDL은 설명서, UDDI는 설명서를 모아두는 도서관, SOAP은 이 설명서를 다운로드 받았을 때 실제로 데이터를 주고받을 수 있는 프로토콜(약속)이다.
= api/openapi만 정리해주세요. 나머지들은 그냥 연결을 하는거지 api에 많이 쓰이는게 아니라 이런 기술들이 있구나 정도만.
ㅁ 인터페이스 전송 데이터
- 인터페이스를 할 때 왔다 갔다 하는 데이터의 유형. 정하기 나름임. 서로.
- JSON. 설명 3줄 나오면서 이런게 뭐냐. 나오면 JSON 답 쓰기. 문법은 예시인듯? 아마? 키와 밸류.
- XML. 확장된 마크어 ㅂ랭귀지. 원래 마크업 랭귀지의 대표적인건 html. html은 구조를 만든다. 얘는 확장이 불가능 함. 태그들이 이미 정해져 있음. 그래서 XML. 사용자가 간단히 구조를 확장할 수 있음. 예제는 필요 없음.
- YAML. 얘는 직렬화 언어이다. 이것만 알면 됨.
- CSV.
쉼표 밑줄.
ㅁ 인터페이스 구현
- AJAX. 용어 꼭 기억. 시험 잘 나옴. 비동기 밑줄. 네이버의 광고 배너만 바뀜. 동기면 내가 여기 데이터를 받아올 때까지 다른거 아무것도 못함. 비동기여서 이거 기다리면서 다른 것도 할 수 있는 거. 일부만 밑줄.
장단점. 읽긴 했음. 외우거나 이럴 필요는 없음. 예제도 필요 없음.
- SOAP. 아까 전에 얘기했던 인터페이스 연계 기술 - 웹 서비스. WDSL, UDDI, SOAP 기억.
실제 어떤 프로토콜을 쓰냐. HTTP, HTTPS, SMTP. 밑줄. 셋째줄 X.
SOAP 구성. UDDI, SESL, SOAP만 잘 알아두심 돼요. WSDL은 설명서 UDDI에 모아 놓음.
SOAP, UDDI, WSDL 설명은 음 어렵게 알아두지 말자 하는데 나오면 어캄.
SOAP 보안 프로토콜. 이건 나올 확률은 희박한데 낼라면 또 내나 봐. SAML, XKMS, XACML
장단점. 안나올듯.
기본구조. 안나옴.
- REST. 개념 설명 ㅈㄴ어려움. 데이터를 이용해서 API만드는거. 자원은 X침.
그냥 HTTP를 통한 CRUD라고 외워야 겠다.
구성요소. 자원, 행위, 표현. 밑줄. GET, POST, PUT, DELETE 밑줄.
CRUD Operation. POST, GET, PUT, DELETE 밑줄. 기억해두세요.
특징, 장단점, 예제 다 넘길듯. RESTful. 그냥 REST만 알아두심 될거같아요. 필요없단건가?
ㅁ 인터페이스 보안
- 인터페이스는 데이터가 왔다 갔다 하잖아요. 그걸 지켜볼 수가 있는 거죠.
- 패킷이라는 건 데이터가 왔다갔다 하는 단위를 말함.
- 인터페이스 보안 기능 적용. 셋 다 함.
ㅁ 인터페이스 검증
- 구현 검증 도구 특징만 정확히 알아두시면 돼요.
xUnit - 다양한 언어, 단위테스트
STAF - 서비스 호출 및 컴포넌트 재사용
FitNesse - 웹 기반 테스트케이스
NTAF - Naver의 테스트 자동화
Selenium - 웹 애플리케이션 테스트 프레임워크
wair - ruby
- 구현 감시 도구. 다 읽음. 어쩌라는 거지. 스카우터라든지 제니퍼라든지 이렇게 구현을 감시하는 도구가 있다. 밑줄은 안함.
인터페이스 구현 감시도구. apm을 이용해 앱의 퍼포먼스 관리르 한다. 스카우터나 제니퍼가 있다.
ㅁ 인터페이스 오류 처리
- 이건 나오기 힘듦.
17강. 객체지향 설계
ㅁ 객체지향 개념
- 그냥 한번 읽어보심 돼요.
ㅁ 객체지향 구성요소 - 이건 나옴
- 클래스. 추상화. 속성과 연산(메소드).
- 객체. 클래스는 구조(붕어빵 틀)이고 객체는 붕어빵.
ㅁ 객체지향 언어의 특징 - 이것도 나옴
ㅁ 객체지향 설계 원칙(SOLID) - 잘 나옴. 영어를 다 외울 필요는 없음. 약자만 외우면 되는듯?
SRP. 하나의 책임(기능)
ㅁ 디자인패턴
- 개념들이 나오진 ㅇ낳음.
- 구조. 설명은 필요 없는데 종류는 알아두세요 라는 듯.
ㅁ GoF 디자인 패턴
- 쉽게 나오면 생성, 구조, 행위가 나옴. 어렵게 나오면 패턴의 특징 보여주면서 어떤 패턴인지 물어봄.
- GoF 디자인 패턴 분류. 생성 2째줄은 x.
- 많이 나오는 건 정해져 있음. 프록시, 데코레이터, 어댑터, 싱글톤, 옵저버 등. 나머지 것들도 나올 수 있음.
추상 팩토리. 구체적인 클래스에 의존하지 않고
빌더. 복합 객체의 생성과 표현을 분리.
팩토리 메서드. 객체 생성을 서브클래스로 위임하여 캡슐화.
프로토타입. 원본 객체를 복사함으로써 객체를 생성함.
싱글톤. 클래스의 인스턴스는 오직 하나. (소스코드까지 나오진 않을거에요. 예시 필요없음)
어댑터. 변환하여 다른 클래스가 이용할 수 있또록 함.
브릿지. 구현부에서 추상층을 분리.
컴포지트. 트리구조로 구성. 이것만.
데코레이터. 덧붙이는 방식. 데코레이션하는 거다. 덧붙이는거.
퍼샤드. 래퍼를 제공. 서브시스템 앞쪽. 밑줄 안치고 말로만 함.
플라이웨이트. 크기가 작은 여러개의. 메모리를 절약.
프록시. 대리. 대체글.
책임 연쇄.
커맨드. 실행될 기능을 캡슐화.
인터프리터. 언어를 해석.
반복자.
중재자. 중재자.
메멘토. 객체의 상태정보를 저장했다가 이전상태로 복원
옵저버. 상태변화가 있을 때마다 메서드를 통해.
상태. 상태를 객체로 표현한다.
전략. 알고리즘.
템플릿 메소드. 여기선 알고리즘 나오지만 아님. 골격만. 구체적 처리는 서브클래스.
방문자.
18강. 애플리케이션 테스트케이스 설계
블랙박스 테스트, 결합도와 응집도 영어로 쓰라고 출제가 됨.
너무 어려운 영어 용어는 출제 안되지만 간단한 영어들은 쓰라고 함.
ㅁ 소프트웨어 테스트
- 개념 안나옴.
- 근데 개념에서 (결함) 이렇게 나올 수 있대.
- 필요성. (오류 발견) 관점, (오류 예방) 관점, (품질 향상) 관점. 나올 수 있다.
- 기본 원칙. 필기에선 엄청 나오는데 실기에서도 나올 수 있다. 보기 하고 다 골라라.
개발 초기. 단위테스트부터 시작.
결함 집중의 법칙은 (파레토 법칙)이라함.
살충제 패러독스. 테스트 케이스 똑같은거 쓰지말고 계속 바꿔야 한다.
오류 부재의 궤변.
ㅁ 테스트 프로세스
- 모든 프로세스는 똑같. 계획. 분석 및 디자인. 케이스 및 시나리오 작성. 수행. 결과 평가 및 리포팅.
- 테스트 케이스 및 시나리오 작성이 설계단계가 됨. 테스트 수행이 구현
케이스는 하나의 단위 테스트가 됨.
ㅁ 테스트 산출물
- 테스트 케이스. 입력, 실행 조건 및 기대 결과. 나올 수 있음.
ㅁ 테스트 오라클
- 테스트 오라클 개념. 테스트 오라클에 대해 쓰시오 나올 수 있음.
- 유형. 중요.
- 테스트 레벨. v의 왼쪽은 필요 없음.
단위 테스트. 정적 테스트 - 소스코드 보면서, 동적 테스트 - 실행 시켜봄
통합 테스트. 상드, 하스, 빅뱅테스트(둘 다쓰는건 백본인데 몰라도 되고. 빅뱅테스트는 비점진적 테스트. 한번에 다 테스트. 작은 규모에 사용. 상, 하는 점진적이다)
시스템 테스트. 기능(사용자가 요구한 기능이 잘 작동하는지), 비기능 테스트.
- 단위 테스트. 여기서 기능 비기능 테스트 할 수 있음. 다른데서도 정적, 동적 테스트 할 수 있고. 그저 대표적인 것뿐.
코드의 효율성과 코딩 표준 준수가 정적. 기능의 정확성은 동적 테스트.
- 통합 테스트. 통합 밑줄.
- 시스템 테스트. 기능 테스트. 명세 - 요구사항 명세서에 따라 확인한다.
- 인수 테스트. 알파테스트와 베타 테스트가 대표적. 나머진 곁가지. 몰라도 될 듯.
ㅁ 소프트웨어 테스트 기법
ㅁ 프로그램 실행 여부
- 리팩토링 : 기능의 변경 없이 안에 있는 소스코드를 변경하는 작업.
ㅁ 테스트 기법
- 이게 좀 헷갈릴 수 있음. 화이트박스 테스트라고 해서 실행을 아예 안시키는게 아니어서 정적 테스트라 볼수도 있는데 동적 테스트에 들어감. 분류 자체가 틀린거니까. 정적, 동적테스트랑 이거랑 연결시킬 필요 없음.
- 화이트박스 테스트 기법.
이게 시험에 두번인가 나왔음. 그냥 1 2 3 4 5 6 7. 시험에 나온 답안 그대로 써주시면 됨.
문장 검증. 1234567
선택 검증. 1234567일 수도 있고 124561일 수도 있음. 다 해도 되고 몇개만 선택해도 되고.
설명, 검증 방법말고 앞에 있는 기법만 알면 됨. 화이트밗 ㅡ테스트 기법의 종류만 기억하심 돼요.
검증방법에 있는 1234567이건 실기 시험 전에 옛날 기출 하면서 설명드릴테니까 그 답안만 알아두심 돼요. 여기선 기법들 종류만.
- 기초 경로 검사. 이 그림을 준 다음에 McCabe의 순환복잡도 cyclomatics를 구해라 나올 수 있음.
엣지 빼기 노드. 엣지는 선. 선 6개 빼기 노드 동그라미 4개. 그리고 +2. 답은 4.
생각 안 날 수 있잖아. 면 수 + 1 해도 됨.
- 블랙박스 테스트 기법.
기능 밑줄.
기법들도 잘 나옴. 영어로도 나옴. 영어로도 알아야 함.
이 설명에 대한 기법이 뭐냐.
원인-효과. 입력, 출력 밑줄.
ㅁ 테스트에 대한 시각
- 검증검사. 확인검사. 검증과 확인이 있음. 완성된 소프트웨어 밑줄.
ㅁ 테스트 목적
- 테스트 목적에 따라 여러 테스트가 있음.
- 특징 정확히 알아두셔야. 설명 나오고 뭔지 물어봄.
구조. 내부 구조, 복잡도.
ㅁ 테스트 종류
- 명세 기반 테스트. 제목의 명세 밑줄. 둘째줄은 필요없고.
구조 기반 테스트. 제목의 구조 밑줄.
ㅁ 테스트 커버리지
- 어렵게 나오는 건 7급이나 감리사. 여기서는 그냥 종류들만 알아두심 돼요.
본강에선 시험에 나왔던 수준으로만 하고 시험 전 특강에선 어려운 내용도 다룰건데 안보셔도 돼요.
- 내가 얼마나 테스트를 진행했느냐. 첫줄 필요 없고. 셋째줄이 중요.
- 기능 기반 커버리지
- 라인 커버리지
- 코드 커버리지. 코드 커버리지의 유형이 많이 나옴.
조건 커버리지.
결정포인트란 if( x> 0 && y < 0) 여기 있는 전체 조건식이 참인지 거짓인지 보는거. 개별 조건식은 &&의 왼쪽 오른쪽.
x > 0, y < 0만 봄. 결정포인트는 T/F 상관 없음 T/F 둘 다 안나와도 됨.
결정 커버리지. 개별 조건식 T/F 상관 없음. 결정포인트의 T/F만 중요.
이런 계산식을 어려워 하세요. 근데 이런 계산식이 아직까지 출제 안 됨.
조건/결정 커버리지. 개별 조건식과 결정포인트 전부 T/F 나와야 함.
변경 조건/결정 커버리지.
결정포인트 T/F 나옴. 그리고 그 때 각각 개별 조건식이 T/F 나와야 함.
다중 조건 커버리지. 이거까진 안나올 거다. 문장이 나온다면 결정포인트 내 모든~ 이게 나올거에요. 문장이 나온다면.
19강. 애플리케이션 통합테스트
ㅁ 결함관리 도구
- 개념. 도구 밑줄. 둘째줄 X.
- 결함관리 프로세스. 이건 나올 수 있음. 이거는 좀 기억해두셔야 해요.
발견 등록 분석 확정 할당 조치 조치 검토 및 승인
- 결함 추이 분석은 나올 게 없음.
- 결함 관리 측정 지표는 나올 수 있음.
결함 분포. 결함의 수를 측정~밑줄.
결함 추세.
결함 에이징. 지속 시간을 측정 밑줄.
종류를 외우라는 건지 설명-답을 외우라는 건지. 결함관리측정지표에 이 3가지가 있다. 3가지 종류가 있다 이정도만.
- 결합의 식별. 몰라도 됨.
- 결함 관리 항목. 몰라도 됨.
- 결함 관리 도구 종류. 몰라도 됨.
ㅁ 테스트 자동화 도구
스크립트 라는건 설명서임. 그 스크립트대로 테스트가 됨.
ㅁ 개념
- 반복적인 테스트 작업. 밑줄. 설명 1, 2줄 나오면 테스트 자동화 도구 써주시면 될거같아요.
ㅁ 장단점 - 일거보시고.
ㅁ 테스트 자동화 도구 유형
- 정적 분석 도구.
소스코드 보는거. 종류가 가끔 나온다!
- 테스트 실행 도구
실제로 동작하는거. 종류 설명은 했는데 외워야 되나.
- 성능 테스트 도구
얜 종류 안나온다.
- 테스트 통제 도구
형상관리 같은거
- 테스트 장치
이건 잘나와요. 환경 및 도구 밑줄.
구성요소. 이것도 알아두셔야 돼요.
테스트 드라이버. 상향식
테스트 스텁. 하향식
테스트 슈트. 테스트 케이스의 집합
테스트 케이스. 입력 값, 실행 조건, 기대 결과
테스트 시나리오는 절차다
테스트 스크립트. 명세=설명서
목 오브젝트. 조건, 객체.
ㅁ 통합 테스트
- 개념. 비점증적, 점증적
- 분류.
하향식. 더미 모듈인 스텁.
상향식. 클러스터 밑줄. 클러스터 나올 수 있음. 괄호. 드라이버 밑줄. 클러스터 단위로 묶는다.
-> 이거 순서 나온건 큰 의미 없음.
다 장단점은 별 필요 없는듯.
빅뱅 테스트. 모든걸 한꺼번에 테스트.
백본 테스트.
- 순서. 큰 의민 없는듯. 지난 시간 테스트 절차랑 비슷. 그래도 하긴 했음. 문제 나오면 공부안하면 못풀겠는데?
20강. 애플리케이션 성능개선
ㅁ 애플리케이션 성능 저하 원인
ㅁ DB 관련 성능 저하
- 그냥 이런게 있다??
ㅁ 내부 로직
ㅁ 외부 호출로 인한 성능 저하
그냥 큰 덩어리만 알아두시면 돼요. 이 3개의 대분류만 알면 되는듯.
ㅁ 애플리케이션 성능 분석
ㅁ 애플리케이션 성능 분석 지표
- 경과시간=반환시간. 대분류만 알면 되나.
ㅁ 성능 분석 도구
- 종류만 알아두시면 돼요.
ㅁ 모니터링 도구
- NMON 첫줄만. 종류만.
ㅁ 정형 기술 검토회의(FTR)
- 필기에서만 많이 나오는거지 실기에서 출제될 건 아님.
- 용어만. FTR이란 용어만.
ㅁ 소스코드 품질 분석
- 동료 검토
- 워크스루
개발자가 발표.
- 인스펙션
공식 검토 회의. 전문가들이.
수행 절차 미친척하고 가끔 나올 수도 있음.
- 이 3을 이용해서 리팩토링을 수행한다. 리팩토링은 기능은 그대로 둔 상태에서 안에 있는 소스코드 품질을 높이는것.
ㅁ 소스코드 품질 분석 도구
- 필기에선 출제됐는데 아직까지 실기에선 출제 안됐음.
- 스레드라는 건 프로세스 안에서 동작하는 작은 프로세스라고 보면 됨.
- 도구 종류. 만약 알아둔다면 동적분석도구. 2개밖에 없으니까
ㅁ 애플리케이션 성능 개선하기
- 리팩토링. 코드 스멜. 밑줄.
ㅁ 코드 스멜
- 종류는 외울 필요 없음. 코드 스멜만 알면 됨.
- 스파게티 코드ㅡ, 외계인 코드. 이건 알자.
ㅁ 리팩토링
- 기능은 둔 상태에서 소스코드를 변경. 리팩토링 전에 동워인 진행해서 문제점 발견하고 문제점 해결 위해 리팩토링.
ㅁ 클린코드
- 클린코드 용어만 알아두심 돼요.
- 클린코드 작성원칙은 외우.
21강. 소프트웨어 유지보수
ㅁ 개념. 안나옴.
ㅁ 중요성. 읽어보심되는거지 외울건 아님.
ㅁ 유지보수의 구분. 기억. 영어로도.
수정보수. 오류 수정.
적응보수. 환경변화에~
향상보수. 첫줄만.
예방보수. 장래를 위한 선젲거 조치.
ㅁ 유지보수 관련 용어. 다.
22강. 국제표준 제품 품질특성
ㅁ 국제표준이란 건 2가지가 있음. 품질 표준과 프로세스 표준.
품질 표준은 SW의 품질.
프로세스 표준은 SW 만드는 회사가 잘 돌아가는가를 보는거.
ㅁ 제품 품질 국제 표준
- 개념. 제품이 사용자 요구를 만족하는지. 밑줄.
ㅁ 소프트웨어 품질 관련 국제 표준
- 대표적인게 9126. 세부내용도 읽었음. 기신사효유이 외워야함.
- 14598. 이거까지 사실 나오긴 어렵고. 근데 반복성, 공정성, 객관성, 재현성은 밑줄.
- 12119. 품질 요구사항 및 테스트까지 포함한거다. 밑줄. 특징만 정확히 알아쉬면 돼요. 품질 요구사항에 테스트까지 포함한거.
- 25000. 9126하고 14598을 통합한 모델. 세부내용은 필기에는 가끔 나오는데 실기까지 내면 진짜 나쁜사람이지.
1) 9126 - 영어로도 아셔야 하고
기능성. 요구사항을 만족하는 기능. 부특성은 필기에서나 나오지 실기에선 안나올거에요. 너무 많으니까
신뢰성. 오류가 없어야.
사용성.
효율성.
유지보수성.
이식성.
2) 14598
- 9126 가지고 평가에 대한 기준을 제시한거.
반복성. 동일 평가자 동일 제품 일관성
재현성. 다른 평가자 동일 제품 일관된 평가
공정성. 평가의 편향 없음
객관성. 주관성 X
3) 12119 구성요소
얘는 잘 안나와요. 걍 읽어보심 될거같아요 12119는
4) 25000
설명은 모르셔도 돼요. 앞에 평가모델과 괄호는 기억해주세요.
이것도 시험용 실무는 X.
ㅁ 프로세스 품질 국제 표준
- 개념. 첫줄만.
ㅁ 국제 프로세스 품질 표준
- 9001은 안나옴.
1) 12207
- 기본, 지원, 조직. 세부 프로세스도 설명 다 함.
기본, 지원, 조직 이렇게 나눈게 12207이다. 꼭 기억해쥬셔야 해요.
2) 15504
- 첫줄이 나오진 않음.
- 6단계.
특히 3, 4, 5단계는 더 신경써주세요.
3, 4에서 잘 나온다.
3단계. 표준. 4단계. 정량적.
3) CMM
초반정관최
- 반복 단계. 반복.
- 정의 단계. 표준이다.
- 관리 단계. 정량적.
- 최적화 돤계.
4) CMMi
시스템 소프트웨어 영역을 추가한거임. 밑줄.
초관정 정관 최
- 관리 단계 첫줄만.
- 정의 단계. 표준.
- 정량적 관리 단계. 정량적.
ㅁ 서비스관리 국제 표준
- 여기가지 시험에 나오기는 애매하긴 한데. 종류만 알아두시면 될거같아요.
- 20000. 첫줄만. 이런게 있다.
23강. 제품소프트웨어 패키징 & 메뉴얼 작성
ㅁ 실기에서 메뉴얼 부분은 안나와서 그냥 이런 부분이 있구나. 정도만.
ㅁ 애플리케이션 패키징
- 개념. 안나옴. 특징. 안나옴.
- 수행순서. 나올 수도. 혹시라도 마이너학 ㅔ나온다면.
ㅁ 애플리케이션 배포
ㅁ CI/CD
- 통합을 하고 배포
- 공유 레포지토리에 통합 밑줄.
- CD의 두개. 모르겠다. 걍 CI CD만 알면 되려나.
ㅁ 릴리즈 노트
- 설명서임. 패치노트에 가깝네. 릴리즈 노트 용어 알아야. 3개 나오고 익 ㅔ뭐냐.
- 작성항목. 필기에서나 나올거. (4)도 볼거 없음.
ㅁ DRM
- 개념. DRM에 대해 쓰시오. 나오면 첫줄만 쓰면 됩니다.
- 특징. 시험 안나옴.
- 구성 및 흐름. 영화관.
컨텐츠 제공자. 컨텐츠의 컨텐츠를 메타 데이터라 함. 컨텐츠와 메타 데이터를 패키저로 묶음.
그리고 클리어링 하우스에 감. CGV 본사다. 여기다 라이선스 등록을 하고,
컨텐츠 분배자에게 컨텐츠 등록. CGV 영화관. 상암 CGV. 여기다간 컨텐츠 등록.
나(컨텐츠 소비자)가 돈내고 라이선스 요청. 바로 본사에 요청할수도 있고 컨텐츠 분배자를 거칠 수도 있음.
표. 다 함.
ㅁ DRM 사용 규칙 제어 기술
- 컨텐츠 식별 체계.
컨텐츠가 어디 있는지 찾는거.
DOI, URI 밑줄.
- 메타데이터
첫줄만 앎녀 됨.
- 권리 표현 기술
기간, 횟수. XrML이 대표적. 밑줄.
- 권리 표현 종류
RENDER는 볼수만 있음. TRANSPORT는 양도 가능. DERIVATIVE는 변형 가능.
ㅁ 저작권 보호 기술
- 암호화 기술
- 위변조 방지
얘가 시험에 나왔음. 영어로도 알아야 하나.
- 워터마킹
워터마킹. 핑거프린팅.
ㅁ DRM 구성요소
- 암호화
설명은 ㄴ. 그냥 암호화라느 ㄴ구성요소가 있다.
- 키 관리
- 암호화 파일 생성
- 식별 기술
- 저작권 표현
- 정책 관리
기간, 횟수
- 크랙 방지
이러 ㄴ설명들이 나오는게 아니라 DRM 구성요소를 골라서 적으시오. 나올 수 있음.
- 인증
ㅁ 제품 소프트웨어 매뉴얼 작성
- 얜 진짜 나올 거 없음. 다 나올거 없다.
- 설치 매뉴얼과 사용자 매뉴얼(쓰다가 궁금하면) 2가지가 있음.
'정처기 실기' 카테고리의 다른 글
| 6과목. 신기술 용어 (58강 ~ 59강) (0) | 2024.04.09 |
|---|---|
| 5과목. 정보보안 (53강 ~ 57강) (0) | 2024.04.08 |
| 4과목. 네트워크 (45강 ~ 52강) (0) | 2024.04.08 |
| 3과목. 운영체제 (38강 ~ 44강) (0) | 2024.04.07 |
| 2과목. 데이터베이스 구축 (24강 ~ 37강) (0) | 2024.04.06 |