소프트웨어 프로세스 모델

다루는 주제

• 소프트웨어 프로세스 모델

  • 폭포수 모델 (Waterfall)
  • 진화적 모델 (Evolutionary: 프로토타이핑, 증분)
  • 애자일 모델 (XP, Scrum)
  • 변환 모델 (Transformation)
  • 나선형 모델 (Spiral)
  • V 모델 (V Model)
  • DevOps 모델

• 프로젝트 특성에 따른 SDLC (Software Development Life Cycle)

• 소프트웨어 프로세스 표준: ISO 12207

소프트웨어 개발이란 무엇인가

• 최종 목적지에 도달하는 방법은?
• 그곳에 도달하기 위해 무엇이 필요한가?
• 소프트웨어 개발은 어떻게 해야 하는가?

소프트웨어 개발 프로세스

소프트웨어 개발은 지속적이고 절차적인 활동

위 활동들은 무엇인가요? 뭔데

요구사항에서 최종 시스템까지 그림인데 이걸 말하는걸까

소프트웨어 개발을 위한 여러 경로를 어떻게 표현할 수 있나요?

• Software Process Model

소프트웨어 프로세스 모델이란

소프트웨어 생산 프로세스

• 프로세스는 소프트웨어 제품을 빌드하고, 전달하고, 배포하고, 진화시키기 위한 과정
• 아이디어의 시작부터 전달하고 시스템의 최종 폐기까지

생산 프로세스의 목표

• 고객의 기대를 충족시키는 것
  • 제시간에 예산 내로 품질 높은 제품을 제공
  • 수익을 창출하며
  • 신뢰성 있고 예측 가능하며 효율적인 생산을 통해
    • 신뢰성, 예측성, 효율성

소프트웨어 생명주기 모델 (Software Life Cycle Model)

• 요구사항 -> 분석 -> 설계 -> 코딩 -> 테스트 -> 제공 -> 운영 및 유지보수 -> 폐기

프로세스 모델이 중요한 이유는?

블랙박스 프로세스 (Black-Box Process)

• 내부 진행 상황을 담당자에게만 확인할 수 있음

• 외부에서 진행 상황을 알 수 없으며 피드백이 어려움
  투명한 프로세스 (Transparent Process)

• Visibility

• 계속해서 피드백을 받을 수 있다면, 소프트웨어가 제대로 진행되고 있는지 확인할 수 있음

• 추적표를 통해 요구사항에 맞는 결과물이 만들어졌는지 확인 가능함

• 시장 진출 시간을 단축하고 생산 비용을 절감함

• 제품의 품질에 결정적인 영향을 미침

• 프로세스를 제어함으로써 제품의 품질을 더 잘 제어할 수 있음

소프트웨어 생산 활동

• 프로세스
  • 무엇을 해야 할지에 대한 일련의 (관련된) 단계들
• 주요 활동:
  • 
    1. 타당성 검토 (Feasibility Study)
       • 경제적
         • 개발한 서비스가 수익성이 있는가
       • 기술적
         • 구현가능한가
         • 불가능하다면 아웃소싱 진행 but 회사 내 기술 유출
    • 법률적
      • 사회적 문제가 있는가
    2. 요구사항 도출, 이해, 명세화 (Eliciting, Understanding, and Specifying REQs)
    3. 소프트웨어 아키텍처와 상세 설계 (Software Architecture and Detailed Design)
    4. 코딩 및 모듈 테스트 (Coding and Module Testing)
    5. 통합 및 시스템 테스트 (Integration and System Testing)
    6. 전달, 배포 및 유지보수 (Delivery, Deployment, and Maintenance)

소프트웨어 프로세스 모델

• 소프트웨어 개발 활동을 어떻게 구성할 수 있는지에 대한 표현

대표적인 프로세스 모델

• 빌드 앤 픽스 모델 (Build-and-Fix): 코드 작성 후 클라이언트가 만족할 때까지 수정
• 폭포수 모델 (Waterfall Model): 단계별로 순차 진행
• 진화적 모델 (Evolutionary Model): 프로토타이핑 및 증분 방식
• 변환 모델 (Transformation Model): 형식 명세를 바탕으로 한 개발
• 나선형 모델 (Spiral Model): 위험 분석 중심
• 기타 모델들: 다양한 응용 가능한 모델들

