19a4-기술사-핵심토픽-SW공학

DevOps

• 두음: 품프도

개념 시스템 개발자와 시스템 운영자의 협업과 자동화를 강조하는 개발 방법론

특징 개발 운영 협업 자동화

• DevOps를 통해 소프트웨어 개발,배포,릴리즈 속도 향상 가능

개념도

설계 개발 빌드 테스트 배포 릴리즈 모니터링 피드백 (앞에 4개 CI, 뒤 4개 CD)

• CI, CD가 순환하며 개발이 이루어짐

구성요소

품질 품질 기준: 정적 분석, 테스트 통과율 테스트 자동화: 자동화된 테스트로 빠른 검증

프로세스 지속적 배포: 운영 서버 반영 자동화 릴리즈와 배포의 구분: 변경사항 전달 시점 유연화

도구 지속적 통합: 형상관리 도구 활용 배포 자동화: 배포 스크립트를 통한 빠른 배포

• DevOps는 품질, 프로세스, 도구라는 기준으로 나눠볼 수 있음

DevOps의 고려사항

인력

• 개발,운영간 화합
• 협업 문화

보안

• 빠른 배포 → 리스크 업
• DevSecOps 관점 필요

비용

• 신규 도구 도입

• 클라우드 비용 업

• 장점을 취하고 한계를 보완하는 DevOps 도입 과정 필요

소프트웨어 안전성 분석 기법

FHA (Functional Hazard Analysis, 기능위험분석)
시스템이 아직 구체적인 설계나 구성요소로 분해되기 전, 개념/요구분석 단계에서 시스템이 수행해야 할 기능을 나열하고 각 기능이 상실되거나 오작동했을 때 발생할 수 있는 위험과 심각도를 평가하는 기법입니다. 설계에 대한 편견 없이 순수하게 “무엇을 하는 시스템인가” 관점에서 위험을 도출하기 때문에 안전분석 절차에서 가장 이른 시점에 수행되며, 그 결과가 이후 FTA나 FMEA 같은 세부 분석의 입력(시스템 수준 위험목록)이 됩니다.

PHA (Preliminary Hazard Analysis, 예비위험분석)
요구분석 단계에서 시스템/구성요소 수준의 잠재적 위험원을 초기에 식별하고 대략적인 심각도와 발생가능성을 평가하는 기법으로, 이후 정밀분석(FTA, FMEA 등)의 대상과 우선순위를 정하는 스크리닝 역할을 합니다. FHA가 기능 단위 관점이라면 PHA는 시스템/구성요소 단위 관점이라는 차이가 있으며, 두 기법은 상호보완적으로 함께 쓰이는 경우가 많습니다.

HAZOP (Hazard and Operability Study, 위험성 및 운전성 분석)
No, More, Less, Reverse, As well as 등 정해진 가이드워드를 프로세스나 설계의 각 요소에 체계적으로 적용해, 정상 운전조건에서 벗어나는 편차(Deviation)와 그로 인한 위험을 빠짐없이 탐색하는 기법입니다. 브레인스토밍에 가까운 팀 기반 검토 방식이라 분석가의 직관에 의존하지 않고 누락 없이 위험을 찾아낼 수 있다는 장점이 있지만, 대상 시스템이 크면 소요 시간이 많이 든다는 단점이 있습니다.

FTA (Fault Tree Analysis, 결함수분석)
최상위 사고(Top Event)를 먼저 정의한 뒤, AND/OR 게이트를 이용해 그 사고를 유발할 수 있는 하위 원인들을 트리 구조로 역추적해 나가는 하향식(Top-down) 기법입니다. 기본사건(Basic Event)에 발생확률을 부여하면 Top Event의 발생확률을 정량적으로 산출할 수 있어, 여러 원인이 복합적으로 결합해 사고를 유발하는 경우를 분석하는 데 강점이 있습니다.

FMEA (Failure Mode and Effects Analysis, 고장모드영향분석)
개별 구성요소가 어떤 방식으로 고장 날 수 있는지(고장모드)를 먼저 나열하고, 그 고장이 상위 시스템에 미치는 영향을 추적해 나가는 상향식(Bottom-up) 기법입니다. 심각도(S)·발생도(O)·검출도(D)를 곱한 RPN(Risk Priority Number)으로 개선 우선순위를 정량적으로 매길 수 있어 표 형태로 체계적인 문서화가 가능하지만, 여러 고장모드가 동시에 발생하는 복합적 상황을 분석하는 데는 한계가 있습니다.

SFMEA (Software Failure Modes and Effects Analysis, 소프트웨어 고장모드영향분석)
하드웨어용 FMEA를 소프트웨어 영역으로 확장한 기법으로, 소프트웨어는 물리적으로 마모되지 않는다는 특성 때문에 고장모드를 열화·부식 같은 물리적 메커니즘이 아니라 논리 오류, 예외 미처리, 타이밍/동기화 오류, 자료형 오버플로우 같은 설계적·논리적 결함으로 재정의해 모듈·함수·인터페이스 단위로 분석합니다. 주로 구현/시험 단계에서 적용되며, FTA로 시스템 수준 위험을 좁혀놓은 뒤 그 하위 구성요소를 SFMEA로 점검하는 방식으로 상호보완적으로 쓰입니다.

STPA (System-Theoretic Process Analysis, 시스템이론 프로세스 분석)
사고를 개별 구성요소의 고장이 아니라 시스템 전체의 부적절한 제어(Inadequate Control)의 결과로 보는 STAMP 이론에 기반한 기법으로, 제어자-액추에이터-제어대상 프로세스-센서로 이어지는 제어루프를 모델링한 뒤 각 제어행위가 언제·왜 불안전해지는지(Unsafe Control Action)를 분석합니다. 소프트웨어·인적·조직적 요인까지 포괄해서 분석할 수 있어 자율주행차나 항공 자동화처럼 소프트웨어 집약적이고 복잡한 시스템에 특히 적합하며, 요구분석부터 운영까지 전 생명주기에 걸쳐 제어구조를 지속적으로 갱신하며 적용된다는 점이 다른 기법들과 다릅니다.

캡슐화

I. 데이터·기능 결합체, 캡슐화의 개요

• 개념: 데이터와 메서드 하나로 묶는 기법

• 특징: (1) 데이터-로직 단일 객체화 (2) 외부접근 제어 인터페이스

• 속성·행위 결합해 응집도 향상

II. 캡슐화의 구성도 및 구성요소

가. 캡슐화의 구성도

[Class]
 ├─ private [Data/속성]
 └─ public [Method] → 속성 접근/제어
      ↑
   [외부 객체] --호출--> Method

• 외부는 Method 통해서만 접근
• Method를 호출함으로써 객체에게 메시지를 전달함

나. 캡슐화의 구성요소

구분	구성요소	설명
접근제어	private 필드	내부데이터 은닉
접근제어	접근제어자	public/protected 구분
인터페이스	getter/setter	속성 간접 접근
인터페이스	public 메서드	기능 외부제공
구조	클래스	속성·행위 묶음단위
구조	객체	클래스 인스턴스화

• 접근제어·인터페이스·구조로 구성

III. 캡슐화 추가정보

구분	내용	비고
비교	정보은닉은 캡슐화 목적요소	상호보완 관계
효과	결합도 감소, 유지보수성 향상	변경영향 최소화
시사점	인터페이스 안정성 확보 필요	설계원칙 적용

• 결합도 낮춰 변경 파급 최소화

추상화

I. 핵심속성 추출기법, 추상화의 개요

• 개념: 공통특성 추출해 단순모델링

• 특징: (1) 불필요세부사항 제거 (2) 공통속성·행위 일반화

• 복잡시스템 단순화해 이해도 향상

II. 추상화의 구성도 및 구성요소

가. 추상화의 구성도

        [추상 클래스/인터페이스]
          (공통속성·행위 정의)
        /        |        \
[구체 클래스A] [구체 클래스B] [구체 클래스C]

• 다수 구체클래스에서 공통점 추출

III. 추상화의 구성요소

구분	구성요소	설명
구현체	추상클래스	공통기능 일부구현
구현체	인터페이스	명세만 정의
기법	일반화	공통속성 상위추출
기법	모델링	현실개념 단순표현
대상	속성추상화	데이터 공통화
대상	행위추상화	메서드 공통화

• 구현체·기법·대상 3범주 구성

III. 추상화 추가정보

구분	내용	비고
비교	상속의 기반원리로 작용	상속과 밀접관계
적용	설계초기 도메인분석 활용	요구분석 단계
시사점	과도한 추상화는 복잡도 증가	적정수준 필요

• 상속기반원리, 과도적용 주의

다형성

I. 동일인터페이스 다형태, 다형성의 개요

• 개념: 동일메시지 다른동작 수행능력

• 특징: (1) 오버라이딩 통한 재정의 (2) 오버로딩 통한 중복정의

• 하나 인터페이스 다양구현 지원

II. 다형성의 구성도 및 구성요소

