Archive

02_프로세스와 방법론

17 min read

0. 프로세스 없는 개발

주먹구구식(Build-and-fix) 모델 공식 가이드라인 없이 즉흥적으로 개발하는 방식

  • 프로젝트 계획 없음 → 비용·일정 만족 어려움
  • 사용자 요구사항 및 설계 작업의 중요성을 깨닫지 못함
  • 체계적 테스트·품질 보증 활동 필요성 인식 없음

1. 소프트웨어 생명주기

  • 소프트웨어 생명주기 (SDLC; Software Development Life Cycle)

    • 개발·유지보수에 필요한 작업들을 체계적으로 정리
    • 정의 → 운용 → 유지보수 등의 과정을 단계별 구성
    • 개발 방법론의 바탕
    • 흐름: 요구 분석 → 설계 → 구현 → 테스팅 → 유지보수

  • ISO 12207

    • 소프트웨어 생명주기를 전 세계적으로 소통하도록 약속된 국제 표준

cf. 단계 (Phases)

  • SDLC의 목적은 소프트웨어를 체계적으로 개발하여, 정해진 시간과 비용 안에 높은 품질의 소프트웨어를 제공하고 유지보수까지 효율적으로 할 수 있도록 하는 것이다.

  • 계획(Planning)

    • 프로젝트 일정, 예산, 리소스, 리스크 분석
    • 개발 팀 구성 및 역할 분담

  • 요구사항 분석(Requirement Analysis)

    • 소프트웨어 개발 초기 단계에서 요구를 식별
    • 기능적 요구사항(Functional Requirement, FR): 프로그램이 무엇을 해야 하는지
    • 비기능적 요구사항(Non-functional requirement, NFR): 성능, 에러 처리, 편의성, 안정성, 보안 등

  • 설계(Design)

    • 아키텍처 설계 (시스템 구조, DB 설계, UI 설계 등)
    • 상세 설계로 개발자들이 구현할 수 있도록 구체화 (클래스, 데이터베이스, API 설계 등)

  • 구현(Implementation)

    • 설계에 따라 프로그래밍 언어로 소프트웨어 개발
    • 코드 버전 관리 도구(Git 등) 활용

  • 테스트(Testing)

    • 단위 테스트, 통합 테스트, 시스템 테스트, 사용자 수용 테스트 등을 수행
    • 버그 탐지 및 품질 향상

  • 배포(Deployment)

    • 실제 운영 환경에 소프트웨어를 배포

  • 유지보수(Maintenance)

    • 운영 중 발생하는 오류 수정
    • 성능 개선, 기능 추가, 보안 패치
    • 사용자의 피드백 반영

2. 프로세스

개념설명
프로세스소프트웨어 개발 시 실행되는 작업 단계 (실행 관점)
프로세스 모델일반적인 프로세스를 추상적으로 기술한 것 (전략 관점)

  • 프로세스 정의의 3요소

    • 목적: 프로세스 수행으로 얻는 효과
    • 작업 방법(Activity): 해야 할 작업
    • 성과(Outcome): 결과물 (문서, 코드, 프로토타입 등)

  • 소프트웨어 품질

    • 프로세스(원인) → SW 제품 품질(결과) → 개발 조직 역량 향상
    • 품질 평가 모델: CMMI, SPICE

  • 관리 프로세스

    • 자원·일정·비용·품질을 계획하고 통제하는 모든 활동
    • 계획 → 모니터링 → 분석과 조절

2.1. 프로세스 vs 방법론

구분프로세스방법론
특징단계적 작업의 틀
무엇을(What) 하는가
패러다임에 독립적		프로세스의 구체적 구현
어떻게(How) 하는가
패러다임에 종속적
사례폭포수, 나선형, 프로토타이핑, Unified, 애자일구조적, 객체지향, 컴포넌트 기반, 애자일 방법론

3. 프로세스 모델 종류

분류모델
선형 순차적폭포수 모델, V 모델
진화적프로토타이핑 모델, 나선형 모델
기타단계적 모델, 통합(Unified) 프로세스, 애자일 프로세스

3.1. 폭포수(Waterfall) 모델

1970년대 도입된 가장 오래되고 전통적인 프로세스 모델

  • 특징

    • 순차적: 각 단계 사이에 중복·상호작용 없음
    • 단계별 종결: 각 단계 끝날 때마다 승인된 결과물(문서) 필요
    • 계획 중심: 프로젝트 초기에 모든 요구사항 확정

  • 흐름

    • 계획 → 요구분석 → 설계 → 구현 → 테스트 → 운영·유지보수
