Gereksinimleri geliştirme

Ürün ne hissedarlar beklediğiniz gereksinimleri açıklanmaktadır.Sözlük ve iş etki alanı kavramları kullanarak iş hissedarlar ile kolayca ele izin terimleriyle gereksinimlerinizi express.Gereksinimleri tartışmak kendisi uygulamasına bağlıdır.Yalnızca davranış ve hizmet beklentilerini kullanıcıları ancak aynı zamanda yasal kısıtlamalar ve ticari standartları, kalite gereksinimlerini içerir.

Kayıt gereksinimleri tarafından Visual Studio Team Foundation Server kullanarak madde gereksinimleri çalışma, aşağıdaki avantajlara sahip:

• Gereksinimleri durumlarda sınamak için bağlayarak memnun olduğunu doğrulayın.

• Görev çalışma öğeleri bağlayarak gereksinimlerini uygulamak doğru ilerlemeyi izlemek.

• Genel ve ayrıntılı gereksinimleri içine gereksinimleri böylece daha kolay yönetebilmek ve ilerleme raporları bilgileri özetleyebilir olacak şekilde yapılandırın.

• Gereksinimleri de model Visual Studio Ultimate, model öğeleri gereksinimlerinin bağlanarak Team Foundation Server.

Bu konuda çok büyük gövde gereksinimlerini belirleme konu üzerinde kullanılabilir belgeleri çoğaltmak denemez.Bunun yerine, kullanımı ile ilgili önemli yönleri üzerinde durulmuştur Visual Studio CMMI için uygun bir şekilde Araçlar. CMMI hakkında daha fazla bilgi için, bkz. Arka plana CMMI.

Herhangi bir geliştirme faaliyetleri gibi bu konuda açıklanan etkinliklerin katı sırayla gerçekleştirilmesi gereken değil.Etki alanı modeli, bir etkinliğe yardımcı olduğu için senaryo diğer etkinliği artırmak yazarken geliştirin.Yaklaşımlar kodlamak için kullanılan süre olarak senaryoları geliştir.Yazılan ve gösterilen kod deneyimiyle yeniden uygulanması için henüz senaryoları besleme.

Bu konuda

Ne zaman gereksinimlerini geliştir

Vizyon ifadesi yazın

Senaryo yazma

İş etki alanı modeli

Kalite hizmet gereksinimlerini geliştir

Gereksinimlerini gözden geçir

Doğrulama

İnceleme ve düzenleme gereksinimleri

Ne zaman gereksinimlerini geliştir

Team Foundation Serveryinelemeli çalışma destekler ve bu uygulama yapıldığında en etkili erken yineleme olası kullanıcıları ve diğer hissedarlar'ndan görüş elde etmek için kullanılır. Bu görüş, gelecekte yineleme için belirtilen gereksinimleri artırmak için kullanılabilir.Bu ultimate yükleme daha verimli herhangi bir kullanıcı deneme olmadan aynı dönem içinde geliştirilen bir ürün'den bir ürünün, sonuçlanır.Projenizi daha büyük bir programda birçok arasında bir bileşeni ise, genel ürün geliştirmek programın mimarları diğer bileşenleri ile erken tümleştirme sağlar.

Bu esneklik, müşteri ya da paralel proje ortakları kesin sözler vermek zorunda karşı dengelenmelidir.

Denetlenen bir ölçüde bu nedenle gereksinimleri geliştirilmiş ve proje boyunca Siyah Zemin.Ayrıntılı gereksinimler proje sırasında olası olduğu için uygun uygulama büyük bir olasılıkla neden olmadan önce tam olarak belirleme çaba boşa tüketilmiş.

• Yineleme 0'da, ürün planı oluşturmak için yeterli ayrıntı ile ana özelliklerini açıklayan gereksinimleri kümesi geliştirin.Ürün planı yineleme için gereksinimleri atar ve hangi gereksinimi her yinelemenin sonunda karşılanacağıyla belirtmektedir.Etki alanı modeli başlıca kavramları ve aktiviteleri oluşturabilir ve bu kavramları kullanıcılarla tartışma hem de uygulanması için kullanılan sözcük dağarcığı tanımlayabilirsiniz.Güvenlik ve diğer hizmet gereksinimleri kalitesi gibi her özellik pervade geniş gereksinimlerini belirleyin.