가. 다형성의 구성도

[Animal.sound()]
   ├─ [Dog.sound()] → "멍멍"
   ├─ [Cat.sound()] → "야옹"
   └─ [Bird.sound()] → "짹짹"

• 동일호출, 객체별 다른동작 실행

나. 다형성의 구성요소

구분	구성요소	설명
정적다형성	오버로딩	매개변수 다른동명메서드
정적다형성	컴파일타임 바인딩	컴파일시 결정
동적다형성	오버라이딩	부모메서드 재정의
동적다형성	런타임 바인딩	실행시 결정
기반기술	가상함수테이블	동적바인딩 구현체
기반기술	업캐스팅	부모타입 참조사용

• 정적·동적다형성, 기반기술로 구성

III. 다형성 추가정보

구분	내용	비고
비교	상속기반 구현이 일반적	상속과 연계
효과	확장성·유연성 크게 향상	OCP원칙 지원
시사점	과다사용시 추적어려움	설계복잡도 유의

• OCP지원, 과다사용 주의필요

정보은닉

I. 내부구현 비공개, 정보은닉의 개요

• 개념: 내부구현 외부노출 차단원칙

• 특징: (1) 내부구조 외부차단 (2) 최소인터페이스만 공개

• 구현세부 감춰 독립성 확보

II. 정보은닉의 구성도 및 구성요소

가. 정보은닉의 구성도

[외부] --접근불가--> [private 내부구현]
[외부] --접근가능--> [public 인터페이스]

• 공개영역만 외부와 통신경로

나. 정보은닉의 구성요소

구분	구성요소	설명
접근수준	private	클래스내부 전용
접근수준	protected	상속관계 공유
은닉대상	내부알고리즘	구현로직 비공개
은닉대상	내부자료구조	데이터표현 비공개
공개영역	public API	외부제공 기능창구
공개영역	명세문서	사용법만 안내

• 접근수준·은닉대상·공개영역 구성

III. 정보은닉 추가정보

구분	내용	비고
비교	캡슐화 실현수단 성격강함	캡슐화와 밀접
효과	변경 파급효과 최소화	모듈독립성 향상
시사점	인터페이스 설계 신중필요	후속변경 최소화

• 캡슐화 실현수단, 독립성 강화

상속

I. 부모속성 재사용체계, 상속의 개요

• 개념: 상위클래스 속성·행위 재사용

• 특징: (1) 코드재사용성 향상 (2) 계층구조 통한 확장

• 부모특성 물려받아 자식확장구현

II. 상속의 구성도 및 구성요소

가. 상속의 구성도

[부모클래스: Vehicle]
       │ extends
   ┌───┴───┐
[Car]    [Truck]
(속성·메서드 상속+확장)

• 부모속성 물려받고 기능추가

나. 상속의 구성요소

구분	구성요소	설명
관계유형	단일상속	부모클래스 하나
관계유형	다중상속	부모클래스 다수
구성요소	부모클래스	공통속성 정의부
구성요소	자식클래스	상속받아 확장부
관련기법	메서드오버라이딩	부모기능 재정의
관련기법	super키워드	부모요소 명시접근

• 관계유형·구성요소·관련기법 구성

III. 상속 추가정보

구분	내용	비고
비교	다중상속시 다이아몬드문제 발생	Java등 단일상속제한
대안	인터페이스로 다중구현 지원	다중상속 보완
시사점	과도한 상속계층 결합도 증가	합성우선 원칙권장

• 다이아몬드문제, 합성우선 고려

형상관리

• 두음: 식통감기
• 종결어: 기법
• 키워드: 산출물, 체계적 관리, 품질 향상, 형상 식별, 형상 통제, 형상 감사, 형상 기록, 저장소, CCB, 변경 허용, 변경 심사, 형상관리 도구, SVN, Git, 베이스라인
• 목적: 무결성과 추적성 확보를 위해 산출물의 변화를 체계적으로 관리

구성도

형상 식별                CCB
형상 통제   -> 저장소 <-  CR(Change Request)
형상 감사               변경 심사
형상 기록               변경 허용

git, svn등

소스코드 뿐만 아니라 기획서, 설계 문서, 테스트 등이 모두 형상에 포함됨

DevOps, CI/CD: 형상관리 자동화가 확장된 현대적 실천 방식

형상관리 기준선(Baseline)

• 두음: 기할제
• 종결어: 상태
• 키워드: 특정 시점, 검토, 승인, 공식적, CCB 검토, 기능 기준선, 할당 기준선, 제품 기준선, 형상 감사, 형상항목식별자
• 목적: 변경통제의 기준점 확보

개념: 변경 통제의 기준점을 확보하기 위해 공식적으로 승인된 형상의 상태

구성도

요구사항 → [기능기준선]
              ↓
설계    → [할당기준선]
              ↓
구현/시험 → [제품기준선]
              ↓
        (변경시 CCB 승인 → 갱신)

• 기능→할당→제품 3단계, 변경은 CCB 승인 후 갱신

증분형 개발 모델

• 종결어: 개발 방식

• 키워드: 범위 분할, 병렬적 개발, 개발 후 통합, 점진적 통합, 요구사항 분할, 전체 아키텍처, 증분 단위, 반복 주기, 점진적 통합, 회귀 테스트, 형상관리, 위험관리

• 목적: 가치를 조기에 전달하기 위해 명확한 요구사항을 기반으로 범위를 나누어 개발하고 통합하는 방식

• 요구사항이 명확한 프로젝트에서 사용 가능

• 분할을 잘못하면 통합시 큰 비용 발생

구성도

[요구사항 분석]→[전체 아키텍처 설계]  
├→[증분1: 설계-구현-테스트-인도]  
├→[증분2: 설계-구현-테스트-통합]  
└→[증분N: 설계-구현-테스트-통합]→[전체 시스템 완성]

• 아키텍처 고정 후 기능 순차 증분

구성요소

구분	구성요소	설명
계획	요구사항 분할	기능단위 우선순위 분류
계획	전체 아키텍처	증분 수용 골격 설계
실행	증분 단위	독립 개발·테스트 단위
실행	반복 주기	증분별 개발 사이클
통합	점진적 통합	기존 시스템에 순차 결합
통합	회귀 테스트	통합시 기존기능 검증

• 계획·실행·통합 3단계 반복구조

증분형 개발 모델을 사용하면 병렬 개발이 가능하지만 필수는 아님. 가치를 조기에 전달하기 위해 중요도가 높은 기능부터 범위를 분할해 개발함.

진화형 개발모델

• 종결어: 개발 방식
• 키워드: 반복적, 프로토타입, 요구사항 불명확, 최종 시스템, 형상관리, 위험관리
• 목적: 초기 요구사항이 불명확한 프로젝트의 핵심 기능부터 개발하고 피드백을 받아 개선하는 개발 방식

구성도

• 요구사항 분석, 설계, 구현, 테스트, 피드백

• 위 단계들의 순환

• 각 반복마다 요구사항 구체화 및 기능 확장

• 간글: 반복적 개발-평가 순환으로 시스템 완성

구분	구성요소	설명
프로세스	반복 개발	단계별 기능 점증 개발
프로세스	고객 피드백	매 반복 평가·수정 반영
산출물	프로토타입	반복별 실행 가능 버전
산출물	최종 시스템	반복 누적된 완성본
관리	형상관리	버전별 변경이력 관리
관리	위험관리	반복초기 고위험 식별

• 프로세스·산출물·관리 3범주로 구성

요구공학의 요구사항 개발

요구공학은 ‘요구사항 개발’과 ‘요구사항 관리’로 나뉨.

• 두음: 추분명검
• 종결어: 활동
• 키워드: 요구사항 추출, 요구사항 분석, 요구사항 명세화, 요구사항 검증, SRS 문서, 도출기법, 분석기법, 명세 산출물, 확인 검증, 기능, 비기능, 반복적, 점진적
• 목적: 요구사항을 확정하기 위해 이해관계자로부터 요구사항을 추출하고 분석, 명세화, 검증하는 활동

구성도

[요구도출]→[요구분석]→[요구명세(SRS 작성)]→[요구확인(SRS 확정)]→(변경관리 피드백)  
↑__________________________________________|

• 4단계 순차 진행, 변경시 재귀환

구분	구성요소	설명
도출기법	인터뷰	이해관계자 직접면담
도출기법	워크숍/브레인스토밍	집단 아이디어 수집
분석기법	요구사항 분류	기능·비기능 구분
분석기법	우선순위 결정	중요도·긴급도 평가
명세산출물	SRS 명세서	요구사항 표준문서화
확인검증	요구사항 검토·승인	완전성·일관성 확인

• 도출·분석·명세·확인 4범주로 구성

요구공학의 요구사항 관리

형상관리와 유사함

• 두음: 협기변검
• 종결어: 활동
• 키워드: 협상, 기준선 관리, 변경 관리, 검증, 요구사항 일관성, 추적성 확보, 변경 통제, 형상 항목
• 목적: 이해관계자의 변경되는 요구사항을 산출물에 일관성 있게 반영하고 추적성을 확보하는 활동

