본문으로 건너뛰기

"pe/software-engineering" 태그로 연결된 55개 게시물개의 게시물이 있습니다.

기술사 소프트웨어공학 토픽

모든 태그 보기

ISO 12207

· 약 5분

ISO 12207 개요

ISO 12207 개념

  • 소프트웨어 생명주기 프로세스를 위한 국제표준으로, SW개발 및 유지보수를 관리하는 구조화된 프레임워크 제공

ISO 12207 필요성

  • 조직이 SW를 효율적으로 개발하고 품질 표준을 충족하도록 하여 리스크를 줄이고 프로세스를 개선하는데에 필요

ISO 12207 구성도, 구성요소, 적용방안

ISO 12207 구성도

ISO 12207 구성요소

구분내용비고
기본 생명주기SW 개발의 주요 단계를 나타냄획득, 공급, 개발, 운영, 유지보수
지원 생명주기기본 생명주기를 지원하는 활동문서화, 구성 관리, 품질 관리, 문제 해결
조직 생명주기조직의 성숙도 및 역량 강화를 위한 활동관리, 기반 구조, 개선, 교육 훈련

ISO 12207 적용방안

구분내용비고
리더전략 수립 및 지원도입 필요성 공유, 예산 확보 및 지원, 결과 검토, 지속적 지원
매니저프로세스 구축 및 실행표준 프로세스 조정, 상세 절차 수립, 결과 분석 및 개선
오퍼레이터실무 적용 및 개선표준 프로세스 준수 및 실무 적용, 교육 참여, 개선 제안

ISO 12207 고려사항

  • 조직 내 새로운 프로세스 도입에 대한 구성원들의 저항을 최소화하고, 적극적인 참여를 유도하기 위한 변화 관리 전략 필요

소프트웨어 공학의 모든 것

· 약 19분

특징

  • 복잡성: Complexity
  • 순응성: Conformity
  • 변경성: Changeability
  • 비가시성: Invisibility

종류

  • 주문형: 고객, 기업의 요구사항 만족
  • 패키지형
  • 임베디드형

위기

  • 요구 증가, 복잡도 증가, 난이도 증가

목표

  • 최소 비용
  • 최고 효율

단계

  • 요구 분석
  • 설계
  • 개발
  • 테스트
  • 유지보수

품질 보증

ISO 25010, 기신사효유이호보

  • 기능적절성: Functional suitability
  • 신뢰성: Reliability
  • 사용성: Usability
  • 효율성: Performance efficiency
  • 유지보수성: Usability
  • 이식성: Portability
  • 호환성: Compatibility
  • 보안성: Maintainability

프로젝트 관리

  • 계획
  • 자원 관리
  • 리스크 관리
  • 프로젝트 수행 및 모니터링

연구 결과

  • 방법: Method
  • 도구: Tool
  • 프로세스: Process
  • 패러다임: Paradigm

연관 분야

ISO 24773, SWEBOK

구분내용비고
소프트웨어 공학 전문가 기량소프트웨어 엔지니어링의 전문적 실천에 필요한 지식과 기술윤리, 커뮤니케이션, 팀워크 등 포함
소프트웨어 공학 경제학소프트웨어 공학 프로젝트의 비용과 가치를 평가하는 지식과 기술경제적 분석 기법, ROI, TCO 포함
컴퓨팅 기반소프트웨어 엔지니어링의 기초가 되는 컴퓨팅 이론과 기술데이터베이스, 네트워크, 운영체제 등 포함
수학적 기반소프트웨어 엔지니어링 문제 해결에 필요한 수학적 이론과 기법통계, 확률, 이산 수학, 계산 이론 등 포함
공학적 기반일반 공학 원리를 소프트웨어 개발에 적용하는 지식과 기술시스템 공학, 품질 관리, 성능 최적화 등 포함

vs 컴퓨터 과학

소프트웨어 프로세스

