[정보처리기사] 실기 대비 요약 정리 - 요구사항 확인2

유스케이스 다이어그램

• 유스케이스 다이어그램은 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있도록 "사용자 관점"에서 표현한 것
• 유스케이스 다이어그램의 구성요소
  • 시스템 : 시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
  • 액터 : 시스템과 상호작용을 하는 모든 외부 요소
    • 주액터 : 시스템을 사용함으로써 이득을 얻는 대상으로, 주로 사람이 해당
    • 부액터 : 주액터의 목적 달성을 위해 시스템에 서비스를 제공하는 외부시스템
  • 유스케이스 : 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
  • 관계 : 유스케이스 다이어그램에서의 관계는 액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있음
    • 포함, 확장, 일반화 관계

유스케이스에서 나타날 수 있는 관계

• 포함 관계

  • 두개 이상의 유스케이스에서 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스를 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케와의 관계를 포함 관계라고 함
  • 원래의 유스케이스에서 새롭게 포함되는 유스케이스에 점선 화살표를 연결한 뒤, <<\include>>라고 표기

• 확장관계

  • 유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계를 확장 관계라고함
  • 확장될 유즈케이스에서 원래의 유즈케이스 쪽으로 점선 화살표를 연결한 뒤, <<\extends>>라고 표기

활동 다이어그램

• 활동 다이어그램은 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것
• 활동 다이어그램의 구성요소
  • 액션/액티비티
  • 시작 노드
  • 종료 노드
  • 조건(판단)노드
  • 병합 노드
  • 포크 노드
  • 조인 노드
  • 스윔레인

클래스 다이어그램

• 클래스 다이어그램은 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것이다.
• 클래스 다이어그램의 구성요소
  • 클래스
    • 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한 것
    • 속성 : 클래스의 상태나 정보를 표현함
    • 오퍼레이션 : 클래스가 수행할 수 있는 동작으로, 함수(메소드)라고도 함
  • 제약 조건
    • 속성에 입력될 값에 대한 제약 조건이나 오퍼레이션 수행 전 후에 지정해야할 조건이 있다면 이를 적음
  • 관계
    • 관계는 클래스와 클래스 사이의 연관성을 표현함
    • 클래스 다이어그램에 표현하는 관계에는 연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계가 있음

클래스 다이어그램 - 연관 클래스

• 연관 클래스는 연관 관계에 있는 두 클래스에 추가적으로 표현해야할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스이다.
• 두 클래스의 연관 관계를 나타내는 선의 가운데로부터 점선을 연관 클래스로 이어 표시한다.

시퀀스 다이어그램

• 시퀀스 다이어그램은 시스템이나 객체들이 메시지를 주고 받으며, 상호작용하는 과정을 그림으로 표현한 것
• 시퀀스 다이어그램의 구성요소
  • 액터 : 시스템으로부터 서비스를 요청하는 외부요소로, 사람이나 외부 시스템을 의미
  • 객체 : 메시지를 주고 받는 객체
  • 생명선 : 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현함
  • 객체 소멸(X)이 표시된 기간까지 존재함
  • 실행상자(ACTIVE BOX, 활성상자) : 객체가 메시지를 주고 받으며 구동되고 있음을 표현함
  • 메시지 : 객체가 상호작용을 위해 주고 받는 메시지
    • 객체 소멸 : 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
  • 프레임 : 다이어그램의 전체 또는 일부를 묶어 표현한 것

커뮤니케이션 다이어그램

• 커뮤니케이션 다이어그램은 시스템이나 객체들이 메시지를 주고 받으며 상호작용 하는 과정과 객체들과의 연관을 그림으로 표현한 것
• 커뮤니케이션 다이어그램의 구성요소
  • 액터
  • 객체
  • 링크 : 객체들간의 관계를 표현한 것
  • 메시지 : 객체가 상호작용을 위해 주고 받는 내용

상태 다이어그램

