Bu sürecin sonucunda, ürün gereksinimlerini sağlayan alternatifler değerlendirilir ve çözüme karar verilir. Bu sürecin sonucunda:

• Mimari tasarım için dayanak noktası oluşturulur.
• Tasarım modelleri oluşturulur.
• Gereksinimler, mimari ve tasarım arasında izlenebilirlik oluşturulur.
• Teknik riskler tanımlanır, gerekirse proje yönetim planı güncellenir.
• Arayüz gereksinimlerini sağlayan tasarım modelleri oluşturulur.
• Entegrasyon için genel kriterler belirlenir.
• Tasarım doğrulama kriterleri oluşturulur.
• Çözümün mantıksal, fiziksel ve veri yapısı oluşturulur

Sürecin başarılı uygulanması sonucunda, gereksinimleri karşılayan tasarım birimleri oluşturulmuş, değişikliklerin kolayca tasarıma yansıtılabildiği, test sonucunda tasarıma bağlı hataların sürecin önceki sürümlerine göre azaldığı bir sonuç alınır.

GTD: Gereksinim Tanımları Dokümanı

YTT: Yazılım Tasarım Tanımları

FVM: Fiziksel Veri Modeli

MTM: Mantıksal Tasarım Modeli

MVM: Mantıksal Veri Modeli

ATD: Arayüz Tanımları Dokümanı

TDD: Test Durumları Dokümanı

TP: Test Planı

• ISO 9000:2008
• TS ISO/IEC 15504-1
• TS ISO/IEC 15504-2
• TS ISO/IEC 15504-3
• TS ISO/IEC 15504-4
• TS ISO/IEC 15504-5
• TS ISO/IEC 15504-6
• TS ISO/IEC 15504-7
• CMMI v1.2

Bu süreç, şartnamenin kabulüyle başlar ve sonrasında yazlım gereksinimlerinin oluşturulmasıyla iş yoğunluğu artar. Kodlama aşamasında ve değişiklik istekleriyle tasarım değişikliğine sebep olan istekler oluşuyorsa tasarım güncellenir. Süreç projelerde aynen kullanılabilir veya kalite güvence uzmanının onayı alınarak, Proje Yönetim Planı ile proje gerekliliklerine göre uyarlanabilir. Bu durumda Proje Yönetim Planı değiştirilecek/uygulanmayacak maddeleri tam olarak tarif etmelidir

• İzlenebilirlik ilişkisi, proje yönetim ya da ilgili planlara göre projeye spesifik araçlarda sağlanabilir.
• Tasarım değişiklikleri değerlendirme toplantıları, yüz yüze olabileceği gibi, iş akışına sahip bir otomasyon sisteminde ya da toplantı tutanağının paydaşlara onaylatılması şeklinde de gerçekleşebilir.
• FRM.07 Problem Kayıt formu tüm problem tipleri için oluşturulmuştur. Projeler bu formda uyarlamaya gidebilirler. Bu kalite güvence uzmanı tarafından Şirket ‘in uymakta olduğu standartlara göre (SPICE, ISO 9000 vs) gözden geçirilir. Standart beklentilerini sağlıyorsa onaylanır. Problem kayıt formu kullanılan iş akışı sistemleriyle otomasyona geçirilebilir. Bu durumda otomasyonun kısıtlarıyla form şablonu değerlendirilmelidir.

Tasarım Uzmanı: Mimarinin oluşturulmasından ve ana tasarım bileşenlerinin belirlenmesinden sorumludur. Tasarım risklerini tanımlamak ve kaçınma planlarının hazırlanmasına katkı sağlamaktan sorumludur.

Sistem Analisti: Gereksinimlerin analiz edilmesinden ve çıktının tasarım ekibine ulaştırılmasından sorumludur.

Proje Yöneticisi: Tasarım sürecini planlamaktan ve ilgili süreçlerle koordinasyonu sağlamaktan sorumludur. Tasarıma bağlı risklerin yönetilmesinden sorumludur.