구성도

[협상]→[기준선 관리]→[변경 관리]→[검증]→(피드백, 협상/변경 재유입)

• 확정→고정→통제→확인 순환구조

구분	구성요소	설명
협상	Win-Win협상	이해관계자 상충조정
협상	우선순위기법	MoSCoW 등 순위화
기준선관리	형상항목(CI)	버전관리 대상 식별
기준선관리	CCB승인	공식 기준선 확정
변경관리	변경요청(CR)	수정 공식절차
변경관리	영향분석	비용·일정·범위 분석
검증	추적성매트릭스	요구-산출물 매핑
검증	리뷰/테스트	충족여부 확인

• 협상·기준선·변경·검증 4범주 구성

폭포수 개발방법론

• 종결어: 개발 모델
• 키워드: 전통적, 순차적, 후행없음, 요구사항 수집, 분석, 아키텍처 설계, 시스템 설계, 구현, 배포, 유지보수, 단계별 산출물
• 목적: 전통적 소프트웨어 개발 방법론으로서 각 단계를 순차적으로 후행없이 진행하는 개발 방법론

구성도

• 순서대로 우하향. 순차적 진행과 후행이 없다는 것을 구성도에 표기

구분	구성요소	설명
상위단계	요구분석	사용자 요구사항 정의
상위단계	설계	시스템·SW 구조 설계
개발단계	구현	코딩 및 단위개발
개발단계	시험	통합·시스템 테스트
운영단계	배포	실환경 설치 및 이관
운영단계	유지보수	결함수정·기능개선

• 상위·개발·운영 3단계로 구분

애자일 개발방법론

• 종결어: 개발 모델
• 키워드: 짧은 주기, 설계 구현 검증 피드백 반복, 백로그(프로덕트, 스프린트), 스프린트, 번다운차트, 데일리 스크럼 미팅, 프로덕트 오너, 스크럼 마스터
• 목적: 소규모 개발팀이 짧은 주기 동안 설계,구현,검증을 반복하며 고객에게 가치를 전달하는 개발 모델

구성도

• 프로덕트 백로그 → 스프린트 백로그 → 설계 구현 테스트 → 배포 및 피드백 수집 → 회고 → 다시 스프린트 백로그 순환

구분	구성요소	설명
프로세스	스프린트	1~4주 단위 개발주기
프로세스	데일리스크럼	매일 진행상황 공유
산출물	제품백로그	요구사항 우선순위 목록
산출물	스프린트백로그	해당주기 작업목록
역할	스크럼마스터	프로세스 촉진·장애제거
역할	프로덕트오너	요구사항 우선순위 결정

• 프로세스·산출물·역할 3범주 구성

모놀리식 아키텍처

• 종결어: 서비스 아키텍처
• 키워드: 하나, 통합된 소스코드, 단일 언어 사용, 수직 확장이 효율적, 수평 확장은 비효율적, 전통적 3계층 (표현, 비즈니스, 데이터 계층)
• 목적: 하나의 실행 단위에서 모든 기능을 제공하는 서비스 아키텍처

구성도

• 요청 → 서버 → 데이터베이스 각 1개

구분	구성요소	설명
계층구조	표현계층	UI·화면처리 담당
계층구조	비즈니스계층	핵심로직·트랜잭션 처리
계층구조	데이터계층	DB접근·영속성 관리
배포단위	단일실행파일	WAR/EXE 등 통합 패키징
배포단위	단일DB	전모듈 공유 데이터저장소
운영요소	스케일업	서버증설 방식 확장

• 모놀리식 아키텍처의 경우 주로 전통적 3계층 아키텍처를 사용

마이크로서비스 아키텍처

• 종결어: 서비스 아키텍처
• 키워드: 분할된 소스코드, 여러 언어 사용, 효율적인 수평 확장 가능, API Gateway, 서비스 디스커버리, REST/gRPC, 메시지 브로커, 서비스별 DB, 컨테이너 오케스트레이션, 서킷 브레이커
• 목적: 비즈니스 기능 단위로 서비스를 분리해서 제공하는 서비스 아키텍처

구성도

• 요청 → API Gateway → 앱 서버 2개 → 각각의 앱 서버에 DB

구분	구성요소	설명
접점계층	API 게이트웨이	단일 진입점 라우팅
접점계층	서비스 디스커버리	서비스 위치 동적 탐색
통신계층	REST/gRPC	서비스간 동기 통신
통신계층	메시지 브로커	비동기 이벤트 통신
데이터계층	서비스별 DB	데이터 소유권 분리
운영계층	컨테이너 오케스트레이션	배포·확장 자동관리

• 접점·통신·데이터·운영 4범주 구성

아키텍처 스타일(=아키텍처 패턴, 아키텍처 모델)

• 두음: 구통상, 계클마 파브이 모블인
• 종결어: 해결책
• 키워드: 아키텍처가 만족해야 할 품질 속성 달성, 반복적 일반적 문제 해결, 재사용
• 목적: 아키텍처가 만족해야 할 품질 속성을 달성하기 위한 반복적/일반적인 문제를 해결하는 검증된 해결책

TBD: 각 패턴의 다이어그램 정리

구성도

1. 구조

   1. 계층형
   2. 클라이언트-서버
   3. 마스터-슬레이브

2. 통신/데이터 흐름

   1. 파이프-필터
   2. 브로커
   3. 이벤트-버스

3. 상호작용

   1. 모델-뷰-컨트롤러
   2. 블랙보드
   3. 인터프리터

+a)

• 저장소 구조 (Repository)
• MSA

‘소프트웨어 아키텍처 평가’ 토픽 추가

TODO: 아키텍처 설계 5단계 정리하기

요구사항 수집 → ?? → 4+1 View → 평가 → 프로토타입 → 배포

아키텍처는 5가지 그림을 그려줘야 함. 4+1 View

• Use Case
• Logical
• Implementation
• Process
• Deployment

이 때 아키텍처 스타일이 필요함.

설계를 했으면 잘 됐는지 ‘평가’를 한다 → SAAM

아키텍처 평가 기법

• 두음:
• 종결어:
• 키워드: 품질 수준, 고수준 판단, 이해관계자 요구 반영, 시나리오 기반, 설계/혼합 기반
• 목적: 아키텍처가 요구되는 품질 수준을 충족하는지 아키텍처 수준에서 평가하는 기법

구성도

• ADR과 ARID는 모듈/컴포넌트 상세 설계 적합성 검토 기법과 함께 사용

약어	원어(Full Name)	설명(10자 이내)
SAAM	Software Architecture Analysis Method	수정 용이성, 기능 분석
ATAM	Architecture Tradeoff Analysis Method	품질 속성 trade off 추가
EATAM	Extended ATAM	제품라인 가변성 확장평가
CBAM	Cost Benefit Analysis Method	경제적 평가 부분 보강 (경제적=비용 편익)
ADR	Architecture Decision Record	설계결정 기록문서
ARID	Active Reviews for Intermediate Designs (중간설계 능동적 검토)	아키텍처 일부를 초기에 평가

fyi) EATAM = ATAM + 변이점/가변성 분석 단계 → 단일 시스템이 아니라 제품군(패밀리) 전체를 대상으로 품질속성을 평가하는 확장 기법입니다.

아키텍처에 제품별 차이를 수용하기 위한 variation point를 정의하고, 각 variation point로부터 개별 제품을 적절히 파생할 수 있는지, 그리고 그 선택이 제품별 품질 속성과 품질 간 트레이드오프를 만족하는지를 평가하도록 ATAM을 확장한 것이 EATAM이다.

개별 방법에 대해서도 정리해보기. 140회 시험에 ATAM 나옴

디자인 패턴

• 두음: 생구행
• 종결어: 해결책
• 키워드: 코드 수준, 반복, 설계 문제, 재사용, 검증된
• 목적: 코드 수준에서 반복되는 설계 문제에 대해 재사용 가능한 검증된 해결책

다 외울 필요는 없다.. 아래 정도만 정의 쓸 수 있게 적당히 외우기.

구성도

1. 생성
   1. 추상 팩토리
   2. 팩토리 메서드
   3. 빌더
   4. 싱글톤
   5. 프로토타입
2. 구조
   1. 어댑터
   2. 프록시
   3. 브릿지
   4. Facade
   5. Composite
   6. Decorator
3. 행위
   1. 전략 패턴
   2. 템플릿 메서드
   3. 옵저버
   4. 이터레이터
   5. 비지터

허용적 라이선스

• 종결어: 오픈소스 라이선스
• 키워드: 파생저작물, 저작권 최소 제약, 라이센스 전파 의무 없음. 소스코드 비공개 가능, 확산/채택 극대화, MIT, Apache, BSD
• 목적: 파생저작물에 공개 의무가 없는 오픈소스 라이선스

구성도

