TASARIM

Anasayfa Süreçler Tasarım
Pazar Araştırması İş Analizi Tasarım Yazılım Mühendisliği Kalite Kontrol Test





Piyasa Araştırması yapıldıktan sonra, müşterinin ihtiyaçlarını imkan dahilinde karşılayacak uygun maliyetli sistemi kavramsallaştırmak için müşterinin ihtiyaçları Araştırma & Geliştirme bölümüne (R&D) verilir.Kavramsal sistem geliştirildiğinde ve hipotetik ortamda test edildiğinde, geliştirme takımı kontrolü ele alır.Geliştirme takımı yazılım geliştirme metodolojilerinden birini benimser ve önerilen sistemi geliştirir ve de bunu müşteriye verir.

Risk azaltmanın en etkili yöntemi geliştirme sırasında test etmeye erken başlamaktır ve her aşamada tekrarlayarak test etmektir.Bu yaklaşım ile özellikler tamamlandıkça kusurlar kaldırılır.Uygulamanın test edilmesi son özelliklerin kodlanmasından kısa bir süre sonra tamamlanır ve sonuç olarak ürün piyasaya sürülmeden önce hazır olur.Ek Olarak, hangi özelliklerin tamamlandığının bilgisi ( örneğin hem kodlanması hem de test edilmesi) yönetime, tüm süreç üzerinde daha büyük kontrol verir ve iş stratejisinin etkin işletmesini yükseltir.

Yazılım geliştirme ve bakım ihtiyaçlarının maliyetinin yüksekliği, bir tasarımın iyi olup olmadığını en baştan belirleme ihtiyacı doğurur.Ayrıca, birçok organizasyon olası kalite sunumunu ve gerekebilecek bakım çabasını tahmin etmek için yazılımdaki kusur sayılarını uygulanmadan önce öngörmek isteyebilirler.Yazılım dizayn matriksleri bunu yapabilir.

Günümüzde güvenilebilir yazılım tasarım yoksunluğundan dolayı, yazılım mühendisleri belirli tasarımı seçmekte zorlanıyorlar.Belirli bir yazılım problemi ya da belirli özellik için birçok olası tasarımlar olabilir.Yazılım tasarımı, tasarımcının yargısına dayanan, beceri isteyen bir karar verme sürecidir.Modüllerin sayıları, bu modüller arasındaki etkileşim, veri yapılarının organizasyonu, vs gibi birçok yazılım tasarım kararı tasarımcının yargısına bağlı, zor kararlardır.

Dizayn matriksleri, belirli bir metodu kullanmanın ya da birçok olası tasarım metodolojilerinin karşılaştırmalı araştırmasının yararlarını ölçebilmelidir ve yazılım mühendisine ihtiyaç önceliklerine uygun olarak bunlar arasından en iyisini seçmeyi sağlayabilmelidir.

Yazılım tasarımının basit olması için, bileşenlerin bağımsız olması ve yoğun ölçülerde etkileşime sahip olmaması gerekmektedir.Bağlaşım-bağımsızlığın ve bağlılığın bir ölçüsü olması-, bir modülün işlevinin tekliliği- tasarım ölçevlerinde kullanılabilen iki kriteridir.Bağlaşım, yazılım kalitesinde çok büyük etkisi olan yazılımın niteliklerinden biridir ve bağlaşımın ölçüsünü belirlemek için birçok metod vardır; bunlar yazılım tasarımının sübjektif (subjective) ölçümleridir.Ayrıca, bu kriterleri daha büyük tasarımlar için kullanmak yersiz olur.

