Amaç

​

Bu bölümde AR&GE projelerinde dokümantasyon konusundaki tecrübelerimi aktarmaya çalışacağım.

​

Giriş

​

Araştırma ve geliştirme (Ar-Ge) projeleri, müşteri taleplerini ve pazarlarını karşılamak için sistematik olarak yeni ürün ve hizmetler sunarak işletmeleri veya diğer işletmeleri sürdürmek ve büyütmek için üstlenilen çabalardır.

​

Araştırma doğası gereği çok temel olduğunda, Ar-Ge çabası daha bilimseldir.Araştırma daha uygulamalı olduğunda, Ar-Ge çabası daha ticaridir. Nihai amacın doğayı daha derinden anlamak veya keşfetmek olan saf bilimsel araştırmadan farklı olarak, Ar-Ge, mevcut veya beklenen pazarlar için yeni ürünler ve hizmetler yaratmanın çok özel bir amacına sahiptir. Geliştirme, Ar-Ge'deki "Ge", bilimsel araştırma ilkeleriyle eşleştirildiğinde "Ar", yeni çözümler, teknikler, ürünler, yöntemler ve hizmetler sunmak için sistematik bir yöntem içeren yaratıcılık ve yeniliğe atıfta bulunur.

​

Cevapları deneysel olarak belirlenebilen ve üretken sonuçlara daha doğrudan bir yol göstermek için kullanılabilen stratejik olarak ifade edilmiş sorular sorarak rastgele evrimi ve tahminde bulunmayı geliştirmeye çalışır. Saf bilim, doğayı keşfetme ve anlama mucizesiyle ilgilenir; mühendislik ayrıca bu bilgiyi iyi kullanmak için sorumluluk taşır ve Ar-Ge, sürdürülebilir işletmeler içinde yürütülen süreçtir.

​

Bir Ar-Ge çalışmasının sonuçlarını sunmak, sürecin bireysel adımlarını gerçekleştirmek kadar önemlidir. Sonuçlar başkaları tarafından erişilebilir hale getirilmezse, daha verimli ürün geliştirme orijinal hedefine karşı çıkarak çaba boşa gitmiş olur.

​

Her ürün tasarım döngüsü, daha fazla iyileştirmenin bağlı olduğu bir öncül, bir hipotez veya bir inanç sıçraması ile başlar. Genellikle, daha fazla iyileştirme oldukça pahalıdır. Bu nedenle sağduyu, ilk önermeyi veya hipotezi mümkün olan en kısa sürede doğrulamayı gerektirir.

​

“Bu makale, AR&GE dokümantasyon sürecinden üretime ve üretim sonrası dokümantasyon konusunda kendi araştırmalarıma ve pratik gözlemlerime dayanmaktadır. Bu makalede, kişisel deneyimime dayanan; avantajlar, dezavantajlar, varsayımlar, sonuçlar, tasarım kuralları ve kullanışlı ipuçları da dahil olmak üzere dokümantasyon yönergeleri sunacağım.”

 

AR&GE Dokümantasyonu

​

Tüm Ar-Ge çabaları, aşağıdaki soruları cevaplamak için son noktadır;

​

• Bu ürün konsepti teknik olarak uygulanabilir mi?

• Bu tasarım bu teknoloji kullanılarak oluşturulabilir mi?

• A tasarımı mı yoksa B tasarımı mı daha güvenilir?

• Üretim maliyeti nasıl düşürülebilir?

• Hangi tasarım müşterinin ihtiyaçlarına en iyi şekilde hizmet edecek?

 

Kısacası, bir Ar-Ge raporu, Ar-Ge sorusunun nasıl araştırıldığının ve cevaplandığının hikayesini anlatır.

 

Etkili bir Ar-Ge raporu aşağıdaki bileşenleri içermelidir:

​

1. Başlık Sayfası

2. Takım, Roller ve Sorumluluklar

3. Ürün Gereksinimleri Belgesi

4. Gerçekçi Kısıtlamalar ve Mühendislik Standartları

5. Sistem Gereksinimleri Belgesi

6. Proje Takvimi

7. Proje Kaynakları

8. Deneylerin Ana hatları

9. Deneme Tasarımları

10. Deneysel Sonuçlar

11. Etki ve Sonuçlar

12. Sonuçlar ve Öneriler

 

Tasarıma ait ilk dokümantasyon AR&GE raporuyla başlar. Bu yüzden; yukarıda belirtilen tüm parametreler dokümantasyonun ilk adımlarıdır. AR&GE raporu gereksinimlerin belirlenmesiyle taçlanır.

​

Yaygın olarak bulunan gereksinimlerden bazıları aşağıda listelenmiştir. Bunların her biri, daha spesifik öğelere daha fazla bölünecek olan genel kategorilerdir;

​

1. Fonksiyonel Gereksinimler

2. Boyut, Ağırlık ve Maliyet Gereksinimleri

3. Mekanik Gereksinimler

4. Güç Gereksinimleri

5. Termal Gereksinimler

6. İletişim ve Arayüz Gereksinimleri

7. Kontrol Gereksinimleri

8. Hesaplama Gereksinimleri

9. Yazılım ve Gömülü Yazılım Gereksinimleri

10. Veri Depolama, Format, Güvenlik Gereksinimleri

11. Hassasiyet ve Doğruluk Gereklilikleri

12. Kullanıcı Arayüzü Gereksinimleri

13. Test ve Doğrulama Gereklilikleri

14. Elektromanyetik Uyumluluk Gereksinimleri

15. Güvenlik Gereksinimleri

16. Standart Gereklilikleri

17. Düzenleyici Gereklilikler

18. Çevresel Gereklilikler

19. Malzeme Gereksinimleri

 

Bu gereksinimlerin dokümante edilmesi çok önemlidir. İyi kayıt tutma, bir mühendisin rolünün önemli bir yönüdür ve iş hayatının temel bir parçasıdır. Tasarım takibinin tüm yönlerini detaylandıran doğru bir yazılı kayıt, yalnızca tasarımın sağlanmasının veya mühendislik yönetiminin ayrılmaz bir parçasını oluşturduğu için değil, aynı zamanda dahil olan farklı ekipler arasında bilgi dolaşımına da katkıda bulunduğu için önemlidir. Yine cihaz bakımında ve saha testlerine de  katkıda bulunduğu için önemlidir.

 

Sorumlu olduğun kişiye ve şirkete kaşı da hukuki anlamda dokümantasyon ve kayıt tutma, mühendisin korunması için vardır. İyi tutulan bir kayıt, eylemlerinin yasal olarak savunmasının gerekli olduğu durumlarda uygulayıcıyı koruyabilir. Dokümantasyon ayrıca bir profesyonelleşme meselesini ve uygulamaların iyileştirilmesinin kanıtını da sağlar.

​

Kısıtlamalar

​

Sistemin donanımının, yazılımının ve/veya iletişiminin tasarımı üzerinde önemli bir etkisi olan tüm küresel sınırlamaları veya kısıtlamaları tanımlayın ve ilgili etkiyi tanımlayın.

