Chapter2. Software Processe

Waterfall 

alalyse(기능명세) -> design -> code(=implementation) -> test(<validation) -> release

 

(참고) 임베디드 시스템. 잘못하면 죽으니까, 한단계 한단계를 완벽하게.

 

waterfall design의 단점 : 다시 되돌아갈 수 없음.

Agile : 계획을 진행하면서 고쳐나가는 전략 . 실력 high 요구됨

 

<목차>

 

1. Software process Models

- 6가지

 

2. Process activities

- 4단계. specification, design and implementtion, validation, evolution

 

3. Coping with change

- Prototyping, incremental delivery

(* incremental delivery랑 incremental development 비교하는거 시험에 나왔었음)

 

4. Process improvement

- capability maturity model (?)

 

 

 

Software Process Models

 

소프트웨어 제품을 생산하기위한 구조화 된 activities 세트입니다. 

모든 소프트웨어 시스템에 적용되는 범용(universal) 소프트웨어 프로세스가 없습니다.

 

소프트웨어 개발할 때 어느 프로세스 모델을 적용해야 할까?

고려해야하는 것들

- type of software

ch1에서 공부한 것들

 

- requirements of customer.

고객의 요구사항 바뀌지않고 완전 고정 -> waterfall

자주 바뀌거나 잘 모름. -> agile

 

- skills of developer

코딩실력이 좋은 소규모 -> agile

코딩실력이 부족하거나 대규모 -> waterfall

 

Software Process Model

소프트웨어 프로세스의 단순화 된 표현 – SDLC (Software Development Life Cycle) 모델이라고도 함

 

일반적으로 software process models 3가지로 나눔.

1) Waterfall model(plan-driven)

2) Incremental development (mostly agile + plan-driven)

3) Integration and configuration(plan-driven or agile)

 

-현실에서는 섞어서 씀.

 

 

Waterfall Model

개발 시작 전에, 모든 process activities에 대해 계획을 싹 세워놓고 시작.

software process의 첫 모델임. 조상격

waterfall model

각 단계가 지날 때마다 document가 나오고, 자세히 검토 후 승인을 함. 전 단계로 돌아가지 않기 때문에 매 단계를 꼼꼼히!

단계들을 살펴보자.

 

1. Requirements definition and analysis

- 시스템의 목표, functional Req, non-functional Req 등을 분석 및 정의 -> documentation 문서화

- 위의 정보들이 디테일하게 모여 system specification(기능명세)을 이룸

 

2. System and software design

- 전체적인 시스템 구조 확립

- 기본적인 시스템의 구조와 관계 등이 묘사됨

 

3. Implementation and unit testing

- 프로그램 단위의 testing

- software design(소프트웨어 설계)는 프로그램 단위로 실현된다.

- 각 unit (프로그램 조각들(함수, 클래스, 등등))은 그의 specification에 맞는지 검증한다.

 

4. Integration and system testing 

- 각각의 unit들을 합친 후 시스템 단위의 testing

- system testing 후, 고객에게 전달됨

 

5. Operation and maintenance

- 시스템 설치, 실질적으로 사용

- waterfall 모델에서의 maintenance : error connecting 등의 사소한 것들. 큰 게 나오면 망한거임

 

** 각 단계가 끝나면 산출물로 하나 이상의 documents가 나와야함! (signed off)

 

 

Waterfall Model의 문제점

- 변경 사항이 생길 경우, system rework 해야함.

- customer Req 변경에 대응하기 어려움.

- 비격식적(informal)으로 팀 커뮤니케이션이 가능하고 소프트웨어 요구사항이 빨리 변경되는 경우, waterfall 모델 적합하지 않음

 

Waterfall Model이 적합한 곳

- Embedded systems : h/w, s/w의 기능이 완전 고정이 되어야함.

- Critical systems : 각 단계의 문서가 매우 중요. 광범위한 분석이 가능하도록.

- Large software systems : 여러 팀이 참여하는 경우. 서로 다른 하위 시스템을 독립적으로 개발하려면 complete specification이 필요함.

 

 

 

Incremental Development

초기버전(initial version) 개발하고, 몇번의 버전에 걸쳐 발전시킴.

- plan-driven + agile

- Specification, development, and validation are interleaved

- activity가 진행됨에 따른 빠른 피드백.

요즘, 소프트웨어 개발을 위한 가장 일반적인 접근 

