Yazılım Tasarım Belgeleri Yazmak Neden Önemlidir?

Tebrikler, yetkin bir bağımsız geliştiricisiniz. Mütevazı başlangıçlarınızdan, belki de bir testçi olarak çalışarak, bir ekip geliştiricisine, ardından kıdemli bir geliştiriciye geçtiniz ve şimdi, doğrudan müşterilerle çalışmak için hepsinden en büyüğü olan başka bir sıçrama yaptınız.

Ancak diğer geçişlerin lineer olduğu yerde, bu sonuncusu üsteldi. Geçmişte, müşterilerle çalışan veya kendisi yazılım işinde olan bir işverenden yürüyüş siparişlerinizi alırken, bir zamanlar uzman testi, program yönetimi vb. arasında dağıtılan tüm sorumluluklar artık size ait. Ve şimdi yazılım işinde olmayan müşterilerle çalışıyorsunuz; bir yazılıma ihtiyaç duyan başka bir işteler ve sizden ne istediklerine dair net ve kesin bir vizyona sahip değiller. Bu göründüğünden çok daha büyük bir meydan okumadır.

*Not:* Burada, geliştiricilerinden tek kişilik bir ordu isteyen daha küçük müşterileri açıklıyorum. Bu, bir serbest çalışanın gidebileceği tek yol değil ve Toptal'da birlikte çalıştığımız tek müşteriler bunlar değil, ama benim en çok keyif aldığım yol bu. Tabii ki, tek başınıza değil de bir ekip içinde çalışıyorsanız, aşağıdakilerden bazıları geçerli olmayacaktır. Örneğin, Çevik metodolojiler veya Scrum kullanıyorsanız, muhtemelen kilometre taşlarınızı biraz farklı bir şekilde yapılandırmak isteyeceksiniz.

Hepiniz iletişimin üstün önemini duydunuz. Skype üzerinden birkaç cümlelik kısa ve öz açıklama alıp “İşim bitince üç ay sonra görüşürüz” diyerek çalışamazsınız. Müşterinizle iletişim halinde olmalısınız ve çalışmanızın her aşamasında, hedef hakkında uyumlu fikirlere sahip olduğunuzdan emin olmalısınız, çünkü bir müşterinin size tel çerçeveler ve ayrıntılı bir işlevsel özellik göndermesi gerçekten nadirdir. Yazılımın ne yapması, neye benzemesi ve akması gerektiği konusunda çok genel bir fikir edineceksiniz. Genellikle başladığınız üstünkörü açıklamaya dayalı bir uygulama yazarsanız, müşterinizin sonuçtan memnun olma şansı neredeyse yoktur. Her aşamada, anlaşmaya yaklaşmak için yolunuzu yinelemelisiniz.

Ekipteki herkesin aynı kültürden olduğu, aynı ana dili konuştuğu, aynı koridorda çalıştığı, her gün buluştuğu vb. yazılım işiyle uğraşan şirketlerde yıllarca çalıştıktan sonra dikkat çekiciydi. şirket hala istediğini alamadı. Hata yapmayın: Buradaki zorluk çok büyük.

Yazılım Tasarım Belgeleri Neden Önemlidir?

Bu nedenle, yeni bir projeye başladığınızda, Xcode veya Visual Studio'yu açmadan önce, net ve üzerinde anlaşmaya varılmış tasarım hedeflerine sahip olmanız gerekir . Ve bu hedefler bir şartname belgesinde oluşturulmalıdır. Müşteri bir tane yazmadıysa, onu yazmalı ve IDE'nizi açmadan önce incelemesi için onlara göndermelisiniz. Ve samimi bir şekilde “Tasarım belgeleri için zamanımız yok” diyen bir müşteriyle karşılaşırsanız, projeden uzaklaşmalısınız çünkü önünüzde sıkıntı var. Spesifikasyonun özellikle uzun olması gerekmez; sadece birkaç sayfa olabilir, ancak en azından kullanıcı arayüzünü düzenlemeli, tel çerçeveler içermeli (bir kullanıcı arayüzü bileşeni varsa) ve tamamlama kilometre taşlarını belirlemelidir.

Bu belge olmadan , müvekkillerin size söylediklerini veya onlara söylediklerinizi tartıştığı, öfkeyle önceki iletişimlerin kes-yapıştırlarını gönderen, müşterinin talep ettiği zaman gelene kadar yorumlayan ve tartışan sert bir kaçamaklar döngüsüne gireceksiniz. uygulamayı "gerçekten istedikleri" ile uyumlu hale getirmek için değişiklikler yaptığınızı ve bu değişiklikleri ücretsiz olarak yapmanızı beklediğini.

Bu yazılım tasarım belgesi ile, bu tür herhangi bir kelime oyununa bir yanıtınız olacak: anlaşmazlıklar ortaya çıktığında, müşterinin kabul ettiği ve imzaladığı spesifikasyona başvurabilir ve bunu harfi harfine yerine getirdiğinizi belirtebilirsiniz. Öfkeli tartışmalar yerine belgede değişiklikler ve açıklamalar yapacaksınız. Herhangi bir şey olursa, müşteri ilk etapta belirsizliğin kaybolmasına izin verdiği için özür dileyecektir.