Test Uzmanı: Tasarım değişikliklerinin etkilerine göre test durumlarını güncellemekten sorumludur.

Konfigürasyon Yöneticisi: İhtiyaçlardan, tasarıma ve tasarımdan koda ve ilgili konfigürasyon öğelerine izlenebilirliği ve tutarlılığı sağlamaktan sorumludur. Tasarım çıktılarının sürüm kontrolünden ve temellerin yönetiminden sorumludur.

Kalite Güvence Uzmanı: Sürecin doğru işletildiğini kontrol etmek ve süre destek vermekten sorumludur. İş ürünlerini gözden geçirir.

Proje Ekibi: Tasarım doğrulama aktivitelerine katılmak ve tasarım çalışmalarına katkıda bulunmaktan sorumludur.

Müşteri: Tasarımın gözden geçirme aktivitelerine katılmak ve geri bildirim yapmaktan sorumludur.

• Gereksinim Yönetimi Süreci (HIZ.MUH.01)
• Problem Yönetim Süreci ( HIZ.DES.06)
• Konfigürasyon Yönetim Süreci (HIZ.YON.02)
• Gerçekleştirim Süreci (HIZ.MUH.03)

• Gerçekleştirim Süreci (HIZ.MUH.03)
• Gereksinim Yönetimi Süreci(HIZ.MUH.01)
• Konfigürasyon Yönetimi Süreci (HIZ.YON.02)
• Risk Yönetimi Süreci(HIZ.YON.03)
• Test Süreci (HIZ.MUH.05)
• Problem Yönetim Süreci ( HIZ.DES.06)
• Entegrasyon Süreci(HIZ.MUH.04)

• Gereksinim Tanımları Dokümanı(RPR-004-GTD)
• Konfigürasyon Yönetim Planı (RPR-015-KYP)
• Sürüm Yönetim Planı (RPR-022-SYP)
• Değişiklik İstekleri
• Şartname
• Teknik Kısıtlar
• Gözden Geçirme ve Test Sonuçları
• Teknoloji ve Programlama Dili
• İzlenebilirlik

Bu aşamada proje yöneticisi, tasarımın diğer süreçlerle ilişkisini, roller ve sorumlulukları, zaman planını, onay ve gözden geçirme süreçlerini seçilen proje yaşam döngüsüne uygun olarak tanımlar. Bu aşamada tasarım için kullanılacak araçlar, modeller, standartlar, yöntemler oluşturulur.

Bu aşamada gereksinimleri karşılayan farklı mimari tasarım seçenekleri belirlenir. Alternatifler kıyaslama yapılarak elenir ve son model üzerinde karar verilir. Alternatifler değerlendirilirken esneklik, güvenilirlik, güvenlik, test edilebilirlik ve bakım kolaylığı, performans gibi kalite kriterleri kullanılır. Bu aşamada tasarım bileşenleri, bileşenler arasındaki arayüzler, dış sistemlerle geliştirilecek sistem arasındaki arayüzlere, satın alınacak hazır ürünler ya da alt yüklenici tarafından geliştirilecek bileşenlere karar verilir. Tasarım kısıtları ortaya çıkar. Oluşturulan tasarım bileşenleriyle ilgili gereksinimler eşleştirilir. Mimari oluşturulurken kabul gören patternlerden ve tasarım standartlarından yararlanılır. Mimari tasarım çalışmaları sırasında alınan kararlar toplantı tutanaklarıyla kayıt altına alınır. Eğer işlemler mail, elektronik ortamda yapıldıysa mailler konfigürasyon yöneticisi sorumluluğunda kayıt altına alınır.

