[소프트웨어분석및설계🛠️] 1장 SW 개발 프로세스

출처 : 강의 교안, 시스템분석설계 with 애자일 (생능출판사, 최은만)

 

1. 소프트웨어 개발 개요

1.1 소프트웨어 개발 개요

1) 소프트웨어 개발 과정

1️⃣ 실현 가능성 분석

2️⃣ 요구사항 도출 및 분석

3️⃣ 설계

4️⃣ 코딩 및 단위 시험

5️⃣ 통합 및 시스템 시험

6️⃣ 배포, 설치 및 운영

 

2) 소프트웨어

- 프로그램 자체 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체

- 개념적, 무형적

- 소프트웨어의 특징

• 복잡성 (complexity)
• 순응성 (conformity)
• 변경성 (changeabilty)
• 비가시성 (invisibility)

- 소프트웨어는 사람의 지적 활동에 의해 구축된다.

- 소프트웨어 개발작업의 특징

• 명세화의 어려움
• 재사용의 어려움
• 예측의 어려움
• 유지보수의 어려움
• 고품질의 어려움

 

2. 분석과 설계

2.1 분석과 설계

1) 분석

- 소프트웨어가 해결해야 할 문제들을 이해하기 위한 적업

- 요구분석 : 소프트웨어 개발을 의뢰한 고객이 개발될 소프트웨어에 대해 요구하는 기능과 성능을 요구사항으로 일관성 있게 정리하는 것

 

2) 설계

- 분석 작업을 통해 밝혀진 SW의 요구사항을 어떤 형태로 프로그램에 반영할 것인지를 결정하는 작업

- 요구사항에 기술된 문제의 솔루션을 계획 

- 아키텍쳐 설계, 인터페이스 설계, 모듈 알고리즘 설계, 데이터베이스 설계

 

3) 분석과 설계의 방향

- 단계적 분할 (구조적 분석 설계) : 결정된 단위로 조금씩 분할 

- 객체지향 분석 설계

 

3. SW개발 프로세스

3.1 SW개발 프로세스

1) 소프트웨어 개발의 어려움

- 소프트웨어의 특성적 어려움

• 무형성
• 진화성

- 기타 어려움

• 요구사항이 수시로 변경
• 사람에 의존하여 개발됨 ; 개인의 특성
• 의사소통의 어려움
• 프로젝트 규모에 따른 인력, 비용, 의사소통, 복잡도 등이 증가함.

- 소프트웨어 개발에 공학적 접근 방법을 적용 ; 방법론, 프로세스, 도구 사용

 

 

• 프로세스 - 방법, 절차, 공정
• 단계적 SW 개발 프로세스
  • 소프트웨어에 대한 비전과 개념을 먼저 파악하고, 구현할 때까지 정해진 순서의 작업 수행
  • 분석 ➡️ 설계 ➡️ 구현 ➡️ 테스트
  • 각 단계별 결과물은 요구분석 명세서, 설계서, 프로그램, 매뉴얼 등으로 다양함.

 

4. 프로세스 모델

4.1 프로세스 모델

1) 프로세스의 정의

- 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업

 

2) 소프트웨어 개발 프로세스

- 소프트웨어 개발 과정 (작업 순서)

- 높은 품질과 생산성이 목표

- 프로세스가 없는 개발  = Code-and-Fix (즉흥적 개발)의 문제

• 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움
• 신중하게 설계하지 않으면 소프트웨어 구조가 나빠짐
• 일이 잘 되었는지 판단하기 어려움
• 비용과 일정의 조절이 어려움
• 발견되지 않은 결함을 계속 고치게 되며 시스템 악화

3) 소프트웨어 개발 프로세스 모델

- 일반적인 프로세스를 기술한 것

- 작업의 단계와 순서, 작업의 제약사항이나 조건 등을 모아 놓은 것

 

💙 SDLC (SW Development Life Cycle)

: 소프트웨어를 개발하는 절차, 혹은 개발단계를 반복하는 과정

 

💙 SW 개발은 단순 코딩이 아닌 문제 해결 과정이 되어야 한다.

 

4.2 전통적인 프로세스 모델

1) 폭포수 모델 (Wateffall Model)

- 각 단계가 완료된 후, 다음 단계로 진행한다.

- 이전 단계로 돌아갈 수 없다.

• 순차적 : 각 단계 사이에 중복이나 상호작용이 없다.
• 각 단계의 결과는 다음 단계가 시작되기 전에 점검한다.

- 결과물 정의가 중요하다.

