본문으로 건너뛰기

기술사 - 소프트웨어 공학

· 약 7분

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운영 간의 상호의존 관계를 개선하기 위해 등장, 소프트웨어 제품 및 서비스를 빠르게 생산하려는 조직을 돕는 것이 목적.

참조