Temelde PHP'de geliştirilen ve başka bir normal web uygulaması olan bir web uygulamasını tamamladım. Genellikle son üretim sürümünü teslim ettiğimde, kod belgelerini ve mimari bilgileri istemciye teslim ediyorum. Bununla birlikte, bu özel proje için müşteri, proje hakkında eksiksiz bir giriş ve çıkış verisine sahip olmakta ısrar eder.

Merak ediyorum ... Müşterime kod ve mimari belgelerinden ayrı olarak verebileceğim zorunlu teknik ve teknik olmayan dokümanlar nelerdir?

(Ayrıca, ilgili işin miktarını ve ürünün ne kadar havalı olduğunu gerçekten bilmesi için müşteriye proje hakkında çeşitli istatistikler ve veriler hakkında vurmak biraz havalı olurdu.)

Listenin şunları içermesi gerektiğini düşünüyorum:

• Teknik olmayan gereksinimler (böyle bir belge vardı, değil mi?)
• Teknik gereksinimler
• Bazı kararların neden diğerleri üzerinde verildiğini açıklayan bir "kararlar" belgesi (eğer varsa). Bu zaten farklı bir gereksinim veya mimari belgesinde olabilir, ancak bunu Büyük Kararlar için genellikle ayrı ayrı yaparız.
• Kod ve diğer kaynaklar (resim dosyaları, CSS, vb.)
• Veritabanı modeli (şema, belge, her neyse)
• Veritabanı oluşturmak için DDL.
• Veritabanını tohumlamak için DML.
• Uygulama kurulumunu ve temel sorun giderme işlemlerini açıklayan bir belge.
• Önemli kullanıcı adlarının ve şifrelerinin (Yönetici hesapları için) bir listesinin yanı sıra şifreyi nasıl değiştireceğinizle ilgili talimatlar. İdeal olarak, web sitesini ilk kez oluşturduklarında, yeni bir yönetici şifresi girmeleri istenmelidir, ancak bu daha çok mimari bir şeydir.
• Sistem gereksinimleri ve web uygulamaları için minimum barındırma gereksinimleri de (Uygulamanın MySQL veya PostgreSQL'e ihtiyacı var mı? Ne kadar RAM ?, vb ...)

Bunların hepsi her proje için mevcut olmayabilir (veya gerekli olmayabilir), ancak bunun iyi bir genel rehber olduğunu düşünüyorum.

FrustratedWithFormsDesigner'ın gerçekten iyi cevabına ek olarak, teknik olmayan belgelerin neler içerdiğini söylemek istiyorum (yaptığımız gibi):

• analiz verileri: Müşteri gereksinimler hakkında ilk konuştuğunuzda size ne söyledi?

• yaptığınız teklif:

  • ürün gereklilik belgesi
  • ve işlevsel şartname belgesi

  birlikte yapmanız gereken ve
  müşterinin geliştirme sırasında ne yapmasını beklediğiniz , tahmini süre ve maliyet konusunda bir tür sözleşme olarak hareket eder .

• inceleme protokolleri, kullanım örnekleri ve test planları, test sonuçları dahil olmak üzere şartname

• UML'deki tasarım ve ilgili tüm belgeler

• kaynak kodunun dökümantasyonu

• kılavuz ve kurulum yönergeleri

• proje için kullanılan son gerçek kaynak miktarı (zaman ve para), böylece fatura yazabilirsiniz

• bazı müşteriler de toplantı protokollerini ister, bu da yukarıda belirtilen "kararlar belgesinin" bir uzantısıdır

Umarım aradığınız şey budur.

Projeniz için aşağıdakilerden hangisinin geçerli olduğunu izleyin. Bunlardan bazılarına zaten sahip olabilirsiniz.

Teknik döküman:

• PHP hakkında ayrıntılar ve proje için ne kadar yararlı olduğuna dair bilgi
• Arka uçla ilgili ayrıntılar ve proje için ne kadar yararlı olduğuna dair bilgi
• Veri akışını gösteren uygun resimlerle birlikte Veritabanı bağlantısı hakkında bilgi
• Diğer programlama dilleri veya XML, HTML vb. Gibi projeye dahil olan uygulamalar hakkında bilgi
• SSS Yardım dosyası

Ekran görüntüsü olan belgeler hazırlayın ve aşağıdakiler için ilgili kodu (gerekirse) vurgulayın:

• Nesneler veya kontroller, nesne özellikleri vb. Gibi ön uç uygulamasındaki bilgiler.
• Veritabanı sorgularıyla ilgili bilgiler (zaten yoksa)
• Birincil Anahtar, Yabancı Anahtar vb.Gibi veritabanı özellikleri ve veri tutarlılığı ve doğruluğunu nasıl sağladıkları hakkında bilgi.
• Mantıksal bir sırayla benzer türden veri veya ekran tekrarlanmadan örnek verilerle çalıştırıldıktan sonra hem ön ucu hem de arka ucu kullanarak tüm olası ekran türlerinin ekran görüntülerini kullanarak proje boyunca ayrıntılı rehberlik.

• Ön veri ve ön uçta veri doğrulaması yaptığınız için geçersiz veri girin ve bunu yapmanın imkansız olduğunu gösterin.
  /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

• Sunucuda veya istemci sisteminde ani bir arıza varsa, ilgili kodu açıklayarak programda herhangi bir hata olmadığını veya verilerde tutarsızlık olduğunu gösterin.

• Ön uçtan örnek veriler verdikten sonra, verileri sunucudan doğrudan almak için arka uca örnek sorgular ekleyebilir ve verilerinizin hayati istatistiklerini hazırlamaya yardımcı olabilecek örnek DML sorguları ekleyebilirsiniz.

Bunları belgelemeden önce kendiniz kontrol etmelisiniz, böylece müşteriniz örnek verilerle bir demo isterse, projenin gerçekte nasıl çalıştığını gösterebilirsiniz.Ayrıca, ön uç kodunuzun uygun yorum satırlarına sahip olduğundan emin olun.

• Son olarak, toplam kod satırı, projeye yönelik toplam gün sayısı, projeyi toplam kontrol sayısı, kullanılan tüm uygulamaların listesi ve diğer teknik ve teknik olmayan bilgiler gibi istatistiklerle sonuçlandırın.

  
  Teknik olmayan belgeler:

• Varsa, projenin lisans ayrıntıları.
• Varsa, projenin ticari yönleri.

Dikkatli olmak

Müşteriye verebileceğiniz potansiyel belgeler neredeyse sınırsızdır. Henüz sahip olmadığınız belgeleri oluşturmak için gereken ek süre ücretsizdir.

İstemci neden bu belgeleri istiyor (kaynak kodunun üstünde ve üstünde)? Bununla ne yapılacak? Kimin için?

Bu soruların cevapları ne sunacağının kapsamını daraltmaya yardımcı olacaktır.

Sizin ve müşterinizin tam olarak hangi belgelerin sunulacağına ve ek çabaların telafi edilip edilmeyeceğine karar vermeniz önemlidir.

Tahmin oyunları oynamayın. Teknik belgelerin çoğu, tipik (teknik olmayan) istemciler için işe yaramaz.

Muhtemelen bunu birkaç belge kategorisine ayırırım:

Kılavuzlar:

• Kurulum kılavuzu, bunu bir sunucuda nasıl kurar.
• Optimum performans için uygulamanın nasıl yapılandırılacağı ve çalıştırılacağı hakkında yönetici kılavuzu. Güvenlik de burada ele alınacak bir şey olurdu, böylece bu uygulamanın hangi şifrelerin sahip olduğu ve çalıştırmak için kullandığı bilinir.

Destek:

• Sorunlar varsa, ne tür prosedürler önerirsiniz? Bir süre destek veriyor musunuz? Muhtemelen hala bir ya da iki rehber bu alanda sadece bir başkası hizmetleri yeniden başlatmak ya da bir sunucuyu yeniden başlatmak gibi denemek için daha kolay şeyler bilir.

Entegrasyon noktaları:

• Bu uygulama için kodunuz dışındaki diğer satıcılara güvenen 3. taraf entegrasyon noktaları var mı?