[정처기] 메타코드M 1-1,2강 소프트웨어 설계

시작하면서

해당 글은 메타 코드 M에서 지원하는 정처기 필기 장학생에 합격하여 글을 작성하게 되었습니다.
메타 코드 해당 강의 보러 가기

참고 사항

• 플랫폼 => 이 뜻은 참고할 주제라는 뜻입니다.
• 이렇게 형관펜이 되어 있는 곳은 시험에 나오거나, 강조하고 싶은 부분이 있을 때 표시할 것입니다.

정보 처리 기사 소개

정보 처리 기사는 꼭 필요합니다. 그에 대한 이유는 우리가 아는 네카쿠베라 뿐만 아니라, 자동차 , 무역, 패션 등에서 IT가 필요하기 때문입니다.
예를 들어, 음료수 회사에서 음료수 재고 관리 시스템, 임직원 인사정보관리 시스템 등이 있습니다.

정보처리기사란?

• IT 프로젝트의 전체 흐름에 대한 이해를 도와주는 자격증

소개

• 시험 과목
  • 필기 : 소프트웨어 설계 | 소프트웨어 개발 | 데이터베이스 구축 | 프로그래밍 언어 활용 | 정보시스템 구축 관리
  • 실기 : 정보처리 실무
• 합격 기준
  • 필기 : 100점 만점에 과목당 40점 이상, 전과목 평균 60점 이상
  • 실기 : 100점을 만점으로 하여 60점 이상

🖥️ 공부 전략

• 20년 개정 이후 기출문제와 함께 학습하기
• 제가 바탕으로 삼고 있는 강의는
  • 20년 개정 이후 빈출 개념 위주
  • 비전공자를 위한 쉬운 비유와 예시
  • 자주 묻는 선지는 강조
  • 실무에 필요한 개념이라면 추가
    하여 설명하고 있습니다.

---

현행 시스템 분석

요구 사항의 단계

• 현행 시스템 분석
• 요구사항 확인
• 분석 모델 확인

요구사항 확인 및 분석은 시스템 개발의 첫 단계이다.

현행 시스템 분석

• 플랫폼
  • 애플리케이션이나 서비스를 개발하고 실행할 수 있는 기반 환경(주로 소프트웨어)
• 플랫폼 성능 분석 시 고려하는 항목
  • 경과 시간(Turnaround Time) : 작업이 완료될 때까지의 시간
  • 사용률(Utilization): 작업이 진행될 동안의 자원 사용률(CPU, 메모리)
  • 응답시간(Response Time) : 작업 요청에 대한 응답이 올 때까지의 시간
  • 가용성(Availability) : 얼마나 안정적인가? (장애 가능성)

시스템

: 특정 기능을 수행하기 위해 다양한 구성 요소들이 상호 작용하는 통합된 구조(주로 소프트웨어 + 하드웨어)

현행 시스템 분석 시 고려하는 항목

• 운영체제

• DBMS

  • 성능 : 얼마나 빠르고, 많은 데이터를 처리할 수 있는가?
  • 가용성 : 얼마나 안정적인 시스템인가? (장애 가능성)
  • 상호 호환성 : 다양한 운영체제와 호화 가능한가?
  • 기술 지원 : 안정적인 기술 지원이 가능한가?
  • 구축 비용 : 라이센스 및 유지 보수 비용

