The software process
: 소프트웨어 생산을 위해 필요한 여러 활동들을 구조적(시간, 역할)으로 모아둔 것
* 공동 활동
- 명세 : 시스템이 어떤것을 해야하는지를 정의
- 설계 및 실행 : 시스템의 구조를 정의하고 구현
- 검토 : 고객이 원하는 바를 수행하고 있는지 검토
- 변화 : 고객의 요구사항의 변화에 대응
* Software process model
: 추상화하여 간략히 표현한 것으로 특정 관점에 따라 process를 나타내게 됨
Plan-driven VS agile processes
* plan-driven processes
: 2000년도 초의 모델로 프로세스의 모든 활동들이 모두 미리 계획되어 진행 정도가
계획에 대비되어 측정됨
* agile processes
: 최근에 등장한 모델로 모든 계획이 점진적으로 이루어지며 고객의 요구사항 변화를
수용하기 쉬운 구조 ==> 고객의 요구사항에 민첩하게 반응할 수 있다.
==> In practice, 위의 두가지를 혼용해서 사용
==> because there are no right or wrong software processes.
Software process models
* The waterfall model(폭포수형 모델)
: plan-driven model, 명세(specification)와 개발(development)이 명확히 분리됨
* Incremental development(점진적 개발)
: May be plan-driven or agile, 명세와 개발 및 검증이 같이 일어남
=> 섞여서 들어가는 이상한 구조! but, game 개발에는 유용함
* Reuse-oriented software engineering(재사용 기반 소프트웨어 공학)
: May be plan-driven or agile, 기존의 컴포넌트로부터 조림됨
=> 서비스단위 또는 통채로 재사용하기도 함 ==> 재사용가능하게 제작하는게 좋다.
==> In practice, 대규모 시스템 개발의 경우 위의 process 모델의 일부 요소들을 도입하여 프로세스를 구성하게 됨(process tailoring) ==> 관리자의 역할
1. The waterfall model
: 1970년대에 출현했으며, software life cycle이라고도 불림
임의의 phase가 시작되기 위해서는 이전 phase가 완료되어야하며 명확한 단계로 구분되어져 있어 한 번 다음 단계로 넘어가면 돌아갈 수 없다. 즉,
요구사항이 fix되면 잘못된 부분이 있어도 되돌아 갈수 없다. 따라서
고객의 요구사항 변화에 즉각적으로 반응하기 힘들다.
만약 설계가 잘못된 경우, 우회적으로(설계에 영향을 미치지 않는 정도로) 작업하지만 불가능할 경우 처음부터 다시 해야한다.
요구사항 정의 -> 설계 및 구상 -> 기능 테스트 -> 통합 테스트 -> 작동 및 유지
ex. 하드웨어 기반 software : 하드가 이미 출하되면 요구사항이 바뀌지 않음
통신 분야 : 표준대로 해야함
표준화된 모델들 : 요구사항이 변하지 않음
==> 요구사항이 명확한 경우에 사용!
따라서, 관리자(사장)는 이 모델을 좋아한다.
because..
1. 변동사항이 없고 명확함 : 한 phase가 지나면 특정한 output이 발생함
대형 프로젝트를 할때 유용함
2. 오래 사용될 프로그램에 사용 : 잘 짜여진 설계를 사용하므로 차후에 고치기 편함
3. 개발자가 흩어져 있는 경우 : 한번 만들어진 설계가 바뀌지 않음
BUT!
소비자 입장에서는 불친절한 process다!!
(완성될 때까지 고객이 사용 불가, 요구사항 변화를 받아드리기 힘듬)
2. Incremental development
: 2000년대에 출현, waterfall모델과 달리 단계가 명확히 구분되어있지 않고 유동적으로 흘러가기 때문에 고객의 요구사항 변화를 수용하기위한 비용(시간, 자원..)이 적다. 따라서 고객의 feedback 받는 것에 용이하며 waterfall보다 해당 소프트웨어를 빠르게 경험 할 수 있다. (Increment는 version들을 구분하는 가늠자)
ex. Game, 비지니스 시스템에 유용 : 고객의 요구사항 변화를 수용하기 좋음
==> 고객의 요구사항 변화를 수용하기 좋음!
따라서, 관리자(사장)는 이 모델을 싫어한다.
because..
1. 단계가 명확하지 않다 : 개발정도를 확인하기 위한 정기적 산출물이 없다.
2. 새로운 Increments가 추가됨에 따라 시스템 구조가 망가지므로 관리측면에서
매우 좋지 않은 process이다.
BUT!
소비자 입장에서는 매우 친절한 process다!!
(비교적 일찍 고객이 사용할 수 있으며, 요구사항 변화를 받아드리기 좋음)
3. Integration and Configuration
: 최근 오픈소스가 활발해짐에 따라 출현, 현재 오픈소스에 등록된 소프트웨어들을 통합 및 조정해서 새로운 프로그램을 만드는 방법.
Component analysis -> Requirements modification -> System design with reuse ->
Development and integration
ex. 비지니스 시스템 구축, Stand-alone software systems, Collections of objects,
웹 서비스, office programs
=> 구성 요소(기능)가 비슷하다.
Process activities
: 앞선 3가지의 모델은 전부 다르지만 , 4가지 기본 활동을 기반으로 작동함
- specification, development, validation, evolution
=> 위의 4가지 활동이 프로세스 모델에 따라 다르게 조직화 됨
1) software specification
: 어떤 서비스를 할 것인지와 시스템 작동과 개발에 대한 제약사항을 명확하게 하는 것
ex. 쇼핑몰에서의 service (기능적 요구사항): 검색, 결제, 분류, 장바구니....
쇼핑몰에서의 constraint (비기능적 요구사항) : 비용, 보안
과정 :
적합성 검토 --> 요구사항울 마구 추출한 뒤 분석 --> 요구사항 명세 --> 요구사항 검증
==> 완료시 RS라는 요구사항 명세서가 생겨난다.
ps) The requirements engineering process : 고객이 무슨 기능을 원하는 지 찾는 방법
2) software design and implementation (development)
: System specification을 실행 가능한 시스템으로 변화시키는 과정
-> software design : 명세한 자료를 실현하는 소프트웨어의 구조를 설계
-> implementation : 설계단계의 소프트웨어 구조를 수행가능한 프로그램으로 전환함
==> 위 두 활동은 매우 밀접하게 연관되어져있다!!
 |