• 상태 다이어그램은 객체들 사이에 발생하는 이벤트에 의한 객체들의 상태변화를 그림으로 표현한 것이다.
• 상태 다이어그램의 구성요소
  • 상태 : 객체의 상태를 표현한 것
  • 시작 상태 : 상태의 시작을 표현한 것
  • 종료 상태 : 상태의 종료를 표현한 것
  • 상태 전환 : 상태 사이의 흐름, 변화를 화살표로 표현한 것
  • 이벤트 : 상태에 변화를 주는 현상
  • 프레임 : 상태 다이어그램의 범위를 표현한 것

패키지 다이어그램

• 패키지 다이어그램은 유스케이스나 클래스 등의 요소들을 그룹화한 패키지간의 의존 관계를 표현 한 것
• 패키지 : 객체들을 그룹화 시킨 것
  • 단순 표기법 : 패키지 안에 패키지 이름만 표현
  • 확장 표기법 : 패키지 안에 요소까지 표현
• 객체 : 유스케이스, 클래스, 인터페이스, 테이블 등 포함될 수 있는 다양한 요소들
• 의존 관계 : 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현함

구조적 방법론

• 구조적 방법론은 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리(Process) 중심의 방법론
• 이해가 쉽고 검증이 가능한 프로그램 코드를 생성하는 것이 목적
• 개발 절차
  • 타당성 검토 단계 -> 계획 단계 -> 요구사항 단계 -> 설계 단계 -> 구현 단계 -> 시험 단계 -> 운용/유지보수 단계

객체지향 방법론

• 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 객체들을 조립해서 소프트웨어를 구현하는 방법론
• 개발절차
  • 요구 분석 단계 -> 설계 단계 -> 구현 단계 -> 테스트 및 검증 단계 -> 인도 단계

컴포넌트 기반 방법론

• 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 새로운 애플리케이션을 만드는 방법론

소프트웨어 재사용

• 이미 개발되어 인정 받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것
• 합성 중심 : 전블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법으로 블록 구성방법이라고도 함
• 생성 중심 : 추상화 형태로 써진 명세를 구체화하여 프로그램을 만드는 방법, 패턴 구성방법이라고도 함

소프트웨어 재공학

• 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상하는 것이다.

CASE(COMPUTER AIDED SOFTWARE ENGINEERING)

• 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것

하향식 비용 산정 기법

• 과거의 유사한 경험을 바탕으로 전문지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 비과학적인 방법이다.
  • 전문가 감정 기법, 델파이 기법

상향식 비용 산정 기법

• 세부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
  • LOC(원시 코드 라인 수) 기법
  • 개발 단계별 인월수 기법
  • 수학적 산정 기법
    • COCOMO 모형
    • PUTNAM 모형
    • 기능 점수(FP) 모형

상향식 비용 산정 기법 - LOC 기법

• 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
• 개발비용 = 노력(인월) X 투입인원

상향식 비용 산정 기법 - 수학적 산정 기법 - COCOMO 모형

• COCOMO 모형 : LOC(원시코드 라인 수)에 의한 비용 산정 기법, 보헴이 제안
• COCOMO의 소프트웨어 개발 유형
  • 조직형(ORGARNIC) : 기관 내부에서 개발 된 중소 규모의 소프트웨어이다. 5만 라인 이하의 소프트웨어 개발 유형
  • 반분리형(SEMI-DETACHED) : 조직형과 내부형의 중간, 30만 라인 이하의 소프트웨어 개발 유형
  • 내장형(EMBEDDED) : 초대형 규모 30만 라인 이상의 소프트웨어 개발 유형

상향식 비용 산정 기법 - 수학적 산정 기법 - PUTNAM 모형

• 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
• Rayleigh-Norden 곡선의 노력 분포도 이용

상향식 비용 산정 기법 - 수학적 산정 기법 - 기능점수 모형