[원저작물]→[사용/수정/재배포]→[저작권고지 유지]→[파생물 라이센스 자유선택]  
↳(카피레프트 미적용)

• 파생물에 원소스 공개 강제 없음

구분	구성요소	설명
라이센스 유형	MIT	최소조건, 고지문 유지
라이센스 유형	Apache 2.0	특허권 명시적 허여
라이센스 유형	BSD	3-Clause 무보증 명시
필수조건	저작권 고지	원저작자 표시 유지
필수조건	라이센스 사본 포함	배포시 원문 첨부
권리범위	상업적 이용	제한없이 판매·활용

• MIT·Apache·BSD 대표 3유형, 고지의무만 부과

기업 활용도 높음

카피레프트 라이선스

• 두음:
• 종결어: 강약파 GLM
• 키워드: 파생저작물, 공개 의무, 전파성, 강도(강함, 약함, 파일단위)
• 목적: 파생저작물을 동일한 라이선스 공개해야 하는 오픈소스 라이선스

구성도

[원저작물]→(카피레프트 적용)→[배포/수정 허용]→[파생저작물]→(동일 라이선스 상속)→[재배포]

• 라이선스 조건이 파생물까지 전파

구분	구성요소	설명
강도별	강한 카피레프트(GPL)	파생물 전체 동일라이선스
강도별	약한 카피레프트(LGPL)	링크 라이브러리만 예외
강도별	파일단위(MPL)	수정파일만 공개의무
적용범위	소스코드 공개	배포시 소스 제공 의무
적용범위	상업적 이용 허용	영리목적 사용 가능
권리주체	저작자 권리 유지	저작권 자체는 보유

• 강도(GPL/LGPL/MPL)별 의무범위 상이

소프트웨어 안전성 분석 기법

• 두음:
• 종결어: 기술
• 키워드: 잠재적 위험 Hazard, 불확실성 Risk, 피해 Harm, 트리거, HAZOP 가이드워드. FTA 하향식, FMEA 상향식
• 목적: 소프트웨어로 발생할 수 있는 잠재적 위험을 식별하고 분석해서 제거·통제하는 기법

‘전통적’과 ‘최근’으로 크게 구분된다.

전통적 3총사, 하드웨어 중심

• FTA, 트리 형태. 이벤트와 게이트(And, Or)
• FMEA, 위험의 강도 측정할 때. 3가지 봄. 심발검 (심각도, 발생가능성, 검출 가능성)
• HAZOP, 가이드워드

최근

• STPA, (스탬프?)

구성도

• 요구분석
  • FHA/PHA
  • HAZOP
• 설계
  • FTA
  • FMEA
• 구현/테스트
  • SFMEA
  • 코드분석
• 운영
  • 사고/변경 분석
  • 재발방지

요구분석/설계 (정성적)

• FHA: Functional Hazard Analysis, 기능위험분석
• PHA: Preliminary Hazard Analysis, 예비위험분석
• HAZOP: Hazard and Operability Study, 위험성 및 운전성 분석
  • 가이드워드

설계 (정성적, 정량적)

• FTA: Fault Tree Analysis, 결함수 분석
• FMEA: Failure Mode and Effects Analysis, 고장모드 영향분석

구현/테스트

• SFMEA: Software Failure Modes and Effects Analysis, 소프트웨어 고장모드 영향 분석

소프트웨어 안전성 분석 기법

I. SW 결함 사전예방 위한, 소프트웨어 안전성 분석 기법의 개요

• 개념: SW 생명주기별 위험요소 식별·분석 기법

• 특징: (1) 개발단계별 순차적 적용 (2) 정성·정량 분석 병행

• 생명주기 전반 걸친 위험 사전제거 활동

II. 소프트웨어 안전성 분석 기법의 구성도 및 구성요소

가. 소프트웨어 안전성 분석 기법의 구성도

[요구분석]         [설계]           [구현/테스트]
 FHA/PHA    →    FTA(하향식)   →    SFMEA
 HAZOP      →    FMEA(상향식)  →    코드분석
   │                 │               │
 위험식별          원인·영향분석      결함검증
   └──────────── 피드백(재분석) ────────┘

• 요구→설계→구현 순차 진행, 결과 피드백

나. 소프트웨어 안전성 분석 기법의 구성요소

구분	구성요소	설명
요구분석	FHA/PHA	시스템 위험요소 초기식별
요구분석	HAZOP	가이드워드 기반 이상상태 분석
설계	FTA	결함 원인 하향식 논리분석
설계	FMEA	고장모드 상향식 영향분석
구현/테스트	SFMEA	SW 모듈단위 고장모드분석
구현/테스트	코드분석	정적·동적 결함 검증

• 요구·설계·구현 3단계별 기법 매핑

III. 소프트웨어 안전성 분석 기법 적용시 고려사항

구분	내용	비고
기법선정	SW 특성·안전등급별 기법선택	SIL 등급 고려
기법선정	정성·정량 기법 병행적용	분석신뢰성 향상
전문성	분석팀 도메인 지식 필수확보	오분석 방지
전문성	안전전문가 검토 프로세스화	주관성 최소화
추적성	요구~구현간 위험분석 이력관리	변경영향 추적
추적성	분석결과 형상관리 연계	이력 일관성 유지
비용효율	분석범위 리스크 기반 조정	과잉분석 방지
비용효율	자동화도구 병행활용	분석공수 절감

• 소프트웨어의 성격에 맞는 수준의 안전진단으로 과비용 방지

AOP(Aspect Oriented Programming)

• 종결어: 기법
• 키워드: 횡단 관심사, 핵심 관심사, 응집도, 재사용성, 중복 제거, OOP 보완 기법
• 목적: 횡단 관심사를 분리하여 응집도를 높이고 중복을 제거하는 OOP 보완 기법

구성도

• 방사형과 유사하게
• 가운데 AOP. 좌측은 ‘핵심 관심사’, 우측은 ‘횡단 관심사’
  • 핵심 관심사 예시: 주문, 결제, 장바구니
  • 횡단 관심사 예시: 보안, 인증, 로깅
• 핵심 관심사측에서 AOP로 오는 화살표, Joint Point
• 횡단 관심사 측에서 AOP로 오는 화살표, Advice
• 하단에는 Point Cut

구성도 좌측에 십자형으로 그리는게 낫나? 횡단, 핵심 관심사

구성요소

구분	구성요소	설명
관심사	핵심 관심사	핵심 비즈니스 로직
관심사	횡단 관심사	공통 부가 기능
프로그래밍 요소	Advice	횡단관심사 로직
프로그래밍 요소	Joint Point	적용 가능 지점
프로그래밍 요소	Point Cut	로직과 적용점 연결정보
프로그래밍 요소	Aspect	횡단관심사 모듈 (Advice + Point Cut)
프로그래밍 요소	Weaving	로직 결합 과정

3단락 AOP 구현방식 2가지 비교

• Bytecode Weaving
  • 컴파일,빌드,실행시 bytecode를 조작해 횡단 관심사 기능을 삽입
• IoC 컨테이너 활용
  • Proxy 객체를 활용하여 의존성 주입시 횡단 관심사 기능을 객체에 추가

객체지향 설계 원칙 5가지

• 두음: SOLID
• 종결어: 설계 원칙
• 키워드: 유지보수성, 재사용성, 응집도, 결합도
• 목적: 객체지향 패러다임에서 재사용성과 유지보수성을 높이기 위한 5가지 설계 원칙

구성도

[SRP]단일책임 → [OCP]개방폐쇄 → [LSP]리스코프치환
      ↓                              ↓
[ISP]인터페이스분리 ← ← ← ← [DIP]의존관계역전
        (상호보완적 설계원칙 5종)

• 5원칙 상호보완적 적용 구조

구성요소 5개 개념도 테이블 TBD: 다이어그램 추가

• SRP
  • 객체는 한가지 책임만 담당해야 함
  • 다이어그램: Point → Point / Point Repository
• OCP
  • 클래스는 변경에는 닫혀있고 확장에는 열려있어야 함
  • 다이어그램: OAuth → Google, Naver, Facebook
• LSP
  • 부모 클래스 대신 어떤 자식 클래스라도 대입 가능해야 함
  • 다이어그램: Shape, Triangle, Rectangle
• ISP
  • 작은 단위로 인터페이스를 분리해야 함
  • 다이어그램: Repository → QueryRepo, CommandRepo
• DIP
  • 구체 클래스가 아니라 인터페이스를 의존해야 함
  • 다이어그램: List <<interface>> <- LinkedList, ArrayList

3단락

응집도와 결합도의 관점으로 본 객체지향 5원칙

• 응집도
  • SRP, ISP
  • 클래스,인터페이스 내부 응집 강화
• 결합도
  • OCP, LSP, DIP
  • 클래스 간 관계, 의존 구조 개선

휴리스틱에 의한 사용성 평가