• ' E yakın veya her tekrarında başlangıcı, bu özelliklerin ayrıntılı gereksinimleri geliştirin.Kullanıcılar, etkinlik ya da sequence diyagramları yardımıyla tanımlanması adımları belirleyin.Olağanüstü durumlarda ne olacağını tanımlarsınız.

• Yazacak olan sık mümkün olduğunca tüm gereksinimlerini denetleyin.Her yeni özellik için genişletilmiş olan testler ile yayılan gereksinimleri, güvenlik gibi doğrulanması gerekir.Mümkünse, otomatik sınamalar sürekli olarak yapılması nedeniyle testler otomatikleştirin.

Gereksinimleri değişikliklerini yönetme

Aşağıdaki yönergeleri CMMI gereksinimlerini karşılamak üzere izlerken artımlı bir işlem çalışmasına olanak tanır.

• Bir yineleme için ayarlanan gereksinimleri değiştirmeyin.Taraflar durumlarda ani bir değişiklik, bir yineleme iptal, ürün planı gözden geçirmek ve yeni bir yineleme başlatmak gerekebilir.

• Gereksinimleri uncertainties arayın.Böylece erken yineleme ile kullanıcı deneyimi uncertainties azaltır bilgi üretir planı düzenlemeyi deneyin.

• Değişiklik isteği çalışma öğeleri kayıt istekleri için istenen geliştirme planının bir parçası değilse, zaten uygulanmıştır, davranışını değiştirmek için kullanın.Her değişiklik isteği uygun gereksinimi iş maddelere bağlayabilirsiniz.Daha fazla bilgi için bkz. Değişiklik isteği (CMMI).

• Her yineleme önce ürün gözden geçirdiğinizde değişiklik isteklerini gözden geçirin.Bağımlı projelerin ve kullanıcıların isteği etkisini incelemek ve kodunuzda değişiklikler ile ilgili olarak maliyet tahmini.Değişiklik isteği kabul edilirse, gereksinimi güncelleştir.

• Gereksinimleri tarafından yapılan her değişiklik için uygun sınamaları güncelleştirin.

• Hangi gereksinimleri değişiklikleri çok daha önemle bloklanmış gerekir sonra sonlandırma tarihi (örneğin, sonra yineleme 2 veya 3) belirleyin.Projenizi ödeyen bir müşteri için ise, bu müşteri gereksinimlerini temel kümesini onaylamak ve sabit fiyatlı saatlik ödeme geçiş için tarihtir.

• Açık veya örtülü gereksinimlerine göre gerçekleştirmez uygulanan kayıt davranışına hata çalışma öğelerini kullanın.Pratik nerede hata yakalandı yeni bir test oluşturun.

Vizyon ifadesi yazın

Ekip vizyonu deyimiyle tartışmak ve projenin Web portalı için görüntüleme Team Foundation Server.

Ürün ne fayda kısa bir Özet getirecek bir Vizyon açıklamadır.Hangi kullanıcıların önce yapamadı, bunu yapmak olabilir mi?Geleceğe Bakış ifadesi, ürün kapsamı açıklamak yardımcı olur.

Ürün zaten varsa, bu sürümü için bir Vizyon ifadesi yazın.Hangi ürünün kullanıcılar önce yapamadı, bunu yapmak olabilir mi?

Senaryo yazma

Senaryolar oluşturmak için müşteri ve diğer hissedarlar çalışmak ve bunları senaryoya ayarlama gereksinimi türü alanında gereksinim çalışma öğeleri girin.

Bir senaryo ya da kullanım olay sırasını açıklar, nasıl belirli bir amacı elde edilir ve genellikle kişiler veya kuruluşlar ve bilgisayarlar arasındaki etkileşimi içerir gösterir açıklamaları durumdur.

Açıkça, bir liste görüntülendiğinde ayırır açıklayıcı bir başlık verin.Asıl Aktör ya da oyuncuları belirtildiği ve bunların amacı boş olduğundan emin olun.Örneğin, bu iyi bir başlık şöyle olabilir:

Müşterinin satın aldığı bir yemek.

Bir senaryo aşağıdaki formlarda yazabilirsiniz.Bazen birden fazla form kullanmak yardımcı olabilir:

• Bir veya iki cümle iş madde açıklaması:

  Bir müşteri Web sitesinde bir yemek siparişleri ve kredi kartı ile öder.Sipariş hazırlar ve yemek sunan bir restoran için gönderilir.

