4. Process Models

Learning Goals

  • Process(ν”„λ‘œμ„ΈμŠ€) κ³ λ € μ‚¬ν•­μ˜ ν•„μš”μ„± 이해
  • 주어진 project(ν”„λ‘œμ νŠΈ)에 μ ν•©ν•œ process(ν”„λ‘œμ„ΈμŠ€) 선택
  • Iteration(반볡)을 ν†΅ν•œ project(ν”„λ‘œμ νŠΈ) 및 engineering(μ—”μ§€λ‹ˆμ–΄λ§) risks(μœ„ν—˜) ν•΄κ²°
  • Process quality(ν”„λ‘œμ„ΈμŠ€ ν’ˆμ§ˆ) 보μž₯

The Waterfall Model

  • [폭포수 λͺ¨λΈ diagram]

Margaret Hamilton

The "V" Model(80s, 90s)

  • [V λͺ¨λΈ diagram]

When is Waterfall Appropriate?

  1. Requirements(μš”κ΅¬μ‚¬ν•­)κ°€ 사전에 μ•Œλ €μ§
  2. cost(λΉ„μš©), schedule(일정), performance(μ„±λŠ₯), safety(μ•ˆμ „), security(λ³΄μ•ˆ), user interfaces(μ‚¬μš©μž μΈν„°νŽ˜μ΄μŠ€), organizational impacts(쑰직적 영ν–₯) λ“±μœΌλ‘œ μΈν•œ λ―Έν•΄κ²° κ³ μœ„ν—˜ risks(μœ„ν—˜)κ°€ μš”κ΅¬μ‚¬ν•­μ— μ—†μŒ
  3. μš”κ΅¬μ‚¬ν•­μ˜ nature(본질)이 많이 λ³€κ²½λ˜μ§€ μ•ŠμŒ
  4. μš”κ΅¬μ‚¬ν•­μ΄ λͺ¨λ“  μ£Όμš” system stakeholders(μ‹œμŠ€ν…œ μ΄ν•΄κ΄€κ³„μž)의 κΈ°λŒ€μ™€ ν˜Έν™˜λ¨
  5. μš”κ΅¬μ‚¬ν•­ κ΅¬ν˜„μ„ μœ„ν•œ architecture(μ•„ν‚€ν…μ²˜)κ°€ 잘 이해됨
  6. 순차적으둜 μ§„ν–‰ν•˜κΈ°μ— μΆ©λΆ„ν•œ μ‹œκ°„μ΄ 있음

Key Challenge: Change

  • Software(μ†Œν”„νŠΈμ›¨μ–΄)λŠ” λ³€κ²½ κ°€λŠ₯ν•œ("soft") κ²ƒμ²˜λŸΌ λ³΄μž„
  • Developers(개발자)λŠ” λ³€κ²½ 및 "μΆ”κ°€ features(κΈ°λŠ₯)"에 빠지기 쉬움
  • Customers(고객)λŠ” μ’…μ’… 무엇이 λ³€κ²½ν•˜κΈ° 쉽고 무엇이 μ–΄λ €μš΄μ§€ μ΄ν•΄ν•˜μ§€ λͺ»ν•¨
  • "Good enough(μΆ©λΆ„νžˆ μ’‹μŒ)" vs. "optimal(졜적)"

Early Improvement: Sequencing

  • 초기 μ†Œν”„νŠΈμ›¨μ–΄ κ³ λ € 사항 κ°•μ œ
  • Waterfall(폭포수 λͺ¨λΈ)은 70λ…„λŒ€ TRW(항곡 우주 μ •λΆ€ κ³„μ•½μž)μ—μ„œ(prototypes(ν”„λ‘œν† νƒ€μž…)κ³Ό 같은) iteration(반볡)을 μœ„ν•œ λͺ‡ 가지 μΆ”κ°€ ꢌμž₯ 사항과 ν•¨κ»˜ λ„μž…λ¨
  • 전톡적인 engineering(μ—”μ§€λ‹ˆμ–΄λ§)을 λͺ¨λΈλ‘œ 함
    • 건섀 μ „ Blueprints(청사진)
    • 무엇을 λ§Œλ“€μ§€ κ²°μ •, ꡬ좕, ν…ŒμŠ€νŠΈ, 배포
    • λ³€κ²½ κ°μ†Œ
  • 일상적인 κ°œλ°œμ„ μœ„ν•œ 성곡적인 λͺ¨λΈ
  • large scale(λŒ€κ·œλͺ¨)μ—μ„œ 문제 λ°œμƒ
    • Requirements(μš”κ΅¬μ‚¬ν•­) -> Delays(지연) -> Surprise!(놀라움!)

