[정보처리기사] Part01 소프트웨어 설계 - Section02

[Section 02] 소프트웨어 개발 방법론

01 소프트웨어 개발 환경

1) 운영체제(OS : Operating System)

① 운영체제의 정의

• 하드웨어와 소프트웨어 자원을 관리하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 시스템 소프트웨어이다.

② 운영체제의 종류

• Windows : 중소 규모 서버, 개인용 PC, Tablet PC, Embedded System 등에서 사용한다. 유지 및 관리 비용 측면에서는 Windows 기반 시스템이 강점을 가진다.
• UNIX : 대용량 처리, 안정성이 요구되는 Server, NAS*, Workstation 등에서 사용한다. 신뢰할 수 있는 대용량 처리를 위해서는 UNIX 기반 시스템이 선호되고 있다.
• Linux : 중대 규모 서버 등에서 사용한다. 일반적으로 Linux 기반 시스템이 하드웨어 및 소프트웨어 소요 비용이 가장 적게 소요된다.
• iOS : 애플의 운영체제로 스마트폰, 태블릿 PC 등에서 사용한다.
• Android : 구글의 개방형 운영체제로 스마트 폰, 태블릿 PC 등에서 사용한다.

  • NAS(Network Attached Storage) : 서버와 저장장치를 네트워크로 연결하는 방식

③ 운영체제 분석 시 고려사항

• 신뢰도 : 오랜 시간 시스템을 운영할 때 운영체제 고유의 장애 발생 가능성이 있는지 확인한다.
• 성능 : 다수의 동시 사용자 요청 처리가 가능한지 확인한다. 대량 파일 작업 처리가 가능한지 확인한다.
• 기술 지원 : 공급 벤더(Vender)들의 안정적인 기술 자원이 있는지 확인한다.
• 주변 기기 : 다수의 주변 기기 지원 여부를 확인한다.
• 구축 비용 : 지원 가능한 하드웨어 비용, 설치할 애플리케이션의 라이선스 정책 및 비용이 어느 정도인지 확인한다. TCO*를 확인한다.

  • TCO(Total Cost of Ownership) : 컴퓨터 시스템을 구축하고 사용하는 데 드는 모든 비용

④ 운영체제 현황

• 32bit 운영체제에서는 4GB 메모리까지 액세스 가능(사용자 메모리는 2GB)
• 64bit 운영체제에서는 4GB 이상의 메모리까지 액세스 가능
• CISC 설계 방식이 적용된 인텔의 x86* 아키텍처 기반 칩을 사용하고 있는 하드웨어는 Windows나 Linux 운영체제로 설치할 수 있으며, RISC 설계 방식이 적용된 칩들은 UNIX 운영체제를 설치한다.
• HP와 Intel사가 협력해서 만든 (IA* -64) 칩은 여러 운영체제를 지원한다.
• RISC 설계 방식이 적용된 ARM 칩은 스마트 폰이나 태블릿에 주로 채택되고 있으며, iOS, Android 등의 운영체제를 지원하고 있다.

  • x86 : 컴퓨터 하드웨어 제작 회사인 Intel 사에서 개발한 마이크로프로세서 모델 중 하나.
  • IA(Itanium Architecture) : 아이테니엄 아키텍처

2) CPU(중앙 처리 장치)

① CISC(Complex Instruction Set Computer) 설계 방식

• 복잡하고 많은 종류의 명령어와 주소 지정 모드를 사용한다.
• 가변 길이 명령어 형식이다.
• 100~250개 정도의 많은 명령어를 가지고 있어 설계가 어렵다.
• 마이크로 프로그래밍(소프트웨어적) 제어 방식이다.
• 명령어가 소프트웨어적이므로 호환성이 좋다.
• 명령어를 해석한 후 명령어를 실행한다.
• 컴파일 과정이 쉽고, 호환성이 좋다는 장점이 있지만, 속도가 느리다는 단점이 있다.
• 인텔(Intel)사의 CPU에 주로 사용되었다.

② RISC(Reduced Instruction Set Computer) 설계 방식

