Madison Digital Garden

Search

SearchSearch

01. 소프트웨어 프로세스

Jan 05, 2025, 20 min read

충남대학교 컴퓨터공학과 김현수 교수님의 "소프트웨어 공학" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

소프트웨어 개발 프로세스란

  • 하나의 소프트웨어를 개발하는 과정
  • 무엇을 해야 하는가 / 어떤 순서로 작업할 것인가를 결정하는데 도움이 되어야 함
    • 말 그대로 도움이 되어야 함 - 모델들은 엄격하게 규정되기 보다는 지금 그리고 그 다음에 뭘 해야하는지는 생각하는데 도움이 되도록 구성되어 있다
  • 각 프로젝트마다 성격이 다르므로 고유의 계획이 있어야 한다

즉흥적인 개발 프로세스의 문제점

  • 설계가 제대로 안되어 품질이 떨어짐
  • 계획이 없어 목표없이 일하게 됨 - 하나를 다 하고 나면 그 다음에 뭘 해야될지 모른다
  • 테스트, 품질보증 등이 제대로 이루어지지 않음
  • 위와 같은 이유로 개발과 유지보수 비용이 증가함

Waterfall Model (Phased Model)

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image1.png

  1. Requirements gathering and definition - 요구사항 수집과 정의
  2. Specification - 명세
    • 위 두 과정은 약간 블로그나 책마다 다르게 설명되어 있는데 대략 타당성 조사(비용 대비 이익이 얼마나 되는가, 주어진 시간 내에 우리가 가진 기술력으로 해결이 가능한가 등)와 요구사항 수집과 명세(문서화)정도로 이해하면 된다
  3. Design - 디자인
    • 여기서의 디자인은 외적인 디자인 말고도 시스템 전체에 대한 설계 등의 과정도 포함된다
  4. Implementation - 구현
  5. Integrate & Deploy - production build + deploy 같은 느낌
  6. Maintenance - 유지보수

특징

  • 현재의 단계가 끝나야 다음단계로 넘어가는 순차적인 구조로 진행된다
  • 각 단계의 구분이 명확해 중복되는 작업이 이루어지지 않는다
  • 그리고 각 단계가 시작되기 전에 전단계의 결과에 대해 점검하고 문서화 작업이 이루어진다
  • 만일 문제점이 발견되면 바로 전 단계로 피드백을 주게 된다

장점

  • 요구사항의 변경이 한정된 상황에서 유용
  • 대규모 시스템 공학 프로젝트에서 많이 쓰임(대표적으로 국방관련 프로젝트)

단점

  • 요구사항이 변경되었을 경우 대처하기가 힘들다
  • 초기 단계(요구사항 분석과 설계 등)에서 잘못하면 미래가 어둡기 때문에 초기 단계가 중요한데 초기단계에서 힘을 너무 빼버리면 구현이나 테스트 등의 뒷 단계가 지연된다
  • 단계가 전환될때 많은 노력이 필요하다
  • 한번에 모든걸 끝내고하 하는 성격의 모델이기 때문에 프로토타입을 만들어볼 기회가 적다
  • 앞으로의 단계에서 무슨일이 일어날지 모르기 때문에 갖가지 문서를 만들게 되는데 이 과정에서 쓸데없는 문서를 생산해낼 가능성이 있다

Prototype Model

프로토타입의 종류

  • 실험적 프로토타입
    1. 인간 - 기계 상호작용 프로토타입 : 뭐 ppt같은걸로 ui같은거 그려서 시나리오 짜보고 그런 경험 있제? 그런걸 말하는거다
    2. Working prototype : 프로젝트의 가장 핵심적인 부분만 구현하여 프로토타입을 만들어보는 것
    3. Throw-away prototype : 요구사항을 이해하기 위해 만들어서 버릴 생각으로 간단하게 만들어보는 것
  • 점진적 프로토타입
    1. 개선을 목표로 요구되는 기능의 일부 또는 전체를 러프하게 만들어보는 것

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image2.png

  1. System analysis - 시스템 분석
  2. Requirement definition / design - 요구사항 분석 및 소프트웨어 설계
  3. Prototype Development / Refinement - 프로토타입 구현과 코드 정리
  4. Prototype Evaluation : 프로토타입 테스트(평가)
    • 위의 네 단계가 이루어지고 프로토타입 평가 결과에 따라 1, 2, 3번의 과정을 다시 수행하여 평가가 통과할때까지 프로토타입을 만든다
  5. Full-scale implementation - 프로토타입이 다 완성되었으면 정식 버전을 구현한다