A Natural Engineering Process?

  • [μ™Όμͺ½ λ°•μŠ€]
    • 무엇을 λ§Œλ“€μ§€ κ²°μ •
    • ꡬ좕
    • ν…ŒμŠ€νŠΈ
    • 배포
  • [였λ₯Έμͺ½ λ°•μŠ€]
    • 무엇을 λ§Œλ“€μ§€ 미리 μ•Œμ§€ λͺ»ν•¨
    • μ–΄λ–»κ²Œ λ§Œλ“€μ§€ λͺ¨λ“  μ„ΈλΆ€ 사항을 μ•Œμ§€ λͺ»ν•¨
    • testing(ν…ŒμŠ€νŠΈ) 및 evaluation(평가)에 어렀움
    • 배포, evolve(진화), 재배포

Iteration!

  • 초기 및 λΉˆλ²ˆν•œ feedback(ν”Όλ“œλ°±)
  • 지속적인 adaptation(적응) 지원
  • Risks(μœ„ν—˜) μš°μ„  ν•΄κ²°

The Spiral Model(Barry Boehm)

  • [λ‚˜μ„ ν˜• λͺ¨λΈ diagram]

Software Engineering Risks

  • Project risks(ν”„λ‘œμ νŠΈ μœ„ν—˜)
    • ν”„λ‘œμ νŠΈ 지연, buggy(버그 많음), cost overruns(λΉ„μš© 초과)
  • System risks(μ‹œμŠ€ν…œ μœ„ν—˜)
    • Security(λ³΄μ•ˆ) 및 safety(μ•ˆμ „) 문제
    • 예: Toyota 사둀
  • Engineering risks(μ—”μ§€λ‹ˆμ–΄λ§ μœ„ν—˜)
    • λΆ€μ μ ˆν•œ technology(기술) 선택, validation(검증) 문제, usability(μ‚¬μš©μ„±) 문제, scalability(ν™•μž₯μ„±) 문제 …

Cone of Uncertainty

  • [λΆˆν™•μ‹€μ„±μ˜ 원뿔]
  • Steve McConnell. 1996. Rapid Development

Mitigation of Risk Through Process Interventions(Examples)

  • Risk-driven process(μœ„ν—˜ 주도 ν”„λ‘œμ„ΈμŠ€)
    • Prioritization(μš°μ„ μˆœμœ„ 지정) 및 prototyping(ν”„λ‘œν† νƒ€μ΄ν•‘)
  • Architecture(μ•„ν‚€ν…μ²˜) 및 design(섀계)
    • Risks(μœ„ν—˜) 격리/encapsulate(μΊ‘μŠν™”)
    • 업계 standards(ν‘œμ€€) μ€€μˆ˜
  • Design for assurance(보증을 μœ„ν•œ 섀계)
    • Preventive engineering(예방 곡학)
    • μ‹œμŠ€ν…œκ³Ό evidence(증거)의 Co-development(곡동 개발)
  • Functionality(κΈ°λŠ₯μ„±) 및 usability(μ‚¬μš©μ„±)
    • Prototypes(ν”„λ‘œν† νƒ€μž…), 초기 usability labs(μ‚¬μš©μ„± 랩)