• 네트워크 분석

  ---

  요구사항 확인

  요구 사항 분석

  • 소프트웨어가 무엇을 해야 하는 지 추적하고, 명세를 작성하는 작업

  • 사용자 요구 추출, 목표 설정, 어떤 방식으로 해결할 지 결정

  • 개발의 출발점이며, 실질적인 첫 단계 (요구 사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지 보수)

    요구사항 분석의 특징

  • 개발 비용이 많이 드는 단계는 아님 (유지 보수 단계에서 비용이 가장 많이 듦.)

  • 자료 흐름도, 자료 사전 등의 문서가 효과적으로 이용 가능

  • 코딩 / 개발 기술 보다는 청취, 인터뷰, 중재 등의 커뮤니케이션 기술이 중요함.

    기능적 요구사항과 비기능적 요구사항

  • 기능적 요구 사항은 시스템이 무엇을 해야 하는 지 초점을 맞춤.
    ex) 시스템이 무슨 일을 하는지 (태그를 붙이면, 알림이 가거나 / 특정 키워드를 입력하면 이스터테그가 발동하거나)

  • 비 기능적 요구 사항은 시스템이 어떻게 동작 해야 하는 지 초점을 맞춤. (성능, 품질, 보안 등)
    ex) 얼마나 빨라야 하고, 보안이 얼마나 좋아야 하고, 등등

    (Data Flow diagram, DFD)

  • 데이터가 프로세스를 따라 흐르면서 어떻게 변화하는 지를 보여주는 시각적 표현

  • 자표 흐름 그래프 또는 Bubble Chart로 표현하기도 함.

  • 구조적 분석 기법에 이용되며, 데이터 흐름에 가장 중심을 둠.
    - 구조적 분석 기법이란? : 복잡한 구조의 시스템을 간단한 구조의 시스템으로 분리함으로써, 쉽게 이해하고, 시스템의 기능과 데이터를 구조적으로 표현하는 기법
    

  • 시간의 흐름을 명확히 표현할 수 없음. (논리적 흐름 위주)

    데이터 흐름도의 구성 요소

  • 처리기 (Process) : 데이터를 처리하는 활동 or 기능, O (동그라미)로 표현

  • 데이터 흐름도 (Data flow) : 프로세스 간의 데이터 흐름, ->(화살표)로 표현함.

  • 데이터 저장소 (Data Store) : 데이터가 저장되는 장소, =로 표현

  • 단말(Terminator) : 프로세스의 시작과 끝, ㅁ (사각형)로 표현
    
    [출처: 메타 코드 M 정보처리기사 필기 환급 챌린지]
    
    

자료 사전

• 시스템이나 데이터베이스에서 사용되는 데이터들의 정의, 속성, 제약 조건 및 관계를 체계적으로 정리한 문서
• 모든 데이터 요소들을 통일된 형식으로 정의하여 요구사항 분석과 의사 소통을 효율적으로 지원

자료 사전의 기호

• = : 자료의 정의, ~ 는 ~로 구성되어 있다.
• + : 자료의 연결, ~ 에는 ~ 랑 ~랑 ~가 있다.
• { } : 자료의 반복, { } 의 좌측에는 최소 반복 횟수, 우측에는 최대 반복 횟수를 표시
  횟수 표시가 없으면 최소 0회, 최대 무한대
• ( ) : 자료 생략 가능함을 표현
• [¦] : 자료의 선택을 표현, ~ 랑 ~ 중 하나를 선택한다.
• * * : 자료에 대한 설명

자료 사전의 예시

• 직원 = 고유코드 + 이름 + 전화번호 + 부서명 + 직급 + (별명) + {인사 변경이력}
  • 별명은 정해도 되고 안해도 됨.
  • 인사 변경 이력은 반복될 수 있다는 의미
• 고유코드 = 직원의 사번 정보 = 입사년도 + 부서코드
• 부서명 = [ 개발부 ¦ 재무부 ¦ 인사부 ¦ 마케팅부 ]
  • 다음의 선택지 중에 하나를 고를 수 있음.
• 직급 = [사원 ¦ 대리 ¦ 과장 ¦ 팀장 ¦ 사장 ]
  • 다음과 선택지 중에 하나를 고를 수 있음.
• 인사 변경이력 = * 입사 및 승진일자를 날짜 : 직급 의 규칙으로 표현 *
  = 0 { 승진일자 : 직급} 10
  • 최소 0 개에서 10개까지 가질 수 있음을 표시
    
    [출처: 메타 코드 M 정보처리기사 필기 환급 챌린지 강의 자료]
    
    

UML(Unified Modeling Language)

• 주로 객체 지향 소프트웨어 개발 시, 명세화, 시각화하기 위한 모델링 언어
• 개발 방법론이나 개발 프로세스가 아닌, 표준화된 모델링 언어임.
• 사물(Things) / 관계 (Relationship) / 다이어그램(Diagram) 으로 구성
  • 객체 지향이란? : 현실 세계의 객체를 모델링하고 이를 속성과 동작으로 표현하여 프로그래밍하는 방법
    레고를 조립하는 것처럼 프로그램을 만들고, 각각의 레고 블럭을 모두 조립하여, 상호작용하며 기능을 수행하게 함.

UML 다이어그램의 종류

- 클래스 다이어 그램

• 클래스, 송석, 연산 등을 사용하여 시스템의 정적 구조를 표현하는 다이어그램
  • 클래스와 클래스 간의 관계를 표현
• 클래스 다이어그램의 구성 요소
  - 클래스명(Class Name)
  - 속성 : 클래스가 가지고 있는 특징이나 성질 ( 이름, 나이)
  - 연산 : 클래스가 할 수 있는 동작 (걷다, 말하다)
  - 접근 제어자 (Access Modifier) : 누가 그 클래스를 사용할 수 있는 표현
  - ex) -,+,#,~
  
  
  [출처: 메타 코드 M 정보처리기사 필기 환급 챌린지]
  

