Teknik şartname nasıl hazırlanır? Her sayfada ne olacağını açıklayın. Teknik şartname fiyatını dolduruyoruz

Yazardan: Nasıl yazılır web sitesi geliştirme için görev tanımı (TOR)? Konu oldukça kapsamlı ve tek bir not çerçevesinde (mümkünse) %100 analiz etmek zor. Ancak bir web sitesinin kullanım koşullarını hazırlarken nelere dikkat edilmesi ve nelere dikkat edilmesi gerektiğine ilişkin genel hükümleri yeterince detaylı bir şekilde özetlemeye çalışacağım.

Yani, web sitesi geliştirme için teknik özellikler

Teknik şartname geliştirici için hazırlanır. Müşteri ile yüklenici arasında bir anlaşma hazırlanırken görev tanımına atıfta bulunulmalıdır. Her iki tarafın da puanları ve son teslim tarihlerini yerine getirmemesi veya yanlış yerine getirmesi sorumluluğu belirlenmelidir. Ancak teknik şartnamelerin oluşturulduğu en önemli şey (bence) proje geliştirme sürecini hızlandırmak.

Bu örneği analiz edelim:

Web sitenizin yan tarafında bir yerde bir takvime ihtiyacınız olduğunu varsayalım. Küçük bir şeymiş gibi görünüyordu. Ancak işlevselliğini ne kadar ayrıntılı açıklarsanız, sonucu o kadar hızlı alırsınız.

Burada biraz açıklayayım. İçinde bulunulan ayın haftasının gününe göre sayıları gösteren bir takvim var. Ve aylar arasında geçiş yapma yeteneği var. Aylar ve yıllar arasında geçiş yapma yeteneğine sahip bir takvim var.

Diyelim ki, geçerli tarihin vurgulandığı ikinci seçeneği (aylar ve yıllar arasında gezinme olanağı sunan) istediğinizi varsayalım. Belirttiğiniz referans şartlarında: "kenar çubuğunda bir takvime ihtiyaç var." Size ilk seçeneği veriyorlar (sadece geçerli ayın haftasının gününe göre sayıları gösteriyor).

Neyimiz var. Yüklenici şartnameyi yerine getirdi, ancak siz tamamen farklı bir şey istediniz. Her şey yolunda görünüyor, suçlanacak kimse yok, çatışma yok ama en önemli şey kayboluyor zaman ve para.

Bu sadece sıradan bir takvim örneğidir.

Peki ya takvimde olduğu gibi işlenmesi yarım günden fazla süren daha ciddi bir şeyi yeniden yapmak zorunda kalırsanız? Yüklenici projenizi bitirip yeni bir projeye başlayabilecekken sizinle meşgul.

Bu nedenle, daha daha fazla detay Her modülün işlevselliğini anlatırsanız sonuca o kadar hızlı ulaşırsınız. Her iki tarafın da bununla ilgilenmesi gerekiyor.

Teknik şartname genellikle hangi noktalardan oluşur?

Bir şirketin veya firmanın sahibi olduğunuzu düşünelim. Firmanız her türlü ürünün üretimi ve satışı ile uğraşmaktadır. Alıcılarınız var. Satıcılarla (mağazalar ve çevrimiçi mağazalar), hizmet merkezleriyle ve ürün tüketicileriyle işbirliği yaparsınız. Veya böyle bir firmaya kaynak yapıyorsunuz ve teknik şartname yazmanız gerekiyor.

Hangi rolü oynarsanız oynayın, taslak hazırlamadan önce yapmanız gereken ilk şey başvuru şartları Bir web sitesi tasarımı oluşturmak, kuruluşun yapısını, ne yaptığını, isimlendirmesini, özelliklerini ve genel olarak ürün ve şirketle bağlantılı her şeyi incelemektir. Kaynağa ne olacağı, müşterinin işletmede olup bitenlerin özünü ne kadar derinlemesine anladığına bağlıdır. Bu nedenle buradaki görev karşılıklıdır: Müşteri işletmeyi mümkün olduğunca ayrıntılı olarak anlatmalı ve yüklenici olup bitenlerin özünü iyice anlamalıdır.

Projenizi yapacak şirket için teknik şartnameyi kendiniz yazıyor olsanız bile, hepsini bir kağıt parçası üzerinde çözmek iyi bir fikirdir.

Nokta nokta gidelim.

Tanım

Buraya şirket ve ne yaptığı hakkında birkaç cümle yazabilirsiniz. Giriş gibi bir şey yapın.

kimin için - hedef kitle:

Potansiyel Alıcılar

ürün satıcıları (mağazalar, çevrimiçi mağazalar)

servis merkezleri

ortaklar (firmalar)

Ürünlerin tüketicileri (zaten satın almış olanlar)

Neden bir web sitesine ihtiyacınız var:

Şirketin imajını iyileştirmek için

Satışları artırmak için

Müşteri rahatlığı için

Kurumsal

Web sitesi – kartvizit

Online mağaza

Dil versiyonları:

İngilizce

Sitenin bazı sorunları çözmesi gerekiyor. Buna göre amaç ve hedeflere doğru ilerliyoruz.

Amaçlar ve hedefler

Teknik şartnamenin bu bölümünde hedef kitlenin tamamını inceliyor ve sitenin onlar için çözmesi gereken görev yelpazesini açıklıyoruz.

Potansiyel ürün alıcıları.

Hedef: daha fazla alıcı çekin ve onları ilk satın almalarını yapmaya ikna edin, seçim yapmalarına yardımcı olun.

Sorunların çözülmesi gerekiyor:

Ürünler hakkında kaliteli, kapsamlı bilgi sağlamak, ek hizmetler, garantiler, servis, seçim yöntemleri.

Showroomlar hakkında bilgi verin

Perakende ağı hakkında bilgi sağlayın

Ürün seçme ve satın alma konularında şirket uzmanları tarafından potansiyel alıcılara çevrimiçi danışmanlık düzenleyerek soru sorma fırsatı sağlayın.

Böylece hedef kitlenin tamamının üzerinden geçiyoruz. Ayrıca ürün satıcıları (mağazalar, çevrimiçi mağazalar), hizmet merkezleri, ortaklar (firmalar) ve ürün tüketicileri için amaç ve hedefleri de açıklıyoruz. Yani sitenin her biri için özel olarak yapması gereken şey.

Şimdi modülleri listeliyoruz.

Site işlevselliği

İşlevselliği listelemek için neye ihtiyacı olduğuna karar vermeniz gerekir:

Kayıt gerekli mi?

Kapalı bir bölüme ihtiyacım var mı (sadece kayıtlı kullanıcılar için)

Bir form gerekli mi? geri bildirim

Vesaire. ve benzeri.

Web geliştirmede modern eğilimler ve yaklaşımlar

Web sitesi oluşturmada sıfırdan hızlı büyüme algoritmasını öğrenin

Bütün bunları anlattıktan sonra en önemli ve ilginç şeye geliyoruz. Elbette yukarıda yapılan tüm çalışmalar çok önemli ama artık durum daha da kızışıyor.

İşlevselliğin açıklaması

Açık şu an sitenin kimin için olduğunu, hangi amaç ve hedefleri yerine getirmesi gerektiğini, ek özelliklerini biliyoruz işlevsellik.

Toplanan tüm bilgileri sisteme getirip güzelce düzenlemeniz gereken zaman geldi. Görevi kolaylaştırmak ve tekerleği yeniden icat etmemek için benzer konulardaki kaynaklara bakabilirsiniz. Onlardan bir şeyler alın, işlevlerine bakın ve deneyin ve uygunsuz görünen şeyleri projenizde geliştirmeye çalışın. Prensip olarak, teknik şartnamelerin hazırlanmasının en başında benzer konulardaki sitelere bakabilirsiniz (ve deneyiminiz yoksa, o zaman buna ihtiyacınız bile vardır).

Menü öğeleriyle başlamanızı öneririm. Ana sayfaları görüntülemesi ve her ziyaretçinin kendisi için hızlı bir şekilde bilgi bulmasını sağlaması gerekiyor. Ve ziyaretçiler bizimdir hedef seyirci kitlesi. Menü birçok öğeyi içerecek, dolayısıyla açılır liste biçiminde olacaktır.

Öncelikle bize firmadan bahsetmeniz gerekiyor. Şirketle ilgili sayfalar, şirket geçmişi, kişiler, incelemeler olabilir.

Doğal olarak, "ürün kataloğu", "sürümler", "ürün incelemeleri" alt öğeleriyle birlikte bir "ürünler" menü öğesi bulunmalıdır.

Genel olarak, umarım nasıl tanımlanacağı açıktır. Olası menünün son halini sunayım:

Şirket hakkında

şirketin geçmişi

kişiler

ürünler

Ürün kataloğu

ürün incelemeleri

servis bölümü

Garanti hizmeti

garanti sonrası servis

tüketiciye

satın alma ve teslimat

kullanmak

hizmet hakkında

mağazalar ve çevrimiçi mağazalar

ürün fotoğrafları

SSS

servis merkezleri

Nasıl olunur servis Merkezi

SSS

ortaklar

işbirliğine davet

SSS

Menüyü halletmiş gibiyiz. Şimdi her sayfada ne olacağını ve her şeyin nasıl çalıştığını açıklamanız gerekiyor. Ayrıca yaklaşık bir düzen sağlayın. Bir kağıda kurşun kalemle çizilebilir, taranabilir ve teknik şartnameye eklenebilir. Söyleyeceğim tek şey tasarımcının hayal gücünü sınırlamayın, kendiniz çizin Genel görünüm.

Bu kısım sayfanızın nasıl görünmesini istediğinize bağlı olarak değişir. Belki üstte bu kadar banner'a ihtiyacınız yok, belki de kişileri (adres, telefon, faks) üstte belirtmeniz gerekiyor, belki "site haritası", "ev", "kişiler" simgeleri şeklinde. Belki sol tarafta haberlere ihtiyacınız yok ama sol tarafta “promosyonlar ve yeni çıkanlar”ı göstermelisiniz.

Şimdi asıl mesele işin mantığını anlatmak.

