[CS] 소프트웨어 개발 프로세스

1. 소프트웨어 개발 프로세스의 정의

• 기본 용어 정의
  • 프로그램:  
    
    • 컴퓨터 명령어가 나열된 원시코드
  • 애플리케이션
    • 컴퓨터의 OS 위에서 동작하는 컴퓨터 프로그램
  • 소프트웨어
    • 저장장치에 저장된 특정한 목적과 기능을 수행하도록 만들어진 프로그램
  • 프로세스
    • 주어진 일을 해결하기 위해 순서가 정해져 수행되는 일련의 절차
• 소프트웨어 개발 프로세스란?
  • 좁게는 사용자의 요구사항을 SW 시스템으로 구현하기 위한 일련의 활동(절차, 과정, 구조)
  • 넓게는 SW개발 목적을 이루는데 필요한 모든 수단(절차, 구조, 도구, 참여자)
  • 소프트웨어를 개발하기 위한 단계적 절차를 말하며, 소프트웨어 생명주기 전체를 포괄함

2. 소프트웨어 프로세스 모델의 정의와 예시

• 소프트웨어 프로세스 모델의 정의
  • 순서
  • 💡 요구사항 → 설계 → 구현 → 테스트 → 문서
• 소프트웨어 프로세스 모델은 소프트웨어 개발 생명주기(SDLC)에 따라 어떻게 개발할 것인지 전체적인 흐름을 정량화한 개념이다.
• 목적
  • 소프트웨어 개발 전 과정을 하나의 프로세스로 정의
  • 주어진 예산과 자원으로 개발하고 관리하는 방법을 구체적으로 정의
  • 고품질의 소프트웨어 제품 생산을 가능하게 하기 위함
• 역할
  • 일정 계획 수립 용이
  • 개발 진행 상황을 명확히 파악할 수 있음
  • 전체적인 기본 골격을 세워줌
  • 개발 비용 산정 뿐 아니라 전체적인 자원 산정, 분배 가능
  • 용어의 표준화를 통해 참여자 간에 의사소통의 기준을 정할 수 있음( 👍🏽)
  • 각 단계별로 생성되는 문서를 포함한 산출물을 활용하여 검토할 수 있음
