소프트웨어 개발 방법론

02. 소프트웨어 개발 방법론

1) 구조적 방법론 - 1970년대

1. 구조적 방법론의 절차

1. 타당성 검토 단계
2. 계획 단계
3. 요구사항 단계
4. 설계 단계
5. 구현 단계
6. 시험 단계
7. 운용/유지보수 단계

2. 구조적 방법론의 특징

• 1970년대까지 가장 많이 적용되었던 소프트웨어 개발 방법론
• 구조화 프로그래밍 또는 구조적인 프로그램 작성이라고도 함
• 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 체계적 분석 방법
• 쉽게 이해할 수 있고 검증할 수 있는 프로그램의 코드를 생성하는 것이 목적
• 모듈(부품) 중심으로 개발
• 분할과 정복 방법으로 하향식으로 기능을 분해
• 프로세스 중심 방식의 개발에 유용
• 재사용성, 유지보수성이 낮음

2) 정보공학 방법론 - 1980년대

1. 정보공학 방법론의 절차

1. 수직적 구조 방법론
   1. 정보 전략 계획
   2. 업무 영역 분석
   3. 업무 시스템 설계
   4. 기술 설계
   5. 업무 시스템 구축
   6. 업무 시스템 실행

2. 수평적 구조 방법론
   1. 데이터
   2. 업무 활동
   3. 상호 작용

2. 정보공학 방법론의 특징

• 정보 시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
• 소프트웨어 공학의 기술 발전에 따라 활용하기 위한 개발 방법론
• 생명주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
• 기업 정보 시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계 및 구축을 하는 데이터 중심의 방법론
• 자료 구조 중심의 방법론으로 비교적 안정적
• 데이터와 프로세스가 균형적
• 기능적 설계를 벗어나지는 못함
• 기능별로 유지보수를 해야 하며, 재사용성이 낮음

3) 객체지향 방법론 - 1990년대

1. 객체지향 방법론의 절차

1. 요구분석
2. 설계
3. 구현
4. 시험
5. 인수

2. 객체지향 방법론의 특징

• 데이터와 그 데이터에 관련되는 동작을 모두 포함하는 방법론
• 데이터는 실체이고, 동작은 절차, 방법, 기능을 의미
• 정보 시스템과 데이터베이스를 설계하는 방법론
• 분석과 설계 및 개발에 있어서 객체지향 기법을 활용하여 시스템을 구축하고자 하는 방법론
• 객체 중심으로 캡슐화, 추상화 기술이 필요
• 분석 초점이 명확함
• 자연스럽고 유연하며 재사용성이 용이함
• 개발 전문가가 부족함

4) 컴포넌트 기반 방법론 - 2000년대

1. 컴포넌트 기반 방법론의 절차

1. 개발 준비
2. 분석
3. 설계
4. 구현
5. 시험
6. 전개
7. 인도

2. 컴포넌트 기반 방법론의 특징

• 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 애플리케이션을 작성하는 방법론
• 모듈은 기능을 구현하기 위한 최소의 단위
• 공공 행정 정보 시스템의 개발에 많이 활용되고 있는 표준 프로세스
• 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 개발하는 방법론
• 생산성과 품질을 높이고, 유지보수 비용을 최소화할 수 있는 개발 방법
• 반복적, 점진적으로 개발
• 재사용성, 생산성, 품질이 높은 방법론
• 비용이 저렴하고, 위험을 개선할 수 있음
• 소프트웨어 위기를 극복하기 위한 방법론
• 컴포넌트 유통의 환경을 개선해야 함
• 테스트 환경이 부족하고, 컴포넌트 평가, 인증 환경이 미흡함

3. 소프트웨어의 위기(문제점)