Key: Iterative Processes

  • Interleaving(인터리빙) 및 repeating(반볡)
    • Requirements engineering(μš”κ΅¬μ‚¬ν•­ 곡학), Risk assessment(μœ„ν—˜ 평가)
    • Architecture(μ•„ν‚€ν…μ²˜) 및 design(섀계)
    • Implementation(κ΅¬ν˜„)
    • Quality assurance(ν’ˆμ§ˆ 보증)
    • Deployment(배포)
  • ν•˜μ§€λ§Œ μ–Έμ œ, μ–΄λ–€ sequence(μˆœμ„œ)둜, μ–Όλ§ˆλ‚˜ 자주?
  • 결정을 내리기 μœ„ν•΄ μ–΄λ–€ measurements(μΈ‘μ •)이 ν•„μš”ν•œκ°€?

Iteration Decision

  • λ„ˆλ¬΄ 느린 경우?
    • λŠ¦μ€ λ°˜μ‘, predictability(예츑 κ°€λŠ₯μ„±) κ°μ†Œ
  • λ„ˆλ¬΄ λΉ λ₯Έ 경우?
    • Overhead(μ˜€λ²„ν—€λ“œ), innovation(ν˜μ‹ ) κ°μ†Œ
  • "Death spiral(죽음의 λ‚˜μ„ )"
    • deferred commitment(μ—°κΈ°λœ 약속), κ²°λ‘  μ—†λŠ” prototypes(ν”„λ‘œν† νƒ€μž…), missing feedback loops(ν”Όλ“œλ°± 루프 λΆ€μž¬)
  • -> risks(μœ„ν—˜) 및 measurement data(μΈ‘μ • 데이터) 기반으둜 좔진; project(ν”„λ‘œμ νŠΈ)별 κ²°μ •

Process Quality

Process Evaluation

  • 우리 project(ν”„λ‘œμ νŠΈ)λŠ” μ–Όλ§ˆλ‚˜ predictable(예츑 κ°€λŠ₯)ν•œκ°€?
  • 33%의 쑰직이 productivity(생산성) 및 efficiency(νš¨μœ¨μ„±) 데이터 μˆ˜μ§‘
  • 8%κ°€ quality(ν’ˆμ§ˆ) 데이터 μˆ˜μ§‘
  • 60%λŠ” process(ν”„λ‘œμ„ΈμŠ€)λ₯Ό monitor(λͺ¨λ‹ˆν„°λ§)ν•˜μ§€ μ•ŠμŒ

Process Improvement Loop

  • [ν”„λ‘œμ„ΈμŠ€ κ°œμ„  루프 diagram]
  • High-level approaches(κ³ μˆ˜μ€€ μ ‘κ·Ό 방식):
    • Opportunistic(기회주의적), double-loop learning(이쀑 루프 ν•™μŠ΅) 기반
    • Analytic(뢄석적), measurement(μΈ‘μ •) + principles(원칙) 기반
    • Best practices(λͺ¨λ²” 사둀) frameworks(ν”„λ ˆμž„μ›Œν¬)
  • Documenting(λ¬Έμ„œν™”)
  • Training and enforcement(ꡐ윑 및 μ‹œν–‰)
  • Monitoring(λͺ¨λ‹ˆν„°λ§)
  • Analyzing difference(차이 뢄석)
  • Acting(쑰치)

Defect Prevention Process, IBM 1985

  • mishap(사고) λ°œμƒ μ‹œ:
  1. Take corrective action(μ‹œμ • 쑰치 μˆ˜ν–‰)
  2. Conduct root cause analysis(κ·Όλ³Έ 원인 뢄석 μˆ˜ν–‰)(Root cause(s)(κ·Όλ³Έ 원인): Management(경영), people(μ‚¬λžŒ), process(ν”„λ‘œμ„ΈμŠ€), equipment(μž₯λΉ„), material(자재), environment(ν™˜κ²½)):
    • μ™œ mishap(사고)이 λ°œμƒν–ˆλŠ”κ°€? μ™œ 더 일찍 κ°μ§€λ˜μ§€ μ•Šμ•˜λŠ”κ°€?
    • 더 κ΄‘λ²”μœ„ν•œ 문제λ₯Ό λ‚˜νƒ€λ‚΄λŠ” trend(μΆ”μ„Έ)κ°€ μžˆλŠ”κ°€? ν•΄κ²°ν•  수 μžˆλŠ”κ°€?
    • 이 λ§ˆμ§€λ§‰ λ‹¨κ³„μ—μ„œ 무엇이 잘 λ˜μ—ˆλŠ”κ°€? 무엇이 잘λͺ»λ˜μ—ˆλŠ”κ°€?
  3. team context(νŒ€ 상황) λ‚΄μ—μ„œ preventive actions(예방 쑰치) κ΅¬ν˜„
    • 성곡적인 λ³€κ²½ 사항은 corporate level(κΈ°μ—… μˆ˜μ€€)으둜 μ „νŒŒλ¨

