[Object Oriented S/E] Chapter 2 - Software Process and Methodology(1)

 

# 범위

16page ~ 30page

• 2.1 CHALLENGES OF SYSTEM DEVELOPMENT (시스템 개발의 과제)
• 2.2 SOFTWARE PROCESS
• 2.3 MERITS AND PROBLEMS OF THE WATERFALL PROCESS ( 폭포수 과정의 장단점)
• 2.4 SOFTWARE DEVELOPMENT IS A WICKED PROBLEM
• 2.5 SOFTWARE PROCESS MODELS 

# 내용

## 2.1 CHALLENGES OF SYSTEM DEVELOPMENT

• 실험실 또는 학부에서 소프트웨어를 개발한것과 현실세계(현업)에서 개발하는 것은 상당히 큰 차이를 갖고 있다. 그렇기 때문에 왜 소프트웨어 프로세스와 방법론이 필요한지 알 수 있다.
• 현실에서는, 1년에서 몇년까지의 긴 개발 기간을 가지고 있다. 그렇기 때문에 향후 몇년간 어떤일이 일어나고 변화할지를 정확히 알 수 없는 상태에서 개발해야한다(과제).
• 현실에서는, 다른 부서와 팀과의 협력을 해야한다. 그렇기 때문에 어떻게 상호 의존적인 부분으로 작업을 나누고 팀에게 할당하고 다시 원할히 합칠 수 있을까(과제).
• 현실에서는, 부서나 팀별로 다른 개발방법이나 프로세스를 도구를 사용한다. 그렇기 때문에 어떻게 적절히 나누고 팀간 원할히 소통할 수 있을까(과제)?
• 현실에서는, 엄격한 실시간 제약이 적용되는데 메일의 경우 40,000개 이상의, 또는 초당 12개씩 철리해야한다. 어떻게 이러한 요구사항을 충족시키는 시스템을 개발할 수 있을 것인가(과제)?
• 현실에서는, 요구사항이 계속해서 변화한다. 이러한 예측불가능한 요구사항의 변화를 적절히 수용할 수 있도록 개발할 수 있을까(과제)?
• 현실에서는, 문서화되지않은 오래된 시스템들에 대한 유지보수가 필요하다. 어떻게하면 쉽게 시스템의 타격없이 변화할수 있도록 할까(과제)
• 현실에서는, 여러 플랫폼들에 대한 실행이 필요하다. 이러한 하드웨어에 대한 의존성을 숨기고 개발할 수 있을까(과제)

 

## 2.2 SOFTWARE PROCESS

• RDBS의 발전은 비지니스 부문에서 소프트웨어 어플리케이션의 급격한 확장(성장)을 불러 일으켰고, 기존의 개발 프로세스는 이것을 충족시킬 수 없었다.
• 소프트웨어 프로세스 단계는 일련의 입력과 출력 기준이 존재한다.

 

## 2.3 MERITS AND PROBLEMS OF THE WATERFALL PROCESS 

### 장점

• 폭포수 방식의 장점은 간단하고 straight한 방식은 프로젝트의 플랜이나 스케줄링을 간단하게 할 수 있고, 프로젝트의 상태를 추적하기 편하여 예측할수 있는 과정을 만든다.
• 폭포수 방식의 장점은, 기능 중점의 프로젝트 구성을 가능하도록 한다. 그러한 기능팀은 요구사항 분석팀, 디자인팀, 구현팀들과 같은 기능 중점으로 나뉜다.
• 폭포수 방식의 장점은, 단계적 접근 방식은 일부 크고 복잡하고 오래 지속되는 임베디드 시스템에 적합하다. 그리고 이러한 시스템은 요구사항에 대한 주요 변경 사항이 드물다.

 

### 단점

• 폭포수 방식의 단점은, 엄격한 순서는 요구사항 변화에 대응이 어렵다.
• 폭포수 방식의 단점은, 제품이 출시되기 전까지 유저(FeedBack)의 반응을 알 수 없다.
• 폭포수 방식의 단점은, 긴 개발 기간동안 시세템의 이점을 얻을 수 없다.
• 폭포수 방식의 단점은, 프로젝트가 망하면 그만큼 위험이 크다.

 

## 2.4 SOFTWARE DEVELOPMENT IS A WICKED PROBLEM

• WICKED PROBELM은 문제를 명확히 정의 할 수 가 없다. 그래서 풀기 어렵다(또는 그런걸 칭한다). TAME PROBELM은 그 반대말(수학과 같이 정확히 문제를 정의하고 풀 수 있음)
• 소프트웨어 시스템은 평생 테스트가 필요함 오타와 같은 간단한 문제가 몇십년 뒤에 큰 문제가 되어 나타날 수 도 있기 때문이다. 오류가 있음을 바로 알지 못한다.
• 개발자들의 실수(실패가) 인명피해를 야기할 수 도 있다.

## 2.5 SOFTWARE PROCESS MODELS 

• 그렇기 때문에 순차적인 폭포수(WATERFALL)의 방식이 아닌 반복전인 방식의로 소프트웨어 프로세스의 변화가 필요했다.

### Prototyping Process

• 간단한 프로토타입과 정교한 프로토타입을 만들고 사용자의 기대와 개발방향의 불일치에 대한 검증을 거친다.

### Evolutionary Process

• 프로토타입을 만드는데 드는 노력들이 낭비 될 여지가 있다.(정교한 프로토타입을 만들어야 할 때)
• 프로타타입을 진화시킴으로써 이 노력의 낭비의 문제를 해결한다
• 초기 프로토타입을 만들고 유저에게 보여주고 피드백을 받고 다시 만든다 이러한 반복의 과전을 통해 발전시킨다. 일회용 모델이 아니다.

### Spiral Process

• 사이클(주기)를 가지며 각 주기에는 functionality, performance, or quality가 들어간다. 
• 1현재 사이클(주기)의 목표, 대안, 제약을 결정한다. 목표를 달성하기 위한 목표와 제약조건은 이 과정에서 반드시 만족되어야 한다.
• 대안을 평가한다. 위험이 있다면 다음 단계의 프로토타이핑을 계획하고 새로운 주기를 따라야 한다. 만약 이전 프로토타입이 견고하다면, 같은 프로타입을 사용하고 확장해라

### The Unified Process

• 각 주기는 시시템의 출시로 끝을 맺는다. 주기에는 여러 반복이 존재하는데, inception(인지), elaboration(정교화), construction(건설), transition(전환)이다.

### Personal Software Process

• 소프트웨어 엔지니어가 개인 소프트웨어 프로세스를 개선하기 위해서 고안된것이다. PSP를 거치면 테스트와 디버깅에 소요되는 노력과 시간이 줄어든다.

### Team Software Process

• PSP로 단련된 엔지니어가 팀단위에서 같이 프로젝트를 수행할 수 있도록 하는 것

### Agile Processes

• wicked problem을 해결하고자 고안된 프로세스이다. 
• 팀워크가 강조된다.
• 유저와 개발자가 상호작용을 하면서 개발한다.
• 변화를 위한 디자인
• 빠르게 개발한다.

[클린소프트웨어#1] 애자일(Agile) 방법론과 4가지 가치와 12개의 원칙

 

[클린소프트웨어#3] 애자일한(Agile)설계를 위한 방법과 7가지 부패한 특성