​

Bu tür kısıtlamalar aşağıdakilerden herhangi biri tarafından uygulanabilir (liste ayrıntılı değildir):

​

• Donanım veya yazılım ortamı
• Son kullanıcı ortamı
• Kaynakların kullanılabilirliği veya değişkenliği
• Standartlara Uygunluk
• Birlikte çalışabilirlik gereksinimleri
• Arayüz/protokol gereksinimleri
• Lisans gereksinimleri
• Veri deposu ve dağıtım gereksinimleri
• Güvenlik gereksinimleri (veya bu tür diğer düzenlemeler)
• Bellek veya diğer kapasite sınırlamaları
• Performans gereklilikleri
• Ağ iletişimi
• Doğrulama ve doğrulama gereksinimleri (test)
• Kalite hedeflerini ele almanın diğer yolları
• Gereksinimler Belgesinde açıklanan diğer gereksinimler

​

Mimari Stratejiler

​

Sistemin genel organizasyonunu ve üst düzey yapılarını etkileyen tüm tasarım kararlarını ve/veya stratejilerini tanımlayın. Bu stratejiler, sistem mimarisinde kullanılan temel soyutlamalar ve mekanizmalar hakkında bilgi sağlamalıdır.

​

Her bir karar ve/veya strateji için kullanılan mantığı (muhtemelen daha önce belirtilen tasarım hedeflerine ve ilkelerine atıfta bulunarak) ve herhangi bir tasarım hedefinin veya önceliğinin nasıl dengelendiğini veya değiş tokuş edildiğini tanımlayın.

​

Kurumsal Mimari ve standartlarla uyumluluğu açıklayın. Standartlardan yapılan sapmaları özellikle tanımlayın ve sapmaları desteklemek için gerekçe sağlayın.

​

Bir tasarım kararını tanımlarken, dikkate alınan diğer önemli alternatifleri ve bunları reddetme nedenlerini (nihai olarak seçilen alternatifi kabul etme nedenlerini) tartışın.

​

Bazen bir stratejiyi tanımlamak için “kalıp biçimini” kullanmak en etkili olabilir.

​

Tasarım kararlarının örnekleri aşağıdaki gibi şeylerle ilgili olabilir (ancak bunlarla sınırlı değildir):

​

• Belirli bir ürün türünün kullanımı (programlama dili, veritabanı, kitaplık, ticari kullanıma hazır (COTS) ürün vb.)
• Sistemin çeşitli parçalarını/özelliklerini uygulamak için mevcut yazılım bileşenlerinin yeniden kullanımı
• Yazılımı genişletmek veya geliştirmek için gelecek planları
• Kullanıcı arayüzü paradigmaları (veya sistem giriş ve çıkış modelleri)
• Donanım ve/veya yazılım arayüzü paradigmaları
• Hata algılama ve kurtarma
• Bellek yönetimi politikaları
• Harici veritabanları ve/veya veri depolama yönetimi ve kalıcılığı
• Bir ağ üzerinden dağıtılmış veri veya kontrol
• Kontrole yönelik genelleştirilmiş yaklaşımlar
• Eşzamanlılık ve senkronizasyon
• İletişim mekanizmaları
• Diğer kaynakların yönetimi

​

Mühendislikte Kullanılan Kayıt Tutma Türleri

​

• Elle yazılmış kayıtlar

• Bilgisayar tabanlı sistemler (elektronik)

• Bazı kuruluşlar veya işverenler her ikisinin bir kombinasyonunu kullanır(ERP, RPM vb.).

​​

İşvereninizin veya kuruluşunuzun kayıt tutma için belirlediği gereksinimlere uymanız beklenecektir. Bu, şunları yapmanız gerekeceği anlamına gelir:

​

• Güvenlik, gizlilik ve uygun kullanım dahil olmak üzere işyerinizdeki bilgi sistemleri ve araçları konusunda güncel olduğunuzdan emin olun;

• Herhangi bir sisteme erişiminizi sağlamak için size verilen şifreleri veya ayrıntıları koruyun;

• Yazılı kayıtların yetkisiz kişilerin görebileceği halka açık yerlerde (her türlü elektronik sistem veya ekran dahil) bırakılmadığından emin olun;

​

Bir mühendisin tasarım ve üretim kayıtlarının bileşenleri şunları içerir:

 

• Tasarım, üretim kayıtları

• Test kayıtları/ilerleme notları

• Çizelgeler

• Gereksinimler ve raporlar

• Malzeme bilgileri ve alternatif malzemeler listesi

• Gözden geçirme toplantı notları

• Ürün tasarım süreci ve tablolar

​

İyi Kayıt Tutma İlkeleri

 

Bazı önemli faktörler, iyi bir kayıt tutmanın temelini oluşturur. 

​

Tasarımla ilgili kayıtlar:

​

• Gerçek, tutarlı ve doğru olun;

• Kaydedilebilir herhangi bir olaydan sonra tasarımla ilgili herşeyi mümkün olan en kısa sürede güncelleyin;

• Tasarımın, ürünün bakımı ve durumu hakkında güncel bilgiler sağlayın;

• Metin silinemeyecek şekilde net bir şekilde belgelenmelidir;

• Şema üzerinde ve diğer dokümanlar üzerinde ardışık ve doğru tarihli, zamanlanmış ve tüm giriş / çıkışlar ve değişiklikler kaydedilmiş olmalıdır. Eski versiyonlar bir şekilde arşivlenmelidir.

• Tüm işyerleri veya kuruluşlar aynı terminolojiyi kullanmayacağından tasarımcı; kısaltma, argo veya jargon içermeyen şeyler kullanmalıdır.

• Kayıtlar güvenli bir şekilde saklanmalı ve yalnızca şirket politikanıza göre imha edilmelidir;

• Anlamsız ifadeler, spekülasyonlar ve saldırgan öznel ifadeler/hakaret veya aşağılayıcı dilden kaçınılmalıdır.

• Tasarım dokümanlarınız; fotokopi veya taranmışsa yine de okunabilir olmalıdır.

 

Kayıt Tutmada Yaygın Eksiklikler

 

Kötü kayıt tutma, tasarımda veya üründe doğru bilgiye ulaşmayı, müdaheleyi, bakımı, gerekliyse diğer tasarımcıların müdahalesini engeller işlerin aksamasına yol açabilir.

​

Kayıt tutmadaki en yaygın eksiklikler şunları içerir:

​

• Netlik yokluğu

• Yanlışlıklar

• Yazım hataları

• Eksik bilgi

• Bir sorun tespit edildiğinde yapılan işlemin kaydedilmemesi.

 

İyi Kayıt Tutmanın Faydaları

 

Kayıt tutma, profesyonel uygulama için bir araçtır. Tasarım, üretim ve bakım sürecine yardımcı olması gereken bir araçtır. Ayrı değildir ve koşullar izin verirse takılacak isteğe bağlı bir ekstra değildir.

