[정보처리기사 실기 대비] 요구사항 확인 파트 (1)

young-gue Park·2024년 9월 26일

CS

목록 보기

13/18

⚡ 정보처리기사 실기 준비 1

들어가기 전에...

필기는 당연히 합격했습니다.
근데 이 필기를 보기 전에 해프닝이 있었는데 그 얘기를 좀 해보고 가려합니다.
정보처리기사와 정보처리기'능'사는 엄연히 다른 자격증인거 다들 아실겁니다.
저도 모르던 사실은 아니었구요. 난이도는 전공자라면 기능사보다 기사가 더 높다고 느낄겁니다.
문제는 제가 비전공자였다는 사실이죠.

그러니까 문제집을 구매할 당시에 표지에 적힌 제목을 한번만 다시 봤더라면,
기사가 아닌 기'능'사라고 써져있는 그 제목을 다시 봤더라면 이런 사태는 일어나지 않았을겁니다.

그리고 비전공자인 내가 처음 기능사 문제를 풀기 시작하면서 크게 이상한 점을 느끼지 못했다는 것...
시험 하루 전에서야 많이 이상함을 깨닫고 사태의 전말을 알게 되었습니다.
뭐 어쩌겠습니까. 그냥 그 날 밤새서 정처기 필기 기출문제를 마구잡이로 외우기 시작했고, 그래도 개발 3년 짬밥 덕택에 알고있던 것들이 많아 합격하긴 했습니다. 다시 생각해보면 참으로 아찔한 경험이었네요. 여러분은 헷갈리지 마세요...

📃 요구사항 확인 (1)

소프트웨어 생명 주기
- 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
- 소프트웨어 개발 단계와 각 단계별 주요 활동 그리고 활동의 결과에 대한 산출물로 표현
나선형 모형(점진적 모형)
- 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 모형
- 계획 수립 - 위험 분석 - 개발 및 검증 - 고객 평가 순으로 반복

폭포수 모형(고전적 생명 주기 모형)
- 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론

애자일 모형
- 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
- 특정 개발 방법론이 아니라 고객과의 소통에 초점을 맞춘 방법론을 통칭
- 스크럼, XP, 칸반, Lean, 기능 중심 개발 등

애자일 개발 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
- 계약 협상보다는 고객과 협업에 더 가치를 둔다.
- 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.
소프트웨어 공학
- 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
- 소프트웨어 공학의 기본 원칙
  1) 현대적인 프로그래밍 기술을 계속적으로 적용해야한다.
  2) 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야한다.
  3) 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야한다.
스크럼 개발 프로세스

프로세스	내용
스프린트 계획 회의	제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의
스프린트	실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행
일일 스크럼 회의	모든 팀원이 매일 약속된 시간에 약 15분 동안 진행 상황을 점검하는 회의, 남은 작업 시간은 번다운 차트에 표시
스프린트 검토 회의	부분 또는 전체 완성 제품이 요구사항에 잘 부합하는지 테스팅하는 회의
스프린트 회고	정해놓은 규칙 준수 여부 및 개선할 점을 확인하고 기록하는 것

XP(eXtreme Programming)
- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 5가지 핵심 가치(의단용존피)
  의사소통
  단순성
  용기
  존중
  피드백
XP의 주요 실천 방법

1) Pair Programming
- 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성한다.
2) Collective Ownership
- 개발 코드에 대한 권한과 책임을 공동으로 소유한다.
3) Test-Driven Development
- 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하므로 자신이 무엇을 해야할지를 정확히 파악한다.
- 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 구조(구조, 프레임워크)를 사용한다.
4) Whole Team
- 개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 한다.
5) Continuous Integration(CI)
- 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합된다.
6) Refactoring
- 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발할 수 있도록 하기 위해 프로그램의 기능의 변경 없이 시스템을 재구성한다.
7) Small Relesases
- 릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있다.
데이터베이스 관리 시스템(DBMS)
- 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고, 데이터베이스를 관리해 주는 소프트웨어
- 요구사항 식별 시 고려사항(가성기상구)
  가용성
  성능
  기술 지원
  상호 호환성
  구축 비용
기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지 등의 기능이나 수행과 관련된 요구사항
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는 지에 대한 사항
- 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항
- 시스템이 반드시 수행해야하는 기능
- 사용자가 시스템을 통해 제공받기를 원하는 기능
비기능 요구사항
- 품질이나 제약사항과 관련된 요구사항
- 시스템 장비 구성 요구사항
- 성능 요구사항
- 인터페이스 요구사항
- 데이터를 구축하기 위해 필요한 요구사항
- 테스트 요구사항
- 보안 요구사항
- 제약사항
- 프로젝트 관리 요구사항
- 프로젝트 자원 요구사항
- 품질 요구사항: 가용성, 정합성, 대응성, 보안성, 상호 호환성, 이식성, 확장성 등
요구사항 명세 기법

5가지 핵심 가치(의단용존피)
의사소통
단순성
용기
존중
피드백

요구사항 식별 시 고려사항(가성기상구)
가용성
성능
기술 지원
상호 호환성
구축 비용

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화된 표기법	일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성
특징	요구 사항을 정확하고 간결하게 표현, 결과가 일관성이 있어 완전성 검증이 가능, 표기법이 어려움	자연어 사용으로 인해 요구사항 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지고 해석이 달라질 수 있지만 이해가 쉬워 의사소통이 용이함
종류	`VDM`, `Z`, `Petri-net`, `CSP` 등	`FSM`, `Decision Table`, `ER Modeling`, `State Chart` 등

