맨위로가기

소프트웨어 개발 방법론

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 개발 방법론은 정보 시스템의 소프트웨어 개발 프로세스를 구조화하고 제어하기 위한 프레임워크로, 시스템 개발 생명 주기(SDLC)를 시작으로 다양한 방법론들이 발전해 왔다. 1960년대 SDLC는 대규모 비즈니스 시스템 개발에 사용되었으며, 1990년대에는 객체 지향 프로그래밍과 애자일 방법론이 등장했다. 소프트웨어 개발 방법론에는 폭포수 모델, 프로토타이핑, 나선형 모델 등이 있으며, 래셔널 통합 프로세스(RUP)와 애자일 통합 프로세스(AUP)와 같은 프레임워크가 존재한다. 이러한 방법론을 지원하기 위해 CASE, 통합 개발 환경(IDE), 모델링 언어, 프로그래밍 패러다임, 소프트웨어 프레임워크 등의 도구와 기술이 활용된다.

더 읽어볼만한 페이지

  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
소프트웨어 개발 방법론
소프트웨어 개발 프로세스
활동과 단계요구사항 분석
기능 명세
구조
설계
구현
테스팅
배치
유지보수
개발 모형
개발 모형 목록애자일 소프트웨어 개발
클린룸
DSDM
순차점증적 개발
반복형 개발
RAD
RUP
나선 모형
폭포수 모델
익스트림 프로그래밍
스크럼
V 모델
TDD
지원 활동
지원 활동 목록구성 관리
문서화
품질보증
프로젝트 관리
사용자 경험 설계
도구
소프트웨어 개발 도구컴파일러
디버거
프로파일러
GUI 디자이너
통합 개발 환경
중심 활동
중심 활동 목록소프트웨어
소프트웨어 개발
요구 분석
소프트웨어 아키텍처
소프트웨어 설계
소프트웨어 엔지니어링
프로그래밍
소프트웨어 테스트
디버깅
소프트웨어 배포
소프트웨어 유지보수
파라다임 및 모델
파라다임 및 모델 목록애자일 소프트웨어 개발
소프트웨어 클린룸
반복적 개발
소프트웨어 프로토타이핑
나선 모델
V 모델
워터폴 모델
소프트웨어 개발 방법론 및 프레임워크
소프트웨어 개발 방법론 및 프레임워크 목록DevOps
사용자 기능 기반 개발
반복적 개발
칸반
모델 구동 공학
고속 애플리케이션 개발
래셔널 통합 프로세스
스크럼
통합 프로세스
익스트림 프로그래밍
개발 지원
개발 지원 목록소프트웨어 구성 관리
소프트웨어 문서화
소프트웨어 품질 보증
소프트웨어 프로젝트 관리
사용자 경험
관행
관행 목록행동 주도 개발
지속적 통합
지속적 전달
도메인 주도 설계
짝 프로그래밍
테스트 주도 개발
프로그래밍 도구
프로그래밍 도구 목록컴파일러
디버거
링커
성능 분석
GUI 빌더
통합 개발 환경
빌드 자동화
애플리케이션 릴리스 자동화
표준 및 기관
표준 및 기관 목록BABOK
IEEE Standards Association
ISO 9001
PMBOK
SWEBOK
ITIL

2. 역사

소프트웨어 및 정보 시스템은 특정 목적을 달성하기 위해 개발된다. 개발을 하나의 프로세스 ('''소프트웨어 개발 프로세스''')로 간주하면, 개발 방식에 따라 다양한 구조, 규칙, 원칙이 발견된다. 이러한 일련의 규칙과 지침으로 구성된 개발 방식을 소프트웨어 개발 방법론이라고 한다. 또한 다양한 개발 방식에 공통적이거나 특수한 규칙을 연구하는 소프트웨어 공학 분야도 소프트웨어 개발 방법론이라고 한다.

소프트웨어 개발 방법론(SDM) 프레임워크는 1960년대에 탄생했다. Elliott (2004)에 따르면, 정보 시스템 구축을 위한 가장 오래된 정형화된 방법론 프레임워크는 시스템 개발 생명 주기(SDLC)이다. 1960년대 당시에는 주로 대규모 기업의 비즈니스 시스템 개발이 중심이었고, 정보 시스템은 데이터 처리와 수치 계산에 중점을 두었다.[2]