​

Şirket içi ve saha testleri tamamlandıktan sonra en kısa sürede tutanak tutulmalıdır. Tasarımın veya ürünün notlarında doğru kaydın yapılması önemlidir ve müdahaleleri ve müdahalelere verilen yanıtları içermelidir.

​

İyi bir kayıt tutmanın önemi şunlardır:

​

• Kayıt tutma, bakımın sürekliliğini kolaylaştırır;

• Kayıt tutma, çok profesyonel ekibin üyeleri arasında daha iyi iletişim ve bilginin yayılmasını teşvik eder;

• Şikayetlerin veya yasal süreçlerin ele alınmasına yardımcı olur;

• Şirket içi denetim, araştırma, kaynak tahsisi ve performans planlamasını destekler;

• Risklerin belirlenmesine yardımcı olur ve komplikasyonların erken tespit edilmesini sağlar;

• Müşteri merkezli iletişimi destekler;

• Hizmet sunumunu destekler;

• Hesap verebilirliği geliştirmeye yardımcı olur;

• Tasarım, üretim ve bakım sürecinde kararların nasıl alındığını gösterir.

 

Kayıt Tutmada Yasal Konular

 

Tasarımla ilgili kayıtlar; mühendis çalıştığı şirketten ayrıldığında bazen bir mahkeme önünde kanıt olarak veya yerel, kuruluş düzeyinde bir şikayeti araştırmak için gereklidir.

​

Suistimalle ilgili iddiaları araştırırken bazen profesyonel yönetim organları tarafından kayıtlar istenebilir. Bu nedenle yazdıklarınıza dikkat etmelisiniz. Örneğin, bir müşteriden gelen bir şikayet durumunda veya şirket içi bilgilerin dışarıda kullanılması durumunda kayıtlarınızı resmi olarak açıklamanız istenmeyecektir. Yazışmalar esas alınacaktır.

 

Organizasyon Elektronik Dosya Yönetiminin Anahtarıdır

​

Elektronik belgelerinizi düzenli tutmak, günümüzün "kablolu" dünyasında oldukça angarya olabilir.

​

Belgeleri masaüstü bilgisayarlarda, dizüstü bilgisayarlarda veya mobil cihazlarda yerel olarak depolamaya ek olarak , giderek daha fazla işletme, temel iş uygulamaları ve dosya depolama için bulutu kullanıyor.

 

Depolama sorununu daha da karmaşık hale getirmek, birçok işletmenin çalışanları arasında belgeleri paylaşma ihtiyacıdır. 

​

Bir ofis içinde bu, genellikle bir dosya sunucusu veya ağa bağlı depolama aygıtı kullanılarak gerçekleştirilir.

​

Paylaşılan mobil erişim gerekiyorsa, belgeler bulutta saklanabilir ve erişim izinleri atanarak paylaşılabilir.

​

Tüm bunların sonucu, bir kişinin belgelerinin bazılarının bulutta ve bazılarının yerel olarak depolandığı ve hatta tek tek belgelerin yalnızca bir yerde veya diğerinde saklandığı bir dosya yönetimi kâbusu olabilir.

​

Belgelerin saklandığı her yerde, onları düzenli ve güncel tutmak önemlidir. Amaç elektronik dosya yönetim size onun oluşturulmasından sonra yıllarca aradığınız bile aradığınızı bulabilirsiniz sağlamaktır.

​

Çoğu iş adamı/tasarımcı; bir zamanlar, bir müşteri araması yapmak ve ilgili faturayı veya diğer önemli müşteri belgelerini hızlı bir şekilde bulamamak gibi utanç verici bir durumda olmuştur . Aynı derecede sinir bozucu olan, yıl sonunda muhasebecinin veya daha da kötüsü vergi memurunun şirket hesaplarıyla ilgili belgeleri bulmaya çalışmaktır .

​

Dijital belgelerin düzgün bir şekilde düzenlenmesi, özellikle paylaşılan bir ortamda kritik öneme sahiptir. Çalışanlarınızdan biri (geçici veya kalıcı olarak) yoksa, o kişi tarafından oluşturulan veya yönetilen herhangi bir belgeyi kolayca bulabilmelisiniz.

​

Hoşnutsuz, işten ayrılan çalışanlarla ilgili olası veri kaybı sorunları , iş verilerinizi korumanın bir başka nedenidir.

​

Elektronik Dosyalarınızı Düzenli Tutmak için Dosya Yönetimi İpuçları

 

1. Program Dosyaları için Varsayılan Kurulum Klasörlerini Kullanın

​

Uygulama programlarını kurarken varsayılan dosya konumlarını kullanın. Windows altında, kural olarak, uygulama programı dosyalarını örneğin (Drive D:)->Prject Files dizini altına koyabilirsiniz. Başka bir yere uygulama yüklemek kafa karıştırıcı ve gereksizdir. 

​

2. Tüm Belgeler için Tek Yer

​

Tüm belgeleri tek bir "kök" klasörün altına yerleştirin. Windows ortamındaki tek bir kullanıcı için varsayılan konum Belgelerim klasörüdür.

Bir dosya paylaşım ortamında da aynısını yapmayı deneyin. Tek bir kök klasör (örneğin "Paylaşılan Belgeler" olarak adlandırılır) oluşturun ve tüm belgeleri kök klasörün içindeki alt klasörlerde saklayın. Tüm elektronik belgeler için tek bir konuma sahip olmak, bir şeyleri bulmayı ve yedeklemeleri ve arşivleri çalıştırmayı kolaylaştırır.

​

 3. Mantıksal Bir Hiyerarşide Klasörler Oluşturun

​

Bunlar, tabiri caizse bilgisayarınızın dosya dolabının çekmeceleridir. Klasörlerinizi adlandırmak için sade bir dil kullanın; Gelecekte bu klasör listesine bakmak veya icat ettiğiniz diğer ilginç kısaltmaların ne anlama geldiğini merak etmek istemezsiniz.

​

4. Klasörleri Klasörler İçine Yerleştirin

​

Gerektiğinde bu ana klasörler içinde başka klasörler oluşturun. Örneğin, "Project" adlı bir klasör, "2018", "2017" ve "2016" adlı klasörler içerebilir. Bir istemci için adlandırılan bir klasör, "Design" ve "Yazışmalar" klasörlerini içerebilir. Amaç, bir grup yetim dosyanın listelenmesi yerine her dosyayı bir klasörde tutmaktır.

Karmaşık, çok katmanlı klasör yapıları oluşturmayın. Mümkün olan her yerde bunun yerine açıklayıcı dosya adları kullanın.

 

5. Dosya İsimlendirme Kurallarını Takip Edin

​