좋은 프로세스

  • 예측 가능성: Predictability
  • 테스팅과 유지보수 용이성: Testability, Maintainability
  • 변경 용이성: Changeability
  • 결함 제거 용이성: Fault Tolerance

프로세스 모델

폭포수모델

V모델

프로토타이핑 모델

나선형모델

  • 프로토타입핑 반복

진화적 모델

  • 점증적: incremental
  • 반복적: iterative

Unified Process

  • 여러 사이클: iteration
  • 도입(inception) -> 정련(elaboration) -> 구축(construction) -> 전환(transition) 반복

애자일 프로세스

  • 2~6주간의 짧은 주기
  • 익스트림 프로그래밍: XP, 사용자 스토리, 매일 빌드/통합, TDD, 페어프로그래밍
  • 스크럼: 프로덕트 백로그 -> 스프린트 백로그 -> 2-4주기 개발, 스크럼미팅 -> 배포 가능 프로덕트 추가

지원 프로세스

ISO 12207, SDLC

  • 계약: 획득, 공급 프로세스
  • 운영: 운영 프로세스
  • 지원: 문서화, 형상관리, 품질 보증, 문제 해결 프로세스
  • 관리: 관리, 개선 프로세스
  • 엔지니어링: 개발, 유지보수 프로세스

관리 프로세스

  • 계획
  • 모니터링
  • 제어, 분석

품질보증 프로세스

  • 인스펙션 프로세스: 전문 인력, 고비용, 해결방법보다 이슈집중
  • 프로세스 관리 프로세스: CMMI

형상 관리 프로세스

  • 원시코드, 목적코드, 스크리븥, 관련 문서 전체 형상 관리

구조적 방법론

  • 분할정복
  • DFD: 배경도

정보공학 방법론

구분내용비고
ISP기업의 장기적 전략 계획 수립전략 계획서
BAA비지니스 영역별 데이터와 프로세스 모델링, 연관성 분석요구사항 명세서
BSD데이터와 프로세스 설계논리 ERD, 프로세스 구조도, 흐름도
SC데이터 상세 설계, 코딩물리 ERD, UI, 코드
  • 기업중심
  • 전략적 시스템 계획중심
  • 데이터 중심
  • 분할 정복
  • 공학적 접근
  • 사용자의 적극 참여

객체지향 방법론

  • 실세계를 객체로보고 객체사이 인터랙션을 모델링하는 방법
  • 대규모 시스템을 클래스로 모듈화하고 캡슐화
  • OMT: Object Modeling Technique, Booch, Usecase -> UML: Unified Modeling Language, UP: Unified Process

프로젝트 계획

  • 목표설정
  • 프로젝트 범위 설정
  • WBS작성
  • 작업별 소요시간 및 노력 예측
  • 작업 의존관계 정의
  • 자원 할당
  • 마일스톤 설정
  • 일정 개발

CPM 네트워크

  • Critical Path Method
  • Critical Path: 가장 오래 걸리는 경로

비용 예측 기법

  • 전문가 판단
  • PERT: Program Evaluation and Review Technique, 낙관적, 보통, 비관적
  • 알고리즘식 방법: 코코모, FB

COCOMO

  • Constructive Cost Model
  • LOC등 단계에 따라 값 예측하고 노력 추정
구분1단계2단계3단계
단계프로토타이핑초기설계설계이후
크기application pointsFP, 언어 종류FP와 LOC
요구변경비용모델에 포함변경 비율 반영변경 비율 반영
프로덕트 비용없음복잡도, 재사용요구도신뢰도, DB규모, 문서화요구정도, 재사용 요구도, 복잡도
플랫폼 비용없음플랫폼 난이도실생시간, 기억공간 제약
인력 비용없음개인능력, 경험분석능력, 응용경험, 프로그래머 능력/경험, 언어/도구 경험
프로젝트 비용없음개발기간, 개발환경 요구SW도구 사용, 개발 기간, 여러 사이트 개발 요구