요구사항 개발 프로세스
- 개발 대상에 대한 요구사항을 체계적으로 도출하고 분석한 후 명세서에 정리한 다음 확인 및 검증하는 일련의 구조화된 활동
- 진행되기 전에 타당성 조사가 선행되어야 함
- 도출 - 분석 - 명세 - 확인

요구사항 분석
- 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화하는 활동
- 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정

자료 흐름도(DFD)
- 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
- 자료 흐름 그래프, 버블 차트라고도 한다.

자료 흐름도의 구성 요소(프자자단)

기호	의미
프로세스	자료를 변환시키는 시스템의 한 부분을 나타내며 처리, 기능, 변환, 버블이라고도 함
자료 흐름	자료의 이동이나 연관관계를 나타냄
자료 저장소	시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄
단말	시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고 출력 데이터를 받음

자료 사전(메타 데이터)

자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것

기호	의미
=	`자료의 정의`: ~로 구성되어 있다
+	`자료의 연결`: 그리고
()	`자료의 생략`: 생략 가능한 자료
[]	`자료의 선택`: 또는
{}	`자료의 반복`: Iteration of
* *	`자료의 설명`: 주석

SADT
- 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위한 도구
- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구
HIPO
- 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법
- 시스템 실행 과정인 입력/처리/출력의 기능을 표현한 것
- 하향식 소프트웨어 개발을 위한 문서화 도구
- HIPO Chart

UML
- 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
- UML의 구성 요소(사관다)
  사물
  관계
  다이어그램

UML의 구성 요소(사관다)
사물
관계
다이어그램

연관 관계
- 2개 이상의 사물이 서로 연관되어 있는 관계
- 사물 사이를 실선으로 연결하여 표현하며 방향성은 화살표로 표현
- 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결
- 다중도를 선 위에 표기

집합 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계
- 포함하는 쪽과 포함되는 쪽은 서로 독립적이다.
- 포함되는 쪽에서 포함하는 쪽으로 속이 빈 마름모를 연결하여 표현

포함 관계
- 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
- 포함하는 쪽과 포함되는 쪽은 서로 독립될 수 없고 생명주기를 함께한다.
- 집합 관계와 다르게 속이 채워진 마름모를 연결하여 표현

일반화 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
- 일반적인 개념을 상위 혹은 부모라고 부르고 더 구체적인 개념을 하위 혹은 자식이라고 부른다.
- 하위에서 상위 쪽으로 빈 화살표를 연결하여 표현

의존 관계
- 연관 관계와 같이 사물 사이에 서로 연관은 있으나 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
- 하나의 사물과 다른 사물이 소유 관계는 아니지만 사물의 변화가 다른 사물에도 영향을 미치는 관계
- 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현

실체화 관계
- 사물이 할 수 있거나 해야하는 기능, 서로를 그룹화 할 수 있는 관계
- 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
- 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
- 인터페이스!

다이어그램
- 사물과 관계를 도형으로 표현한 것
- 여러 관점에서 시스템을 가시화한 뷰를 제공하여 의사소통에 도움을 줌
- 정적 모델링에서는 구조적 다이어그램을, 동적 모델링에서는 행위 다이어그램을 주로 사용

구조적 다이어그램의 종류

1) 클래스 다이어그램
- 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현
예시 출처

2) 객체 다이어그램
- 클래스에 속한 객체들(인스턴스)을 특정 시점의 객체와 객체 사이의 관계로 표현
- 럼바우 객체지향 분석 기법에서 객체 모델링에 활용
예시 출처

3) 컴포넌트 다이어그램
- 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
- 구현 단계에서 사용
예시 출처

4) 배치 다이어그램
- 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
- 구현 단계에서 사용
예시 출처

5) 복합체 구조 다이어그램
- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
예시 출처

6) 패키지 다이어그램
- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현
예시 출처
행위 다이어그램의 종류

1) 유스케이스 다이어그램
- 사용자의 요구를 분석하는 것으로, 기능 모델링 작업에 사용
- 사용자와 사용 사례로 구성
예시 출처

2) 순차 다이어그램
- 상호작용하는 시스템이나 객체들이 주고받는 메시지를 표현
예시 출처

3) 커뮤니케이션 다이어그램
- 동작에 참여하는 객체들이 주고받는 메시지와 객체들 간의 연관 관계를 표현
예시 출처

4) 상태 다이어그램
- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는 지를 표현
- 럼바우 객체지향 분석 기법에서 동적 모델링에 활용
예시 출처

5) 활동 다이어그램
- 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현
- 플로우 차트와 비슷해서 헷갈릴 수도 있을듯 하다...
예시 출처

6) 상호작용 개요 다이어그램
- 상호작용 다이어그램 간의 제어 흐름을 표현
7) 타이밍 다이어그램
- 객체 상태 변화와 시간 제약을 명시적으로 표현
스테레오 타입
- UML에서 표현하는 기능 외에 추가적인 기능을 표현하는 것
- 길러멧이라고 부르는 겹화살괄호(《》) 사이에 표현할 형태를 기술한다.