소프트웨어 개발 프로세스

2025. 1. 23. 12:39기반기술/SW공학

소프트웨어 개발 프로세스

기본 용어 정의

  • 프로그램 : 컴퓨터 명령어가 나열된 원시 코드(source code)
  • 소프트웨어 : 컴퓨터에서 실행되는 모든 종류의 프로그램을 포함하는 넓은 개념이다. 하드웨어와 대조되는 개념으로, 물리적 장치가 아닌 데이터와 프로그램의 집합을 의미한다.
  • 시스템 소프트웨어 (System Software) : 운영 체제(OS)와 유틸리티 프로그램을 뜻한다. 하드웨어와 애플리케이션 소프트웨어 간의 중개 역할을 한다. (ex. 윈도우, 리눅스, macOS, 안티바이러스 소프트웨어, 디스크 관리 도구)
  • 응용 소프트웨어 (Application Software) : 특정 사용자 작업을 수행하기 위한 소프트웨어를 뜻한다. (ex: 워드 프로세서, 스프레드시트, 웹 브라우저, 게임, 메신저 등) 프로세스 : 주어진 일을 해결하기 위해 순서가 정해져 수행되는 일련의 절차를 뜻한다. (ex: 요리 과정, 제품생산 과정, 다리나 건물의 건축 과정 등)

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

  • 소프트웨어를 개발하기 위한 일련의 단계적 절차
  • 요구사항 수집, 설계, 구현, 테스팅, 배포, 유지보수에 이르는 소프트웨어 생명주기 전체를 포괄하는 것을 말한다.
  • 좁은 의미로는, 사용자의 요구사항을 SW 시스템으로 구현하기 위한 일련의 활동(절차, 과정, 구조)
  • 넓은 의미로는, SW개발 목적을 이루는데 필요한 모든 수단(좁은 의미 + 방법, 도구, 참여자)

 

프로세스의 3요소

 

 

필요성 

  •  대규모 소프트웨어를 개발할 때의 어려움
    • 개발 과정이 복잡하다.
    • 참여 인력이 많다. (feat. 중간에 이직 및 새로운 인력 충원)
    • 개발 기간이 길다. (feat. 진행상황 파악이 어렵고 개발 비용 산정도 어려움)
  • 이를 해결하기 위해 필요한 것 -> 소프트웨어 개발 프로세스 
    • 개발의 복잡성을 줄이기 위한 방법과 기술
    • 개발에 참여하는 팀을 구성하고 관리하는 효율적인 방법
    • 프로젝트를 효율적으로 관리하기 위한 체계

 

소프트웨어 프로세스 모델


정의

  • 소프트웨어 프로세스 모델은 개발 계획 수립부터 최종 폐기 까지의 전과정을 다루며 이러한 소프트웨어 개발 생명주기(Software Development Life Cycle)에 따라 어떻게 개발할 것인지 전체적인 흐름을 체계화한 개념이다.
  • 요구사항 → 설계 → 구현 → 테스트 → 문서로 정리
  • 요구사항을 분석하고 요구사항대로 소프트웨어를 구현하는 방법 및 논리를 정리하는 설계를 거쳐 실제로 개발하는 구현, 이를 테스트하고 문서로 정리하는 단계로 순차적인 단계로 진행하는 것을 말한다.

목적

  • 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의
  • 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
  • 고품질의 소프트웨어 제품 생산을 목적으로 함  

역할 

  • 일정 계획 수립 용이
  • 개발 진행 상황을 명확히 파악할 수 있음
  • 전체적인 기본 골격을 세워줌
  • 개발 비용 산정 뿐 아니라 여러 자원을 산정하고 분배할 수 있음
  • 용어의 표준화를 통해 참여자 간에 의사소통의 기준을 정할 수 있음(유비쿼터스 언어)
  • 각 단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있음

 