기능점수

  • Function Point
  • 입력(트랜잭션), 출력(화면 및 출력양식), 질의, 파일, 응용 인터페이스

소프트웨어 대가 산정 가이드

  • 외부 입력: External Input, 내부 파일의 내용에 영향을 주는 사용자데이터 또는 입력을 트랜잭션 단위로 카운터 (입력, 수정, 삭제)
  • 외부 출력: External Output, 소프트웨어 외부로 표출되는 사용자 데이터 또는 제어 출력을 트랜젝션 단위로 카운트 (계싼, 통계 그래프 등)
  • 내부 논리 파일: Internal Logical File, 소프트웨어에 의해 생성, 사용, 관리되는 파일을 포함하여 시스템 내 존재하는 사용자 데이터 및 제어 정보의 그룹 카운트
  • 외부 인터페이스 파일: External Interface File, 소프트웨어 시스템 사이에 전다로디거나 공유된 파일 카운트
  • 외부 조회: External Query, 중간 출력을 생성하는 외부 조회를 카운트

프로젝트 모니터링

  • 어닝 밸류 분석: Earning Value Analysis, 비용과 일정 통합 모니터링
  • BAC: 프로젝트 예산
  • AC: 실제 비용
  • PV: 계획된 비용
  • EV: 어닝 밸류
  • PV - EV: 일정 차이
  • AC - EV: 비용 차이

리스크 관리

  • 6M: Machine, Method, Materials, Measurement, Man, Mother nature, 기계, 방법, 재료, 측정, 사람, 환경
  • 8P: Price, Promotion, People, Process, Place/Plant, Policy, Procedure, Product, 가격, 광고, 인력, 프로세스, 장소, 정책, 절차, 제품
  • SW프로젝트(Boehm): 인력부족, 비현실적 일정 및 예산, 잘못된 기능과 특징 개발, 잘못된 인터페이스 개발, 과포장, 계속적 요구변경, 외부 노출 컴포넌트 빈약, 실시건 성능 빈약, 녹슨 컴퓨터 분야 기술

요구

  • 시스템에 대한 고객의 요청을 확정한 것

기능 요구

기능, 데이터, 입출력, 사용자

  • 시스템과 외부 요소들 간의 인터렉션
  • 입력 검증
  • 정확한 작업 순서
  • 비정상적 상태에 대한 응답 및 복구
  • 매개변수 유효성
  • 입출력 관계

비기능 요구

성능, 품질, 안전, 보안, 사용성

  • 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항
  • 외부 인터페이스
  • 메모리 제약
  • 성능 요구
  • 사용자 특성과 가정
  • 설치 환경의 적합성

요구 추출

  • Requirement Elicitation
  • 요구에 대한 정보 출처 파악 > 요구에 대한 정보 취합 > 요구와 제한 사항 정리

요구 정보 출처

  • 고객
  • 도메인 전문가
  • 이해당사자
  • 사용자
  • 역공학
  • 기존 문서
  • 인터뷰
  • 설문
  • 브레인스토밍
  • 프로토타이핑

요구 품질

  • 원자성: atomic, 요구사항이 복합 목적이 아니라 단일 목적인지
  • 완전성: complete, 요구 사항 안에 정의된 것이 정보의 모든 것을 포함하는 것인지
  • 비모호성, 통일성: unambiguous, consistent, 명확하지 않거나 같은 내용을 다르게 언급하지 않는 것
  • 추적성: traceable, 요구 사항을 쉽게 추적할 수 있도록 고유번호
  • 우선순위화: prioritize: 요구 사항의 중요도를 파악하는 성질
  • 테스트 가능성: testable, 요구 사항이 검증 가능하도록 기술되어있는 특성