Six Sigma, Motorola 1985

  • "Six Sigma(μ‹μŠ€ μ‹œκ·Έλ§ˆ)λŠ” 원인을 식별 및 μ œκ±°ν•˜κ³  variability(변동성)λ₯Ό μ΅œμ†Œν™”ν•˜μ—¬ process outputs(ν”„λ‘œμ„ΈμŠ€ μ‚°μΆœλ¬Ό)의 quality(ν’ˆμ§ˆ)λ₯Ό κ°œμ„ ν•˜κ³  defects(결함)λ₯Ό 100만 κ°œλ‹Ή 3.4개둜 μ€„μ΄λŠ” 것을 좔ꡬ함. manufacturing(제쑰) 및 services(μ„œλΉ„μŠ€)에 적용 κ°€λŠ₯함. statistical methods(톡계적 방법)λ₯Ό μ‚¬μš©ν•˜λ©°, 쑰직 내뢀에 μ „λ¬Έκ°€("Champions", "Black Belts", "Green Belts")λ“€λ‘œ κ΅¬μ„±λœ νŠΉλ³„ν•œ infrastructure(인프라)λ₯Ό 생성함."
  • DMAIC, Existing products and services(κΈ°μ‘΄ μ œν’ˆ 및 μ„œλΉ„μŠ€)
    • Define(μ •μ˜)
    • Measure(μΈ‘μ •)
    • Analyze(뢄석)
    • Improve(κ°œμ„ )
    • Control(관리)
  • DMADV & DFSS, New or redesigned products and services(μ‹ κ·œ λ˜λŠ” μž¬μ„€κ³„λœ μ œν’ˆ 및 μ„œλΉ„μŠ€)
    • Define(μ •μ˜)
    • Measure(μΈ‘μ •)
    • Analyze(뢄석)
    • Design(섀계)
    • Verify(검증)

Google SRE Process

  • Blame-free postmortem culture(λΉ„λ‚œ μ—†λŠ” 사후 κ²€ν†  λ¬Έν™”)
  • "μ΄λŸ¬ν•œ incidents(사건)λ‘œλΆ€ν„° λ°°μš°λŠ” κ³΅μ‹ν™”λœ process(ν”„λ‘œμ„ΈμŠ€)κ°€ μ—†λ‹€λ©΄, 사건듀은 λ¬΄ν•œμ • μž¬λ°œν•  수 있음."

Process Standards

  • [μ†Œν”„νŠΈμ›¨μ–΄ μΈ‘μ • κ΄€λ ¨ μ±… ν‘œμ§€]
  • C. Ebert and R. Dumke, Software Measurement,: Establish – Extract – Evaluate – Execute, Springer, 2007