- 행위적/ 동적 다이어그램

• 시스템의 동적 구성 요소와 그들간의 관계를 보여줌
• 분류
  • 유스케이스 다이어그램 (특히 시험에 많이 나옴.
  • 시퀀스 다이어그램
  • 상태 다이어그램
  • 커뮤니케이션 다이어그램
  • 활동 다이어그램
  • 타이밍 다이어그램

---

- 유스케이스 다이어그램

• 시스템의 기능과 사용자와의 상호 작용을 시각적으로 표현한 다이어그램

- 유스케이스 다이어그램의 구성요소

• 유스케이스 : 시스템이 액터에게 제공하는 특정 기능이나 서비스
• 액터 : 시스템 외부에서 시스템과 상호작용하는 사용자 또는 다른 시스템
• 시스템 : 유스케이스가 수행되는 경계를 나타내는 사각형, 다이어그램 내에서 시스템의 범위를 정의
  
  [출처: 메타 코드 M 정보처리기사 필기 환급 챌린지]
  

- 유스케이스 다이어그램의 구성요소 관계

• 연관(Association) : 액터와 유스케이스 간의 상호 작용, 실선으로 표현
• 포함(Include) : 하나의 유스케이스가 다른 유스케이스를 반드시 포함할 때
• 확장(Extend) : 특정 조건이 만족될 때 유스케이스가 다른 유스케이스를 확장할 때
• 일반화(Generalization) : 비슷한 일들을 더 일반적으로 묶을 때 사용
  
  [출처: 메타 코드 M 정보처리기사 필기 환급 챌린지]

---

시퀀스 다이어그램

• 시스템의 동적 측면을 모델링하며, 객체 간의 상호 작용을 시간 순서에 따라 시각적으로 보여줌.
• 시간의 흐름에 따라 객체들이 주고 받는 메시지의 전달 과정을 강조

---

상태(State) 다이어그램

• 특정 객체가 가질 수 있는 상태와 상태 간의 전이를 표현

  해당 정보에 대해 물어보는 경우가 많음
  

  시퀀스 다이어 그램의 구성 요소	상태 다이어그램의 구성 요소
  • 객체	• 상태
  • 생명선	• 상태 전이
  • 실행	• 시작 상태
  • 메시지	• 종료 상태
  • 회귀 메시지	• 이벤트
  	• 전이 조건

UML의 관계

• 연관: 서로 어떤 방식으로 연결되어 있는지를 표현함.
• 일반화 : 상휘 개념과 하위 개념 간의 관계 ('과일'과 '사과')
• 의존
  : 한 요소가 다른 요소에게 종속적인 관계('주문'과 '결제')
  : 한 요소의 변화가 다른 요소에도 영향을 줌.
• 실체화 : 추상화된 개념과 실제로 이를 구현하는 개념 사이의 관계 ('수영 선수'와 '수영')
• 포함
  : 전체와 부분 간의 강한 관계('집'와 '방')
  : 전체 객체가 사라지면 부분 객체도 사라짐.
• 집합
  : 전체와 부분간의 느슨한 관계('도서관'과 '책')
  : 전체 객체와 부분 객체가 독립적으로 존재할 수 있음.

---

Agile의 방법론

• 소프트웨어 개발 및 프로젝트 관리에서, 유연하고 신속하게 변화에 대응할 수 있도록 고안된 접근 방식
• 고객의 요구사항 변화에 빠르게 적응하고, 개발 과정에서 지속적으로 개선해 나가는 것 (ZARA의 판매 방식이 비슷하게 생각난다...)
  ex) 신발 가게에서, 평범하게 모든 재고를 채워놓고 마케팅을 하는 것과 달리, 몇가지 인기 신발만 소량으로 넣고 반응을 살펴가며 고객이 원하는 신발을 더 많이 넣고, 빠르게 재고를 조정하는 방식

Agile의 방법론의 특징

• 절차와 도구보다, 개인과 소통을 중요하게 생각
• 계획을 따르기보다, 요구사항 변화에 유연하게 대응하는 것을 중요하게 생각
• 소프트웨어가 잘 실행되는 데에 가치를 둠.
• 고객과의 피드백을 중요하게 생각
• 프로젝트의 요구사항을 모듈 중심이 아닌 기능 중심으로 개발

Agile 선언문 속 핵심 가치 4가지

