정보시스템감리사 시험공부 정리노트 with Gemini
close
프로필 사진

정보시스템감리사 시험공부 정리노트 with Gemini

  • 분류 전체보기 (50) N
    • 감리사(기술사)기출문제 (2)
    • 감리 및 사업 관리 (5) N
    • 소프트웨어공학 (25)
    • 데이터베이스 (2)
    • 시스템구조 (10)
    • 보안 (4)
    • 읽을거리 (2)
    • 법령 및 지침 (0)
  • 홈
  • 공지사항
  • 태그
  • 방명록
ISO/IEC/IEEE 29119-4

ISO/IEC/IEEE 29119-4

ISO/IEC/IEEE 29119-4 테스트 설계 기법 요약 정리1. 명세 기반 기법 (Clause 5.2) - 입력 및 출력의 명세 기반조항기법명특징계산 및 설계 방법5.2.1동등 분할데이터를 동일 결과가 예상되는 영역으로 분할유효/무효 영역당 최소 1개 값 선정5.2.2분류 트리 기법테스트 요소를 트리 구조로 시각화하여 조합트리의 잎(Leaf) 노드 조합으로 케이스 생성5.2.3경계값 분석영역의 경계에서 발생하는 오류 집중 공략2-point(경계, 외부) 또는 3-point($n-1, n, n+1$)5.2.4구문 규칙 테스팅입력 값의 형식(문법) 규칙을 검증올바른 문법과 잘못된 문법 케이스 설계5.2.5.3모든 조합 기법모든 변수의 가능한 모든 값을 결합모든 값의 개수를 곱함 ($\prod V_i$)..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 2. 2.

