Developer.

정보처리기사 실기 요구사항 확인 정리

📂 목차


📚 본문

Ctrl + P 인쇄 가능합니다.

요구사항 분석 단계 절차

  1. 요구사항 분류: 기능 요구사항, 비기능 요구사항을 구분하는 단계
    • 기능 요구사항: 기능과 관련하여 소프트웨어가 가져야 하는 기능적 속성에 대한 요구사항
    • 비기능 요구사항: 기능적 속성이 아닌 성능, 보안, 품질 등에 대한 요구사항
  2. 개념 모델링 생성 및 분석: 현실 세계의 상황을 단순화, 개념적으로 표현하는 것을 모델링이라고 한다.
    • DFD: 데이터 흐름을 처리기(◯), 데이터 흐름(→), 데이터 저장소(=), 단말(□) 로 표현함. 시간의 흐름 ❌, 제어 흐름 ❌
    • DD: 시스템에 사용하는 모든 데이터에 대한 정의와 설명을 체계적으로 정리한 문서로 =(is composed of), +(연결), (생략), { , , }(반복), [ ](택일), **(주석) 을 통해 표현함.
    • UML
    • E-R
  3. 요구사항 할당
  4. 요구사항 협상
  5. 정형 분석

UML

객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어

UML 구성요소

  • 사물(Things): 주제를 나타내는 추상적 개념으로 명사, 동사 의미
  • 관계(Relationships): 사물-사물 연결로 형용사, 부사 의미
  • 다이어그램(Diagrams): 사물과 관계를 모아 그림으로 표현, 9가지로 정의

구조적 다이어그램

외우기 - 클객 컴배 복패

클래스 다이어그램
  • 시스탬 내 클래스의 정적 구조 표현
  • 속성과 동작으로 구성
  • 클래스와 클래스, 클래스와 속성 사이 관계 표현
  • 접근 제어자: public +, default ~, protected #, private -

UML에서 클래스는 보통 직사각형으로 표현됨

객체 다이어그램
  • ‘특정 시점’의 인스턴스와 인스턴스 사이의 관계를 표현
  • 객체 인스턴스를 나타내는 대신 실제 클래스를 사용
  • 연관된 모든 인스턴스를 표현

객체가 인스턴스이다.

컴포넌트 다이어그램
  • 컴포넌트(Executable 단위) 기반의 물리적 구조 표현
  • 실질적 프로그래밍 작업에 사용
배치 다이어그램
  • 컴포넌트 사이의 종속성을 표현
  • 소프트웨어가 실제 시스템에 어떻게 배포되는지를 시각화할 때 사용
  • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
  • 아키텍처 설계나 배포 구조 문서화, 운영 인수인계 할 때 사용
복합체 구조 다이어그램
  • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
  • 일반적인 클래스 다이어그램은 이런 속성과 메서드를 가진다는 외형적인 관계만을 보여주지만, 이 클래스 내부에 어떤 역할과 부품이 있고, 어떻게 동작 객체를 통해 연결되는가 까지 설명하려면 이를 사용
  • 내부 구조를 정밀하게 모델링
패키지 다이어그램
  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

동적 다이어그램

외우기 - 유시커 상황타

유스케이스 다이어그램
  • 사용자 관점에서 시스템의 활동을 표현
  • 유스케이스는 시스템의 기능적 요구 정의에 활용
  • 구성요소
    • 유스케이스: ◯
    • 액터
    • 시스템: □
  • 관계 표현
    • 연관관계 (유스케이스)-(액터)
    • 포함 관계 (포함하는) - « include » - > (포함되는)
    • 확장 관계 (확장 기능) - « extend » -> (확장 대상, 더 넓은 개념)
      ex) (비밀번호 재설정) - « extend » -> (로그인)
    • 일반화 관계 (추상화) ◁- (구현체)
시퀀스 다이어그램
  • 객체 간 상호 작용을 메시지 흐름으로 표현
  • 객체 사이 메시지를 보내는 시간을 표현
  • 교류 다이어그램의 한 종류로 볼 수 있음
  • 구성 요소
    • 객체: □
    • 생명선: 객체 아래로 이어진 ┆
    • 실행: 생명선 위의 □
    • 메시지: -▶
    • 회귀 메시지: Lifeline 에서 자신의 Activation 에 메시지로 연결
커뮤니케이션 다이어그램
  • 시퀀스 다이어그램과 같이 동작에 참여하는 ‘객체’들이 주고 받는 메시지를 표현
  • 메시지 뿐만 아니라 객체 간의 연관까지 표현
상태 다이어그램
  • 하나의 객체가 자신의 속한 클래스의 상태 변화 표현
  • 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현
  • 모든 가능한 상태와 전이를 표현
  • 진입 조건, 탈출 조건, 상태 전이 등을 기술
  • 구성요소
    • 상태: 객체가 존재할 조건, 둥근 사각형으로 표현
    • 시작 상태: ●
    • 종료 상태: ⦿
    • 전이: -▶
      • 이벤트: -이벤트-▶
      • 전이 조건: -[전이조건]->
활동 다이어그램
  • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서대로 표현
  • 활동의 순서대로 흐름을 표현
타이밍 다이어그램
  • 객체 상태 변화와 시간 제약을 명시적으로 표현

UML 관계

연의 일실 포집

  • 연관 관계: ->
  • 의존 관계: - - ->
  • 일반화 관계: (Child Class) -▶ (Parent Class)
  • 실체화 관계: (Class) - - -▶ (Interface)
  • 포함 관계: (Class) ◆-> (Several Class)
  • 집합 관계: (Class) ◇-> (Several Class)

포함은 강한 결합, 집합은 느슨한 결합

UML Stereotype

  • « include »: Usecase
  • « extend »: Usecase
  • « interface »: Class Diag.
  • « entity »: Usecase
  • « boundary »: 외부 액터와의 상호작용을 담당하는 클래스 Sequence
  • « control »: 로직 및 제어를 담당하는 클래스 Sequence

Agile 개발 방법론

반복적이고 점진적인 개발을 통해 변화하는 요구사항에 빠르게 대응

XP

의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

  • 1~3주의 반복 개발 주기
  • 5가지의 가치와 12개의 실천

SCRUM

매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

  • 제품 책임자(Product Owner)
  • 제품 백로그
  • 스프린트: 2~4주의 짧은 개발 기간 반복 수행
  • 스크럼 미팅: 매일 15분 정도의 미팅으로 To-Do List 수립
  • 스크럼 마스터: 스크럼 수행 시 문제를 인지하는 사람
  • 스프린트 회고: 스프린트 주기를 되돌아봄
  • 번 다운 차트: 백로그 대비 시간을 그래프로 나타냄

Lean

JIT, 칸반 보드 이용

분석 자동화 도구

  • 상위 CASE(문서 기반): 계획 수립, 요구 분석, 기본 설계 단계를 다이어그램으로 표현, 자료흐름도 프로토타이핑 작성 지원 및 UI 설계 지원
  • 하위 CASE(코드 기반): 구문 중심 편집 및 정적, 동적 테스트 지원