• 간단하고 적은 종류의 명령어와 적은 수의 주소 지정 모드를 사용한다.
• 고정 길이 명령어 형식이다.
• CISC에 비해 명령어 수가 적다.
• 하드웨어(논리 회로를 이용한 하드웨어)적 제어 방식이다.
• 효율적인 파이프라이닝 구조를 사용한다.
• 명령어의 길이가 미리 정해져 있으므로 해석 속도가 빠르다.
• 작고 빠른 명령어 사용을 위해 많은 수의 범용 레지스터가 사용되며, 처리 속도가 빠르고 하드웨어 구조가 간단해진다.
• 효율성이 떨어지고 전력 소모가 적다.
• 처리 비트 단위가 변하거나 프로세서의 구조가 조금만 바뀌어도 하위 프로세서와의 호환성이 떨어진다.
• 고성능의 워크스테이션이나 그래픽용 컴퓨터에서 주로 사용된다.

3) DBMS(DataBase Management System)

① DBMS의 정의

• 대량의 데이터를 저장하고 있는 데이터베이스를 생성, 조회, 변경 등의 관리를 하는 프로그램이다.
• 사용자, 다른 애플리케이션, 데이터베이스와 상호 작용하여 데이터를 저장하고 분석하기 위한 애플리케이션이다.

② DBMS의 종류

• Oracle : 대규모 데이터 처리, 안정적인 처리가 된다.
• IBM DB2 : 대규모 데이터 처리, 안정적인 처리가 된다.
• SQL Server : 중고 규모 데이터 처리, 안정적인 처리가 된다.
• MySQL : 오픈소스에서 주로 사용되는 RDBMS이다.
• SQLite : 스마트폰, 태블릿 PC 등의 Embedded 데이터베이스 용도로 사용된다.
• MongoDB : 오픈소스이며 NoSQL DBMS이다.
• Redis : 오픈소스이며 키-값(Key-Value) DBMS이다.

③ DBMS 분석 시 고려사항

• 가용성 : 오랜 기간 시스템을 운영할 때 장애 발생 가능성이 있는지 확인한다.
• 성능 : 대규모 데이터를 처리할 만한 성능인지 확인한다. 다양한 튜닝 옵션을 지원하는지 확인한다.
• 기술 지원 : 공급 벤더들의 안정적인 기술을 지원하는지 확인한다. 오픈소스 여부를 확인한다.
• 상호 호환성 : 설치 가능한 운영체제 종류를 확인한다. 오픈소스 여부를 확인한다.
• 구축 비용 : 라이선스 정책 및 비용을 확인한다. 유지 및 관리 비용을 확인한다. 총 소요 비용(TCO)을 확인한다.

4) 미들웨어(Middleware)

① 미들웨어의 정의

• 운영체제와 소프트웨어 애플리케이션 사이에 위치하는 미들웨어는 소프트웨어 애플리케이션에게 운영체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어이다.
• 클라이언트와 서버 간 통신을 담당하는 시스템 소프트웨어이다.
• 분산 컴퓨팅 환경에서 서로 다른 기종 간의 하드웨어나 프로토콜, 통신 환경 등을 연결하여 응용 프로그램과 운영 환경 간에 원만한 통신이 이루어질 수 있게 서비스를 제공하는 소프트웨어이다.

② 미들웨어의 종류

• DBMS(DataBase Management System)
  데이터베이스 벤더에서 제공하는 클라이언트에서 데이터베이스와 연결하기 위한 미들웨어로, 이 제품을 사용하여 시스템을 구축하는 경우 보통 2-티어(Tier) 아키텍처라고 한다.

• RPC(Remote Procedure Call)
  애플리케이션의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어

• MOM(Message Oriented Middleware)
  메세지 기반의 비동기형 메세지를 전달하는 방식의 미들웨어로 이 기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용된다.

• TP-Monitor
  트랜잭션이 올바르게 처리되고 있는지 데이터를 감시하고 제어하는 프로그램이다.
  온라인 트랜잭션 업무(은행 계정, 항공기/버스 예약 업무 등)에서 트랜잭션을 처리, 감시하는 미들웨어이다.
  사용자 수가 증가하여도 빠른 응답 속도를 유지해야 하는 업무에 적합하다.