Capability Maturity Model(CMM)

  • customer(고객)λŠ” 쑰직이 μ›ν•˜λŠ” product(μ œν’ˆ)λ₯Ό delivering(제곡)ν•  λŠ₯λ ₯이 μžˆλ‹€λŠ” confidence(μ‹ λ’°)λ₯Ό μ–»μ–΄μ•Ό 함
  • US Department of Defense(λ―Έκ΅­ κ΅­λ°©λΆ€)λŠ” contractors(계약업체)λ₯Ό ν‰κ°€ν•˜κΈ°λ₯Ό μ›ν–ˆμŒ
    • Software processes(μ†Œν”„νŠΈμ›¨μ–΄ ν”„λ‘œμ„ΈμŠ€)의 maturity(μ„±μˆ™λ„)λ₯Ό 평가할 framework(ν”„λ ˆμž„μ›Œν¬)κ°€ ν•„μš”ν–ˆμŒ
    • 1986λ…„, Software Engineering Institute(SEI)λŠ” CMM이라 뢈릴 framework(ν”„λ ˆμž„μ›Œν¬) 개발 μ‹œμž‘
  • CMM model(CMM λͺ¨λΈ)μ—μ„œ, 쑰직의 maturity level(μ„±μˆ™λ„ μˆ˜μ€€)은 쑰직이 low cost(μ €λΉ„μš©), high quality(κ³ ν’ˆμ§ˆ) μ†Œν”„νŠΈμ›¨μ–΄λ₯Ό μ–Όλ§ˆλ‚˜ 잘 생산할 수 μžˆλŠ”μ§€λ₯Ό μ•Œλ €μ€Œ
  • ν˜„μž¬ maturity level(μ„±μˆ™λ„ μˆ˜μ€€)을 μ•Œλ©΄, 쑰직은 λ‹€μŒ μƒμœ„ level(μˆ˜μ€€)에 λ„λ‹¬ν•˜κΈ° μœ„ν•΄ λ…Έλ ₯ν•  수 있음
    • CMM model(CMM λͺ¨λΈ)μ—λŠ” 5개의 maturity levels(μ„±μˆ™λ„ μˆ˜μ€€)이 있음

SEI's Capability Maturity Model(Integration)

  • Process(ν”„λ‘œμ„ΈμŠ€)κ°€ μ•„λ‹Œ meta-process(메타 ν”„λ‘œμ„ΈμŠ€)
  • CMM(I)λŠ” νšŒμ‚¬κ°€ 자체 process(ν”„λ‘œμ„ΈμŠ€)λ₯Ό μ–Όλ§ˆλ‚˜ 잘 measures(μΈ‘μ •)ν•˜λŠ”μ§€ μΈ‘μ •
    • 주둜 US government(λ―Έκ΅­ μ •λΆ€)κ°€ software vendors(μ†Œν”„νŠΈμ›¨μ–΄ 곡급업체)의 estimates(견적)λ₯Ό ν†΅μ œν•˜κΈ° μœ„ν•΄ μ‚¬μš©
    • 더 λ†’κ³  μ•ˆμ •μ μΈ estimate(견적)λ₯Ό μˆ˜μš©ν•˜λŠ” 것을 μ„ ν˜Έ

The CMMI Framework

  • [CMMI ν”„λ ˆμž„μ›Œν¬ μˆ˜μ€€ diagram]
  • Level 1 "Initial"(초기): Processes(ν”„λ‘œμ„ΈμŠ€) unpredictable(예츑 λΆˆκ°€λŠ₯), poorly controlled(μ œμ–΄ 미흑) and reactive(λŒ€μ‘μ )
  • Level 2 "Managed"(관리): Process(ν”„λ‘œμ„ΈμŠ€) characterized(νŠΉμ§•ν™”) for projects(ν”„λ‘œμ νŠΈ) and is often reactive(λŒ€μ‘μ )
  • Level 3 "Defined"(μ •μ˜): Process(ν”„λ‘œμ„ΈμŠ€) characterized(νŠΉμ§•ν™”) for the organization(쑰직) and is proactive(λŠ₯동적).(Projects(ν”„λ‘œμ νŠΈ)λŠ” 쑰직의 standard(ν‘œμ€€)μ—μ„œ process(ν”„λ‘œμ„ΈμŠ€)λ₯Ό tailor(μ‘°μ •)함)
  • Level 4 "Quantitatively Managed"(μ •λŸ‰μ  관리): Process(ν”„λ‘œμ„ΈμŠ€) measured(μΈ‘μ •) and controlled(μ œμ–΄)
  • Level 5 "Optimizing"(μ΅œμ ν™”): Focus on process improvement(ν”„λ‘œμ„ΈμŠ€ κ°œμ„ μ— 집쀑)
  • Higher Risk - Lower Productivity/Quality(κ³ μœ„ν—˜ - 저생산성/ν’ˆμ§ˆ) -> Lower Risk - Higher Productivity/Quality(μ €μœ„ν—˜ - 고생산성/ν’ˆμ§ˆ)