Sistem mimarisi oluşturuldukça geliştirilecek yazılımın ara yüzleri ve birbirleriyle etkileşimleri, nasıl bir iletişim mekanizması ve bilgi ihtiyacına sahip olacakları ortaya çıkar. Ara yüz tasarımı sistemin diğer sistemlerle (donanım, yazılım, işletim sistemi, network, iletişim yapısı) ve kullanıcıyla olan ara yüzlerini, entegrasyon ihtiyaçlarını, sistemin iç bileşenlerinin birbirleriyle ilişkisini, bağımlılıklarını, mesajlaşma ihtiyaçlarını ve kısıtlarını kapsayacak şekilde yapılır. Ara yüz tasarımı yazılım tasarım tanımları dokümanıyla yazılı hale getirilir. Ara yüz kontrolü konfigürasyon yönetim süreciyle sağlanır. Konfigürasyon yönetim planında kontrollerin mekanizması açıklanır. Dolayısıyla tasarım ve konfigürasyon yönetim süreçleri koordineli yürütülmelidir.

Belirlenen tasarım bileşenleri, sistem mimarisine uygun olarak tasarlanır. Tasarım birimleri arasındaki ilişkiler, iletişim yapısı, mesajlaşmalar, sistemin veri yapısı, statik ve dinamik modelleri oluşturulur. Tasarım modeli oluşturulurken gereksinim analizi aşamasında oluşturulan kullanım senaryolarından faydalanılır. Tasarım modeli oluştururken sınıf, sıralama, durum diyagramlarından UML ya da farklı notasyonlardan yararlanılır. Kullanılacak modelleme dili ve standardı tasarım aşamasından önce teknik süreç planında belirtilmelidir.

• Mimari model
• Statik model
• Dinamik model
• Veri modeli gibi modeller bulunur.

Yazılım projelerinde gereksinimler proje sonuna kadar değişmeye (ekleme, çıkarma, değiştirme) devam eder. Bu nedenle tasarımın mümkün olduğunca esnek yapılması gerekir. Gelen değişikliklerin ve yeni gereksinimlerin gerçekleştirilmesi için öncelikle sistem mimarisiyle uyumları ve sebep olacakları teknik riskler gözden geçirilir. Tasarımda güncelleme gerektiriyorsa tasarım modeli güncellenir. Etki analizi detayları konfigürasyon yönetim sürecinde anlatılmıştır. Tasarım tanımları dokümanı sadece kodlama ve üretim aşaması için değil, müşterinin sistemi sonradan genişletebilmesine, değişiklik yapabilmesine, sorunların kaynağını tespit edebilmesine olanak verecek şekilde detaylı hazırlanır.

Tasarım modeli gözden geçirme kriterlerine göre proje ekibi ya da bağımsız bir tasarım uzmanı tarafından gözden geçirilir. Bu aşamada gereksinimlerin tasarım modeliyle doğru ve kaliteli bir şekilde karşılandığı kontrol edilir. Tasarımın,

• Modüler
• Test edilebilir
• Bakımı kolay
• Basit
• Güvenilir
• Performans sorunu olmayan
• Güvenlik açığı olmayan bir tasarım olması beklenir.

Tüm gereksinimlerin tasarımla karşılandığı ve tasarımın mimari gereksinimleri sağladığının doğrulanması müşterinin gözden geçirmesi ve Tasarım Tanımlarını onaylamasıyla gerçekleşir. Şartnamede bu şart koşulmamışsa kabul testleriyle de tasarım doğrulanmış olur. Bu aşama problem yönetim sürecinde belirtildiği şekilde kayıt altına alınır.

Gereksinim yönetimi süreci çıktılarıyla oluşturulan test durumları tasarım süreci çıktılarıyla güncellenir. Mimari tasarım sonucunda ortaya çıkan performans, güvenlik, güvenilirlik ve diğer mimari koşullar için test durumları oluşturulabilir. Tasarım, birim ya da yapısal testlerin oluşturulmasıyla geçerlenir.