• ORB(Object Request Broker)
  객체 지향 미들웨어로 코바(CORBA) 표준 스펙을 구현한 미들웨어이다.
  EJB는 서버 컴퓨터에서 운영되는 Java 컴포넌트들을 설정하기 위한 아키텍처이다.

5) WAS(Web Application Server)

① WAS의 개념

• 동적인 웹 사이트, 웹 애플리케이션, 웹 서비스의 개발을 지원하기 위하여 설계된 소프트웨어로 데이터 접근 관리, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리를 제공하고 있다.
• WAS는 HTTP 세션 처리를 위한 웹 서버 기능뿐만 아니라 필수적인 기업 업무까지 Java, EJB 컴포넌트 기반으로 구현이 가능하다.
  
• 사용자가 웹 브라우저로 요청하면, 정적 데이터는 웹 서버가 직접 처리한다.
• 동적 데이터는 웹 서버에서 직접 처리하지 못하여 WAS에서 지원받아 처리한다.
• 정적 데이터는 이미지나 자바스크립트 코드 등이다.
• 동적 데이터는 데이터베이스와 접속, 외부 시스템과의 연동 등이다.

② WAS의 종류

• GlassFish : GlassFish Community(애플리케이션 서버 개발을 위한 Java 공동체)에서 제공, NetBeans(Java 개발자 플랫폼) 개발 툴과 연동하여 사용한다.
• JBoss : Red Hat, JBoss(Java 기반으로 오픈소스 미들웨어의 총칭)에서 제공, 오픈소스 제품들을 이용하는 경우에 사용한다.
• Jetty : Eclipse Foundation(Eclipse는 Java, C언어 등을 개발할 수 있는 통합 환경을 제공하는 프로그램으로 현재 가장 많이 사용)에서 제공, 빠른 처리 속도가 요구되는 경우에 사용한다.
• JEUS : TmaxSoft(국내 미들웨어 시장 1위 기업)에서 제공, 대량의 안정적인 거래 처리가 요구되며 적시의 기술 지원이 필요한 경우에 사용한다.
• Resin : Caucho Technology(오픈소스 창시자, 웹 서버 소프트웨어 개발사)에서 제공, 빠른 처리 속도가 요구되는 경우에 사용한다.
• WebLogic : Oracle Corporation(매출 규모 상위권의 소프트웨어 회사, 오라클 DBMS는 세계 최고의 점유율)에서 제공, 대량의 안정적인 거래 처리가 요구되는 경우에 사용한다.
• WebSphere : IBM에서 제공, 대량의 안정적인 거래 처리가 요구되는 경우에 사용한다.

③ WAS 분석 시 고려사항

• 가용성
  오랜 시간 동안 시스템을 운영할 때 장애 발생 가능성이 있는지 확인한다.
  안정적인 트랜잭션 처리가 가능한지 확인한다.
  패치 설치를 위한 재기동이 되는지 확인한다.
  WAS 이중화를 지원하는지 확인한다.

• 성능
  대규모 거래 요청 시 처리 성능을 확인한다.
  다양한 설정 옵션을 지원하는지 확인한다.
  GC의 다양한 옵션을 지원하는지 확인한다.

• 기술 지원
  공급 벤더들의 안정적인 기술 지원이 가능한지 확인한다.
  다수의 사용자들 간의 정보를 공유할 수 있는지 확인한다.
  오픈소스 여부를 확인한다.

• 구축 비용
  라이선스 정책 및 비용을 확인한다.
  유지 및 관리 비용을 확인한다.
  총 소요비용(TCO)를 확인한다.

6) 오픈소스(Open Source)

① 오프소스의 정의

• 오픈소스는 소스 코드를 공개해 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈소스 라이선스를 만족하는 소프트웨어이다.

② 오픈소스 분석 시 고려사항

• 오픈소스를 사용하는 경우에는 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야 한다.
• 라이선스의 종류 등 자세한 내용은 한국저작권위원회의 OLIS 사이트를 참조한다.
• 어떠한 오픈소스를 사용해야 라이선스에 문제가 없을지 판단이 어려운 경우에는 전자정부 표준 프레임워크에서 사용 중인 오픈소스 소프트웨어를 참조한다.