• 기능 점수(FP) 모형은 소프트웨어의 기능을 증대시키는 요인별로 기능 점수를 구한 후 이를 이용해서 비용을 산정하는 방법이다.
• 소프트웨어 기능 증대 요인
  • 자료 입력(입력 양식)
  • 정보 출력(출력 보고서)
  • 명령어(사용자 질의수)
  • 데이터 파일
  • 필요한 외부 루틴과의 인터페이스

비용 산정 자동화 추정 도구

• SLIM : RAYLEIGH-NORDEN 곡선과 PUTNAM 예측 모델을 기초로 하여 개발된 자동화 도구
• ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

PERT(PROGRAM EVALUATION AND REVIEW TECHNOLOGY)

• 프로젝트에 필요한 전체작업의 상호관계를 표시하는 네트워크
• 단계를 나누어 종료시기를 정한다
  • 낙관적인 경우
  • 가능성이 있는 경우
  • 비관적인 경우

CPM(CRITICAL PATH METHOD, 임계경로기법)

• 프로젝트에 필요한 작업을 나열하고, 작업에 필요한 소요기간을 예측하는데 사용하는 기법
• 가장 길게 걸리는 임계경로, 즉 최장경로를 구하면 됨

간트차트

• 작업 일정을 막대도표를 이용하여 표시하는 프로젝트 일정표이다.

ISO/IEC 12207

• ISO(국제표준화 기구)에서 만든 표준 소프트웨어 생명주기 프로세스
• 프로세스 구분
  • 기본 생명 주기 프로세스 : 획득, 공급, 개발, 운영, 유지보수
  • 지원 생명 주기 프로세스 : 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제해결
  • 조직 생명 주기 프로세스 : 관리, 기반 구조, 훈련, 개선

CMMI(CAPABILITY MATURITY MODEL INTEGRATION)

• 소프트웨어 개발 조직의 업무 능력 및 조직 성숙도를 평가하는 모델
• CMMI의 소프트웨어 프로세스 성숙도
  • 초기 : 작업자의 능력에 따라 성공여부 결정
  • 관리 : 특정 프로젝트 내 프로세스 정의 및 수행
  • 정의 : 조직의 표준 프로세스를 활용하여 업무 수행
  • 정량적 관리 : 프로젝트를 정량적으로 관리 및 통제
  • 최적화 : 프로세스 역량 향상을 위해 지속적인 프로세스 개선

SPICE(SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION)

• 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준
• 공식 명칭은 ISO/IEC 15504

SPICE 프로세스 수행 능력 단계

• 수준 0 : 불완전
• 수준 1 : 수행
• 수준 2 : 관리
• 수준 3 : 확립
• 수준 4 : 예측
• 수준 5 : 최적화

소프트웨어 개발 방법론 테일러링

• 소프트웨어 개발방법론의 절차, 사용기법 등을 수정 보완하는 작업
• 내부적 기준
  • 목표 환경
  • 요구사항
  • 프로젝트 규모
  • 보유 기술
• 외부적 기준
  • 법적 제약사항
  • 품질 표준 기준

소프트웨어 개발 프레임워크

• 소프트웨어 개발에 공통적으로 사용되는 구성요소와 아키텍처를 일반화하여 제공해주는 반제품 형태의 소프트웨어 시스템

스프링 프레임워크

• 자바 플랫폼을 위한 오픈 소스 경량형 애플리케이션 프레임워크
• 동적인 웹사이트 위함

소프트웨어 개발 프레임워크의 특성

• 모듈화 : 캡슐화를 통해 모듈화를 강화하고, 설계 및 구현 변경에 따른 영향 최소화, 소프트웨어 품질 향상
• 재사용성 : 재사용 가능한 모듈 제공, 예산 절감, 생산성 향상, 품질 보증
• 확장성 : 다형성을 통한 인터페이스 확장, 다양한 형태와 기능을 가진 애플리케이션 개발
• 제어의 역흐름 : 객체들의 제어를 프레임워크에 넘김으로써 생산성 향상