2. 소프트웨어 개발 생명 주기

Process

일이 처리되는 과정이나 공정

주어진 일을 해결하기 위한 목적으로, 그 순서가 정해져 수행되는 일련의 절차

소프트웨어를 정해진 기간동안 고객이 원하는 수준의 품질로 deliver하는 것이 목적

 

SW 프로세스의 3요소

• 소프트웨어 세부 작업들의 관계를 정의하는 절차와 방법
• 능력, 교육 및 동기가 부여된 인원
• 도구와 장비

 

소프트웨어 프로세스 모델

소프트웨어 개발 프로세스

프로세스: 작업(task)순서의 집합 + 제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동

(좁은 의미: SW제품을 개발할 때 필요한 절차, 과정, 구조. 사용자의 요구사항을 SW시스템으로 구현하기 위한 일련의 활동)

(넓은 의미: 절차,구조,방법, 도구, 참여자까지 모두 포함. SW개발 목적을 이루는데 필요한 통합적 수단)

 

작업(task): SW를 개발할 때 일을 수행하는 작은 단위

 

프로세스의 목적

이전에 얻은 노하우를 전달 -> 시행착오 감소 -> 빠르게 적응

SW개발시 가이드 역할

 

소프트웨어 프로세스 모델의 정의

SW 개발 생명주기(SDLC)

SW를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념

개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다룸

순차적인 단계로 이루어짐

 

소프트웨어 프로세스 모델의 목적

SW개발의 전 과정을 하나의 프로세스로 정의

주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의

고품질의 소프트웨어 제품 생산을 목적으로 함

 

소프트웨어 프로세스 모델의 역할

• 프로젝트에 대한 기본골격을 세움
• 일정 계획을 수립 가능
• 개발 비용 등 여러 자원 산정과 분배 가능
• 참여자 간 의사소통의 기준을 정할 수 있음
• 용어의 표준화 가능
• 개발 진행 상황을 명확히 파악 가능
• 각 단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있게 해줌

 

CASE tool

Computer-Aided Software Engineering

SW공학의 여러 작업들을 자동화하는 도구

SW시스템의 문서화 및 명세화를 위한 그래픽 기능 제공

자료흐름, 비즈니스 프로세스 등의 다이어그램을 쉽게 작성할 수 있게 함

소프트웨어 설계 단계의 작업을 지원하는 도구도 CASE도구이다.

 

Software process model

• Build-and-Fix
• Waterfall
• Prototyping
• Incremental & Iterative
• Spiral
• V model
• Agile

---

Build-and-Fix model

공식적인 가이드라인이나 프로세스가 없음

명세서나 설계 단계 없이 간단한 기능만을 정리하여 개발하는 형태

일단 코드를 작성하여 제품을 만들어본 후, 요구 분석, 설계, 유지보수에 대해 생각함.

 

사용

개발자 한 명이 단시간에 마칠 수 있는 경우에 적합

대학 수업의 한 학기용 프로젝트 정도

 

단점

정해진 개발 순서나 단계별 문서화된 산출물이 없어 관리 및 유지보수가 힘듦

좋은 SW architecture를 만들 수 없음

일을 효과적으로 나눠 개발하기 힘듦

프로젝트 진척 상황을 파악하기 힘듦

계속적인 수정으로 인해 프로그램 구조가 나빠져 수정이 어려워짐

 

---

Waterfall model

Requirement(요구사항 분석) -> Design(설계) -> Implementation(구현) -> Verification(테스트) -> Maintenance(유지보수)

단계별로 진행하는 SW개발 모델.

• 체계적인 문서화를 진행
• 요구사항의 변화가 적은 프로젝트에 적합.
• 각 개발 단계의 결과물이 완벽할 수 있도록 충분한 시간을 들여 작업
• 산출되는 문서가 많기 때문에 PM입장에서 프로젝트 관리가 쉬움
• 순차적이며, 엄격하고, 획일적이고 자유성이 떨어진다.

 

1. Requirements analysis and specification

기능적/비기능적 요구사항을 정의

소프트웨어의 전반적인 기능과 목표를 정함

 

2. Design and specification

3. Coding and testing

4. Delivery and maintenance(가장 많은 비용과 노력이 투입)

앞 단계에서 수정해야 비용이 적게 든다.

 

Verification: 품질, 기획대비 결과물 등을 검증. 동료검토(Review, Walk-through, Inspection: 체계적, 공식적) 

Management: tailoring the process

 

장점:

관리의 용이

체계적인 문서화

요구사항의 변화가 적은 프로젝트에 적합

 

단점:

각 단계의 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 넘겨주지 않는다.

사용자가 중간에 가시적인 결과를 볼 수 없어 답답해할 수 있다.

---

Prototyping