종류

  1. 선형 순차적 모델 (폭포수, Waterfall)
    • 전통적인 소프트웨어 개발 방법론. 각 단계가 순차적으로 진행됨. 한 단계가 끝나면 다음 단계로 넘어가고, 뒤로 돌아갈 수 없음.
    • 단계: 요구사항 분석 > 시스템 설계 > 구현 > 테스트 > 배포 > 유지보수
    • 장점
      • 계획이 명확하고 구조적이라 프로젝트 관리가 쉽다.
      • 각 단계가 분명하게 구분되어 있어 진행 상황을 측정하기 용이.
      • 요구사항이 확실한 프로젝트에 적합.
    • 단점
      • 요구사항이 변할 때 유연하게 대응하기 어려움.
      • 각 단계가 끝나고 나면 이전 단계로 돌아가기 힘듦.
      • 테스트와 수정이 후반부에 이루어져 초기 단계에서 문제가 발견되기 어려움.
  2. 애자일(Agile) 모델
    • 반복적이고 점진적인 개발 방법론. 소프트웨어를 작은 단위로 나누어 주기적으로 개발하고, 피드백을 통해 지속적으로 개선한다.
    • 주요 특징
      • 스프린트(Sprint): 개발을 짧은 주기의 반복으로 나누어 진행.
      • 고객과의 협업: 개발 중에 고객과 긴밀하게 협업하며 요구사항을 지속적으로 조정.
      • 유연성: 요구사항의 변경을 유연하게 반영.
    • 장점
      • 요구사항의 변경에 유연하게 대응 가능.
      • 빠른 피드백을 통해 품질을 개선하고 문제를 일찍 발견할 수 있음.
      • 개발 과정에서 고객과의 협업을 통해 제품이 실제 요구에 맞춰짐.
    • 단점
      • 초기 계획이 명확하지 않아 일정 관리가 어려울 수 있음.
      • 반복적인 개발 과정에서 자원이 많이 소모될 수 있음.
      • 문서화가 부족할 수 있어 후속 작업이나 관리가 힘들 수 있음.
    • 핵심 차이점
      • 폭포수는 "단계별 순차 진행" 모델이라 한 번 시작하면 끝까지 그 과정을 고수해야 하는 반면, 애자일은 "반복적이고 유연한 개발" 모델이라 중간에 요구사항을 바꿀 수 있고 점진적으로 개선하면서 개발한다.
      • 폭포수는 큰 계획과 구조를 필요로 하는 프로젝트에 적합하고, 애자일은 빠르게 변하는 요구나, 피드백을 자주 받고 개선해야 하는 프로젝트에 적합하다.
      • 프로젝트의 특성, 팀의 구조, 목표, 그리고 조직의 문화에 맞게 선택하는 것이 좋다.
  3. 스크럼 
    • 정의
      • 애자일 개발의 한 형태로 팀이 정해진 기간(스프린트)동안 목표를 달성하기 위해 협력하는 프레임워크이다
      • 계획, 검토, 일일 스탠드업 미팅 등 정기적인 회의를 통해 프로젝트 진행 상황을 관리한다.
      • 개발 팀을 운영하는 효율적인 운영 방식으로 소프트웨어 개발 보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론이다.
    •  스크럼 진행 시 역할
      • 제품 책임자(Product Owner): 제품 기능 목록을 만들고 비즈니스 관점에서 우선순위와 중요도를 매겨 스프린트 계획 수립 시까지만 역할을 수행하고 스프린트가 시작되면 팀 운영에 관여하지 않는다.
      • 스크럼 마스터(Scrum Master): 제품 책임자를 돕고 스크럼 팀이 스스로 조직하고 관리하도록 지원하며 개발 과정에 방해될 만한 요소를 찾아 제거한다.
      • 스크럼 팀(Scrum Team): 팀원은 보통 5~9명으로 구성되며 사용자 요구사항에서 사용자 스토리를 도출하고 이를 구현한다. 기능을 작업 단위로 나누고 일정이나 속도를 추정해서 제품 책임자에게 알려주며 매일 스크럼 회의에 참여하여 진척 상황을 점검하고 스프린트에서 생산된 결과물을 제품 책임자에게 시연한다.  
    • 주요 용어
      • 스프린트 구현 목록(Sprint Backlog) : 각각의 스프린트 주기에 개발할 작업 목록으로 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성해야 한다.
      • 일일 스크럼 회의(Daily Scrum Meeting) : 매일, 서서, 짧게(15분 정도) 진행하며 진행 상황만 점검하고 스프린트 작업 목록을 잘 개발하고 있는지 확인한다. 모든 팀원이 한 사람씩 어제 한 일을 얘기하고(개별 팀원에 대한 진척 상태 확인) 오늘 할 일과 문제점 및 어려운 점 정도를 얘기하며 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트 한다.
      • 스프린트 회고(Sprint Retrospective) : 스프린트에서 수행한 활동과 개발한 것을 되돌아보고 개선점은 없는지 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토한다. 문제점을 확인하고 기록하며 프로세스 품질은 측정하지 않는다.
      • 스프린트 검토회의(Sprint Review) : 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토하고 비즈니스 가치를 점검
      • 사용자 스토리(User Story)와 스토리 포인트(Story Point) : 사용자 스토리는 메모지 한 장에 구현할 기능을 사용자 관점에서 사용자의 언어로 작성한 사용자 요구사항으로 유스케이스보다 작은 단위로 작성하며 테스트가 가능해야 좋다. 스토리 포인트는 사용자 스토리를 수행하는데 걸리는 개발 기간(시간)
    • 장점
      • 팀 구성원 간의 높은 수준의 협력과 의사소통을 촉진한다.
      • 빠른 피드백 루프를 통해 제품을 지속적으로 개선할 수 있다. 
      • 복잡한 프로젝트를 더 효과적으로 관리할 수 있다.
    • 단점 
      • 스크럼의 성공은 팀 구성원의 경험과 자기 조직화 능력에 크게 의존한다.
      • 일정한 규모 이상의 대규모 프로젝트에는 적용하기 어려울 수 있다.
      • 엄격한 일정과 빈번한 회의로 인해 일부 팀원이 스트레스를 받을 수 있다.