Geliştirme sonrasında bir Yazılım Tasarım Belgesi oluşturmak haklı olabilir mi?

Şu anda harici bir şirkette bireysel olarak karmaşık yazılım geliştirmem gereken "Yazılım Geliştirme" çalışmalarım için mezuniyetim üzerinde çalışıyorum. Tüm bunların, ilgili tüm belgeleri oluşturarak yapılandırılmış bir şekilde yapılması gerekir.

Bu proje için IEEE standart belgeleriyle çalışmayı seçtim: Yazılım Gereksinimleri Belgesi (SRS), Yazılım Mimarisi Belgeleri (SAD) ve Yazılım Tasarım Belgesi (SDD). Okulda başka türlü öğretilmesine rağmen, bu proje için SDD'yi geliştirmeden sonra (daha önce değil) oluşturmayı seçtim . Benim akıl yürütmem:

Staj yaptığım şirket bana, belirli bir gereksinim kümesini deneysel bir şekilde karşılayan karmaşık bir yazılım oluşturma talimatı verdi. Bana proje tanımında verdikleri özgürlük miktarı nedeniyle, neredeyse hiçbir şey önceden kesin değildir ve en iyi geliştirme sürecinde denemeler yapılırken karşılaşılabilir. Ayrıca, yazılımı bireysel olarak oluşturuyorum , bu Yazılım Tasarımını önceden yapmamın şirketteki hiç kimseye faydası olmazdı. Önceden yapmak, daha sonra değiştirmek için bana çok zaman kazandıracak, çünkü projedeki belirsizlikler ile önceden yaptığım tasarımın çok değiştirilmesi gerekeceğinden emin olabilirim . Bu bana verimsiz geliyor.

Bu, geliştirme sonrasında SDD oluşturmak için iyi bir gerekçe midir? Değilse, bunun için iyi bir gerekçe var mı?

Düzenleme: SDD'yi daha sonra yaratmanın nedeni gelecekteki geliştiricilerin projeye devam etmeleri olacaktır. Mezuniyet dönemimde tüm projeyi bitiremeyeceğim, bu yüzden diğer geliştiriciler mevcut kod tabanına devam etmek zorunda kalacaklar.

IEEE Std 1016 Bölüm 3.1 Bağlamda yazılım tasarımı bölümünde bu paragrafı bulabilirsiniz:

Bir SDD çeşitli tasarım durumlarında hazırlanabilir ve kullanılabilir. Tipik olarak, bir SDD, bir problemi çözmek için bir yazılım öğesinin geliştirilmesini desteklemek üzere hazırlanır; bu problem, bir dizi gereksinim açısından ifade edilir. SDD'nin içeriği bu gereksinimlere göre takip edilebilir. Diğer durumlarda, bir SDD tasarım belgelerine sahip olmayan mevcut bir sistemi anlamak için hazırlanır. Bu gibi durumlarda, bir SDD, ilgili bilgilerin yakalanması, organize edilmesi, sunulması ve ilgili tüm taraflara dağıtılması için hazırlanır. İlgilenilen bu bilgiler, temel tasarım endişelerini belirleyip ele alarak yazılım sisteminin planlanması, analizi, uygulanması ve evrimi için kullanılabilir.

IEEE Std 1016'nın yazarları, SDD'nin önceden oluşturulamayabileceğini kabul ediyor. İlgilenen taraflar için bilgi yakalamak amacıyla yazılım sistemi oluşturulduktan sonra oluşturulabilir.

Bölüm 1.1 Kapsam ayrıca bazı ilginç bilgiler sunar:

Bu standart, tasarım, konfigürasyon yönetimi veya kalite güvencesi için belirli metodolojiler öngörmez.

Bu sorular bağlamında, anahtar kelimeler "konfigürasyon yönetimi" dir. Yapılandırma yönetimi yalnızca oluşturulan yazılım sistemi için değil, ilişkili tüm belgeler için de geçerlidir.

Kişisel durumunuzda ve birçok durumda ön tarafta bir SDD oluşturmak israftır. David Arno'nun cevabı doğru cevabı düşündüğüm konuya yakın. Yazılım sisteminizin gerçek tasarımı koddur. Ancak, "önce SDD oluştur" veya "sonra SDD oluştur" tek seçenekleriniz değildir. Üçüncü bir seçeneğiniz var - SDD'yi yazılım sistemiyle geliştirin.

IEEE Std 1016 gibi bir standardı izliyorsanız, bir SDD için gereksinimleriniz vardır. Özellikle, bu standardın 4. Bölümü sahip olduğunuz içeriği tanımlar. Tasarım kararları üzerinde çalışırken farklı bakış açıları, görüşler ve katmanlar oluşturmaya başlayın. Karar verirken, onlar için tasarım mantığını yakalayın.

Bu, ilgili tarafların, kodun içine girmeye gerek kalmadan yazılım tasarımının gelişimini takip etmelerini sağlayacaktır. Tabii ki, insanların yorum ve önerileri olabilir. SDD'yi güncelliyorsanız, ilerlemenizi izleyebilir ve yaklaşıma ilişkin geri bildirimde bulunabilirler; bu, daha sonra ürüne ve SDD'ye dahil edebilirsiniz. Projeden geçiş yaptığınızda, yazılım kodu ve SDD eşzamanlıysa, bir kişi kolayca işe koyulmalı ve işi almalıdır.