정식 절차에 따라 완전한 소프트웨어를 만들기 전에, 사용자의 요구를 받아 일단 모형(시제품)을 만들고 이 모형을 사용자와 의사소통 하는 도구로 활용한다.

프로토타입을 통해 사용자의 요구사항 만족 여부 판단 후 최종 시스템을 구현(프로토타입 개발 과정 + waterfall)

사용자의 요구사항을 반복적으로 반영하여 최종 프로토타입 생성.

최종 프로토타입을 통해 결정된 사용자의 요구를 가지고 다시 처음부터 본격적으로 제품 개발(최종 프로토타입은 버림)

개발하고자 하는 소프트웨어의 요구사항이 자주 변경될 가능성이 높은 경우 사용하기 적절함.

 

1. 요구사항 정의 및 분석: 1차 개략적인 요구 사항 정의 후, 2,3,..n차를 반복하며 최종 프로토타입 개발

2. 프로토타입 설계: 완전한 설계 대신, 사용자와 대화할 수 있는 수준의 설계. 입출력 화면을 통한 UI중심 설계

3. 프로토타입 개발: 입력 화면을 통한 사용자의 요구 항목 확인, 출력 결과를 통해 사용자가 원하는 것인지 확인

4. 사용자에 의한 프로토타입 평가(추가 및 수정 요구가 가능)

5. 구현: 최종 프로토타입 개발

 

장점:

반복된 요구사항 정의를 통해 사용자 요구가 충분히 반영된 요구 분석 명세서가 작성됨.

(개발자와 사용자간의 견해차이가 해결)

프로토타입을 이용하여 오류(일치하지 않는 요구사항)를 일찍 발견

초기 프로토타입을 통해 새로운 요구사항 발견

완성품의 예측 가능(기능성과 유용성을 고객에게 쉽게 보여줄 수 있다)

 

단점:

반복적 개발을 통한 투입 인력 및 비용 산정의 어려움

프로토타이핑 과정에 대한 통제 및 관리 어려움

중간 산출물 생성, 문서화 어려움

불명확한 개발 범위로 인한 개발 종료 및 목표의 불확실성

---

Incremental & Iterative model

Incremental Model

소프트웨어를 작은 부분 단위로 나누어 각각 개발하고 통합해 나가는 방식.

 

Iterative model

초기에 정의된 요구사항을 기반으로 시스템을 개발하고, 이후 반복적으로 요구사항을 수정하고 개선해나가는 방법.

 

stepwise 개발방식

각각 빌드에서 waterfall 모델을 사용

 

장점:

변경사항을 받을 시간여유가 있음

변화를 수용하기 좋음

큰 금전지출을 요구하지 않음

 

단점:

각각의 추가 빌드 작업이 기존의 것과 통합돼야함

더 잘 준비해야한다. 잘못하면 build and fix 모델이 될 수 있음.

---

Spiral model(나선형 모델)

진화적 프로토타입 모델 + 위험 분석(risk analysis)

프로젝트 수행 시 발생하는 위험을 관리하고 최소화하는 것이 주된 목적

 

위험 분석 단계의 위험 요소 예

• 빈번히 변경되는 요구사항
• 팀원들의 경험 부족
• 결속력이 떨어지는 팀워크
• 프로젝트 관리 부족
• 개발자의 이직
• 발주사의 재정적 어려움
• 예상을 빗나간 투입 인력
• 기간 부족
• 비용 초과

Spiral model 개발 절차

1. Planning objectives(계획 및 요구 분석 단계)

2. Risk analysis(위험 분석 단계)

3. Development(개발 단계)

4. Evaluation(사용자 평가 단계)

계획 및 정의 - 위험 분석 - 개발 - 고객 평가

 

장점:

사전 위험 분석을 통한 돌출 위험 요소 감소 -> 프로젝트 중단 확률 감소

사용자 평가에 의한 개발 방식 -> 요구가 충분히 반영됨. 불만 감소

 

단점:

반복적 개발에 의한 프로젝트 기간 연장 가능성

반복 횟수의 증가에 따른 프로젝트 관리의 어려움

위험 관리의 중요(위험 관리 전문가가 필요 -> 비용증가)

---

V model

waterfall + extended testing phases(waterfall model에서 테스팅 단계를 추가 확장)

각 개발 단계를 검증하는 데 초점을 둠.

초기 개발 단계부터 세부 테스팅 단계들이 1:1로 매칭된다

테스트 계획은 테스트 수행 직전이 아닌, 각 단계 종료 시점(프로젝트 초기단계부터)에서 수립함.

UI 검증 단계가 포함된다.

 

여러가지 테스팅 작업으로 결함을 빠르게 발견 -> 비용 감소

                                                           

 

                                                       인수 테스트

요구 분석 ----------------요구 분석 검증-------------- 시스템 테스트

        아키텍처 설계 -----인터페이스 검증--------- 통합 테스트

                 모듈 설계 ----모듈 검증----- 단위 테스트

                               구현

 

