2. 소프트웨어 개발 절차

 소프트웨어 절차 ( Software Process )

 - 단순히 코딩하고 고치고 코딩하고 고치고를 반복하는건 절차적이라고 할 수 없다.

 - 개발에 필요한 절차들을 순차적으로 나눠두고, 직접적인 개발과 간접적인 개발 지원 절차를 모두 포함한다.

 좋은 소프트웨어 절차의 특징

  - 예측가능성(Predictability) : 이전과 같은 절차로 진행하면 이전과 비슷한 비용 및 퀄리티가 나올 것이라 예측 가능.

  - 시험과 유지보수가 편리함 : 소프트웨어 개발에 들어가는 비용 중 절반이 시험에 들어가므로 중요하다.

  - 변화 대응에 용이함 : 개발 중간마다 소프트웨어의 프로토타입을 소비자에게 검증받는게 중요하다.

  - 오류 수정에 적은 비용 : 소프트웨어의 완성도가 높아질수록, 오류 수정에 필요한 비용이 커진다.

 

 소프트웨어 개발 절차 ( Software Development Process )

 - 소프트웨어 개발 모델이나 소프트웨어 개발 LifeCycle(SDLC) 등으로 말할 수 있다.

 - 소프트웨어 계획, 개발, 유지보수 단계의 순서를 정해두고, 해당 단계가 종료되었는지 확인할만한 조건을 설정한다.

 - 전통적으로 `요구사항 분석 > 설계 > 구현 > Verification & Validation > 유지보수`의 순서이다.

 

 

소프트웨어 개발 모델 ( Software Development Model )

 1. 폭포수 모델 ( Waterfall Model )

  - Plan & Documentation 모델들의 가장 기본이 되는 모델이다.

  - 요구사항 분석 > 설계 > 개발 > 검증 > 유지보수 순으로, 개발 절차가 단순명료하다.

  - 코딩 이전에 충분한 계획을 세우고 시작하며, 모든 절차에서 많은 문서작업을 진행한다.

  - 각 단계를 완벽하게 하고 넘어가므로 되돌아가는 일이 없고, 그렇기에 에러가 예측가능하다.

  - 그러나, 절차를 중요시하므로 변화에 유연한 대응이 힘들다.

 

 2. Rapid Prototyping Model

  - 요구사항 분석 > 프로토타입 개발 > 평가의 과정을 반복한다.

  - 프로토타입을 자주 만들어 검증받으므로, 사용자의 피드백이 적극 반영된다.

  - 그러나, 개발 계획을 세우거나 통제하는데 어려움이 있다.

 

 3. Evolutionary Model

  - Release 버전을 만들면서, 사용자가 직접 사용해보고 피드백을 받는다.

  - 2번과 비슷하게, 피드백 수용에 원활하지만 계획을 세우는 등에 어려움이 있다.

 

 4. 나선형 모델 (The Spiral Model)

  - 위험 분석 및 관리에 중점을 둔 모델이다.

  - 리스크를 줄이고, 변화에 대응하는 것이 중요하며, 전체 개발 종료보다 일찍 소프트웨어를 확인한다.

  - 그러나, 미리 위험 분석을 하는것이 어렵고, 전체 완성도가 초기 분석 수준에 달려있다.

  -> 다른 모델에 비해 복잡하고 높은 비용이 들어가게 된다.

 

 5. V Model

  - 테스팅을 자주 엄격하게 하는 모델이다.

  - 자동차, 비행기, 의료기기 등 버그가 발생하면 인명이나 재산에 큰 위험을 줄 수 있는 경우에 사용된다.

  - Unit Test, Integration Test, System Test, Acceptance Test 등의 절차가 있다.

 

 6. (Rational) Unified Process (RUP or UP)

  - Use-case 중심으로 개발하며, 수직으로는 폭포수모델, 수평으로는 3번 모델과 비슷하다.

  - UP는 Inception Phase ( 프로젝트 계획, 요구사항 분석, 비용 및 기간 설정 등..), Elaboration Phase ( 시스템의 구조 설계 ), Construction Phase ( 실제 소프트웨어 구현 ), Transition Phase ( 시스템이 어느정도 완성되서 피드백을 받고 시험 ) 의 페이즈로 구성되었다.

 

 7. 에자일 모델 ( Agile Model )

  - 위의 6 개의 모델은 Plan & Documentation 모델이지만, 에자일 모델은 아니다. 아래의 4가지를 중시하는데,

    - 팀, 고객과의 상호작용 ( Individuals and Interaction )

    - 작동하는 소프트웨어 ( Working Software )

    - 고객과의 협업 ( Customer Collaboration )

    - 변화에 대응 ( Responding to Change )

  - 단기적인 계획을 세우고, 각 주기마다 고객과의 상호작용을 하게된다.

   -> 모바일 앱이나 웹사이트 개발 등에 잘 맞는다.

 

 에자일 모델에서 사용되는 용어

  - Agile Methods -- XP ( eXtreme Programming )

   -| TDD ( Test-Driven Development ) : 테스트 주도의 개발 ( 테스트-오류발견-테스트-오류수정-테스트... )

   -| Pair Programming : 한 모니터에 두 명이 앉아서 한명은 개발, 한명은 코멘트 하면서 진행

   -| CI ( Continuous Integration ) : 지속적으로 Build를 제작하면서 개발한다.

  - Scrum : 소프트웨어 개발 팀의 관리 기법. - 매일 개발자들끼리 미팅을 갖고, 일정 주기마다 고객과 상호작용.

  - Sprint : 개발 주기

  - Product backlog : 요구사항 목록, 고객과의 상호작용이 가능할 정도의 비-전문적

  - Sprint backlog : 현재 진행 상황

  - Daily Scrum : 매일하는 미팅

  - Sprint Demo : 한 주기마다 고객과 상호작용 하게되는 데모

  - Sprint Retrospective : 주기 회고, 한 주기를 마치고 잘된것과 안된것을 소통.

  - Slack time between Sprints : Sprint 사이에서의 휴식 기간.

 