Build and Fix Model(빌드 앤 픽스 모델)

• 첫 번째 버전을 작성하고, 클라이언트가 만족할 때까지 수정
• 분석 및 설계X
• 단일 개발자가 주로 수행하며, 명세가 없이 구축됨
• 적정 규모 제품에는 불만족
• 오늘날 환경에서는 부적합
  • 컴퓨터 배경이 없는 사람들을 위해 개발된 모델
  • 더 엄격한 신뢰성 요구사항
  • 그룹 활동에 적합하지 않음

Waterfall Model(폭포수 모델)

1. 타당성 검토
2. 요구사항 수집
3. 설계
4. 코딩 및 모듈 테스트
5. 통합 및 시스템 테스트
6. 제공, 배포 및 유지보수

특징

• 1970년대 Windstom Joyce
• 순차적, 단계(Phase) 기반, 문서지향
• 각 단계의 출력이 다음 단계의 입력이 됨

기여

• 계획적이고 관리 가능한 접근 방식을 강제함
• 목표가 잘 이해된 후에 제품을 구현해야 함

폭포수 모델의 문제점

• 변경사항 피드백 어려움
• 테스트 후반 집중
• 유연성 부족
• 결과물이 맞지 않을 경우 큰 비용 발생

폭포수 모델의 변형

• with feedback loop
• with incremental builds

Evolutionary Model(진화 모델)

• 운영 소프트웨어 제품의 증분을 확장하는 모델

개발 전략

1. Deliver
   • 실제 사용자에게 무언가를 제공
   • 실제 사용자에게 Deliver하고 피드백 받음
2. Measure
   • 사용자에게 추가된 가치를 측정
3. Adjust
   • 관찰된 현실을 기반으로 설계와 목표를 조정

수정가능성은 생명주기 단계에서 사라짐

• SW가 지속적으로 진화함
• 따로 유지보수 단계가 필요하지 않음

진화적 모델 2가지 유형:

• 증분 접근법 (Incremental Approach)
• 프로토타이핑 (Prototyping)

Incremental Approach(증분 접근법)

1. 첫 번째 빌드를 구현&테스트
2. 연속하는 빌드를 구현, 통합 및 테스트
3. 제품이 완성될 때까지 반복

증분 접근법 특징

• 계단식 개발
• 각 단계 ProcessModel#Waterfall Model(폭포수 모델) 규율 유지
• 일련의 미니 폭포수 모델 프로세스

이점

• 사용자가 새로운 제품에 조정할 시간을 제공
• 변경 수용이 쉬워짐
• 단계적 전달(일부 전달)로 인해 큰 자본이 필요하지 않음

문제점

• build-and-fix model과 비슷해질 수 있음음
• 각 통합과 테스트마다 오버헤드가 발생
• 부분적인 시스템이 사용자에 의해 최종 시스템으로 간주될 수 있음

(Rapid) Prototying(프로토타이핑)

1. 1번째 빌드 구현&테스트(prototype)
   • if prototype이 원하는 형태면 다음 단계 진행
2. 연속하는 빌드를 구현, 통합 및 테스트를 제품이 완성될 때까지 반복

Throw away Prototype

• 첫 번째 버전
  • 제품의 타당성을 평가
  • 요구사항을 확인
  • 위 가능성 증명 후 프로토타입 버림
• 두 번째 버전
  • 폭포수 모델을 따름

Evolutionary Prototype(진화 프로트타입)

• 프로트타입이 점점 최종 시스템으로 진화
• 프로트타입에서 이어서 작업

이점

• 비용&시간을 절감할 수 있음
• 개발자와 사용자 간의 의사소통을 향상
• 오류를 초기에 발견할 수 있음

문제점

• 변경 예상에 대해 강제하지 않음
• 결국 폭포수 모델로 진행하므로 요구사항 변경이 어려움

추가적인 프로트타입 종류