Bazı işletim sistemleri (Unix gibi) dosya veya klasör adlarında boşluklara izin vermez, bu nedenle bilgi işlem ortamınız karışıksa bundan kaçının. Bunun yerine, ayırıcı olarak çizgi kullanımı (Örneğin; Project_Test_Report.docx) Diğer karakterleri gibi /? < > \ : * | " ^ Windows altında dosya veya klasör adlarında da yasaktır.

​

Kolay tanımlama ve alma için açıklayıcı dosya adları kullanın, ancak aşırıya kaçmayın - dosya/yol adlarının işletim sistemleri arasında değişen uzunluk sınırları vardır. Örneğin ORCAD veya Altium kullanıyorsanız; uzun dosya isimlendirmesi veya uzun klasör isimlerinden dolayı dosyayı bazen açamama sorunuyla bile karşılaşabilirsiniz.

​

Windows altında bir dosya için maksimum tam yol uzunluğu (Örneğin; Sürücü harfi + klasör adları + dosya adı) 260 karakterdir. 

​

6. Spesifik olun

​

Elektronik dosyalara mantıklı, belirli adlar verin ve mümkünse dosya adlarına tarihler ekleyin. Dosyaları adlandırırken amaç, dosyayı açıp bakmak zorunda kalmadan dosyanın ne hakkında olduğunu söyleyebilmektir. Bu nedenle, belge EMC test sonuçlarına, buna "EMC_Line_conducted_26102021" vb gibi bir şey yazın; "mektup" gibi bir şey yazmayın. Mektubun kime olduğunu açmadan nasıl bileceksiniz?

Dosyaları e -posta veya taşınabilir cihazlar aracılığıyla paylaşıyorsanız , klasör bilgileri paylaşılan dosyaya dahil edilmeyeceğinden dosya adının daha spesifik bilgiler içermesini isteyebilirsiniz. 

​

Örneğin, belgeniz Belgelerim\Designs\2021\Customers\ATA_26102021.docx konumunda bulunuyorsa ve dosya paylaşılıyorsa veya e-postayla gönderiliyorsa, alıcının tüm göreceği ATA_26102021.docx dosyasıdır ve dosyanın bir müşteriye veya kendisine ait olduğunu anlayamayabilir.

​

7. Doğru Dosyalayın

​

Bir belgeyi dosyalamak için en iyi zaman, onu ilk oluşturduğunuz zamandır . Bu nedenle, belgenizi dosyalamak ve adlandırmak için "Farklı Kaydet" iletişim kutusunu kullanma alışkanlığını edinin ve ilk etapta doğru yere koyun.

​

8. Rahatlığınız İçin Dosyalarınızı İşaretleyin

​

Çok kullandığınız klasörler veya dosyalar varsa, onları bir ! veya dosya adının başında bir AA veya + işareti koyarak isimlendirebilirsiniz.

​

9. Dosyalarınızı Düzenli Olarak Ayırın

​

Bazen neyin eski olduğu, yukarıdaki "Designs" adlı klasör örneğinde olduğu gibi açıktır. Değilse, eski dosyaları temizleyerek klasörlerinizi düzenli tutun .

​

Dosyaya bir daha asla ihtiyacınız olmayacağından kesinlikle emin olmadığınız sürece işle ilgili dosyaları silmeyin. Bunun yerine, kök klasörünüzün altındaki ana klasör koleksiyonunuzda "Eski" veya "Aktif Değil" adlı bir klasör oluşturun ve eski dosyaları karşılaştığınızda bu klasöre taşıyın.

 

10. Dosyalarınızı Düzenli Olarak Yedekleyin

​

Dosyalarınızı ister başka bir sürücüye ister teybe kopyalıyor olun, düzenli bir yedekleme rejimi kurmak ve takip etmek önemlidir.

 

Veri kaybı

​

Verilerinizi kaybetmenin birçok yolu vardır:

​

• Bir masaüstü/dizüstü bilgisayar sabit diskinin çökmesi veya mobil cihazınızın zarar görmesi verilerinizi kurtarılamaz hale getirebilir

• Bilgisayarınız veya telefonunuz çalınabilir - iş yerlerine izinsiz girişler yaygındır ve FBI istatistiklerine göre çalınan dizüstü/masaüstü bilgisayarların %97'si asla kurtarılamaz.

• Veriler yanlışlıkla silinebilir (veya hoşnutsuz bir çalışan tarafından kasıtlı olarak silinebilir)

• Bilgisayarınız kötü amaçlı yazılımlar tarafından ele geçirilebilir

• Çevrimiçi depolama hesaplarınız saldırıya uğrayabilir

• Bir fidye önemli bir ücret ödenir kadar saldırı dosyalarınızı ulaşılmaz hale getirebilir.

​

Veri Yedekleme Rejimi Bir Zorunluluktur

​

Yeterli veri koruması için şu üç adımı takip eden bir veri yedekleme sistemi kurmanız gerekir:

​

• İş verilerini düzenli olarak yedekleyin

• Güvenilir ortamda veya bulutta yedekler oluşturun

• Yedeklemeler için medya kullanıyorsanız, cihazları güvenli, site dışında bir yerde tutun

​

İş verilerinin korunması için temel kural, verilerin kaybedilmesi iş yapmayı engelleyecekse, yedeklemesidir.

 

Gerekirse masaüstü yazılım programları yeniden yüklenebilir, ancak bu dosyalar kaybolur veya onarılamayacak şekilde hasar görürse, işlemlerin veya iş yazışmalarının ayrıntılarını kurtarmak imkansızdır. 

 

Kritik İş Verilerini Yedekleyin

​

Başarılı veri yedekleme için iki adım vardır;

​

• Yedeklenmesi gereken kritik verilerin belirlenmesi

• Verilerin yedeklerini düzenli bir programa göre uygulamak

​

Veri yedeklemesinde neler olması gerekir? Oluşturduğunuz ve/veya değiştirdiğiniz tüm dosyalar düzenli olarak yedeklenmelidir.

​

Çevrimiçi Yedekleme Hizmetleri

​

Nihai güvenlik için güçlü parolalar kullandığınızdan , bunları düzenli olarak değiştirdiğinizden ve yedeklenen dosyaların şifrelendiğinden emin olun (bulut depolama alanı paylaşıldığından, bulut sağlayıcıları normalde kullanıcı verilerini şifreler). 

​

USB Sürücüler

​

USB belleklerin kapasitesi sürekli artıyor ve hızlı veri yedeklemeleri için ideal. Harici sabit disklerin kapasitesine sahip olmasalar da, yüksek veri aktarım hızlarına sahiptirler ve oldukça taşınabilirler. Verileri kolayca bir USB sürücüsüne yedekleyebilir ve saha dışına çıkarabilirsiniz. Hareketli parçaları olmadığı için USB sürücüler çok güvenilirdir.

​

Harici sabit diskler

​

Küçük işletmeler için, veri yedeklemeleri için harici bir sabit disk satın almak ve kullanmak önerilen yöntemdir. Harici sabit sürücüler, teyp sürücü sistemlerine kıyasla ucuzdur. Ayrıca kullanımı kolaydır; sabit sürücüyü bilgisayarınızın USB bağlantı noktasına takmanız yeterlidir. Çoğu harici sabit sürücü, yedekleme yazılımıyla birlikte gelir.