• 예시
  • 워터폴
    • 정의 : 전통적인 접근 방식이며, 이름과 같이 선형적으로 진행되며, 이전 단계가 완료되어야만 넘어갈 수 있다.
    • 장점:
      1. 구조가 명확하고 이해하기 쉽다
      2. 각 단계의 명확한 구분으로 문서화가 잘 된다.
      3. 큰 규모의 프로젝트나 변경이 거의 없는 프로젝트에 적합하다.
    • 단점:
      1. 변화에 대응하기 어렵고 유연성이 부족하다.
      2. 사용자 피드백을 개발 과정 후반에야 받을 수 있어, 초기 설계 오류의 수정이 어렵다.
      3. 프로젝트 초기 단계에서 정확한 요구사항을 파악해야 하는데 이는 쉽지 않다.
  • 애자일 방법론
    • 정의 : 변화에 유연하게 대응 및 고객의 지속적인 피드백을 수용하는 반복적인 개발 접근 방식, 스프린트를 통해 지속적으로 제품을 개선한다. 
    • 장점:
      1. 빠르게 변화하는 요구 사항에 유연하게 대응할 수 있다.
      2. 정기적인 피드백을 통해 고객의 요구사항을 더 잘 반영할 수 있다.
      3. 팀원 간의 긴밀한 협력과 의사소통이 장려된다.
    • 단점:
      1. 프로젝트의 규모가 커지면 관리가 복잡해질 수 있다.
      2. 문서화가 충분히 이루어지지 않을 수 있어, 프로젝트에 대한 이해도가 낮은 새로운 팀원의 참여가 어려울 수 있다.
      3. 초기에 최종 비용과 시간을 추정하기 어려울 수 있다.
  • 스크럼(애자일 방법론의 방식 중 하나)

 
    - 정의

        애자일 개발의 한 형태로 팀이 정해진 기간(스프린트)동안 목표를 달성하기 위해 협력하는 프레임워크이다.
        계획, 검토, 일일 스탠드업 미팅 등 정기적인 회의를 통해 프로젝트 진행 상황을 관리한다.
        개발 팀을 운영하는 효율적인 운영 방식으로 소프트웨어 개발 보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론이다.

        스크럼 진행 시 역할
        **1. 제품 책임자(Product Owner):** 제품 기능 목록을 만들고 비즈니스 관점에서 우선순위와 중요도를 매겨 스프린트 계획 수립 시까지만 역할을 수행하고 스프린트가 시작되면 팀 운영에 관여하지 않는다.

        **2. 스크럼 마스터(Scrum Master):** 제품 책임자를 돕고 스크럼 팀이 스스로 조직하고 관리하도록 지원하며 개발 과정에 방해될 만한 요소를 찾아 제거한다.

        **3. 스크럼 팀(Scrum Team):** 팀원은 보통 5~9명으로 구성되며 사용자 요구사항에서 사용자 스토리를 도출하고 이를 구현한다. 기능을 작업 단위로 나누고 일정이나 속도를 추정해서 제품 책임자에게 알려주며 매일 스크럼 회의에 참여하여 진척 상황을 점검하고 스프린트에서 생산된 결과물을 제품 책임자에게 시연한다.

    - 스크럼 생명선

        > **스프린트 구현 목록(Sprint Backlog)
        :** 각각의 스프린트 주기에 개발할 작업 목록으로 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성해야 한다.

        **사용자 스토리(User Story)와 스토리 포인트(Story Point)**
        : 사용자 스토리는 메모지 한 장에 구현할 기능을 사용자 관점에서 사용자의 언어로 작성한 사용자 요구사항으로 유스케이스보다 작은 단위로 작성하며 테스트가 가능해야 좋다.
        스토리 포인트는 사용자 스토리를 수행하는데 걸리는 개발 기간(시간)

        **일일 스크럼 회의(Daily Scrum Meeting)**
        : 매일, 서서, 짧게(15분 정도) 진행하며 진행 상황만 점검하고 스프린트 작업 목록을 잘 개발하고 있는지 확인한다. 모든 팀원이 한 사람씩 어제 한 일을 얘기하고(개별 팀원에 대한 진척 상태 확인) 오늘 할 일과 문제점 및 어려운 점 정도를 얘기하며 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트 한다.

        **스프린트 검토회의(Sprint Review)**
        : 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토하고 비즈니스 가치를 점검

        **스프린트 회고(Sprint Restrospective)**
        : 스프린트에서 수행한 활동과 개발한 것을 되돌아보고 개선점은 없는지 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토한다.
        문제점을 확인하고 기록하며 프로세스 품질은 측정하지 않는다.
        > 

    - 장점

        1. 팀 구성원 간의 높은 수준의 협력과 의사소통을 촉진한다.
        2. 빠른 피드백 루프를 통해 제품을 지속적으로 개선할 수 있다.
        3. 복잡한 프로젝트를 더 효과적으로 관리할 수 있다.

    - 단점

        1. 스크럼의 성공은 팀 구성원의 경험과 자기 조직화 능력에 크게 의존한다.
        2. 일정한 규모 이상의 대규모 프로젝트에는 적용하기 어려울 수 있다.
        3. 엄격한 일정과 빈번한 회의로 인해 일부 팀원이 스트레스를 받을 수 있다.

워터폴 | 애자일(기민, 민첩) 비교표

추가 요구 사항의 수용	추가 요구사항을 반영하기 어려운 구조	추가 요구 사항을 수용할 수 있는 방법의 설계
릴리즈 시점	최종 완성된 제품을 릴리즈	수시로 릴리즈
시작 상태	시작 단계에서의 완성도가 매우 높음	시작 단계는 미흡, 점차 완성도가 높아짐
고객과의 의사소통	사용자와 산출물의 근거 중심, 대화 부족	처음부터 사용자의 참여 유도, 대화를 통한 개발 진행
진행 상황 점검	단계별 산출물에 대한 결과로 개발의 진척 상황을 점검	개발자와 사용자는 개발 초기부터 진행 상황 공유
분석/설계/구현 진행 과정	분석/설계/구현 과정이 명확	하나의 단계 또는 반복 안에 분석/설계/구현 과정이 모두 포함되어 동시에 진행
모듈(컴포넌트)통합	구현이 완료된 후에 모듈 간의 통합 작업을 수행	개발 초기부터 빈번한 통함, 문제점을 빨리 발견하고 수정하는 방식