• İş öğesi tanımı numaralı adımları:

  Bir müşteri Web sitesini ziyaret ederse ve bir yemek için bir sipariş oluşturur. Web sitesi, Müşteri ödeme yapmak için bir ödeme siteye yönlendirir. Sipariş restoran'ın iş listesine eklenir. Restoran hazırlar ve yemek sunuyor.

• Film şeridi.Bir film şeridi, Öykü anlatan aslında bir çizgi çubuðudur.PowerPoint'te çizebilirsiniz.Gereksinimi iş öğesi için film şeridi dosya eklemek veya takım Portalı'na dosya karşıya yükleme ve çalışma öğesi için bir köprü ekleyin.

  Bir film şeridi kullanıcı etkileşimlerini göstermek için özellikle yararlıdır.Ancak bir iş senaryosu için taslak kullanılacak önerilir kolaylaştıran stili temizleyin bunun kullanıcı arabirimi için son tasarım olmadığını.

• Gereksinim belgeler.Gereksinim belgeler her gereksinim için uygun ayrıntı düzeyini sağlamak için özgürlüğü verin.Belgeleri kullanmaya karar verirseniz, her gereksinim için bir Word belgesi oluşturun ve gereksinimi iş öğesi için belgeyi iliştirin veya takım Portalı'na dosyayı karşıya yüklemeyi ve çalışma öğesi için bir köprü ekleyin.

• Birleştirilmiş Markup Language (uml) sıra Diyagram.Çeşitli tarafların etkileşim burada sırası Diyagram özellikle yararlıdır.Örneğin, yemek siparişi, müşteri, DinnerNow Web sitesi, ödeme sistemi ve restoran belirli bir sýrada etkileşimine izin gerektirir.Bir uml modeli sıra diyagram çizmek, içine bakın Team Foundation Serverve bir bağlantı gereksinimi iş öğesini girin.Daha fazla bilgi için bkz. UML Sıralı Diyagramlar: Yönergeler.

Belirli senaryolar

Belirli bir dizi oyuncuları aracılığıyla belirli bir sıra izleyerek belirli senaryolar yazarak başlatın.Örneğin, "Carlos pizza ve garlic ekmek DinnerNow Web sitesinde siparişler.Web sitesi Carlos Woodgrove bankanın ödeme Hizmeti'ne yönlendirir.Dördüncü kahve pizza hazırlar ve bunu teslim eder."

Belirli senaryolarda sistem kullanımda envisage yardımcı olmak ve bir özelliği ilk kez geçirirken en kullanışlı olandır.

Ayrıca, arka planlar ve diğer etkinlikler kişi ve kuruluşların açıklayan adlandırılmış personas oluşturmak yararlı olabilir.Carlos kaba uykuya geçme ve Internet café kullanır; Gülşen gated topluluk içinde yaşar; Sanjay Yemekleri kendi wife kendi iş için siparişleri; Contoso 2.000 restoranlar zinciri dünya çapında çalışır; Dördüncü kahve bisiklet tarafından teslim birkaç tarafından çalıştırılır.

"Bir müşteri," "bir menü öğesi," yazılır ve benzeri daha genel senaryolar daha uygun olabilir, ancak neden yararlı özellikleri bulma olasılığı daha düşüktür.

Ayrıntı düzeyleri

Yineleme 0, birkaç önemli senaryolarda bazı ayrıntılı olarak yazmak, ancak anahatta çoğu senaryosu yazmak.Bir yineleme yaklaştığında belirli bir senaryo olması tamamen veya kısmen uygulanan daha fazla ayrıntı eklemek için olduğu.

İlk kez bir senaryo düşünün, iş bağlam içinde hiçbir bölümü ürün götüren bile yönlerini açıklamak yararlı olabilir.Örneğin, teslimat DinnerNow yöntemi tanımlar: her restoran kendi teslimatlar düzenliyor veya DinnerNow teslim hizmeti çalışıyor mu?Bu tür soruların yanıtlarını yararlı içerik geliştirme takımı sağlar.

Bir yineleme başlangıcında geliştirmek daha ayrıntılı senaryolar kullanıcı arabirimi etkileşimleri açıklayabilirsiniz ve şeritleri kullanıcı arabirimi düzenini gösterebilir.

Senaryo düzenleme

Aşağıdaki yöntemleri kullanarak senaryolar düzenleyebilirsiniz:

• Her bir senaryo olarak harf kullan Göster kullanımı büyük/küçük harf diyagramları çizin.Senaryo çok sunmak ve tartışmak kolaylaştırır, çünkü bu yöntem önerilir.Daha fazla bilgi için bkz. UML Kullanım Durumu Diyagramları: Yönergeler.

  • Bağlantıyı her senaryo tanımlayan iş öğesi için büyük/küçük harf kullanın.Daha fazla bilgi için bkz. Model Öğelerini ve İş Öğelerini Bağlama.

  • O bir senaryo başka bir türevi olduğunu göstermek için SysGroup ilişkiler çizin.Örneğin, "Müşteri ayrı ödeme ve teslimat adresleri belirtir" temel "Müşteri sipariş yapar" Harf Kullan uzantısıdır.Uzantıları sonraki tekrarda will be implemented senaryolar dışarı ayırmak özellikle yararlı olur.

  • Draw içeren ilişkiler "Müşteri, birkaç için ortak olan günlükleri"gibi bir yordam ayırmak için servis talepleri kullanın.

  • "Müşteri kartı tarafından öder."gibi "Müşteri öder" gibi genel senaryolar arasında belirli türevlerini genelleştirmesi ilişkiler çizme

• Üst-alt senaryo çalışma öğeleri arasında bağlantılar oluşturabilirsiniz Team Foundation Server. Hiyerarşi içinde görüntüleyebilirsiniz Ekip Gezgini.Daha fazla bilgi için bkz. Gereksinimleri ürün planı uygulamasına yerleştirme.

İş etki alanı modeli

Asıl faaliyetleri ve söz konusu ürünü kullanımda olan kavramları açıklayan bir uml modeli oluşturun.Bu model bir "her yerde kullanılabilen dil" olarak tanımlanan terimleri senaryolarda, tartışmalara hissedarlar ile kullanıcı arabirimi ve herhangi bir kullanıcı el kitaplarını ve kodu kullanın.

Birçok gereksinimleri açıkça müşteri tarafından bildirilen değil ve zımni gereksinimleri anlaşılması iş etki alanı, diğer bir deyişle, ürün işe yaramaz içerik bir anlayış bağlıdır.Bazı iş gereksinimleri toplama bilmediğiniz bir etki alanında olduğunu, bu nedenle, söz konusu içerik hakkında bilgi sağlamasını hakkında.Bu tür bir bilgi oluşturulduktan sonra birden fazla proje üzerinde kullanılabilir.

Sürüm denetimi modeli kaydedin.

Daha fazla bilgi için bkz. Kullanıcı Gereksinimlerini Modelleme.

Modelleme davranışlar

Senaryoları özetlemek için aktivite diyagramları çizin.Farklı oyuncular tarafından gerçekleştirilen eylemler gruplandırmak için swimlanes kullanın.Daha fazla bilgi için bkz. UML Etkinlik Diyagramları: Yönergeler.

Bir senaryo, genellikle belirli bir olay sırası tanımlar, ancak tüm olasılıkları etkinlik diyagramı gösterir.Etkinlik Diyagram çizim, alternatif sıralar hakkında düşünün ve bu gibi durumlarda yapılması gerekenleri müşterilerinize sormak için sorabilir.

Etkinlik diyagramı basit bir örneği aşağıda gösterilmiştir.

İletilerin değişim önemli olduğu lifeline her oyuncu ve ana ürün bileşeni içeren bir sıra Diyagram kullanmak daha etkili olabilir.

Use case diyagramları, ürününüzü destekler etkinliği farklı akışları özetlemek olanak tanır.Diyagramdaki her düğümde kullanıcıların belirli bir kullanıcının amacı in pursuit of uygulaması arasındaki etkileşimler bir dizi temsil eder.Size de ortak sıraları ve isteğe bağlı uzantıları ayrı use case düğümü çarpan.Daha fazla bilgi için bkz. UML Kullanım Durumu Diyagramları: Yönergeler.

Use case diyagramı basit bir örneği aşağıda gösterilmiştir.

Modelleme kavramları

Önemli varlıkları ve senaryolarda anlatılan ilişkilerini açıklamak için etki alanı sınıf diyagramları çizin.Örneğin, DinnerNow modeli, lokanta, menü, sipariş, menü öğesi vb. gösterir.Daha fazla bilgi için bkz. UML Sınıf Diyagramları: Yönergeler.

Etiket adları ve cardinalities ile ilişki rollerini (sonu).