- plan-driven : 모든 system increments를 미리미리

- agile : 오직 초기 increments 만 먼저 설정. 

 

요구사항이 변경될 가능성이 있는 시스템에 대해 waterfall 방식보다 훨 나음.

대부분의 비즈니스 시스템과 소프트웨어 제품들에 적용됨.

waterfall에 비해 힘든 문서작업 X(waterfall 에 비해 문서작업이 수월하다는 것이지, 문서작업이 아예 없는 것은 아님!).

Req을 수용하기 좋음.

 

각각의 버전이 그 자체로도 독립된 product이다. 

- 초기 버전들 : 핵심 기능 담음

- 이후 버전들 : 부가적인 기능들 추가.

 

고객은 상대적으로 초기 단계에 시스템을 평가할 수 있다.

- 변경되는 Req에 대응하기 편함.

 

Incremental development의 장점

- requirements 변경에 대응하는 비용 감소 (waterfall 에 비해)

- customer feedback 받기 편함

- useful한 소프트웨어의 초기 배포가 가능. 부가 기능이 모두 들어가지 않았더라도.

 

 

Incremental development의 단점

1) management 관점에서,

- 각 버전마다 req를 받아서 고쳐나가면, 매번 코드를 바꿔야 해서 개발자가 힘듦

- 프로세스 진행도를 측정하기 어려움

- 시스템의 매 버전마다 달라지는 걸 반영해서 documents를 작성하기 힘듦

 

2) maintenance 관점에서,

- 새로운 부가 기능이 추가될 때마다 시스템 구조는 저하될 가능성 있음. 매번 바뀌니까

- 시스템에 새로운 기능을 추가할 때 어려움과 비용이 커지게 됨

- -> 따라서, refactor(=improve&restructure.) 해야함!! 무조건!

Refactor = 기능은 그대로. 코드를 nice하게 다듬는 것.

 

 

** Incremental development 는 매버전을 customer에게 전달할 필요 X.

예를 들면, 3번에 1번꼴로 전달, 짝수 버전만 전달 등등..

(c.f. Incremental delivery : 매 버전을 customer에게 전달해야함)

 

 

Integration(통합) and Configuration(설정) 

2000년대부터 소프트웨어 개발 프로세스는 기존에 존재하는 소프트웨어를 reuse하는 것에 주목하기 시작했다.

 

Reuse-oriented approaches

- 코드를 짤 때 reusable 하게 짜야하고, 다른 사람의 코드를 reuse할 줄 알아야한다.

 

그러나, reuse라는게 쉬운게 아님.

그 코드를 모두 분석해서 reuse해도 괜찮겠다, 했을 때만 가져와서 쓸 수 있음.

완벽히 이해하는 것이 쉽지 않음!

 

 

Type of Reusable Software Components

- Stand-alone software systems

특정 환경에서 사용하도록 구성됨

 

- Collections of objects

프레임워크에 합칠 수 있는 패키지 같은 거. library, object, class같은 것들

 

-Web services

인터넷을 통한 원격호출. URL로 호출하는 것

 

 

일반적인 Reuse-Based Process Model

[reuse할 것 분석]

요구사항 기능 명세 -> (reuse할) s/w 발견, 평가 -> 요구사항 정제 -> (요구사항 ㄱㅊ하면 넘어감)

* requirements specification : 주요 req의 간략한 묘사. (바뀔 수 있으니까 간단하게. )

* requirements refinement : 적절한 요소에 반영되기 위해 requirement를 수정

[합치기]

전체가 맞을 경우(application system available) -> application system 구성

일부만 맞을 경우(components available) -> adapt components/ develop new components -> 결합

 

 

장점

- 검증된 애를 가져와서 쓰는 거니까 비용과 리스크 낮음 (그러나, 분석하고 이해하는 데에 오래 걸리므로 대폭 줄어들지는 않음!!)

- 보통 소프트웨어의 faster delivery 를 이끔

 

단점 

- 너무 reuse에 집착하면 본래의 Req를 버릴 수도.

- reuse하는 그 시스템을 control할 수 없다. 예를 들면 reuse하는 시스템이 구형화된다든가, 등등

- 완벽히 이해하지 않으면 사용 못함, 이해하고 분석하는 데에 오래걸림

 

 

Spiral Model

risk-driven software process model (risk를 방지하는)

- risk를 정의하고, 이에 기반하여 무엇을 해야할지 결정

