소프트웨어공학: 두 판 사이의 차이
잔글
→소프트웨어 개발 프로세스
잔글 (→소프트웨어 개발 프로세스) |
잔글 (→소프트웨어 개발 프로세스) |
||
| 21번째 줄: | 21번째 줄: | ||
* 프로토타입 패러다임(Prototype Paradigm): 기능의 일부만 구현되었으나 그 자체로는 완전한 기능을 하는 프로토타입(원형)을 먼저 만들어 공개한 다음 모든 요구 사항이 구현된 완성품에 도달할 때까지 기능들을 조금씩 추가해나가는 방법이다. 프로토타입 제작 단계에서 제품 기획 단계에서 생각하지 못한 추가적인 기능과 문제점을 발견 가능하고 기획을 더 명료하게 할 수 있으며, 완성품의 가능성과 유용성을 증명할 수 있다는 점에서 제품/서비스 개발 프로세스를 안정화하기 쉽다. 보통 1자형으로 프로세스가 구성되는 폭포수 모델과 달리 프로토타입 패러다임은 원형으로 프로세스가 구성되어 설계와 개발, 평가와 피드백이 순환하는 구조로 되어 있다. 다만 기능을 계속 추가하다가 시제품과 완제품의 제품 기획과 성격이 판이하게 달라질 수 있다는 위험이 있다. | * 프로토타입 패러다임(Prototype Paradigm): 기능의 일부만 구현되었으나 그 자체로는 완전한 기능을 하는 프로토타입(원형)을 먼저 만들어 공개한 다음 모든 요구 사항이 구현된 완성품에 도달할 때까지 기능들을 조금씩 추가해나가는 방법이다. 프로토타입 제작 단계에서 제품 기획 단계에서 생각하지 못한 추가적인 기능과 문제점을 발견 가능하고 기획을 더 명료하게 할 수 있으며, 완성품의 가능성과 유용성을 증명할 수 있다는 점에서 제품/서비스 개발 프로세스를 안정화하기 쉽다. 보통 1자형으로 프로세스가 구성되는 폭포수 모델과 달리 프로토타입 패러다임은 원형으로 프로세스가 구성되어 설계와 개발, 평가와 피드백이 순환하는 구조로 되어 있다. 다만 기능을 계속 추가하다가 시제품과 완제품의 제품 기획과 성격이 판이하게 달라질 수 있다는 위험이 있다. | ||
* 나선형 모델(Spiral Model): 폭포수 모델과 프로토타입 패러다임에 위험 분석을 추가해 각 순환마다 위험 평가를 통해 계속 개발할지, 개발을 중단할지 평가하는 체계다. 보통 장기 프로젝트나 국책 IT 사업에 유리한 모델이나 일반적인 상품 기획법으로는 프로젝트 관리의 기준과 평가에 투입할 자원 문제로 쉽지 않은 방법이다. | * 나선형 모델(Spiral Model): 폭포수 모델과 프로토타입 패러다임에 위험 분석을 추가해 각 순환마다 위험 평가를 통해 계속 개발할지, 개발을 중단할지 평가하는 체계다. 보통 장기 프로젝트나 국책 IT 사업에 유리한 모델이나 일반적인 상품 기획법으로는 프로젝트 관리의 기준과 평가에 투입할 자원 문제로 쉽지 않은 방법이다. | ||
* 4세대 기법(4th Generation Techniques): | * 4세대 기법(4th Generation Techniques): CASE 와 정형 명세 언어로 대표되는 기계적 도구의 도움을 받아 명세서로부터 실행 코드를 자동으로 생성할 수 있는 방법이다. 코드 최적화 난이도가 올라가고 불필요한 코드 추가 가능성으로 인해 코드의 유지보수도 어려워지는 등 생성한 결과의 신뢰성 문제로 아직 도입이 빠르지 않으나 생성형 AI가 이 부분에 있어서 엄청난 발전을 선사할 가능성이 제기되었고, [[마이크로소프트|Microsoft]] Copilot 등의 가시적 성과가 나타나고 있다. | ||
* 애자일 방법론(Agile Method): 21세기 들어서는 시점에서 제안된 방법론으로, 프로세스와 도구 못지 않게 고객과의 원활한 커뮤니케이션이 성공적인 소프트웨어 개발에 중요하다는 관점 하에 모든 개발 요구 사항을 추상적이고 큰 규모의 요구 사항에서 구체적이고 자잘한 수많은 세부 사항으로 나눈 다음 고객과 실시간으로 소통하면서 하나씩 iteration으로 구현해나가는 방법이다. 고객의 요구사항이 한 달 안에 구현할 수 있을 정도로 많지 않지만 자주 변화하는 경우에는 민감하게 반응할 수 있으나, 반대로 한 달 정도로는 끝내지 못할 정도로 요구사항이 많은 거대 프로젝트에서는 프로젝트가 엎어질 위험성이 상당히 크다. 그 외에 애자일 방법론은 기술적 진보가 빠른 경우 요구사항 분석 오류나 아키텍처 상의 오류, 테스트 실수, 문서화 오류로 인해 기술적 부채(Technical Debt)가 빠르게 증가하는 경향을 억제하는 데에 도움이 되는 편이다. | * 애자일 방법론(Agile Method): 21세기 들어서는 시점에서 제안된 방법론으로, 프로세스와 도구 못지 않게 고객과의 원활한 커뮤니케이션이 성공적인 소프트웨어 개발에 중요하다는 관점 하에 모든 개발 요구 사항을 추상적이고 큰 규모의 요구 사항에서 구체적이고 자잘한 수많은 세부 사항으로 나눈 다음 고객과 실시간으로 소통하면서 하나씩 iteration으로 구현해나가는 방법이다. 고객의 요구사항이 한 달 안에 구현할 수 있을 정도로 많지 않지만 자주 변화하는 경우에는 민감하게 반응할 수 있으나, 반대로 한 달 정도로는 끝내지 못할 정도로 요구사항이 많은 거대 프로젝트에서는 프로젝트가 엎어질 위험성이 상당히 크다. 그 외에 애자일 방법론은 기술적 진보가 빠른 경우 요구사항 분석 오류나 아키텍처 상의 오류, 테스트 실수, 문서화 오류로 인해 기술적 부채(Technical Debt)가 빠르게 증가하는 경향을 억제하는 데에 도움이 되는 편이다. | ||
** 이때 애자일 방법론 적용과 기술적 부채 억제를 병행하려면 객체 지향 프로그래밍 도입과 비효율적으로 작성된 코드를 교체하는 코드 리팩토링은 필수다. 보통 데이터 타입 등만 미세하게 다른 중복된 구조의 코드, 기능을 불필요하게 몰아 넣어 지나치게 길어진 메서드, 너무 거대해진 클래스 등의 객체를 각각 제네릭 타입 사용 코드, 메소드 분할, 객체 분할 및 상속으로 대체하게 된다. | ** 이때 애자일 방법론 적용과 기술적 부채 억제를 병행하려면 객체 지향 프로그래밍 도입과 비효율적으로 작성된 코드를 교체하는 코드 리팩토링은 필수다. 보통 데이터 타입 등만 미세하게 다른 중복된 구조의 코드, 기능을 불필요하게 몰아 넣어 지나치게 길어진 메서드, 너무 거대해진 클래스 등의 객체를 각각 제네릭 타입 사용 코드, 메소드 분할, 객체 분할 및 상속으로 대체하게 된다. | ||
* 컴포넌트 기반 개발: 프로그램을 기능 꾸러미인 컴포넌트(Component)를 조립하는 방식으로 개발하는 방법이다. 컴포넌트는 그 자체로는 이미 완성되었고 단지 독립적인 실행이 되지 않을 뿐이다. 이를 위해서는 컴포넌트 개발 프로세스와 컴포넌트 조립 프로세스가 분리되어야 한다. | * 컴포넌트 기반 개발: 프로그램을 기능 꾸러미인 컴포넌트(Component)를 조립하는 방식으로 개발하는 방법이다. 컴포넌트는 그 자체로는 이미 완성되었고 단지 독립적인 실행이 되지 않을 뿐이다. 이를 위해서는 컴포넌트 개발 프로세스와 컴포넌트 조립 프로세스가 분리되어야 한다. | ||