​

Yerel Alan Ağı (LAN) Depolaması

​

Yerel alan ağınız (LAN: Local Area Network) varsa, dosyaları başka bir bilgisayara veya sunucuya da yedekleyebilirsiniz. Ancak, yedekleme makinesi aynı yerde bulunuyorsa, hırsızlığa açık olabilir veya yangın veya sel nedeniyle hasar görebilir. Hırsızlığı önlemek için bir sunucu kilitli bir kafese, kabine veya dolaba yerleştirilebilir.

 

Temel belgelerin bir listesi

​

İyi dokümantasyon, ürün hakkında üst düzey bir hikaye anlatır ve ekip üyelerini vizyon konusunda heyecanlandırır. “Bunu nasıl inşa etmek istiyoruz?” sorularına cevap verir. Ve daha da önemlisi, “Bunu neden inşa etmek istiyoruz?” sorusunu yanıtlar.

​

Belgeler projeden projeye değişebilse de aşağıdaki belgeler herkes için geçerli olacaktır. Bu bilgiler tek bir belgeye dahil edilebilir veya birden çok belgeye ayrılabilir. Hangi yaklaşımı seçeceğiniz projenizin karmaşıklığına bağlı olacaktır;

​

• Projeye genel bakış – Bu belge, tasarıma ve tasarım ekibinin başarmak istediği hedeflere üst düzey bir genel bakış içerir . Bu belgeyi okuyan herkes bir projenin amacını anlayabilmelidir.

​

• Ürün gereksinimleri – Bu belge, tasarımın ticari ve teknik gereksinimlerini kapsar. Her iki tür gereksinimin de karşılandığından emin olmak için tasarıma başlamadan önce paydaşlarla paylaşılmalıdır. Tasarım kararlarını etkileyeceğinden, kısıtlamalar ve varsayımlar hakkında bu belgeye bilgi eklemeye de değer.

​

• Proje çıktıları – Bu belgeler, uygulama tamamlandıktan sonra çıktılar olarak sağlanacak çerçeve oluşturma ve prototip oluşturma aşamalarını anlatır.

​

• Hedef kitle bilgileri – Bu belge, kullanıcı kişiliklerinden kullanıcı araştırmasından elde edilen verilere kadar hedef kitlenizle ilgili bilgileri listeler. Bu bilgi, ekibinizin kullanıcılarınızın kim olduğunu ve iyi tasarımın onlar için ne anlama geldiğini (işlevsel ve estetik tercihleri ​​aracılığıyla) anlamasına yardımcı olacaktır. Doküman, bireysel tasarım kararlarının ardındaki gerekçelerini paylaşırken tasarımcılar için bir referans görevi görür.

​

• Kullanıcı yolculukları – Bu belge, bir kullanıcının bir ürünü kullanırken hedeflerine ulaşmak için izleyebileceği yolu özetlemektedir.

​

• Tasarım yönergeleri – Bu belge, çözümü oluşturmak için gereken bileşenleri ve özellikleri açıklar.

​

• Stil kılavuzları – Bu belge, tasarımın stilizasyonu için bir dizi standart listeler. Stiller, renkler ve yazı tipleri bu kılavuzun temel parçalarıdır. Bu genellikle ERP olan sistemlerde kalite kontrol birimi tarafından sağlanır.

​

• Proje kapsamı ve uygulama planı – Bu belge, ekipler arası işbirliğinin rollerini ve akışını açıklar. Uygulama planı, tasarımın uygulanmasını tamamlamak için gerekli gereksinimleri belgelemektedir. Basit projeler için, uygulamayı tamamlamak için gereken adımlara ilişkin üst düzey bir genel bakış olabilir. Karmaşık projeler için, her bir adımı tamamlamak için gereken süre hakkında bilgi içeren bir proje zaman çizelgesi içerebilir.

​

• Tasarım doğrulama ve kullanıcı testi – Bu belge, ürün tasarım döngüsü sırasında yürütülecek uygulamaların yanı sıra ürünün kullanıcı ihtiyaçlarını karşıladığını doğrulamak için ürün piyasaya sürüldükten sonra atılacak adımlara genel bir bakış sağlar.

​

• Operasyonel talimatlar – Bu belge, tasarım uygulandıktan sonra genel operasyonel görevlerin nasıl gerçekleştirileceğine dair ayrıntılı talimatlar sağlar. Örneğin, bir uygulamanın yeni bir sürümünün üretim ortamında nasıl kullanıma sunulacağına ilişkin adım adım talimatlar sağlayabilir.

 

Donanım tasarım kararlarınızı nasıl belgelersiniz?

​

Tasarım aşamasında donanım kararlarınızı nasıl belgelersiniz?

 

Geçmişte yaptığınız bir donanım tasarımını gözden geçirirken kendinize şu soruları sormaktan nasıl kaçınırsınız:

​

• Neden bu bileşeni seçtiniz?

• Bu bileşen için bu belirli parametreleri neden/nasıl seçtim?

• Devrenin bu kısmı ne işe yarıyor?

• Bu bileşen aracılığıyla güç kaybı nedir?

• Bu devrenin toplam güç tüketimi nedir?

• Bu bileşeni diğeriyle değiştirebilir miyim? Bu bileşene eşdeğer bileşenler var mı? vesaire.

 

Bir devrenin tasarım aşamasında kararlarınızı ve hesaplamalarınızı belgelemenin iyi bir yolu nedir? 

​

Yüzlerce veri sayfası sayfasını tekrar gözden geçirmeden yukarıdaki soruların cevaplarını nasıl alabilirim?

​