- incremental development 요소(cycle) + waterfall model (cycle 내에 절차가 있음)

(1) objective identification : req 설정, 목표 설정

(2) alternate evaluation

Risk management : 개발하다가 무슨 risk가 있을지 반드시 먼저 파악해야함

Prototypes : 이걸로 risk를 해결. (prototype : 본제품 x. 본제품 전에 나오는거)

(3) product development 

design, code, integration, test, implementation (deployment : 현장에 탑재) 

(4) next phase planning 

 

Software Process Activities

1. Specification (=Requirements engineering)

- software의 Requirement(functional & non-functional) 을 정의. Req engineering

2. Development (=Design + Implementation)

3. Validation 

-검증. validation의 한 방법 : testing

4. Evolution

- 발전. 고객의 니즈가 바뀜에 따라 소프트웨어도 바꿈

 

** process마다 4개가 수행되는 "순서"가 달라짐.

 

각 단계에 대해 알아보자.

 

1. Software Specification = Requirements engineering

시스템에 어떤 service, 기능(functional Req)을 넣을건지 + 시스템 운영과 개발에서의 constraints(제약사항)(non-functional Req) 정의

 

매우 중요한 단계. 여기서 실수하면 추후에 system design, implementation에 문제 생김.

 

 

이해 관계자(stakeholder) 요구 사항을 충족하는 시스템을 명시하는 합의된 요구사항 문서생성(agreed requirement document )을 목표로 한다.

- For end-users, constomers : user requirement (high-level). 고객이 이해할 수 있도록 큼지막하게

- For system developers : system requirement (low-level) . 개발자가 보고 개발할 수 있도록 상세하게

(user / system requirement는 나중에 chaper4에서 다룸!)

 

Software Specification 단계에서의 Activities

1) Requirements elicitation 추출 and analysis

2) Requirements specification 

documents 생성

-user Req : 고객 사용자를 위한 것. abstract statements

-system Req : 개발자를 위한 것. more detailed description

3) Requirements validation

- 3가지 체크 : realism(현실성), consistency(앞뒤가 맞는지), completeness(빠뜨린건 없는지)

 

 

2. Software Design and Implementation

customer에게 가져다줄(delivery) 실행가능한 시스템(executable system)을 개발하는 단계

 

Design : 소프트웨어의 구조, 데이터 모델, 인터페이스 등을 describe

+

Implementation(Programming) : design한 것을 executable program 으로.

 

이 두개는 interleaved한 관계. 같이 가는 활동.

 

2-1. Design Process

일반적인 Design Process Model

[Design inputs]

 

[Design activities]

전체적인 아키텍처를 짜놓고(architectural design), 각각의 component(모듈, 서브시스템 등등) 설계(interface design, database design). 이때 이미 있으면 selection, 없으면 design

 

(1) Architectural design : 전체적인 구조. 모듈의 구성, 역할, 관계를 설정

(2) Database design : system data 구조 디자인

(3) Interface design : system components들 간의 인터페이스 정의

(4) Component selection and design : reusable components 있으면 selection하여 사용, 없으면 design

 

[Design ouputs]

component, Interface가 뭔지 알아두기.

아키텍처 설계 : component의 구성, 역할, 관계 설정

코딩 전에 인터페이스를 먼저 정의해야 하는 이유 : 일을 분배해서 시작할 수 있음

 

2-2. Implementation (=Programming)

Design이 끝나거나, Design을 하는 중 같이, implementation이 시작됨

소프트웨어 개발 도구를 사용하여 design에서 skeleton program을 생성할 수 있다.

 

Implementation은 개인적인 activity. 따라서 일반적으로 따라야할 process도 딱히 없다.

 

Programmers는 또한 testing과 debugging을 수행해야 한다.

-Testing : defects(bugs)의 존재를 발견하는 것

-Debugging : defects를 고치는 것

 

 

3. Software Validation

내 코드와 Requirement가 잘 맞는가.

software verification, validation : V&V

verification : 기능성. 그 개별 기능이 수행해야 하는 역할을 잘 수행하는가. (ex. 더하기 기능에 왕창 큰수, 음수, 등등)

validation : req와의 일치성

 

시스템이 specification을 준수하고 customer의 req를 충족함을 보여주기 위한 목적

 

기본적인 V&V 기술들

- Program testing : system이 test data를 가지고 실행된다. 