장점단점
명확한 관리 체계 (단계별 시작·끝 분명)고객 피드백 부재
높은 가시성 (중간 산출물 명확)요구사항 변경에 취약
요건 확정 (충분한 연구·분석 단계)병목 현상 (일정 지연 시 인력 운용 비효율)
  • 적용
    • 요구사항 변화가 적고 명확한 프로젝트, 크고 복잡한 장기 프로젝트

3.2. V 모델

폭포수 모델을 확장하여 단계별 검증과 테스트를 강화한 모델

  • 왼쪽(하향): 개발 단계
    • 요구분석 → 시스템 설계 → 상세 설계 → 코딩
  • 오른쪽(상향): 테스트 단계
    • 단위 테스팅 → 통합 테스팅 → 시스템 테스팅 → 인수 테스팅
  • 각 개발 단계와 대응하는 테스트 단계가 검증으로 연결됨

3.3. 프로토타입(Prototype) 모델

사용자 요구사항 확인을 위해 시스템을 실험적으로 만들어 평가 후 최종 시스템 구현

유형설명
실험적 프로토타입최종 프로토타입을 버리고 요구사항 확정 후 처음부터 본격 구현 (일반적)
진화적 프로토타입지속적으로 보완하여 최종 소프트웨어로 발전
  • 흐름
    • 요구분석 → 프로토타입 개발/개선 → 프로토타입 평가 → (불일치 시 요구분석으로) → 구현 → 인수/설치
장점단점
요구사항 도출 용이비용·시간 증가 (반복적 개발)
의사소통 원활문서화 소홀 (중간 산출물 없음)
오류 조기 발견
  • 적용
    • UI/UX 중심 서비스, 요구사항이 불명확한 신규 서비스, R&D 프로젝트

3.4. 나선형(Spiral) 모델

폭포수 + 프로토타입의 장점에 위험 분석 기능을 추가한 반복적 모델

  • 4단계 반복 순환
    1. 목표·방법·제약 조건 결정 (Determine Objective)
    2. 위험 요소 분석 및 해결 (Risk Analysis)
    3. 개발과 평가 (Development and Test)
    4. 다음 단계의 계획 (Evaluation/Plan the next Iteration)
장점단점
위험 관리 최적화관리의 복잡성
품질·완성도 보장시간·비용 증가
유연성 (요구사항 변경 수용)
  • 적용
    • 국방·우주항공 (고위험), 대규모 국가 기간망, R&D 프로젝트

3.5. 단계적(Phased) 모델

요구분석·설계·구현·테스트 사이클과 사용을 병행하며 반복 빠른 시장 출시가 목적

방법설명
점증적(Incremental)기능별로 릴리스 → 개발 범위 증가
반복적/진화적(Iterative)릴리스마다 기능 완성도 향상 → 품질 증가
장점단점
빠른 결과물 확인관리 복잡도 증가
유연한 인력 운용통합의 어려움
피드백 반영소규모 프로젝트 부적합

3.6. 통합(Unified) 프로세스 (UP/RUP)

OMG가 UML과 함께 제안 Rational Software → RUP → IBM 통합 후 UP로 불림

  • 특징
    • 반복적·점증적 개발, 위험 관리 기반, 아키텍처 중심, 유스케이스 기반
단계절차내용
1도입(Inception)프로젝트 범위·목표 설정, 유스케이스 모델·계획 작성
2구체화(Elaboration)아키텍처 설계, 대부분의 유스케이스 작성
3구축(Construction)유스케이스 구현·통합, 점증적 설치
4전환(Transition)배치·사용자 교육·고객 인도, 베타 테스팅·결함 수정
장점단점
품질 향상, 위험 조기 대응높은 복잡도
변경 수용, 재사용성관리 비용 높음
  • 적용
    • 대규모 기업용 시스템, 객체지향 개발 프로젝트

3.7. 애자일(Agile) 프로세스

변화에 유연하게 대응하며 짧은 주기(2~6주)를 반복하여 소프트웨어 개발

애자일 선언문 4가지 기본 가치

기존 중심애자일 중심
프로세스·도구개인과 상호작용 (Individual & Interaction)
문서실행 가능한 소프트웨어 (Working Software)
계약·협상고객과의 협력 (Customer Collaboration)
계획변화에 대한 민첩한 대응 (Responding to Change)
  • 특징
    • 짧은 주기 반복 / 우선순위 높은 기능부터 개발 / 유연한 범위 변경 / 팀 협업 중심