| A general model of the design process |
* Architectural design : 시스템의 개략적 구조, 컴포넌트들 간의 관계 및 분산을 정의
* Interface design : 시스템 컴포넌트 간 인터페이스를 정의
* Component design : 각 시스템 컴포넌트 별로 작동 내용을 설계
* Database design : 시스템의 자료구조를 정의하고 이것이 어떻게 DB에 표현되는지 정의
3) software validation(검증)
: Verification and validation.
=> 시스템이 주어진 specification에 부합하는지, 요구사항을 만족하는지 보이는 작업
ex. checking, review processes, system testing.
* Stages of testing
- Component Testing : 각 컴포넌트들을 독립적으로 테스트함, system이 되기 전까지
Component끼리 묶어가며 여러 번 테스팅함
(Component는 독립적 기능을 제공하는 단위로 함수 or 함수들 또는 객체 or 객체들
or 객체 + 함수들... 을 의미함)
- System testing : 전체 하나의 시스템을 테스트하며 주로 Emergent properties
(창발적 특성) 을 테스트함
ps)창발적 특성 : 따로 있을때는 없었다가 모이게 되면 나타나는 성질
ex. 자동차 각각의 부품들이 하나로 합쳐졌을 때 등장하는 성질(연비, 제동거리...)
- Acceptance testing : 고객 데이터를 통해 시스템이 고객의 요구에 맞는지 테스트
- 개발자 또는 개발부서가 Component Testing과 System Testing을 진행하고
고객들이 Acceptance Testing을 진행함
 |