• 소프트웨어의 개발 비용이 계속적으로 증대
• 소프트웨어를 개발한 후에 발생하는 유지보수 비용이 증대
• 과거에는 소프트웨어를 개발하는 기술적인 측면이 강조되었지만, 현재에는 소프트웨어의 관리적인 면이 강조됨
• 사용자의 요구 변화가 많아 개발 기간이 연장
• 하드웨어의 기술은 높지만, 소프트웨어 기술은 너무 낮음
• 업무의 전문성이 높아지면서 개발자와 사용자 간의 의견 차이가 큼
• 개발된 소프트웨어의 기능적 오류가 많아져 성능 및 신뢰성이 부족
• 소프트웨어의 품질을 평가하는 기준이 없음
• 소프트웨어의 개발 인력 부족

5) 애자일(Agile) 방법론 - 2000년 이후

1. 애자일 방법론의 등장 배경

• 사용자의 요구사항이 빈번하게 변경됨에 따라 새로운 방법론이 필요
• 계획이 없는 개발 방법은 선행 작업을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가짐
• 계획이 지나치게 많은 개발 방법론은 형식적인 절차를 따르는 비용과 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가짐
• 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

2. 애자일 방법론의 정의

• 요구사항, 설계, 구현, 시험의 단계를 통해 개발하는 방법론
• 소프트웨어 개발 방법에 있어서 계획이 없거나 계획이 지나치게 많은 개발 방법들 사이에 타협점을 찾은 방법론
• 소프트웨어 개발 단계의 변화에 신속하게 대응하기 위하여 요구사항을 지속적으로 분석하고 반영하여 시간 지연을 최소화하는 방법론

3. 애자일 방법론의 특징

• 프로세스와 도구 중심이 아닌 개발 과정의 소통을 중요하게 생각하는 소프트웨어 개발 방법론으로 반복적인 개발을 통한 잦은 출시를 목표로 함
• 기존 모형(폭포수 모형, 프로토타입 모형, 나선형 모형)의 문제점을 보완한 모형
  • 폭포수 모형(Waterfall Model)
    • 폭포수의 물흐름처럼 한번 지나가면 다시는 되돌릴 수 없듯이 각 단계를 명확히 하고 다음 단계로 넘어가는 모형
  • 프로토타입 모형(Prototyping Model)
    • 시스템 개발 초기에 사용자의 요구 기능을 시제품으로 만들어 사용자로 하여금 기능과 사용성 등에 대해 검증시켜 가면서 시스템을 개발하는 기법
  • 나선형 모형(Spiral Model)
    • 폭포수 모형과 프로토타입 모형의 장점을 살린 모형으로 사용자 요구 확인에 의한 시스템 개발이 가능함
    • 나선형 모형을 위험 분석을 해나가면서 시스템을 개발
• 소프트웨어를 점증적으로 개발
• 출시 주기를 짧게 하여 다양한 요구 변화에 대응
• 고객과 개발팀과의 소통, 개발팀원 간의 소통, 협력을 극대화
• 인간의 수행 능력을 높이기 위한 현실적인 방법을 제시
• 가볍고 실용적인 소프트웨어 개발 방법론
• 애자일 방법론을 소프트웨어 개발 방법론의 방법론이라고 함

4. 애자일 방법론의 선언문

- 개인과 상호 작용을 프로세스와 도구보다 중시한다.
- 동작하는 소프트웨어를 포괄적인 문서보다 중시한다.
- 고객과의 협력을 계약의 협상보다 중시한다.
- 변화의 대응을 계획의 수행보다 중시한다.

• 대형화, 복잡한 개발 방법론보다는 현실적이고 가벼운 소프트웨어 개발을 지지하는 애자일 방법론 지지자들이 모여 2001년에 4가지 애자일 선언문을 발표
• 애자일 모형의 도입으로 프로세스와 도구 문서 작업, 계약의 협상, 계획의 수행을 무시하는 것이 아님을 주의

5. 애자일 방법론의 원칙

