본문으로 건너뛰기

기술사 - 소프트웨어 공학

· 약 11분
Eunkwang Shin
Eunkwang Shin
Owner

SW 공학 개요​

SW 개념​

SW 위기​

SW 공학​

SDLC​

  • Software Development Life Cycle.

폭포수모델​

프로토타이핑​

나선형모델​

반복점증모델​

반복적 개발 모델​

  • Iteration Model.

점증적 개발 모델​

  • Incremental Development Model.

진화모델​

  • Evolutionary Development Model.

클린룸공학​

  • Clean Room Process Model.

개발 방법론​

구조적기법​

정보공학​

객체지향​

컴포넌트기반​

  • CBD: Component Based Development

모델기반​

MDA​

  • Model Driven Architenture.

서비스기반​

SOA​

데이터, 애플리케이션을 비즈니스 관점에서 표준 블록단위로 나눠 하나의 서비스로 구성한 뒤 웹 서비스 기술 등을 적용 각 서비스를 조합 또는 재사용함으로써 운영체계와 프로그래밍 언어 등에 무관하게 IT자우너을 통합 관리하는 아키텍쳐/모델링/설계패턴

  • Service Oriented Architecture.
  • 실패요인
    • 조직 변화 수용의 실패
    • ESB의 부하 중앙 집중 문제

MSA​

하나의 어플리케이션을 여러 개의 서비스로 나누어 이 서비스들을 조합하여 본래의 서비스를 제공하는 것 업무 로직을 마이크로 서비스화 하고, 데이터 저장소를 서비스 단위로 분리하여 배치하고, 업무 단위의 독립성을 확보하여 개별적으로 업데이트하고 배포하고 스케일아웃 가능.

  • Micro Service Architecture.
  • Saga 패턴
    • DB분산 트랜잭션 처리 기법인 2PC가 장애유발 위험이 커서 서비서별로 분리된 DB의 트랜잭션 처리방안이 별도로 필요
    • Saga Execution Coordinator가 로컬 트랜잭션을 관리해주는 방식
    • 하나의 로컬 트랜잭션 단위로 실행, 트랜잭션이 종료될 때 완료 이벤트를 수신하고 순차적으로 다음 로컬 트랜잭션을 실행
    • 중앙 SEC노드가 다음에 실행할 로컬 트랜잭션을 결정
    • 실패 발생시 원래 트랜잭션에 대한 로그를 남기고, 취소상태를 설정한 후 보상 트랜잭션을 실행, 실패시 일정횟수/일정기간동안 반복적으로 재시도.
    • 각 MSA는 자신의 Local Atomic Transation에만 집중하기 때문에 Pending 상태없음. 따라서 Long-Lived 트랜잭션에 적합.
  • Enterprise Gateway: API G/W
    • 다양한 API호출에 대한 첫 번째 관문 역할
    • 전사 차원의 관리가 필요한 보안(IAM) 및 트래픽 관리
  • Micro Gateway: 경량 API G/W
    • 사용자/타 시스템 API 호출에 대한 종단 관문 역할 수행
  • Service Mesh: 서비스망
    • MSA간 직접 통신하지 않고, 애플리케이션 네트워크를 기능을 제공하는 서비스 메쉬를 통해 수행.
    • MSA의 트래픽 문제 해결 대안
    • 사이드카 패턴
      • 모든 응용 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포, 서비스의 모든 네트워크 트래픽을 처리.
      • 서비스가 타 서비스를 직접 호출하는 것이 아닌 프록시를 통해 호출하므로 로깅, 모니터링, 보안, 트래픽 제어 가능.

Agile 방법론​

  • ASD: Agile Software Development.

XP​

  • eXtreme Programming

TDD​

  • Test Driven Development
  • Need --> Test --> Refactoring --> Code
  • Process
    • 단위테스트 형식으로 스펙 작성
    • 실패하는 테스트를 작성하고 확인
    • 스펙을 만족하는 코드를 작성
    • 테스트 확인
    • 코드와 테스트코드 리팩토링
    • 반복

Scrum​

  • Role
    • Product Owner
    • Scrum Master
    • Scrum Team
  • Process
    • Product Backlog
    • Sprint Backlog
    • Burndown chart
      • 개발 완료까지 남은 작업량을 보여주는 그래프
      • 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸 것
  • Meeting
    • Sprint Planning
    • Daily Scrum
    • Sprint Review
  • 특징
    • Transparency
    • Time boxing: 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야함, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행.
    • Communication: 플래닝포커, 각 사용자 스토리의 구현 난이도/시간을 토론, 협의하는 절차
    • Inspect & Adapt model: 경험주의 모델, 개개인의 경험에 기반하므로 프로젝트마다 고유한 상황과 특징을 갖고 있음, 팀마다 달라지는 걸 허용함.