1. 프로세스와 도구보다는 개인과 상호작용
2. 방대한 문서보다는 작동하는 소프트웨어
3. 계약 협상보다 고객과의 협력이 우선
4. 계획을 따르는 것보다 변화에 대응하는 것이 우선

Agile 프레임워크

• Agile 방법론은 다양한 프레임워크를 통해 구현될 수 있음.

스크럼(Scrum)

• 팀이 복잡한 프로젝트를 관리하고 수행하는 데 도움을 주는 프레임워크
• 짧은 시간 동안의 작업 반복(스프린트)를 통해 소프트웨어를 개발

스크럼(Scrum) 주요 용어

그냥 한번만 읽어보기

용어	설명
스프린트 (Sprint)	일반적으로 1~4주 동안 지속되는 반복 작업 주기
스크럼 팀 (Scrum Team)	주로 스크럼 마스터, 제품 책임자(PO), 개발 팀으로 구성
스크럼 마스터 (Scrum Master)	팀이 스크럼을 잘 따를 수 있도록 돕고 장애물을 제거
제품 책임자 (Product Owner)	백로그를 관리하고 우선순위를 설정하여 고객 요구사항을 반영
개발 팀 (Development Team)	실제 제품을 개발하는 팀원들로 구성
제품 백로그 (Product Backlog)	제품에 필요한 모든 기능과 요구사항의 목록
데일리 스크럼 (Daily Scrum)	매일 짧게 진행되는 미팅으로, 팀원이 진행 상황을 공유하고 문제를 논의
스프린트 회고 (Sprint Retrospective)	스프린트 종료 후 팀이 무엇이 잘 됐고, 무엇을 개선할 수 있을지 논의
속도 (Velocity)	한 번의 스프린트에서 한 팀이 어느 정도의 백로그를 감당할 수 있는지 추정치
번 다운 차트 (Burn Down Chart)	스프린트가 계획대로 되고 있는지, 수행할 작업의 진행 상황을 알 수 있는 차트

---

XP(eXtreme Programming)

• 소프트웨어 품질을 높이고, 개발 팀이 변화에 빠르게 대응할 수 있도록 하는 데 중점을 둔 방법론
• 기술적인 실천과 지속적인 코드 개선 등 실용성에 중점을 둔 방법론
• XP의 5가지 가치: 용기, 단순성, 의사소통, 피드백, 존중

린(Lean)

• 도요타의 품질 관리 기법을 개발 프로세스에 적용
• 칸반 보드, JIT(Just In Time)

크리스탈

• 프로세스보다 사람에게 더 중점을 두는 방법론

ASD(Adaptive Software Development)

• 개발을 혼란으로 규정하고 그에 적응할 수 있는 방법을 제시한 방법론

FDD(Feature Drvien Development)

• 개발을 상품이나 서비스 단위가 아닌, 기능 단위로 하는 개발 방법론

---

분석 모델 확인

소프트웨어 모델

• 복잡한 시스템을 간호화하고 기호나 그림등으로 이해하기 쉽게 표현한 상태
• 모델을 통해 소프트웨어 이해도 향상 가능
• 모델을 통해 이해 당사자 간의 의사소통 향상
• 모델을 통해 향후 개발될 시스템에 대한 유추 가능

소프트웨어 모델링의 특징

• 시스템 모델을 이해하기 쉬운 형식으로 표현하는 기법
• 모델링 작업의 결과물이 다른 모델링 작업에 영향을 줄 수 있음.
• 설계, 구현, 유지보수 등 개발의 전 영역에 걸쳐 활용
• 구조적 방법론에서는 DFD, Data Dictionary 등을 사용하여 요구사항의 결과를 모델링
• 객체 지향 방법론에서는 UML 표기법을 활용해 모델링함.

---

CASE(Computer-Aided Software Engineering)

• 소프트웨어 생명주기의 전 단계를 연결해 주고 자동화하는 소프트웨어 도구
• SW, HW, Database, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 조성
• 개발 과정의 속도를 향상시키며, 소프트웨어 부품의 재사용을 가능하게 함.

CASE의 기능

• 그래픽 지원
• 소프트웨어 생명주기 전 단계의 연결
• 다양한 소프트웨어 개발 모형 지원
• 표준화된 개발환경 구축 및 문서 자동화 기능

상위 Case

• 전체 시스템이나 프로젝트의 큰 틀을 다루는 데 활용(모델 간 모순 검사, 모델의 오류 검증 등)

하위 Case

• 상위 Case의 작업을 실제로 구체화하는 데 활용 (소스코드 생성 등)

메타코드 M 해당 강의 보러가기