1. 소통 : 알기 쉬운 차트, 정보 공유, 회의
2. 협력 : 개발팀 협조, 고객과의 대화로 문제 해결
3. 적응 : 변화 수용, 융통성 발휘
4. 지속 : 검증을 반복, 점증 개발
5. 가치 전달 : 위험도 높은 작업 우선, 비용 감소
6. 피드백 : 자주 출시, 고객 평가

6. 애자일 방법론의 5가지 가치

1. 의사소통 : 개발팀이 발전적인 방향으로 존속하는 데 있어서 가장 중요한 가치
2. 용기 : 모르는 것을 모른다고 말하는 용기, 먼저 도움을 주거나 요청할 수 있는 용기로 소프트웨어 개발 시 커다란 미지의 두려움에 마주할 때 필요한 가치
3. 피드백 : 소프트웨어 개발 및 의사소통의 핵심으로 지속적이고 빠른 피드백을 통해 의사소통과 좋은 분위기를 이어감
4. 단순함 : 간결하고 단순하게 개발하여 어려움을 해소하고자 하는 것
5. 존경 : 위의 모든 가치를 추구하는 과정에서 유지되어야 하는 가치

7. XP(eXtreme Programming, 익스트림 프로그래밍)

• 소프트웨어 개발 방식을 애자일 모형으로 개발하는 대표적인 방법
• 전통적인 소프트웨어 개발 방법론과는 달리 문서화를 강조하지 않고 변경을 추구하며, 개발 초기부터 소프트웨어 검사를 병행할 것을 강력히 권고하는 새로운 방법론
• 의사소통의 개선과 즉각적인 피드백에 의한 단순한 코딩으로 소프트웨어 품질을 높이는 방법
• 12개의 실천 항목을 적용
  1. Pair Programming : 하나의 작업을 2명의 개발자가 공동 수행
  2. Planning Game : 게임처럼 목표를 두고 기획 수행
  3. Test Driven Development : 단위 테스트 후 실제 코드 작성
  4. Whole Team : 고객을 프로젝트팀원으로 상주
  5. Continuous Integration : 상시 빌드 및 배포가 가능한 상태로 유지
  6. Design Improvement : 불필요한 기능 제거 및 리팩토링
  7. Small Releases : 필요한 기능들만 갖춘 간단한 시스템을 빠르게 배포
  8. Coding Standards : 표준화된 코드 작성
  9. Collective Ownership : 소스 코드는 모든 개발자가 언제라도 수정 가능
  10. Simple Design : 가장 간결한 디자인 상태 유지
  11. System Metaphor : 최종 개발되어야 할 시스템 구조를 조망
  12. Sustainable Pace : 오버타임 지양
• 애자일 방법론의 5가지 가치를 실현한 방법론

8. 스크럼(SCRUM)

• 애자일 방법론 중의 하나로 프로젝트 관리를 위한 상호 점진적 개발 방법론
• 매일 정해진 시간, 정해진 장소에서 단기간에 개발하는 개발팀을 위한 프로젝트 관리 중심의 방법론
• 소프트웨어 유지보수팀이나 일반적인 프로젝트 관리에서도 적용 가능
• 추정 및 조정 기반의 경험적 관리 기법

스크럼의 5가지 가치

• 확약 : 약속을 확실히 실현한다.
• 전념 : 확약을 위해 실현에 전념한다.
• 정직 : 모든 사실을 숨기지 않는다.
• 존중 : 다른 사람에게 경의를 표한다.
• 용기 : 옳은 일을 할 수 있도록 갈등과 도전을 극복한다.

스크럼의 요소

• 백로그(Backlog) : 제품 기능 목록으로 사용자가 요구한 기능에 우선순위를 부여하여 나열한 목록
• 스프린트(Sprint) : 작업량이 많지 않고, 짧은 개발 단위를 단기간 내에 전력으로 개발하는 것
• 스크럼 미팅 : 5분 정도의 팀 미팅으로 작업의 계획을 수립
• 스크럼 마스터 : 팀 리더로 효율적인 개발과 문제 해결을 위해 노력

9. 린(Lean)

