2025.05.01

RestFul API 개발

소프트웨어 개발 프로세스

소프트웨어 개발 프로세스

소프트웨어를 개발하기 위한 일련의 단계적 절차

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

프로세스의 3요소

소프트웨어 개발 프로세스의 필요성

무언가를 만들 때 간단한 문제는 머릿 속 구상으로만으로 짧은 시간 안에 할 수 있다.
하지만 대규모 인원이 개발하는 큰 프로젝트와 같은 경우는 많이 어려움이 따른다.

• 개발 과정 복잡, 참여 인력이 많은 경우, 개발 기간이 긴 경우
• 개발의 복잡성 줄이기 위한 방법과 기술 필요
• 개발에 참여하는 팀 구성 및 관리하는 효율적인 방법 필요
• 프로젝트를 효율적으로 관리하기 위한 시스템 체계 필요

주요 소프트웨어 프로세스 모델

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

소프트웨어 프로세스 모델의 목적

• 소프트웨어 프로세스 모델의 목적 및 역할
• 주어진 예산과 자원으로 개발을 하고 관리하는 방법을 구체적으로 정의 -> 트레이드 오프
• 소프트웨어 개발의 전 과정을 하나의 프로세스로 정의

소프트웨어 프로세스 모델의 역할

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

선형 순차적 모델(워터풀)

각 개발 단계(요구 사항 분석, 시스템 설계, 구현, 테스팅, 배포 및 유지보수)가 선형적으로 진행되며, 이전 단계가 완료된 후에만 다음 단계로 넘어간다

• 구조가 명확하고 이해하기 쉽다
• 구조가 명확하고 이해하기 쉽다
• 큰 규모의 프로젝트나 변경이 거의 없는 프로젝트에 적합
• 변화에 대응하기 어렵고 유연성이 부족
• 사용자 피드백을 개발 과정 후반에야 받을 수 있어, 초기 설계 오류의 수정이 어렵다
• 프로젝트 초기 단계에서 정확한 요구사항을 파악해야 하는데 이는 쉽지 않다

애자일 프로세스 모델(애자일 방법론)

변화에 유연하게 대응하고 고객의 지속적인 피드백을 수용하는 반복적이고 점진적인 개발 방식

• 짧은 개발 사이클(스프린트) 을 통해 지속적으로 제품을 개선
• 스프린트(sprint) : 일정 기간 동안 전력질주하듯 집중적으로 개발 작업을 수행하는 단위
• 빠르게 변화하는 요구 사항에 유연하게 대응
• 정기적인 피드백을 통해 고객의 요구사항을 더 잘 반영
• 팀원 간의 긴밀한 협력과 의사소통이 장려

단점

• 프로젝트의 규모가 커지면 관리가 복잡
• 문서화가 충분히 이루어지지 않을 수 있어 프로젝트에 대한 이해도가 낮은 새로운 팀원의 참여가 어려울 수 있다.
• 초기에 최종 비용과 시간을 추정하기 어려울 수 있다

스크럼 (Scrum)

애자일 방법론의 한 프레임워크로, 팀이 정해진 기간(스프린트) 동안 목표를 향해 집중적으로 협업

• 계획, 검토 , 일일 스탠드업 미팅 등 정기적인 회의를 통해 프로젝트 진행 상황을 관리
• 개발 팀을 운영하는 효율적인 운영 방식, 소프트웨어 개발 보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론

역할

• 제품 책임자(Product Owner) :
  제품의 기능 목록(백로그) 만들고 비즈니스 관점에서 우선순위 및 중요도 매겨 스프린트 계획 수립 시까지만 역할 수행
• 스크럼 마스터(Scrum Master) :
  제품 책임자를 돕고 스크럼 팀이 스스로 조직하고 관리하도록 지원하며 개발 과정에 방해요소 제거
• 스크럼 팀(Scrum Team) :
  팀원은 보통 5~9명으로 구성,
  사용자 요구사항에서 사용자 스토리를 도출하고 이를 구현,
  기능을 작업 단위로 나누고 일정이나 속도를 추정해서 제품 책임자에게 알려주며 매일 스크럼 회의에 참여하여 진척 상황을 점검하고 스프린트에서 생산된 결과물을 제품 책임자에게 시연

핵심 개념

• 스프린트 구현 목록 (spring backlog) : 특정 스프린트 동안 개발할 작업 목록 (세부 작업 항목, 담당자, 예상 소요 시간 등 포함)
• 일일 스크럼 회의 (Daily Scrum Meeting) : 매일 짧게 진행되는 회의로, 각 팀원이 어제 한 일, 오늘 할 일, 어려운 점 등을 공유
• 스프린트 검토회의(Sprint Review) : 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품에 대해 검토하고 비즈니스 가치 점검
• 스프린트 회고(Sprint Retrospective) : 스프린트 종료 후, 스프린트에서 수행한 활동과 개발한 것을 되돌아보고 개선점이 있는지 , 팀이 정한 규칙이나 표준(컨벤션)을 잘 준수 했는 지 등을 검토

장점

