정보처리기사 필기 1과목 정리 [1]

[ 1 ] 소프트웨어 생명주기, SDLC ( Software Development Life Cycle ) ★ ★

 

1) 폭포수 모형 ( Saterfall Model )

- 가장 오래되고 가장 폭넓게 사용된 고전적 생명주기모형

- 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형

- 단계별 정의 및 산출물이 명확

- 개발 중간에 요구사항의 변경이 용이하지 않음

- 타당성 검토 > 계획 > 요구 분석 > 설계 > 구현(코딩) > 테스트(검사) > 유지보수

 

2) 프로토타입 모형 ( Prototype Model, 원형 모형 )★

- 견본(시제) 품을 만들어 최종 결과물을 예측하는 모형

- 인터페이스 중점을 두어 개발

- 개발 중간에 요구사항의 변경이 용이

 

3) 나선형 모형 ( Spiral Model, 점진적 모형 ) ★

- 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

- 점진적 개발 과정 반복으로 요구사항 추가 가능

- 정밀하고 유지보수 과정 필요 없음

- 계획 및 정의 > 위험 분석 > 공학적 개발 > 고객 평가

 

4) 애자일 모형 ( Agile Model ) ★ ★

- 애자일은 민첩함, 기만함을 의미

- 변화에 유연하게 대응

- 일정한 주기를 반복하면서 개발과정 진행

- 절차와 도구보다 고객과의 소통에 초점을 맞춤

- 기능 중심 개발

ex) XP( eXtreme Programming ), 스크럼, 칸반, 크리스털, 린

 

[ 2 ] 스크럼 기법 ★

- 팀원 스스로가 스크럼 팀 구성

- 개발 작업에 관한 모든 것을 스스로 해결해야 함

- 스프린트는 2~4주 정도의 기간으로 진행

 

1) 제품 책임자 ( PO )

- 요구사항이 담긴 백로그를 작성하는 주체

- 백로그에 대한 우선순위를 지정, 이해관계자들의 의견을 종합

 

2) 스크럼 마스터 ( SM )

- 일일 스크럼 회의 주관

- 팀원들을 통제하는 것이 목표가 아니다

 

3) 개발팀 ( DT )

- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원

- 최대 인원 7~8명

 

4) 스크럼 개발 프로세스

- 스프린트 계획 회의 > 스프린트 > 일일 스크럼 > 스크럼 검토 회의 > 스프린트 회고

 

[ 3 ] XP 기법 ★ ★

 

1) XP( eXtreme Programming )의 핵심 가치 ★

- 용기, 단순성, 의사소통, 피드백, 존중

 

2) XP의 기본 원리

- Whole Team( 전체 팀 ), Small Releases ( 소규모 릴리즈 ), Test-Driven Development ( 테스트 주도 개발 ), 

  Continuous Integration ( 계속적인 통합 ), Collective Ownership( 공동 소유권 ), Pair Programming ( 짝 프로그래밍 ),

  Design Improvement ( 디자인 개선 ) 또는 Refactoring( 리팩토링 )

 

[ 4 ] 개발 기술 환경 파악 ★

 

1) 운영체제 ( OS )

- 하드웨어가 아닌 스포트웨어

- Windows, UNIX, Linux, Mac OS, iOS, Android등등

- 가용성, 성능 | 기술지원, 구축비용, 주변 기기 ( 고려사항 )

 

2) 미들웨어 ( Middleware )

- 운영체제와 응용 프로그램 사이에서 추가적인 서비스를 제공하는 소프트웨어

 

3) 데이터베이스 관리 시스템 ( DBMS )

- 사용자와 데이터페이스 사이에서 정보를 생성하고 DB를 관리하는 소프트웨어

- 데이터베이스의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐

- jdbc, odbc

- Oracle, MySQL, SQLite, MongoDB, Redis 등등

- 가용성, 성능 | 기술 지원, 구축비용, 상호 호환성 ( 고려사항 ) ★

 

4) 웹 애플리케이션 서버 ( WAS )  

- 정적인 콘텐츠를 처리하는 웹서버와 반대됨

- 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어 (= 소프트 웨어)

- 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공

- Tomcat, JEUS, WebLogic, JBoss, Jetty 등등

