---

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

---

📃 요구사항 확인 (2)

1. 유스케이스 다이어그램

   • 사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것

   • 구성 요소	내용
     시스템/시스템 범위	시스템 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
     액터	시스템과 상호작용을 하는 모든 외부 요소로 주로 사람이나 외부 시스템을 의미
     유스케이스	사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
     관계	액터와 유스케이스, 유스케이스와 유스케이스 사이에서 나타날 수 있으며 포함 관계, 확장 관계, 일반화 관계로 나뉨

   

예시 출처

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

   • 포함 관계	두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우, 원래의 유스케이스와 새롭게 분리된 유스케이스와의 관계를 말함
     확장 관계	유스케이스가 특정 조건에 부합되어 유스케이스의 기능이 확장될 때 원래의 유스케이스와 확장된 유스케이스와의 관계를 말함

3. 활동 다이어그램

   • 사용자의 관점에서 시스템이 수행하는 기능을 처리 흐름에 따라 순서대로 표현한 것

   • 구성 요소	내용
     액션/액티비티	각각 더 이상 분해할 수 없는 단일 작업과 몇 개의 액션으로 분리될 수 있는 작업을 의미
     시작 노드	액션이나 액티비티가 시작됨을 표현한 것
     종료 노드	액티비티 안의 모든 흐름이 종료됨을 표현한 것
     조건(판단) 노드	조건에 따라 제어의 흐름이 분리됨을 표현한 것, 들어오는 제어 흐름은 한 개이고 나가는 제어 흐름은 여러 개
     병합 노드	여러 경로의 흐름이 하나로 합쳐짐을 표현한 것, 들어오는 제어 흐름은 여러 개이고 나가는 제어 흐름은 한 개
     포크(Fork) 노드	액티비티의 흐름이 분리되어 수행됨을 표현한 것, 들어오는 액티비티 흐름은 한 개이고 나가는 액티비티 흐름은 여러 개
     조인(Join) 노드	분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것, 들어오는 액티비티 흐름은 여러 개이고 나가는 액티비티 흐름은 한 개
     스윔레인	액티비티 수행을 담당하는 주체를 구분하는 선, 가로 또는 세로 실선

   

예시 출처

4. 클래스 다이어그램

   • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것

   • 구성 요소	내용
     클래스	각각의 객체들이 갖는 속성과 오퍼레이션을 표현한 것, 이름과 속성, 오퍼레이션으로 3개의 구획을 나눔
     제약 조건	속성에 입력될 값에 대한 제약 조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적으며 클래스 안에 기술할 때는 중괄호를 이용
     관계	클래스와 클래스 사이의 연관성을 표현, 연관, 집합, 포함, 일반화, 의존 관계가 있음

   

예시 출처

5. 연관 클래스

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

6. 순차 다이어그램

   • 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것

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

   

   이 예시에는 객체 소멸 표시가 없다.

예시 출처

7. 커뮤니케이션 다이어그램

   • 시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것

   • 구성 요소	내용
     액터	시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미
     객체	메시지를 주고받는 주체
     링크	객체들 간의 관계를 표현한 것, 액터와 객체, 객체와 객체 간에 실선을 그어 표현
     메시지	객체가 상호작용을 위해 주고받는 내용, 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현

   

예시 출처

8. 상태 다이어그램

   • 객체들 사이에서 발생하는 이벤트에 의한 객체들의 상태 변화를 그림으로 표현한 것

   • 구성 요소	내용
     상태	객체의 상태를 표현한 것
     시작 상태	상태의 시작을 표현한 것
     종료 상태	상태의 종료를 표현한 것
     상태 전환	상태 사이의 흐름, 변화를 화살표로 표현한 것
     이벤트	상태에 변화를 주는 현상, 조건, 외부 신호, 시간의 흐름 등이 있음
     프레임	상태 다이어그램의 범위를 표현한 것

   

예시 출처

9. 패키지 다이어그램

   • 유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존관계를 표현한 것

   • 구성 요소	내용
     패키지	객체들을 그룹화한 것, 패키지 이름만 표현하는 단순 표기법과 요소까지 표현하는 확장 표기법이 있다
     객체	유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
     의존 관계	패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현, 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있으며 대표적으로 import와 access를 사용

   

예시 출처

10. 구조적 방법론

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

11. 컴포넌트 기반 방법론

    • 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
    • 컴포넌트의 재사용이 가능하여 시간과 노력을 절감할 수 있음
    • 개발 준비 - 분석 - 설계 - 구현 - 테스트 - 전개 - 인도

12. 소프트웨어 재사용

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

13. CASE(Computer Aided Software Engineering)

    • 소프트웨어 개발 과정에서 사용되는 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
    • 주요 기능
      • 소프트웨어 생명 주기 전 단계의 연결
      • 다양한 소프트웨어 개발 모형 지원
      • 그래픽 지원