- Insections and reviews : 코드를 보면서 로직을 보는 것. 회사에서는 반드시 다른 사람ㄷ르이 특정 코드를 보고 코드리뷰를 해야함.

 

 

Stages of Testing

(1) Componenet testing (=Unit testing)

개발자가 시행. 각 component 독립적으로. 함수를 따로 떼어놔도 독립적으로 test가 가능하도록 함수를 짜야함. 

 

(2) System testing

component를 합친 다음에 전체 시스템에 대한 test. 위에서 직접 코드를 짠 개발자가 안하고 다른 사람이 함. 

예상치 못한 상호작용으로 에러가 나지 않는지. 

이 단계에서 non-functional req를 체크할 수 있음! functional req도 물론.

합쳐야만 발현되는 특성들을 test.

 

(3) Customer testing (=Acceptance testing)

customer가 직접 자신의 환경에서 실제 데이터로 가동. 

 

 

*위 3개가 반복적으로 이루어짐

 

Development and Testing

- 보통 development 와 testing은 interleaved한 관계이다. 

개발과 테스트는 동시에 진행이 됨. (100% 코딩 완료 후 검증하는 것이 아니란 얘기!)

why? test coverage!? (만약 100줄 짜고 test했는데 20줄만 통과되면 곤란하니까)

 

- incremental process : 각 increment는 반드시 개발되면 테스트를 거쳐야 함. 그 테스트는 그 increment의 req를 기반으로 만들어짐.

- plan-driven process : req가 결정되면, testing 팀은 testing scenarios를 작성하고, 개발팀은 code 작성해서 나중에 따로 맞춰봄.

 개발팀과 독립된 별도의 팀이 test를 수행한다!

개발팀이 QA팀에 넘기면 테스팅 해줌.

 

 

V-model

waterfall 모델의 확장판.

Requirements - Acceptance testing (abstraction level : high . 추상화 수준 높음 = 전체를 아우르는)

Architecture design - integration testing

Detailed design - unit testing  (abstraction level : low . 추상화 수준 낮음 = 구체적)

 

 

Alpha and Beta Testing

- Alpha testing (=acceptance/customer testing)

특정 customer에게 하는 test. 

 

- Beta testing

불특정 다수 customer에게 하는 test. 

 

 

4. Software Evolution

software는 flexible하다. change가 충분히 발생할 수 있음. 또한 Req도 충분히 change될 수 있음.

 

이전까지는, development와 evolution은 분리되어왔다. development: 창의적인 활동/ evolution: 지겹..

그러나, 그 분리는 점점 없어졌다. 극소수의 software system만 완전히 새로운 시스템. 개발 빛 유지 관리를 연속체(계속 버전을 업데이트)로 보는 것이 훨씬 합리적이다.

 

 

 

 

 

Software Process Description

보통 software process를 설명하라하면, 우린 보통 그 프로세스의 activities에 대해 이야기한다.

ex) data model을 정의, 유저인터페이스 디자인 등등

 

또한 다음과 같은 것들을 설명하는 것도 중요하다.

- Products (= deliverables) 산출물.

inplementation의 산출물 : code

requirement engineering의 산출물 : document

 

-Roles

ex) project manager, programmer 

 

-Pre-condition & post-condition

activity의 (전제)조건. 

ex) error가 3개 미만 

 

 

완벽한 Software Process 는 없다

기존의 소프트웨어 프로세스 중에는 자기가 만드는 소프트웨어 맞는 완벽한 프로세스가 없기 때문에,  대부분의 조직에서는 그에 맞는 process를 개발해서 사용함.

ex) Critical systems: a very structured development process 

Business systems: a less formal, flexible process

 

대부분의 software process 는 2가지 타입으로 나뉨

1) Plan-driven processes

-waterfall

-모든 process activity는 미리 계획됨.

-이 계획에 대해 진행률이 측정된다. 얼마나 진행됐는지 알 수 있음.

2) Agile processes

-incremental ~~

-planning이 연속적이고 증가적. 모든 것이 미리 계획되지는 않음.

-고객 요구 변경에 대응하기 쉬움

-계획을 어렴풋하게 세워놓고, 진행해나가면서 보완

-Req가 불안정. 

-버전 1.0 끝나고나서야 다음 버전에 대한 계획 세움

 

3) 그 중간에 둘 특징 모두 가지고 있는 것

-각 버전에 대한 모든 계획이 있음. -> 버전 1.0에 대한 계획 따로, 버전 2.0에 대한 계획 따로. ...