Yazılım Dizayn matrikslerinin hedefi aşağıdaki konuları yerine getirebilmektir:
  • Tasarımlanan yazılımdaki kusur derecelerinin olası tahminleri.
  • Belirli bir yazılımın, gerekebilecek bakım kolaylığının derecesinin tasarım aşamasından beri görülmesi
  • Yazılım modülünün halen işe yarar olduğuna karar vermek üzere, gerçekleştirilmesi gereken testin haricinde ihtiyaç duyulan uygulamanın zorluk derecesi nedir?
  • Belirli bir tasarıma dayanan yazılım geliştirmede, modüldeki kusur sayıları gibi ölçülebilir özellikler ne kadardır
  • Tasarım özelliklerine dayanan yazılım modülünü test etmek için gereken gayret ne kadardır?
  • Tasarıma dayanan yazılımın son ölçüsünü tasarım öngörüyor mu?
  • Ayrıca bazı aykırılıkların belirlenmesinin temelinde matriks kullanma ve tasarımda olan problemleri belirleme

Tasarım yapılarına dayanan tasarım ölçevlerinin işlevi,belirli bir tasarımın uygulama aşamasında problemlere yol açabilecek tasarım zayıflığını belirlememize izin vermelidir.Ayrıca, sonunda bu tasarımın temelinde geliştirilmiş yazılımın bakım kolaylığındaki problemleri tahmin etmede kolaylık sağlamalıdır.Fakat tasarım yapı ölçevleri, bir yazılım tasarımındaki modüllerinin ölçülerini göz önünde blundurmayacaktır.

Henry ve Kafura’nın bilgi akış ölçevi, sisteminin karmaşık yapısını yakalamaya çalışır ve tasarım yapma süreci için belirli nicel esas sağlar.Fakat,bu ölçev bir yazılımın bakım kolaylığı ve kusur eğilimi derecesini doğru tahmin etmede yardımcı olmaz.Bir bileşenin uzunluğunu kendisi tasarım aşamasındayken kullanmak, tasarımcı bunu belirleyemiyebileceği için zordur.Ayrıca,bu ölçevlerde eğer faktörlerden biri örneğin giriş yelpazesi ya da çıkış yelpazesi eksikse, o zaman karmaşıklığın kendisi sıfıra düşürülür.Bu ölçev kullanışsızlığını oluşturur.

Yazılım kalitesinin esas tanımı, belirlenmiş nitelik derecesindeki önceden belirlenmiş işlevsel ihtiyaçları karşılaması gerektiğidir.Onaylanmış olabilecek yazılıma karşı birçok sayıda nitelik faktörleri vardır.Bir tasarımın modülerliği kalite yazılımı için önemli bir kriterdir ve en iyi modüller yapısını tahmin edecek ölçevler gereklidir.

Bilgi akış ölçevine göre, yapısal karmaşıklığı belirlemedeki temel faktör, bir modülün çevresine bağlanmışlık derecesidir.Tasarım aşamasında bileşenler arasındaki bilgi akış seviyesini kullanarak yazılım hakkımda tahminlerde bulunmak zordur.Aykırı değer analizini kullanmak tasarımdakiolası problemleri tahmin etmede iyi bir yöntem gibi gözükebilir.Ama burada bile, aykırı değer olarak belirtilmeleri sonucunda anormal derecede etkileşim ihtiyacı olan modüller olabilir.

 

Yazılım tasarımı, yazılım mühendisinin bir tasarımının üzerine bir diğerini seçmek için kullanacağı yinelemeli bir süreçtir.Bu yüzden ölçevler farklı tasarım çözümleri arasında karşılaştırmalar yapmanın temelinde, aykırı değer modüllerini belirlemede kullanılabilir ve böylece yazılım mühendisinin daha iyi ve etkin tasarımlarla gelmesine yardımcı olur.


Digg! Del.icio.us! Facebook! Technorati! StumbleUpon!
 
Golden Spider 2004 Golden Spider 2006 Eulda 2007 Horizon 2008
Copyright © 2010, Rhxo Teknoloji Grubu | Rhxo bir Altınova Bilişim ve İletişim Teknolojileri kuruluşudur.
Anasayfa | Kurumsal | Süreçler | Sektörel | Teknolojiler | Hizmetler | Çözümler | Ürünler | İletişim