Hepimiz memnun müşteriler isteriz. Hepimiz dostça bir çalışma ilişkisi istiyoruz. Ve hepimiz iyi yapılmış bir işin gururunu istiyoruz. Ancak işin gerçekte ne olduğu konusunda herhangi bir belirsizlik varsa bunlar elde edilemez. Müşteriniz bir tasarım belgesinin çok fazla ekstra iş olduğunu söylüyorsa, onlara bir tür yanlış anlaşılma nedeniyle revizyon yapılması gerektiğinde asıl ekstra işin ortaya çıkacağını açıklamak sizin görevinizdir. Müşteri hala böyle bir belge olmadan ilerlemenizde ısrar ederse, yürütülemez bir ilişkiniz olduğu gerçeğini kabul etmeli ve çekip gitmelisiniz.

Yazılım Tasarım Spesifikasyonu Gerçekte Neleri Belirtmelidir?

En azından istenen uygulamanın, tamamlama kriterlerinin ve kilometre taşlarının bir açıklaması olmalıdır. Bir uygulama belirtimi değil, gereksinimler ve işlev belgesi olarak en iyi tanımlanan şeyi paylaştığınızı unutmayın. Ve belirli bir uygulama, belirtilen bir müşteri hedefi olmadıkça, onu nasıl çalıştıracağınız size kalmış.

Kullanıcı arayüzü

Çoğu proje, kitaplıklar veya çerçeveler değil, uygulamalardır. Ancak bunlardan birine sahipseniz, kendinizi şanslı sayın çünkü kullanıcı arayüzü tasarım belge şablonunuzun en sorunlu bileşenidir ve neredeyse her zaman yanlış anlamalara yol açar. Birçok müşteri, programcı olmayan bir grafik tasarımcı tarafından bir grafik düzenleyicide oluşturulmuş mükemmel illüstrasyonları size gönderecektir. Ancak sorun şu ki: bu çizimler animasyonlar, kontrol durumları (örneğin, Bu düğme devre dışı mı? Kullanılamaz olduğunda kayboluyor mu?) veya bir düğmeye basıldığında hangi eylemlerin gerçekleştirileceği hakkında hiçbir şey söylemiyor.

Bu resimlerin arkasındaki kodu yazmaya başlamadan önce, tüm bu soruları cevaplayabilmelisiniz. Özellikle şunları bilmelisiniz:

1. Kontroller her zaman görünür ve/veya etkin mi? Durumları hangi koşullar altında değişir?
2. Bir bitmap gibi görünüyor - bu bir düğme mi?
3. Bu durumlar ve görüşler arasında hangi geçişler meydana gelir? Ve nasıl canlandırılmalılar?

İstemcinin uyumluluğu için kullanıcı arabirimini oluşturmak size kalmışsa, aynısını tersten yapın: bir tel kafes aracı kullanın ve görünümlerin farklı uygulama durumlarında gösterdiği tüm değişkenler dahil olmak üzere eksiksiz bir ekran düzeni seti oluşturun. Bu, kapsamlı ve sıkıcı bir iş olabilir, ancak pişman olmayacaksınız; sizi büyük miktarda kodu yeniden yazmaktan ve büyük sonuçları olan küçük bir yanlış anlama nedeniyle arayüzleri yeniden oluşturmaktan kurtarabilir. İkili bir uygulama oluşturuyorsanız (örneğin, hem iPhone hem de iPad için), her ikisi için de ayrı tel çerçeveler oluşturun.

Ekran boyutları da önemlidir. (Yazıldığı gibi) üç boyutta iPhone ekranı vardır. 3.5” ve 4” ekranlar için ayrı tel kafesler muhtemelen aşırıdır, ancak bunları yapmanız gerekebilir; çoğu durumda, oranları basitçe değiştirebilirsiniz.

Müşteriniz size grafikler sağlıyorsa, bunların uygun en boy oranlarıyla doğru şekilde boyutlandırıldıklarından emin olun; metin veya nesneler (daireler gibi) içeren herhangi bir bitmap'in dönüştürülmesi, bozulmalara neden olur. Eşleşmiyorlarsa, müşteriye bunları eşleşen boyutlarda yeniden oluşturmasını söyleyin. 3,5 inçlik bir açılış ekranını 4 inçlik bir açılış ekranına uzatabileceğinizi ve onunla yuvarlanabileceğinizi düşünmeyin.

işlevsellik

Uygulama tasarım belgesinde sorulacak temel sorular:

• Uygulama ne yapar ve ne kadar hızlı yapar?
• Olası arıza koşulları nelerdir ve nasıl ele alınır?
• İlk çalıştırmada (yani kurulumdan sonra) hangi tek seferlik işlemler yapılır?
• Kullanıcı herhangi bir tür girdi (örneğin, yer imleri) oluşturursa, sınırlamalar nelerdir?

Bu fikirleri genelleştirin ve olabildiğince ayrıntılı ve eksiksiz olun; çünkü buradaki hatalar veya yanlış anlamalar kodun yeniden yazılması anlamına gelecektir.

