[Software Engineering] 2. Software Dev. Life Cycle

📕 목차

1. Process
2. Software Process Model
3. Types of Software Process Model
4. Types of Agile software development
5. DevOps

1. Process

📌 Definition of Process

일이 처리되는 과정이나 공정
주어진 일을 해결하기 위한 목적으로써, 그 순서가 정해져 수행되는 일련의 절차
목적을 달성하기 위함

📌 What is software process model?

SW Model의 목적은 S/W 개발 및 진화에 관련된 단계의 순서를 결정하고, 한 단계에서 다음 단계로 진행하기 위한 전환 기준을 설정하는 것이다. 여기엔 현재 단계의 완료 기준과 선택 기준 및 다음 단계의 진입이 포함된다. 따라서 프로세스 모델은 다음과 같은 S/W 프로젝트 질문을 다룬다.
우리가 다음으로 무엇을 해야 하는가? 언제까지 이 작업을 할 것인가?
- Boehm (1988)

📌 Why are Process Models important?

다양한 기술들이 수반되는 프로젝트에서 일련의 순서에 대한 가이드 라인을 제시해준다.
개발과 유지를 관리하기 위한 프레임 워크를 사용함으로써, 자원을 측정하고, 중간 방향성을 정의하고, 진행사항을 모니터링 할 수 있다.
Process의 quality는 곧 Product quality로 이어진다.

📌 SW development process

작업(task) 순서의 집합 + 제약 조건(일정, 예산, 자원)을 포함하는 일련의 활동(activity)
- task : SW 개발할 때 일을 수행하는 단위
좁은 의미 : SW product를 개발할 때 필요한 절차·과정·구조
넓은 의미 : SW 개발 목적을 이루는 데 포함되는 절차·구조·방법·도구·참여자 등의 통합적 수단
이전에 얻는 노하우 전달 → 시행착오 감소 → 빠른 적응

2. Software Process Model

📌 Definition

SE project에 수반되는 활동들의 순서에 대한 설명
SDLC (Software Development Life Cycle)
SW를 어떻게 개발할 것인가에 대한 전체적인 흐름을 체계화한 개념
개발 계획 수립부터 최종 폐기 때까지의 전 과정을 다룬다.
순차적인 단계로 구성된다.

📌 Purpose

고품질 소프트웨어 product 생산
- 공장처럼 SW 개발 전 과정을 하나의 Process로 정의

📌 Role

전체적인 프로젝트 기본 골격을 세운다.
일정 계획 수립
개발 비용 포함 여러 자원을 산정·분배
참여자 간에 의사소통 기준 확립
용어 표준화
개발 진행 사항 명확히 파악
각 단계별 생성되는 문서를 포함한 산출물을 활용하여 검토 가능

📌 CASE (Computer-Aided Software Engineering)

SE의 여러 작업들을 자동화하는 도구
SW system의 문서화 및 명세화를 위한 그래프 제공
자료 흐름, Business Process 등의 digram을 쉽게 작성

📌 Types

💡 모든 프로젝트에 절대적인 방법은 없으니, 자신의 프로젝트에 적합한 모델을 선정해야 한다.

Build-and-Fix (Code-and-Fix)
Waterfall
Prototyping
Incremental & Iterative
Spiral
V model
Agile

3. Types of Software Process Model

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

📌 Build-and-Fix Model

공식적인 가이드라인이나 프로세스가 없는 방식
명세서 및 설계 단계 없이 간단한 기능만을 정리하여 개발 착수
일단 코드 작성하여 제품을 만들어 본 후에 요구 분석, 설계, 유지 보수 고려
개발자 한 명이 단시간에 마칠 수 있는 대학 수업 한 학기용 프로젝트 정도 규모에 적합

🔴cons

정해진 개발 순서나 각 단계별 문서화된 산출물이 없으므로 관리 및 유지보수 어려움
좋은 SW Architecture를 만들 수 없다.
일을 효과적으로 나눠 개발할 수 없으며, 프로젝트 진척 상황을 파악할 수 없다.
계속적 수정으로 인해 프로그램 구조가 나빠져 수정이 매우 어려워진다.

📌 Waterfall Model

1970's에 인기를 끌었다.
표준 산업 관행으로 문서 지향적
각 단계별 산출물은 다음 단계의 input
많은 변형이 존재한다.
Linear(순차적), Rigid(엄격한), Monolithic(획일적이고 자유성이 떨어지는)
- 분석부터 코딩까지 선형적으로 진행된다.
- 각 페이즈 별 산출물은 이전 단계가 진행되기 전까지 동결된다.
- 모든 계획이 하나의 delivery date를 지향하고 있다.

🟢 pros

관리 용이
체계적 문서화
요구 사항의 변화가 적은 프로젝트에 적합

🔴 cons

각 단계의 결과물이 완벽한 수준으로 작성되어야 다음 단계에 오류를 전파하지 않는다.
클라이언트가 중간에 가시적인 결과를 볼 수 없다.