• Horizontal Prototype(수평적 프로트타입)
  • 다양한 기능의 콘셉을 예상 가능
  • 전반적인 흐름 점검
  • 서비스 전체 개발은 아님
• Vertical Prototype(수직적 프로트타입)
  • 특정한 조건에서 제대로 작동하는지 확인할 떄 사용
  • 서비스 주요 기능만 세부적인 수준으로 구현

신속한 애플리케이션 개발

소프트웨어 시스템을 신속하게 개발할 수 있는 방법

• Tools(도구)
• User involvement(사용자 참여) 어떻게 신속해지지

왜 소프트웨어를 신속하게 개발해야 하는가

• 개발시간 축소
• 시장 점유율 높이기 위함(기억의 이익)

신속한 애플리케이션 개발

• 신속한 개발과 전달(delivery)은 현재 소프트웨어 시스템의 가장 중요한 요구사항
  • 비즈니스는 빠르게 변화하는 요구사항 속에서 운영 = 안정적인 소프트웨어 요구사항 정의는 사실상 불가능
  • 소프트웨어는 변화하는 비즈니스 요구를 반영하기 위해 빠르게 진화해야 함

신속한 소프트웨어 개발에서

• 명세, 설계 및 구현이 상호 병행
• 시스템은 다양한 버전의 연속으로 개발되며, 이해관계자가 각 버전을 평가하는 과정에 참여
• 사용자 인터페이스는 IDE(통합 개발 환경)와 그래픽 도구 세트를 활용하여 개발되는 경우가 많다.

신속한 개발 ➔ 애자일 개발

애자일 방법론(Agile Methods)

• 목표

  • 더 빠르고 신뢰할 수 있는 소프트웨어를 만드는 것

• 여러 애자일 방법론:

  • 동적 시스템 개발 방법 (Dynamic System Development Method)
  • 적응형 소프트웨어 개발 (Adaptive Software Development)
  • Crystal Clear
  • XP (Extreme Programming)
  • 스크럼 (Scrum)
  • Lean 소프트웨어 개발
  • Feature-Driven Development
  • Agile Unified Process
  • 등

XP 프로세스 (Extreme Programming)

• eXtreme Programming
• 요구사항 변경을 다룸

역할과 책임

• 프로그래머
  • 분석, 설계, 테스트, 코딩, 통합
• 관리자
  • 프로젝트 프로세스의 진행 관리
• 고객
  • 요구사항과 그 우선순위 지정

XP의 4가지 가치

1. 의사소통 (Communication)
2. 단순성 (Simplicity)
3. 피드백 (Feedback)
4. 용기 (Courage)
   • 모든 생각, 의견을 공유하기 위해서서

XP의 12가지 실천사항

• 계획 수립 (Planning Process)
  • Incremental Planning
  • 각 증분에 따라 중요도가 다를 수 있음
  • 따라서 처리 설계, 계획을 잘해야 함
• 작은 릴리스 (Small Releases)
  • 작은 기능 단위로 배포
  • 피드백을 빠르게 받을 수 있음 but 너무 많은 피드백을 받을 수 있음
  • trade off for user feedback 사용자 피드백을 적당히 받아야함
  • 개발자의 융통성까지 제한 가능하기 때문에
• 메타포 (Metaphor)
  • Term Dictionnary(용어 사전)
  • 고객, 개발자 간의 의사소통 언어
• 단순한 설계 (Simple Design)
  • 최소화된 문서
  • 개발하고 배포하는데 초점을 맞춤
• 지속적인 테스트 (Continuous Testing)
• 리팩토링 (Refactoring)
  • 고유의 특징을 그대로 유지하고 인터페이스 등을 변경
  • 기능 변화없이 코드 수정
• 페어 프로그래밍 (Pair Programming)
  • 짝을 지어서 프로그래밍
• 집합된 코드 소유권 (Collective Code Ownership)
  • 자기 코드라 생각하며 자발적으로 문제해결에 나서는 정신
• 지속적 통합 (Continuous Integration)
• 주 40시간 근무 (40-hour Week)
  • Sustainable Pace(효율성 문제)