Çalışma mantığı

Yukarıdaki resme dayanarak anlatacağım.

Üst kısmı(başlık) her sayfada aynı kalır. Haber akışı yalnızca şu adreste görülebilir: ana sayfa. Soldaki ikincil sayfalarda o anda içinde bulunduğumuz ürünün menü alt öğelerini gösteriyoruz (örneğin, “müşteri hizmetleri” sayfasındaysak “garanti servisi”, “garanti sonrası servis” bağlantılarını gösteriyoruz) ”). Buna göre, bu bağlantılara tıklamak ilgili sayfalara yönlendirir. Burada soldaki alt öğeler altında çevrimiçi danışmanlarla (Skype, ICQ) iletişim kurmaya yönelik verileri görüntülüyoruz. Promosyonlar ve sürümler bloğu her sayfada kalır. Altbilgi her sayfada aynı şekilde görüntülenir.

İşin genel mantığı kabaca bu şekilde anlatılıyor.

Şimdi, web sitesi geliştirme referans şartlarımızda, sitenin belirlenen her bloğunu ayrıntılı olarak açıklıyoruz. Örneğin, “Haber Kaynağı”.

10 üzerinden "Haber akışı" son Haberler. Her haber; haber başlığı, yayın tarihi, haberin kısa bir başlangıcı (4-5 satır) ve “tamamını oku” bağlantısından oluşmalıdır. “Tamamını oku” linkine tıkladığınızda haber sayfasına yönlendirileceksiniz. Karşılaştığınız haberler ana içeriğin yerine görüntülenir. Ayrıca haberin başlığı ve yayınlanma tarihi de yer alır. Ayrıca solda da görüntülenir haber akışı. Geçmiş aylara ve yıllara ait haberler arşivlenir. Yani haberin altında içinde bulunduğumuz ay“(şu ve şu ay veya yıl) arşivini” görüntüle. “(Şu ay veya yıla ait) arşivle” linkine tıkladığınızda ilgili aya/yılın haber listesi açılır.

Her bloğun işleyişini bu şekilde açıklıyoruz. Takvim olayını unutmayalım. Ve en önemlisi ürün kataloğunun çalışmasını anlatmanız gerekiyor. Burada size bir görev veriyorum: Kataloğun nasıl çalışacağını iyice düşünmeye ve açıklamaya çalışın. Seçeneklerinizi e-postayla gönderin. En iyisini yayınlayacağız.

Başka ne olmalı? Uyumluluğu belirtmek güzel olurdu.

Uyumluluk

Bir web sitesi oluşturmaya ilişkin görev tanımımızın bu paragrafında, işletim sistemleri ve web sitesinin hangi tarayıcılarda eşit derecede iyi görünmesi gerektiği. Hangi versiyonda, hangi dilde yazılmalıdır. Hangi CMS'nin kullanıldığı. Eğer gerçekten neden bahsettiğinizi biliyorsanız, bunu belirtmekte fayda var.

Bu soruları bilmiyorsanız sitenin doğru görüntülenmesi gereken tarayıcıları belirtmeniz yeterlidir. Geri kalanı için sanatçının vicdanına güvenin.

Çözüm

Bu yazımda teknik şartnamelerin bu şekilde derlendiğini ve başka bir şekilde olmadığını göstermeye çalışmadım. Bunu yapın ve hiçbir sorun olmayacak. Niteliksel bir kompozisyon oluşturun web sitesi geliştirme için referans şartları- bu daha çok bir soru deneyim. İlk birkaç yılda herkes yetkin bir teknik şartname oluşturamayacaktır.

Bu yazıda bir web sitesinin tasarımını ve mantığını geliştirmeye yönelik örnek bir teknik şartnamenin oluşturulduğu örnek ve ilkelerin yanı sıra dikkat edilmesi gereken ana noktaları göstermek istedim. Ne kadar başarılı olduğumu umarım yorumlarınızdan öğrenebilirim.

Ve görevi unutma!

G O S U D A R S T V E N Y S ST A N D A R T S O Y W A S S R

SSCB Devlet Standartlar Komitesi'nin 18 Aralık 1978 tarih ve 3351 sayılı Kararı ile giriş tarihi belirlendi

01.01'den itibaren. 1980

Bu standart, bir programın veya yazılım ürününün geliştirilmesine yönelik teknik özelliklerin oluşturulması ve hazırlanmasına yönelik prosedürü kapsar. bilgisayarlar amaç ve kapsamlarına bakılmaksızın kompleksler ve sistemler.

Standart, ST SEV 1627-79'a tamamen uygundur.

1. GENEL HÜKÜMLER

1.1. Görev tanımı GOST 19.106-78'e uygun olarak GOST 2.301-68'e uygun 11 ve 12 numaralı formatlarda, kural olarak sayfanın alanları doldurulmadan hazırlanır. Sayfa (sayfa) numaraları, sayfanın üst kısmına, metnin üstüne yerleştirilir.

1.2. Onay sayfası ve Giriş sayfası GOST 19.104-78'e uygun olarak hazırlanmıştır.

Bilgi kısmı (açıklama ve içerik), değişiklik kayıt sayfası belgede yer alamaz.

1.3. Bir programın veya yazılım ürününün geliştirilmesinin sonraki aşamalarında teknik özelliklerde değişiklik veya ekleme yapmak için ona bir ekleme yayınlanır. Teknik şartnamelere yapılacak ilavelerin koordinasyonu ve onayı, teknik şartnamede belirlenen yöntemle aynı şekilde gerçekleştirilir.

1.4. Görev tanımı aşağıdaki bölümleri içermelidir:

• giriiş;
• gelişme nedenleri;
• geliştirmenin amacı;
• bir program veya yazılım ürününe ilişkin gereksinimler;
• program dokümantasyonu için gereksinimler;
• teknik ve ekonomik göstergeler;
• gelişim aşamaları ve aşamaları;
• kontrol ve kabul prosedürü;
• Başvurular teknik şartnamede yer alabilir.

Programın veya yazılım ürününün özelliklerine bağlı olarak bölümlerin içeriğini netleştirmek, yeni bölümler eklemek veya tek tek bölümleri birleştirmek mümkündür.

2.1. “Giriş” bölümünde adı belirtin, kısa açıklama programın veya yazılım ürününün uygulama kapsamı ve programın veya yazılım ürününün kullanıldığı nesne.

(Değişik baskı, Değişiklik No. 1)

2.2. “Geliştirmenin temeli” bölümü şunları belirtmelidir:

• geliştirmenin gerçekleştirildiği belge(ler);
• bu belgeyi onaylayan kuruluş ve onay tarihi;
• isim ve (veya) sembol geliştirme konuları.

(Değişik baskı, Değişiklik No. 1)

2.3. "Geliştirmenin amacı" bölümü, programın veya yazılım ürününün işlevsel ve operasyonel amacını belirtmelidir.

2.4. “Bir program veya yazılım ürünü için gereksinimler” bölümü aşağıdaki alt bölümleri içermelidir:

• fonksiyonel özellikler için gereksinimler;
• güvenilirlik gereksinimleri;
• kullanım Şartları;
• teknik araçların bileşimi ve parametreleri için gereklilikler;
• bilgi ve yazılım uyumluluğuna ilişkin gereksinimler;
• etiketleme ve paketleme gereklilikleri;
• taşıma ve depolama gereksinimleri;
• özel gereksinimler.

(Değişik baskı, Değişiklik No. 1)

2.4.1. “İşlevsel özellikler için gereklilikler” alt bölümü, gerçekleştirilen işlevlerin bileşimi, girdi ve çıktı verilerinin organizasyonu, zamanlama özellikleri vb. ile ilgili gereklilikleri belirtmelidir.

2.4.2. “Güvenilirlik Gereksinimleri” alt bölümü, güvenilir çalışmayı sağlamak için gereklilikleri belirtmelidir (kararlı çalışmayı sağlamak, giriş ve çıkış bilgilerini izlemek, bir arızadan sonra kurtarma süresi vb.).

2.4.3. “Çalışma koşulları” alt bölümü, belirtilen özelliklerin sağlanması gereken çalışma koşullarını (seçilen depolama ortamı türleri için ortam sıcaklığı, bağıl nem vb.) ve ayrıca hizmet türünü, gerekli sayı ve nitelikleri belirtmelidir. personel.

2.4.4. “Teknik araçların bileşimi ve parametreleri için gereklilikler” alt bölümünde, teknik araçların gerekli bileşimi, ana teknik özelliklerini belirterek belirtilmiştir.

2.4.5. “Bilgi ve yazılım uyumluluğu için gereklilikler” alt bölümü, aşağıdakiler için gereklilikleri belirtmelidir: bilgi yapıları Giriş ve çıkışlarda ve çözüm yöntemlerinde, kaynak kodları, programlama dilleri ve yazılım program tarafından kullanılır.

Gerektiğinde bilgi ve programların korunması sağlanmalıdır.

(Değişik baskı, Değişiklik No. 1)

2.4.6. “İşaretleme ve paketleme gereksinimleri” alt bölümünde genel olarak bir yazılım ürününün işaretlenmesine ilişkin gereksinimler, paketleme seçenekleri ve yöntemleri belirtilmiştir.

2.4.7. “Taşıma ve depolama gereksinimleri” alt bölümü, yazılım ürününe ait taşıma koşullarını, saklama yerlerini, saklama koşullarını, saklama koşullarını, çeşitli koşullardaki saklama sürelerini belirtmelidir.

2.5a. “Program dokümantasyonu için gereklilikler” bölümü, program dokümantasyonunun ön yapısını ve gerekirse bunun için özel gereklilikleri belirtmelidir.

(Ek olarak sunulan Değişiklik No. 1).

2.5. “Teknik ve ekonomik göstergeler” bölümü şunları belirtmelidir: tahmini ekonomik verimlilik, tahmini yıllık talep, en iyi yerli ve yabancı örnekler veya analoglarla karşılaştırıldığında kalkınmanın ekonomik avantajları.