| Testing phases in a plan-driven software process ( V-model) |
1. requirements Specification -> 2. Acceptance test plan -> 3. System Specification
-> 4. System Integration test plan -> 5. System Design -> 6. Sub - system Integration
Test plan -> 7. Detailed Design -> 8. Module and Unit code and test -> 9. Sub-system
Integration test -> 10. System Integration test -> 11. Acceptance test -> 12. Service
4) software evolution
: 소프트웨어는 business변화, New technology를 통한 변화, platforms 변화로 인해 변화가 요구되어진다. 따라서 소프트웨어의 변화는 불가피하다.
이러한 변화에 대한 비용(요구사항 재분석 + 새로운 기능 구현)을 최소화 하기 위해
등장한 것이 software prototyping과 Incremental delivery이다.
(1) 변화에 대한 비용 최소화
1. software prototyping
: prototype을 만들어 보는 것.
- prototype
: 시스템 초기에 요구사항들의 개념을 증명하기 위해 제작되면 try out 용도로 쓰임.
설계 단계에서 가능한 옵션을 알아보고 UI 디자인 검토에 쓰임.
- prototype을 통한 이득
: 사용 편이성이 증대, 사용자의 필요에 부합할수 있음, 설계 품질 향상, 유지보수 용이
개발 비용 절약
- prototype 개발 과정
=> 위와 같은 과정은 설계 과정에서 일어남으로 매우 빨리 진행되어야함
따라서, 신뢰성이나 보안 같은 비기능적인 측면보다는 기능적인 측면만 제작되어있다.
또, 문서화 작업(유지보수를 위한)이 없으며 특별한 tools이나 language가 사용되므로
개발 이후에는 무조건 버려지게 됨.
만약 prototype으로 개발 되는 경우 비기능적 요구사항들의 실현과 유지보수가
어려워지고 차후 변화를 겪으면서 구조가 나빠질 가능성이 높다.
===> 이러한 과정을 통해 중대한 rework가 발생하기 전에 가능한 변동사항을 prototype
으로 예측하여 변화로 인한 비용을 없애는 방법이다.
2. Incremental delivery
: 시스템을 한번에 변화에 맞춰 바꾸는 것이 아니라 조금씩 increment단위로 나누어
개발하고 delivery함.
- 사용자 요구사항들을 우선순위로 구분하여 우선순위가 높은 요구사항을
초기 increment에 포함하여 개발함
=> 한번 increment 개발이 시작되면 이전부터 해당 increment의 요구사항은 변동될 수
없음.(이후의 increment가 앞선 increment에 부가 내용을 추가해서 개발함)
- Incremental delivery개발 과정
- Incremental delivery의 장점
: 1. 각 increment가 출시될 때마다 고객의 평가를 빨리 받을 수 있다.
2. 일단 하다보면 다음 할 일이 생각 나듯이 각 increment는 다음 increment가 구현해야
하는 요구사항을 추출해 내는데 prototype의 역할을 할 수 있음.
3. 중간에 프로젝트가 중단되어도 중요사항부터 완성된 결과물이 존재하므로 프로젝트
실패의 위험성이 낮다.
4. 우선순위가 가장 높은 서비스는 가장 많이 테스팅을 하는 경향이 있다.
=> 가장 중요한 서비스가 자주 테스트 됨으로 차후 변경 비용이 감소하게 된다.
- Incremental delivery의 단점
1. 시스템의 여러 부분에서 공동으로 쓰이는 기본 facilities는 어떻게 구현할 것인가?
=> 모든 increment들이 필요로 하는 공통된 부분을 식별하는게 어렵다.
즉, 중복된 코드 또는 흩어진 코드가 될 가능성이 있어 유지보수가 어렵다.
2. 소프트웨어 개발과 동시에 명제 작업이 일어나는 반복 구조가 항상 좋은가??
=> 비지니스에서 어떤 계약에 의해 필요한 output이 존재하지 않아
좋아하지 않는 기업도 있다.
(1) 프로세스의 개선
1. 프로세스 성숙도 접근법
: 프로세스와 프로젝트 관리 기법의 개선을 위해 바람직한 소프트웨어 공학의
여러 실무(사례)를 조직에 소개함으로 개선을 시도
단계 :
1. 프로세스 측정 : 한가지 이상의 속성 측정 => 개선의 효과가 있었는지 판단
2. 프로세서 분석 : 프로세스의 약점 및 방해물을 식별
3. 프로세스 변경 : 약점을 해결하기 위해 프로세스 변경
4. 위의 3단계를 무한루프시킴
==> 그렇다면 구체적으로 어떻게 사이클을 돌면서 개선하는 것이 좋은가??
=> 조직들이 프로세스를 개선할 때 아래와 같은 5단계를 순차적으로 진행한다.
==> 역량 성숙도 수준(단계)
어떤 차이가 있을까?
1.아무것도 조절이 되지 않는 level 1의 회사에게 어떤 프로세스를 주면 어쩌다가 성공한다!
2.제품에 대한 관리 절차가 정의되어 있는 level 2의 회사에게 어떤 프로세스를 주면
성공했던 것은 계속 성공한다!
3. 프로세스 관리 절차와 전략이 정의되어있는 level 3의 회사는 개인이 할 일이 명확하다.
4. 품질 관리 전략이 정의되어 있는 level 4의 회사는 다수의 데이터를 확보하고 있다.
5. 프로세스 개발 전략이 정의되어있는 level 5의 회사는 스스로 최적화를 할 수 있는
힘이 있다.
ps) 작고 특정 소프트 개발회사가 단계가 높다.
