2022년 정보처리기사 실기를 준비하면서 실기를 정리하면서 공부하려고 포스팅으로 정리해보고자 만들고 있습니다.
정보처리기사 실기시험 출제 경향
정보시스템 등의 개발 요구 사항을 이해하여
각 업무에 맞는 소프트웨어의 기능에 관한 설계, 구현 및 테스트를 수행에 필요한 지식을 함양합니다.
1. 현행 시스템 분석 및 요구사항 확인(소프트웨어 공학 기술의 요구사항 분석 기법 활용)
2. 데이터 입출력 구현(논리, 물리데이터베이스 설계, 조작 프로시저 등)
3. 통합 구현(소프트웨어와 연계 대상 모듈간의 특성 및 연계 모듈 구현 등)
4. 서버프로그램 구현(소프트웨어 개발 환경 구축, 형상 관리, 공통 모듈, 테스트 수행 등)
5. 인터페이스 구현(소프트웨어 공학 지식, 소프트웨어 인터페이스 설계, 기능 구현, 구현검증 등)
6. 화면설계(UI 요구사항 및 설계, 표준 프로토 타입 제작 등)
7. 애플리케이션 테스트 (테스트 케이스 설계, 통합 테스트, 성능 개선 등)
8. SQL 응용(SQL 작성 등)
9. 소프트웨어 개발 보안 구축(SW 개발 보안 설계, SW개발 보안 구현 등)
10. 프로그래밍 언어활용(기본 문법 등)
11. 응용 SW기초 기술 활용(운영체제, 데이터베이스 활용, 네트워크 활용, 개발환경 구축 등)
12. 제품 소프트웨어 패키징(제품 소프트웨어 패키징, 제품소프트웨어 매뉴얼 작성 , 버전 관리등 )
현행 시스템 및 요구사항 확인1
요구사항 확인(요구분석기법/UML/에자일)
1. 요구사항
요구사항
- 요구사항이란 소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명과 정상적으로 운영되는데 필요한 제약조건을 말한다.
- 소프트웨어 개발/유지보수 과정에서 필요한 기준, 근거 제공
- 개발 참여 이해관계자들간 의사소통의 원할에 기여
기능/비기능 요구사항
- 기능 요구사항(Functional Requirements)
- 시스템이 무엇을 하는지, 어떤기능을 하는지에 대한 기능, 수행에 관련된 요구사항
- 시스템이 반드시 수행해야 하는 기능으로 입력/출력, 어떤 데이터 저장/연산, 사용자가 제공받는 시스템 기능 등
- 비기능 요구사항(Non-functional Requirements)
- 시스템 품질, 제약사항과 관련된 요구사항
- 시스템 장비 구성, 성능 요구사항, 인터페이스 요구사항, 데이터 구축 요구사항, 테스트 요구사항, 보안 요구사항, 제약사항, 프로젝트 관리/자원 요구사항
- 품질 요구사항 : 가용성, 정합성, 상호 호환성, 대응성, 이식성, 확장성, 보안성 등
요구사항 개발 프로세스
- 요구사항 개발 프로세스는 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석 후, 명세서에 정리하고 확인 및 검증하는 구조화된 활동
- 요구사항 프로세스 진행 전 타당성조사(Feasibility Study)가 중시되어야 함
- 요구사항 프로세스 순서 : 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인(Validation)
요구사항 명세(Requirement Specificaton)
- 분석된 요구사항을 바탕으로 모델을 작성하고 문서화하는 것
- 기능 요구사항(필수), 비기능 요구사항(필요한 것)을 기술한다.
- 구체적인 명세를 위해 소단위 명세서가 사용될 수 있다.
- 요구사항 명세기법
요구사항 분석
- 소프트웨어 개발의 첫 단계, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동
- 사용자 요구 타당성 조사 및 비용/일정에 대한 제약 설정
- 사용자 요구를 정확히 추출해 목표를 설정함
자료흐름도(DFD : Data Flow Diagram)
- 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 구조적 분석 기법에 이용되며, 자료흐름 그래프, 버블차트라고 부름
- 자료흐름도 구성요소
| 기호 | 의미 |
| 프로세스(Process) | 자료를 변환시키는 시스템의 처리과정을 나타내며 처리, 기능 변환, 버블이라고도 함 |
| 자료 흐름(Data Flow) | 자료의 이동(흐름)이나 연관관계를 나타냄 |
| 자료 저장소(Data Store) | 시스템에서의 자료 저장소(파일/데이터베이스)를 나타냄 |
| 단말(Terminator) | 시스템과 교신하는 외부개체로, 입력데이터가 만들어지고 출력데이터를 받음 |
자료사전(DD : Data Dictionary)
- 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 사항
- 자료를 설명하는 데이터 : Meta Data(메타데이터, 데이터의 데이터)
| 기호 | 의미 |
| = | 자료의 정의 : ~로 구성되어 있다 |
| + | 자료의 연결 : 그리고(and) |
| () | 자료의 생략 : 생략 가능한 자료(Optional) |
| [] | 자료의 선택 : 또는(or) |
| {} | 자료의 반복 : Iteration of |
| ** | 자료의 설명 : 주석(Comment) |
데이터 요구사항 분석용 CASE(자동화 도구)
- SADT, SREM, PSL/PSA, TAGS
- 대표적인 요구사항 분석용 CASE : SADT, SREM, PSL/PSA, TAGS
- SADT* : 시스템 정의 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구, 구조적 요구 분석을 위한 블록다이어그램을 채택한 자동화 도구, SoftTeck사에서 개발
- HIPO* : 시스템 실행과정 입력/처리/출력의 기능을 표현한 것(시스템 분석/설계, 문서화에 이용)으로 하향식 소프트웨어 개발을 위한 문서화 도구이다.
- HIPO Chart : 시스템의 기능을 여러 고유모듈로 분할해, 기능간 인터페이스를 계층구조로 표현한 것.
2. UML(Unified Modeling Language)
UML(Unified Modeling Language)
- 시스템 개발과정에서 개발자 ~ 고객, 개발자 ~개발자 간의 의사소통이 원할이 이루어지도록 표준화한 대표적인 객체지향 모델링 언어를 말한다.
- UML 구성요소 : 사물(Things), 관계(Relationships), 다이어그램(Diagram)
- 럼바우(OMT), Booch, Jacobson 등 객체지향 방법론의 장점 통합
관계(RelationShips)
- 사물과 사물 사이의 연관성을 표현하는 것
- 종류 : 연관관계, 집합관계, 포함관계, 일반화 관계, 의존관계, 실체화 관계
- 연관관계 : 2개 이상의 사물이 서로 관계되어 있는 관계(화살표)
- 집합관계 : 하나의 사물이 다른 사물에 포함되어 있는 관계(빈 마름모)
- 포함관계 : 포함하는 사물의 변화가 포함되는 사물에게 여향을 미치는 관계(검은 마름모)
- 일반화관계 : 하나의 사물이 다른 사물에 대해 더 일반적이거나 구체적인 관계(상위-하위, 부모 관계, 실선 화살표)
- 실체화관계 : 사물이 할 수 있거나 해야하는 기능, 서로를 그룹화 할 수 있는 관계(상위 하위, 부모 관계, 점선 화살표)
- 의존 관계 : 서로에게 영향을 주는 짧은 시간동안만 연관을 유지하는 관계(점선 화살표)
3. 애자일 모형, 폭포수 모형, 나선형 모형, 프로토타입 모형
애자일 모형(Agile)
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
- 좋은 것을 빠르고 낭비없이 만들기 위한 고객과의 소통에 초점을 둔 방법론
- 대표적인 개발모형 : 스크럼(Scrum), XP(eXtreme Programming), Kanban, Lean, 기능중심개발
애자일 개발 4가지 핵심가치
- 프로세스와 도구보다 개인과 상호작용에 더 가치를 둠
- 방대한 문서보다 실행되는 SW에 더 가치를 둠
- 계약 협상보다 고객과 협업에 더 가치를 둠
- 계획에 따르기보다 변화에 반응하는 것에 더 가치를 둠
XP(eXtreme Programming)
- XP(eXtreme Programming)은 고객의 요구사항에 유연하게 대응하기 위해 고객참여, 개발과정 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 짧고 반복적인 개발주기, 단순 설계, 고객의 적극적 참여를 통한 빠른 SW개발
- XP 5가지 핵심가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
XP 주요 실천 방법
- Pair Programming : 다른사람과 함께 프로그래밍 수행, 개발에 대한 공동책임
- Collective Ownership : 개발코드에 대한 권한/책임 공동 소유
- Refactoring : 프로그램의 기능의 변경 없이 시스템 재구성, 프로그램의 쉬운 이해/수정 및 개발을 위함
- Continuous integration: 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합됨
- Test-Driven Development : 실제코드 작성전, 테스트 케이스를 작성하여 무엇을 해야할지 정확히 파악함, 테스트가 지속적으로 진행될 수 있도록 테스팅도구(구조, 프레임 워크)를 사용함
- Whole Team : 개발에 참여하는 모든 구성원들은 자신의 역할이 있고 책임져야함
- small Releases : 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다.
나선형 모형(Spiral Model)
- 여러번의 소프트웨어 개발과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
- 4가지 주요활동 : 계획수립 → 위험 분석 → 개발 및 검증 → 고객 평가
폭포수 모형(Waterfall Model)
- 각 단계를 확실히 매듭짓고 결과를 철저히 검토하여 승인과정을 거친 후 다음단계를 진행하는 개발방법론
- 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명주기 모형
- 고전적 생명주기 모형
프로토타입 모형(Prototype Model)
- 실제 개발될 SW에 대한 Prototype을 만드렁 최종 결과물을 예측하는 모델
DB관리 시스템(DBMS : Database Management System)
- 사용자와 db사이에서 사용자의 요구에 따라 정보를 생성하고 DB를 관리해주는 시스템
- DBMS 요구사항 식별 시 고려사항 : 가용성, 성능, 기술지원, 상호호환성, 구축비용
4. 다이어그램
다이어그램(Diagram)
- 다이어그램(Diagram)은 사물과 관계를 도형으로 표현한 것으로 시스템을 가시화한 뷰(view)를 보여주어 의사소통에 도움을 준다.
- 정적 모델링 : 구조적 다이어그램
- 동적 모델링 : 행위 다이어그램
구조적 다이어그램의 종류
- 클래스 다이어그램 : 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
- 객체 다이어 그램 : 클래스에 속한 사물(객체)들, 인스턴스를 특정 시점의 객체와 객체사이의 관계로 표현, 럼바우 객체지향 분석 기법에서 객체 모델링으로 사용됨
- 컴포넌트 다이어그램 : 실제 구현 모듈인 컴포넌트 등 물리적 요소들의 위치를 표현한다.
- 배치 다이어그램 : 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현한다. 구현 단계에서 사용
- 복합체 구조 다이어 그램 : 클래스, 컴포넌트가 복합 구조를 갖는 경우 내부구조를 표현한다.
- 패키지 다이어그램 : usecase나 class등 모델 요소들의그룹화한 패키지들의 관계를 표현한다.
행위 다이어그램의 종류
- 유스케이스 다이어그램(use case Diagram) : 사용자 요구를 분석하는 것으로 기능 모델링 작업에 사용함, 사용자와 사용사례로 구성됨
- 시퀀스 다이어 그램(Sequence Diagram) : 상호작용하는 시스템이나 객체들이 주고받는 메세지를 표현
- 상태 다이어그램(State Diagram) : 하나의 객체가 자신이 속한 클래스의상태변화, 다른 객체와 상호작용에 따라 상태가어떻게 변화하는지 표현
- 커뮤니케이션 다이어그램(Communication Diagram) : 동작에 참여하는 객체들이 주고 받는 메세지와 객체들 간의 연관관계를 표현
- 활동 다이어그램(Activity Diagram) : 시스템이 어떤 기능을 수행하는지 객체 처리 로직,조건에 따른 처리의 흐름을 순서에 따라 표현
- 상호작용 다이어그램 : 상호작용 다이어그램간 제어 흐름을 표현
- 타이밍 다이어그램 : 객체 상태 변화와 시간 제약을 명시적으로 표현
스테레오 타입(Steretype)
UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하는 것, 길러멧(Guilemat) '<< >>' 로 표현
댓글