2.6. “Gelişimin aşamaları ve aşamaları” bölümünde, gerekli geliştirme aşamaları, aşamalar ve işin içeriği (geliştirilmesi, üzerinde anlaşmaya varılması ve onaylanması gereken program belgelerinin listesi) ve kural olarak Geliştirme zaman çerçevesi ve uygulayıcılar belirlenir.

2.7. “Kontrol ve kabul prosedürü” bölümü, test türlerini ve işin kabulüne ilişkin genel gereklilikleri belirtmelidir.

2.8. Teknik şartnamenin eklerinde gerekiyorsa aşağıdakilere yer verilir:

• gelişmeyi haklı çıkaran araştırma ve diğer çalışmaların bir listesi;
• geliştirme sırasında kullanılabilecek algoritma diyagramları, tablolar, açıklamalar, gerekçeler, hesaplamalar ve diğer belgeler;
• diğer geliştirme kaynakları.

Temmuz 1981'de onaylanan 1 No'lu Değişiklikle Yeniden Basım (Kasım 1987) (IUS 7-81)

Dolayısıyla, TK olarak kısaltılan görev tanımı, oldukça uzun bir süredir, gerçekte ne görmek istediğimizi resmi olarak tanımlamaya hizmet ediyor. son ürün. Bir web kaynağı geliştirmeye yönelik teknik özellikler bir istisna değildir. Özünde bu, web sitesi geliştirmenin temelidir. Site ile doğrudan veya dolaylı olarak ilgili olan tüm hükümleri belirtir.

Teknik şartname, kural olarak, bir web kaynağının oluşturulmasına ilişkin ana sözleşmeye eklenmiştir, çünkü müşteri ile yüklenici arasındaki olası anlaşmazlıkları ortadan kaldırmak için yapılması gereken tüm işlerin tam bir listesini içerir; bilindiği üzere halen zaman zaman ortaya çıkmaktadır.

Tecrübeyle "dövülmüş" bazı kişiler arasında TK'nin sanki duruşmaya onunla çıkacakmış gibi yazılması ve savunma olarak kullanılması gerektiği yönünde bir görüş var. Bu aşırı bir durum olabilir ama yine de tekrar düşünmek için bir neden İyi yazılmış ve ayrıntılı bir teknik şartnamenin önemi hakkında .

Hacmi bakımından teknik şartname oldukça büyük bir belge olabilir. Web şirketleri genellikle teknik spesifikasyonların hazırlanmasında ayrı bir hizmet olarak yardım sunar; genellikle tüm web sitesi geliştirme maliyetinin %10-20'si kadardır.

Teknik şartnamelerin hazırlanması genellikle proje yöneticisi tarafından veya temel bilgileri sağlayan müşterinin katılımıyla doğrudan programcı tarafından gerçekleştirilir.

Nasıl daha detaylı teknik özellikler (tabii ki makul sınırlar dahilinde), her iki taraf için de o kadar iyidir - hem müşteri hem de işin icracısı. Her ikisi de kazanır, tabiri caizse:
— Müşteri, projede planladığı her şeyin açıkça belirtildiğinden ve teknik spesifikasyonlara uygun olarak uygulanması gerektiğinden emin olacaktır.
- Sanatçı, yine aynı teknik özellikler esas alınarak, birçok küçük veya büyük ayar ve değişikliğe karşı sigortalıdır.

Teknik özellikler olmadan yapabileceğiniz bir görüş var. Örneğin argümanlardan biri, görevin görev tanımına sığmayacak kadar yaratıcı olmasıdır. Bu görüş büyük olasılıkla bu alandaki deneyim ve profesyonellik eksikliğini maskelemektedir. Bu görüşün yanlış olduğunu düşünüyorum, çünkü web sitesi oluşturmadaki neredeyse her şey teknik şartnamelerde resmileştirilip sunulabilir ve bunu derlemek daha ziyade bir deneyim meselesidir.

• Basit gerçek şu ki, proje ne kadar karmaşıksa teknik özellikler de o kadar ayrıntılı olmalıdır.
• Arasında olası seçenekler Arayüzün ana sayfalarını, üzerindeki tüm öğeler kümesiyle ve bunların davranışlarının bir açıklamasıyla açıklayan teknik bir spesifikasyon olarak adlandırılabilir. Veya bir kartvizit web sitesi vb. için birkaç sayfanın kısa ve öz bir açıklaması olabilir.
• Programcıya yönelik teknik özellikler, elemanların tasarımından veya tasarım isteklerini ifade etmemelidir. Görev hala programcınındır..
• Teknik şartnamenin ayrı bölümlerindeki görev tanımları sınırlı olmalıdır. Bu ne anlama geliyor? Belirli bir görev öğesinin sonunu açıkça belirtmek gerekir. Teknik şartnamede “gezinme kolaylığı olmalı” gibi soyut ifadeler bulunmamalıdır. Bunların hepsi öznel işaretlerdir; bazıları için uygundur, diğerleri için uygun değildir ve teknik şartname hükümlerinin belirsizliği nedeniyle bu noktanın yerine getirilip getirilmediğini anlamak zor olabilir. Yani kontrol edilmesi gerekiyor.
• Tekerleği yeniden icat etmemek için bazı işlevsel modülleri tanımlamanız gereken basit siteler için, benzer işlevselliğe sahip siteleri analiz etmeniz, tabiri caizse rakiplerin bir analizini yapmanız gerekir; gerekli arayüz öğelerini ve işlevlerini içeren sayfalara olan köprüleri kaydedin ve bunları, tam olarak ne yapılacağına ilişkin genişletilmiş açıklamalarla birlikte iş bildirimine ekleyin. Aynı zamanda gerekli zorunlu ekran görüntülerini al gerekli sayfalar Sitenin bir süreliğine kullanılamaması durumunda. Aynı zamanda görüntülerin üzerine kendi işaretlerinizi de koyabilirsiniz (neyse ki artık bunun için pek çok araç var - Clip2net, Joxi, Awesome Screenshot ve diğerleri).
• Sayfaların tasarımı yoksa veya bir proje çerçevesinde o kadar önemli değilse, örneğin müşteri sitenin yönetici panelinin tasarımından tasarruf etmeye karar verdi, bu durumda programcı prototipleri pekala kullanabilir.

Referans

Prototip, arayüz elemanlarının grafiksel düzenidir. Kabaca söylemek gerekirse, çizilmiş özel program tüm öğelerin bulunduğu sayfa.

Hem masaüstü uygulamaları hem de çevrimiçi hizmetler dahil olmak üzere prototip çizmek için birçok yazılım ve ayrıca daha mütevazı yeteneklere sahip tarayıcılar için uzantılar var. Gibi yazılımlar ücretsiz lisansÜcretli olanlarda aynı.

Popüler olanlar şunları içerir:
— ücretsiz olanlar arasında: iPlotz, MockFlow, Mockup Builder, Cacoo;
— ücretli olanlar arasında: Creately, ProtoShare, Adobe Fireworks, Axure. Genel olarak birçok olasılık vardır; seçin, ustalaşın, çizin...

Teknik şartnamelerin genel yapısı. Soyutlamadan özgüllüğe

Olası site yapılarından biri, olası olanları vurguluyorum, şöyle görünebilir:

1. Genel bilgi Site hakkında.
2. Sitenin işlevsel amacı.
3. Kavramlar ve terimler
4. Site modüllerinin açıklaması
5. Fonksiyonel özellikler
6. Sayfaların açıklaması.
7. Artıklık ve güvenilirlik.
8. Site için barındırma.

1. Site hakkında genel bilgiler
Ne tür bir site veya modülün geliştirileceğini ve genel olarak amacını size tanıtmak için burada birkaç cümle yeterlidir. Serbest stilde yazılmıştır.

2. Sitenin işlevsel amacı
Genel hedefe dayalı olarak bir sitenin hangi teknik araçlara veya araçlara sahip olması gerektiğinin kısa bir listesini burada bulabilirsiniz. Bir örnekle açıklayayım. Bir kartvizit web sitesi için bu önemsiz olabilir, bir geri bildirim formu, ana sayfaların bir listesi, örneğin "şirket hakkında", "kişiler" ve diğerleri.

3. Kavramlar ve terimler
Bu bölüm her iki tarafın da belirli bir konuyu anlamasını sağlamalıdır. konu alanı Bir web sitesini anlamak ve geliştirmek için önemli olan kavramlar. Her iki taraftan da girilebilir.

4. Site modüllerinin açıklaması
Bu bölüm sitede kullanılan modüllerin bir listesini içerir. Örneğin bu yukarıda bahsedilen geri bildirim formu (FOF) olabilir. Ancak çok önemli olan, basitçe "FOS mevcut olmalı" yazamazsınız. Her varlık kendi niteliklerinin tanımlanmasını gerektirir! İÇİNDE bu durumda nitelikler şu şekilde olabilir:

• “Adınız” Alanı;
• “E-postanız” alanı;
• “Sorunuz” alanı;
• Spam robotlara karşı koruma sağlamak için Captcha giriş alanı.

Ve daha sonra soruların ortaya çıkmaması için tüm bunların açıkça belirtilmesi gerekir: « ...soru kategorisi seçme listesi nerede?» Ya da böyle bir şey.

5. Fonksiyonel özellikler
Bu, örneğin sitenin düzgün görüntülenmesi ve çalışması gereken tarayıcıların bir listesini içerebilir. Örneğin, bazı müşteriler web sitelerinin doğru ve bilinen standartlarda çalışmasını isteyebilir. İnternet Explorer 6, küçük de olsa, olası ziyaretçilerin bir kısmını kaybetmemek için.
Yüksek yüklü bir web sitesi oluşturmayı planlıyorsanız, bunun da belirtilmesi gerekir. Oldukça yüklü bir web sitesi, sunucuyu geliştirirken ve kurarken farklı bir yaklaşım gerektirir.

Fonksiyonel özellikler ayrıca varlığı veya yokluğu da içerir mobil versiyon site, ancak bu, kural olarak, ya bu teknik şartnamenin ayrı bir bölümüne girer ya da tamamen ayrı olarak yazılır.