이후 구체적인 소프트웨어 개발 방법론이 개별 조직이나 프로젝트에 적용되기 시작했는데, 연대순으로 살펴보면 다음과 같다.

연도내용
1970년대구조적 프로그래밍(1969년), 캡 제미니 SDM(1974년)
1980년대SSADM(1980년), 정보 요구 분석/소프트 시스템 방법론
1990년대객체 지향 프로그래밍(1960년대 초부터, 1990년대 중반 주류), RAD(1991년), DSDM(1994년), 스크럼(1995년), 팀 소프트웨어 프로세스(1998년), 익스트림 프로그래밍(1999년)


2. 1. 1960년대

정보 시스템 구축을 위한 가장 오래된 정형화된 방법론 프레임워크는 시스템 개발 생명 주기(SDLC)이다. SDLC는 정보 시스템을 계획적이고 구조화된 형태로 개발하려면 아이디어 구상부터 최종 시스템 배포까지, 적용하는 프레임워크의 맥락 속에서 개발 공정의 각 단계를 순차적으로 실행해야 한다는 생각을 바탕으로 한다.[2] 1960년대의 이 방법론 프레임워크는 주로 거대 기업의 대규모 비즈니스 시스템 개발을 대상으로 하였으며, 당시의 정보 시스템은 막대한 데이터 처리와 수치 처리를 중심으로 한 것이었다.[2]

2. 2. 1970년대

구조적 프로그래밍은 1969년부터 사용되었다. 캡 제미니 SDM은 네덜란드 기업 PANDATA에서 개발되었으며, 1974년에 영어권에 소개되었다. 여기서 SDM은 System Development Methodology의 약자이다.

2. 3. 1980년대

SSADM (구조적 시스템 분석 및 설계 방법)은 1980년부터 사용되었다.[1] 정보 요구 분석/소프트 시스템 방법론도 이 시기에 사용되었다.[1]

2. 4. 1990년대


  • 객체 지향 프로그래밍(OOP)은 1960년대 초부터 있었지만, 1990년대 중반에 주역으로 떠올랐다.
  • RAD는 1991년부터 사용되었다.
  • Dynamic systems development method|DSDM영어는 1994년부터 사용되었다.
  • 스크럼은 1995년부터 사용되었다.
  • Team software process|팀 소프트웨어 프로세스영어는 1998년부터 사용되었다.
  • 익스트림 프로그래밍은 1999년부터 사용되었다.

2. 5. 2000년대

3. 소프트웨어 개발 접근법

소프트웨어 개발 및 정보 시스템은 목적을 달성하기 위해 개발된다. 개발을 하나의 프로세스 ('''소프트웨어 개발 프로세스''')로 간주하면, 개발 스타일에 따라 다양한 구조, 제약 (규칙), 원칙이 발견된다. 일련의 규칙과 지침으로 구성된 하나의 개발 스타일을 소프트웨어 개발 방법론이라고 한다. 또한 다양한 스타일에 공통적이거나 특수한 규칙을 연구하는 소프트웨어 공학 분야도 소프트웨어 개발 방법론이라고 한다.[3]

소프트웨어 개발 방법론 프레임워크의 구체적인 예는 다음과 같다.


  • 1970년대
  • * 구조적 프로그래밍 - 1969년부터
  • * 캡 제미니 SDM - 네덜란드의 PANDATA라는 기업에서 탄생했다. 영어권에 소개된 것은 1974년이다. 이 경우의 SDM은 System Development Methodology의 약자이다.
  • 1980년대
  • * SSADM (구조적 시스템 분석 및 설계 방법) - 1980년부터
  • 1990년대
  • * 객체 지향 프로그래밍 (OOP) - 1960년대 초부터 있었지만, 1990년대 중반에 주역으로 떠올랐다.
  • * RAD - 1991년부터
  • * DSDM (Dynamic systems development method) - 1994년부터
  • * 스크럼 - 1995년부터
  • * 팀 소프트웨어 프로세스 - 1998년부터


정보기술이 태어났을 때부터 여러 소프트웨어 개발 기법이 사용되어 왔으며, 주요한 것은 다음과 같다.[3]

  • 폭포수 모델 - 직선적인 프레임워크
  • 소프트웨어 프로토타이핑 - 반복적인 프레임워크
  • 점증적 모델 - 직선적인 요소와 반복적인 요소를 조합한 프레임워크
  • 나선형 모델 - 직선적인 요소와 반복적인 요소를 조합한 프레임워크
  • RAD - 반복적인 프레임워크