프로젝트에 어떤 모델을 선택해야할까?

 - 소프트웨어의 요구사항에 대해 이해하는 수준에 따라 달라진다.

  -> 요구사항을 잘 모르면 flexible한 모델을 선정하는게 유리하다.

 - 위험도에 대해 이해하는 수준에 따라 달라진다.

  -> 잘 모르면 Agile 모델, 잘 알면 Traditional한 모델이 좋다.

 - 고객들과 상호작용 해야 하는가?, 프로젝트의 생명 주기? 개발 기간, 참여자들의 전문성 등 에따라 달라진다.

 

개발 지원 프로세스 (Umbrella Process)

 - 프로젝트 관리 프로세스, 프로세스 관리 프로세스, 설정 관리 프로세스 등..

 

소프트웨어 공학적인 방법으로 프로그램 개발 vs 단순 프로그래밍으로 개발

 - 잘 관리되는 절차가 있는가? 의 차이

 

소프트웨어 프로젝트 관리

 - 일정과 예산을 맞추고, 고객이 요구한 품질을 지키고, 좋은 팀을 구성해 좋은 유지보수를 수행한다.

 - 프로젝트 계획서에 있어야 하는 것

   -> 범위 ( Scope ), 팀 구성 ( Team Organization ), 비용 계획 ( Man-month plan ), 일정 ( Work schedule ), 위험요소 관리 ( Risk management ), 작업 명세서 ( Statement of work, SOW ), 제안 요청서 ( Request for Proposal, RFP )

 

비용 추정 방법

 - 비용 계산이 정확할 수는 없으나, 개발 절차 계획을 위해서는 추정해 두는 것이 중요하다.

 - 경험적인 추적 ( 이전 프로젝트에서는... ), 공식을 이용한 추적의 방법이 있다.

 - 개발이 진행될수록 예상비용과 실제비용의 차이가 줄어들게 된다.

 

COCOMO ( Constructive Cost Model )

 - 문서화가 잘 되어 있으며, 고객이나 개발자에게 의존되지 않는 독립적, 중립적 공식이다.

 - 공식 : A * Size^(B) * M

 - A : 소프트웨어의 타입에 따라 경험적으로 미리 만들어 둔 상수

 - Size : kLOC, FP

 - B : 소프트웨어의 복잡도에 따라 1~1.5를 유기적으로 선정

 - M : 절차에 따른 프로세스, 제품의 속성, 팀의 능력 영향 등 외부 요소.

 

프로젝트 사이즈 기반 비용 추정 방식의 문제

 - 개발 시작 단계에서 프로젝트의 사이즈를 정확히 추정하기 어렵다.

 - B와 M의 수치를 정하는 방식이 주관적이여서 모호하다.

 - 프로그래밍 언어나 환경에 따라 사이즈가 변경될 수 있다.

 - 팀의 능력에 따라 수치가 변경될 수 있다.

=> 이를 해결하기 위해 고안된 새로운 모델이 1995년에 등장한 COCOMO II

 

COCOMO II

 - 소프트웨어 개발의 진행에 따라 서로 다른 공식을 적용한다.

  1. 응용합성, 프로토타이핑 단계 ( Application Composition Model )

   -> 만들어야 하는 화면/출력/컴포넌트의 개수를 이용해 추정한다.

  2. 초기 설계 단계 ( Early Design Model )

   -> 만들어야할 기능에 대해 점수를 부여(Function Point) 한 후, 그 점수를 통해 추정한다.

  3. 설계 이후 ( Post-Architecture Model )

   -> 작성된 라인의 수 ( LOC )를 이용해 추정한다.