6. Site sayfalarının açıklaması
Bu, sitenin tüm sayfalarının çizildiği ve çalışmaları hakkında yorumların yazıldığı oldukça kapsamlı bir öğedir.
Ayrıca verilebilir Genel yapı site sayfaları. Sözde "üst düzey" prototipler. Örneğin, basit bir dizin sitesi için bu şöyle olabilir:

Her belirli sayfa için, arayüz öğelerinin her biri ve bunların davranışları hakkında ayrıntılı yorumlar içeren prototipler çizilebilir.
Yönetici paneli için kullanılan sayfalar genellikle genel sayfalardan ayrı olarak listelenir. Bu iki bölüm de kendi ayrı alt bölümleri halinde gruplandırılabilir. Burada prototiplerin açıklamalarıyla çelişmediğinden ve hiçbir çelişkinin ortaya çıkmadığından emin olmakta fayda var. Belirli bir web sitesi sayfası için prototip örneği şu şekilde olabilir:

Diğer sayfalar

Teknik şartnamenin son iki bölümünü detaylı olarak ele almayacağız; kısaca, güvenilirlik gereksinimlerinden birinin veritabanı yedeğinin oluşturulmasını içerebileceğini söyleyeceğim.

Barındırma gereksinimleri mevcut olanları içerebilir fiziksel hafıza site için, kanal bant genişliği, kullanılan veritabanı desteği ve bir takım diğer gereksinimler doğru işlem alan.

İş Tanımının sonuna, bu İş Tanımında açıklanmayan tüm işlerle ilgili bilgilerin dahil edilmesi zorunludur. programcının takdirine bağlı olarak gerçekleştirilir bariz sebeplerden dolayı. Bu, teknik şartname kapsamını aşan olası değişiklik ve değişikliklere karşı “küçük garantimizdir”.

Sonuçlar: Teknik şartnamenin bölümlerinin bu yapısının tamamen tamamlanmış gibi görünmediğini (en azından büyük stratejik projeler için) ancak yine de ana noktaları kapsadığını söylemek gerekir.

Yukarıdakilerin tamamının yalnızca web sitesi geliştirme alanında çalışan kişilerin deneyimlerine dayanan öneriler olduğu ve hiçbir şekilde teknik şartnamelerin yazılması için katı bir gereklilik olmadığı vurgulanmalıdır.

Projelerinizde ve insan anlayışınızda iyi şanslar!

Bana sık sık şu soru soruluyor: "Otomatik bir sistem için teknik özellikler nasıl doğru şekilde geliştirilir?" Teknik spesifikasyonların geliştirilmesi konusu çeşitli forumlarda sürekli olarak tartışılmaktadır. Bu soru o kadar geniştir ki kısaca cevaplamak imkansızdır. Bu yüzden yazmaya karar verdim büyük makale Açık bu konu. Makale üzerinde çalışma sürecinde her şeyi tek bir makaleye sığdırmanın mümkün olmayacağını fark ettim çünkü... Yaklaşık 50 sayfa olacak ve onu 2 parçaya ayırmaya karar verdim:

• İlk bölümde" Teknik spesifikasyonların geliştirilmesi. Nedir, neden gereklidir, nereden başlamalı ve neye benzemelidir?? Konunun sorularını detaylı bir şekilde cevaplamaya çalışacağım, Görev Tanımının yapısını ve amacını ele alacağım ve gereksinimlerin formülasyonu konusunda bazı önerilerde bulunacağım.
• İkinci kısım " Teknik spesifikasyonların geliştirilmesi. Gereksinimler nasıl formüle edilir? tamamen gereksinimlerin belirlenmesi ve formüle edilmesine ayrılacaktır. bilgi sistemi.

Öncelikle “Teknik şartname nasıl geliştirilir?” diye soranların ilgisini çeken sorunun ne olduğunu bulmanız gerekiyor. Gerçek şu ki, teknik şartnamelerin geliştirilmesine yönelik yaklaşım, büyük ölçüde, bunun hangi amaçla yapıldığına ve kim tarafından kullanılacağına bağlı olacaktır. Hangi seçeneklerden bahsediyorum:

• Ticari bir kuruluş, otomatik bir sistem uygulamaya karar verdi. Kendi BT hizmeti yoktur ve şunu yapmaya karar vermiştir: İlgili taraf bir Teknik Şartname geliştirmeli ve bunu geliştirilmek üzere üçüncü bir tarafa sunmalıdır;
• Ticari bir kuruluş, otomatik bir sistem uygulamaya karar verdi. Kendi BT hizmeti vardır. Bunu yapmaya karar verdik: bir Teknik Şartname geliştirin, ardından BT hizmeti ile ilgili taraflar arasında üzerinde anlaşmaya varın ve bunu kendi başımıza uygulayın;
• Devlet kurumu bir BT projesi başlatmaya karar verdi. Buradaki her şey o kadar karanlık ki, pek çok formalite, komisyon, kesinti vb. Bu makalede bu seçeneği dikkate almayacağım.
• Bir BT şirketi, otomatik sistemlerin geliştirilmesi ve/veya uygulanmasına yönelik hizmetler sağlar. Bu en çok zor durum, çünkü çeşitli koşullarda çalışmak zorundasınız:

  Müşterinin kendi görüşleri olan kendi uzmanları vardır ve bunlar Teknik Şartname için özel gereklilikler hazırlar;

  • Görev tanımı şirket içi geliştiriciler için geliştirildi (müşterinin umurunda değil);
  • Görev tanımı yükleniciye (yani şirket kadrosundaki bir grup programcıya veya bireysel bir uzmana) transfer edilmek üzere geliştirilir;
  • Elde edilen sonuç konusunda firma ile müşteri arasında bir yanlış anlama ortaya çıkıyor ve firma tekrar tekrar şu soruyu soruyor: “Teknik Şartname nasıl geliştirilmeli?” Son durum bir paradoks gibi görünebilir ama doğrudur.
  • Daha az yaygın olan diğer seçenekler de mümkündür;

Okuyucunun artık şu soruları sorması gerektiğini düşünüyorum:

• Teknik Şartname neden her zaman aynı şekilde geliştirilemiyor?;
• Herhangi bir standart, yöntem, öneri var mı? Onları nereden alabilirim?
• Görev Tanımını kim geliştirmelidir? Bu kişinin herhangi bir özel bilgisi olması gerekir mi?
• Görev Tanımının iyi yazılıp yazılmadığı nasıl anlaşılır?
• Kimin pahasına geliştirilmeli ve hatta gerekli mi?

Bu liste sonsuz olabilir. Bunu güvenle söylüyorum çünkü 15 yıldır mesleki gelişim içerisindeyim. yazılım ve birlikte çalıştığınız herhangi bir geliştirme ekibinde Teknik Özellikler sorusu ortaya çıkar. Bunun nedenleri farklıdır. Görev Tanımının geliştirilmesi konusunu gündeme getirirken, bunu konuyla ilgilenen herkese %100 sunamayacağımın çok iyi farkındayım. Ama dedikleri gibi "her şeyi halletmeye" çalışacağım. Makalelerime zaten aşina olanlar, başkalarının eserlerini “kopyala-yapıştır” kullanmadığımı, başkalarının kitaplarını yeniden basmadığımı, çok sayfalı standartlardan ve internette bulabileceğiniz diğer belgelerden alıntı yapmadığımı biliyorlar. bunları kendi dahiyane düşünceleriniz olarak aktarıyorsunuz. Sadece bir arama motoruna "Teknik Şartname nasıl geliştirilir" yazın; birçok ilginç ama ne yazık ki tekrarlayan şeyleri okuyabilirsiniz. Kural olarak, forumlarda zekice davranmayı sevenler (sadece aramayı deneyin!) hiçbir zaman kendileri uygun bir Teknik Şartname hazırlamamışlar ve bu konuyla ilgili sürekli olarak GOST tavsiyelerinden alıntı yapmışlardır. Ve konu hakkında gerçekten ciddi olanların genellikle forumlarda oturacak vakti yoktur. Bu arada GOST standartlarından da bahsedeceğiz. Yıllar süren çalışmalarım boyunca, hem bireysel uzmanlar hem de seçkin ekipler ve danışmanlık şirketleri tarafından derlenen teknik belgelerin birçok versiyonunu gördüm. Bazen ben de bu aktiviteye giriyorum: Kendime zaman ayırıyorum ve ilgilendiğim bir konu hakkında alışılmadık kaynaklardan (biraz zeka gibi) bilgi araştırıyorum. Sonuç olarak GazProm, Rus Demiryolları ve diğer birçok ilginç şirket gibi canavarlarla ilgili belgeleri görmek zorunda kaldım. Bu belgelerin bana kamuya açık kaynaklardan gelmesine veya danışmanların sorumsuzluğuna (bilgilerin internette yayılmasına) rağmen elbette gizlilik politikasına uyuyorum. Bu nedenle hemen şunu söylüyorum: Başka şirketlere ait gizli bilgileri, kaynağı ne olursa olsun (mesleki etik) paylaşmıyorum.

Teknik şartname nedir?

Şimdi yapacağımız ilk şey bu “Teknik Şartnamenin” nasıl bir canavar olduğunu bulmak olacak.

Evet, faaliyetin bu kısmını (yazılım geliştirme) düzenlemeye çalışan gerçekten GOST'ler ve standartlar var. Bir zamanlar tüm bu GOST'lar alakalıydı ve aktif olarak kullanılıyordu. Şimdi bu belgelerin geçerliliği konusunda farklı görüşler var. Bazıları GOST'ların ileri görüşlü insanlar tarafından geliştirildiğini ve hala geçerli olduğunu iddia ediyor. Diğerleri umutsuzca modası geçmiş olduklarını söylüyor. Belki birileri artık gerçeğin ortada bir yerde olduğunu düşünüyordu. Goethe'nin şu sözleriyle cevap verirdim: “İki karşıt görüş arasında gerçeğin yattığını söylüyorlar. Hiçbir durumda! Aralarında bir sorun var." Dolayısıyla bu görüşler arasında doğruluk payı yoktur. Çünkü GOST'ler pratik sorunları ortaya çıkarmaz modern gelişme, onları eleştirenler ise bir alternatif (spesifik ve sistemsel) sunmuyorlar.