Aklımıza gelen ilk yol, şematik dosyalara notlar eklemektir (EDA'nız destekliyorsa), ancak şemayı çok fazla bilgi ile karıştırmak istemezsiniz. Yukarıdaki soruları cevaplamaya çalışalım.

​

Donanım Detaylı Tasarım

​

Sistem için tüm donanımı doğru bir şekilde oluşturmak ve/veya tedarik etmek (veya COTS öğelerini entegre etmek) için her bir donanım bileşeni hakkında yeterli ayrıntılı bilgi sağlayın.

​

Çok sayıda bileşen varsa veya bileşen belgeleri kapsamlıysa, bunu bir eke yerleştirin.

​

Gerekirse, her bir bileşeni ve işlevlerini yeterince açıklamak için ek diyagramlar ve bilgiler ekleyin.

​

Endüstri standardı bileşen spesifikasyon uygulamaları izlenmelidir.

​

COTS bileşenleri için, belirli satıcıyı ve uygun öğe adlarını ve model numaralarını belirleyin.

​

Ayrıntılı bileşen tasarımlarına uygun olduğu şekilde aşağıdaki bilgileri dahil edin:

​

• Her bileşen için güç girişi gereksinimleri
• Sinyal empedansları ve mantık durumları
• Konektör özellikleri (seri/paralel, 11 pinli, erkek/dişi vb.)
• Bellek ve/veya depolama alanı özellikleri
• İşlemci gereksinimleri (hız ve işlevsellik)
• Donanım öğelerinin (örneğin, sunucular, G/Ç aygıtları, monitörler, yazıcılar, vb.) sayısını ve bileşenlerin birbirine göreli konumlarını gösteren grafiksel gösterim
• Kablo türleri ve uzunlukları
• Kullanıcı arayüzleri (düğmeler, geçiş anahtarları vb.)
• Sabit sürücü/CD-ROM özellikleri
• Monitör çözünürlüğü

 

Harici Arayüzler

​

Diğer sistemlerin veya başka bir varlık tarafından yönetilip yönetilmediğine bakılmaksızın, tasarlanmakta olan sistemin kapsamında olmayan harici sistemlerle var olan arayüzleri tanımlayın.

​

Tasarlanan sistem ile diğer sistemlerin ve/veya alt sistem(ler)in her biri arasındaki elektronik arayüz(ler)i, tasarlanmakta olan sistemin bakış açısını vurgulayarak tanımlayın. Bir veya ikiden fazla harici sistem varsa veya arayüzler basit değilse, bir veya daha fazla ayrı Arayüz Kontrol Dokümanı hazırlanmalı ve burada referans gösterilmelidir.

​

Varsa, kaç tane Arayüz Kontrol Belgesi bulunduğunu ve bunların ne olduğunu belirleyin.

​

Arabirim Mimarisi

 

Geliştirilen sistem ile diğer sistemler (örneğin, toplu aktarımlar, sorgular vb.) arasındaki arayüzleri(ler) arayüzleri açıklayın ve arayüz sisteminin konumunu belirtin.

 

Uygulanan arabirim mimarilerini (örneğin, geniş alan ağları, ağ geçitleri vb.) ve arayüz mekanizmalarını vb.) dahil edin.

 

Uzaktan bağlantı gerekiyorsa, erişim yöntemini tanımlayın.

 

Bu sistemle diğer sistemlerin her biri arasındaki iletişim yollarını gösteren ve Sisteme Genel Bakış Bölümünde sağlanan bağlam diyagramlarıyla eşlenen bir diyagram sağlayın.

 

Grafiksel gösterim, veri akışının yönünü gösteren sistemler arasındaki bağlantıyı göstermelidir. Her arabirimi bağımsız olarak ele almak için alt değerlendirmeleri veya ayrı bir Arayüz Kontrol Belgesi' ni kullanın.

​

Donanım tasarımında pratik yaklaşımlar

 

Ben şahsen eski moda bir yol izliyorum:

​

Verdiğim tasarım kararları hakkında kesinlikle her şeyi yazdığım bir tasarım defterim var. Özellikle bileşen ve değer seçimleri, akım hesaplamaları, güç kaynağı hesaplamaları, her şey. Ayrıca yazılım/ürün yazılımı kararlarını ve zamanlama ve kaynak kullanımına ilişkin notları da belgeliyorum.

​

Her tasarımımda, tasarımın belirli bir bölümüne (güç kaynağı, vb.) atıfta bulunmak için bir içindekiler sayfası bulunur ve tüm sayfalar numaralandırılmıştır.

​

Birkaç kez dijitale geçmeyi düşündüm ama çalışırken defterimin önümde olması güzel ve formülleri dijital olarak yazmayı oldukça garip buluyorum. Hesaplamaları elle yazmak çok daha kolaydır.

​

Bir PCB kart tasarımı için bir spesifikasyon veya resmi belge hazırlarken, genellikle yaptıklarımı tazelemek için defterime geri dönerim (veya aynı zamanda dijital belgeleri de yazarım). Bu, aynı şeyi iki kez yapıyormuşum gibi görünse de defterlerimin neredeyse tamamen kendim için hesaplama ve açıklama olduğunu, belgelerin başkaları için çok daha az ayrıntılı ve çok daha resmi ve açıklayıcı olduğunu görüyorum. Bu nedenle, aynı şeyi iki kez yazdığımı pek sık görmüyorum.

 

Diğer bir yaklaşım-2:

 

Genelde yaptığımız şey, pazarlama gereksinimleriyle başlamaktır, sonra belki resmi bir mühendislik yanıtı veya sadece resmi olmayan bir tartışma. Bunu, pazarlama gereksinimleri belgesi takip eder. Buna gereksinimler, rekabet analizi, pazar büyüklüğü, fırsat, tahmini geliştirme maliyeti vb. dahildir. Bu genellikle bir pazarlama görevlisi tarafından yazılır.

 

Bunu, genellikle mühendislik tarafından, yine bir word şablonunda yazılan PRD (ürün gereksinimleri belgesi) takip eder. Bu, ürünün ne yapacağını, hangi parçaların gerekli olduğunu ve her birinin nasıl işlev göreceğini daha teknik bir şekilde açıklar. Genellikle buraya hedef performans, fiyat, güç, boyut ve diğer metrikleri dahil edeceğiz.

​

Bunu, bölümlerin her biri için ayrıntılı işlevsel özellikler takip eder. Bazı tasarım çalışmaları aslında şematik haline getirilmeden önce burada yapılır. Örneğin güç hesaplanacak, parçalar seçilecek ve birçok araştırma yapılacak. Açık olmayan tasarım kararlarını belgeleyeceğimiz yer burasıdır.

​

Son olarak, bu noktada kolay olan şemalara geçeceğiz çünkü spesifikasyon aşamasında çok fazla zor tasarım çalışması yapıldı. Bence nerede yapılmalı :) Şematik aşamada bir şey değişirse, örneğin bir şeyin çalışmayacağını anlarsak veya bir pazarlamacı koşarak koridordan mavi yerine kırmızı olması gerektiğini söyleyerek koridordan gelir, o zaman biz geri dönecek ve özellikleri güncelleyecektir.

​

Bir tasarımla ilgili verilen her küçük kararı belgelemek isteyebileceğinizi düşünüyorum ve bunu kesinlikle yapmıyoruz. Yapmamanız gerektiğini söylemiyorum, nerede yararlı olacağını görmek gerektiğini söylüyorum. Sanırım her zaman neden değil, nasıl olduğunu belgeliyoruz.

 

Diğer bir yaklaşım-3:

 

Hesaplar yapıyorsanız, belki excel'de? Veya kağıt üzerinde ve sonuçların ve yöntemin devrenizin anlaşılması ve tasarımı için önemli olduğunu düşünüyorsanız, bunları tasarım spesifikasyonunun uygun bölümüne eklemelisiniz. Bu, el çiziminizin fotoğrafını çekmek anlamına gelse bile :)

​