1️⃣ Requirements analysis and specification

application에 필요한 qualities를 확인한다.
반드시 "무엇"을 해야 하는지에 초점을 맞춰야 한다. ("어떻게"가 아니라)
산출물은 고객과 디자이너에게 사용되는 문서
문서(SRS; Software Requirement Specification)는 다음 내용들을 포함한다.
- 문제 정의
- 대체 가능한 계획과 그렇게 했을 때 이점
- 필요한 자원, 비용, 기간

⇒ SRS 도출

2️⃣ Design and specification

문제에 대한 해결책을 강구한다.
전체 시스템을 모듈(부분 문제)로 분리한다.
- 모듈 간의 관계를 명확히 한다.
- 각 모듈을 설계한다.
High-level(architectural), Low-level(detailed), User interface로 나눌 수 있다.

⇒ SDS 도출

3️⃣ Coding and Testing

설계를 코드로 이상적으로 전환하는 과정
Testing
- 유닛 테스트 (Unit testing)
- 통합 테스트 (Integration testing)
- 시스템 테스트 (System testing)
- 인수 테스트 (Acceptance testing)

⇒ Program source code 도출

4️⃣ Delivery and Maintenance

가장 많은 비용과 노력이 투입되는 단계
오류 수정(Corrective) 20%, 환경 변화 반영(Adaptive) 20%, 새로운 기능 추가·성능 개선(Perfective) 60%
Requirements analysis는 심각한 문제의 근원이다. (망하면 되돌리기도 힘든데, 도미노 마냥 모든 단계가 망함)
- 수많은 에러가 시스템이 완성되어 전달되고 난 후에도 제거되지가 않는다.
product가 개발 단계에서 변화를 수용하기가 굉장히 힘들다.

5️⃣ Other activities

문서화
검증
- application quality 모니터링
- Methods(Review, Walk-through, Inspection)
  - inspection: 체계적으로 정의된 절차를 기반으로 결함을 발견하기 위해 훈련된 엔지니어에 의해 수행되는 산출물의 동료 검토(Peer Review)
관리
- Process 맞춤화
- 정책 결정
- Process에 영향을 주는 모든 자원 관리

📌 Prototyping Model

Prototype: 대량 생산에 앞서 미리 제작해보는 원형 또는 시제품
SW develop에서 Prototype : 정식 절차에 따라 완전한 SW를 만들기 전에 사용자 요구를 받아 일단 모형을 만들고, 해당 모형을 사용자와 의사소통하는 도구로 사용한다.
Prototype을 통해 사용자 요구사항 만족 여부 판단 후 최종 시스템 구현 (Prototyping + Waterfall)

🟢 pros

반복된 요구사항 정의를 통해 사용자 요구가 충분히 반영된 SRS 작성
오류를 일찍 발견할 수 있음
초기 Prototype 사용을 통한 새로운 요구사항 발견
완성품 예측 가능

🔴 cons

반복적 개발을 통한 투입 인력 및 비용 산정 어려움
Prototyping process에 대한 통제 및 관리 어려움
중간 산출물 생성이 어려우므로, 문서 관리 또한 어려움
불명확한 개발 범위로 인한 개발 종료 및 목표의 불확실성

1️⃣ Requirement Analysis

1차 개략적인 요구 사항 정의 후 n차 반복하면서 최종 Prototype 개발

2️⃣ Prototype Design

완전한 설계 대신, 사용자와 대화할 수 있는 수준의 설계
입출력 화면을 통한 사용자 인터페이스 중심 설계

3️⃣ Prototype Development

완제품을 개발하는 것이 아님
입력 화면을 통한 사용자 요구 항목 확인
출력 결과를 통해 사용자가 원하는 것인지 확인

4️⃣ Prototype Evaluation

5️⃣ Implementation

최종 Prototype 개발

📌 Incremental & Iterative Model

단계적인 개발
각 빌드에서 Waterfall Model에서 나온 규율들을 지켜야 한다.
Lifecycle의 모든 단계는 확장될 수도 있다.

🟢 pros

Client에게 새로운 prodct를 조정할 수 있는 시간을 제공한다.
변화를 수용하기 쉽다.
단계적 전달은 큰 규모의 자금 지출을 요구하지 않는다.

🔴 cons

각각의 추가되는 빌드들은 기존 구조에 통합되어야만 한다.
더 신중한 설계가 필요할 수도 있다. (잘만 한다면 이점으로 작용할 수도)
build-fix model로 퇴화하기가 굉장히 쉽다.

📌 Spiral Model

Prototype 진화 모델 + 위험 분석(Risk analysis)
위험 요소 예시
- 빈번히 변경되는 요구사항
- 경험 부족 팀원
- 결속력이 떨어지는 팀워크
- 프로젝트 관리 부족

🟢 pros

사전 위험 분석을 통한 돌출 위험 요소 감소 (프로젝트 중단 확률 감소)
사용자 평가에 의한 개발 방식 (개발 단계에서 사용자 요구를 충분히 반영 가능)