Key Practices of Each CMMI Level

  • [CMMI μˆ˜μ€€λ³„ Key Practices ν‘œ]

Capability Maturity Model(CMM)

  • [CM μˆ˜μ€€λ³„ Key Process Areas(KPA) diagram]

Capability Maturity Model(CMM)

  • Common features of key practices(핡심 ν”„λž™ν‹°μŠ€μ˜ 곡톡 νŠΉμ§•)
    • λͺ¨λ“  key process area(핡심 ν”„λ‘œμ„ΈμŠ€ μ˜μ—­)의 key practices(핡심 ν”„λž™ν‹°μŠ€)λŠ” common features(곡톡 νŠΉμ§•)라 λΆˆλ¦¬λŠ” 5가지 categories(λ²”μ£Ό)둜 ꡬ성됨
    • Common features(곡톡 νŠΉμ§•)λŠ” Key Process Area(KPA)의 implementation(κ΅¬ν˜„)이 effective(효과적), repeatable(반볡 κ°€λŠ₯), lasting(지속적)인지λ₯Ό λ‚˜νƒ€λ‚΄λŠ” key practices(핡심 ν”„λž™ν‹°μŠ€)의 attributes(속성)μž„
  • 5가지 common features(곡톡 νŠΉμ§•) categories(λ²”μ£Ό)λŠ” λ‹€μŒκ³Ό κ°™μŒ
    • Commitment to perform(μˆ˜ν–‰ μ˜μ§€)
    • Ability to perform(μˆ˜ν–‰ λŠ₯λ ₯)
    • Activities performed(μˆ˜ν–‰ ν™œλ™)
    • Measurement and analysis(μΈ‘μ • 및 뢄석)
    • Verifying implementation(κ΅¬ν˜„ 검증)

Capability Maturity Model(CMM)

  • Application of the CMM(CMM의 적용)
    • 쑰직이 νŠΉμ • maturity(μ„±μˆ™λ„) level(μˆ˜μ€€)에 λ„λ‹¬ν•˜κΈ° μœ„ν•΄μ„œλŠ”, ν•΄λ‹Ή level(μˆ˜μ€€) 및 λͺ¨λ“  이전 levels(μˆ˜μ€€)의 λͺ¨λ“  KPAs(핡심 ν”„λ‘œμ„ΈμŠ€ μ˜μ—­)의 λͺ¨λ“  goals(λͺ©ν‘œ)κ°€ μΆ©μ‘±λ˜μ–΄μ•Ό 함
  • 예: 쑰직이 Level 3에 λ„λ‹¬ν•˜λ €λ©΄, Level 2의 6개 KPA와 Level 3의 7개 KPAλ₯Ό λͺ¨λ‘ μΆ©μ‘±ν•΄μ•Ό 함
    • SEIλŠ” 쑰직의 self-assessment(자체 평가)λ₯Ό 돕기 μœ„ν•΄ Capability Maturity Model-Based Assessment Internal Process Improvement(CBA-IPI)λ₯Ό κ°œλ°œν•¨
  • CBA-IPIλŠ” CMM을 reference model(μ°Έμ‘° λͺ¨λΈ)둜 μ‚¬μš©ν•˜μ—¬ μ–΄λ–€ KPAκ°€ 좩쑱되고 있고 μ–΄λ–€ 것이 κ°œμ„ λ˜μ–΄μ•Ό ν•˜λŠ”μ§€ μ‹λ³„ν•¨μœΌλ‘œμ¨ 쑰직의 process capability(ν”„λ‘œμ„ΈμŠ€ λŠ₯λ ₯)λ₯Ό 평가함
    • SEIλŠ” 쑰직의 formal evaluation(곡식 평가)λ₯Ό μœ„ν•œ mechanism(λ©”μ»€λ‹ˆμ¦˜)을 μ œκ³΅ν•˜κΈ° μœ„ν•΄ CMM Appraisal Framework(CAF)λ₯Ό κ°œλ°œν•¨
  • CAFλŠ” external assessors(μ™ΈλΆ€ ν‰κ°€μž)κ°€ CAF-compliant evaluation methods(CAF μ€€μˆ˜ 평가 방법)λ₯Ό 섀계할 λ•Œ μ‚¬μš©ν•  requirements(μš”κ΅¬μ‚¬ν•­)와 guidelines(κ°€μ΄λ“œλΌμΈ)을 μ„€λͺ…함