• 두음: 상익 복일에 직효 핵명도
• 종결어: 기법
• 키워드: 사용성 원칙, 전문 평가자, 문제점 진단, 빠른 평가, 문제점 도출, 심각도 평가(0~4단계)
• 목적: 전문 평가자가 정립된 사용성 원칙을 기준으로 문제점을 진단하는 기법

구성도1

[평가계획]→[전문가 개별평가]→[휴리스틱 원칙 대조]→[문제점 도출]→[심각도 산정]→[통합 및 보고]

• 개별평가 후 결과취합 순차 구조

구성도2

사전 교육 -> 평가 수행 -> 심각도 판정 -> 결과 취합 -> 결과 보고

• 5단계 구성

원칙 10가지

• 상태 안내

• 익숙함

• 복구 가능성

• 일관성

• 에러 예방

• 직관성

• 효율성

• 핵심 정보

• 명확한 에러 문구

• 도움 서비스

구분	구성요소	설명
평가원칙	시스템상태 가시성	현재상태 사용자에 인지
평가원칙	오류방지 및 복구	오류예방·복구 지원
평가주체	사용성 전문가	3~5인 독립평가 수행
평가주체	진행촉진자	평가세션 조율·기록
평가결과	문제목록	발견된 사용성 결함
평가결과	심각도 등급	0~4단계 우선순위화

• 원칙·주체·결과 3범주로 구성

사용성 테스트

고객에게 물어보는 것.

대상자 찾아서 실행

• 두음: 탐평확비, 카페스
• 종결어: 기법
• 키워드: 실제 사용자, 제품 사용, 관찰/분석, 문제점/개선점, 탐색 테스트, 평가 테스트, 확인 테스트, 비교 테스트, 카드 소팅, 페이퍼 목업, 스크린 목업
• 목적: 실제 사용자가 제품을 사용하는 것을 관찰/분석해서 문제점/개선점을 발견하는 연구 기법

구성도

• 테스트 종류 4개 트리 형태, 탐평확비

구분	구성요소	설명
테스트 종류	탐색 테스트	문제점 발견 탐색
테스트 종류	평가 테스트	사용성 수준 평가
테스트 종류	확인 테스트	개선사항 검증
테스트 종류	비교 테스트	대안간 우열 비교
테스트 기법	카드 소팅	정보구조 분류
테스트 기법	페이퍼 목업	종이 시제품 테스트
테스트 기법	스크린 목업	화면 시제품 테스트

테스트 표준 ISO 29119

• 두음: 개테프도테키, 조관동, 명구경
• 종결어: 국제 표준
• 키워드: 계층화, 문서 표준화
• 목적: SW 개발 전 과정의 테스팅 프로세스 관련 국제 표준

구성도

• Part1. 개념과 정의
• Part2. 테스트 프로세스
• Part3. 문서(Documentation)
• Part4. 기법(Technique)
• Part5. 키워드 기반 테스팅
• 연관표준: ISO 33063, 절차 평가용

2가 가운데에 있고 모든 파트와 ISO 33063에 화살표

구성요소

구분	구성요소	설명
프로세스	조직 테스트 프로세스	정책·전략 수립
프로세스	테스트 관리 프로세스	계획·모니터링·통제
프로세스	동적 테스트 프로세스	설계·실행·완료
기법	명세 기반	블랙박스 테스팅
기법	구조 기반	화이트박스 테스팅
기법	경험 기반	테스터 경험·직관 활용

• 프로세스·기법 2범주 구성

테스트 설계 기법 3가지: 명세(블랙박스), 구조(화이트박스), 경험기반

명세기반

• 불동경의상 유분페원오 구조기반
• 화제루 결구조 다변조 경험기반
• 탐색적 테스팅, 체크리스트, 특성 테스팅, 오류 추정, 분류 트리

ISO 25000 (SQuRE)

• 두음: 31024 요모관측평
• 종결어: 국제 표준
• 키워드: 요구사항, 품질 모델, 품질 관리, 품질 측정, 품질 평가
• 목적: SW 개발 공정 각 단계의 산출물의 품질을 측정하기 위한 국제 표준

구성도

구성요소

구분	구성요소	설명
2500n	품질관리부	표준군 전체 관리지침
2501n	품질모델부	품질특성 정의(25010)
2502n	품질측정부	품질측정지표 제공
2503n	품질요구부	요구사항 명세화
2504n	품질평가부	평가절차·방법 규정
품질	제품 품질	GS 인증
품질	프로세스 품질	PS 인증

• 관리·모델·측정·요구·평가 5분야

품질요소 2가지

• 제품 품질 → GS, Good Software
• 프로세스 품질 → SP, Software Process

인증 ‘제도’는 ‘법근거, 대상, 인증기준, 절차’ 4개가 나와야 함. 제도 공부할 때는 프레임워크처럼 이 4개로 공부하기

DevOps

• 종결어: 방법론
• 키워드: 적시 출시, 소통, 협업, 자동화, CI/CD, 순환, 형상관리, IaC, 신뢰성 엔지니어링
• 목적: 소프트웨어 적시 출시를 위해 개발과 운영의 소통, 협업, 자동화를 강조하는 개발 방법론

구성도

• 설계 → 구현 → 빌드 → 테스트
• 릴리즈 → 배포 → 운영 → 모니터링
• 옆으로 뉘운 8자로. 12시 시작해서 시계 반대방향. 좌측 Dev, 우측 Ops

구분	구성요소	설명
형상관리	코드 형상관리	- git등의 도구 도입
형상관리	지속적 통합	- 짧은 주기 Push
인프라	지속적 배포	- 자동화된 배포 시스템
인프라	IaC	- 인프라 형상관리
안전성	모니터링&로깅	- 에러 로그 알람 구성
안전성	신뢰성 엔지니어링	- DevOps 실천 방법론

DevOps 5가지 핵심 요소 CALMS

• Culture: 개발/운영 협업 문화, 사일로 제거
• Automation: 빌드, 테스트, 배포, 인프라 자동화
• Lean: 낭비 제거, 작은 단위 반복 개선
• Measurement: 지표 기반 모니터링/피드백
• Sharing: 지식/책임 공유

3단락에 방사형으로 적어도 괜찮을듯?

회귀테스트 (Regression Test)

변경사항이 발생했을 때

사이드이펙트와 리플 이펙트를 확인하기 위함

• 두음: RS 올셀프점
• 종결어: 반복 시험
• 키워드: 사이드이펙트(부작용), 리플 이펙트(파급효과), 변경
• 목적: 소프트웨어에 변경이 발생했을 때 새로 발생하는 오류가 없는지 확인하는 반복 시험

구성도

구분	구성요소	설명
효과	사이드 이펙트	수정 시 오류 발생
효과	리플 이펙트	영향 파급 전파
테스트 종류	전체 테스트	전체 재실행
테스트 종류	선별적 테스트	연관 부분만 선별
테스트 종류	우선순위 테스트	위험도순 실행
테스트 종류	점진적 테스트	단계적 확대 실행

고려사항 (방사형)

• 개발 테스트 통합

• 테스트 자동화

• 테스트 축적

• 테스트 조직

• 개발 과정에서 수시로 자동화된 테스트 실행

• 작성된 테스트는 부작용/파급효과를 막는 자산이 됨

• 자동화하기 힘든 테스트를 수행하기 위한 전담 조직 필요

V-모델 (V-Model)

• 두음: 단통시인설
• 종결어: 개발 모델
• 키워드: 폭포수 확장, 단위, 통합, 시스템, 인수, 설치, 검증/확인 중심, 단계별 산출물, 추적성 확보
• 목적: 개발 단계와 테스트 종류를 1:1로 대응시켜 폭포수 모델을 확장한 개발 모델

구성도

요구분석 ────────────── 인수테스트
  \                       /
 시스템설계 ──────── 시스템테스트
    \                   /
  아키텍처 설계 ───── 통합테스트
      \               /
   모듈 설계 ────── 단위테스트
         \         /
             코딩

• 좌측 개발, 우측 테스트 V자 대응구조

구분	구성요소	설명
개발단계	요구분석/설계	좌측 하향식 개발과정
개발단계	상세설계/코딩	구현 직전 최종단계
테스트단계	단위/통합테스트	코드·모듈 검증
테스트단계	시스템/인수테스트	전체·사용자 검증
검증기법	정적/동적검증	산출물 리뷰·실행검증
검증기법	트레이서빌리티	요구-테스트 추적관리

• 개발·테스트·검증기법 3범주로 구성

3단락 다중 V-모델 (모프제)

• 점점 커지는 V자 3개

• 설계 구현 테스트

• 모델 검증, 프로토타입 검증, 제품 검증

• 규모가 크거나 반복/점증적으로 개발하는 프로젝트에 사용

화이트박스 테스트

• 두음: 화제루, 구결조 조변다
• 종결어: 테스트 기법
• 키워드: 개발자 관점, 내부 로직, 구조 기반
• 목적: 개발자 관점에서 내부 로직을 알고 수행하는 구조 기반 테스트 기법