GOST'un açıkça bir tanım bile vermediğini unutmayın, sadece şunu söylüyor: “Bir nükleer santral için TK, otomatik bir sistemin oluşturulmasına (geliştirilmesi veya modernizasyonu - daha sonra oluşturulmasına) uygun olarak gereklilikleri ve prosedürü tanımlayan ana belgedir. Nükleer santralin geliştirilmesinin gerçekleştirildiği ve işletmeye alındıktan sonra kabulünün yapıldığı."

Hangi GOST'lardan bahsettiğimi merak eden varsa işte buradalar:

• GOST 2.114-95 Birleşik tasarım dokümantasyon sistemi. Teknik özellikler;
• GOST 19.201-78 Birleşik program dokümantasyon sistemi. Teknik görev. İçerik ve tasarım gereksinimleri;
• GOST34.602-89 Bilgi Teknolojisi. için bir dizi standart otomatik sistemler. Otomatik bir sistemin oluşturulması için referans şartları.

Vikipedi'de çok daha iyi bir tanım sunulmaktadır (sadece yazılım için değil, genel olarak teknik özellikler hakkında da olsa): " Teknik görev- bu orijinal tasarım belgesidir teknik nesne. Teknik görev geliştirilmekte olan nesnenin ana amacını, teknik ve taktik-teknik özelliklerini, kalite göstergelerini ve teknik ve ekonomik gerekliliklerini, dokümantasyon oluşturmanın gerekli aşamalarını (tasarım, teknolojik, yazılım vb.) ve kompozisyonunu tamamlama talimatlarını belirler. yanı sıra özel gereksinimler. Yeni bir şeyin yaratılmasına yönelik ilk belge olarak görev, adı, içeriği, uygulama sırası vb. bakımından farklılık gösteren tüm faaliyet alanlarında mevcuttur (örneğin, inşaatta bir tasarım görevi, bir savaş görevi, Ev ödevi, edebi eser sözleşmesi vb.)"

Ve böylece, tanımdan da anlaşılacağı gibi, Teknik Şartnamenin ana amacı, bizim durumumuzda otomatik bir sistem için geliştirilmekte olan nesnenin gerekliliklerini formüle etmektir.

Ana şey bu, ama tek şey. Asıl meseleye inme zamanı geldi: söz verildiği gibi her şeyi "raflara" koymak.

Gereksinimler hakkında bilmeniz gerekenler nelerdir? Tüm gereksinimlerin türe ve özelliklere göre bölünmesi gerektiğini açıkça anlamak gerekir. Şimdi bunu nasıl yapacağımızı öğreneceğiz. Gereksinimleri türe göre ayırmak için GOST bize yardımcı olacaktır. Burada sunulan gereksinim türlerinin listesi, ne tür gereksinimlerin dikkate alınması gerektiğine dair iyi bir örnektir. Örneğin:

• İşlevsellik gereksinimleri;
• Güvenlik ve erişim hakları gereksinimleri;
• Personel niteliklerine ilişkin gereklilikler;
• …. Vesaire. Bahsedilen GOST'ta bunlar hakkında bilgi edinebilirsiniz (ve aşağıda bunlara biraz daha ayrıntılı olarak bakacağım).

Başarılı bir Teknik Şartnamedeki temel faktörün tam olarak iyi formüle edilmiş işlevsellik gereklilikleri olduğunu sizin için açık olduğunu düşünüyorum. Bahsettiğim çalışmaların ve yöntemlerin çoğu bu gereksinimlere adanmıştır. İşlevsellik gereksinimleri, Görev Tanımını geliştirme çalışmasının karmaşıklığının %90'ını oluşturur. Geriye kalan her şey genellikle bu gereklilikleri kapsayan bir “kamuflajdır”. Gereksinimler kötü formüle edilirse, onlara ne kadar güzel kamuflaj koyarsanız koyun başarılı bir proje ortaya çıkmayacaktır. Evet, resmi olarak tüm gereksinimler karşılanacak (GOST J'ye göre), teknik şartname geliştirildi, onaylandı ve imzalandı ve bunun için para alındı. Ve ne? Ve sonra en ilginç kısım başlıyor: ne yapmalı? Bu Devlet Düzeni ile ilgili bir proje ise, o zaman sorun yoktur - oradaki bütçe kimsenin cebine sığmayacak şekildedir ve uygulama sürecinde (varsa) her şey netleşecektir. Proje bütçelerinin çoğunluğu tam da bu şekilde Devlet Emirlerine harcanıyor (“TZ” yazdılar, on milyonlar kaybettiler ama projeyi yapmadılar. Tüm formaliteler yerine getirildi, suçlu taraf yoktu, yeni bir araba yakınlarda) ev. Güzellik!). Ama paranın sayıldığı, farklı bir sonuca ihtiyaç duyulan ticari organizasyonlardan bahsediyoruz. Bu nedenle, asıl meseleyi, nasıl geliştirileceğini anlayalım kullanışlı ve çalışır durumda Teknik özellikler.

Gereksinim türlerinden bahsettim, peki ya özellikler? Gereksinim türleri farklı olabiliyorsa (projenin hedeflerine bağlı olarak), o zaman özelliklerde her şey daha basittir, bunlardan 3 tane vardır:

1. Gereklilik şu şekilde olmalıdır: anlaşılır;
2. Gereklilik şu şekilde olmalıdır: özel;
3. Gereklilik şu şekilde olmalıdır: sınava girenler;

Dahası son özellikönceki ikisi olmadan imkansız, yani. bir tür “turnusol testi”dir. Bir gereksinimin sonucu test edilemiyorsa bu, onun belirsiz olduğu veya spesifik olmadığı anlamına gelir. Bunu düşün. Ustalık ve profesyonellik, gereksinimlerin bu üç özelliğine hakim olmada yatmaktadır. Aslında çok basit. Bunu anladığında.

Bu, Teknik Şartnamenin ne olduğuna dair hikayeyi sonlandırıyor ve asıl konuya geçiyor: gereksinimlerin nasıl formüle edileceği. Ama o kadar hızlı değil. son derece başka bir şey daha var önemli nokta:

• Teknik şartname hangi dilde (anlaşılma zorluğu açısından) yazılmalıdır?
• Çeşitli fonksiyonların, algoritmaların, veri türlerinin ve diğer teknik şeylerin özelliklerini açıklamalı mı?
• Bu arada GOST'larda da bahsedilen teknik tasarım nedir ve Teknik Şartname ile nasıl ilişkilidir?

Bu soruların cevaplarında çok sinsi bir şey gizlidir. Bu nedenle gereksinimlerin yeterliliği veya gerekli ayrıntıların eksikliği, belgenin Müşteri ve Yükleniciler tarafından anlaşılabilirliği, fazlalık, sunum formatı vb. konularda sıklıkla anlaşmazlıklar ortaya çıkar. Görev Tanımı ile Teknik Proje arasındaki çizgi nerede?

Teknik görev- Müşterinin anlayabileceği (sıradan, tanıdık) bir dilde formüle edilmiş gereksinimlere dayanan bir belgedir. Bu durumda Müşterinin anlayabileceği sektör terminolojisi kullanılabilir ve kullanılmalıdır. Teknik uygulamanın ayrıntılarıyla hiçbir bağlantı olmamalıdır. Onlar. Teknik şartname aşamasında prensip olarak bu gereksinimlerin hangi platformda uygulanacağı önemli değildir. İstisnalar olmasına rağmen. Mevcut bir sistemi temel alarak bir sistem uygulamaktan bahsediyorsak yazılım ürünü, bu durumda böyle bir bağlantı yalnızca tarama formları, rapor formları vb. düzeyinde gerçekleşebilir. Gereksinimlerin açıklığa kavuşturulması ve formüle edilmesinin yanı sıra Görev Tanımının geliştirilmesi de gerçekleştirilmelidir. iş analisti. Ve kesinlikle bir programcı değil (bu rolleri birleştirmediği sürece bu olur). Onlar. bu kişi Müşteriyle işinin dilinde konuşmalıdır.

Teknik proje - Bu, Görev Tanımında formüle edilen gerekliliklerin teknik olarak uygulanmasına yönelik bir belgedir. Bu belge veri yapılarını, tetikleyicileri ve saklı prosedürleri, algoritmaları ve gerekli olacak diğer şeyleri açıklamaktadır. teknik uzmanlar. Müşterinin bunu hiçbir şekilde araştırmasına gerek yoktur (bu tür şartlar bile onun için net olmayabilir). Teknik proje yapılır sistem mimarı(Bu rolü bir programcıyla birleştirmek oldukça normaldir). Daha doğrusu, bir mimar tarafından yönetilen bir grup JSC uzmanı. Proje ne kadar büyükse, o kadar fazla Daha fazla insan teknik özellikler üzerinde çalışıyoruz.

Pratikte elimizde ne var? Yönetmene, teknik terminoloji, veri türlerinin açıklamaları ve değerleri, veritabanı yapısı vb. ile dolu bir teknik şartnamenin onay için sunulmasını izlemek komik. Onaylaması gerektiği için elbette anlamaya çalışıyor. , satır aralarında tanıdık sözcükler bulmaya çalışmak ve zincirleme iş gereklerini kaybetmemek. Bu tanıdık bir durum mu? Peki nasıl bitiyor? Kural olarak, bu tür teknik özellikler onaylanır, daha sonra uygulanır ve vakaların% 80'inde, yapılan işin gerçeğine hiç uymuyorlar çünkü değiştirmeye karar verdiler, birçok şeyi yeniden yaptılar, yanlış anladılar, yanlış düşündüler vb. ve benzeri. Ve ardından iş teslimiyle ilgili seri başlıyor. "Ama burada ihtiyacımız olan şey bu değil" ama "bu bizim işimize yaramayacak", "bu çok karmaşık", "bu sakıncalı" vb. Tanıdık geliyor mu?!! Bu bana tanıdık geliyor, tümseklere zamanında çarpmam gerekiyordu.