• 팀 간 협업 강화 및 빠른 피드백 루프
• 점진적 개선과 빠른 제품 검증 가능
• 복잡한 프로젝트를 작은 단위로 쪼개어 관리 가능

단점

• 스크럼의 성공은 팀 구성원의 경험과 자기 조직화 능력에 크게 의존
• 일정한 규모 이상의 대규모 프로젝트에는 적용하기 어려울 수 있다
• 엄격한 일정과 빈번한 회의로 인해 일부 팀원들이 스트레스
• 대규모 프로젝트에서는 확장성 측면의 어려움이 존재
  

요구사항

사용자 또는 이해관계자가 시스템이나 소프트웨어로부터 기대하는 기능, 서비스 및 조건을 명시하는 것

• 프로젝트의 기초를 형성하며 개발 전반에 걸쳐 중요한 지침 역할
• 프로젝트의 목표를 명확히 하고 , 개발 팀이 무엇을 개발해야 할 지를 구체적으로 안내
• 프로젝트의 범위를 정의하고 이해 관계자 간의 의사소통을 원활하게 하는 것에 중요한 역할

기능적 요구사항(Functional Requirements)

시스템이 수행해야 하는 구체적인 기능들을 명시

비기능적 요구사항(Non-Functional Requirements)

시스템이 어떻게 동작해야 하는 지에 대한 요구사항으로 성능, 보안, 신뢰성 , 사용 편의성을 포함

요구사항 추출 과정

• 인터뷰(Individual Interview) :
  다양한 이해관계자들이 일대일로 진행하는 대화를 통해 그들의 요구사항을 직접 듣고 개별적인 관점과 깊이 있는 정보를 얻을 수 있다.
• 워크숍(Workshop) :
  다양한 이해관계자들이 함께 모여 요구사항에 대해 토론하는 집단적인 활동,
  상호작용이 많은 세션을 통해 다양한 관점을 수렴하고 합의점에 도달
• 설문조사(Survey) :
  특정한 질문에 대한 답변을 통해 많은 수의 사용자로부터 요구사항을 수집하는 방법,
  빠르고 비용 효율적으로 대규모 데이터를 수집

요구사항 분석 절차

• 1. 요구사항 정리 및 분류 :
     추출(수집)된 요구사항을 기능적, 비기능적 요구사항으로 분류, 사용자 스토리 형식으로 정리
     각 사용자 스토리는 “As a [role] , I want [feature], so that [reason] 의 형식
• 2. 요구사항 검토 및 우선순위 결정 :
     사용자 스토리를 기반으로 각 요구사항의 우선순위를 결정, 중요도와 프로젝트 목표에 따라 조정
• 3. 모델링 및 분석: 사용자 스토리를 사용하여 유스케이스, 시퀀스 다이어그램, 활동 다이어그램 등을 생성하며, 요구사항을 더 깊이 분석하고 시스템의 행동을 모델링
• 4. 검증 및 승인: 생성된 사용자 스토리를 이해관계자와 함께 검토하여 명확성과 완전성을 검증하고 승인을 받는다
• 5. 명세서 작성: 승인된 사용자 스토리를 요구사항 명세서에 포함, 이 문서는 개발 및 테스트의 기준.
• 6. 반복 및 정제: 프로젝트의 진행 상황에 따라 사용자 스토리를 계속해서 검토, 필요한 경우 정제하거나 업데이트

요구사항 분석 및 명세서 작성 시 주의 사항

• 명확성 : 모든 이해관계자가 이해할 수 있도록 명확하고 구체적인 언어를 사용한다.
• 완전성 : 모든 필수 요구사항을 포함하며, 누락된 내용이 없어야 한다.
• 일관성 : 문서 내의 정보가 서로 모순되지 않아야 한다.
• 추적 가능성 : 각 요구사항이 원본 출처로 추적될 수 있도록 한다.
• 검증 가능성 : 요구사항이 실제로 검증 가능해야 하며, 측정 가능한 기준을 포함해야 한다.

요구사항 검증

• 리뷰 : 문서화된 요구사항을 이해관계자와 함께 검토하여 정확성, 완전성, 가독성 확인
• 테스트 케이스 : 각 요구사항에 대해 테스트 케이스를 작성, 해당 테스트를 실행하여 요구사항이 충족되는지 검증
• 프로토타입 : 초기 단계에서 요구사항을 기반으로 프로토타입을 제작, 이를 이해관계자에게 제시하여 피드백을 받는다
• 시뮬레이션 : 복잡한 시스템의 경우, 시뮬레이션을 통해 요구사항이 실제 운영 환경에서 어떻게 작동하는지 평가

요구사항 변경 관리

• 변경 요청 프로세스: 모든 변경 요청은 공식적인 프로세스를 통해 제출
• 영향 분석: 제안된 변경이 프로젝트에 미칠 영향 분석
• 변경 승인: 변경 사항에 대한 승인은 이해관계자나 변경 관리 위원회가 담당
• 변경 기록 및 추적: 모든 변경 사항은 문서화 되고 추적 가능해야 한다
• 통신 및 업데이트: 승인된 변경 사항은 모든 관련 이해관계자에게 통신, 관련 문서 및 계획 업데이트