14. LOC 기법

    • 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법
    • 산정 공식
      • 노력(인월) = 개발 기간 X 투입 인원 = LOC / 1인당 월평균 생산 코드 라인 수
      • 개발 비용 = 노력(인월) X 단위 비용(1인당 월평균 인건비)
      • 개발 기간 = 노력(인월) X 투입 인원
      • 생산성 = LOC / 노력(인월)

15. 수학적 산정 기법

    • 상향식 비용 산정 기법으로, 개발 비용 산정의 자동화를 목표로 함
    • 경험적, 실험적 추정 모형 이라고도 함
    • COCOMO 모형, Putnam 모형, 기능 점수(FP) 모형

16. COCOMO 모형

    • 원시 프로그램의 규모인 LOC에 의한 비용 산정 기법
    • 개발할 소프트웨어의 규모(LOC)를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정함
    • 비용 산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 나타남

17. COCOMO의 소프트웨어 개발 유형

    • 조직형

      • 기관 내부에서 개발된 중 내부에서 개발된 중·소 규모의 소프트웨어
      • 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용 등의 5만 라인 이하의 소프트웨어를 개발하는 유형
      • 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합

    • 반분리형

      • 조직형과 내장형의 중간형 소프트웨어
      • 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 개발하는 유형
      • 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합

    • 내장형

      • 초대형 규모의 소프트웨어
      • 트랜잭션 처리 시스템이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형
      • 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

18. Putnam 모형(생명 주기 예측 모형)

    • 소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
    • 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함

    

예시 출처

19. 기능 점수 모형

    • 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능 점수를 산출하며, 총 기능 점수와 영향도를 이용하여 기능 점수(FP)를 구한 후 이를 이용하여 비용을 산정하는 기법
    • 소프트웨어 기능 증대 요인
      • 자료 입력(입력 양식)
      • 정보 출력(출력 보고서)
      • 명령어(사용자 질의수)
      • 데이터 파일
      • 필요한 외부 루틴과의 인터페이스

20. 비용 산정 자동화 추정 도구

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

21. PERT

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

22. CPM

    • 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는데 사용하는 기법
    • 노드와 간선으로 구성된 네트워크로 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타냄.
    • 최장 경로를 임계 경로라고 하며, 예시에서는 붉은 선으로 표시함.

예시 출처

23. 간트 차트

    • 프로젝트의 각 작업들이 언제 시작하고 언제 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표
    • 중간 목표 미달성 시 그 이유와 기간을 예측할 수 있게 함

24. ISP/IEC 12207

    • ISO(국제표준화기구)에서 만든 표준 소프트웨어 생명 주기 프로세스
    • 소프트웨어의 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공함

    • 기본 생명 주기 프로세스	획득, 공급, 개발, 운영, 유지보수 프로세스
      지원 생명 주기 프로세스	품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상관리, 문제 해결 프로세스
      조직 생명 주기 프로세스	관리, 기반 구조, 훈련, 개선 프로세스

25. CMMI

    • 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델

    • 프로세스 성숙도를 단계별로 나눈다. (초관정정최)

    • 단계	특징
      초기	작업자 능력에 따라 성공 여부 결정
      관리	특정한 프로젝트 내의 프로세스 정의 및 수행
      정의	조직의 표준 프로세스를 활용하여 업무 수행
      정량적 관리	프로젝트를 정량적으로 관리 및 통제
      최적화	프로세스 역량 향상을 위해 지속적인 프로세스 개선

26. SPICE(ISO/IEC 15504)

    • 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준

27. SPICE의 프로세스 수행 능력 단계(불수관확예최)

    • 수준	단계	특징
      0	불완전	프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
      1	수행	프로세스가 수행되고 목적이 달성된 단계
      2	관리	정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
      3	확립	소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
      4	예측	프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
      5	최적화	프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

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

    • 프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업이다.

    • 고려사항은 다음과 같다.

    • 기준	내용
      내부적 기준	목표 환경, 요구사항, 프로젝트 규모, 보유 기술
      외부적 기준	법적 제약사항, 표준 품질 기준

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

    • 소프트웨어 개발에 공통적으로 사용되는 구성 요소와 아키텍처를 일반화하여 손쉽게 구현할 수 있도록 여러가지 기능들을 제공해주는 반제품 형태의 소프트웨어 시스템

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

    • 모듈화: 프레임워크는 캡슐화를 통해 모듈화를 강화하고 설계 및 구현의 변경에 따른 영향을 최소화함으로써 소프트웨어의 품질을 향상시킨다.

    • 재사용성: 프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능하다.

    • 확장성: 프레임워크는 다형성을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.

    • 제어의 역흐름: 개발자가 관리하고 통제해야하는 객체들의 제어를 프레임워크에 넘김으로써 생산성을 향상시킨다.

    스프링 공부할 때 귀가 따갑도록 들었던 것들을 다시 보니 감회가 새롭구만..