• 린 시스템의 품질 기법을 적용하여 개발 프로세스의 낭비적인 부분을 제거한 방법론
• 낭비적 요소를 제거하고, 개발 결과를 측정, 성과를 분석하여 품질을 향상

린 방법론의 7가지 원칙

• 낭비적인 요소를 제거한다.
• 품질을 내재화한다.
• 지식을 창출한다.
• 가능한 늦게 결정한다.
• 가능한 빠르게 인도한다.
• 사람을 존중한다.
• 전체 공정을 최적화한다.

10. DSDM(Dynamic Systems Development Method)

• 동적 시스템 개발 방법
• RAD 방식으로 개발하여 소프트웨어의 개발 여부를 판단하는 방식
  • RAD(Rapid Application Development)
    • 초고속 응용 프로그램 개발 모형으로 사용자 요구사항의 일부분이나 제품의 일부분을 반복적으로 개발하여 최종 제품을 완성하는 방법
    • 2~3개월 정도의 짧은 기간으로 기술적으로 위험이 적고 빠른 개발이 요구될 때 적합
    • 빠른 개발을 위해 CASE 도구 및 Visual Tool, Code Generation Tool 등을 사용
    • 프로토타입 사용, 개발 주기 동안 사용자의 적극적인 참여가 필요
    • 통합 단계가 필요한 대규모 프로젝트에 부적합
• DSDM은 애자일 프로젝트 프레임워크로 개정되면서 소프트웨어 개발과 코드 작성보다는 프로젝트 관리, 솔루션 전달의 일반적을 접근 방식으로 발전
• DSDM의 5단계
  1. 타당성 조사 : RAD 방식으로 개발하여 소프트웨어의 개발 여부를 판단
  2. 비즈니스 연구 : 사용자의 요구사항을 분석
  3. 기능 모델 반복 : 프로토타입을 개발하여 사용자의 요구사항을 수용
  4. 설계 : 반복된 모델로 최종 설계
  5. 구현 : 설계 자료를 구현하며 테스트 단계를 통하여 최종 결과물 도출

DSDM의 원칙

• 적극적인 사용자 참여는 필수적이다.
• 개발팀이 의사 결정을 할 수 있도록 힘을 실어주어야 한다.
• 수시로 제품을 인도해야 한다.
• 비즈니스 목적에 부합하는 지가 필수 기준이 되어야 한다.
• 반복적이고 점증적인 개발로 정확한 비즈니스 솔루션으로 수렴하게 한다.
• 개발하는 동안 발생되는 변경 사항은 원래 상태로 되돌릴 수 있어야 한다.
• 요구사항은 상위 수준에서 기준선이 만들어진다.
• 테스팅은 소프트웨어 생명주기 동안에 통합된다.
• 모든 이해관계자 간의 협업과 협조가 필수적이다.

11. FDD(Feature Driven Development, 기능 중심 개발) 방법

• 사용자가 원하는 기능의 시나리오에 필요한 만큼만 개발하는 방법
• 모듈이나 서비스 단위로 개발하는 것이 아니라 기능 중심 단위로 개발하는 방법
• 설계와 구축 기능을 중점으로 개발
• 모듈화와 구조화의 원칙을 지키면서 한 모듈이 개발되기 전에 테스트할 수 있을 정도로만 개발하는 방법
• 개발 초기부터 기능을 테스트할 수 있기 때문에 모듈 중심 개발보다 테스트가 빠름
• 기능 중심 개발을 깊이 우선 통합, 모듈 중심 개발은 넓이 우선 통합
• 기능을 매우 구체적이고 짧은 작업으로 분할
• 작업을 시작하여 2주의 반복 주기로 기능을 개발
• 스크럼 방법은 소프트웨어 개발보다는 프로젝트 관리를 위한 개발팀을 운영하는 효율적인 운영 방침
• 스크럼은 상품이나 서비스 단위로 개발되지만 FDD 방법은 기능 단위로 개발
• FDD 방법은 5가지 기본 활동으로 구성된 단기 반복 프로세스
  • FDD 방법의 5가지 기본 활동
    1. 전체 설계 작성
    2. 기능 목록 작성
    3. 기능에 의한 계획
    4. 기능에 의한 설계
    5. 기능에 의한 구현