유스케이스

  • 찾아낸 각 액터에 대해 시스템과 관련된 작업은 무엇인가?
  • 시스템에서 발생하는 특정 사건에 대해 액터에게 알려야 하는가?
  • 액터가 갑작스런 외부 변화에 대해 시스템에 알려야 할 것인가?
  • 시스템이 비지니스에 정확한 동작을 제공하나?
  • 찾아낸 유스케이스로 모든 기능을 수행할 수 있는가?
  • 어떤 유스케이스가 시스템을 지원하고 유지보수하나?
  • 시스템에서 어떤 정보를 수정하거나 만들어야하나?

요구분석 명세서

  • SRS: Software Requirement Specification
  • 소개
    • 목적
    • 제품 범위
    • 정의, 동의어, 약어
    • 참조문서
    • 개요
  • 일반적인 기술사항
    • 제품의 개관
    • 제품의 기능
    • 사용자 특성
    • 제약사항
    • 가정 및 의존성
  • 상세한 요구사항
    • 외부 인터페이스
    • 기능요구
    • 성능요구
    • 논리 데이터베이스 요구
    • 설계 제약사항
    • 소프트웨어 시스템 속성
    • 상세요구 사향의 구성
  • 부록
  • 색인

요구 검증

  • 이해용이성: comprehensibility, 요구 명세서를 읽을 떄 요구의 의미를 잘 이해할 수 있는가?
  • 중복: redundancy, 필요없이 중복된 부분이 없는가?
  • 완전성: completeness, 빠진 요구가 없는지, 요구 기술시 빠진 정보가 없는가?
  • 일관성: consistency, 요구사항이 모순되지 않는가?
  • 모호성: ambiguity, 요구분석 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
  • 검증가능성: verifiable, 요구분석 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지 검증할 수 있는가?
  • 추적가능성: traceable, 시스템 요구사항과 시스템 설계문서 및 구현과 매핑되어 추적할 수 있는가?

요구 모델링

  • 도메인지식을 체계화하는 과정
  • 도메인지식: 업무 프로세스, 기능, 역할, 업무 규칙
  • 기능적 모델링: 유스케이스 다이어그램, 액티비티 다이어그램
  • 정적 모델링: 클래스 다이어그램, ERD
  • 동적 모델링: 시퀀스 다이어그램, 협동 다이어그램
  • 제어 모델링: 액티비티 다이어그램

UML

  • 구조다이어그램: 클래스, 객체, 컴포넌트, 배치, 패키지, 컴포지트 구조
  • 동작 다이어그램: 유스케이스, 액티비티, 상태
  • 인터랙션 다이어그램: 시퀀스, 커뮤니케이션, 인터랙션 오버뷰, 타이밍

아키텍처 평가 모델

SAAM

  • Software Architecture Analysis Method
  • 이해관계자 품질 민감 시나리오 도출, 시나리오 우선순위, 시나리오 기반 아키텍처 평가

ATAM

  • Architecture Trade-off Analysis Method
  • 업무 배경 및 요구사항으로 품질 속성 도출, 시나리오 기반 아키텍처 절충점, 리스크 분석, 아키텍처 반영 및 평가
    • 품질속성: 유지보수성, 성능, 가용성, 보안성, 사용용이성

UI

  • 관련 분야
    • HCI 인간 컴퓨터 상호작용
    • 인터렉션 디자인, 사용자 중심 디자인, 상황별 디자인, 참여 디자인, 목표지향 디자인
    • 사용자 경험
    • 인간 공학
  • 사용성 (효과적 -> 쉬움 -> 즐거움)
    • 학습용이성
    • 효율성
    • 기억용이성
    • 낮은 오류율

참조

MAS, 상용SW 다수 공급자 계약 제도

· 약 4분

MAS 개념

  • 공공기관이 다양한 수요 충족을 위해 2인 이상(다수)을 대상으로 단가 계약을 체결하는 제도
  • 조달제품 다양화수요기관의 선택권 확대

MAS의 특징

  • 여러 공급자와 계약을 체결하여 수요기관의 선택 폭을 확대
  • 기업에게 정부조달시장 참여 기회 제공
  • 업체 간 경쟁의 확대