폭포수 모델은 순차적인 개발 방법론으로, 요구 분석・설계・구현・테스트(평가)・통합・유지보수와 같이 물이 낮은 곳으로 흘러가듯이 상위 단계에서 하위 단계로 순차적으로 이행한다. 이 기법을 처음으로 정립한 것은 윈스턴 W. 로이스의 1970년 논문으로 알려져 있지만[4], 로이스 자신은 "폭포수"라는 용어를 이 논문에서 사용하지 않았다.

폭포수 모델의 기본 원칙은 다음과 같다.[3]

  • 프로젝트는 순차적인 공정으로 나뉘며, 공정 간 약간의 중복과 되돌림이 허용된다.
  • 계획, 스케줄, 일정, 예산 등을 중시하며, 시스템 전체를 한 번에 구현하는 것을 특징으로 한다.
  • 다양한 문서를 작성하고, 공식적인 검토를 하며, 어떤 공정에서 다음 공정으로 이행할 때 사용자 또는 IT 관리자의 승인을 필요로 한다.


소프트웨어 프로토타이핑은 개발해야 할 소프트웨어의 불완전한 버전인 프로토타입을 (몇 번) 개발 중에 작성하는 개발 방법론이다. 프로토타이핑의 기본 원칙은 다음과 같다.[3]

  • 단독으로 사용할 수 있는 완비된 개발 방법론이 아니라, 다른 개발 방법론에 더하여 사용된다.
  • 대형 프로젝트에 따르는 위험을 줄이기 위해, 프로젝트를 작은 부분으로 분할하여 개발 중의 수정을 용이하게 하는 수단을 제공한다.
  • 프로토타입은 사용자에게 제시하는 것이며, 사용자가 개발 프로세스에 장기적으로 관여하게 된다. 따라서 최종적인 구현을 사용자가 수용하기 쉬워진다.
  • 프로토타입에 반복적으로 수정을 가하여, 사용자의 요구를 충족하도록 한다.
  • 프로토타입은 최종적으로 버려지는 경우가 많지만, 최종적인 시스템이 프로토타입을 발전시켜 만들어지는 경우도 있다.
  • 프로토타이핑에 의해, 개발자와 사용자 간의 근본적인 오해를 조기에 해결할 수 있다.


반복적 개발은 프로젝트를 작은 부분으로 분할하여 개발 과정 중의 수정을 용이하게 하고, 프로젝트의 리스크를 줄이는 방법론이다. 반복적 개발의 기본 원칙은 다음과 같다.[3]

  • 워터폴을 소규모로 여러 번 반복한다. 한 번의 워터폴은 시스템 내의 작은 부분을 완성하는 것이다.
  • 전체 요구 사항은 반복을 수행하기 전에 정의된다.


나선형 모델은 하향식 설계와 상향식 설계의 각 장점을 활용한 것으로, 설계와 프로토타이핑 과정을 반복하는 방법이다. 이는 일종의 메타 모델로, 다른 모델들이 활용할 수 있다. 나선형 모델의 기본 원칙은 다음과 같다.[3]

  • 프로젝트의 리스크를 최소화하는 것을 주안점으로, 작은 부분으로 분할하여 개발 과정에서의 수정을 용이하게 하고, 리스크 재평가의 기회를 제공하며, 프로젝트 지속 여부를 검토할 수 있도록 한다.
  • 각 사이클은 동일한 일련의 과정으로 이루어져 있으며, 제품 전체의 개념을 개별 프로그램의 코딩에 이르기까지 구체화하고, 한 번의 사이클로 하나의 부분을 완성하거나 전체를 개선한다.[5]
  • 하나의 사이클은 (1) 해당 반복의 목적, 선택 사항, 제약 조건 결정, (2) 선택 사항 평가, 리스크 식별 및 해결, (3) 구체적인 개발 및 해당 사이클 결과물 평가, (4) 다음 반복 계획 수립, 이렇게 4가지로 나뉜다.[6]
  • 각 사이클은 이해 관계자와 그들의 성공 조건을 식별하는 것으로 시작하여, 검토 및 확정으로 끝난다.[7]