- 가용성, 성능 | 기숙지원, 구축 비용 ( 고려사항 )

 

5) 오픈소스

- 누구나 별 다른 제한 없이 사용할 수 있도록 소스 코드를 무료로 사용할 수 있게 공개한 것

- 라이선스의 종류, 사용자 수, 기술의 지속 가능성 ( 고려사항 )

 

[ 5 ] 요구사항의 정의 ★

 

1) 기능 요구사항

- 기능, 입력, 출력, 저장, 수행 등등

 

2) 비기능 요구사항

- 성능, 품질, 제약사항, 호환성, 보안 등등

 

3) 요구사항 개발 프로세스 ★

- 도출/추출 > 분석 > 명세 > 확인/검증

 

4) 요구사항 분석 기법

- 요구사항 분류, 개념 모델링, 요구사항 할당, 요구사항 협상, 정형 분석

 

5) 요구사항 확인 기법 ★ ★

- 요구사항 검토, 프로토타이핑, 모델검증, 인수 테스트( 알파테스트, 베타테스트 )

 

[ 6 ] UML

 

1) UML ( Unified Modeling Language )의 구성요소 ★

- 사물, 관계, 다이어그램

 

2) 사물 ( Things )

- 구조, 행동, 그룹, 주해 {사물}

 

3) 관계 ★ ★

- 연관 ( - ) 

- 집합 ( ◇ )

- 포함 ( ◆ )

- 일반화 ( ㅡ▷ )

- 의존 ( --> )

- 실체화 ( --▷ ){ 관계 }

 

4) 구조적, 정적 다이어그램 ★ ★

- 클래스, 객체, 컴포넌트, 배치, 복합체 구조 패키지

- 컴포넌트, 배치 다이어그램은 구현 단계에서 사용되는 다이어그램 ★

 

5) 행위, 동적 다이어그램 ★ ★

- 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍

 

[ 7 ] 사용자 인터페이스 ( UI ) ★

 

1) UI의 구분 ★

- CLI ( Command Line Interface ) : 텍스트 형태로 이뤄진 인터페이스

- GUI ( Graphical User Interface ) : 마우스로 선택해 작업을 하는 그래픽 환경의 인터페이스

- NUI ( Natural User Interface ) : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

- VUI ( Voice User Interface ) : 사람의 음성으로 기기를 조작하는 인터페이스

- OUI ( Organic User Interface ) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

 

2) UI의 기본 원칙 ★ ★

- 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 함

- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 함

- 학습성 : 누구나 쉽게 배우고 익힐 수 있어야함

- 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화 해야함

 

3) 웹의 3요소

- 웹 표준, 웹 접근성, 웹 호환성

 

4) UI 설계 도구 ★

- 와이어프레임 : 레이아웃을 협의하거나 공유하기 위해 사용

- 스토리보드 : 최종적으로 참고하는 작업 지침서, 작업 산출물 ( 디스크립션 )

- 프로토타입 : 인터랙션을 적용해 실제 구현된 것처럼 테스트가 가능한 동적인 모형

- 목업 : 실제 화면과 유사한 정적인 모형

- 유스케이스 : 사용자 측면 요구사항을 다이어그램 형식으로 묘사

 

5) UI 프로토타입

- 장점 : 사용자를 설득하고 이해시키기 쉬움 | 개발 시간을 줄일수 있음 | 사전 오류 발견 가능

- 단점 : 반복적인 개선 및 보완 작업으로 인한 작업 시간 증가 및 자원 소모 | 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성

 

6) UI 시나리오 문서 요건

- 이해성 : 누구나 쉽게 이해할 수 있도록 설명

- 완전성 : 최대한 상세하게 기술

- 일관성 : 일관성 유지

- 가독성 : 표준화 된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함

- 수정 용이성 : 수정 및 개선이 쉬워야 함

- 추적 용이성 : 변경사항에 대해서 쉽게 추적할 수 있어야 함

 

7) 기타

- HCI : { 사람 }과 { 컴퓨터 }의 { 상호작용 }을 연구해서 사람이 컴퓨터를 편리하게 사용하도록 만드는 학문

- UX : 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험