MAS 의 평가 절차, 항목, 2단계 경쟁

MAS의 평가 절차

  • 조달사업법 제13조 기반하여 계약 진행

MAS의 절차 세부 항목

구분내용비고
구매입찰공고나라장터 입찰공고규격확정, 상용화, 경쟁성 확보
적격성평가가격 기초자료 제출결격사유 확인, 협상품목대상 규격서 제출
가격협상적격자와 가격 협상실거래가의 가중평균, 최빈가격 기반 작성
계약체결나라장터 전자계약기본계약 3년
  • 5천만원 이상의 경우, 2단계 경쟁으로 투명성, 경쟁성 강화

MAS 2단계 경쟁 제도

구분내용비고
대상1회 구매애정 금액 5천만원 이상중소기업제품은 1억 이상
기본평가항목SW특성 반영한 기본 평가항목가격, 기능성, 사용성
선택평가항목유지보수 상품 등록, 국산SW 우대 등 반영유지관리성, 혁신 우수성
예외사항본상품 구매에 따른 제외 범위유지관리, 계속계약, 증설 등

제3자 단가계약과 MAS차이점

구분제3자단가계약다수공급자계약
계약방법수의경쟁
계약수량업체계약수량업체계약수량
계약자단일업체다수업체
가격자료동일품목 3건 이상 구매실적규격별 최근 1년간 전자세금계산서, 유사 거래 실적
2단계 경쟁없음1회 구매예정 일정금액 이상
납품업체 선정수요기관 지정일정금액 미만 수요기관 지정, 일정금액 이상 2단계 경쟁 통한 평가

참조

ISO 25000

· 약 2분

ISO 25000의 개요

  • SQuaRE: Software Product Quality Requirements and Evaluation
  • SW 품질 평가 모델 ISO 9126과 SW 품질 평가 절차 모델 ISO 14598을 통합한 품질 평가 모델
  • 기존 SW 품질 평가 표준 모델의 모호성 개선 및 통합 품질 요구 명세부터 품질 판정까지 표준 지침 제공

ISO 25000 구성도 및 구성요소

ISO 25000 구성도

ISO 9126 품질특성 + ISO 14598 품질평가 절차

                        +----------------+
| 품질모델 (25010) |
+----------------+
|
+----------------+ +-------------+ +----------------+
| 품질평가 (25040) |-------| 품질관리 |-------| 품질측정 (25020) |
+----------------+ +-------------+ +----------------+
|
+----------------+
| 품질요구 (25030) |
+----------------+

ISO 25000 구성요소

구분설명표준
품질관리SQuaRE에 대한 개요, 전체 관리ISO 25000
품질모델품질 모델 및 품질 사용 안내ISO 25010
품질측정기본, 내/외부 품질 매트릭스 문서화ISO 25020
품질요구품질 요구사항 명세ISO 25030
품질평가평가자 관점의 평가 프로세스ISO 25040
  • 기능적합성, 신뢰성, 사용성, 실행효율성, 유지보수성, 이식성, 호환성, 보안성 품질 제고

ISO 25000 활용 및 기대효과

  • SW 품질 평가의 편리성, 신뢰성, 명확성 제공
  • SW 품질 향상 및 경쟁력 확보 지표 제시
  • ISO 9126과 ISO 14598 표준 간 갭을 제거하여 품질 평가의 일관성 확보

리먼(Lehman)의 소프트웨어 진화 법칙

· 약 4분

소프트웨어 진화 법칙 개요

소프트웨어 진화 법칙 개념

  • 대부분의 소프트웨어가 존재하는 동안 변경이 일반적이며, 지속적으로 유지되기 위해 준수해야하는 법칙
  • 품질관리와 변경관리의 중요성 강조, 유지보수 비용증가에 따른 관리전략 수립을 위해 필요