RAD (Rapid Application Development, 급속 애플리케이션 개발)는 프로토타입을 반복적으로 개발·구축해 나가는 소프트웨어 개발 방법론이다. 원래는 1991년에 제임스 마틴이 제창한 소프트웨어 개발 프로세스를 가리키는 말이다. RAD의 기본 원칙은 다음과 같다.[3]

  • 고품질의 시스템을 상대적으로 낮은 비용으로 신속하게 개발하는 것을 목표로 한다.
  • 프로젝트에 따르는 위험을 줄이기 위해 작은 부분으로 분할하여 개발 중 수정을 용이하게 한다.
  • 고품질의 시스템을 신속하게 만들기 위해 반복적인 프로토타이핑을 수행하고, 사용자를 적극적으로 참여시키며, 고도화된 개발 도구를 활용한다. 도구로는 예를 들어 GUI 빌더, CASE 툴, 데이터베이스, 4GL, 코드 생성기, 객체 지향 기술 등을 활용한다.
  • 비즈니스 요구 사항을 충족하는 데 중점을 두며, 기술적으로 세련되었는지는 그다지 중요하게 생각하지 않는다 (자동 생성된 코드는 일반적으로 세련되지 않다).
  • 개발해야 할 기능 그룹에 우선 순위를 부여하고, 몇 가지 기능별로 납기를 정한다. 프로젝트가 지연되면 납기를 연기하지 않고, 구현할 기능을 줄인다.
  • 일반적으로 JAD를 포함한다. JAD는 사용자가 시스템 설계에 적극적으로 참여하는 방법이며, 사용자의 요구 사항을 반영하기 쉽다.
  • 프로토타입을 버리지 않고, 제품을 반복적으로 개선해 나간다고 생각한다.
  • 향후 개발 및 유지보수에 도움이 되는 문서를 작성한다.
  • 표준적인 시스템 분석·설계 기법을 이 프레임워크에 도입할 수 있다.

3. 1. 전통적인 방법론

소프트웨어 개발 접근법에는 전통적으로 폭포수 모델, 프로토타이핑, 진화적 모델, 나선형 모델, 고속 개발 도구 등이 쓰여왔다.

정보 시스템 구축을 위한 가장 오래된 정형화된 방법론 프레임워크는 시스템 개발 생명 주기(SDLC)이다. SDLC는 정보 시스템을 계획적이고 구조화된 형태로 개발하기 위해 아이디어 탄생부터 최종 시스템 배포까지, 개발 공정의 각 단계를 순차적으로 실행해야 한다는 생각을 바탕으로 한다.[2] 1960년대에는 거대 기업의 대규모 비즈니스 시스템 개발에 주로 사용되었으며, 당시 정보 시스템은 막대한 데이터 처리와 수치 처리를 중심으로 하였다.[2]

소프트웨어 개발 방법론은 개발 프로세스를 구조화하고 계획하며 제어하기 위한 프레임워크이며, 프로젝트 팀이 애플리케이션 개발 및 유지 보수를 위해 생성·구축하는 결과물의 사전 정의 등도 포함된다.[3] 이러한 프레임워크는 오랜 세월 동안 다양하게 고안되었으며, 각각 장점과 단점이 있다. 어떤 소프트웨어 개발 방법론 프레임워크가 모든 프로젝트에 적합한 것은 아니며, 기술적, 조직적인 면을 고려하면 각 방법론 프레임워크마다 적합한 종류의 프로젝트가 있다.[3]

소프트웨어 개발 프레임워크는 이를 더욱 발전시키고 사용을 지원하며, 해당 방법론 프레임워크의 보급에 힘쓰는 조직이 존재한다. 방법론 프레임워크는 일종의 공식적인 문서로 정의되는 경우가 많다.

3. 2. 현대적인 방법론

4. 관련 도구 및 기술

컴퓨터 지원 소프트웨어 공학(CASE), 통합 개발 환경(IDE), 모델링 언어, 프로그래밍 패러다임, 소프트웨어 프레임워크는 소프트웨어 개발 과정에서 다양하게 활용되는 도구 및 기술이다.

4. 1. CASE

컴퓨터 지원 소프트웨어 공학(CASE)은 고품질이며 유지보수가 용이한 소프트웨어 제품을 만들기 위해 툴 등을 이용하는 것이다.[11] 정보 시스템의 소프트웨어 개발 공정에서 자동화 툴을 이용하는 기법을 가리킨다.[12] CASE 툴에는 분석용, 설계용, 코드 생성용 등이 있으며, 소정의 프로그래밍 언어의 구조화된 코드를 생성하거나 문서를 생성한다.[13]