Incremental Model

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image3.png

  • 우선 이전의 모델들처럼 요구사항 분석, 명세 등의 과정을 다 끝낸다
  • 그리고 구현할때 한번에 모든 기능을 구현하는 것이 아닌 기능별로 구현해서 여러번 배포할 목표로 계획을 하고 계획에 따라 구현, 배포한다 - 이게 핵심!
    • 즉 바로 요구사항 분석 등의 과정이 끝난 후에 바로 소프트웨어 설계를 하는 것이 아닌 배포 계획을 세우고 각 배포 단계에 선행하여 설계를 하게 되는 것
  • 각 배포 단계마다 설계, 구현, 테스트, 배포가 이루어진다

배포 구성 방법

  • 점증적 방법 - 전체 시스템을 기능별로 쪼개어 그 기능이 구현될때마다 배포하는 방법
  • 반복적 방법 - 기능을 다 구현한 다음 배포 하고 배포할때마다 기능들의 완성도를 높이는 방법

장점

  1. 빠른 시간 안에 시장에 출시해야 할 경우 강점을 가진다
    • 시장에 처음으로 나온 소프트웨어의 경우 인지도 형성과 시장 점유에서 강점을 가지기 때문
  2. 자주 릴리즈를 하면 서비스 중일때 일어날 수 있는 문제를 빨리 파악하고 해결할 수 있다
  3. 기능별로 쪼개어 릴리즈를 하는 경우 개발팀이 각 배포 단계마다 하나의 기능에만 집중할 수 있기 때문에 기능의 완성도가 높아질 수 있다

Spiral Model

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image4.png

  • 1사분면이 요구사항 분석 등의 과정(Planning - 목표, 기능선택, 제약조건의 결정)
  • 2사분면이 위험분석, 프로토타입 생성(Risk analysis - 기능선택의 우선순위, 위험요소의 분석) - 여기가 핵심!
  • 4사분면이 구현 및 테스트(Engineering - 선택된 기능의 개발)
  • 3사분면이 다음 단계 계획(Evaluation - 개발 결과의 평가)
  • 이렇게 구성되어 있고 저렇게 빙글빙글 돌면서 반복한다는 컨셉인듯
  • 이것도 반복적으로 배포하게 됨
  • 점진적으로 반복해서 배포한다는 것은 다른 모델들과 비슷하나 위험부담을 최소화하기 위해 리스크 분석 단계가 존재하는 것이 나선형 모델의 가장 큰 특징인 듯 하다

장점

  1. 대규모 시스템 개발에 적합
  2. 리스트 분석을 매번 하기 때문에 리스크를 줄일 수 있다
  3. 반복적인 개발 및 테스트가 이루어진다

단점

  1. 관리가 중요
  2. 위험 분석이 중요

Evolutionary Model

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image5.png

  • 위의 그림처럼 하나 구현할때마다 설계 구현 시험 설치 운영을 거친다더라
  • Incremental Model과의 차이점은 Incremental Model의 경우에는 요구사항 분석등의 과정을 처음에 한번만 하고 그것을 토대로 앞으로의 계획을 짜서 여러번 배포하는 것이라면
  • Evolutionary Model은 매번 그것을 반복한다
  • 아래의 UP 를 예시로 보면 이해하기 쉬움 이게 뭔지