구성도

• 구문 커버리지

  • 모든 구문들이 최소 1번 이상 수행

• 결정 커버리지

  • 전체 결정문이 참/거짓을 최소 1번 이상 수행

• 조건 커버리지

  • 개별 조건문이 참/거짓을 최소 1번 이상 수행

• 조건/결정 커버리지

  • 전체 조건과 개별 조건 모두 참/거짓을 갖도록 수행

• 변경조건/결정 커버리지

  • 개별 조건이 독립적으로 전체 결정 결과를 바꾸도록 수행

• 다중 조건 커버리지

  • 개별 조건들의 참/거짓이 가능한 모든 케이스로 수행

TODO: 커버리지 사례 정리, A와 B로

구성요소 테이블을

• 유형
• 설명
• 사례 3개 컬럼으로 적기

블랙박스 테스트

사용자 관점

• 두음: 불동경의상 유분페원오
• 종결어: 기법
• 키워드: 사용자 관점
• 목적: 사용자 관점에서 내부 로직을 모르고 수행하는 명세 기반 테스트 기법

구성도

• 동등 클래스 분할 기법
  • 동일하게 처리되는 값들 중 대표값 1개 추출해서 테스트
• 경계값 분석
  • 경계값과 인접값을 집중적으로 테스트
• 의사결정 테이블 테스팅
  • 여러 조건의 조합에 따른 결과를 표로 정리하여 검증
• 상태 전이 테스팅
  • 상태 전이를 다이어그램으로 표현해서 검증
• 유스케이스 테스팅
  • 사용자 관점의 업무 시나리오 기반 테스트
• 분류 트리 기법
  • 입력을 트리 구조로 분류하고 조합하여 테스트
• 페어와이즈 테스팅
  • 모든 파라미터 쌍을 최소 1회 이상 테슽
• 원인-결과 그래프
  • 입출력간 논리적 관계를 그래프로 표현
• 오류 예측 기법
  • 테스터의 휴리스틱을 바탕으로 결함 발생 부위 예측

SW 분리발주 (상용SW 직접구매제도)

국내 제도 물어볼 때: 1. 법근거, 2. 대상, 3. 절차, 4. 예외

• 두음: 예외 기준 - 민통 현현현
• 종결어: 제도
• 키워드: SW 산업 겅쟁력, 상용 SW, 별도 발주
• 목적: SW 산업 경쟁력을 강화하기 위해 상용SW를 SI사업과 별도로 발주하는 제도

구성도

[발주기관] 
   ├─(직접계약)→ [상용SW 공급사]
   └─(별도발주)→ [IT서비스 사업자] → (SI 구축)
        ↑
   [조달청 종합쇼핑몰/디지털서비스몰] (등록·검증)
        ↑
   [대상판정: 사업규모+SW가격/쇼핑몰등록 요건]

• 발주기관이 SW·SI 이원화 계약 체결

법률: 소프트웨어 진흥법 제54조(국가기관등의 상용소프트웨어 구매) 지침(행정규칙): 소프트웨어사업 계약 및 관리감독에 관한 지침 제7조(직접구매 대상), 제8조(직접구매 제외) 대상: 1차 && 2차조건중 1개 이상 만족시

• 1차: 총 사업규모 3억원 이상
• 2차
  • 1. 조달청 등록여부: 조달청 종합쇼핑몰 등록 SW
  • 2. GS, CC, NEP, NET 인증 또는 국가정보원 검증·지정 SW로서 5천만원 이상인 경우 (동일 SW를 다량 구매해 5천만원을 초과하는 경우도 포함) 제외 기준
• 대상 사업: 민간투자형 SW사업
• 대상 SW
  • 정보시스템 통합 불가능
  • 현저한 사업비용 증가
  • 현저한 사업기간 증가
  • 현저하게 비효율적

절차 (개략 프로세스)

1. 직접구매 대상 여부 판단: RFP 작성 단계에서 1차·2차 조건 검토
2. 직접구매 대상 상용SW 구매계획 수립: 대상 품목·직접구매 여부·제외사유를 명시한 구매계획서 작성(발주기관 규정 별지서식)
3. 제외사유 사전 검토 요청: 제외하고자 하는 SW가 있으면 사전 검토·소명 절차 진행
4. 입찰공고 및 발주: SI사업과 SW구매를 분리 발주(경쟁입찰 또는 종합쇼핑몰 등을 통한 수의/카탈로그 구매)
5. BMT(성능시험) 실시: 경쟁입찰로 구매 시 BMT를 실시해 평가에 반영하되, 조달청 등록 제품은 BMT 생략 가능
6. 계약·검수: 별도 계약 체결 후 SI사업자와의 연계·통합 관리

(BMT: BenchMark Test)

문제 풀이 시 자주 나오는 키워드 축으로 정리하면: 개념(구 분리발주) – 법적근거(진흥법 §54, 지침 §7·§8) – 대상(1차/2차 조건) – 제외기준(사업/SW) – 절차(판단→계획→검토→발주→BMT→계약) 순으로 구조를 기억해두면 서술형 답안 뼈대로 바로 활용할 수 있습니다.

fyi) 국내 SW 인증

구분	초점	소관 성격
GS(Good Software)	SW 품질 전반	소프트웨어산업 진흥법 계열
CC(Common Criteria)	보안성	국가정보원 계열 (보안SW 특화)
NEP (New Excellent Product)	신제품의 우수성	산업기술 인증 계열
NET (Net Excellent Technology)	신기술의 우수성	산업기술 인증 계열

SW 분할발주

법근거: 「행정기관 및 공공기관 정보시스템 구축·운영 지침」 제14조의4 — 분석·설계사업의 분할발주 허용

• 두음: 공기부
• 종결어: 방식
• 키워드: 사업 불확실성, 실패 위험, 정보시스템 구축 사업, 계약 나눔, 공정분할, 기능분할, 부품분할
• 목적: 사업 불확실성과 실패 위험을 줄이기 위해 정보시스템 구축 사업을 여러 계약으로 나누어 발주하는 방식

구성도

• 계획 수립 → 분할 전략 수립 → 발주 → 사업관리 → 인수 → 통합 및 종료. ⇒ 모양자 쓰기
• (발주 → 사업관리 → 인수)를 분할공정별 반복

구성요소 테이블은 6단계 쓰기

테이블은 |#|단계|설명| 이렇게 3단으로

정보시스템 감리

• 두음: 예현시 (예비조사, 현장감시, 시정조치)
• 종결어: 제도
• 키워드: 제3자 관점, 전자정부법 제57조
• 목적: 정보시스템의 효율성 향상, 안전성 확보를 위해 제 3자적 관점에서 시스템을 독립적으로 점검/평가하는 활동

구성도

• 예비조사 → 현장감리 → 시정조치의 순차적 3단계

구성요소

• 예비조사
  • 범위 확정
  • 계획 수립
• 현장감리
  • 문서 심사, 인터뷰
  • 문제점 도출
• 시정조치
  • 시정계획서 작성
  • 사후관리 확인

구분	구성요소	설명
주체	감리법인	독립적 제3자 검증기관
주체	감리원	자격보유 전문인력
절차	감리계획수립	범위·기준 사전정의
절차	감리수행	현장점검·인터뷰·문서검토
산출물	감리보고서	문제점·개선사항 기술
산출물	시정조치계획	개선이행 계획 수립

법근거

• 전자정부법 제 57조

대상 (OR 조건임)

• 사업비
  • 5억원 이상
• 특성
  • 대국민 서비스
  • 여러 행정기관등이 공동으로 구축
• 행정기관장의 필요성 판단

예외

구분	내용
제외 규정	사업비 1억 원 미만 소규모 + 비용 대비 효과 낮다고 인정 시
감리 생략	전자정부사업관리 위탁 수행 시, 사업비 5억 원 미만 또는 사업기간 5개월 미만이면 생략 가능
특수정보 관련(법 제57조제4항)	국방·외교·안보 등 국가안전보장 정보, 개인정보, 기밀성 높은 정보를 다루는 시스템은 별도 고려 대상

실무 판단 순서 (관계 정리)

1. 사업비 5억 원 이상인지 먼저 확인 (가장 명확한 기준)
2. 5억 원 미만이라도 시스템 특성(대국민서비스, 공동구축)에 해당하면 의무 대상 가능
3. 판단 기준 시점은 예산 편성 단계가 원칙 (계약금액이 아닌 예산 기준)

절차

• 계획
• 수행
• 보고
• 사후관리

더 복잡한 절차 있겠지… 일단 이렇게 4단계로만 알고 넘어가자

PMO

• 두음: 기집사 (기획, 집행, 사후), 성변보 (성과, 변화, 보안)
• 종결어: 제도
• 키워드: 전자정부법 제 64조의 2, 사업 품질 향상, 발주자 관점, 사업 관리, 기술 지원
• 목적: 사업 품질 향상을 위해 발주자 관점에서 사업 관리를 수행하고 기술을 지원하는 제도