Neden bu bileşeni seçtiniz? İşlevsel özelliklerin bunun için iyi bir yer olduğunu düşünüyorum, delirmeye gerek yok, avantajlarının ne olduğu hakkında sadece birkaç basit satır. Bunu kritik bileşenler için ayırırdım, örneğin neden bir çekme direnci seçtiğinizi açıklamak istediğinizi sanmıyorum.

​

Bu bileşen için bu belirli parametreleri neden/nasıl seçtim? Bunu yukarıdakiyle birleştirin.

​

Devrenin bu kısmı ne işe yarıyor? Bu, işlevsel özelliğinizin bir parçası olacaktır, eğer devre bu soruyu garanti edecek kadar önemliyse, spesifikasyonun kendi bölümüne sahip olmalıdır.

​

Bu bileşen aracılığıyla güç kaybı nedir? Güç kaynağından bahsediyorsanız, bunu güç bölümüne koyun, bunu şemalara da not etmeyi seviyorum. Aslında tüm parçalarım bir veri tabanından geliyor ve şema doğrudan bunlarla bağlantılı, böylece parametreleri, veri sayfasını vb. kolayca görebiliyoruz. Ancak sadece bir çıktınız varsa, bunlardan bazılarını bilmek güzel.

​

Bu devrenin toplam güç tüketimi nedir? Bunun, spesifikasyonunuzun güç kaynağı bölümüne ait olduğunu düşünüyorum.

​

Bu bileşeni diğeriyle değiştirebilir miyim? Bu bileşene eşdeğer bileşenler var mı? vb. Bu, ürün reçetenize veya üretim için kullandığınız herhangi bir işleme ait olduğunu düşünüyorum. Alternatif parçalar, kaynak bulmayı kolaylaştırmak içindir. Yine bizim için bunların hepsi bir parça veritabanından çıkıyor.

 

Diğer bir yaklaşım-4:

​

Çok fazla hızlı dönüş tasarımı yapıyorum ve şunu söylemeliyim: şemaya açıklama eklemek açık ara en uygun şey. Tasarımlarımdan herhangi birinin 2 veya 3 adet A4 sayfadan fazla olması nadirdir, bu nedenle tasarım kararlarının miktarı sınırlıdır.

 

Pek çok tasarım kararı hemen hemen otomatiktir; Her bölümün nedenlerini sıralamama gerek yok. Sadece bir veya iki ana parça ve belki bir miktar filtre veya pasif boyutlandırma. Gerisi, herhangi bir deneyimli tasarım mühendisi için hemen açıktır.

​

Tasarım bilgilerine sahip çok sayıda ayrı dosyaya sahip olmak (ayrı sistem tasarımı, tasarım karar belgeleri, kaynak belgeleri, tümü temel şematik ve yerleşim dosyalarınızdan ayrı) çok fazla (zihinsel) karışıklığa neden olur ve bir tasarımı her gözden geçirmek istediğinizde bağlam değiştirmeyi gerektirir.

 

Her şeyin tek bir yerde olması iyi sonuç verir. Şemanız dağınık görünmeye başlarsa, bu iş akışıyla ilgili bir sorun değil, daha ziyade tasarımınızı daha iyi bölümlere ayırmanız, daha fazla sayfa kullanmanız veya daha büyük sayfalar kullanmanız gerektiği anlamına gelir.

​

Diğer bir yaklaşım-5:

​

Küçük projelerimin çoğu için, genellikle alt devrelerin etrafına basit bir yeşil etiket ve kenarlık yerleştiriyorum. Daha büyük projeler için, bazı eCAD yazılımları, her sayfanın tek bir bloğu daha ayrıntılı olarak tanımladığı bir hiyerarşik blok diyagramdan aşağıya doğru oluşturmanıza izin verir.

 

Herhangi bir sorunu ayrıştırmak ve takasları yönetmek için bir sanat var. Analog filtreleme gibi bileşenlerin seçimi için açıkça bazı analizlerin olduğu durumlarda, kesme frekansını ve filtre türünü not edeceğim (örn. Düşük Geçişli Filtre (fc = 100Hz))

​

Zaman zaman karşılaştığım ortak bloklar şunları içerir:

​

• Güç Yönetimi (voltaj regülatörleri, ters polarite koruması, TVS diyotları, güç anahtarı, baypas kapasitörleri vb.)

• MCU (mikrodenetleyici, programlama başlığı veya pedleri, çip baypas kapasitörleri)

