📕 목차
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 동작이 배포 및 운영 환경에서도 동일하게 보장되어야 한다.
📌 Comparison of tranditional process model and Agile model