Tasarım birimleriyle ilgili oldukları gereksinimler ilişkilendirilir. Gereksinimlerin tutarlı bir şekilde planlanan gereksinimlerin tasarımının tamamlandığı sağlanmış olur. İzlenebilirlik için FRM.01 Gereksinimlerin izlenebilirliği matrisi formu kullanılır. Projeler bu formu uyarlayabilirler. Kodlama aşamasına geçildiğinde tasarımla kodlama birimleri arasında da izlenebilirlik kurulur. İzlenebilirlik matrislerinden değişikliklerin etki analizi aşamasında, bağımsızlık ve kapsam kontrolü sırasında proje taraflarına yarar sağlar. İzlenebilirlik ve aradaki ilişkilerin güncel olmasını konfigürasyon yöneticisi kontrol eder.

• Yazılım Tasarım Tanımları (RPR-030-YTT)
• Yapısal testler
• Test Durumları (RPR-024-TDD)
• Test Planı (RPR-025-TP)
• Hazır ve Yeniden Kullanılabilir Ürünler
• Toplantı Tutanakları(FRM.02)
• Problem Kaydı Formu(FRM.07)
• Gereksinimlerin İzlenebilirliği Formu(FRM.01)

• Tasarım Uzmanının başta ve diğer proje ekip üyelerinin
• Yazılım Yaşam Döngüsü
• Tasarım ve diğer mühendislik süreçleri
• UML
• Tasarım Patternleri
• Mimari Patternler
• İlgili Programlama Dili
• Kullanılacak Araçlar ve Teknoloji
• Nesneye Yönelik Programlama ya da kullanılan metodolojiyle ilgili bilgilerinin olması ve eğitim almış olmaları beklenir.

Tasarım için Visio, MSVSTS, Eclipse Modeling Framework ya da diğer araçlardan faydalanılabilir. Proje yöneticisi tasarım süreci için kullanılacak araçları planlama aşamasında ya da analiz sonrasında belirler.

Projede aksi belirtilmedikçe kayıtların hepsi konfigürasyon yönetimi altında kontrol edilir ve proje sitesinde saklanır. Bu sistemlerle tüm çıktılar sürüm yönetimine tabidir, gelen değişiklikler izlenebilir. Bunun haricinde eğer projede farklı bir CASE aracı kullanılıyorsa proje yöneticisi proje yönetim planında kullanılacak aracı ve sürüm yönetim mekanizmasını belirtir.

Tasarım sürecinin kontrolü projelere yapılan iç denetimlerle yapılır. Ortaya çıkan düzeltici ve önleyici faaliyet istekleri incelenerek süreç performansı değerlendirilir. Eğer düzeltici faaliyetlerin oranı yapılan denetimlere ve soru sayılarına göre yüksekse projede süreç uygulanmıyor olabilir. Bu durumda projede gereksinim yönetim performansını değerlendirmek mümkün olmaz. Bu durumda sürecin neden uygulanmadığı araştırılır. Düzeltici faaliyetler az ve süreç uygulanıyorsa, bu durumda veri toplanarak sürecin performansı değerlendirilir. Süreç etkin uygulandığı durumda, gelen değişiklik isteklerinin mimari ve ana tasarım üzerinde maliyeti az ve testten tasarımla ilgili dönen hata az olur. Bu azlık, çokluk değerleri proje aşamalarında ya da geçmiş projelere bakılarak ya da projenin şartnamesine ve proje ekibinin kararına göre proje planlama aşamasında belirlenir ve ölçüm planına yansıtılır. Süreç performansı, veriler yıllık olarak tüm süreçlerden alınarak kalite grubu tarafından değerlendirilir ve kalite yönetim sistemi performans raporuna yansıtılır. Bu raporda süreçlerle ilgili iyileştirme önerileri sunulur. Yönetim kurulu, proje yöneticileri, kalite ekibi iyileştirme önerileri için önceliklendirme yapıp plan hazırlarlar. Öncelik verilen süreçler veya hedefler için süreç iyileştirme çalışması başlatılır ve takip edilir. Bu çalışmanın sonunda değerlendirme yapmak için sağlıklı veri bulunmadığı yorumu da çıkabilir. O zaman verilerin doğru değerlendirilebilmesi için metrik toplamaya devam edilmesine ve sürecin izlenmesine karar verilir.