Final Check:

  • All ## headings are in English only.
  • Bullets use -.
  • Numbered lists use 1..
  • Korean translation with English(ν•œκ΅­μ–΄) format for first occurrences of key terms within the body.
  • Noun endings used.
  • No bolding.
  • No horizontal lines.
  • LaTeX formatting applied(none in this specific text).
  • Backticks used for technical terms(none in this specific text, CMM-SW is a name).
  • All content extracted.

Looks good.

Capability Maturity Model(CMM)

  • Capability Maturity Model Integration(CMMI)
    • Software(μ†Œν”„νŠΈμ›¨μ–΄) λΆ„μ•Ό(CMM-SW둜 μ•Œλ €μ§)μ—μ„œ CMM의 성곡적인 적용 이후, λ‹€λ₯Έ λΆ„μ•Όμ˜ CMM도 개발됨
  • Systems Engineering(μ‹œμŠ€ν…œ 곡학) CMM
  • Integrated Product Development(톡합 μ œν’ˆ 개발) CMM
  • Electronic Industry Alliance(μ „μž μ‚°μ—… μ—°ν•©) 731 CMM
  • Software Acquisition(μ†Œν”„νŠΈμ›¨μ–΄ νšλ“) CMM
  • People(인λ ₯) CMM
  • Supplier Source(곡급업체 μ†ŒμŠ€) CMM

Process Tradeoffs

  • (μ°Έκ³ : λ§Žμ€ μ‚°μ—… ν™˜κ²½(예: μžλ™μ°¨ μ‚°μ—…)μ—μ„œμ˜ 성곡 사둀)
  • Process(ν”„λ‘œμ„ΈμŠ€) vs product quality(μ œν’ˆ ν’ˆμ§ˆ)
    • Process Quality(ν”„λ‘œμ„ΈμŠ€ ν’ˆμ§ˆ)λŠ” Product Quality(μ œν’ˆ ν’ˆμ§ˆ)에 영ν–₯을 λ―ΈμΉ˜μ§€λ§Œ, 보μž₯ν•˜μ§€λŠ” μ•ŠμŒ
  • 법적 λ°©μ–΄ μ „λž΅μœΌλ‘œμ„œμ˜ "best practices(λͺ¨λ²” 사둀)" μ€€μˆ˜
    • "Check box compliance(μ²΄ν¬λ°•μŠ€ μ€€μˆ˜)"?

Summary

  • Sequential process models(순차적 ν”„λ‘œμ„ΈμŠ€ λͺ¨λΈ)은 "coding(μ½”λ”©) μ „ 생각"을 κ°•μ‘°
  • μ’…μ’… λ„ˆλ¬΄ rigid(경직)되며, requirements(μš”κ΅¬μ‚¬ν•­)와 environments(ν™˜κ²½) λ³€ν™”
  • Risks(μœ„ν—˜) 해결을 μœ„ν•œ Iteration(반볡)
  • Process(ν”„λ‘œμ„ΈμŠ€) μΈ‘μ •, 지속적인 process(ν”„λ‘œμ„ΈμŠ€) κ°œμ„ 
졜근 μˆ˜μ •:
Contributors: kmbzn

BUILT WITH

CloudflareNode.jsGitHubGitVue.jsJavaScriptVSCodenpm

All trademarks and logos are property of their respective owners.
Β© 2025 kmbzn Β· MIT License