소프트웨어 진화 법칙 필요성

  • SW 변화의 특성을 이해하여 유지보수, 변경관리, 형산관리, 품질 통제의 중요 모델로 반영할 수 있으므로 효과적인 유지보수 및 변화관리 가능.

소프트웨어 진화 법칙 개념도, 핵심요소, 적용방안

소프트웨어 진화 법칙 개념도

소프트웨어 진화 법칙 핵심요소

구분법칙내용
완전유지관리조직적 안전성평균 유효한 글로벌 작업률은 제품 수명 기간동안 변하지 않음
지속적인 성장사용자를 만족시키기 위해 기능적 성장 필요
적응유지관리지속적인 변화SW는 지속적으로 적응하고 변화해야함
자기 규제시스템 진화는 제품의 배포와 프로세스 측정으로 자체 조절됨
피드백 시스템진화 프로세스는 다중 레벨, 다중 에이전프 피드백 시스템이여야함
수리유지관리품질 저하변경이 엄격하게 유지 관리되고 적응하지 않으면 품질 감소
예방유지관리증가하는 복잡성시스템이 발전할 때 관리하지 않으면 복잡성 증가
친숙도 보존사용자는 만족스러운 진화가 될 수 있게 내용과 행동을 숙달해야함
  • SW 변화 특성을 이해하고, 유지보수, 변경관리, 형상관리, 품질 통제의 중요 모델로 반영

소프트웨어 진화 법칙 적용방안

구분방안비고
요구사용자 요구 지속적 수집, 분석요구관리 툴
설계모듈화된 설계를 통한 변경 용이성컴포넌트화
구현변경관리 프로세스 통한 코드 관리VCS 활용
테스트자동화된 테스트 통한 품질 검증Continuous Test
배포점진적 배포를 통한 안정적 대응블루-그린 배포
유지보수지속적 모니터링과 피드백 수집, 개선CMS
폐기SW 수명 종료시 폐기 절차 수행데이터 마이그레이션

소프트웨어 진화법칙 추가적인 고려사항

  • 신기술 도입과 기존 기술의 진화를 지속적으로 모니터링하여 SW 기술 부채를 최소화하는 활동 필요

화이트박스, 블랙박스 테스트

· 약 4분

화이트박스, 블랙박스 테스트 개요

화이트박스, 블랙박스 테스트 개념

화이트박스, 블랙박스 테스트 배경

  • 테스트 V모델에서 요구사항/분석/설계/코딩 측면은 개발자 관점의 화이트박스 테스트로 Verification 하고,
  • 단위/통합/시스템/사용자 테스트 측면은 사용자 관점의 블랙박스 테스트로 Validation 하게 설계 필요.

화이트박스, 블랙박스 테스트 개념도, 핵심요소, 적용방안

화이트박스, 블랙박스 테스트 개념도

  • 내부구조를 파악하는지 여부에 따라 기법 변경

화이트박스, 블랙박스 테스트 핵심요소

구분화이트박스블랙박스
테스트기반소스코드, 제어흐름그래프요구사항명세서, 유스케이스
테스트설계문장커버리지, 결정커버리지, 조건커버리지, 경로커버리지동등분할, 경계값 분석, 오류추정, 원인/결과 분석
테스트목표코드의 정확성, 안정성, 완전성 검증기능요구사항 충족여부, UX 및 시스템 동작 검증
테스트시점개발 초기 단계개발 후반 단계
테스트자동화JUnit, Jest 등 단위테스트 프레임워크Selenium, Playwright 등 UI테스트 프레임워크
장점숨겨진 결함 발견 용이, 테스트 커버리지 향상사용자 관점 검증, 비교적 쉬운 TC 설계
단점높은 비용, 시간 소모, 코드 변경시 TC 수정 필요숨겨진 결합 발견 어려움, 낮은 TC 커버리지

화이트박스, 블랙박스 테스트 적용방안