- 장점

• 가장 오래되고 폭넓게 사용되어 사례가 풍부하다
• 진행과정이 세분화되고 순차적이므로 관리가 용이하다.

- 단점

• 후반부에 개발이 구체화되기 때문에 초기 중요한 문제를 발견하기 어렵다
• 한 공정이 늦어지면, 이후 전체 공정 진행에 영향을 준다.

- 적용 시 고려사항

• 관리가 상대적으로 쉬우나 요구 사항의 변경에 대한 대응력이 떨어진다.
• 요구사항이 비교젹 명확히 정의되어 있는 경우 적용한다.

 

2) 프로토타이핑 모델 (Prototyping Model)

- 사용자의 요구사항을 충분히 분석할 목적으로 시스템의 일부분을 일시적으로 간략히 구현

- 이후 다시 요구사항을 반영하는 과정을 반복하는 개발 모델

- 프로토타입의 역할

• 요구 분석의 어려움 해결 ; 사용자의 참여 유도
• 요구 사항 도출과 이해에 있어 사용자와의 커뮤니케이션 수단으로 활용 가능 (의사소통 도구)
• 사용자 자신이 원하는 것이 무엇인지 구체적으로 잘 모르는 경우, 간단한 시제품으로 개발
• 개발 타당성으로 검토
• 실험적(Experimental) 프로토타입 : 기존의 프로토타입을 사용하지 않고 새로 구현
• 진화적(Evolutionary) 프로토타입 : 프로토타입을 계속 확장해나가며 구현

- 장점

• 프로토타입을 통해 요구사항 도출이 용이하다
• 실제 모습을 확인할 수 있기 때문에 시스템의 이해와 품질이 향상된다
• 개발자와 사용자 간 소통이 용이하다

- 단점

• 프로토타입으로 사용자 기대수준이 올라갈 수 있다.
• 개발단계 반복으로 투입 인력 및 비용 산정이 어렵다.
• 중간 이정표나 산출물이 없어서 과정을 통제하기 어렵다.

 

3) 진화적(evolutionary) 모델

- 빠른 시간 안에 출시해야 할 경우에는 시스템을 나눠 릴리즈한다.

- 릴리즈할 때마다 기능의 완성도를 높인다.

- 개발된 모듈을 업그레이드하는 방식으로 SW가 진화해나가는 개념

- 장점

• 몇 가지 기능이 부족하더라도 초기에 사용이 가능하다.
• 새로운 기능을 가진 SW에 대한 시장을 빠르게 형성할 수 있다.
• 가동 중인 시스템에서 일어나는 예상치 못한 문제를 신속하고 꾸준하게 고쳐나갈 수 있다.

- 단점

• 프로젝트 관리가 복잡하다.
• 반복적인 프로세스로 실패의 위험이 크다.

 

4) 나선형(Spiral) 모델

- 폭포수 모델과 프로토타입 모델의 장점을 활용한다.

• 복잡해지고 있는 소프트웨어 개발 환경에 위험 요소를 분석하고 해결할 수 있도록 지원하는 모델
• 여러 번의 점증적인 릴리즈

- 장점

• 반복적인 개발 및 테스트로 강인성을 향상
• 한 사이클에 추가하지 못한 기능을 다음 단계에 추가

- 단점

• 관리 및 위험 분석이 중요하므로 매우 어렵고 개발 기간이 장기화될 수 있다.

- 적용

• 재정적 또는 기술적으로 위험 부담이 큰 경우
• 요구사항이나 아키텍쳐 이해에 어려운 경우

 

5) 점증적(Incremental) 모델

- 사용자 요구사항의 일부분, 제품의 일부분을 반복적으로 개발하면서 대상 범위를 확대해 나아가서 최종제품을 완성한다.

- 증분을 따로 개발한 후 통합 : 프로토타이핑과 같이 반복적이나, 각 증분마다 실행이 가능한 완성 모듈을 인도

- 규모가 큰 개발 조직일 경우 자원을 증분 개발에 충분히 할당할 수 있어 병행 개발 가능

6) V 모델

- 폭포수 모델을 확장한 Verification & Validation 모델

- 폭포수 모델이 산출물 중심이라면, V모델은 각 갭라단계를 검증하는 데 초점을 둔다.

- 장점

• 소프트웨어 개발 결과물에 대한 단계적인 검증과 확인 과정을 거친다.
• 오류를 줄일 수 있다.

- 단점

• 개발 활도에 반복이 없어 변경을 다루기 쉽지 않다.

- 적용