CASE의 기본이 되는 생각은 다음 두 가지이다.[14]

주요 CASE 툴로는 구성 관리, 데이터 모델링, 모델 변환, 리팩토링, 자동 프로그래밍, UML과 같은 툴이 있다.

4. 2. 통합 개발 환경

'''통합 개발 환경'''(integrated development environment|통합 개발 환경영어, '''IDE''')은 프로그래머가 소프트웨어를 개발할 때 포괄적인 기능을 제공하는 응용 소프트웨어이다. IDE에는 일반적으로 다음과 같은 기능이 갖춰져 있다.

Anjuta - C 및 C++용 IDE (GMONE)


IDE는 프로그래머의 생산성을 최대화하도록 설계되었으며, 이를 위해 통일감 있는 사용자 인터페이스의 구성 요소들이 긴밀하게 연동되도록 되어 있다. 일반적으로 특정 프로그래밍 언어 전용으로 제작되어, 해당 언어의 프로그래밍 패러다임에 맞는 기능들을 제공할 수 있다.

4. 3. 모델링 언어

뷰 모델(View model)은 시스템과 이를 둘러싼 환경의 뷰포인트를 제공하는 프레임워크이며, 소프트웨어 개발 공정에서 사용된다. 뷰의 근본적인 의미론은 그래픽으로 표현된다.

정보의 현재 상태를 그래픽으로 표현하는 것은 사용자와 시스템 개발자 모두에게 효과적으로 정보를 표현하는 수단을 제공한다.

모델링 언어는 정보, 지식, 시스템을 구조적으로 표현하는 데 사용되는 인공 언어이며, 일관된 규칙으로 정의된다. 이러한 규칙들은 구조 내 각 구성 요소의 의미를 나타내기 위한 것이다. 모델링 언어는 그래픽적인 것과 문자만으로 구성된 것이 있다.[15] 그래픽 모델링 언어는 어떤 개념을 나타내는 이름이 붙은 기호와 이들 간의 관계를 나타내는 기호를 연결하는 선으로 이루어진 다이어그램을 표현으로 채택하며, 여기에 제약을 나타내는 그래픽 주석을 더한다. 문자만으로 이루어진 모델링 언어는 매개변수를 동반하는 표준화된 키워드를 사용하는 것이 일반적이며, 컴퓨터가 해독 가능한 표현으로 만든다.