waterfall은 저 단계가 한번, 전체에 적용됨, agile은 저 단계가 여러번 반복되므로 이번 버전에만 적용된다.

plan-driven vs agile

실질적으로, 대부분의 프로세스가 plan-driven과 agile의 요소 모두 가지고 있다. 맞고 틀리고가 없음.

 

 

 

 

Coping with Change 

어떤 process 든지 change는 불가피한 것. 

- requirement change

- design과 implementation의 새로운 방식이 가능해짐(업데이트 등)

- platform changes

 

이러한 변화에 대처하는 2가지 방법!!

 

 

Reducing the Costs of Rework

rework : change때문에, 완료된 작업을 다시 수행해야 하는 것.

ex) re-analyzing the req, re-design the system, re-implementing program, re-testing system

 

변화에 잘 대처하는 2가지 방법 = reducing the costs of rework 

Prototyping , Incremental delivery

 

 

 1. Prototyping

필요한 부분만 빠르게 만드는 것이 핵심 + 다 쓰고 버림

앞으로 변화될 부분을 예측해서, 빨리 prototype으로 확인해봄으로써, 앞으로 변경될 requirement를 줄인다. -> rework의 양이 줄어든다.

 

일반적으로 프로토타입은 최종 제품의 몇 가지 측면만 시뮬레이션하고 최종 product와 완전히 다를 수 있다.

 

- 개념을 설명하고, 설계 옵션을 시도하고, 문제에 대해 자세히 알아내는 데 사용되는 소프트웨어 시스템의 초기 버전

Rapid, low-cost가 핵심!!

이해관계자들은 process 초기에 prototype을 실험할 수 있다.

 

- software prototype은 requirement engineering process(=specification) : 고객이 원하는게 이게 맞나와 , system design process에 사용될 수 있다.

 

 

prototyping 의 장점

: Req를 좀더 깔끔하게 이해하게 해줌. : req에 대해 new idea를 얻을 수도 있고, 새로운 시스템 req를 제안할수도있고, 초기 view가 잘못되었다는 것을 깨달을 수도 있고

-> 따라서, system specification이 좀더 일찍 정제될 수 있다. refined early

(시스템 이용성 up/ users' real needs에 close/ design quality up/ development effort down)

 

 

Process Model for Prototype Development

prototype은 재활용하기 어려우므로 버리는게 낫다.

prototyping을 빠르고 효율적으로(low-cost) 하기 위해서는,

- 몇가지 functionality는 버린다

- non-functaional req에 대해서는 좀 널널하게.

- error 와 quality standard에 대해서는 약간 무시.

 

 

Prototyping의 문제점 

user는 최종 시스템을 사용하는 것과 동일한 방법으로 prototype을 사용할 수 없다.

- 부정확한 피드백 올 수 있다.

- 고객의 대표가 피드백 하는 것이므로, 실제고객 != 대표고객이므로, 다른 방향으로 제품이 흘러갈수도.

 

prototypes는 reuse하기 어렵다.

- 보통 프로토타입은 documentation 하지 않음.

- 앞서 말한 것처럼, 빠르고 low-cost로 만들기 위해 이것저것 막 무시하면서 만듬.

 

 

2. Incremental delivery

각 버전이 나올 때마다 반드시 고객에게 갖다 바쳐야함. 

customer가 미리 보고 평가를 하기 때문에 나중에 큰 변화와 rework가 발생하지 않는다.

각각의 버전이 real operational environment (실제 운영환경) 아래의 complete product. 어떤 버전이 맘에 들면 그걸로 선택됨. 버리는 게 아님!

 

개발된 increments 중 일부는 고객에게 전달되고, 그들의 환경에 맞게 이용된다.

 

Incremental development & Incremental delivery

Incremental development 

- increment로 시스템을 개발하고, 다음 increment로 넘아가기 전에 각 increment를 평가

- agile 방식에 사용되는 일반적인 방식

- user/customer proxy에 의해 수행되는 평가

 

Incremental delivery

- incremental development + delivery

- 매 버전을 고객에게 전달 . 최종 사용자(end-users)가 사용할 increment 전달

- 소프트웨어의 실제 사용에 대한 보다 현실적인 평가

- increment는 교체되는 시스템보다 기능이 적기 때문에 교체 시스템을 구현하기 어려움 (?)

 

Stages of incremental devliery

(1) customer가 Req에 대해 정의+prioritize 우선순위 정하기

(2) delivery increments 대강 roughly 정의

(3) increments가 확립되면, 첫번째 increment에 대한 req를 상세하게detail하게 정의하고, 개발함

(4) increment가 complete되면, customer에게 delivered하여 고객의 환경에서 설치하고 사용.

우선순위 높은거부터 먼저

Incremental delivery의 장점

- 버리는게 아니라 진짜 사용될 real system이니까 고객은 early increments를 프로토타입처럼 사용해볼 수 있고, 이후 increments에 대한 requirement에 대한 경험치를 쌓을 수 있다.

- 고객 입장에서, 전체 시스템이 delivered 되는걸 기다릴 필요가 없다. 첫번째 increment가 우선순위가 가장 높은, 중요한 req를 담고 있으니까. 

- 시스템 변화에 대해 통합하기가 상대적으로 쉬움. (이거는 incremental development의 장점이기도 함)

- 가장 중요한 시스템 서비스는 가장 많은 테스트를 받는다. 맨 첨부터 만들어지니까.

 

Incremental delivery의 단점

- 고객 입장에서, 익숙해질만하면 새로운게 오고, 이런게 반복되니까 불편. 고객은 incomplete new system을 실험하는 걸 안좋아함.

- 모든 increments에 공통으로 필요한 기능을 정의하기 어려움(?). req이 나중에까지 상세하게 정의되지 않음. 따라서 시스템의 구조는 degrade.

- final increment까지 완벽한 시스템 기능명세 (system specification)이 없다. 

 

 

 

 

 

 

Process Improvement

프로세스를 개선하려면, 현황부터 파악해야함. 1~5레벨로 평가

Nowadays, 보다 cheaper, better, delivered faster 한 소프트웨어를 원한다.

현존하는 process를 이해하고, product quality를 향상시키게 바꾸거나 costs/time을 감소하도록 바꿔야 한다.

 

Process imporvement에 접근하는 2가지 방식

1) Process maturity approach