• 요구사항이 정확히 이해되는 작은 시스템 개발 시 유용
• 신뢰성이 높이 요구되는 분야

 

4.3 에자일 프로세스

1) 에자일의 기본 가치

- 프로세스와 도구 중심이 아닌 개개인의 상호소통을 중시

- 문서 중심이 아닌 실제 고객이 실행 가능한 SW 중시

- 계약과 협상 중심이 아닌 고객과의 협력 중시

- 계획 중심이 아닌 변화에 민첩한 대응을 중시

 

2) 에자일 12가지 원칙

• Customer satisfaction : 최우선 목표는 고객을 만족시키는 SW를 빨리 지속적으로 제공하는 것
• Welcome change : 고객의 경쟁력을 위해 요구사항의 변경을 수용
• Deliver frequently : 동작 가능한 SW를 고객에게 전달
• Working together : 업무 담당자와 개발자는 매일 의견을 주고 받으며 함꼐 참여
• Motivated team : 동기가 부여된 개인을 중심으로 프로젝트 구축
• Face to face : 개발팀에 정보를 전달하는 가장 효율적인 방법은 대면 대화
• Working SW : 진척사항을 보여주는 가장 좋은 방법은 실행 가능한 SW를 보여주는 것
• Constant pace : 지속가능한 개발을 위해서 일정한 개발 속도 유지
• Good design : 좋은 설계와 기술에 관심 가지기 ; 우수한 기술과 디자인에 대한 관심으로 민첩성 향상
• Simplicity : 단순성(수행되지 않은 작업량을 최대화하는 기술)은 필수적
• Self organization : 최고의 아키텍쳐 요구사항 및 설계는 자기조직화 팀에서 나온다.
• Reflect and adjust : 정기적으로 보다 효과적인 방법을 적용해보고 그에 따라 행동을 조율하고 조정

 

3) XP (eXtreme Programming)

-  모호하고 빠르게 변하는 요구사항이 발생하는 환경의 프로젝트를 수행하는 중소규모 팀을 위한 경량화된 방법론 

- 실행되는 소프트웨어 기능을 고객에게 가치가 높은 것부터 순서대로 구현해서 단기간에 릴리즈하는 과정을 반복

- 특징

• 5 ~ 10명 정도로 구성된 개발자가 고객과 함께 한 장소에서 작업
• 개발은 점진적으로 이루어지고 각 단계마다 기능을 덧붙여 나감
• 요구사항 정의는 스토리 형태로 구체적으로 작성
• 프로그래머는 엄격한 코딩 규칙을 준수

- XP의 핵심 가치

• 소통 (Communication)
• 단순성 (Simplicity)
• 피드백 (Feedback)
• 용기 (Courage)
• 존경 (Respect)

- XP의 실천사항 (Practices)

• 증분계획
• 단순 설계
• 재구조화 (refactoring)
• 공동소유권
• 하나의 팀 (whole team)
• 시스템 메타포어 (system metaphor)
• 주 40시간 작업
• 작은 배포
• 테스트 주도 개발
• 페어프로그래밍
• 지속적 통합
• 코딩 표준

- XP 프로세스 흐름

• 유저스토리 (User Story) : 요구사항 정의서
• 구조적 스파이크 : 전체 시스템을 한눈에 보기 위한 모델
• 스파이크 : 일의 규모나 시간 요구량을 가늠하기 위한 솔루션 (일종의 프로토타입)

 

4) 스크럼

- 반복적 개발의 관리 관점을 강조

- 용어

• 스트린트 (sprint) : 반복적인 개발 주기
• 제품 백로그 (backlog) : 개발 제품에 대한 요구사항 목록 
• 스프린트 백로그 : 스프린트 목표에 도달하기 위해 필요한 작업 목록
• 번다운 차트 : 작업 현황을 추적하기 위해서 사용하는 차트. 스프린트 백로그에 남아 있는 작업 목록을 보여주는 차트
• 번업 차트 : 배포에 필요한 진행 사항을 보여주는 차트

- 스크럼은 특정 언어나 방법론에 의존적이지 않은, 넓은 응용 범위의 개발 기법

- 특징

• 기능 및 개선점에 대한 우선순위를 부여
• 개발 주기는 30일 (1~4주) 정도로 하며, 개발 주기마다 실제 동작 가능한 결과를 제공
• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공
• 항상 팀 단위로 생각하고, 날마다 15분 정도 스크럼 미팅

5) TDD (Test-Driven Development)

- 요구사항 검증 및 설계의 고도화