소프트웨어 공학 분야의 그래픽 모델링 언어로는 다음과 같은 것들이 있다.

  • BPMN (Business Process Modeling Notation, 그리고 XML을 기반으로 하는 BPML)는 프로세스 모델링 언어 중 하나이다.
  • EXPRESS와 EXPRESS-G (ISO 10303-11)는 범용 데이터 모델링 언어의 국제 표준 (STEP의 일부)이다.
  • Extended Enterprise Modeling Language (EEML)은 다층적인 비즈니스 프로세스 모델링에 자주 사용된다.
  • 순서도는 알고리즘이나 작업 공정의 개략을 표현하는 그림이다.
  • Fundamental Modeling Concepts (FMC)는 소프트웨어 중심 시스템을 위한 모델링 언어이다.
  • IDEF는 모델링 언어 제품군이며, 기능 모델링을 위한 IDEF0, 정보 모델링을 위한 IDEF1X, 모델링 온톨로지를 위한 IDEF5 등이 포함된다.
  • LePUS3는 객체 지향 비주얼 설계 기술 언어이며, (Java, C++, C# 등으로 작성되는) 대규모 객체 지향 프로그램이나 디자인 패턴의 모델링에 적합한 형식 명세 기술 언어이다.
  • 명세 및 기술 언어 (Specification and Description Language, SDL)는 분산 시스템 등의 행위를 명세로 명확하게 기술하기 위한 명세 기술 언어이다.
  • UML (Unified Modeling Language, 통합 모델링 언어)은 업계 표준의 범용 모델링 언어이다. 최신 버전인 UML 2.0은 13가지 종류의 다이어그램을 지원하며, 다양한 지원 도구가 있다.


모델링 언어는 반드시 실행 가능하지 않으며, 실행 가능하다 하더라도, 이를 사용함으로써 인간 프로그래머가 불필요해지는 것은 아니다. 오히려 실행 가능한 모델링 언어는 숙련된 프로그래머의 생산성 향상을 의도하며, 특히 병렬 계산이나 분산 컴퓨팅과 같은 어려운 문제를 다루기 쉽게 만들어준다.

4. 4. 프로그래밍 패러다임

프로그래밍 패러다임은 컴퓨터 프로그래밍의 근본적인 스타일이며, 이와 대조적으로 소프트웨어 개발 방법론은 특정 소프트웨어 공학 문제를 해결하는 스타일이다. 개별 패러다임은 객체, 함수, 변수, 제약 조건 등 프로그램의 요소와 할당, 평가, 처리 흐름, 데이터 흐름 등 처리 단계를 표현하는 개념과 추상화가 각각 고유하다.

프로그래밍 언어는 어떤 프로그래밍 패러다임을 지원할 수 있다. 예를 들어 C++나 Object Pascal로 작성된 프로그램은 순수하게 절차적으로 작성할 수도 있고, 순수하게 객체 지향적으로 작성할 수도 있으며, 두 패러다임의 요소를 모두 포함하는 프로그램으로 작성할 수도 있다. 객체 지향 프로그래밍에서는 프로그래머가 프로그램을 상호 작용하는 객체들의 집합으로 생각할 수 있으며, 함수형 프로그래밍에서는 상태를 갖지 않는 함수 평가의 나열로 생각할 수 있다. 다수의 프로세서를 가진 컴퓨터나 시스템에서의 프로그래밍에서는 process-oriented programming|프로세스 지향 프로그래밍영어을 채택함으로써, 자료 구조를 논리적으로 공유하고 병행 동작하는 프로세스 군으로 생각하여 프로그래밍할 수 있다.[1]

소프트웨어 공학에 다양한 "방법론"이 있듯이, 프로그래밍 언어는 각각 다른 "프로그래밍 패러다임"을 권장한다. 단일 패러다임을 지원하도록 설계된 언어 (예: 객체 지향 프로그래밍을 지원하는 스몰토크, 함수형 프로그래밍을 지원하는 하스켈 등)도 있으며, 여러 패러다임을 지원하는 언어 (Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, 파이썬, 루비, Oz 등)도 있다.

많은 프로그래밍 패러다임에는 그것에 의해 가능해지는 것과 반대로 "금지"되는 것이 있다. 예를 들어 순수한 함수형 프로그래밍에서는 부작용의 사용이 금지되어 있다. 또한, 구조적 프로그래밍에서는 GOTO 문의 사용이 금지되어 있다.

4. 5. 소프트웨어 프레임워크

소프트웨어 프레임워크는 소프트웨어 시스템 또는 서브 시스템의 재사용 가능한 설계이다. 소프트웨어 프레임워크는 지원 프로그램, 라이브러리, 스크립트 언어, 컴포넌트 그룹의 결합을 지원하는 소프트웨어 등으로 구성된다. 프레임워크의 각 부분은 응용 프로그래밍 인터페이스를 공개하는 경우가 있다.

참조

[1] 논문 Comparative study on software development methodologies 2014
[2] 서적 Global Business Information Technology: an integrated systems approach Pearson Education 2004
[3] 간행물 Selecting a development approach http://www.cms.gov/R[...] Centers for Medicare & Medicaid Services (CMS) Office of Information Service 2008-03-27
[4] 웹사이트 Wasserfallmodell > Entstehungskontext http://cartoon.iguw.[...] 2007-11-28
[5] 논문 "A Spiral Model of Software Development and Enhancement" ACM 1986-08
[6] 서적 Tutorial: software engineering project management Computer Society Press of the IEEE 1986
[7] 서적 Software cost estimation with Cocomo II: Volume 1 2000
[8] 서적 Unified Software Engineering with Java 2006
[9] 간행물 Concepts for Automating Systems Integration http://www.mel.nist.[...] NIST 2003
[10] 간행물 Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. http://www.osti.gov/[...] Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group 1993
[11] 학술대회 Selecting and effectively using a computer aided software engineering tool 1989-11-06
[12] 서적 System Requirements Engineering McGraw-Hill 1995
[13] 웹사이트 CASE definition http://www.its.bldrd[...] 2008-10-26
[14] 서적 Putting the Software Engineering into CASE John Wiley and Sons Inc. 1992
[15] 학술대회 A metamodel for the notation of graphical modeling languages 2007-07-24


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com