02 소프트웨어 개발 방법론

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

① 구조적 방법론의 절차

② 구조적 방법론의 특징

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

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

① 정보공학 방법론의 절차

② 정보공학 방법론의 특징

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

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

① 객체지향 방법론의 절차 :
요구분석 -> 설계 -> 구현 -> 시험 -> 인수

② 객체지향 방법론의 특징

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

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

① 컴포넌트 기반 방법론의 절차 :
개발 준비 -> 분석 -> 설계 -> 구현 -> 시험 -> 전개 -> 인도

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

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

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

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

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

① 애자일 방법론의 등장 배경

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

② 애자일 방법론의 정의

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

③ 애자일 방법론의 특징

• 프로세스와 도구 중심이 아닌 개발 과정의 소통을 중요하게 생각하는 소프트웨어 개발 방법론으로 반복적인 개발을 통한 잦은 출시를 목표로 한다.
• 기존 모형(폭포수 모형, 프로토타입 모형, 나선형 모형)의 문제점을 보완한 모형이다.
• 소프트웨어를 점증적으로 개발한다.
• 출시 주기를 짧게 하여 다양한 요구 변화에 대응한다.
• 고객과 개발팀의 소통, 개발팀원 간의 소통, 협력을 극대화한다.
• 인간의 수행 능력을 높이기 위한 현실적인 방법을 제시한다.
• 가볍과 실용적인 소프트웨어 개발 방법론이다.
• 애자일 방법론을 소프트웨어 개발 방법론의 방법론이라고 한다.

④ 애자일 방법론의 선언문

• 대형화, 복잡한 개발 방법론보다는 현실적이고 가벼운 소프트웨어 개발을 지지하는 애자일 방법론 지지자들이 모여 2001년에 4가지 애자일 선언문을 발표하였다.

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

• 애자일 모형의 도입으로 프로세스와 도구 문서 작업, 계약의 협상, 계획의 수행을 무시하는 것이 아님을 주의한다.

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

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

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

• 소프트웨어 개발 방식을 애자일 모형으로 개발하는 대표적인 방법이다.
• 전통적인 소프트웨어 개발 방법론과는 달리 문서화를 강조하지 않고 변경을 추구하며, 개발 초기부터 소프트웨어 검사를 병행할 것을 강력히 권고하는 새로운 방법론이다.
• 의사소통의 개선과 즉각적인 피드백에 의한 단순한 코딩으로 소프트웨어 품질을 높이는 방법이다.
• 12개의 실천 항목을 적용한다.
• 애자일 방법론의 5가지(의사소통, 용기, 피드백, 단순함, 존경) 가치를 실현한 방법론이다.

<XP의 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 : 오버타임 지양

⑧ 스크럼(SCRUM)

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

<스크럼의 5가지 가치>

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

<스크럼의 요소>

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

⑨ 린(Lean)

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

<린 방법론의 7가지 원칙>

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

⑩ DSDM(Dynamic Systems Development Method)

• 동적 시스템 개발 방법이다.
• RAD 방식으로 개발하여 소프트웨어의 개발 여부를 판단하는 방식이다.
• DSDM은 애자일 프로젝트 프레임워크로 개정되면서 소프트웨어 개발과 코드 작성보다는 프로젝트 관리, 솔루션 전달의 일반적인 접근 방식으로 발전되었다.
• DSDM의 5단계
• 1. 타당성 조사 : RAD 방식으로 개발하여 소프트웨어의 개발 여부를 판단한다.
• 2. 비지니스 연구 : 사용자의 요구사항을 분석한다.
• 3. 기능 모델 반복 : 프로토타입을 개발하여 사용자의 요구사항을 받아들인다.
• 4. 설계 : 반복된 모델로 최종 설계를 한다.
• 5. 구현 : 설계 자료를 구현하며 테스트 단계를 통하여 최종 결과물을 만들어낸다.

<DSDM의 원칙>

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

⑪ FDD(기능 중심 개발) 방법

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