Peki pratikte elimizde ne var? Ancak pratikte, Görev Tanımı ile Teknik Proje arasında bulanık bir sınırla karşı karşıyayız. Çeşitli tezahürlerle TK ve TP arasında süzülüyor. Ve bu kötü. Bunun nedeni kalkınma kültürünün zayıflamasıdır. Bu kısmen uzmanların yeterliliklerinden, kısmen de bütçeleri ve son teslim tarihlerini azaltma arzusundan kaynaklanmaktadır (sonuçta belgeleme çok zaman alır - bu bir gerçektir). Teknik Tasarımın ayrı bir belge olarak kullanımını etkileyen bir başka önemli faktör daha vardır: hızlı gelişim hızlı geliştirme araçları ve geliştirme metodolojileri. Ama bu ayrı bir hikaye, aşağıda birkaç kelime söyleyeceğim.

Küçük ama önemli bir nokta daha. Bazen Görev Tanımına, basit ve anlaşılır, küçük bir gereklilik parçası denir. Örneğin, bir nesnenin aramasını bazı koşullara göre iyileştirin, rapora bir sütun ekleyin vb. Bu yaklaşım oldukça haklı, neden hayatı zorlaştırıyor. Ancak büyük projelerde değil, küçük iyileştirmelerde kullanılıyor. Bunun yazılım ürünü bakımına daha yakın olduğunu söyleyebilirim. Bu durumda, Görev Tanımı, gereksinimin uygulanmasına yönelik spesifik bir teknik çözümü de tanımlayabilir. Örneğin, programcı için belirli bir prosedürü ve belirli bir değişikliği belirten "Şöyle bir algoritmada şöyle bir değişiklik yapın". Bu, Görev Tanımı ile Teknik Projeler arasındaki sınırın tamamen silindiği durumdur, çünkü İhtiyaç duyulmayan evrakları şişirmenin ekonomik bir fizibilitesi yoktur, ancak faydalı bir belge yaratılır. Ve bu doğru.

Teknik spesifikasyon gerçekten gerekli mi? Teknik Proje ne olacak?

Aşırı ısınıyor muyum? Bu herhangi bir şey olmadan mümkün mü? Teknik özellikler? Bunun mümkün olduğunu (daha doğrusu mümkün olduğunu) ve bu yaklaşımın pek çok takipçisinin olduğunu ve sayılarının arttığını hayal edin. Kural olarak, genç uzmanlar Scrum, Agile ve diğer hızlı gelişim teknolojileri hakkında kitaplar okuduktan sonra. Aslında bunlar harika teknolojiler ve işe yarıyorlar ama kelimenin tam anlamıyla “teknik görevler yapmaya gerek yok” demiyorlar. "Minimum düzeyde evrak işi", özellikle de gereksiz olanlar, Müşteriye daha yakın olanlar, daha fazla ayrıntı ve daha hızlı sonuçlar diyorlar. Ancak hiç kimse gereksinimlerin kaydedilmesini iptal etmedi ve bu orada açıkça belirtiliyor. Yukarıda bahsettiğim üç dikkat çekici özelliğe göre gereklilikler orada belirleniyor. Sadece bazı insanların zihinleri öyle yapılandırılmıştır ki, eğer bir şey basitleştirilebiliyorsa, o zaman onu tamamen yok olacak kadar basitleştirelim. Einstein'ın dediği gibi " Mümkün olduğu kadar basitleştirin, ancak bundan daha basit değil." . Bunlar her şeye uyan altın kelimelerdir. Bu yüzden Teknik görev aksi takdirde başarılı bir proje göremezsiniz. Başka bir soru da bunun nasıl oluşturulacağı ve oraya nelerin dahil edileceğidir. Hızlı geliştirme metodolojileri ışığında, yalnızca gereksinimlere odaklanmanız gerekir ve tüm “kamuflaj” bir kenara bırakılabilir. Prensip olarak buna katılıyorum.

Teknik Proje ne olacak? Bu belge çok faydalıdır ve geçerliliğini kaybetmemiştir. Üstelik çoğu zaman onsuz yapamazsınız. Özellikle geliştirme çalışmalarının dış kaynak kullanımı söz konusu olduğunda, ör. dış kaynak kullanımı ilkesine dayanmaktadır. Bunu yapmazsanız aklınızdaki sistemin nasıl görünmesi gerektiği hakkında çok şey öğrenme riskiyle karşı karşıya kalırsınız. Müşteri buna aşina olmalı mı? Eğer istiyorsa neden olmasın ama ısrar et ve iddia et bu belge gerek yok, sadece seni geri çeker ve işine engel olur. Bir sistemi en ince detayına kadar tasarlamak neredeyse imkansızdır. Bu durumda Teknik Tasarımda sürekli değişiklik yapmanız gerekecek ve bu da çok zaman alacaktır. Ve eğer organizasyon ağır bir bürokratikse, o zaman tüm sinirlerinizi orada bırakırsınız. Bu tür tasarımın azaltılması, yukarıda bahsettiğim modern hızlı geliştirme metodolojilerinin tam olarak amacıdır. Bu arada, hepsi zaten yaklaşık 20 yıllık bir yaklaşım olan klasik XP'ye (ekstrem programlama) dayanıyor. Bu nedenle, Müşterinin anlayabileceği, yüksek kaliteli bir Teknik Şartname hazırlayın ve Teknik Tasarımı, sistem mimarı ile programcılar arasındaki ilişki için dahili bir belge olarak kullanın.

Hakkında ilginç detay teknik tasarım: Konu odaklı prensibe göre tasarlanan bazı geliştirme araçları (1C ve benzeri gibi), tasarımın (belgeleme süreci anlamına gelir) yalnızca tüm alt sistemler arasında etkileşimin gerekli olduğu gerçekten karmaşık alanlarda gerekli olduğunu varsayar. En basit durumda, örneğin bir dizin veya belge oluştururken, yalnızca doğru şekilde formüle edilmiş iş gereksinimleri yeterlidir. Bu aynı zamanda bu platformun uzmanların eğitimi açısından iş stratejisiyle de kanıtlanmaktadır. Bir uzmanın (“programcı” değil, buna denir) sınav kartına bakarsanız, yalnızca iş gereksinimlerinin olduğunu ve bunların bir program dilinde nasıl uygulanacağının uzmanın görevi olduğunu göreceksiniz. Onlar. Sorunun Teknik Projenin çözmeyi amaçladığı kısmını, uzmanın yine "kafasında" (orta karmaşıklıktaki görevlerden bahsediyoruz) burada ve şimdi, belirli geliştirme ve tasarım standartlarını izleyerek çözmesi gerekir. platformu için 1C şirketi. Böylece, çalışma sonuçları aynı görünen iki uzmandan biri sınavı geçebilir, diğeri geçemez çünkü geliştirme standartlarını açıkça ihlal etti. Yani uzmanların, sistem mimarlarının katılımı olmadan tipik görevleri bağımsız olarak tasarlayabilecek niteliklere sahip olmaları gerektiği açıkça varsayılmaktadır. Ve bu yaklaşım işe yarıyor.

Şimdi şu soruyu incelemeye devam edelim: "Görev Tanımında hangi gereksinimler yer almalıdır?"

Bilgi sistemi gereksinimlerinin formülasyonu. Görev Tanımının Yapısı

Hemen açık konuşalım: Özellikle bir bilgi sistemi için gereksinimlerin formüle edilmesinden bahsedeceğiz; iş gereksinimlerinin geliştirilmesi, iş süreçlerinin resmileştirilmesi ve önceki tüm danışmanlık çalışmalarının halihazırda tamamlanmış olduğu varsayılmaktadır. Elbette bu aşamada bazı açıklamalar yapılabilir ama sadece açıklamalar. Otomasyon projesinin kendisi iş sorunlarını çözmez - bunu unutmayın. Bu bir aksiyomdur. Bazı yöneticiler, programı satın almaları halinde işin kaotik bir hal alacağına inanarak bunu çürütmeye çalışıyorlar. Ancak aksiyom aksiyomdur çünkü kanıt gerektirmez.

Herhangi bir aktivite gibi, gereksinimlerin formüle edilmesi de aşamalara ayrılabilir (ve bölünmelidir). Her şeyin bir zamanı var. Bu zorlu bir entelektüel çalışmadır. Ve eğer ona yeterince dikkat etmezseniz, sonuç uygun olacaktır. Uzman tahminlerine göre, Görev Tanımını geliştirmenin maliyeti %30-50 olabilir. Ben de aynı fikirdeyim. Her ne kadar 50 belki çok fazla olsa da. Sonuçta, Teknik Şartname henüz son belge geliştirilmesi gereken bir şey. Sonuçta teknik tasarımın da olması gerekiyor. Bu farklılık, proje ekiplerinin geliştirme sırasında kullandığı farklı otomasyon platformları, yaklaşımları ve teknolojilerinden kaynaklanmaktadır. Örneğin C++ gibi klasik bir dilde geliştirmeden bahsediyorsak o zaman detaylı teknik tasarım olmazsa olmazdır. 1C platformunda bir sistem uygulamaktan bahsediyorsak, yukarıda gördüğümüz gibi tasarımla ilgili durum biraz farklıdır (her ne kadar sıfırdan bir sistem geliştirirken klasik şemaya göre tasarlanmış olsa da).

Gereksinimler beyanı ana kısım olmasına rağmen Teknik özellikler ve bazı durumlarda teknik şartnamenin tek bölümü haline geliyor, bunun önemli bir belge olmasına dikkat etmeli ve buna göre hazırlanmalıdır. Nereden başlamalı? Öncelikle içerikten başlamanız gerekiyor. İçeriği yazın ve ardından genişletmeye başlayın. Şahsen bunu yapıyorum: önce içeriğin taslağını çiziyorum, hedefleri, tüm giriş bilgilerini tanımlıyorum ve sonra ana kısma - gereksinimlerin formülasyonuna iniyorum. Neden tam tersi olmasın? Bilmiyorum, benim için daha uygun. Birincisi, bu çok daha küçük bir zaman dilimidir (gereksinimlerle karşılaştırıldığında) ve ikincisi, tüm giriş bilgilerini anlatırken asıl konuya odaklanırsınız. Peki kim beğenirse. Zamanla kendi Teknik Şartname şablonunuzu geliştireceksiniz. Başlangıç ​​​​olarak, tam olarak GOST'ta açıklananı içerik olarak almanızı öneririm. İçerik için mükemmel! Daha sonra, aşağıdaki üç özelliğin önerilerini unutmadan, her bir bölümü alıp açıklamaya başlıyoruz: anlaşılabilirlik, özgüllük ve test edilebilirlik. Neden bu konuda bu kadar ısrar ediyorum? Bir sonraki bölümde bununla ilgili daha fazla bilgi vereceğiz. Ve şimdi GOST'ta önerilen teknik spesifikasyonların bu noktalarını gözden geçirmeyi öneriyorum.