구분화이트박스블랙박스
단위테스트각 함수, 모듈 기능 검증없음
통합테스트모듈간 인터페이스 상호작용 검증여러 모듈 통합 후 기능 검증
시스템테스트없음전체 시스템 기능, 성능 검증

테스트시 고려사항

  • 화이트박스와 블랙박스 테스트의 장점을 결합하여 제한적 내부 정보를 활용한 그레이박스 테스트 기법 고려

모듈화, 응집도, 결합도

· 약 4분

모듈화

모듈화의 개념

  • 시스템을 분해하고 추상화하여 SW 성능을 향상시키거나, 시스템의 디버깅, 테스트, 통합 및 수정을 용이하도록 하는 SW 설계 기법

모듈화의 장점

  • 모듈 재사용성, 개발과 유지보수성
  • 복잡성 감소
  • 오류 파급효과 최소화
  • 기능 분리가능, 인터페이스 단순화
  • 낮은 결합도, 높은 응집도

응집도와 결합도 개요

응집도와 결합도의 개념

  • 응집도: 하나의 모듈 내부의 처리요소 간 기능적 연관성을 측정하는 척도
  • 결합도: 모듈 간관련성을 측정하는 척도

응집도와 결합도의 배경

  • 최근 MSA 적용에 따른 모듈화의 중요성이 증가되었고, MSA의 각 서비스 단위(컴포넌트)는 응집도가 높고 결합도가 낮게 구현되어야함.

응집도와 결합도 종류 및 설명

응집도의 종류 및 설명

우논시절통순기

종류설명응집도
능적모든 요소가 단일 기능 수행높음
차적한 기능의 출력이 다른 기능의 입력으로 사용
신적동일한 입출력 데이터로 다른 기능 수행
차적기능 요소가 반드시 특정 순서대로 실행
기능 요소가 모두 같은 시간에 실행
리적논리적으로 유사하나 관계가 밀접하지 않음
연적모듈 내 요소가 연관이 없음낮음
  • 가능한 높은 응집도를 추구하여 유지보수 용이성 확보
  • 모듈 간 결합도는 최소화하여 각 모듈은 높은 응집도 확보
  • Co-incidental -> Logical -> Temporal -> Procedural -> Communicational -> Sequential -> Functional

결합도의 종류 및 설명

내공외제스자

종류설명결합도
모듈 간 파라미터 전달낮음
탬프모듈 간 자료구조 전달
다른 모듈을 제어하기 위해 플래그 전송
모듈이 SW외부 환경과 연관
모듈들이 공통 데이터 참조
다른 모듈의 내부 데이터 변경높음
  • 모듈 상호간 낮은 결합도 추구
  • 모듈 간 사이드 이펙트(리플 이펙트) 최소화
  • Contents -> Common -> External -> Control -> Stamp -> Data

응집도, 결합도 적용방안

구분내용비고
설계시스템 모듈화, API통신유지보수 용이성
개발모듈간 인터페이스 단순화, 명확한 역할 분담의존성 주입

모듈성을 높이기 위한 고려사항

  • 코드리뷰를 통해 개발단계에서의 의존성 문제, 인터페이스 불일치 등 저해요인 방지
  • MSA 설계시 서비스 단위로 높은 응집도, 낮은 결합도를 갖게 설계

몽키테스트, 회귀테스트

· 약 3분

몽키테스트, 회귀테스트 개요

몽키테스트와 회귀테스트 개념

몽키테스트와 회귀테스트 배경

  • 애자일 개발 방법론 도입으로 소프트웨어의 잦은 변경으로 인하여 자동화되고 연속적인 테스트의 필요성 증가
  • 기존 테스트를 지속하면 살충제 패러독스가 발생하므로, 새로운 버그 발견을 위해 몽키테스트 실행

몽키테스트와 회귀테스트 개념도, 구성요소