Bir etki alanı sýnýf diyagramý, genellikle işlem sınıfları eklemeyin.Etki alanı modeli, aktivite diyagramları davranışını açıklar.Program sınıfları sorumluluklarını atama geliştirme çalışmaları parçasıdır.

Bir sýnýf diyagramý basit bir örneği aşağıda gösterilmiştir.

Statik kısıtlamaları

Sınıf diyagramları öznitelikleri ve ilişkileri yöneten kısıtlamaları ekleyin.Örneğin, bir siparişteki maddelere tümü aynı restoran gelmelidir.Bu kural türleri, ürün tasarımı için önemlidir.

Model tutarlılık

Model ve senaryoları tutarlı olduğundan emin olun.Bir model için en güçlü kullanımları ambiguities çözmek için biridir.

• Senaryo açıklamaları modelinde tanımlı ve onu tanımlayan ilişkileri ile tutarlı olan koşulları'nı kullanın.Modeli menü öğelerini tanımlar, senaryolar ürünleri ile aynı şey bakın değil.Sýnýf diyagramý menü öğesi için tam olarak bir menü ait olduğunu gösteriyorsa, senaryolar menüler arasında öğe paylaşma görüşmelisiniz değil.

• Her senaryo, bir dizi etkinlik diyagramları tarafından izin verilen adımları açıklar.

• Senaryolar veya etkinlikleri nasıl her sınıf ve sınıf diyagramında ilişki oluşturulan bozdu ve açıklayın.Örneğin, hangi senaryoyu bir menü öğesi oluşturur?Ne zaman sipariş edilir?

Kalite hizmet gereksinimlerini geliştir

Hizmet gereksinimleri kalitesini belirleyen çalışma öğeleri oluşturun.Hizmet kalitesi için gereksinim türü alanını ayarlayın.

Kaliteli hizmet veya işlevsel olmayan gereksinimler ve son performans, kullanılabilirlik, güvenilirlik, kullanılabilirlik, veri bütünlüğü, güvenlik, uygun maliyet, Bakım kolaylığı ve yükseltilebilme, e-posta erişimini, bakýmýný, tasarım ve uyum içerir.

Her senaryo için bu kategorilerin her birinde göz önünde bulundurun.

Her servis gereksinimi kalitesi başlığı tanımına bir içerik, eylem ve ölçüm sunularak yakalamak zorundasýnýz.Örneğin, aşağıdaki gereksinimin oluşturabilirsiniz: "katalog arama sırasında üç saniyeden daha kısa bir süre içinde arama sonuçları iade ediniz."

Buna ek olarak, ihtiyaç neden gerekli olduğunu açıklayan ayrıntılı yakalamak yararlıdır.Persona gereksinimi değer neden ve bu hizmet düzeyini neden gerekli olduğunu açıklayın.İçerik ve bloklama sağlar.Bu açıklama, Pazar Araştırması, müşteri odak grup veya kullanılabilirlik çalışmasını verileri gibi yararlı risk yönetimi bilgileri içerebilir. Yardım Masası raporları/biletleri; ya da diğer anecdotal kanıtlar.

Hizmet Kalitesi tarafından etkilenen herhangi bir senaryo (gereksinimi iş öğesi) hizmeti gereksinimi kalitesi bağlayın.Bağlama ilgili çalışma öğeleri verir kullanıcıları Team Foundation Server bağımlı gereksinimleri takip etmek.Sorgular ve raporlar nasıl hizmet gereksinimleri kalitesini etkiler senaryolar yakalanan levsel gereksinimler gösterebilirsiniz.

Gereksinimlerini gözden geçir

Gereksinimleri yazılan veya güncelleştirilen sahip olduğunda, bunlar yeterli biçimde birleştirilebilmesi ürünüyle tüm kullanıcı etkileşimlerini tanımladıkları emin olmak için uygun proje hissedarları tarafından incelenmesi gerekir.Ortak hissedarlar uzman bir konuya, iş analisti ve kullanıcı deneyimi Mimarı içerebilir.Senaryolar da bunlar proje karışıklığı ya da sorunları olmadan uygulanabilir olmasını sağlamak için incelenebilir.Herhangi bir sorun anlaþýlmaz, bu etkinlik sonuç geçerli olacak şekilde senaryoları gidermelisiniz.

Gözden geçirme izlemek için bir İnceleme iş öğesi oluşturun.Bu öğe için bir standart CMMI değerlendirme süreci geliştirme (SCAMPI) değerlendirme için önemli kanıt sağlar ve iyi bilgi kaynağı olarak neden çözümlemesi için gelecekte sağlayabilir.