장점:

개발 결과물에 대한 단계적인 검증과 확인 과정을 통해 오류를 줄일 수 있음

요구사항이 정확히 이해되는 작은 시스템 개발 시 매우 유용

 

단점:

폭포수 모델을 적용함으로써 개발 활동에 대한 반복이 허용되지 않기 때문에 변경을 다루기 쉽지 않음

 

---

Agile model

build and fix와 상세하고 구체적인 계획을 수립하는 방식 사이에서 타협

'날렵한','민첩한'

개발 오버헤드를 줄임으로써 소프트웨어를 신속히 생산하도록 하는 반복적 개발방법.

 

고객의 요구에 민첩하게 대응하고,

그때그때 주어지는 문제를 낭비없이 풀어나가는 방법론

 

기본 가치(Agile 선언문)

• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통(협업) 중시
• 문서 중심이 아닌, 실행 가능한 SW 중시
• 계약과 협상 중심이 아닌, 고객과의 협력 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응 중시

Agile software development의 종류

• Extreme programming(XP)
• scrum
• Dynamic Systems Development Method(DSDM)
• Lean
• Kanban
• Scrumban

---

Extreme Programming(XP)

협동, 팀워크 강조

소통, 간소화, 피드백, 리스펙, 장려

Pair programming, small release, incremental planning

 

 

XP에서의 10가지 실천사항

• 증분 계획: 요구사항은 스토리 카드에 기록되고, 릴리즈마다 스토리의 상대적 우선순위가 결정된다.
• 작은 배포: 비즈니스 가치를 제공할 수 있는 최소한의 유용한 기능을 먼저 개발하여 배포한다.
• 단순 설계
• 테스트 우선 개발: 기능 자체가 구현되기 전에 새로운 기능에 대한 테스트를 위해 자동화된 단위 테스트 프레임워크 사용
• 재구조화
• 짝 프로그래밍
• 공동 소유권: 모든 개발자가 모든 코드를 책임지며, 누구나 변경 가능
• 지속적 통합
• 지속 가능한 개발 속도
• 현장 고객

---

Scrum

개발에 대한 실천사항보다 반복적인 개발을 관리하는데 초점.

고객 피드백을 중요시한다.

 

3가지 artifact

Product backlog: 제품 기능 우선순위 정리

Sprint backlog: 하나의 sprint동안 개발할 목록

Burndown chart: 개발을 완료하기까지 남은 작업량을 보여주는 그래프

 

특징:

하나의 sprint마다 위의 3 산출물을 관리해가며 진행

하나의 sprint마다 일일스크럼, Sprint계획, Sprint 리뷰 회의를 함께 해가며 진행

하나의 Sprint가 끝나면 개발된 결과물을 가지고 고객 확인과 피드백

---

Dynamic Systems Development Method(DSDM)

 

우선순위 지정

MoSCow rules

M: Must have requirements

S: Should have if at all possible

C: Could have but not critical

W: Won't have this time, but potentially later

 

---

Lean

빠른 피드백을 통한 제품 개발과 실험, 정확한 성과 측정을 통해 고객이 원하는 방향에 초점

만들기-측정-학습의 반복

(Build-Measure-Learn)

 

• 낭비되는 공정 제거
• 배운 내용들을 확산
• 결정 신중히
• 빠르게 납품
• 산출물 통합이 쉽게 가능한 환경 구축
• 전체적인 최적화

---

DevOps

Agile이 system규모가 커지고 복잡해지면서, 보다 안정적인 운영을 필요로하게 되고, 빠른 개발 방식에도 태클이 걸리기 시작. 

운영자측: 빠른 개발은 종종 장애를 일으킴. 새 기술 도입, 변화에 부담. 사용자의 빠른 피드백 필요

개발자측: Agile로는 비대해진 기존 시스템을 파악하기 어려움. 운영자 도움 없이 새로운 기술 구현시 예상치 못한 문제 발생 

 

DevOps

빠르고 새로운 변화를 시도하는 개발과 장애없고 안정적인 운영이 서로 충돌하는 문제를 해결하기 위해 고안된 개발 방식

개발과 운영활동에 대한 기민한 협업과 활동의 자동화를 통한 진화된 소프트웨어 개발 활동을 의미.

- 개발 시스템의 Build와 Operation의 반복 과정을 거쳐 SW를 개발함

(개발 활동, 운영 활동, 사용자의 피드백을 상호 연결)

DevOps 적용 이후 code deployment(배포) 하는데 걸리는 시간이 빨라지고 빈도수가 늘어났다

특징:

지속적 통합과 지속적 배포(CI and CD): 각 팀이 개발한 결과물을 서버로 전송, 서버는 컴포넌트를 주기적으로 가능하면 매일 통합.

자동화