UP (Unified Process)

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image6.png

  • 위의 그림을 어떻게 이해하면 되냐면
  • 다음의 4단계가 하나의 사이클이라고 보면 된다
    • Inception(도입 단계) : 프로젝트의 범위를 설정하고 목표를 명확하게 함
    • Elaboration(정련 단계) : 시스템의 중요한 요구를 찾아내어 기본이 되는 설계를 완성
    • Construction(구축 단계) : 원시코드가 완성되고 중요한 요구의 테스트를 하는 것
    • Transition(전환 단계) : 사용자에게 릴리즈
  • 근데 다른 모델들과의 차이점은 Inception 단계라고 해서 계획만 하는 것은 아니라는 거다
    • 세로축에 있는 Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment의 작업을 각 단계마다 수행하게 되는 것
  • 하지만 각 단계마다 집중하는 비율은 당연히 달라지고 그 비율을 나타낸 것이 위의 그래프인 것
    • 보면 Inception단계에서는 Business Modeling과 Requirements의 비중이 높은 것을 알 수 있고
    • Construction에서는 Implementation의 비율이 높은 것을 알 수 있다
  • 즉, 다른 모델들은 각 단계마다 한가지의 일만을 하는 반면 UP에서는 비중만 달라질 뿐 모든 일을 골고루 처리한다는 차이점이 존재한다

Agile Model

  • Agile [형용사] : 빠른, 기민한, 날렵한, 민첩한

특징

  1. 설계가 변경되어도 쉽게 수용이 가능하도록 계획부터 배포까지의 사이클을 짧게 가져가는 것
    • 점증적 설계 : 설계를 하되 나중에 충분히 개선될 여지가 있다는 것을 염두해 두고 설계에 대한 결정을 최대한 미루는 것
    • 약 4-5주의 사이클로 계획 ~ 배포가 이루어진다
  2. 사용자를 팀에 아예 참여시켜 지속적으로 피드백을 받음
  3. 필요한 문서만 최소한으로 작성하고 대부분 소스코드로 대체, 커뮤니케이션도 문서를 통하기보다는 대화를 통해 해결
  4. 대규모의 프로젝트의 경우에는 설계가 자주 변경되는 것이 좋지 않으므로 소규모 프로젝트를 진행할때 적합하다
    • 소규모의 프로젝트 같은 경우에는 설계가 자주 바뀌어도 품질에 크게 영향을 끼치지 않기 때문

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image7.png

  • 위처럼 요구사항 수립을 한 후에 지속적으로 개발 & 통합 & 테스트를 이어나가다가
  • 고객에게 피드백을 받고 배포할지말지를 결정
  • 빠꾸먹으면 왜 빠꾸먹었는지 등을 정리해놓고 다시 개발 & 통합 & 테스트 & 피드백
  • 빠꾸 안먹어도 배포 후에 계속 요구사항을 정리해서 개발 & 통합 & 테스트 & 피드백

XP : eXtreme Programming

  • 최초의 애자일 프로세스랜다
  • Metaphor : 프로젝트에 사용할 아키텍처를 설계하는 것이 아닌 기존의 서비스 중 유사한 것의 아키텍처를 차용함
  • 불필요하게 복잡한부분은 제거해서 설계
  • TDD를 중심적으로 개발 프로세스가 돌아감
  • Refactoring : 동일한 동작을 하되 더 간결하고 깔끔하게 시스템을 재구성
  • 주당 40시간의 개발속도로 진행
  • 코딩 컨벤션을 정해 동일한 규칙을 적용

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image8.png

  1. Exploration : User story - 즉, 사용자의 니즈를 잘게 나누고 해당 니즈와 관련된 정보들을 모음.
    • Capture stories in parking lot - 사무실에 앉아서 니즈를 알아내려고 하지 말고 엉뚱한데를 뒤져보라는 것.
    • Architectural spikes : 어떤 user story에 대해 이것을 왜 해결해야 하는지 등의 신뢰성 혹은 기술적인 부분에서 문제가 없는지 등을 확인하기 위해 작성하는 간단한 프로그램
  2. Iteration planning : 각 user story들에 대해 개발 사이클인 iteration이 얼마나 걸릴지를 예상. + 비용도 예상
  3. Iteration : Pair programming : 하나의 컴퓨터를 공유하고 개발과 테스팅을 분리하여 진행 + 지속적으로 개발의 결과를 통합시킴
    • 개발 + 테스팅 이후에는 기존의 코드들과 연동이 잘 되는지 regression test를 진행함
    • 그리고 iteration의 중간에 mid iteration review, iteration의 끝에 end of iteration review를 진행함
  4. Acceptance tests : 릴리즈 전에 고객한테 피드백을 받음
  5. Small release : 고객이 ㅇㅋ하면 소규모의 배포를 진행