SDD'den aradığınız tek şey tasarımı başkalarıyla iletmekse, evet, geliştirmeden sonra oluşturabilirsiniz. Tek şey, o zaman belgeleme denir.

Ancak, bir SDD'nin başka bir amaca da hizmet edebileceğini belirtmek isterim. Ayrıca, tasarım hakkında akıl yürütmenize ve "hızlı başarısız olmanıza" emin olmanıza yardımcı olabilir. Bu iyi bir şeydir, özellikle önceden bir sürü şey belirsizse, erken uygulama boyunca işe yaramayacak yaklaşımları atabilirsiniz. Ayrıca, tasarımı anlayana kadar hiçbir şey kodlamadan teknik ayrıntılara odaklanmanızı da engelleyebilir.

En azından SDD'yi önceden denemenizi tavsiye ederim. İşlerin nasıl çalışacağından emin olmadığınız şeylerle karşılaşırsanız, çözmeye çalıştığınız sorunların küçük prototiplerini yapabilirsiniz. Bu, projeniz için uzun vadede eksiksiz çözümün kalitesine fayda sağlayacak belirli sorunları çözme konusunda deneyim verecektir.

Yaratacağınız gerçek bir ayrıntılı tasarım belgesi koddur. Derleyiciye uygulamanızı nasıl oluşturacağınızı tam olarak anlatır. Bu nedenle, tasarımınız göndermeden önce son bir yapıya kadar tamamlanamaz.

SDD gibi oluşturduğunuz diğer tüm tasarım belgelerinin, tasarımınızı (kod) tamamladıktan sonra güncellenmesi gerekecektir. Bu nedenle, SDD'yi daha sonra yazmak için zorlayıcı bir neden var: Bunu sadece bir kez yapmanız gerekiyor.

Bunun bariz karşı tarafı , "olaydan sonra ne sıklıkla bir SDD yazıyorsunuz ?" Uygulama gönderilir, bu nedenle o aşamada dokümantasyon yapmak için zaman harcamak istemezsiniz. Ancak bu, var olanı güncellemek için de geçerlidir. Hangisi daha kötü, SDD veya yanlış olan ve güvenilemeyen bir SDD yok mu?

Önceden yazmak için iki neden var. Öncelikle bunu yapmak sizin için zorunlu bir gereklilik olabilir (hoş değil; ama olur). İkincisi, böyle bir belge oluşturmak, tasarım için genel bir strateji formüle etmenize yardımcı olabilir. Ancak bu gayri resmi bir şekilde resim çizerek, notları karalayarak vb. Daha sonra yeniden yazılması gerekeceğinden, bu ön makro tasarım sürecine "hızlı ve kirli" yaklaşımın birçok yararı vardır.

Benim için bu iyi bir tartışma olmazdı.

Gerçekten ihtiyaç duyulursa, bilinmeyen bir problem alanını daha iyi anlamak için prototip geliştirmeye güçlü bir şekilde odaklanacağım. Bununla birlikte, bu durumlarda bile, bazı tasarım parçaları daha önce yararlı olacaktır.

Zaten bunu yapmak için yapılması gereken bir dava var . Çünkü böyle belgeler yazma hakkında bilgi edinmek için bunu yapıyorsunuz . Bu işi atlamak, burada% 100 gerekmeyebileceği için öğrenmenizi atladığınız anlamına gelir.

Bir uzlaşma, uygulama sırasında yazmak olabilir . Her bileşen / modül / ekran veya programınızın diğer alt bölümlerinden önce, bunu nasıl yapacağınızı düşünmeniz gerekir. Ardından kararlarınızı tasarım belgenize ekler ve uygularsınız.

Daha sonra herhangi bir değişiklik olursa, belgeyi güncellersiniz.

Bu, gerçeğin ardından yazmaya kıyasla çeşitli avantajlara sahiptir:

• Gereksinimler değiştiğinde tasarım belgelerini güncel tutmayı öğreneceksiniz, yararlı bir alışkanlık

• Uygulamadan önce tasarım hakkında düşünmeyi öğreneceksiniz

• Olgudan sonra tasarım belgeleri yazmak kadar zihinsel olarak sıkıcı değil

• Zamanınız tükenirse, başkalarının çalışmalarınıza devam edebilmesi için şu ana kadar sahip olduklarınızı açıklayan bir tasarım belgeniz olacaktır.

• Bu şekilde fazladan iş yok

• Projeniz devam ederken, neden iki ay önce böyle bir şey yaptığınızdan emin olamayabilirsiniz ve notlarınızı size söyleyeceksiniz.

Sistem, yeni tasarım ve çözüm nitelikleriyle ilerlerken temel gereksinimlerin yanı sıra (yeni özellikler) bir güncellemenin kaydıdır. Proje / çözüm sağlanana kadar sürdürülür. Yararlı, tüm ilgili kişilerle iletişim kurar.