Lehman의 소프트웨어 진화의 법칙(Lehman's Laws of Software Evolution)

Lehman의 소프트웨어 진화의 법칙(Lehman's Laws of Software Evolution)은 소프트웨어 공학의 선구자인 메이어 리만(Meir M. Lehman)과 라즐로 벨라디(Laszlo Belady)가 1974년부터 제안한 이론입니다. 이 법칙의 핵심은 "소프트웨어는 완성된 후에도 계속해서 변화하고 진화해야 하며, 그렇지 않으면 도태된다"는 것입니다. 8가지 주요 법칙 (The 8 Laws)에 대해 정리하여 드립니다.1. 계속적인 변경의 법칙 (Law of Continuing Change)핵심: 시스템은 현실 세계의 변화에 맞춰 끊임없이 변경되어야 합니다.이유: 사용자의 요구사항과 운영 환경은 멈춰있지 않고 계속 변하기 때문입니다.결과: 변경되지 않는 시스템은 유용성이 점차 떨어져 결국 ..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 28.

오버로딩(Overloading)과 오버라이딩(Overriding)

1. 오버로딩 (Overloading): 과적하기"같은 이름의 함수를 여러 개 만드는 것"입니다. 트럭에 짐을 많이 싣는(Overload) 것처럼, 하나의 이름에 여러 기능을 껴 넣는다고 생각하세요.핵심 : 이름은 같지만, 매개변수(개수나 타입)가 달라야 함.비유 : 식당의 '주문하기' 기능. 주문하기라는 함수(메서드)는 같지만 매개변수인 메뉴명, 수량, 옵션이 다름.주문하기(메뉴명) -> "김치찌개 하나요!"주문하기(메뉴명, 수량) -> "김치찌개 세 개요!"주문하기(메뉴명, 옵션) -> "김치찌개 맵게 하나요!"목적 : 같은 성격의 기능을 이름 하나로 편하게 쓰기 위해 사용합니다.2. 오버라이딩 (Overriding): 덮어쓰기"부모에게 물려받은 기능을 내 식으로 재정의하는 것"입니다. 기존의 것을 ..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 28.

가상 또는 추상 클래스는 일반 클래스와 달리 객체를 생성할 수 없다!?

추상 클래스나 객체라는 개념, 처음 접하면 "붕어빵 틀이 있는데 왜 붕어빵을 못 만든다는 거지?" 싶어서 충분히 헷갈릴 수 있어요. 아주 핵심만 짚어서 쉽게 설명해 드릴게요!1. '객체(Object)'란 무엇인가?컴퓨터 프로그래밍에서 객체는 "실제로 메모리에 존재하며 일을 하는 실체"를 말해요.클래스: 설계도 (예: 자동차 설계도)객체: 설계도를 보고 실제로 만든 물건 (예: 내 주차장에 있는 아반떼, 옆집 테슬라)설계도만 가지고는 도로를 달릴 수 없죠? 실제로 공장에서 찍어낸 '실물(객체)'이 있어야 운전을 할 수 있는 것과 같은 이치입니다.2. 왜 추상 클래스는 객체를 못 만들까?가장 큰 이유는 "미완성 설계도"이기 때문이에요.예를 들어, 제가 당신에게 "동물(Animal) 한 마리만 그려보세요"라고..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 28.

응집도(Cohesion)

1. 응집도 (Cohesion)응집도는 "모듈 내부 요소들이 얼마나 밀접하게 관련되어 있는가"를 나타냅니다. 높을 수록(High Cohesion) 좋습니다. 응집도의 종류 (약함 → 강함 순)단계종류설명예시1(😫)우연적(Coincidental)서로 관련 없는 요소들이 모임단순 편의상 묶어둔 코드2(😔)논리적(Logical)유사한 성격의 기능을 논리적으로 묶음출력 관련 함수들을 한 모듈에 모음3(😒)시간적(Temporal)특정 시간에 처리되는 기능을 모음초기화(init), 종료 처리 모듈4(😐️)절차적(Procedural)실행 순서가 정해진 기능을 모음순서도는 있으나 데이터 공유는 없음5(😊)통신적(Communication)동일한 입출력 데이터를 사용하는 기능동일 데이터셋으로 A계산, B계산 수행..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 26.

형상관리 핵심 암기 용어 정리

형상관리에서 주로 출제되는 용어 및 주의깊게 봐야 할 특징을 정리합니다.구분용어 (Keyword)핵심 정의 및 특징 (암기 포인트)기초 개념형상 항목 (CI)관리 대상이 되는 소프트웨어 생명주기 산출물 (코드, 문서, 데이터 등)베이스라인 (Baseline)공식적으로 검토/승인된 산출물 집합. 변경의 기준점(CCB의 승인이 반드시 필요)4대 활동형상 식별관리 대상 선정, ID 부여, 베이스라인 확정 활동형상 통제(제어)변경 요청 검토/승인 및 버전 관리를 수행하는 가장 핵심적인 활동형상 감사FCA(기능적): 요구사항과 일치 여부 / PCA(물리적): 설계서와 실제 항목 일치 여부형상 상태 보고(기록)형상 항목의 변경 이력 및 현재 상태를 기록하고 보고하는 활동의사결정CCB (형상통제위원회)변경 승인 여부..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 20.

형상감사(Configuration Audit)

형상감사(Configuration Audit)는 소프트웨어나 시스템 개발 과정에서 형상 항목(CI, Configuration Item)이 요구사항 및 설계대로 정확하게 구현되었는지, 그리고 베이스라인(Baseline)이 잘 관리되고 있는지 검증하는 매우 중요한 활동입니다. 형상감사는 크게 두 가지 종류로 나뉩니다.1. 물리적 형상감사 (PCA: Physical Configuration Audit)물리적 형상감사는 "우리가 만들기로 한 구성 요소들이 실제로 모두 존재하는가?"를 확인하는 과정입니다. 제품의 물리적 무결성을 검증합니다. 형상 항목이 설계 도서나 문서에 명시된 대로 실제 제품(코드, 실행 파일, 매뉴얼 등)으로 모두 존재하고 일치하는지 확인합니다.[주요 활동]소스 코드와 설계 문서 간의 일치성..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 20.

Halstead의 소프트웨어 사이언스(Software Science) 계산 방법

[예제 문제]다음 C 언어 코드 조각을 보고 할스테드의 소프트웨어 사이언스 지표 중 프로그램 어휘량(Vocabulary)과 부피(Volume)를 계산하시오. (단, $\log_2 16 = 4$로 계산한다.)if (a > b) x = y + 1;else x = y - 1;1단계 연산자(Operator)와 피연산자(Operand) 분류할스테드 측정의 핵심은 무엇이 연산자고 무엇이 피연산자인지 정확히 구분하는 것입니다.연산자 ($n_1, N_1$) : 제어문, 산술 연산자, 할당문, 괄호, 세미콜론 등피연산자 ($n_2, N_2$) : 변수명, 상수(숫자)구분종류 (Distinct)개수 (Total)연산자 ($n_1$)if, else, ( ), >, =, +, -, ;8종류 ($n_1 = 8$)연산..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 20.

소프트웨어 복잡도(Software Complexity)

소프트웨어 복잡도(Software Complexity)는 코드의 유지보수성, 오류 가능성, 테스트 용이성을 판단하는 핵심 지표로 자주 출제되는 영역입니다. 암기할 것 위주로 정리합니다.1. McCabe의 순환 복잡도 (Cyclomatic Complexity)가장 출제 빈도가 높습니다. 제어 흐름 그래프(Control Flow Graph)를 기반으로 프로그램 내의 독립적인 경로의 수를 측정합니다. (기본 경로 Basic Path)[공식 1] (그래프 이용): $V(G) = E - N + 2P$$E$: 간선(Edges) 수$N$: 노드(Nodes) 수$P$: 연결된 성분의 수 (보통 단일 프로그램이면 1)[공식 2] (분기점 이용): $V(G) = \text{화살표로 둘러싸인 영역(Region)의 수}$[공..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 20.

가용성(Availability) 핵심 정리

1. 주요 지표의 정의 및 관계식MTBF (Mean Time Between Failures, 평균 고장 간격) 수리 가능한 시스템이 고장 난 후, 다음 고장이 발생할 때까지의 평균 시간입니다.MTTR (Mean Time To Repair, 평균 수리 시간) 고장이 발생했을 때 이를 수리하여 정상 가동하는 데까지 걸리는 평균 시간입니다.MTTF (Mean Time To Failure, 평균 고장 시간)수리 후 다음 고장까지의 순수 가동 시간, 혹은 수리 불가능한 부품이 고장 나기까지 걸리는 시간입니다.💡 핵심 관계식 (암기 필수) : 시험에서 가동 시간과 수리 시간을 구분할 때 반드시 사용되는 공식입니다.MTBF = MTTF + MTTR (고장 간격 = 순수 가동 시간 + 수리 시간)MTTF = MTBF..

  • format_list_bulleted 소프트웨어공학
  • · 2026. 1. 19.
  • navigate_before
  • 1
  • 2
  • 3
  • 4
  • 5
  • navigate_next
전체 카테고리
  • 분류 전체보기 (50) N
    • 감리사(기술사)기출문제 (2)
    • 감리 및 사업 관리 (5) N
    • 소프트웨어공학 (25)
    • 데이터베이스 (2)
    • 시스템구조 (10)
    • 보안 (4)
    • 읽을거리 (2)
    • 법령 및 지침 (0)
인기 글
전체 방문자
오늘
어제
대부분의 자료는 Google Gemini로 학습한 내용을 편집한 것 입니다.
Designed by JJuum.
Base skin "dev-roo" is modified by Jin and Current skin modified by nooree

티스토리툴바