장점단점
변화에 최적화전체 일정·비용 예측 어려움
품질 향상운영 난이도 높음 (숙련도·자율성 필요)
고객 만족도 증대확정된 문서 부족
  • 적용
    • 모바일 앱·웹 서비스, 스타트업 프로젝트

3.8. 익스트림 프로그래밍(XP)

개발 기술 관점의 애자일 방법론 1999년 Kent Beck 발표

5가지 핵심 가치설명
용기(Courage)변화에 능동적 대처
단순성(Simplicity)필요 기능만 구현, 불필요한 구조 배제
커뮤니케이션(Communication)개발자·관리자·고객 간 원활한 의사소통
피드백(Feedback)진행 상황 확인 및 빠른 피드백
존중(Respect)팀원 간 상호 존중 및 성과 공유
7가지 기본 원리설명
Planning Game사용자 스토리로 작업 범위·우선순위 결정
Continuous Integration매일 빌드·통합, 실행 시스템 항상 준비
Test-Driven Development코드 작성 전 테스트 시나리오 준비
Pair Programming2명이 공동 작업
Refactoring기능 변경 없이 설계 구조 향상
Whole Team고객을 팀원으로 포함, 즉각적 피드백
Collective Ownership코드는 누구든 수정 가능, 공동 책임
  • XP 과정
    • 스토리/스파이크 → 릴리즈 계획 → 반복 싸이클 → 인수 테스트 → 릴리즈

3.9. 크리스탈(Crystal)

인적자원 중심의 맞춤형 방법론 (코번·하이스미스 창시) 프로젝트 규모에 따라 다른 방법론 적용

방법론팀 규모
Clear~5명
Yellow~20명
Orange~40명
Red~80명
Maroon/Blue대규모

3.10. 스크럼(Scrum)

관리 기법 중심 작은 목표를 짧은 주기(1~4주)로 반복하며 점진적으로 개발하는 프레임워크

3가지 역할설명
스크럼 마스터프로젝트 관리·회의 주제
제품 책임자(Product Owner)백로그 관리·제품 검토
팀원(Developer)백로그의 제품 개발
주요 용어설명
제품 백로그고객 요구사항인 사용자 스토리 집합
스프린트1~4주 단위의 개발 사이클
스프린트 계획 회의이번 스프린트 작업 계획 수립
스프린트 백로그스프린트 목표 달성을 위한 작업 목록
일일 스크럼매일 어제 한 일·오늘 할 일·장애 요소 공유
스프린트 리뷰개발 내용을 이해관계자에게 시연·검토
스프린트 회고좋았던 점·개선할 점 도출

4. 방법론

구분구조적 방법론정보공학 방법론객체지향 방법론
특징프로그램 로직 중심, DFD·구조적 다이어그램기업정보·전략 계획, 데이터 중심, CASE 도구유스케이스 분석, 클래스·객체 상호작용
설계 관심사함수 위주자료 위주클래스 위주
설계의 핵심모듈엔티티객체
중심 방법프로그래밍 기법기업 전략·산출물설계의 표현

4.1. 구조적 방법론

기능·프로세스 위주의 분석 설계 방식, 1970년대 등장

  • 분리와 정복(divide and conquer)에 의한 하향식 원리

  • 분할된 기능을 독립된 모듈로 구성 → 복잡도 감소, 재사용성 향상

  • 산출물: DFD(자료 흐름도) → 구조도(Structured Chart)

  • DFD 구성 요소

    • 사각형(Terminator) / 화살표(Data Flow) / 두 줄 직선(Data Store) / 원(Process)

4.2. 정보공학 방법론

기업 데이터 중심(Data-Driven) 방법론, 1980년대 James Martin 체계화

  • 특징

    • 기업 중심 / 전략적 시스템 계획 중심 / 데이터 중심(ERD 사용)
    • 분할과 정복 / 공학적 접근 / 사용자 적극적 참여

  • 절차

    • 정보전략 계획 → 비즈니스 영역 분석 → 비즈니스 시스템 설계 → 시스템 구축

4.3. 객체지향 방법론

실세계 대상을 추상화하고 클래스로 캡슐화하여 객체 상호 관계를 모델링하는 상향식 방식

  • 관련 기법
    • OOSE(Jacobson), OMT(Rumbaugh), OOD(Booch), UML, UP

그래프 뷰