Ortak bir sorundan çalışan bir sisteme.

Mevcut süreci onu kullanan kişilerle birlikte ele alırız. Kısıtları, veri kaynaklarını ve sistemin desteklemesi gereken kararları belirleriz.

• Çıktı: sorun özeti, kapsam ve teslim teklifi
• Karar: önce hangi iş akışının sınanacağı
• Ölçüm: kalite, süre, emek veya maliyet için başlangıç durumu

Kritik iş akışının yararlı en küçük sürümünü oluşturur ve temsili örneklerle sınarız. İnsan geri bildirimi, uygulama büyümeden eksikleri ortaya çıkarır.

• Çıktı: çalışan prototip ve değerlendirme notları
• Karar: kanıta göre devam etmek, değiştirmek veya durmak
• Ölçüm: kararlaştırılan ölçütlere göre görev tamamlama ve çıktı kalitesi

Doğrulanmış iş akışını; arayüz, seçilen entegrasyonlar, inceleme kontrolleri ve kurtarma yollarıyla üzerinde anlaşılan sisteme dönüştürürüz.

• Çıktı: kabul testine hazır uygulama
• Karar: yayın ölçütlerinin karşılanıp karşılanmadığı
• Ölçüm: güvenilirlik, yanıt süresi, işletim maliyeti ve inceleme emeği

Sistemin nasıl çalıştığını belgeler ve kimin işleteceğini kararlaştırırız. Yayın sonrasında yeni varsayımlar yerine gerçek kullanım bir sonraki geliştirmeyi yönlendirir.

• Çıktı: dokümantasyon, devir ve kararlaştırılmış destek sorumlulukları
• Karar: hangi sonraki değişikliklerin yatırıma değer olduğu
• Ölçüm: başlangıç durumuna kıyasla kalıcı yarar

CAP benzeri bir editoryal akışta sorumuz somuttur: bir taslak, onaylanana kadar ne kadar düzeltme gerektiriyor? RepoHunter benzeri bir katalogda ise şunu sorabiliriz: kullanıcı adını hatırlamadığı yararlı bir depoyu bulabiliyor mu? Kontrolleri ürününüzün hizmet ettiği işe göre seçer, kabul ölçütlerini sizinle kararlaştırırız. Bunlar sınanabilecek davranış örnekleridir; elde edilmiş ürün sonuçları değildir.