Scrum

과정

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image9.png

  1. Product backlog : 고객이나 팀 임원진 등등의 사람들에게 요구사항을 물어봐서 정리함
  2. Sprint planning meeting : Product backlog 중에 어떤 것들을 이번 Sprint(iteration마냥 한 사이클)때 해결할 것인지를 결정함. 그리고 그것들에 대해 시간이 얼마나 걸릴지, 비용은 얼마나 필요할지 등을 산출함
  3. Sprint : 1주에서 4주정도의 기간 동안 회의때 결정한 내용들을 개발하고 테스트함. Daily scrum meeting을 통해 매일 15분 정도 얼마나 진도가 나갔는지, 이슈는 없는지 등을 논의함
  4. Sprint review : 스프린트 후 산출된 결과에 대해 리뷰함
  5. Sprint Retrospective : 스프린트 과정에 대해 변경할 부분은 없는지, 문제는 없었는지 등을 회고함

프로세스 모델 선정

  • 참고해라

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image10.png

Model과 관계없이 해야되는 작업들

Specification

  • Feasibility study : 타당성 조사. 비용 대비 이익이 얼마나 되는가, 주어진 시간 내에 우리가 가진 기술력으로 해결이 가능한가 등 - Feasibility report의 문서가 나오게 됨
  • Requirements elicitation and analysis : 요구사항 도출 및 분석
  • Specification : 명세. 문서화
  • Validation : 검증 - Requirement validation의 문서가 나오게 됨

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image11.png

  • 뭐 대충 이렇댄다

Design & Implementation

  • Specification으로 실행가능한 프로그램을 만드는 과정
  • Design : 설계
    • Architectural design : 프로그램이 돌아갈 OS등의 아키텍처를 고려해 설계
    • Interface design : UI등의 인터페이스를 설계함
    • Component design : 프로그램을 구성하는 클래스 등의 구성요소 들을 설계함 (Component는 기능이나 객체 혹은 이들의 그룹을 의미함)
    • Data structure design : DB또는 자료구조들을 설계
    • Algorithm design : 프로그램이 돌아가는 알고리즘을 설계

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image12.png

  • 이렇댄다

Verification & Validation (V & V)

  • 작성한 프로그램이 명세와 요구사항을 충족하는 것을 보여주기 위한 과정
  • Component or unit testing : unit testing을 진행
  • System testing : 프로그램 전체 테스트 - 명세에서 유도된 테스트 케이스들을 가지고 시스템 전체를 테스트함
  • Acceptance testing : 시스템이 고객의 요구를 충족하는지 확인하기 위해 고객의 데이터를 이용해 테스트

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image13.png

  • 이건 좀 잘 봐야됨
    • 일단 위엣줄이 Specification과 Design을 진행하는 과정임
    • 그리고 이 Spec과 design을 가지고 개발을 진행함(맨 오른쪽)
    • 맨 아랫줄이 Specification과 Design을 진행하는 과정에서 산출된 테스트를 가지고 테스트를 진행하는 과정이다
    • 위 그림만 보면 >이지만 어쨋든 V형태를 띈다고 해서 V-Model이라고 부르더라

Evolution

%E1%84%8B%E1%85%B5%E1%84%85%E1%85%A9%E1%86%AB02%20-%20%E1%84%89%E1%85%A9%E1%84%91%E1%85%B3%E1%84%90%E1%85%B3%E1%84%8B%E1%85%B0%E1%84%8B%E1%85%A5%20%E1%84%91%E1%85%B3%E1%84%85%E1%85%A9%E1%84%89%E1%85%A6%E1%84%89%E1%85%B3%2096375d189c39451d93f318a757a7d1a9/image14.png

  • 유지보수 과정이라 생각하면 될듯

Graph View

Backlinks