소프트웨어 개발 프로세스

1.      소프트웨어 개발 프로세스에 관한 마인드 맵

2.      소프트웨어 개발 프로세스에 관한 내용

A.     소프트웨어 개발 프로세스의 등장 배경(두둥~!!)

                i.         산업 혁명 때와는 다르게 대량 생산이 필요 없다.

               ii.         초기 소프트웨어 개발에서는 대량 생산 프로세스를 적용 à 그런데 실패를 한다.

1.      대표적 초기 프로세스 모델: Waterfall Model(폭포수)

2.      사람이 작업하기 때문에 기계와 같지 않아 정밀하지 못함.

              iii.         처음 개발이 어렵다.

              iv.         인간의 업무를 체계화 시키는 것으로 바뀜 à 소프트웨어 개발 프로세스를 인간의 인지적 프로세스라 여김

               v.         엔지니어는 있는 그대로를 정확하게 전달해야 한다.

              vi.         인간의 인지 심리를 파악하면 단서를 발견할 수 있다. (인지 심리에 대한 자료는 다음에 올리겠음)

B.     Case by Case 로 다양한 프로세스가 있다. à 반복적 à 정의된(Define) 프로세스를 정리

C.     방법론: 다양하고 정리 안된 순서 à 정리된 순서로 정의 내림(How to 를 제공해주는 것)

D.     초기 방법론

                i.         Method/1

1.      틀에 정리만 되어있음 à 모든 것을 문서화에만 집중 à 구현은 뒷전 à 결국 실패

2.      그래서 방법론(필요한 것만을 선별하여 정리)이 나옴

E.      개발 과정 중 서로 중복되는 과정이 있음 à 재사용할 수 있는 함수로 묶음(Method Content) ex) C의 함수, C++의 클래스 같이 공통점을 뽑아 재사용할 수 있도록 함.

                i.         최초의 Method Content 를 도입: Unified Process

1.      해야 될 일과 시간의 흐름을 분리

2.      기존의 것보다 훨씬 유연한다.

               ii.        

1.      관리: Risk를 Hedging(회피)하기 위해

2.      Process의 최대 목표: 생산품을 최대한 효율적으로, 최소비용으로 생산하는 것

3.      관리(Management)

A.     Milestone(이정표)

                                           i.         정확한 시점에서 무엇(결과물)을 끌어낸다.

                                          ii.         시간 별로 나눈다.

                                         iii.         관리가 필요하다. à Risk를 Hedging 한다.

1.      관리를 안 할 경우 한꺼번에 모든 문제가 발생하게 된다. (Big Bang과 같은 현상(?)과 같은 한번에 큰 문제가 폭발 한다.)

B.     결과(목표)가 정해지면 à Tactics(전술) – 구체적인 행동 à 상황에 따라 바뀔 수 있음

                                           i.         장기적으로 실행할 목표 설정(Long Term Goal)

                                          ii.         최종 목표 설정

1.      왜 이것을 정했는가 / 목표 달성을 위해 무엇을 할지에 대한 전력이 필요. 단, 목표가 실현 가능해야 한다. (당위성)

2.      틀려도 상관없다. à 충분한 시간과 에너지를 가지고 있다. (우리 20대에 관한 이야기가 될 수 있다.)

3.      상품 기획에도 적용할 수 있다.