프로세스그룹 10개에서 성변보 추가

• 기획: 통합관리, 성과관리
• 집행: 10개 + 성변보 - 원가관리, 총 12개
• 사후: 통합관리, 성과관리, 변화관리

구성도

• 역삼각형 그리자. 꼭지점마다 ‘발주기관’, ‘PMO 사업자’, ‘PMO대상사업 수행자’, 역삼각형 가운데는 PMO
• 삼각형 선의 화살표 방향과 화살표 내용
  • 발주기관 — (전자정부사업관리 위탁(PMO) 계약) ⇒ PMO 사업자
  • 발주기관 — (관리/감독) ⇒ PMO대상사업 수행자
  • PMO 사업자 — (사업관리/기술지원) ⇒ PMO대상사업 수행자

      발주기관                   PMO 사업자
      
      
      
                PMO대상사업
                  수행자

법근거

• 전자정부법 제 64조 2
• 전자정부법 시행령 제 78조 2 ~ 제 78조의 5

대상

• 의무 대상 없음
• 발주기관이 자체적으로 PMO 도입 여부를 결정함

절차 (기집사)

• 기획 단계
  • 통합관리, 성과관리
• 집행 단계
  • 통합관리, 범위관리, 일정관리, 품질관리, 자원 관리, 의사소통 관리, 위험 관리, 조달 관리, 이해관계자 관리, 성과관리, 변화관리, 보안관리
• 사후관리 단계
  • 통합관리, 성과관리, 변화관리

3R (역공학, 재공학, 재사용)

• 두음: 역재재
• 종결어: 기법
• 키워드: 역공학, 재공학, 재사용, 분석, 개선, 재사용
• 목적: SW위기 극복을 위해 레거시 자산을 최대한 활용

SDLC의 유지,관리 단계

• 역공학: 산출물 다시 만들어내기
• 재공학: >> 구조화 <<
• 재사용: 다른 프로젝트에 활용

I. SW 자산 재활용체계, 3R의 개요

• 개념: 기존SW 분석·개선·재사용 활동 총칭

• 특징: (1) 레거시 자산 가치 재발견 (2) 개발비용·기간 절감

• 기존자산 분석·개선·재사용 통합기법

II. 3R의 구성도 및 구성요소

가. 3R의 구성도

[기존 시스템]
     │
     ▼
[Reverse Engineering] ── 분석 ──▶ [설계정보 추출]
     │
     ▼
[Reengineering] ── 개선 ──▶ [구조/코드 재구성]
     │
     ▼
[Reuse] ── 재사용 ──▶ [신규 시스템 구축]

• 분석→개선→재사용 순차적 흐름

나. 3R의 구성요소

구분	구성요소	설명
역공학	코드분석	소스에서 설계정보 추출
역공학	구조분석	아키텍처/흐름 파악
재공학	리팩토링	코드품질 개선
재공학	재구조화	시스템구조 재설계
재사용	자산라이브러리	검증된 모듈 축적
재사용	컴포넌트조합	재사용자산 조립적용

• 역공학·재공학·재사용 3단계 구성

III. 3R 추가정보

구분	내용	비고
비교	순공학과 반대방향 접근	Forward Eng. 대비
관련기술	정적/동적 분석도구 활용	CASE 도구 연계
시사점	레거시 현대화 핵심전략	유지보수 효율화

• 레거시 자산 최대활용 전략

리팩토링

가독성이 떨어지는 코드를 클린 코드로 바꾸는 과정

I. 코드 개선기법, 리팩토링의 개요

• 개념: 외부동작 유지하며 코드구조 개선

• 특징: (1) 동작 변경없이 구조만 개선 (2) 소규모 단계적 변경 반복

• 가독성·유지보수성 향상 위한 코드 정제

II. 리팩토링의 구성도 및 구성요소

가. 리팩토링의 구성도

[테스트코드 확보]→[냄새(Smell) 식별]
      ↓
[소규모 리팩토링 수행]→[테스트 검증]
      ↓
[커밋]→(반복)

• 식별→개선→검증 순환 프로세스

나. 리팩토링의 구성요소

구분	구성요소	설명
대상식별	코드 스멜	중복·긴 메서드 등 징후
대상식별	정적분석 도구	스멜 자동 탐지
기법	메서드 추출	중복로직 함수화
기법	클래스 분리	책임 단일화
안전장치	단위테스트	동작 불변 검증
안전장치	버전관리	단계별 롤백 대비

• 식별·기법·안전장치 3범주로 구성

III. 리팩토링 추가정보

구분	내용	비고
비교	재작성 대비 점진적·저위험	리엔지니어링과 구분
관련기술	TDD와 결합해 안전성 강화	Red-Green-Refactor
시사점	기술부채 감소, 개발생산성 향상	지속적 적용 필요

• 점진적 개선, TDD 연계 추세

SW규모산정

I. SW개발비 산정 기초, SW규모산정의 개요

• 개념: SW 개발규모 정량화 측정기법

• 특징: (1) 기능점수·LOC 등 정량화 (2) 개발비 산정 선행활동

• SW개발 범위·비용 산정의 기초자료

II. SW규모산정의 구성도 및 구성요소

가. SW규모산정의 구성도

[요구사항 분석]
      ↓
 ┌─────────────┬─────────────┐
[하향식]        [상향식]
 전체→세부       세부→전체
 초기 개략산정    설계후 정밀산정
      ↓             ↓
 [보정계수 적용] → [개발규모 확정]
      ↓
 [개발비/기간 산정]

• 초기 하향식, 이후 상향식 정밀화

나. SW규모산정의 구성요소

구분	구성요소	설명
하향식	전문가판단법	경험기반 전체규모 추정
하향식	Delphi법	전문가 의견 반복수렴
하향식	유사프로젝트비교법	과거사례 유추 산정
상향식	LOC법	코드라인 수 기반 측정
상향식	기능점수(FP)법	기능단위별 산정후 합산
상향식	Use Case Point법	유스케이스별 산정후 합산

• 하향식 3기법, 상향식 3기법 대별

III. SW규모산정 추가정보

구분	내용	비고
비교	하향식 신속·주관적, 상향식 정확·시간소요	산정단계별 선택
적용시점	하향식 기획초기, 상향식 설계이후	요구사항 구체화도 좌우
실무동향	초기 하향식 후 상향식 재산정 혼합	정확도·효율 균형

• 단계별 혼합적용이 실무 표준

SW규모산정 하향식 기법

I. 전문가 경험기반 추정법, SW규모산정 하향식 기법의 개요

• 개념: 전체 시스템 규모서 하위 기능 배분 추정

• 특징: (1) 전문가 경험·유추 기반 추정 (2) 상세설계 이전 신속 산정

• 프로젝트 초기 개략적 규모 신속 파악

II. SW규모산정 하향식 기법의 구성도 및 구성요소

가. SW규모산정 하향식 기법의 구성도

[전체 시스템 규모 추정]
        ↓
[유사 프로젝트 데이터 참조]
        ↓
[하위 서브시스템별 비율 배분]
        ↓
[모듈/기능 단위 세부 규모 산출]

• 전체→부분 순차적 배분 흐름

나. SW규모산정 하향식 기법의 구성요소

구분	구성요소	설명
산정기법	전문가 판단법	경험기반 유추 산정
산정기법	유추법	유사 SW 규모 비교
산정기법	델파이법	전문가 합의 도출
기준정보	기능 목록서	시스템 범위 정의
기준정보	과거 사업 실적	이력 기반 참조치
배분방식	가중치 배분법	서브시스템별 비율 산정

• 산정기법·기준정보·배분방식 3범주 재구성

III. SW규모산정 하향식 기법 추가정보

구분	내용	비고
비교	상향식 대비 신속·저정밀	상향식은 LOC·FP 정밀
한계	전문가 주관성 개입 위험	편차 보정 필요
시사점	초기 견적·상위계획 활용	상세단계서 상향식 병행

• 신속성 강점, 정밀도는 한계

SW규모산정 상향식 기법

I. LOC/기능점수 기반 산정, SW규모산정 상향식 기법의 개요

• 개념: 세부 단위 산정 후 합산하는 방식

• 특징: (1) 구성요소별 상세 분석 필요 (2) 정확도 높으나 시간 소요

• 하위 요소 합산으로 전체 규모 도출

II. SW규모산정 상향식 기법의 구성도 및 구성요소

가. SW규모산정 상향식 기법의 구성도

[요구사항 분석]
      ↓
[기능/모듈 단위 분해]
      ↓
[단위별 규모 산정] → LOC 방식 / FP 방식 / UCP 방식
      ↓
[단위 규모 합산]
      ↓
[전체 SW 규모 산출]

• 분해→개별산정→합산의 상향 흐름

나. SW규모산정 상향식 기법의 구성요소

