Software Development Process

Terminologies

 

• development project는 여러개의 activity로 구성
• activity는 여러개의 task로 구성
• task는 여러개의 resource를 사용하여, 여러개의 work product를 산출
• resource는 인적,물적,시간 자원등을 포함
• work product는 system, model, documen 등을 포함.

Activities in software development

 

 

Software development process

• software development를 위한 set of activities와 그들 사이의 relationship
• 이 복잡한 관계에 order를 주는 것
• Software Development Life Cycle (SDLC)
• sw cirsis에 대한 solution이 된다.
• 이 software process의 가장 fundamental한 activities가 위 사진

 

Software development process model

• 특정한 관점에서, software process를 abstraction 하는 것. 
• ex) SDLC model
• process와 process model은 다른 것이다. 구별!!

1) Sequential models => 반복을 가정하지 않고 만든 모델

• Waterfall model
• V-model

2) Iterative models => 반복 모델 (최근 트렌드)

• Spiral model
• Unified Process (UP)

 

Plan-driven and agile processes

1) Plan-driven processes

• activity가 미리 계획되고, 이것이 잘 수행되는지 감시하는 방식

2) Agile processes

• plan 자체가 점진적으로 세워지고, requirement 변화에 유연하다

 

두 process 중 뭐가 좋은지 정답은 x, 실제로는 두 성격을 모두 가진 경우가 많다 (비율의 차이)

 

 

Waterfall Model

• 이 전 단계가 완수되어야지만, 다음 단계로 진행되는 모델
• 각 activity를 한번씩만 수행함
• => 잘못됐을 때 loop back이 가능하지만, 현실적으로 panelty가 매우 큼.
• Plan-driven approach

• Advantage
• 각 phases가 확실히 구분되고, 모델 자체의 concept을 이해하기 쉬움
• 가장 자연스러운? 떠올리기 쉬운? 문제 해결 방식
• 각 단계별 수행이 확실하기 때문에 관리자 입장에서 쉽다.
• requirement가 이해하기 쉽거나, 변화가 적은 기술을 사용하는 업장에서 자주 사용됨
• large system이나, 여러 도시에 하부 조직이 존재하는 곳에서 사용
• => 국방이나 항공사업 ==> 작은 오차도 중요하므로 문서 중심으로 움직여야함

 

• Disadvantage
• 너무 일찍 requirement를 fix해서 정확히 파악 불가
• hw나 다른 기술도 너무 일찍 fix 해버림
• 개발을 다 하고 나서야 완성품이 보이므로(오래걸림) => 잘못되면 big risk
• 유저/client도 개발 초기단계에 모든 requirement를 다 말해야해서 불필요한게 생김 
• very document oriented => 정해진 틀이 존재하므로, 문서 검증 overhead 존재

 

V-Model

• waterfall model의 변형
• testing의 효율성을 끌어낼 수 있고, 더 높은 퀄리티의 작업을 낼 수 있음
• 하지만 여전히 waterfall model의 단점을 안고 간다.

 

Coping with change

• requirment는 ALWAYS 변함
• 이 Change 는 rework를 가져옴 ==> cost
• 이러한 cost에 대한 대응방안이 필요함

1) Prototype

2) Iterative and incremental development

 

1) Development of prototype

• 중요한 key가 되는 부분 중, 잘 이해가 안가는 부분만 prototype을 제작
• => feedback을 받으면서 그 부분에 대해 이해도를 높일수 있음
• quick에 dirty하게 만든다 (퀄리티 신경 x)
• requirement를 도출하기 힘들거나, 자신감이 없을 때 적용 가능

• Advantage
• requirement를 더 안정적이게 할 수 있고, 더 나중에 fix할 수 있게 됨
• main development를 위한 경험이 됨

 

• disadvantage
• prototype을 만드는데 시간과 비용이 듦
• => 하지만 장기적으로 실패 리스크를 생각하면, 이걸 하는게 오히려 이득일 수 있음

 

2) Iterative and incremental Development

• release하는 버전을 계속 계속 기능적으로 발전시키면서 만들기
• prototype의 장점도 살릴 수 있다.

• Advantage
• Risk reduction, Flexibility, Efficient feedback, high quality

 

• Disadvantage
• architecture나 design이 optimal 하지 않을 수 있다
• => 모든 requirement를 다 이해하고 설계하는게 아니기 때문
• rework가 증가 => total cost 증가

 

• Applicability
• response time이 중요 할 때 (시장 반응? 이 중요할 때)
• 일부 release에 대한 response time을 줄여서 미리 공개 => feedback후 방향 결정
• 긴 프로젝트에서의 risk를 감수할 수 없을 때
• 모든 requirement를 다 모를 때

 

Spiral model

• activity들을 점진적으로 결정하는 모델
• 프로젝트 성격에 따라 반복적 개발, 위험관리가 가능한 모델

1) Object setting

2) Risk assessment & reduction

3) Development and validation

4) Planning

 

Rational Unified Process(RUP) & Unified Process(UP)

• Iterative
• Architecture-centric (초반에 구조 확립 후 점진적 개발)
• Use-case driven

• UML : visual language part
• UP : process part
• RUP => UP가 좀 더 상업적으로 확장된 모델

 

Dynamic Structure of UP

 

4 Phases

1) Inception   ==> 얘는 iteration이 없다

• scope, feasibility
• Most influential and risky req identified

2) Elabolation

• risk 완화, architectrue baseline 잡기
• Build the core architecture, resolve the high-risk elements, define most requirements and estimate the overall schedule and resources.
• Domain model(분석), design model(설계) 시작

3) Construction

• 남은 부분 develop 

4) Transition

• customer acceptance

 

 

** ? use case ranking

• Risk
• Coverage
• Criticality
• 이거 고려해서 먼저 구현 / 나중에 순서 결정

• waterfall model에 대응해서 생각하면 안됨.
• 각 phase마다 iteration이 있고, 각 iteration마다 모델링부터 요구분석, 개발, 테스트까지 다 들어감
• 그럼 phase마다의 차이는 뭐냐?
• 하는 행위는 비슷하지만, 행위의 구성 내용이 다른 것.
• 뭘 더 중점적으로 하냐의 차이.

 

Risk Profile of an Iterative Development

• UP는 각 phase를 거치면서 iteration에 따라 risk를 점진적으로 줄여나갈 수 있게 된다.