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

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

  • 분류 전체보기 (26)
    • 감리사(기술사)기출문제 (2)
    • 감리 및 사업 관리 (4)
    • 소프트웨어공학 (20)
    • 데이터베이스 (0)
    • 시스템구조 (0)
    • 보안 (0)
    • 법령 및 지침 (0)
  • 홈
  • 공지사항
  • 태그
  • 방명록

응집도(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.

이언 소머빌(Ian Sommerville)이 강조하는 위험 관리(Risk Management)의 핵심 프로세스 4단계

위험은 실제로 발생하여 프로젝트 결과에 부정적인 영향을 끼친 문제이다.위 문장이 왜 틀린걸까요? 이언 소머빌(Ian Sommerville)의 소프트웨어 공학 관점에서 해당 문장이 틀린 이유는 '위험(Risk)'과 '문제(Issue/Problem)'의 시점 차이 때문입니다. 공학적으로 이 둘은 엄격히 구분됩니다.1. 위험(Risk) vs 문제(Issue)소머빌은 위험을 다음과 같이 정의합니다.위험(Risk) : 아직 발생하지 않았지만, 미래에 발생할 가능성이 있는 불확실한 사건입니다. 즉, '확률'의 영역에 있습니다.문제(Issue) : 이미 실제로 발생하여 현재 프로젝트에 영향을 주고 있는 결정된 사건입니다.따라서 질문하신 문장에서 "위험은 실제로 발생하여... 문제이다"라는 부분은 위험의 정의가 아니라..

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

CMMI(Capability Maturity Model Integration)

CMMI(Capability Maturity Model Integration)는 소프트웨어 및 시스템 공학의 프로세스 개선을 위한 대표적인 모델입니다. 감리사나 전산직 시험에서 매년 빠지지 않고 등장하는 주제인 만큼, 핵심 내용을 중심으로 정리해 드립니다.1. CMMI의 등장 배경 및 목적과거 미국 국방부(DoD)는 소프트웨어 개발 프로젝트의 비용 초과, 일정 지연, 품질 저하 문제를 해결하고자 했습니다. 이를 위해 카네기 멜런 대학의 소프트웨어 공학 연구소(SEI)에 의뢰하여 SW 개발 역량을 평가하는 CMM을 만들었습니다. 이후 SW뿐만 아니라 시스템(SE), 제품 개발(IPPD) 등 여러 분야로 파생된 모델들을 하나로 통합할 필요성이 생겼고, 2002년에 CMMI라는 통합 모델이 탄생하게 되었습니다..

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

품질속성 시나리오(QAS, Quality Attribute Scenarios)

품질속성 시나리오(Quality Attribute Scenario)는 소프트웨어의 비기능적 요구사항(성능, 보안, 가용성 등)을 막연한 설명이 아니라, 구체적이고 측정 가능한 형태로 표현한 문장입니다.예를 들어 "시스템은 빨라야 한다"는 모호하지만, "정상 운영 상태에서 사용자가 검색 버튼을 누르면 2초 이내에 결과가 화면에 출력되어야 한다"는 구체적입니다. 이렇게 작성하는 것이 바로 품질속성 시나리오입니다.1. 시나리오의 6가지 구성 요소SEI(소프트웨어 공학 연구소)에서는 시나리오를 작성할 때 다음 6가지 요소를 포함할 것을 권장합니다.구성 요소설명예시자극원 (Source)자극을 발생시키는 주체외부 사용자, 관리자, 해커, 다른 시스템자극 (Stimulus)시스템에 도착하는 이벤트데이터 입력, 시스템..

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

맥콜(McCall)의 소프트웨어 품질 모델

맥콜(McCall)의 소프트웨어 품질 모델은 사용자와 개발자의 관점에서 소프트웨어의 품질을 평가하기 위해 제안된 고전적인 모델입니다. 이 모델은 소프트웨어의 특성을 3가지 관점으로 분류하고, 이를 다시 11가지 세부 품질 요소로 정의합니다.구체적인 분류 내용은 다음과 같습니다.1. 제품 운용 (Product Operation)사용자가 소프트웨어를 실제로 실행할 때 느끼는 품질 요소입니다. (사용자 관점)품질 요소설명정확성 (Correctness)사용자의 요구사항을 정확히 충족시키는 정도신뢰성 (Reliability)정해진 기간 동안 오류 없이 기능을 수행하는 정도효율성 (Efficiency)자원(메모리, CPU 등)을 최소한으로 사용하며 성능을 내는 정도무결성 (Integrity)허가되지 않은 접근으로부..

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

티스토리툴바