🔴 cons

반복적 개발에 의한 프로젝트 기간 연장 가능성
반복 횟수 증가에 따른 프로젝트 관리 어려움
위험 관리에 의한 비용 증가

1️⃣ Planning Objectives

사용자의 개발 의도를 파악하고, 프로젝트 목표 수립
제약 조건의 대안을 골, 기능/비기능 요구사항 정의 및 분석

2️⃣ Risk Analysis

3️⃣ Development

4️⃣ Evalation

📌 V Model

Waterfall model + Extended testing phases (테스트 단계 추가)
각 개발 단계를 검증하는 데 초점
- Waterfall model은 Artifact-based model 산출물이 중심
테스트 계획은 각 단계 종료 시점에서 결정

🟢 pros

SW 개발 결과물에 대한 단계적 검증과 확인 과정을 거침으로써 개발 SW에 대한 오류를 줄일 수 있다.
요구사항이 정확히 이해되는 작은 시스템을 개발할 때 유용하다.

🔴 cons

폭포수 모델과 비슷한 단점을 가진다. (반복이 허용되지 않는다는 특성으로 인한 변화에 취약)

📌 Agile

(2001.02월 이후) Build-and-Fix 방식에 상세적이고 구체적인 계획을 수립하여 진행하는 방법의 필요성 대두
고객의 요구에 민촙하게 대응하고 그때그때 주어지는 문제를 낭비없이 풀어나가는 방법론 전체를 일컫는 말
Agile SW Development 선언문
- Process와 Tool 중심이 아닌, 개개인과의 상호 소통 중시
- 문서 중심이 아닌, 실행 가능한 소프트웨어 중시
- 계약 협상 중심이 아닌, 고객과의 협력 중시
- 계획 중심이 아닌, 변화에 대한 민첩한 대응 중시
종류
- Extreme Programming(XP)
- Scrum
- Dynamic Systems Development Method(DSDM)
- Lean
- Kanban
- Scrumban

4. Types of Agile software development

• Extreme Programming(XP)
• Scrum
• Dynamic Systems Development Method(DSDM)
• Lean

📌 Extreme Programming(XP)

Teamwork가 중시 된다. 관리자, 고객, 개발자 모두 동등한 파트너
SW project를 개선시키는 5가지 방법 (커뮤니케이션, 단순화, 피드맥, 존중, 격려)

📌 Scrum

개발에 대한 실천사항 보다 반복적인 개발을 관리하는데 초점을 둔다.
주요 artifacts
- Product backlog : 제품 기능 우선 순위 정리
- Sprint backlog : 하나의 sprint 동안 개발할 목록
- Burndown chart : 개발을 완료하기까지 남은 작업량을 보여주는 그래프
특징
- 하나의 Sprint(1~4주 단위 반복 개발 기간)마다 위의 3가지 산출물을 관리하며 진행
- 하나의 Sprint마다 일일 스크럼, Sprint 계획, Sprint 리뷰 회의를 병행
- 하나의 Sprint가 끝나면 개발된 결과물을 통해 고객 확인과 피드백

📌 DSDM (Dynamic Systems Development Method)

전체 작업 중 일의 우선순위를 따진다.
- 여기서 80%에 초점을 맞추고, 나머지 20%는 다음 개정 버전으로 미룬다.
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)의 반복

5. DevOps

📌 Background

2000년대 이후 system 규모가 커지고 복잡해지면서 보다 안정적인 운영과 빠른 개발 방식이 충돌하기 시작
- 운영자: 빠른 개발 하니까 오류 너무 많이 난다. 새로운 기술 도입하여 변화하는 것이 부담이고, 사용자 피드백 반영하기도 힘들다.
- 개발자: Agile로는 거대한 기존 시스템 파악이 너무 어렵고, 운영자 도움이 부족한 상황에서 새로운 기술 구현이 너무 부담스럽다.

📌 What is DevOps?

Development + Operation : 개발과 운영활동에 대한 기민한 협업과 활동의 자동화를 통한 진화된 SW 개발
개발 시스템의 Build와 Operation의 반복 과정을 거쳐 SW 개발하는 접근 방법
개발 활동, 운영 활동, 사용자 피드백을 상호 연결한다.

📌 Characteristic

지속적 통합과 지속적 배포 (CI/CD)
- 각 팀에서 개발한 결과물을 서버에서 SW 컴포넌트를 주기적으로 매일 통합한다.
- 테스트 단계를 거쳐 생산 단계로 이동하여 사용자에게 배포된다.
- 통합이 주기적으로 이루어지듯 배포도 문제가 없다면 지속적으로 수행되어야 한다.
자동화 (Automation)
- 운영 환경 오류를 신속하고 일관성 있게 해결하기 위해 자동화된 환경을 전체 Lifecycle에 구축한다.
- 개발 환경에서 나타나는 SW 동작이 배포 및 운영 환경에서도 동일하게 보장되어야 한다.