• 현장 고객(On-site customer)
  • 고객과 현장에서 만나는?
• 코딩표준(Coding standard)
  • 사람마다 코딩 스타일이 다르기 때문에
  • 국제적 code standard
    • MISRA => Motor mdustry
    • C Coding Standard

개발 사이클

Scrum(스크럼)

• 일반적인 애자일 방법론
• 기민한 실행보다는 반복적 개발의 중요성을 더 강조
• 반복적 개발을 관리하는 피드백 기반의 경험적 접근 방식
• 세 가지 기둥
  • 투명성, 검사, 적합성
• 스크럼 구조 내의 모든 작업은 결과(프로세스, 워크플로우, 진행 상황 등)에 책임이 있는 사람들에게 명확하게 보이도록 해야 함
• 이를 명확하게 보이게 하기 위해, 스크럼 팀은 개발 중인 제품과 팀의 작업 효율성을 자주 점검
• 할 필요가 있음 => 자주 만나서 피드백

스크럼의 3단계

1. 초기 단계
   • 대략적인 계획을 수립, 프로젝트의 일반적인 목표를 설정하고 소프트웨어 아키텍처를 설계
2. 스프린트 사이클
   • 여러 스프린트 사이클이 이어지며, 각 사이클은 시스템의 증분을 개발
3. 프로젝트 마무리 단계
   • 프로젝트를 정리하고 필요한 문서 작업을 완료하며, 프로젝트에서 얻은 교훈을 평가

산출물(중요)

• Product Backlog (제품 백로그)
  • 요구사항의 정렬된 목록
  • 우선순위를 갖는 요구사항 분류
• Sprint Backlog (스프린트 백로그)
  • 다음 스프린트 동안 개발 팀이 해결해야 할 작업 목록
• Product Increment (제품 증분) 또는 PSI (Potentially Shippable Increment, 잠재적으로 출시 가능한 증분)
  • 스프린트 동안 완료된 모든 Product Backlog Item의 통합
  • 이전 스프린트의 작업과 통합된 형태
• Burn-Down Chart (번다운 차트)
  • 스프린트 백로그에 남은 작업을 보여주는 공개 차트로
  • 매일 업데이트
  • 
• Burn-Up Chart (번업 차트)
  • 출시를 향한 진행 상황을 추적
  • 했던 작업 작업 보여줌

스크럼

Transformation Model(변환 모델)

• Code Auto Gerneration
• 
• 수학적 명세 기반
  • 수학적 방법론(Z, PetriNet, StateCharts 등)
• 명세를 점진적으로 구현(code)으로 변환하는 모델
• 메뉴얼대로 자동적
• 연구 기반 접근방식
• 프로그램에 대한 올바름의 증명
• 수학적으로 정해져있는 것에서 사용

문제점

• 전문가 지식이 필요함
• 제한적인 산업적 사용
  • ex) 원자력 발전소 제어 sw

Spiral Model(나선형 모델)

Meta model

• Meta란 대상물 자체가 아닌 대상의 정보를 담는 것
• 소프트웨어 생산 프로세스를 설계하기 위한 틀을 제공
• 프로젝트의 위험 수준에 따라 진행

신중한 프로세스 설계를 통해 고위험 문제를 식별하고 제거하는 데 중점

문제점

• 각 반복(spiral)마다 위험 분석을 수행해야 하므로 비용이 많이 듬
• 적용 가능한 범위에 제한 존재
• 대규모 소프트웨어 개발에만 적합

V Model

• Verification & Validation Model
• Waterfall Model의 확장
• 각 단계에 대응하는 테스트
• 단계가 한 번에 하나 씩 완료

특징

• 요구사항이 잘 이해된 작은 프로젝트에 적합

장점

• 단순하고 이해하기 쉬움

단점

• 요구사항이 변경될 가능성이 큰 프로젝트에는 하이리스크
• 복잡하고 객체지향 프로젝트에 좋지 않음
  • 객체지향 프로젝트는 사용자의 상호작용, 유연한 확장성이 중점이어서 요구사항에도 잦은 변경이 있음

CBSE Process (컴포넌트 기반 소프트웨어 공학 프로세스)