• Göstergeler (örn. LED'ler, EL kablosu, 7 segmentli ekran, DC motor)

• Belirli bir özellik için algılama (örn. Akım Algılama, Dokunma Algılama, Etkinlik, Çevre Algılama, vb.)

• Hata Ayıklama İletişimleri (ferrit boncuk, USB, I2C, UART, SPI, bilgi almanın herhangi bir yolu)

• Radyo (birçok radyo için tüm destek bileşenleri)

• Video (bir kamera için tüm destek bileşenleri ve çipler)

• Harici Depolama (örn. Harici Flash, ayarları saklamak için EEPROM çipi vb.)

• Tasarımınıza özgü diğer herhangi bir özellik

​

Açıkça organize edilmiş ve etiketlenmiş bu alt hiyerarşik bloklarla, bir şemayı genellikle birkaç dakikadan daha kısa sürede tasarlayabilir ve dokümante edebilirsiniz.

 

Diğer bir yaklaşım-6:

​

Mühendislik notlarını şemalara yerleştirin ve gerekirse daha fazla sayfa oluşturun. Her zaman tüm şemalarıma mühendislik notları koyarım çünkü benim dünyamda bir süreliğine yarım pişmiş tasarımları tekrar ziyaret etmem ve sonra başka bir tasarım alırken onu tekrar arka plana koymam gerekebilir.

 

Çok akıcı tasarım akışı mutlak gerekliliktir. Bu notlar, benim ve diğer ekip üyelerinin tasarım amacını çok az çabayla yeniden benimsemelerine yardımcı oluyor. Ayrıca önemi veya bağlamı belirtmek için farklı metin/grafik renkleri kullanırım.

​

Ayrıca eski devre kartlarının veya devre kartlarının fotoğraflarını ve tasarım seçimlerini yapmak için kullandığım makalelerin bağlantılarını da ekleyebilirim. Bu konuda yeterince titiz olursam her tasarım değişikliğini (donanım, yazılım, mekanik) ihtiyaca göre takip edebilirim.

​

Sistemin dağıtılmış mı yoksa merkezileştirilmiş mi olduğunu gösteren genel sistem donanımını ve organizasyonunu blok diyagramla ve açıklayarak tanımlayın.

​

MCU ve herhangi bir çevresel aygıt (örneğin, yük dengeleyiciler, SSL hızlandırıcı, anahtarlar, güvenlik duvarları, her öğenin kısa bir açıklaması ve bağlantıyı gösteren diyagramlar ile birlikte) dahil olmak üzere tüm donanım bileşenlerinin türünü, sayısını ve konumunu belirleyin.

​

Gerekli güvenlik duvarları(izolasyon vb.), bağlantı noktaları ve kullanılan ağ bantları (örneğin, DATA BUS) ile birlikte bileşenler arasında İşlemci kapasitesi, bellek, çevrimiçi depolama ve yardımcı depolama için kaynak tahminlerinizi dahil edin.

 

Etki ve Sonuçlar

​

Verimlilik ve amaca uygunluk açısından, bir Ar-Ge proje ekibi işin kapsamına odaklanmalı ve teğet konularla dikkatin dağılmasından kaçınmalıdır.

​

İyi bir proje yöneticisi, ekibi odaklanmış ve tamamlanma yolunda tutacaktır. Ancak Ar-Ge projesi yürütülürken, başlangıçta çalışma kapsamında olmayan birçok husus ortaya çıkacaktır.

​

Birçoğu gerçekten önemsiz olacak, ancak diğerleri göz ardı edilemeyecek bir önem taşıyacak. Ar-Ge ekibindeki her kişi, yarattıkları iş ürünlerinin etkisinin ve sonuçlarının tam olarak farkında olmak için profesyonel ve etik bir sorumluluğa sahiptir. Bu şekilde sorumlu olmak, işin kapsamının ötesine bakmak ve projeye ve hem olumlu hem de olumsuz uzun vadeli etkilerine daha geniş bir açıdan bakmak anlamına gelir.

Mühendisler geleceği tasarlayarak kontrol eder ve bu güçle birlikte bilinçli muhakeme yürütme sorumluluğu gelir.

​

Herhangi bir proje için tasarım zarfı sonsuz sayıda çözüm sunar ve bu zarf içinde yapılan seçimler sadece ürünün ve belki de şirketin performansını değil, aynı zamanda çalışanları, yerel ekonomiyi hem yerel hem de küresel çevreyi etkiler. Ve projeye en dolaylı yollarla bile bağlanabilecek herkesin sağlığı, güvenliği ve refahı.

 Örneğin, şirket kârlarını optimize etmek için maliyeti kesinlikle en aza indiren bir tasarım seçilebilir. Ancak, maliyeti biraz daha yüksek olan ancak üretim atıkları ürünlerinin neden olduğu çevresel etkiyi önemli ölçüde azaltan bir tasarım da seçilebilir. Bu seçim ve buna benzer sayısız seçim, bu kararları vermek için bilinçli muhakeme yapmak zorunda olan tasarım mühendislerinin elindedir.

​

Profesyonel ve etik sorumluluklar, bu karar verme sürecinin bir kısmını belirleyecektir, ancak bu kararların altında yatan temel, her tasarım seçiminin etkisi ve sonuçlarına ilişkin geniş bir farkındalığa dayanmaktadır.

​

Her Ar-Ge projesi, hem yerel olarak ürün tasarım döngüsüne ve kurumsal iş planlarına hem de küresel olarak daha geniş çevresel, ekonomik ve toplumsal bağlamlardaki hususlara etkisi ve sonuçları hakkında bir açıklama sağlamalıdır.

​

Kişisel olarak sahip olunan bir inancı bir başkası lehine yaymak gerekli veya arzu edilmez, bunun yerine Ar-Ge projesinin mesleki ve etik sorumlulukların dikkate alınmasını içeren yönlerini belirlemek, ve bu bağlamlarda proje çıktılarının etkisini ve sonuçlarını açıklamak.

Ar-Ge sürecinde gerekli özenin gösterilmesi ve belgelenmesi meselesidir.

 

Sonuç ve Öneriler

​

Bu, kaynak soruya geri dönmenin ana noktasıdır. Yani; bu Ar-Ge çalışmasının amacı neydi? Ar-Ge çalışması, onu harekete geçiren soruyu yanıtladı mı? Nadiren bunun cevabı basit bir evet veya hayırdır. Daha yaygın olarak, Ar-Ge çalışması, çözmek için ek çalışma gerektirebilecek yeni soruları ortaya çıkardı.

​

Sonuçlar ve öneriler bölümü, beklenmeyen sonuçların ve bunların Ar-Ge çalışmasından sonra gelecek teknik ve ticari kararlar üzerindeki etkisinin tartışılacağı yerdir.

​

Başarılı bir Ar-Ge çalışması, normal olarak, yeni ürün için daha başarılı bir iş planı oluşturmak için kullanılabilecek performans, özellikler, maliyet ve tüketici gereksinimlerindeki ödünleşimleri ortaya çıkarır.

​

En iyi Ar-Ge raporları, bu ödünleşimleri gelecekteki iş modellerinde kullanılabilecek sayılarla nicelleştirir.

 

Sonuç oluştururken yapılan en yaygın hata, yalnızca projenin bir özetini sunmaktır. Bir özet, bir özet bölümüne veya özete aittir ve sonuçlar için istenenleri ele almaz. Sonuçlar, deneysel sonuçların kapsamlı bir incelemesine dayanan tümdengelimli akıl yürütmenin sonucudur. Sonuçlar, Ar-Ge çabasını harekete geçiren daha derin soruları yanıtlamaya çalışmalıdır. Bu sonuçlar daha sonra ileriye giden yolda atılacak sonraki adımlarda mantıklı önerilere yol açmalıdır.

​

Ürün geliştirme döngüsünü ileriye doğru yönlendiren, geriye dönük mükemmel özetler değil, ileriye dönük, anlayışlı önerilerdir.

​

Ar-Ge çalışması pahalıdır ve çabanın sonuçları, onu finanse eden şirkete önemli değer katmalıdır. Sonuçlarda ve önerilerde değerin göründüğünden emin olun.

 

Referanslar, Onaylar ve Fikri Mülkiyet

​

İyi bir Ar-Ge raporu, ekip tarafından kullanılan tüm referanslara atıfta bulunur. Bunlar, dergilerden yayınlanmış makaleleri, üreticinin veri sayfalarını ve uygulama notlarını, geçerli standartların kopyalarını ve düzenleyici kurumlardan gelen tüm uyumluluk gerekliliklerini içerir.

​

Başka herhangi bir ilham kaynağı da buraya dahil edilebilir. Günümüz verilerinin çoğu internetten geldiğinden, uygulanabilir web köprüleri dahil edilmelidir.

​

Bu bölümde, tasarımın fikri mülkiyetinin hangi bölümlerinin patent, telif hakkı, ticari marka veya ticari sır ile korunması amaçlandığı da detaylandırılmalıdır.

​

Yeni tasarımlar, patent ihlalinden kaçınmak için dikkatli olmalıdır. Tasarımın üretilmesi için belirli bir telif hakkı patenti lisanslanıyorsa, bunun taraflar arasında imzalanan sözleşmeye atıfta bulunularak not edilmesi gerekir.

​

Fikri mülkiyet sahipliği ve ihlali zorlu bir konudur ve en iyi hazırlık, iddia edilenleri destekleyici belgelere dayanarak açıkça ortaya koymaktır. Patent başvuru numaralarını ve geçici patent numaralarını burada belirtmek çok faydalıdır.

​