Her senaryo için aşağıdaki özellikleri gözden geçirin:

• Senaryo kapsamında görev kullanıcıları gerçekleştirmeniz gerekir, ne zaten bildikleri ve ürünle birlikte etkileşim bekledikleri nasıl yazılır.

• Senaryo bir sorun açıklanır ve sorunu için önerilen çözümleri tarafından getirilmemeli değil.

• Tüm ilgili kullanıcı etkileşimlerini ürün ile tanımlanır.

• Konuya uzman, iş analisti ve kullanıcı deneyimi Mimarı tüm senaryoları başarıyla uygulanabilir doğrulamak için proje kapsamında her senaryoyu gözden geçirin.Bir senaryo geçerli değilse, geçerli olmasını sağlayacak şekilde düzenlendi.

• Senaryo kullanılabilir teknikleri, araçları ve kaynakları ve bütçe ve zamanlama içinde uygulanabilir.

• Senaryo kolay anlaşılan bir tek yorumu vardır.

• Senaryo başka bir senaryo ile çakışmıyor.

• Senaryo sınanabilir.

Doğrulama

Onun son serbest bırakmadan önce kendi çalışma ortamına ürünün beta sürümlerini dağıtmak planlayın.Bu dağıtım Girişimcinin görüşlerine dayalı gereksinimlerini güncelleştirmek planlayın.

Doğrulama, ürünün kullanım amacı, çalışma ortamında karşılayan sağlama anlamına gelir.CMMI için msf hissedarlara proje boyunca her yinelemenin sonunda çalışma yazılım açıklarken doğrulama gerçekleştirilir.Zamanlamayı erken gösteriler geliştiriciler için arkadan kalan yineleme için plan çözüldüğünü verildiğinde ilgili böyle bir şekilde yerleştirilmiştir.

Gerçek doğrulama elde etmek için ürün yalnızca bir örnek çalıştırılmalıdır değil veya bağlam simülasyonu.Kadar gerçek koşullarda test edileceği gibi practicable olur.

İnceleme ve düzenleme gereksinimleri

Senaryo ve kalite geliştirme görevlerin çoğu müşteri adayı, hizmet gereksinimlerinin müşteri gereksinimlerini sorgusu kullanarak kontrol edilebilir.Tüm gereksinimlerini görüntülemek isterseniz, tüm çalışma öğeleri gereksinimi iş öğesi türü döndüren bir sorgu yazabilirsiniz.Yinelemenin yolunu göstermek için sonuç sütunları kümesi.Daha fazla bilgi için bkz. Paylaşılan sorgular (CMMI).

Doğrudan sorgu görüntüleme yanı sıra Ekip Gezgini veya Ekip Web Erişimi, içinde açık Office Excel veya Office Project.Bu toplu iş olarak çalışma öğelerini ekleme ve düzenleme için daha uygun araçlardır.Daha fazla bilgi için, bkz. Team Foundation Server'a Bağlı Microsoft Excel ve Microsoft Project ile Çalışma ve (Excel'deki) İş Öğelerinin Ağaç Listesini Kullanarak Tepe-Aşağı Planlama Yapmak.

Ekibiniz project erken yinelemede çoğu gereksinimleri oluşturmanız gerekir.Yeni gereksinimleri eklenir ve önceki sürümlerden görüş kazanılan gibi diğerleri ayarladı.

Ek Kaynaklar

Daha fazla bilgi için aşağıdaki Web kaynaklarına bakın:

• Feature Driven Development için pratik bir kılavuz, Stephen r.PALMER ve Malcolm j.Felsing; Prentice-Hall ptr, 2002.

• Kolaylaştırılmış Object Model: Desenler, kuralları ve uygulama, Jill Nicola, işareti Mayfield ve Mike Abney; Prentice Hall ptr, 2001.

• Hızlı modelleme: Scott Ambler birleştirilmiş işlem ve Extreme programlama için etkili yöntemler; Wiley, 2002.

• Tasarım üzerine kurulmuş olan etki alanı: Kalp yazılımların karmaşıklığı Tackling, Eric Evans; Addison Wesley Professional 2003.

• Nesne tasarımı: Roller, Sorumluluklar ve Rebecca Wirfs-Brock ve Alan McKean Collaborations; Addison Wesley Professional 2002.