- 감성공학 : 1류; 인간의 감성/ 2류; 심리적 기능/ 3류; 공학적 및 수학적 모델, 객관적

 

[ 8 ] 품질 요구사항

 

1) 국제 제품 품질 표준 ★

- ISO/IEC 9126

- ISO/IEC 12119

- ISO/IEC 14598

- ISO/IEC 25000

 

2) ISO/IEC 9126 ★ ★

- 기능성 : 요구사항을 정확하게 만족하는 기능을 제공하는가 ?

  # 적절성(적합성), 정확성, 상호 운용성, 보안성, 호환성

- 신뢰성 : 요구된 기능을 정확하고 일관되게 오류 없이 수행하는가?

  # 성숙성, 결함 허용성, 회복성

- 사용성 : 사용자가 정확하게 이해하고 사용하는가?

  # 이해성, 학습성, 운용성, 친밀성

- 효율성 : 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리하는가?

  # 시간 효율성, 자원 효율성

- 유지보수성 : 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는가 ?

  # 분석성, 변경성, 안정성, 시험성

-  이식성 : 소프트웨어를 다른 환경에서도 쉽게 적용할 수 있는가?

  # 적용성, 설치성, 대체성, 공존성

 

3) ISO/IEC 14598

- 반복성, 재현성, 공정성, 객관성

 

4) 국제 프로세스 품질 표준

-ISO/IEC 9001

- ISO/IEC 12207 : 기본 프로세스, 조직 프로세스, 지원 프로세스

- ISO/IEC 15504 : 불완전 > 수행 > 관리 >  확립 > 예측 > 최적화

- CMMI : 조직차원의 성숙도를 평가하는 단계별 표현과 프로세스 영역별 능력도를 평가하는 연속적 표현이 있음

 

[ 9 ] 소프트웨어 아키텍처 ★

- 사용자의 비기능적 요구사항으로 나타난 제약 반영

- 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

 

1) 모듈화

- 시스템 기능들을 모듈 단위로 나눠 소프트웨어의 성능 및 재사용성을 향상시키는 것

- 모듈의 크기 ▲ : 모듈 개수 적음 | 모듈 간 통합 비용 적음 | 모듈 하나의 개발 비용 큼

- 모듈의 크기 ▼ : 모듈 개수 많음 | 모듈 간 통합 비용 큼

 

2) 추상화

- 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시키는 것

- 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악

- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표하는 표현으로 대체

- 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표하는 표현으로 대체

 

3) 단계적 분해

- Niklaus Wirth 에 의해 제안된 하향식 설계 전략

- 추상화의 반복에 의해 세분화

- 소프트웨어 기능에서부터 시작해 절차적으로 구체화

- 상세한 내역은 가능한 한 뒤로 미루어 진행

 

4) 정보은닉

- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

- 정보 은닉을 통한 독립적 모듈 수행 가능

- 모듈 변경 시 영향을 받지 않아 수정, 시험, 유지보수 용이

 

[ 10 ] 아키텍처 패턴

 

1) 레이어패턴

- 시스템을 계층으로 구분하여 구성하는 고전적 방법

 

2) 클라이언트 - 서버 패턴

- 하나의 서버 컴포넌트와 다수 클라이언트 컴포넌트로 구성되는 패턴

- 클라이언트나 서버는 요청과 응답을 받기 위해 동기화 되는 경우를 제외하고는 서로 독립적

* 컴포넌트 : 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈

 

3) 파이프 - 필터 패턴 ★
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화해 파이프를 통해 데이터를 전송하는 패턴

- 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장 용이

- 필터 컴포넌트들을 재배치하여 다양한 파이프라인 구축 가능

# UNIX의 Shell

 

4) 모델 - 뷰 - 컨트롤러 패턴

- 서브 시스템을 3개의 부분으로 구조화하는 패턴

- 모델 : 서브시스템의 핵심 기능과 데이터를 보관

- 뷰 : 사용자에게 정보를 표시

- 컨트롤러 : 사용자로부터 받은 입력 처리 / 뷰 제어 / UI담당

- 각 부분은 별도의 컴포넌트로 분리되어 있으므로 서로 영향을 받지 않고 개발 작업 수행

- 한개의 모델에 대해 여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합

 