1. Genel bilgi;
2. sistemin yaratılmasının (geliştirilmesinin) amacı ve hedefleri;
3. otomasyon nesnelerinin özellikleri;
4. sistem gereksinimleri;
5. sistemi oluşturmak için işin bileşimi ve içeriği;
6. sistemin kontrol ve kabul prosedürü;
7. sistemi işletmeye almak için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriğine ilişkin gereksinimler;
8. dokümantasyon gereksinimleri;
9. geliştirme kaynakları.

Toplamda 9 bölüm olup, her biri kendi içinde alt bölümlere ayrılmıştır. Sırasıyla bunlara bakalım. Kolaylık sağlamak için, her öğe için her şeyi bir tablo şeklinde sunacağım.

Bölüm 1. genel bilgiler.

Bölüm 2. Sistemin oluşturulmasının (geliştirilmesinin) amacı ve hedefleri.

Genel olarak hedefleri belirleme, bunları formüle etme ve bir hedef ağacı oluşturma yeteneği tamamen ayrı bir konudur. Önemli olanı unutmayın: Nasıl yapılacağını biliyorsanız yazın, emin değilseniz hiç yazmayın. Hedefleri formüle etmezseniz ne olur? Gereksinimlere göre çalışacaksınız, bu sıklıkla uygulanmaktadır.

Bölüm 3. Otomasyon nesnelerinin özellikleri.

Bölüm 4. Sistem Gereksinimleri

GOST, bu tür gereksinimlerin listesini çözer:

• sistemin yapısı ve işleyişine ilişkin gereksinimler;
• sistem personelinin sayısı ve nitelikleri ile bunların çalışma şekline ilişkin gereklilikler;
• hedef göstergeleri;
• güvenilirlik gereksinimleri;
• güvenlik gereksinimleri;
• ergonomi ve teknik estetik gereksinimleri;
• mobil hoparlörler için taşınabilirlik gereksinimleri;
• sistem bileşenlerinin çalıştırılması, bakımı, onarımı ve depolanmasına ilişkin gereksinimler;
• bilgileri yetkisiz erişime karşı korumaya yönelik gereksinimler;
• kaza durumunda bilgi güvenliği gereklilikleri;
• dış etkenlerden korunma gereklilikleri;
• patent saflığı gereksinimleri;
• standardizasyon ve birleştirme gereklilikleri;

Ana bölümün kesinlikle özel gereksinimleri olan (işlevsel) bölüm olacağı gerçeğine rağmen, bu bölüm de büyük önem taşıyabilir (ve çoğu durumda öyledir). Önemli ve faydalı olabilecek şeyler:

• Kalite gereksinimleri. Geliştirilmekte olan sistemin uzmanların yeniden eğitilmesini gerektirmesi mümkündür. Bunlar hem gelecekteki sistemin kullanıcıları hem de onu desteklemek için ihtiyaç duyulacak BT uzmanları olabilir. Bu konuya yeterince dikkat edilmemesi sıklıkla sorunlara yol açar. Mevcut personelin nitelikleri açıkça yetersizse, eğitimin organizasyonu, eğitim programı, zamanlaması vb. için gereksinimlerin belirlenmesi daha iyidir.
• Bilgilerin yetkisiz erişime karşı korunmasına yönelik gereksinimler. Burada yorum yok. Bunlar tam olarak verilere erişimi sınırlamak için gereken gereksinimlerdir. Bu tür gereksinimler planlanmışsa, bunların ayrı ayrı, mümkün olduğunca ayrıntılı olarak, işlevsel gereksinimlerle aynı kurallara göre (anlaşılabilirlik, özgüllük, test edilebilirlik) yazılması gerekir. Bu nedenle bu gereksinimler işlevsel gereksinimler bölümüne dahil edilebilir.
• Standardizasyon gereksinimleri. Projeye uygulanabilir tasarım standartları varsa bunlar gereksinimlere dahil edilebilir. Kural olarak bu tür gereksinimler Müşterinin BT hizmeti tarafından başlatılır. Örneğin, 1C şirketinin tasarım gereksinimleri var program kodu, arayüz tasarımı vb.;
• Sistemin yapısı ve işleyişi için gereklilikler. Burada sistemlerin birbirleriyle entegrasyonuna yönelik gereksinimler açıklanabilir, bir açıklama sağlanır genel mimari. Entegrasyon gereksinimleri genellikle ayrı bir bölüme, hatta ayrı bir Teknik Şartnameye ayrılır, çünkü bu gereksinimler oldukça karmaşık olabilir.

Diğer tüm gereksinimler daha az önemlidir ve açıklanması gerekmez. Benim düşünceme göre, bunlar yalnızca belgeleri daha ağır hale getiriyor ve pratik fayda biraz taşı. Ergonomik gereksinimleri genel gereksinimler biçiminde tanımlamak çok zordur, bunları işlevsel olanlara aktarmak daha iyidir. Örneğin “Tek tuşa basarak bir ürünün fiyatı hakkında bilgi alın” şartı formüle edilebilir. Benim düşünceme göre bu, ergonomi ile ilgili olsa da, yine de spesifik fonksiyonel gereksinimlere daha yakındır.Sistemin gerçekleştirdiği işlevlere (görevlere) ilişkin gereksinimler Başarıyı belirleyecek ana ve kilit nokta budur. Her şey mükemmel yapılsa ve bu bölüm “3” olsa bile projenin sonucu şu olacaktır: en iyi durum senaryosu“3”te, hatta proje tamamen başarısız olacak. Bültenimizin 5. sayısında yer alacak olan ikinci yazımızda bunu daha detaylı ele alacağız. Bahsettiğim “gerekliliğin üç özelliği kuralı” bu noktada geçerlidir.

GOST aşağıdaki türleri tanımlar:

• Matematiksel
• Bilgilendirici
• Dilbilimsel
• Yazılım
• Teknik
• Metrolojik
• Organizasyonel
• metodik
• ve diğerleri…

İlk bakışta bu gereksinimler önemsiz görünebilir. Çoğu projede bu doğrudur. Ama her zaman değil. Bu gereksinimler ne zaman açıklanmalıdır:

• Hangi dil (veya platform) gelişiminin gerçekleştirileceğine ilişkin herhangi bir karar alınmadı;
• Sistem çok dilli bir arayüz gerektirir (örneğin Rusça/İngilizce)
• Sistemin işleyebilmesi için ayrı bir birimin oluşturulması ya da yeni çalışanların işe alınması gerekiyor;
• Sistemin çalışabilmesi için Müşterinin çalışma yöntemlerinde değişiklik yapılması ve bu değişikliklerin belirtilmesi ve planlanması gerekir;
• Herhangi bir ekipmanla entegrasyon bekleniyor ve ona gereksinimler (örneğin sertifikasyon, uyumluluk vb.)
• Diğer durumlar da mümkündür; bunların hepsi projenin belirli hedeflerine bağlıdır.

Bölüm 5. Sistemi oluşturmaya yönelik çalışmanın bileşimi ve içeriği

Bölüm 6. Sistemin kontrol ve kabulüne ilişkin prosedür

İşin aşamalar halinde kabulüne ilişkin genel gereklilikler (katılımcı kuruluş ve kuruluşların listesi, yer ve zamanlama), kabul belgelerinin koordinasyonu ve onaylanması prosedürü; İşin sunulması ve sistemin kontrol edilmesi prosedürünün sorumluluğunu almanızı şiddetle tavsiye ederim. Test edilebilir gereksinimlere tam olarak bu yüzden ihtiyaç duyulmaktadır, ancak işin kabulü ve devrine ilişkin prosedür açıkça belirtilmemişse, sistem teslim edildiğinde test edilebilir gereksinimlerin varlığı bile yeterli olmayabilir. Örneğin, yaygın bir tuzak: sistem inşa edilmiş ve tamamen çalışır durumdadır, ancak Müşteri bazı nedenlerden dolayı bu sistemde çalışmaya hazır değildir. Bu nedenler herhangi biri olabilir: zaman yok, hedefler değişmedi, birisi istifa etti vb. Ve şöyle diyor: “Henüz çalışmadığımız için yeni sistem bu da çalıştığından emin olamayacağımız anlamına geliyor." Öyleyse işin aşamalarını doğru bir şekilde tanımlamayı ve bu aşamaların sonuçlarını nasıl kontrol edeceğinizi öğrenin. Üstelik bu yöntemlerin Müşteri için en başından itibaren açık olması gerekir. Teknik Şartname düzeyinde sabitlenmişlerse, gerektiğinde her zaman onlara başvurabilir ve aktarımla işi tamamlayabilirsiniz.

Bölüm 7. Sistemin devreye alınması için otomasyon nesnesinin hazırlanmasına yönelik işin bileşimi ve içeriğine ilişkin gereklilikler

Şirket tarafından benimsenen (veya planlanan) bilgilerin girilmesine ilişkin başka kurallar da olabilir. Örneğin, bir sözleşmeye ilişkin bilgiler önceden herhangi bir biçimde metin dizisi olarak girilirken artık ayrı bir sayı, ayrı bir tarih vb. istenmektedir. Bunun gibi birçok durum olabilir. Bazıları personel tarafından dirençle algılanabilir, bu nedenle tüm bu tür durumların veri giriş sırasına göre gereksinimler düzeyinde kaydedilmesi daha iyidir.

