Process Iteration
Process Iteration은 뜻 그대로 해석하면 프로세스 반복을 말한다.
하지만 여기서 말하는 프로세스는 Process Activites 포스트에서 말한 5가지 Activities다.
"전에 말한 Activity들을 수행하는 것은 납득이 가는데, 왜 이 Activity들을 반복 하는 것일까?"
그 이유는 소프트웨어 개발하는 동안 요구사항 변화는 불가피하기 때문이다.
아래의 이유들로 바뀌곤 한다.
- 비지니스의 변경
비지니스의 변경으로 인해 필요로 하는 요구 사항의 기능들이 바뀔 수 있다. - 구현을 위한 새로운 기술의 등장
이런 새로운 기술들은 구현을 쉽게 만들어주어 새로운 가능성을 열 수 있다.
하지만 이런 기술들을 섣불리 도입했다가 큰 결함이 생길 수 있어 조심해야한다.
새로운 기술의 등장, UIKit에서 SwiftUI로, RN과 유사하지만 더 선언적인 Flutter 등등을 예로 들 수 있다. - 플랫폼의 변경
접근성 향상을 위해 모바일 플랫폼으로 옮기게 되면, 전체적인 개발 방법과 프로그램의 변경을 필요로 한다.
"그렇다면 어떻게 바꿀까?"
만약에 구현 단계에서 요구사항이 바뀌었다고 해보자.
그러면 전 단계인 Requirement Design 단계로 돌아간다.
테스팅을 하다가 바뀌어도 돌아갈 수 있다.
Iteration은 사실상 이전 단계를 다시한다는 의미이다.
Incremental delivery
Incremental delivery는 Iteration 방법 중 하나다.
Delivery는 고객이나 마켓(시장)에 갖다주는것을 말한다.
사실상 릴리즈하는 것과 같다.
즉, Incremental delivery는 점진적으로 릴리즈한다는 것을 말한다.
Incremental develop과는 무슨 차이?
Incremental develop 는 점진적 개발이라는 의미로 릴리즈는 한 번에도 할 수 있다.
Increment의 순서
Increment의 순서는 Priority(중요도)를 부여하여 가장 핵심적이고, 가장 중요한 것 부터 만든다.
스마트폰을 만든다고 해보자. ▼
우리가 스마트폰으로 많은 것을 하지만, 스마트폰은 어디까지나 휴대폰이기에 이의 핵심적인 기능으로는 전화나 문자가 될 것이다.
그러면 전화와 문자 기능을 최우선으로 개발을 하고 다른 기능들은 그 다음에 개발을 한다.
이렇게 increment 단위로 개발이 되면 가장 마지막에 있는 increment는 존재는 해야하는데 사람들이 가장 많이 쓰지 않는 것이 될 것이다.
중요도 말고도 여러 시스템에서 겹치는 부분을 개발하는 것도 효율적일 수 있다.
위의 조언대로 increment에 대한 requirement를 정했다고 하자.
그러면 requirement는 고정된 상태로 다음 단계로 넘어간다.
“그러면 requirement가 바뀌면 어쩌죠?”
지금 당장 반영하지 않고 다음 increment에서 변경된 부분을 반영한다. ▼
장점
1. customer value가 각 Increment에 전달된다.
위의 예시를 그대로 받아와보자.
스마트폰의 기능을 개발하는데, 완성된 후에 delivery를 한다고 해보자.
전화와 문자 기능은 전부 개발되어있는데, 나를 비롯한 대부분이 쓰지 않는 기능이 개발이 덜 되었다고 배포를 하지 않아 전화와 문자 기능을 사용할 수 없게 된다. ▼
그렇지만 앞에서 언급한 방식대로 하면 핵심 기능들을 빠르게 사용할 수 있다.
2. Early increment는 프로토 타입 역할을 한다.
스마트폰 초기 버전이 시장에 나왔다고 해보자.
많은 사람들이 사용을 한 후에 이런 저런 피드백과 추가기능을 제시 할 수 있다.▼
예를 들면 “전화의 음질이 너무 안좋다” 라거나 “문자로 한 번에 1000자 이상 보내고 싶다” 라는 피드백들을 받을 수 있다.
그리고 “직장상사의 전화가 오면 무시하고 싶다!”와 같은 추가기능도 제시받을 수 있다.
이렇게 단계별로 출시하면 사용자들의 실제 요구를 받기가 쉬워진다.
3. 가장 우선순위가 높은 시스템은 테스트를 많이 받는다.
전화 기능이 제일 중요하기 때문에 먼저 개발하고 나면, 다음 increment를 개발할 때마다 다시 테스트하게 된다.
기능이 10개가 있다면 가장 핵심적인 기능은 10번 테스트 받게 되는 것이다. ▼
4. 프로젝트가 전체적으로 실패하는 리스크를 낮출 수 있다.
현재 버전의 결점을 이후의 버전에서 개선할 수 있다.
단점
1. Common(공통적으로 들어가는)한 서비스를 초기에 찾기가 힘들다.
모든 서비스를 초기에 계획하고 들어가는 것이 아니기에, 중복되는 서비스가 생길 수 있다.
이는 재사용을 통해 해결하거나 리팩토링을 통해 해결해야한다.
Rational Unified Process (RUP)
가장 현실적인 process iteration model이다.
앞의 것들은 이론적이라면 이건 현업에서 사용하는 모델이라고 한다.
Rational이라는, 지금은 IBM에 들어가있는 회사에서 만든 모델이라고 한다.
이 모델은 3가지 관점에서 묘사되곤 한다.
- A dynamic perspective that shows phases over time
시간에 따라 진행되는 단계들에 대한 묘사 - A static perspective that shows process activities
시간과 상관없이 해야하는 process activities - A practice perspective that suggests good practice
좋은 소프트웨어를 만들기 위한 제안
좋은 소프트웨어를 만들기 위한 제안
Dynamic perspective
Inception
Business Case
비지니스 케이스를 만드는데, 그 중에서 비지니스로 얼마나 성공할 수 있는지를 만든다.
홀로그램 빔 이라는 기능을 만든다고 하면 이 기능에 대한 비지니스 케이스를 만든다.
Cost
만든 비지니스 케이스를 가지고 투자자에게 가면 이에 대한 cost를 생각하고 투자해줄 지 말지를 생각할 것이다.
Cost라고 하면, 이 기능이 제품 판매에 어떤 영향을 줄 지를 말한다.
가장 대표적인 사안으로는 가격과 잘 팔릴 지가 있다.
예를 들어, 이 기능을 넣으면 제품 가격이 20만원이 늘어난다고 하자.
그러면 높아진 가격 대비 사람들의 유인을 생각해야한다.
기존에는 80만원의 가격으로, 100명의 사람이 구매를 했다고 하자.
그런 상황에서 홀로그램 빔 기능을 넣으면서 20만원을 올리게 되면 사람들이 구매를 주저할 수 있다.
하지만 홀로그램 빔 기능이 너무나도 매력적이라서 사람들이 구매를 한다면 이 기능은 비지니스 케이스에서 성공한 것이다.
Prototype and Test
그러면 이제 이 기능을 넣기 위해 결정권자에게 통과를 받아야 한다.
결정권자에게 통과를 받기 위해 프로토타입을 만들어서 증명을 해보여야 한다.
그렇다면 프로토타입을 만들어가져가면 끝일까?
이제 새로운 기능을 사람들이 좋아할 지를 생각해야한다.
아까의 예시대로, 홀로그램 빔이 사람들의 요구에 맞는 기능이라 구매를 하면 다행이지만 20만원이 비싸져서 구매를 안한다고 하면 비지니스 케이스가 실패한 것이다.
이렇게 되면 다시 전 단계로 돌아가서 기능 정의와 비지니스 케이스부터 다시 고려한다.
Elaboration
Inception 단계에서는 러프하게 프로토타입을 만들었다.
그러나 프로토 타입은 상품화 기준에는 전혀 미치지 못하는 완성도가 떨어지는 아이템이다.
그래서 상품화 기준에 맞게 프로토 타입을 다듬는 과정을 하는 것이 Elaboration이다.
Elaboration 과정에서 해야할 일들은 아래의 것들이 있다.
- 문제 영역에 대한 이해도를 높힌다.
현재의 문제가 무엇인지, 어떤 것을 해결하고자 하는 것인지에 대한 이해도를 높힌다. - 시스템의 구조적인 프레임워크를 세운다.
시스템의 전반적인 구조가 어떻게 될 지 그 틀을 짠다. - 프로젝트 계획을 세운다.
기간은 어느정도로, 사람은 어느정도로 사용할 지에 대한 계획을 만든다. - 프로젝트의 리스크를 찾아내야 한다.
예를 들면 ‘대량 생산이 불가능할 수 있다’ 같은 것들이 있다.
프로젝트의 핵심적인 문제 사항을 찾아내야한다.
위의 과정 중에서 문제점이 발견되는 것이 있다면 다시 Inception단계로 돌아간다.
Construction
이 단계에서는 Design, Implemenation, Testing 을 하게 된다.
위의 것들을 전부 수행하여 바이너리 코드까지 만들어졌다면 다음 단계로 넘어간다.
Transition
Transition은 번역하면 변환이라는 뜻인데, 여기서는 개발자의 환경에서 고객들의 환경으로 변환한다는 의미이다.
즉, 시장으로 출시를 한다는 의미이다.
구동 환경에서 실제 서비스가 실행될 수 있게 한다는 의미이다.
Static workflow
시간에 구애받지 않고, 수행해야할 작업들을 설명한다.
| Workflow | Descriptions |
| Business modelling | The business processes are modelled using business use cases. |
| Requirements | Actors who interact with the system are identified and use cases are developed to model the system requirements. |
| Analysis and design | A design model is created and documented using architectural models, component models, object models and sequence models. |
| Implementation | The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process. |
| Test | Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. |
| Deployment | A product release is created, distributed to users and installed in their workplace. |
| Configuration and change management | This supporting workflow managed changes to the system. |
| Project management | This supporting workflow manages the system development. |
| Environment | This workflow is concerned with making appropriate software tools available to the software development team. |
그 중에서 이 4가지는 위의 작업들을 지원해주는 작업들이다.
| Deployment | A product release is created, distributed to users and installed in their workplace. |
| Configuration and change management | This supporting workflow managed changes to the system. |
| Project management | This supporting workflow manages the system development. |
| Environment | This workflow is concerned with making appropriate software tools available to the software development team. |
여기서 Environment라고 되어있는 항목은 프로그래밍 툴을 의미한다.
Practice Perspective
Practice Perspective는 이렇게 하니까 프로그램의 질이 좋아지더라 하고 추천해주는 것들이다.
- Develop software iteratively
소프트웨어 개발을 반복적으로 해라. - Manage requirements
Requirement 문서화를 잘 해야한다. - Use component-based architectures
많이 재사용 할수록 좋다.
기존에 있는 컴포넌트들을 재사용해라. - Visually model software
직관적으로 묘사할 수 있는 다른 것이 있다면 꼭 그림일 필요는 없지만, 그림이 가장 직관적이기에 그림을 통해 묘사하라는 말을 한 것이다.
소프트웨어 모델링을 그림을 통해 해라. - Verify software quality
소프트웨어 퀄리티를 검증해야한다. - Control changes to software
버전관리를 하라는 말이다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 7. Modeling Concepts (0) | 2024.01.26 |
|---|---|
| 6. Agile (0) | 2024.01.21 |
| 4. Process Activities (0) | 2024.01.20 |
| 3. 소프트웨어 프로세스 모델 (0) | 2024.01.19 |
| 2. 소프트웨어 공학이란 (0) | 2024.01.19 |