- 짧은 주기에 라이프 사이클을 반복하는 테스트-설계-피드백 중심의 개발 방법론

- 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현

- 프로세스

• Red phase : 실패하는 작은 테스트케이스를 작성
• Green phase : 테스트를 통과하는 코드를 작성
• Refactor phase : 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고 불명확한 것을 명확하게 한다.

6) Kanban

- 도요타의 kanban 작업 방식을 소프트웨어 개발에 도입

- 작업 흐름(workflow)를 표현하는 kanban 보드를 통해 개발공정을 가시화하고 작업 제한, 소요시간 최적화 기법을 통해 적시 개발(just in time)을 지원하는 에자일 방법론

- 3가지 규칙

• workflow 가시화
• Work in progress(WIP) 제한
• 리드타임 측정

- 칸반 보드

• 진행 중인 작업을 제한하며 효율성을 최대화하는 애자일 프로젝트 관리 도구
• 에자일 팀과 DevOps 팀이 일상 업무에서 체계를 확립하는데 주로 사용

7) Chaos와 DevOps

(1) Chaos Engineering

- 시스템이 격동의 예측치 못한 상황을 견딜 수 있도록 신뢰성을 쌓기 위해 운영 중인 소프트웨어 시스템에 실험을 하는 규율

- 다양한 서비스 운영  환경에 대응하고 새로운 기능을 중단 없이 제공하기 위해서, 기존의 서비스에 임의의 결함을 주입하고 이들이 어떠한 행동을 보이는지 동적으로 검사하면서 시스템 운영에 대응하는 방법을 찾는 것

- 원칙

• 계획
  • 테스트할 항목과 이를 수행할 방법을 결정
  • 목표는 가설을 세우는 것 : 시스템에서 무엇이 잘못될 수 있을까? 악용될 수 있는 잠재적 취약점은 무엇인가?
• 실험
  • 결함을 주입하고 시스템이 어떻게 반응하는지 확인
  • 결함 주입은 단순히 취약점을 노출시키기 위해 기존 시스템에 문제를 도입하는 프로세스 (어떤 일이 일어나는지 확인하기 위해 시스템에 의도적으로 가하는 행위)
• 분석
  • 실험 데이터를 사용하여 잠재적인 실패 지점을 식별
• 완화
  • 문제가 발견되면 실험을 종료하고 문제 완화에 집중
  • 그렇지 않으면 문제의 핵심에 도달할 때까지 실험을 확장

 

❓ 기존의 사일로 기반 개발 방식의 문제점

: 소프트웨어 개발의 각 단계가 종료된 후 다음 단계로 진행 ➡️ 각 단계간 상호작용 부재

 

(2) DevOps = Development + Operations

- 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합

- 정의

• IEEE 정의 : 소프트웨어 개발과 관련된 스테이크홀더(stakeholder)들이 SW 시스템 또는 서비스를 명세, 개발, 운영하고 시스템 전체 수명주기에 걸쳐 지속적인 개선을 도모하기 위해 의사소통과 협업을 증진하기 위한 원리와 실천 사항들의 모임
• 기존의 SW 개발 및 인프라 관리 프로세스를 사용하는 조직보다 제품을 더 빠르게 혁신하고 개선
• 빠른 속도를 통해 고객을 더 잘 지원하고 시장에서 좀 더 효과적으로 경쟁

- 고객 서비스를 365일 24시간 내내 제공해야 하는 IT 조직에서 도입하고 있는 소프트웨어 시스템의 개발 및 운영 전략 (아마존, 구글, 넷플릭스 등)

- 개발팀과 운영팀이 병합 : 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명 주기에 걸쳐 작업하고 단일 기능에 한정되지 않은 광범위한 기술을 개발

- DevOps의 핵심 : 애자일 개발과 지속적인 통합

• 하나의 새로운 소프트웨어 기능, 개선 요청 또는 버그 수정 등이 사용자에게 가치를 제공할 수 있도록 운영 환경에서 개발, 배포로 진행되는 프로세스의 속도를 높이는 접근 방식을 의미
• 장점 : 속도, 신속한 제공, 안정성, 확장, 협업 강화, 보안

- DevOps 방식

• 지속적 통합, 지속적 배포
• 마이크로 서비스
• 코드형 인프라 : 인프라를 프로비저닝하고 관리하는 방식
• 모니터링 및 로깅
• 커뮤니케이션 및 협업

- DevOps 프로세스 실현을 위해 자동화는 필수 ➡️ DevOps Toolchain