구분	구성요소	설명
LOC기법	예측LOC	모듈별 코드라인수 추정
LOC기법	보정계수	신규·수정·재사용 구분
FP기법	기능유형분류	EI/EO/EQ/ILF/EIF 구분
FP기법	복잡도가중치	기능별 난이도 반영
UCP기법	행위자·유스케이스 분류	액터·유스케이스 가중치 산정
UCP기법	기술·환경요인 보정	난이도·숙련도 반영 산정

• LOC·FP·UCP기법의 단위산정 방식으로 구성

III. SW규모산정 상향식 기법 추가정보

구분	내용	비고
비교	하향식 대비 상세·정확	초기단계엔 하향식 유리
관련기술	기능점수(FP) 표준 활용 확대	ISO/IEC 20926
시사점	발주자·수행사 간 분쟁예방 근거	대가산정 활용

• 하향식 대비 정밀하나 초기적용 제한

HW 규모산정

• 두음
  • 기법: 수참시
  • 절차: 구기참가
• 종결어: 활동
• 키워드:
• 목적: 필요자원량을 예측하기 위해

HW 규모산정

I. 정보시스템 자원소요량 예측, HW 규모산정의 개요

• 개념: 시스템 처리요구 맞는 HW용량 산출

• 특징: (1) 정량적 산정기법 활용 (2) 여유율·확장성 고려

• 업무량 기반 최적 HW용량 결정

II. HW 규모산정의 구성도 및 구성요소

가. HW 규모산정의 구성도

HW 규모산정 기법
 ├─ 수식계산법 → TPS/자원계수 기반 산식
 ├─ 참조법     → 유사시스템 벤치마크 참조
 └─ 시뮬레이션법 → 부하모델 시뮬레이션
        ↓
   산정결과 HW Spec 도출

• 3대 기법 병행·상호검증 구조

나. HW 규모산정의 구성요소

구분	구성요소	설명
수식계산법	처리량기반산식	TPS·CPU계수 곱산정
수식계산법	벤치마크계수적용	TPC-C등 표준계수 반영
참조법	유사시스템참조	기구축 사례 규모 비교
참조법	산정기준표활용	조달청 등 기준표 적용
시뮬레이션법	부하시뮬레이션모델링	가상부하 발생 검증
시뮬레이션법	성능예측모델링	응답시간·처리율 예측

• 계산·참조·모의 3기법 상호보완

III. HW 규모산정 추가정보 (공공사업 산정절차)

구분	내용	비고
1단계	구축방향 및 기초자료조사	사업목표·요건 파악
2단계	기초자료 및 업무분석	업무량·트랜잭션 분석
3단계	참조모델 결정 및 규모산정	3대 기법 적용 산정
4단계	참조모델별 가중치 적용	기법별 결과 종합보정

• 조사→분석→산정→보정 4단계 절차

소프트웨어 결합도

• 두음: 자스제외공내
• 종결어: 평가 척도
• 키워드:
• 목적:

I. 모듈 간 상호의존 정도, 결합도의 개요

• 개념: 모듈 간 상호의존성 정도

• 특징: (1) 낮을수록 독립성 높음 (2) 유지보수성에 영향

• 결합도 낮을수록 설계 품질 우수

II. 결합도의 구성도 및 구성요소

가. 결합도의 구성도

[낮음/약함]
 자료결합도
   ↓
 스탬프결합도
   ↓
 제어결합도
   ↓
 외부결합도
   ↓
 공통결합도
   ↓
 내용결합도
[높음/강함]

• 자료→내용 순 결합도 점증 구조

나. 결합도의 구성요소

구분	구성요소	설명
약결합	자료결합도	필요 데이터만 파라미터 전달
약결합	스탬프결합도	자료구조 통째로 전달
중결합	제어결합도	제어flag로 로직 흐름 전달
중결합	외부결합도	외부 전역변수 참조 공유
강결합	공통결합도	공통 데이터영역 공유
강결합	내용결합도	타 모듈 내부 직접 참조

• 약·중·강결합 3단계로 구분

III. 결합도 추가정보

구분	내용	비고
비교	응집도는 모듈 내부 요소 관련성	결합도와 대비 개념
시사점	결합도 최소화 설계 원칙 필요	고응집·저결합 지향
적용	인터페이스 최소화로 결합도 완화	자료결합도 지향 설계

• 저결합·고응집이 설계 목표

소프트웨어 응집도

• 두음: 우논시절통순기
• 종결어: 평가 척도
• 키워드:
• 목적:

구성도

I. 모듈 내부요소 결합강도, 응집도의 개요

• 개념: 모듈 내 요소들 관련성 정도

• 특징: (1) 응집도 높을수록 품질 우수 (2) 우논시절통순기 순 강도증가

• 응집도 높은 모듈이 재사용·유지보수 유리

II. 응집도의 구성도 및 구성요소

가. 응집도의 구성도

[약함]
우연적(Coincidental)
  ↓
논리적(Logical)
  ↓
시간적(Temporal)
  ↓
절차적(Procedural)
  ↓
통신적(Communicational)
  ↓
순차적(Sequential)
  ↓
기능적(Functional)
[강함]

• 우논시절통순기 순 약→강 7단계

나. 응집도의 구성요소

구분	구성요소	설명
저응집(약함)	우연적 응집	무관 요소 임의 결합
저응집(약함)	논리적 응집	유사기능 논리적 묶음
저응집(약함)	시간적 응집	동일시점 실행 요소
중응집	절차적 응집	순서있는 절차 수행
중응집	통신적 응집	동일데이터 참조 요소
고응집(강함)	순차적 응집	출력이 다음입력 연결
고응집(강함)	기능적 응집	단일기능 수행 집중

• 저·중·고응집 3범주 7단계 구성

III. 응집도 추가정보

구분	내용	비고
비교	결합도와 반비례 관계	고응집·저결합 목표
설계원칙	단일책임원칙(SRP)과 연계	객체지향 설계
시사점	기능적 응집 지향 설계	유지보수성 향상

• 저결합·고응집이 이상적 모듈설계

로우코드 (Low Code)

I. 시각화 기반 개발방식, 로우코드의 개요

• 개념: 최소코딩으로 앱 개발하는 방법론

• 특징: (1) GUI 기반 드래그앤드롭 개발 (2) 사전정의 컴포넌트 재사용

• 시각적 도구로 개발생산성 극대화

II. 로우코드의 구성도 및 구성요소

가. 로우코드의 구성도

[비주얼 디자이너]→[컴포넌트 라이브러리]
        ↓                    ↓
   [워크플로우 엔진]←→[데이터 모델러]
        ↓
[자동 코드생성/배포]→[런타임 환경]

• 설계-생성-배포 통합 파이프라인

나. 로우코드의 구성요소

구분	구성요소	설명
개발도구	비주얼 빌더	드래그앤드롭 화면구성
개발도구	컴포넌트 라이브러리	재사용 UI/로직 모듈
실행기반	워크플로우 엔진	비즈니스로직 자동처리
실행기반	코드 생성기	설계내용 실제코드 변환
데이터	데이터 모델러	스키마·연동 시각설계
데이터	API 커넥터	외부시스템 연계

• 도구·실행·데이터 3범주로 구성

III. 로우코드 추가정보

구분	내용	비고
비교	노코드 대비 확장성·커스터마이징 우위	노코드는 비개발자 전용
관련기술	AI 결합한 지능형 로우코드 확산	최신 트렌드
시사점	개발기간 단축, 시민개발자 육성	도입효과

• 노코드와 스펙트럼상 차별화, AI 결합 가속

노코드

I. 코드 없는 SW 개발환경, 노코드의 개요

• 개념: 코딩없이 UI로 SW 개발하는 방식

• 특징: (1) 드래그앤드롭 시각적 개발 (2) 비개발자도 앱 제작

• 시각적 도구로 비개발자 SW 제작 지원

II. 노코드의 구성도 및 구성요소

가. 노코드의 구성도

[요구정의]→[UI빌더(드래그앤드롭)]→[템플릿/컴포넌트 조립]
      ↓
[워크플로우 엔진]→[데이터 연동(DB/API)]→[배포·호스팅]
      ↑______________피드백 루프______________|

• 요구정의부터 배포까지 시각적 조립 흐름

나. 노코드의 구성요소

구분	구성요소	설명
개발환경	UI 빌더	화면 시각적 구성 도구
개발환경	템플릿 라이브러리	사전제작 컴포넌트 제공
로직처리	워크플로우 엔진	비즈니스 로직 시각화 처리
로직처리	트리거/액션	이벤트 기반 자동화
연동	API 커넥터	외부 서비스 데이터 연동
연동	데이터베이스 연결	내장/외부 DB 매핑

• 개발환경·로직처리·연동 3범주 구성

III. 노코드 추가정보

구분	내용	비고
비교	로우코드는 일부 코딩 허용	노코드는 코딩 배제
한계	복잡 로직·대규모 확장성 제약	벤더 종속 위험
시사점	시민개발자 확산, IT 병목 완화	시민개발 트렌드

• 로우코드와 구분, 시민개발 확산 시사점