본격적으로 정보처리기사가 되기 위한 공부를 해보려고 한다. 필기의 경우 기출이 중요하긴 하지만 그래도 기출 풀어보기 전에 작년에 밤새워가며 죽어라 했던 전공 과목들 기억들 되살릴겸 중요 개념부터 다잡고 가보자.
1과목은 소프트웨어 '설계'다. 어느정도 다 익숙한 내용들이긴 하다.
목차는 위와 같다. 1과목 소프트웨어 설계에서는 다음 4가지가 크게 중요 포인트다.
- SW 생명 주기
- UML
- 객체 지향 구성 요소
- 모듈
1. 소프트웨어 생명 주기
소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)
: SW 제품이 기획 단계에서부터 배포, 유지 보수에 이르기까 거치는 전체 과정으로, 품질, 효율성, 비용 절감을 목표로 한다.
1-1. SDLC 주요 단계
-
요구사항 수집 및 분석
프로젝트의 목적과 목표를 정의하고, 사용자와 이해관계자의 요구사항을 분석한다. 고객이 원하고 필요로 하는 기능을 명확히 파악하는 단계라고 생각하면 된다. -
설계 (Design)
요구사항을 바탕으로 시스템의 구조를 설계한다. 여기에는 데이터베이스 구조, 소프트웨어 아키텍처, UI 설계 등이 포함되며, 시스템의 큰 그림과 세부 설계를 포함한다. -
구현 (Coding)
설계된 내용을 바탕으로 실제 코드를 작성하여 소프트웨어를 개발한다. 개발된 소프트웨어의 기능이 올바르게 작동하는지 검증할 수 있도록 코딩 표준을 준수하며 진행한다. -
테스트 (Testing)
개발이 완료된 소프트웨어를 검증하고, 오류나 결함을 찾아 수정한다. 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 수용 테스트 등 다양한 테스트 과정을 거친다. -
유지보수 (Maintenance)
배포 이후 발생하는 문제를 해결하고, 기능을 개선하거나 추가한다. 사용자 피드백을 반영하여 개선할 뿐 아니라, 소프트웨어가 최신 기술에 맞게 지속적으로 발전할 수 있도록 리팩토링한다.
1-2. SDLC 모델
- 폭포수 모델(Waterfall Model)
- 각 단계가 순차적으로 진행되는 모델
- 보헴이 제시
- 간단하고 체계적, 요구사항이 고정된 프로젝트에 적합
- 단계가 순차적이라 중간에 변경이 어렵고, 후반 단계에서 문제 발견되면 해결하기 어려움
- Prototyping Model
- 초기에 prototype(시제품)을 제작하고 사용자에게 피드백을 받아 수정 및 보완을 거쳐 최종 제품을 완성하는 모델
- 요구사항 정확히 반영하는데 유리함
- 반복적인 프로토타이핑은 시간과 비용을 늘림
- 나선형(Spiral) 모델
- 위험 요소 분석과 반복 개발을 결합한 모델로, 단계마다 위험을 평가하고 해결해 소프트웨어를 점진적으로 완성
- 보헴이 제안
- 폭포수+프로토타입 장점에 위험 분석 기능 추가한 모형
- 위험 요소를 관리해 대규모 프로젝트에 적합
- 복잡하고 비용이 많이 발생하는 경향이 있음
- RAD(Rapid Application Development) 모델
- 빠른 개발을 위해 프로토타이핑과 사용자 피드백을 활용해 짧은 주기로 소프트웨어 개발하는 모델
- 짧은 시간, 사용자 요구에 유연하게 대응
- 복잡한 프로젝트에서는 관리가 어려움
*Agile 모델
고객의 요구사항 변화에 유연하게 대응하는 모델
- 반복적, 점진적 개발(Iteration & Increment)
- 빠른 피드백 및 짧은 개발 주기
- 최소한의 문서화, 코드 중심
- 지속적인 고객 협업 및 피드백 & 테스트(TDD, CI/CD)
- 스타트업에서 주로 사용
위에서 언급한 구조적 개발론에 해당하는 모델들과, 애자일 방법론을 비교한 표이다.
추가로 설계 패러다임도 비교해보자. 구조적 개발과 객체지향을 비교한 표이다.
객체지향은 '재사용성'과 '유지보수'가 중요하다. 뒤에서 더욱 자세히 정리하겠다.
Agile에는 세부 모델들도 몇 가지 존재한다. 이것도 정리해보자.
- Scrum: 팀원들이 정해진 기간내에 목표를 달성하기 위해 함께 달리는 방식
- 스프린트: 1-4주 단위의 짧은 개발 반복 주기
- backlog: 우선순위가 매겨진 요구사항 목록
- XP(Extreme Programming): 개발의 극단적인(Extreme) 효율을 추구하며, 기술적인 실천 사항을 강조하는 동시에 고객의 요구사항에 즉각 대응한다.
- Pair Programming (짝 프로그래밍): 개발자 둘이서 한 컴퓨터로 코딩
- TDD (테스트 주도 개발): 코드 짜기 전에 테스트 케이스부터 만들기
- Refactoring (리팩토링): 기능은 그대로 두되 코드 구조를 개선
- Collective Ownership: 공동 코드 소유
- CI(Continuous Integration): 계속적인 통합
XP는 5가지 핵심 가치를 기반으로 한다. 주요 포인트니 잘 외워두도록 하자.
'용단커피존'
- 용기(courage)
- 단순성(simplicity)
- 의사소통(communication)
- 피드백
- 존중(Respect)
- 칸반(Kanban): 업무가 정체되지 않게 시각적으로 관리하는 방식
화이트보드에 포스트잇을 붙여 관리하는 모습을 상상해보자
- WIP(Work In Progress) 제한: 지금 하는 일의 개수를 제한해서 업무 과부화 방지
- 기능 중심 개발(FDD: Feature Driven Development): 사용자에게 의미 있는 '기능'단위를 기준으로 개발 계획을 세우는 방식
2. 요구사항 분석
요구사항 분석이란, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동을 의미한다.
SW 개발의 실질적인 첫 단계이며, 사용자 요구의 타당성을 조사하고, 비용과 일정에 대한 제약을 설정한다. 그에 따른 목표와 해결 방식을 결정하는 것까지 포함된다.
또한, 요구사항 개발 프로세스는 다음과 같은 4단계를 따른다.
도출(Elicitation) -> 분석(Analysis) -> 명세(specification) -> 확인(validation)
주요 비기능 요구사항에는 다음과 같은 5가지가 있다.
- 성능 요구사항
- 보안 요구사항
- 품질 요구사항
- 제약 사항
- 인터페이스 요구사항
요구사항 분석 단계에서, '구조적 개발 방법론'에서 사용하는 3가지 핵심 도구들을 알아보자.
- DFD(자료흐름도)
- DD(자료사전)
- Mini-Spec(소단위명세서)
- 자료 흐름도(DFD, Data Flow Diagram)
데이터가 어디서 들어와서 어떻게 변하고 어디로 나가는지 보여준다. 시간 흐름은 알 수 없으며, 데이터의 흐름에만 집중한다. 구성 요소도 외워두자.
- 단말(Terminator)은, 시스템 바깥에 위치하며, 시스템과 데이터를 주고 받는 '외부 개체'이다.
- 입력 화살표가 있다고 해서 꼭 '출력' 화살표가 있어야 하는 것은 아니다.
- bubble chart라고도 함(process를 원으로 표시)
- 구조적 분석 기법에 이용됨
- 자료 사전(DD, Data Dictionary)
DFD에 등장하는 데이터들의 의미를 약속된 기호로 정의한다. 시험에 기호 의미를 묻는 문제가 자주 출제되니 이미지를 기억해두자.
- 소단위 명세서(Mini-Spec)
자료 흐름도의 최하위 프로세스가 어떤 로직으로 돌아가는지 설명한다.
3. UML(Unified Modeling Language)
UML은 시스템 개발자와 고객, 혹은 개발자 상호간의 의사소통을 원활하게 표준화하기 위한 대표적인 객체지향 모델링 언어이다.
3-1. UML 3대 구성 요소
- 사물(Things): 모델을 구성하는 기본 요소 (클래스, 인터페이스, 유스케이스 등)
- 관계(Relationships): 사물과 사물 사이의 연관성을 표현 (상속, 포함, 실체화 등) - 1:1, 1:N, N:N
- 다이어그램(Diagram): 사물과 관계를 시각적으로 모아놓은 그림
*UML의 주요 관계
- 일반화(Generalization) 관계: 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현한다. ex. Java의 extends(상속)
- 의존(Dependency) 관계: 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현한다.
- 실체화(Realization) 관계: 사물이 할 수 있거나 해야 하는 기능으로 서로를 그룹화 할 수 있는 관계를 표현한다. 인터페이스를 클래스가 구현하는 단계이다. ex. Java의 implements(구현)
다이어그램 구조도는 아래와 같다.
3-2. 구조적 다이어그램(Structural / Static)
시스템의 정적인 모습을 그린다. 건물의 설계도처럼 '무엇이 있는가'에 집중한다.
- Class Diagram
시스템 내의 클래스들의 관계를 표현하며, 첫 번째 블록은 클래스의 이름, 두 번째 블록은 클래스의 '속성', 세 번째 블록은 클래스의 메서드들을 나타낸다.
클래스들간의 연관관계는 위와 같이 나타낸다.
이건 순서대로 Association(연관), Inheritance(상속), Realization/Implementation(실체화), Dependecny(의존), 집합(Aggregation), 합성(Composition)을 나타내는 화살표들이다. 이 화살표들은 객체 다이어그램에서도 똑같이 사용된다.
연관(Association) ───── "사용한다"
집합(Aggregation) ◇──── "가지고 있다" (부분이 독립 존재 가능)
합성(Composition) ◆──── "구성된다" (부분이 독립 존재 불가)
일반화(Inheritance) ────▷ "상속이다" (is-a)
의존(Dependency) ----→ "잠깐 사용한다"
실체화(Realization) ----▷ "인터페이스 구현"-
Object Diagram(객체 다이어그램)
'특정 시점'의 객체 간의 관계를 표현하는 다이어그램이다. -
Component Diagram
물리적인 모듈(Component) 간의 구조와 의존성을 표현한다. -
Deployment(배치) Diagram
시스템의 물리적인 구조를 보여주며, 어떤 SW가 어떤 하드웨어에서 동작하고 있는지를 보여준다. -
Composite Structure(복합체 구조) 다이어그램
클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현한다. -
Package Diagram
유스케이스나 클래스 드의 모델 요소들을 그룹화한 패키지들의 관계를 표현한다.
구조적 다이어그램을 정리하면 다음과 같다.
3-3. 행위 다이어그램(Behaviroal / Dynamic)
시스템의 '동적인 모습'을 그린다. 영화 시나리오처럼 "어떻게 움직이는가"에 집중한다.
-
Use Case Diagram
사용자와 시스템 간의 상호작용을 '기능 위주'로 표현한다. 주로 사람이 주액터에 해당하고, 주액터의 목적 달성을 위한 외부 시스템인 조직이나 기관이 부액터에 해당한다. -
Sequence Diagarm(순차 다이어그램)
객체 간 주고받는 메시지를 '시간 순서'에 따라 표현한다. '시간 순서'를 표현한다는 점에서 매우 중요하며, 가장 출제 비율이 높은 다이어그램이다.
중요한 만큼, 5가지 구성 요소를 살펴 보자.
-
Actor: 시스템으로부터 서비스를 받는 외부 존재, 사람 모양의 아이콘(stick figure)로 나타낸다.
-
Object(객체): 메시지를 주고 받는 실체로 '이름:클래스명' 형식으로 표기하며, 사각형(박스)로 나타낸다.
-
Lifeline(생명선): 객체가 메모리에 존재하는 기간을 의미하며, 객체 아래로 내려오는 점선으로 표기한다. 위에서 아래로 내려오며, 객체가 소멸하면 끝에 'x'표시를 한다.
-
Message(메시지): 객체 간에 주고 받는 데이터나 지시 사항으로, 실선, 점선, 화살표 등으로 표현한다. 메시지의 종류는 아래와 같다.
-
Active Box(실행 상자): 객체가 메시지를 받아 실제로 동작 중인 시간을 의미하며, 생명선 위에 그려지는 긴 직사각형으로 표기한다. 이 박스가 길다는 것은 해당 객체가 그만큼 오랫동안 일을 하고 있다는 것을 의미한다.
-
Communication Diagram
객체 간의 메시지 전달 뿐만 아니라 '연관 관계' 자체에 집중한다. -
State Diagram(상태 다이어그램)
하나의 객체가 가질 수 있는 '상태의 변화'를 표현한다. 다른 객체와의 상호 작용에 따른 상태 변화도 표시하며, 모든 가능한 상태와 전이를 표현할 수 있다. -
Activity Diagram(활동 다이어그램)
시스템이 어떤 기능을 수행하는지를 개체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현한다.
행위 다이어그램을 정리하자면 아래와 같다.
*Stereotype
: UML의 기본 도형(사각형, 화살표)만으로는 표현하기 부족한 추가적인 의미를 덧붙일 때 사용한다.
'Guilemet(길러멧)'이라고 불리는 겹화살표(≪ ≫) 사이에 적는다.
- ≪interface≫: 해당 클래스가 인터페이스임을 명시
- ≪include≫: 유스케이스 사이의 '포함' 관계
- ≪extend≫: 유스케이스 사이의 '확장' 관계
- ≪exception≫: 예외 처리 관련 내용임을 명시
*Rumbaugh(럼바우) 분석 기법(객·동·기)★
: 모든 SW 객체를 객체 -> 동적 -> 기능 모델링 순서로 분석하는 기법이다.
1. 1단계: 객체 모델링; 시스템의 정적 구조를 파악하며 객체 다이어그램을 사용한다.(객객)
2. 2단계: 동적(Dynamic) 모델링; 객체들 간의 제어 흐름, 상태 변화를 파악하며 상태 다이어그램을 사용한다.(동상)
3. 3단계: 기능 모델링; 어떤 데이터가 입력되어 어떤 결과가 나오는지 분석하며, 자료 흐름도(DFD)를 사용한다. (기자)
4. User Interface (UI)
사용자 인터페이스(UI, User Interface)는 사용자와 디지털 기기/시스템 간의 상호장욕을 매개하는 시각적, 기능적 요소(버튼, 화면, 아이콘, 레이아웃)을 의미한다.
4-1. UI 구분
UI는 사용자와 시스템이 어떻게 소통하느냐에 따라 크게 3가지로 나눌 수 있다.
- CLI(Command Line Inteface): 명령어를 직접 텍스트로 입력하는 방식 ex. DOS, Linux Terminal
- GUI(Graphical User Interface): 마우스와 아이콘을 이용해 그래픽으로 소통 ex. Windows, macOS, 모바일 앱
- NUI(Natural User Interface): 신체 부위, 음성 등의 인간의 자연스러운 행동 이용 ex. Siri, 키네틱 게임, 지문 인식 등
VUI(Voice User Interface, 음성)
OUI(Organic User Interface, 모든 사물이 인터페이스가 됨)
4-2. UI 설계의 4대 원칙
'직유학유'
1. 직관성(Intuitiveness): 굳이 설명하지 않아도 직관적으로 사용법을 알 수 있어야 한다.
2. 유효성(Efficiency): 사용자가 원하는 목적을 정확하고 완벽하게 달성해야 한다(오류 없이)
3. 학습성(Learnability): 처음 쓰는 사람도 배우기 쉬워야 하며, 한 번 배우면 잊어버리지 않아야 한다.
4. 유연성(Flexibility): 사용자의 실수나 요구사항을 최대한 수용하고 오류를 방지해야 한다.
4-3. UI 설계 도구
- Wirefrmae
- 화면의 뼈대(레이아웃)만 그리는 단계. 텍스트와 상자 위주
- 정밀도는 낮음
- Mockup
- 정적인 형태와 실제 화면과 유사한 디자인 결과물
- 정밀도는 중간
- 실제 동작하지는 않음(버튼을 누른다고 화면이 넘어가지는 않음)
- Storyboard
- 와이어프레임에 콘텐츠 설명, interaction을 상세히 적어놓은 문서
- 정밀도는 높은 편
- Prototype
- 실제 서비스처럼 동작이 가능하게 만든 동적 모형(시제품)
- 테스트용
- 정밀도는 매우 높은 편
- Use Cse
- 사용자 입장에서 시스템의 기능을 시나리오로 작성한 것
- 설계 도구 보다는 '사용자 중심의 기능 정의서'
- 논리적
*ISO/IEC 9126의 품질 특성
소프트웨어 품질을 6가지로 나눈 국제 표준
'기신사효유이'
- 기능성(Functionality): '기능이 제대로 작동하는가'
- 신뢰성(Reliability): '고장 없이 잘 돌아가며, 장애 발생 시 복구 가능한가'
- 사용성(Usability): '학습하기 쉬운가'
- 이식성(Portability): '다른 환경(다른 OS)에서도 실행 가능한가'
- 효율성(Efficiency): '자원 낭비 없이 빠른가(CPU 사용량)'
- 유지보수성(Maintainability): '고치기 쉬운가'
5. Software Architecture
SW 아키텍처의 기본 설계 과정은 '설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브시스템 구체화 -> 검토'의 순서를 따른다.
SW Architecture는 상위&하위 설계로 나눈다.
각 상위 & 하위에 어떤게 속하는지 꼭 기억해두자.
5-1. 상위 설계(큰 개념)
시스템의 전체적인 구조를 결정한다.
- 아키텍처 설계: 시스템의 전체적이 구조 정의한다
- 데이터 설계: 시스템에 필요한 정보를 어떤 구조로 저장할지 정의한다
- 인터페이스 정의: 시스템 내부 구성 요소들이 서로 어떻게 대화할지 정한다
- UI 설계: 사용자가 보는 화면의 외관을 설계한다.
5-2. 하위 설계(모듈 설계)
상위 구조에서 정한 큰 흐름의 내부를 구체적으로 설계한다.
'하위 설계 - 모듈 설계 - 컴포넌트'를 묶어서 외워두자.
- 모듈 설계: 각 구성 요소의 내부 기능을 정의한다.
- 자료 구조 설계: 모듈 내부에서 데이터를 어떤 방식으로 처리할지 상세히 정한다.
- 알고리즘 설계: 구체적인 로직이나 처리 순서를 설계한다.
5-3. 하향식 설계 (Top-Down) vs 상향식 설계 (Bottom-Up)
하향식 설계 및 상향식 설계를 할 때 테스트 환경의 보조 도구로 Stub과 Driver를 사용한다.
*HIPO
하향식 소프트웨어 개발을 위한 문서화 도구이다.
- 기호, 도표 등을 사용하므로 보기 쉽고, 이해하기도 쉽다.
- 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
*파이프-필터 패턴
아키텍처 패턴 중 하나로, 데이터를 단계별로 처리하는데, 각 단계가 필터 역할을 하고 데이터 전달 통로가 파이프라고 생각하면 된다. 데이터 변환으로 인한 오버헤드가 발생한다.
후기
역시 기사라 그런지 내용이 많긴 한것 같다. 전공 공부하면서 다 한번씩 봤던 내용이라 쓱 보면 되겠지,, 했는데 확실히 시간 투자를 많이 할 필요가 있을 것 같다. 꼭 자격증 때문만은 아니더라도 앞으로 내가 더 공부할 여러 지식들의 기반이 되는 지식이니까 기초를 쌓자라는 느낌으로 더 열심히 공부해봐야겠다.