• 기능에 의한 설계와 구현에 많은 시간(전체의 75% 이상)을 할당

6) 제품 계열 방법론 - 2010년대

• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
• 임베디드 소프트웨어를 작성하는 데 유용한 방법론
• 영역 공학과 응용 공학을 연계시키기 위한 제품의 요구사항, 제품의 아키텍처, 제품의 조립 생산이 필요
  • 영역 공학 : 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
  • 응용 공학 : 제품 요구분석, 제품 설계, 제품을 구현하는 영역

7) 테일러링(Tailoring) 방법론

1. 테일러링 개발 방법론의 특징

• 서로 다른 개발 환경하에서 개발되는 다양한 종류의 프로젝트를 하나의 일관된 개발 방법론으로 적용하기 어렵기 때문에 등장한 방법론
• 개발하려는 소프트웨어 특성에 맞게 융통성 있게 적용하는 방법론
• 표준 프레임워크를 기반으로 실제 업무 분야별로 여건에 맞게 수정 보완하는 방법
• 방법론에 표준이 없음
  • 절차에 대한 구체적인 표준이 존재하지 않고, 일반적으로 따르는 절차들과 개별 방법론에서 제시하는 테일러링 안내서들이 존재함
• 테일러링은 커스터마이징의 작업이 반복됨
• 테일러링 방법론에서 가장 중요한 부분은 프로젝트 분석
• 최적화된 방법론이 되기 위해서는 프로젝트의 다양한 특성들을 분석하여 쉽게 해결하고 용이하도록 테일러링 되어야 함
• 테일러링을 위한 소프트웨어 개발 프레임워크에는 ISO/IEC 12207, CMMI 모델, SPICE 등이 있음

2. 테일러링 개발 방법론의 필요성

• 내부 기준
  • 목표 환경 : 개발 환경과 유형이 다른 경우
  • 요구사항 : 요구사항이 다른 경우
  • 프로젝트 규모 : 납기일, 비용, 범위 등이 다른 경우
  • 기술 환경 : 방법론, 보유 기술, 구성원의 능력 등이 다를 경우
• 외부 기준
  • 법적 제약 사항 : IT 컴플라이언스 등이 다른 경우
  • 표준 품질 기준 : 표준 품질 기준이 다른 경우

8) 보안 개발 방법론

1. MS-SDL(Microsoft Secure Development Life Cycle)

• 보안 수준이 높은 안전한 소프트웨어를 개발하기 위해 MS사가 자체적으로 수립한 SDLC(Software Development Life Cycle)

2. Seven Touchpoints

• 실무적으로 검증된 개발 보안 방법론 중 하나로써 소프트웨어 보안의 모범 사례를 SDLC에 통합한 소프트웨어 개발 보안 생명주기 방법론

3. CLASP(Comprehensive Lightweight Application Security Process)

• 소프트웨어 개발 생명주기 초기 단계에서 보안을 강화하기 위한 정형화된 프로세스로써, 활동 중심 역할 기반의 프로세스로 구성된 집합체
• 이미 운영 중인 시스템에 적용하기에 적합한 방법론
• 개념, 역할 기반, 활동 평가, 활동 구현, 취약성의 5가지 관점에 따라 개발 보안 프로세스를 수행할 것을 제안

4. CWE(Common Weakness Enumeration)

• 소프트웨어의 보안 취약점을 유발하는 원인을 7가지로 정리한 방법론
• 7가지 원인
  • 입력 데이터 검증 표현
  • 보안 기능
  • 시간 및 상태
  • 오류 처리
  • 코드 품질
  • 캡슐화
  • API 악용