LEAN​

  • 도요타에서 시작, 파레토 법칙으로 정말 중요한 20%에 집중
  • 원칙
    • 낭비 제거하라
    • 품질 내재화하라
    • 지식 창출하라
    • 확정을 늦춰라
    • 전체를 최적화하라
    • 사람을 존중하라
    • 빨리 인도하라

DevOps​

개발자와 비 개발자 사이의 대화와 협동, 통합을 강조하고 담당업무와 직급의 장벽을 허물고 상호 이해를 추구 소프트웨어 개발과 IT운영 간의 상호의존 관계를 개선하기 위해 등장, 소프트웨어 제품 및 서비스를 빠르게 생산하려는 조직을 돕는 것이 목적.

SW 공학 응용​

SW 표준​

  • 공식 표준
    • ISO 12207
    • ISO 15504
    • ISO 20000
    • ISO 9126
    • ISO 14143
    • IEEE 1471
  • 사실 표준
    • CMMI
    • PMBOK
    • ITIL

ISO 15504​

  • SPICE: Software Process Improvement and Capability dEtermination
  • 소프트웨어 프로세스를 평가하고 개선함으로써 품질 및 생산성을 높이기 위해 제정한 국제 표준
  • 소프트웨어 프로세스와 능력 레벨에 대한 참조 모델을 제시
  • 실제로 소프트웨어 프로세스를 평가기 위한 짖침과 심사원 자격 등에 관한 사항 명시
  • ISO 12207(소프트웨어 라이프사이클 표준)을 준거하여 소프트웨어 프로세스 영역을 세 영역으로 구분
    • 주요 프로세스, Primary Process
    • 지원 프로세스, Supporting process
    • 조직 프로세스, Organizational process
  • 이 프로세스를 정립하여 수행하고 있는 수준에 따라 소프트웨어 개발 조직의 능력을 6단계로 구분
    • 미완성, Incomplete
    • 실행, Performed
    • 관리, Managed
    • 확립, Established
    • 예측, Predictable
    • 최적화, Optimizing

구성도​

구성도

상세 프로세스​

  • Primary Life Cycle Processes
    • CUS.1 획득
      • CUS.1.1 획득 준비
      • CUS.1.2 공급자 선정
      • CUS.1.3 공급자 감시
      • CUS.1.4 고객 수락
    • CUS.2 공급
    • CUS.3. 요구사항 도출
    • CUS.4. 운영: ITIL
      • CUS.4.1 운영적 사용
      • CUS.4.2 고객 지원
    • ENG.1 개발
      • ENG.1.1 시스템 요구분석 및 설계
      • ENG.1.2 소프트웨어 요구분석
      • ENG.1.3 소프트웨어 설계
      • ENG.1.4 SW 구축
      • ENG.1.5 SW 통합
      • ENG.1.6 SW 시험
      • ENG.1.7 시스템 통합 및 시험
    • ENG.2 시스템과 소프트웨어 유지보수
  • Supporting Life Cycle Processes
    • SUP.1 문서화: 이해관계자들의 관점을 공식화
    • SUP.2 형상관리
    • SUP.3 품질보증
    • SUP.4 검증
    • SUP.5 확인
    • SUP.6 합동 검토: 피어리뷰
    • SUP.7 감사: 제 3자 절차 감사
    • SUP.8 문제해결
  • Organizational Life Cycle Processes
    • MAN.1 관리
    • MAN.2 프로젝트 관리
    • MAN.3 품질 관리
    • MAN.4 위험 관리
    • ORG.1 조직 정비
    • ORG.2 개선
      • ORG.2.1 프로세스 설정
      • ORG.2.2 프로세스 심사
      • ORG.2.3 프로세스 개선
    • ORG.3 인적자원 관리
    • ORG.4 기반구조: 인프라, 개발환경
    • ORG.5 측정
    • ORG.6 재사용

ISO 9126​

ISO 12119​

ISO 14598​

ISO 25000​

ISO 29119​

ISO 26262​

ISO 61508​

ISO 14143​

IEEE 1471​

PSP/TSP​

SDLC​

4세대 모델​

RAD모델​

컴포넌트 어셈블리 모델​

유지보수/재개발​

SW사업 대가산정 가이드​

SW 직접 구매​

  • 구, 분리발주

SW 단계별 발주​

  • 구, 분할발주

GS 인증​

  • Good Software

SP 인증​

  • 프로세스 품질 인증, Software Process

SW 안전​

요구공학​

형상관리​

테스트공학​

도메인공학​

프로덕트라인공학​

SW설계​

SW아키텍처​

UML​

디자인패턴​

참조​