5) 마스터 슬레이브 패턴

- 마스터 컴포넌트에서 슬레이브 컴포넌트로 분할한 후 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴

 

6) 브로커 패턴

- 컴포넌트와 사용자를 연결해주는 패턴

 

7) 피어-투-피어 패턴

- 피어를 하나의 컴포넌트로 간주하며, 각 피어는 서비스를 호출하는 클라이언트가 될수도, 서비스를 제공하는 서버가 될 수 도 있는 패턴

 

8) 이벤트 - 버스 패턴

- 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리하는 방식

- 이벤트를 생성하는 소스, 이벤트를 수행하는 리스너, 이벤트의 통로인 채널, 채널들을 관리하는 버스

 

9) 블랙보드 패턴

- 해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴

 

10) 인터프리터 패턴

- 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할때 사용됨

 

[ 11 ] 객체지향

 

1) 객체

- 독립적으로 식별 가능한 이름을 갖고 있음

- 객체가 가질 수 있는 조건인 상태는 일반적으로 시간에 따라 변함

- 객체와 객체는 상호 연관성에 의한 관계가 형성됨

- 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며, 객체는 행위의 특징을 나타냄

- 객체는 일정한 기억장소를 갖고 있음

 

2) 클래스 ★ ★

- 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것 ★

- 공통된 속성과 연산을 갖는 객체의 집합

- 객체지향 프로그램에서 데이터를 추상화하는 단위 ★

- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀

- 슈퍼 클래스는 특정 클래스의 상위 클래스

- 서브 클래스는 특정 클래스의 하위 클래스

 

3) 인스턴스

- 클래스에 속한 각각의 객체

- 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화라고 함

 

4) 메서드

- 클래스로부터 생성된 객체를 사용하는 방법

- 전통적 시스템의 함수 또는 프로시저에 해당하는 연산

 

5) 메시지

- 객체에게 어떤 행위를 하도록 지시하기 위한 방법

 

6) 캡슐화 ★

- 데이터와 데이터를 처리하는 함수를 하나로 묶는것

- 인터페이스를 제외한 세부 내용이 은폐되어 외부 접근이 제한됨

- 정보은닉 측면과 가장 밀접한 관계가 있음

- 외부 모듈의 변경으로 인한 파급 효과가 적음

- 재사용 용이, 인터페이스 단순해짐

- 결합도 ▼, 응집도 ▲

 

7) 상속

- 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려 받는것 

- 소프트웨어의 재사용을 높이는 중요한 개념

 

8) 다중 상속

- 한개의 클래스가 두개 이상의 상위 클래스로부터 속성과 연산을 상속 받는 것

 

9) 다형성

- 하나의 메시지에 대해 각각의 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

ex)  +연산자의 경우 숫자 클래스에서는 덧셈, 문자열 클래스에서는 문자열의 연결 가능

 

[ 12 ] 결합도 ★ ★

- 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미

- 결합도가 낮을수록 좋다. == 독립적인 모듈

 

1) 내용 결합도

- 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도

 

2) 공통 결합도

- 공유되는 공통 데이터 영역을 여러 모듈이 사용할 떄의 결합도 ( 전역 변수 )

 

3) 외부 결합도

- 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도

 

4) 제어 결합도

- 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도

 

5) 스탬프 결합도

- 모듈간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도

 

6) 자료 결합도

- 어떤 모듈이 다른 모듈을 호출하면서 파라미터나 인수로 데이터를 넘겨주고, 호출 받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 결합도

 

[ 13 ] 응집도 ★ ★

- 모듈의 내부 요소들의 서로 관련되어 있는 정도

- 응집도는 높을수록 좋다 == 독립적인 모듈

 

1) 우연적 응집도

- 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

 

2) 논리적 응집도

- 유사한 성격을 갖거나 특정 형태로 분류되는 처리 오소들로 하나의 모듈이 형성되는 경우의 응집도

 

3) 시간적 응집도

- 특정 시간에 처리되는 몇개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도

 

4) 절차적 응집도

- 모듈이 다수의 관련 기능을 가질때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도

 

5) 통신적 응집도

- 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도

 

6) 순차적 응집도

- 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도

 

7) 기능적 응집도

- 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도