kilometre taşları

Spesifikasyon şablonunuz, net kilometre taşlarını düzenlemelidir. Müşteriniz işlevsel ve kullanıcı arayüzü tasarımını yazarsa, daha sonra bir dizi dönüm noktası üzerinde anlaşmanız gerekir. Bazen bunlar faturalandırma eşikleri de olabilir, ancak en azından tamamlanmaya yönelik net bir ölçüm sağlarlar. Kilometre taşları, işlevsellik ve/veya bileşenler açısından olabilir; Konser bir dizi çıktı içeriyorsa, bunlar ayrı uygulamalar bile olabilirler. Mümkün olduğunda, kilometre taşlarının süresi yaklaşık olarak eşit olmalıdır.

Yazılım Tasarım Spesifikasyonu Örneği

Burada, uygun bir tasarım belgesinin örnek yapısını düzenleyeceğim. Tabii ki, bu şablon gerektiği gibi ayarlanmalıdır. Başka bir örnek için, bu yazıya dayalı olarak Joel Spolsky'nin örnek belirtimine bakın. Belgeye biraz farklı yaklaşıyor, ancak benzer bir hissi paylaşıyor.

Hedef Açıklaması

Projeyi ve hedeflenen kitleyi açıklayan kısa bir paragraf ekleyin.

Fonksiyonel Açıklama

Uygulama ne yapar ? Kullanıcı hangi uygulama durumlarıyla (temel kullanıcı senaryolarının üst düzey açıklamaları) karşılaşacak?

Örneğin, işlevsel açıklamanız şöyle görünebilir:

• İlk Çalıştırma
• Yeni _____ Oluşturma (oyun, arama vb.)
• Operasyonlar
• Arka Plan ve Ön Plan Davranışı

Kullanıcı arayüzü

Her sayfa için aşağıdakilerin ayrıntılı açıklamalarını içeren tel çerçeveler ekleyin:

• Durumlar (etkin/devre dışı/vurgulanan) ve işlemler dahil olmak üzere her kontrol.
• Desteklenen oryantasyonlar ve bunlar arasındaki geçişler.
• İşlevsellik temsil edildi.
• Hata yönetimi.
• Boyutlar ve kısıtlamalar.

En son iOS uygulamam NotifEye ile ilgili tel kafesler:

İlgileniyorsanız, bu maketleri Balsamiq'in tel çerçeveleme aracını kullanarak yaptım.

Örneğin, kullanıcı arayüzü açıklamanız şöyle görünebilir:

• Gezinti çubuğu
  • Sol gezinme kontrolü: ana sayfaya dön
  • Başlık çubuğu: geçerli ekran veya işlem adı
  • Yeni düğme: yeni bir Şey oluştur
• Tablo görünümü
  • Bölüm 0: Bölüm başlığı
  • Bölüm 0 satırları:
    • Satır kontrolü 0 (ör. resim)
    • Metin Satırı 0
    • Metin Satırı 2

kilometre taşları

Yukarıda açıklandığı gibi, tamamlama için son tarihler ve beklenen çıktılar.

Örneğin, tasarım belgesi şablonunuzdaki kilometre taşları bölümü şöyle görünebilir:

1. Ekranı gösteren ve geçici geçişler ve örnek resimler/metin içeren Cephe Uygulaması
2. İletişim Protokolü: uygulama ağa/sunucuya bağlanır
3. İşlevsel Dönüm Noktası 1: …
4. Alfa Uygulaması (tam işlevsellik ile)
5. istikrar
6. Serbest bırakmak

Yazılım Belgelerinin Alakalı Kaldığından Emin Olmak

Siz ve müşteriniz bir şartname belgesi üzerinde anlaştıktan sonra tasarım aşamasının bittiğini ima etmek istemiyorum. Her zaman ikinizin de düşünmediği ayrıntılar olacaktır ve hem siz hem de müşteri ara sonuçlara bakarken yeni fikirler, tasarım değişiklikleri, beklenmedik tasarım kusurları ve uygulanamaz önerilerle karşılaşacaksınız.

Tasarım gelişecek ve değişiklikler belgenize kaydedilmelidir. 25 yıllık deneyimimde, bunun olmadığı bir projede hiç çalışmadım - ve buna kendi uygulamalarım da dahildir (yani, kendi müşterimdim). O zaman bile, ayrıntılı özellikleri olan bir tasarım belgesi oluşturdum ve gerektiği gibi ayarladım.

Her şeyden önce, iletişimde kalın. Haftada en az birkaç kez müşterinizle iletişime geçin, ilerlemeniz hakkında rapor verin, açıklama isteyin ve aynı vizyonları paylaştığınızdan emin olun. İletişiminiz için bir turnusol testi olarak, siz ve müşterinizin şu üç soruya aynı cevapları verdiğinizden emin olun:

1. Geliştirici ne üzerinde çalışıyordu?
2. Geliştirici şu anda ne üzerinde çalışıyor?
3. Geliştirici bundan sonra ne üzerinde çalışacak?