Oluşturulan sistemin teknik şartnamede yer alan gerekliliklere uygunluğunun garanti edildiği otomasyon nesnesinin işleyişi için koşulların oluşturulması.Gerekebilecek her türlü değişiklik. Örneğin şirketin yok yerel ağ, sistemin çalışmayacağı eski bir bilgisayar filosu.

Belki bazıları gerekli bilgi kağıt üzerinde işlendi ve artık sisteme girilmesi gerekiyor. Bunu yapmazsanız, bazı modüller vb. çalışmayacaktır.

Belki bir şey basitleştirildi, ancak şimdi daha ayrıntılı olarak dikkate alınması gerekiyor, bu nedenle birisinin belirli kurallara göre bilgi toplaması gerekiyor.

Bu liste uzun olabilir, bakın özel durum Projeniz Sistemin işleyişi için gerekli departman ve hizmetlerin oluşturulması;

Personel alımı ve eğitim için zamanlama ve prosedür Bu konuyu daha önce konuşmuştuk. Belki de sistem daha önce var olmayan yeni bir yapı veya faaliyet türü için geliştirilmektedir. Uygun personel ve hatta eğitimli personel yoksa sistem ne kadar ustalıkla kurulursa kurulsun çalışmayacaktır.

Bölüm 8. Dokümantasyon Gereksinimleri

Kullanım kılavuzlarının nasıl sunulacağını düşünün.

Belki de Müşteri kurumsal standartları kabul etmiştir, bu da onlara başvurmamız gerektiği anlamına gelir.

Dokümantasyon gereksinimlerinin göz ardı edilmesi çoğu zaman projelerde en beklenmedik sonuçlara yol açar. Mesela her şey yapıldı ve her şey çalışıyor. Kullanıcılar ayrıca nasıl çalışacaklarını da biliyorlar. Dokümantasyon konusunda herhangi bir anlaşma veya görüşme yapılmadı. Ve birden işi teslim ederken, Müşterinin projeye bile katılmayan ancak işin kabulünde yer alan üst düzey yöneticilerinden biri size şunu sorar: "Kullanım kılavuzları nerede?" Ve sizi, kullanım kılavuzlarının mevcudiyeti konusunda anlaşmaya varmaya gerek olmadığına ikna etmeye başlıyor, bu sözde "elbette" ima ediliyor. İşte bu, işini elinden almak istemiyor. Yönergeleri kimin pahasına geliştireceksiniz? Pek çok takım bu kancaya çoktan düştü.

Bölüm 9. Geliştirme Kaynakları

Bu nedenle, anket raporuna ve kilit kişilerin gereksinimlerine başvurmak daha iyidir.

Bu yüzden İş Tanımına dahil edilebilecek tüm bölümleri değerlendirdik. Kesinlikle "Yapılabilir" ve "Zorunludur" çünkü herhangi bir belgenin bir sonuca ulaşmak için geliştirilmesi gerekir. Dolayısıyla belirli bir bölümün sizi sonuca yaklaştırmayacağı aşikarsa, o zaman buna ihtiyacınız yoktur ve üzerinde zaman harcamanıza gerek yoktur.

Ancak hiçbir yetkili teknik spesifikasyon asıl şey olmadan yapamaz: işlevsel gereksinimler. Pratikte bu tür Teknik Şartnamelerin ortaya çıktığını ve nasıl olduğunu belirtmek isterim! Tüm bölümlerde suları ayırabilecek, genel gereksinimleri genel hatlarıyla anlatabilecek kişiler var ve belge çok ağır çıkıyor ve içinde çok fazla akıllıca kelime var, hatta Müşterinin hoşuna gidebilir. (yani onaylayacaktır). Ama buna göre çalışmayabilir, yani. Pratik kullanımı çok azdır. Çoğu durumda, bu tür belgeler, özellikle Görev Tanımı için çok para almanız gerektiğinde doğar, ancak bunun hızlı bir şekilde ve ayrıntılara dalmadan yapılması gerekir. Ve özellikle işin daha ileri gitmeyeceğini veya bunu tamamen farklı kişilerin yapacağı biliniyorsa. Genel olarak sadece bütçeyi, özellikle de devlet bütçesini yönetmek için.

İkinci makalede yalnızca 4. bölüm "Sistem gereksinimleri" hakkında konuşacağız ve özellikle açıklık, spesifiklik ve test edilebilirlik nedenleriyle gereksinimleri formüle edeceğiz.

Neden gereksinimler açık, spesifik ve test edilebilir olmalıdır?

Çünkü uygulama şunu gösteriyor: İlk başta, uzmanlar tarafından geliştirilen teknik özelliklerin çoğu ya talep edilmiyor (gerçeğe uymuyor) ya da bunları uygulaması gereken kişi için sorun haline geliyor, çünkü Müşteri belirsiz şart ve gereksinimleri manipüle etmeye başlar. Hangi ifadelerle karşılaşıldığına, bunun nelere yol açtığına dair birkaç örnek vereceğim, ardından bu tür sorunların nasıl önlenebileceğine dair öneriler vermeye çalışacağım.

Herhangi bir tasarıma başlamadan önce, tasarlanan cihazın amacı ve kapsamı Proje Müşterisi ile Geliştiricisi arasında belirlenmeli ve tüm teknik (taktik ve teknik) özellikleri üzerinde tam olarak mutabakata varılmalıdır. Bu amaçla özel bir belge geliştirilmektedir - Teknik görev Bu cihazın veya sistemin tasarımı için.

Gelecekte, Geliştirici için Teknik Şartname, proje geliştirmenin tüm aşamalarına rehberlik eden birincil ve temel belge olacaktır.

Görev Tanımının geliştirilmesi çok önemli ve sorumlu bir süreçtir. Gelişimin bu aşamasında yapılan hatalar çok ciddi sonuçlara yol açabilir.

Kural olarak, Teknik Şartnamelerin geliştirilmesi Müşteri ve Tasarımcının temsilcileri tarafından ortaklaşa yürütülür. Teknik özellikler, geliştiricilerden büyük bilgi ve deneyim gerektirir. Bu nedenle görev tanımı, bu alanda önemli deneyime sahip, önde gelen, en nitelikli uzmanlar tarafından hazırlanmaktadır.

Görev tanımı, gelişimin ana yönlerini belirler - gelecekteki ürünün (cihaz, sistem) tasarımı ve çalışma prensibi.

Referans şartları İlk aşama yeni bir ürün yaratmak için gerekli tüm gelişmeler ve çalışma türleri için derlenmiştir. Görev tanımı ayrıca bölümlerden biri olarak aşağıdakilerin yürütülmesini de içerebilir:

Araştırma çalışmaları,

Geliştirme işi,

Otomasyon ekipmanlarının, bireysel bileşenlerin ve sistemlerin, teknolojinin, ölçüm cihazlarının, kontrol ekipmanlarının, güvenlik ekipmanlarının vb. geliştirilmesi.

Müşterinin sorumluluğu geliştiriciye ürün geliştirme için güvenilir başlangıç ​​verileri sağlamaktır. Müşteri, yeni ürüne ilişkin gerekliliklerden ve ilk verilerden sorumludur ve sağlanan bilgilerin doğruluğu konusunda tüm sorumluluğu üstlenir.

Görev tanımı üç ana bölümden oluşmalıdır:

1. Tüketici özelliklerini ve kullanım etkinliğini belirleyen ürünler için teknik ve ekonomik gereklilikler,

2. Müşteri ve Geliştirici tarafından ortak olarak değerlendirilmesi gereken belgelerin listesi,

3. Geliştirme sonuçlarının teslimi ve kabulüne ilişkin prosedür.

Gerektiğinde teknik şartname, üretimin hazırlanmasına ve geliştirilmesine yönelik gereklilikleri de içerebilir.

Teknik spesifikasyonun spesifik içeriği Müşteri ve Geliştirici tarafından ve proaktif geliştirme durumunda Geliştirici tarafından belirlenir.

Müşterinin, geliştirilmekte olan ürünler için standartların gerekliliklerinden farklı olan ancak ürünlerin belirtilen koşullar altında kullanılmasının etkinliğini azaltmayan bireysel gereksinimleri varsa, Rusya Federasyonu Devlet Standardından bu konuda görüş almalıdır. bu ürünleri geliştirme ve üretme imkanı.

Güvenlik, sağlık ve çevre korumayı denetleyen kurumların standartlarının ve düzenleyici belgelerinin gerekliliklerine aykırı olan referans şartlarına dahil edilmesine izin verilmez.

Görev tanımı, tasarımcının işini kolaylaştırmak ve geliştirme süresini kısaltmak için mümkün olduğunca fazla bilgi içermelidir.

Görev Tanımının kalitesi, geliştirme için gerekli materyallerin toplanmasının hacmi ve eksiksizliği ile sağlanır. Geliştirmede aşağıdaki malzemeler kullanılır:

Bilimsel ve teknik bilgiler,

Patent bilgileri,

Satış pazarının özellikleri,

Ürünün üretileceği üretimin özellikleri (teknolojik ekipman, personel nitelikleri, iş organizasyonu düzeyi vb.).

Görev Tanımı, kural olarak, geliştirilmekte olan ürünün aşağıdaki göstergelerini belirler:

Öngörülen göstergeler teknik seviye ve kalite,

Ana amaç

Satış pazarının özellikleri,

Teknik ve performans özellikleri,

Standardizasyon ve birleştirme düzeyi,

Teknik ve ekonomik göstergeler

Patent yasal göstergeleri,

Ürün için özel gereksinimler vb.

Görev Tanımı, Müşteri ve Geliştirici tarafından belirlenen şekilde geliştirilir ve onaylanır.

Teknik spesifikasyonların geliştirilmesi ve onaylanmasına ilişkin genel prosedür, Rusya Devlet Standardı GOST 15.001-88 tarafından oluşturulmuştur.

Görev tanımı, geliştirme aşamalarını ve her aşamanın zamanlamasını ve bir bütün olarak geliştirmeyi belirler.

Teknik özellikler, Devlet Standardı GOST 2.105-95'e uygun olarak metin tasarım belgelerinin genel gerekliliklerine uygun olarak hazırlanmıştır.

tablo 1