몽키테스트와 회귀테스트의 개념도

  • 테스트케이스나 시나리오 없이 예측할 수 없는 방식으로 무작위 테스트
  • 코드, 기능 변경 후 기존 기능이 정상적으로 동작하는지 테스트

몽키테스트와 회귀테스트 구성요소

구분몽키테스트회귀테스트
목적예기치 못한 버그 발견기존 기능 동작 확인
방식무작위 입력, 스트레스, 랜덤 클릭기존 테스트케이스 재실행
시기주로 시스템테스트 단계통합, 시스템, 인수테스트 변경시
완료오류 미검출사이드이펙트 수정 완료
장점예상치 못한 행동 시뮬레이션SW안정성 유지
단점재현 어려움, 비일관성살충제 패러독스

통합테스트 계획시 포함할 주요사항

  • 시스템 목적, 범위
  • 대상시스템 구조
  • 테스트 자원, 일정
  • 시작 및 종료 조건
  • 테스트 시나리오
  • 테스트 방법 및 절차 교육

데이터옵스, 데브옵스

· 약 3분

데이터옵스, 데브옵스 개념

  • 데이터옵스: 데이터 분석/관리 프로세스DevOps 원칙을 적용하여 분석 처리의 효율성을 높이는 방법론
  • 데브옵스: 개발과 운영을 통합하여 SW개발주기를 단축하고 품질을 향상시키는 방법론
  • 데이터 요구사항, 비지니스 요구사항실시간으로 대응하기 위해 필요성 대두

데이터옵스, 데브옵스 개념도, 구성요소, 적용방안

데이터옵스, 데브옵스 개념도

데이터옵스, 데브옵스의 구성요소

구분데이터옵스데브옵스
목표데이터 파이프라인 자동화개발, 배포, 운영 자동화
프로세스데이터 수집, 저장, 처리, 분석, 시각화, 품질관리계획, 개발, 빌드, 테스트, 배포, 운영, 모니터링
조직데이터엔지니어, 데이터과학자, 데이터분석가, DBA개발자, QA엔지니어, 보안엔지니어, 시스템엔지니어
도구Apache Airflow, SparkJenkins, GitLab
협업기업 전체 데이터 관련 부서IT부서
기대효과스토리지, 워크플로우, 데이터파이프라인 최적화짧은 개발주기, 지속적 통합, 배포

데이터옵스의 추가적인 고려사항

  • AI를 활용하는 MLOps로까지 확장하여, 데이터 기반의 의사결정을 더 빠르게 가져갈 수 있음.

소프트웨어 안정성 분석

· 약 4분

소프트웨어 안정성 분석 개요

  • 각 개발 수명주기에서 안전 보증, 확인 활동 수행
  • SW시스템의 오류, 장애, 실패를 예방하고, 위험을 회피, 전가, 감수, 수용하기 위해 시스템 위험요소를 식별하고 평가하는 과정.
  • IoT와 안전필수시스템(자율주행, UAM 등)의 기능적 사고로 인한 인명피해방지를 위해 필요

소프트웨어 안정성 분석 주요 기법

FTA, Fault Tree Analysis

  • 시스템 주요 실패 이벤트를 트리구조롤 분석하여 원인 규명
  • Top-Down 방식
  • 분석범위의 정의 및 분석수준의 결정 -> 대상제품의 특성 파악 -> 정상사상 정의 -> 결함수의 구성 -> 결함트리의 정성적 분석 -> 결함트리의 정량적 분석 -> 분석결과의 평가 및 보고

FMEA, Failure Mode and Effects Analysis

  • 분석 과제 정의 및 분석 준비 -> 분석 실시 -> 분석 결과의 정리 및 심층 분석

HAZOP, Hazard and Operability study

  • 목적 및 분석범위 설정 -> 분석팀 구성 -> 예비조사 -> 브레인스토밍 -> 분석결과 기록

소프트웨어 안정성 분석시 고려사항

  • ISO 26262 등 해당 산업의 규제 및 표준을 준수하여 분석 수행