• 컴포넌트를 기반으로 한 개발 과정
• 현대 소프트웨어 컴포넌트의 개념
  • Software ICs
    
• CBSE 프로세스는 재사용을 통해 설계 및 개발됨

DevOps = Develpment + Operations

• 개발과 운영을 결합하여 신속, 협업, 자동화를 중시하는 철학과 실천 방식
  • 자동화 => 배포 사람 관여 최소화

전통적인 소프트웨어 개발 방식

• 사일로(Silo) 접근 방식
  • 각 팀이 독립적으로 일하며 자체 프로세스를 유지
  • Silo = 곡물창고
  • 
  • 이로 인해 잘못된 의사소통, 정렬부족, 생산 지연(“War Room”) 같은 문제들이 발생

DevOps 목

• IT 운영과 개발 사이의 격차를 좁힘
• 의사소통과 협업을 향상
• 더 원활한 프로세스, 전략과 목표의 일관성 확보를 통해
• 더 빠르고 효율적인 전달

DevOps란 무엇인가

개발부터 실행까지 DevOps 생명주기

1. Plan
2. code
3. build
4. test
5. release
6. deploy
7. Operate
8. Monitor

DevOps의 기본 생각

• 지속적인 통합
  • Git
• 지속적인 전달
• 지속적인 배포
  • 사용자 환경메 맞춰서 디바이스에 설치
• 마이크로 서비스 아키텍처
  • 큰 아키텍처를 작은 아키텍처로?
• 코드기반 인프라구조
  • 트래픽이 몰리면 조절
• 모니터링&로깅

DevPos의 장점

• 빠른 개발&빠른 릴리즈
• 테스트 자동화
• 빠르고 쉬운 업데이트
• 협업 강화
• 보안 프로세스

DevPos Tool Example

다른 프로세스 모델

?

프로젝트 특징에 의한 SDLC

주요 산출 문서

Standards for Software Process

• 어떻게가 아닌 무엇을 해야하는가를 나타내는 표준
• ISO 9000 인증받았다 => 개발자체가 프로세스를 따라서 개발했기때문에 품질을 보장받을 수 있음
• CMMI
  • 코딩뿐만 아니라 요구사항 변경 코딩 평균, 버전관리 회사의 전반적인 능력평가 후 인증뿐만 아니라 LEVEL단위로 줌.
• A-SPICE -> Auto motive

ISO/IEC/IEEE 12207

목적

• 소프트웨어 생명 주기를 위한 공통 프레임워크를 수립
  • 소프트웨어의 획득, 공급, 개발, 운영 및 유지보수를 지원
  • 프레임워크를 관리, 통제 및 개선

역사

• 1988년 6월에 제안
• 4개의 작업 초안, 2개의 위원회 초안, 1개의 국제 표준 초안(DIS)
• 6년 이상 17,000 인력 시간이 투입됨
• 1995년 8월 1일에 발행
• 새로운 버전이 2017년 11월에 발행

참여 국가

• 호주, 캐나다, 덴마크, 핀란드, 프랑스, 독일, 아일랜드, 이탈리아, 일본, 한국, 네덜란드, 스페인, 스웨덴, 영국, 미국

아키텍처 기본 컨셉

• Conceptualization
• Retriement
• 프로세스를 쪼개는 과정에서 모듈리티 적용
• PDCA = Plan - Do - Check - Act
  • 비즈니스에서 생산 및 품질 관리 방법

프로세스 기본 컨셉

Legacy Software

동기

• 새로운 프로젝트 다시 새로 개발 불가
  • 이미 많은 투자가 들어감
• 레가시
  • 기존의 오래된 시스템이나 소프트웨어는 중요한 자산
  • 폐기하기 전에 신중하게 보존

Reengineering = Reverse engineering + Forward engineering

• 기존 시스템을 수정하여 새로운 형태로 다시 구성하는 과정
  

1. Reverse engineering(역공학)
2. 소스코드를 넣고 툴을 돌리면 클래스 구성 등의 정보를 줌
3. refactoring
4. Forward engineering(순공학)