- "사람을 믿지 말자." 정확한 규율 속에서 굴러가도록.

- process와 project management를 탄탄하게 만들어서

- software processs는 process maturity level로 평가. 

- 궁극적인 목표는 product quality 와 process predictability 향상

 

2) Agile approach

- "사람을 믿자". 규정없이. 소규모의 사람들이 으쌰으쌰

- 팀원들 간의 끊임없는 커뮤니케이션 중시

- 반복적인 개발과 software process의 overhead 감소에 집중한 방식

- 이거 chapter 3에서 다룸

 

 

Process Improvement Cycle

(1) Measure 수치화

software process, product의 여러가지 attributes에 대한 수치화

 

(2) Analyze 분석

현재의 process 평가. process weakness, bottlenecks에 대해 식별함

 

(3) Change 

식별된 일부 프로세스 약점을 해결하기 위해 프로세스 변경이 제안됨

 

 

Process Measurement

- quantitative = 가능한 한 수치로 나와야함

해당 프로세스를 사용하여 개발된 프로세스나 소프트웨어의 구체적인 (concrete) data

이 데이터들은 process improvement의 가치를 평가하는 데에 사용된다.

 

ex: software process data. 사용할 데이터로 무엇을 측정하는가?

- Time 

- Resources required for processes or activities

- Number of defects 등

 

 

 

Capability Maturity Model (CMM)

현재 수행하는 프로젝트의 레벨이 몇인가 측정.

Level 1 (lowest) ~ Level 5 (hightest)

 

목적은 현존하는 software processes의 향상.

 

암기하기!!!

Level 1. Initial

- 혼돈의 카오스. 두 낫띵. 암것도 안하는 상태

 

Level 2. Managed (or Repeatable)

- 규정이 있긴함 (수동적인 규정). 관리 정도는 되고 있다.

- 그러나, 규정을 위반해도 통제가 안됨.

 

Level 3. Defined

- 규정도 있고 통제도 있고 (적극적인 규정, 통제)

 

Level 4. Quantitatively Managed (or Managed)

- 수치적 관리. 프로세스에 대한 수치가 기록되고 관리됨

 

Level 5. Optimizing

- 수치를 기반으로 self-improve가 가능한 상태

 

 

* 헷갈리는게, Level 4를 managed라고 하면, Level 2를 Reapeatable이라 함.

 

 

 

참고만 하기