teknik görev (TK, başvuru şartları) - bir çevrimiçi mağazanın geliştirilmesi ve test edilmesi için kaynak belge.

TK kavramı

İş Tanımı - ilk tasarım belgesi teknik nesne (ürün). TK, geliştirilen nesnenin ana amacını belirler, özellikler, kalite göstergeleri ve teknik ve ekonomik gereksinimler, dokümantasyon (tasarım, teknolojik, yazılım vb.) Oluşturmanın gerekli aşamalarının ve bileşiminin yanı sıra bileşiminin uygulanması için bir reçete özel gereksinimler.

Referans şartları, yaratıcı bir nesne (video klip, makale, grafik görüntü) oluşturulurken de kullanılır.

TOR'un, müteakip belgelerin aksine, müşterinin NE gereksinimlerini açıklayan bir belge olduğunu söyleyebiliriz. Proje belgeleri, vurgunun, bunun NASIL başarılacağı sorusunun cevabına kaydığı.

Referans şartları yasal belge- tasarım işi için müşteri ve yüklenici arasındaki sözleşmeye ekin nasıl dahil edildiği ve temeli nasıl: amaç, hedefler, ilkeler, beklenen sonuçlar ve son tarihler dahil olmak üzere işin prosedürünü ve koşullarını belirler.

TOR'un metnindeki tüm değişiklikler, eklemeler ve açıklamalar müşteri ile anlaşmalı ve müşteri tarafından onaylanmalıdır. Bu aynı zamanda gereklidir, çünkü tasarım problemini çözme sürecinde yanlışlıklar veya hatalı ilk verilerin keşfedilmesi durumunda, geliştirmede yer alan tarafların her birinin suçluluk derecesini, meydana gelen kayıpların dağılımını belirlemek gerekli hale gelir. bununla bağlantı.

TK'nin tasarım yapısındaki yeri

Tasarım, belirli bir amacı olan bir süreçtir (proje geliştirme). yapı yani, aşamaların ve aşamaların sırası ve bileşimi, bir dizi prosedür ve ilgili teknik araçlar, süreçteki katılımcıların etkileşimi.

Uyarınca Medeni Kanun, tasarım türlerden biridir sözleşmeli iş, bunun sonucu üretimdir ( proje), yani başka bir ürün için bir dizi tasarım belgesi ( tasarım nesnesi). Proje, bir nesne yaratmayı, işleyişini, onarımını ve tasfiyesini ve ayrıca bu nesnenin geliştirildiği ara ve nihai çözümleri test etmeyi veya yeniden üretmeyi amaçlamaktadır.
Kelime "proje" faaliyet alanında "proje Yönetimi""program", "eylem planı", "çalışma paketi" anlamında kullanılır.

Tasarım çalışmasına katılanlar tüketicilere ayrılır ( müşteriler bu işler) ve tedarikçiler ( sanatçılar bu işler, müteahhitler). Uzman bir sanatçıya tasarımcı veya geliştirici denir. Ürünlerin tüketicisi kadar tedarikçisi de bir organizasyon olabilir ( varlık) veya belirli bir kişi (birey).

Tasarımın amacı, maddi bir cihaz veya işin performansı veya örneğin bir yapı veya bir hizmetin sağlanması olabilir. endüstriyel kompleks, teknik cihaz (cihaz, makine, aparat), kontrol sistemi, bilgi sistemi, düzenleyici belgeler (örneğin standart), vb.

Tasarım aşamaları standartlara göre düzenlenir. Bu aşağıdaki sıradır:

• İş Tanımı (GOST 2.103-68'e göre geliştirme aşamaları için geçerli değildir),
• Teknik teklif,
• Ön tasarım,
• Teknik proje,
• Çalışma projesinin aşamaları.

Herhangi bir sorunun çözümü, ilk verilerin anlaşılması ve açıklığa kavuşturulmasıyla başlar. Müşteri tarafından yayınlanan bu (teknik) gereksinimler, uzman olmayan bir tüketicinin dilinde formüle edilmiştir ve her zaman teknik olarak açık ve ayrıntılı değildir. Gereksinimleri dile çevirin konu alanı, görevi mümkün olduğunca eksiksiz ve yetkin bir şekilde formüle edin, çözümüne olan ihtiyacı haklı çıkarın, bu ana hedef TK, zorunlu adım iş. Yüklenici bunu müşteri ile yakın temas halinde gerçekleştirir. Aslında bu, müteahhidin proje üzerindeki çalışmalarının çoktan başladığı anlamına gelir.
Makine mühendisliğinde bu adıma bazen denir. dış tasarım.

Kural olarak, teknik özellikler, ön çalışmaların, hesaplamaların ve modellemenin sonuçlarının analizi temelinde derlenir.

Özel referans şartları

Birkaç geliştiricinin katılımını gerektiren karmaşık bir nesne (sistem) tasarlama sürecinde, alt sistemler için özel teknik özellikler oluşturulur.

Alınan teknik gereksinimlere uygun olarak, sistem geliştiricisi TOR'u oluşturur ve teknik teklif aşamasında nesnenin ayrıştırılmasını gerçekleştirir ve alt sistemler için özel teknik şartnameler hazırlar. Teknik teklifin tüm aşamalarını tamamladıktan sonra, geliştirici, orijinal TOR'u ortaklaşa geliştirirken, sistemin müşterisi ile kabul eder ve onaylar.

Teknik teklifin onaylanmasından sonra, sistem geliştiricisi özel TOR'u ortak yürütücüler arasında dağıtır ve bunun temelinde daha düşük seviyelerdeki alt sistemler için özel TOR geliştirilebilir. İkinci düzey alt sistemler yoksa, alt sistemler için teknik teklif, sistem düzeyinde pratik olarak tamamlandığı için genellikle gerçekleştirilmez.

Teknik şartnamelerin dağıtım aşamasının tamamlanmasının ardından, sistem geliştiricileri ve alt sistemleri, ön tasarım aşamasının uygulanmasına geçer. Bu aşamada yapının geliştirilmesi, tüm geliştiricilerin yakın işbirliği ile gerçekleştirilir. Böyle bir çalışma sürecinde, ayrı parçalar birbirine bağlanır, tasarlanan nesnenin ana parametreleri üzerinde anlaşmaya varılır. Tasarımın kalitesi, geliştiricinin soruna ilişkin vizyonunun genişliğine, yani bakış açısına ve söz konusu nesnenin tüm bağlantılarını hesaba katma yeteneğine ve ilgili alanları yakalayan bilgisine bağlıdır. Ön tasarım ve belirli çözümlerin genel çözümle koordinasyonu sürecinde, TOR'u ayarlamak mümkündür.

Avan tasarımın tamamlanmasından sonra, alınan projenin koordinasyonu ve onayı teknik çözümler müşteri teknik tasarım aşamasına geçer. Burada, nesnenin ve parçalarının tüm ana yapıcı çalışması gerçekleştirilir. Önceki aşamalara geri dönülerek teknik çözümleri geliştirmek mümkündür. Teknik tasarım, tüm geliştiricilerin yakın işbirliği ile gerçekleştirilir.

TK'ye duyulan ihtiyaç

İlk görev müşteri tarafından verilir. Onu geliştiriciye başvurmaya zorlamanın ana nedenleri, müşterinin ilgili özel bilgi eksikliği veya sınırlı kaynaklardır (sorunu çözmek için zaman eksikliği, gerekli sayıda insan, ekipman).

Görev, örneğin tüm iş bir kişi tarafından yapıldığında veya yetkili bir uzman tarafından verildiğinde veya sorgulanamadığında (hükümet emri) açıkça tanımlanabilir. Ancak daha sıklıkla, geliştiricinin dilinden ve konu alanının terimlerinden uzak, uzman olmayan bir tüketicinin dilinde genel terimlerle formüle edilir. Belirsiz gereksinimler, gereksinimlerin farklı yorumlanmasına izin verdiğinden ve geliştirilen ürünün kalitesinin objektif bir değerlendirmesine izin vermeyeceğinden, çalışmadaki tüm katılımcılar arasında belirsizliğe neden olur. Ayrıca geliştirici, müşterinin özel gereksinimleri bilmeyebileceğini (veya kısmen bilmeyebileceğini) anlamalıdır; bu, geliştiriciyi, görevdeki mevcudiyetlerine bakılmaksızın, denetleyici makamların gereksinimlerine uyma sorumluluğunu ve yükümlülüğünü ortadan kaldırmaz. Bu nedenle, geliştirme hedeflerini ve sonucunun kullanışlılığını belirlemekten yalnızca müşteri değil, geliştirici (icracı) da sorumludur.

Teknik bir şartname hazırlamak karmaşık ve sorumlu bir iştir: henüz pek çok veri bilinmemektedir, ancak görevin nasıl belirleneceği sonraki tasarımı daha kolay veya daha zor hale getirebilir (mecazi olarak konuşursak, “bir gemiyi nasıl çağırırsanız, bu yüzden yelken açacaktır” ).

Uzmanlar, bir problemi çözmede başarılı teknik şartnamelerin %50'den fazla olduğuna ve teknik şartname hazırlamak için harcanan zamanın, bir şirketin tasarım sürecinde yapabileceği en iyi yatırımlardan biri olduğuna inanmaktadır. Görev Tanımının hazırlanmasının önde gelen uzmanlara - baş tasarımcılara, proje ve iş yöneticilerine vb. - emanet edilmesi boşuna değildir.

Akademisyen A.N. Krylov söyledi. Bir fabrika kuruldu Yeni araba ama çalıştıramadı. Sonra yardım için bir üniversite profesörüne başvurdular. Fabrikaya vardığında, arabanın etrafında uzun süre dolaştı, dikkatlice bir şeyler aradı ve bir şeyler dinledi. Sonra bir çekiç alarak vücuduna vurdu. Ve araba çalıştı. Profesör, yardımı için fabrika yönetiminden 100 ruble istedi (20. yüzyılın başındaydı). Ancak fabrikanın yönetimi, çekiçle vurulan bir darbenin çok fazla olduğunu düşündü. Profesörün, darbenin kendisinin bir rubleye mal olduğunu, ancak nereye vurulacağını - 99 ruble olduğunu söyledi. Teknik tasarım aşamasında yapılan bir tasarım hatasını düzeltmenin maliyeti 1 olarak alınırsa, o zaman hata yapılmışsa düzeltme maliyetinin sırasıyla yaklaşık 10, 100 ve 1000 kat arttığı fark edilmiştir. ön tasarım, teknik teklif ve TOR aşamaları!

Müşteri ve yüklenici arasındaki iletişimde bir iletişim aracı olarak TK, aşağıdakilere izin verir:

• İki taraf da:
  • bitmiş ürünü hayal edin (hayal edin),
  • bitmiş ürünün nokta nokta kontrolünü gerçekleştirin (kabul testi - yürütme testler),
  • Eksikliklerinin veya yanlışlıklarının bir sonucu olarak değişen gereksinimlerle ilişkili hataların sayısını azaltmak (oluşturmanın tüm aşamalarında ve aşamalarında, aşağıdakiler hariç). testler).
• Müşteriye:
  • neye ihtiyacı olduğunu anla
    • mevcut teknik yeteneklere ve bunların kaynaklarına dayanarak,
  • Yüklenicinin ürüne TOR'da belirtilen tüm koşullara uymasını zorunlu kılar.
• Müteahhit:
  • görevin özünü anlamak, müşteriye gelecekteki ürünün, yazılım ürününün veya otomatik sistemin "teknik görüntüsünü" göstermek,
  • Projenin uygulanmasını planlamak ve plana göre çalışmak,
  • TOR'da belirtilmeyen işleri yapmayı reddetmek.

Düzenlenmiş TK

Önemine rağmen, TK'nin içeriği çok az düzenlenmiştir. normatif belgeler(GOST, OST).

• GOST 19.201-78. tek sistem yazılım belgeleri. Teknik görev. İçerik ve tasarım için gereksinimler (Kısaca Görev Tanımının içeriği özetlenmiştir);
• GOST 34.602-89. Bilgi Teknolojisi. için bir dizi standart otomatik sistemler. Otomatik bir sistemin oluşturulması için görev tanımı (TOR'un bileşimi ve içeriği yeterince ayrıntılı olarak açıklanmıştır);
• GOST 25123-82. Bilgisayar makineleri ve veri işleme sistemleri. Teknik görev. Yapım sırası, sunumu ve tasarımı (TK yapım sırası verilmiştir).

Araştırma çalışması yapma açısından, Görev Tanımı aşağıdaki belgelerle düzenlenir:

• OST 95 18-2001. Araştırma ve geliştirme çalışmaları yürütme prosedürü. Temel hükümler.
• 16 Eylül 2004 tarihinde Rosprom Sipariş No. 95 ile onaylanan Ar-Ge Kabul Kurallarına Ek No. 3. Araştırma çalışması için görev tanımı (ekte örnek) başvuru şartları Devlet Savunma Düzeni kapsamında geliştirme için)

GOST 34.602-89'a göre TK bölümleri (örnek)

GOST 34.602-89'a göre, Görev Tanımı aşağıdaki bölümleri içermelidir (kısaltılmış biçimde verilmiştir):

1. Genel bilgi
   1. sistemin tam adı ve sembolü;
      Örnek:
      Sistemin tam adı: Otomatik sistem "Yönetim"
      Sembol: ACS
   2. sözleşmenin konu şifresi veya şifresi (sayı);
      Örnek:
      XXX tarihli GG.AA.YYYY Sözleşme No.
   3. sistemin geliştiricisi ve müşterisinin (kullanıcısının) işletmelerinin (birliklerinin) adı ve detayları;
      Örnek:
      MÜŞTERİ Müşterinin adı: MIR LLC Yasal adres müşteri: 142345, Moskova, st. Tverskaya, ev 15 Posta adresi müşteri: 142345, Moskova, st. Tverskaya, ev 15 Müşterinin gerçek adresi: 142345, Moskova, st. Tverskaya, 15 Telefon: +7 903 456 67 67 Faks: +7 903 453 34 54 Adres E-posta: [e-posta korumalı] PSRN: 4554545445454 TIN: 4343434345 KPP: 453345443 BANKA: CJSC BankStroy, Moskova
      YÜKLENİCİ Yüklenicinin adı: DYATEL LLC Müşterinin yasal adresi: 142345, Moskova, st. Lenina, ev 34 Müşterinin posta adresi: 142345, Moskova, st. Lenina, ev 34 Müşterinin gerçek adresi: 142345, Moskova, st. Lenina, ev 34 Telefon: +7 495 345 63 63 Faks: +7 495 433 34 54 E-posta: [e-posta korumalı] PSRN: 4554545445454 TIN: 4343434345 KPP: 453345443 BANKA: CJSC BankStroy, Moskova
   4. Sistemin oluşturulduğu, bu belgelerin kimler tarafından ve ne zaman onaylandığına ilişkin belgelerin bir listesi;
   5. sistemin oluşturulmasına ilişkin çalışmaların başlaması ve tamamlanması için planlanan tarihler;
   6. işin finansmanı için kaynaklar ve prosedür hakkında bilgi;
   7. sistemin (parçalarının) oluşturulması, bireysel araçların (donanım, yazılım, bilgi) ve yazılım ve donanımın (yazılım ve metodolojik) komplekslerinin üretimi ve ayarlanması ile ilgili çalışmaların sonuçlarını müşteriye resmileştirme ve sunma prosedürü sistem.
2. Sistemin oluşturulmasının amacı ve hedefleri
3. Otomasyon nesnesinin özellikleri
   1. otomasyon nesnesi hakkında kısa bilgiler veya bu tür bilgileri içeren belgelere bağlantılar;
   2. otomasyon nesnesinin çalışma koşulları ve çevrenin özellikleri hakkında bilgi.
4. sistem gereksinimleri
   1. Bir bütün olarak sistem için gereksinimler;
   2. Sistem tarafından gerçekleştirilen işlevler (görevler) için gereksinimler;
   3. Teminat türleri için gereklilikler.
5. Sistemin oluşturulması ile ilgili çalışmaların bileşimi ve içeriği
   1. ilgili aşamaların ve çalışma aşamalarının sonunda sunulan GOST 34.201 uyarınca bir belge listesi;
   2. muayene türü ve prosedürü teknik döküman(aşama, aşama, kontrol edilen belgelerin hacmi, organizasyon uzmanı);
   3. geliştirilmekte olan sistemin gerekli güvenilirlik düzeyini sağlamayı amaçlayan bir çalışma programı (gerekirse);
   4. son teslim tarihlerinin bir göstergesi olan bir sistem oluşturmanın tüm aşamalarında metrolojik destek ve yürütme kuruluşları (gerekirse) ile ilgili çalışmaların bir listesi.
6. Sistemin kontrolü ve kabulü için prosedür
   1. sistemin türleri, bileşimi, kapsamı ve test yöntemleri ve oluşturan parçalar(geliştirilmekte olan sistem için geçerli olan mevcut standartlara uygun test türleri);
   2. Genel Gereksinimler işin aşamalara göre kabulüne (katılan işletmelerin ve kuruluşların listesi, yer ve zamanlama), kabul belgelerini kabul etme ve onaylama prosedürü;
   3. durum kabul komitesi(eyalet, departmanlar arası, departman).
7. Sistemi işletmeye almak için otomasyon nesnesini hazırlamak için işin bileşimi ve içeriği için gereklilikler
   1. sisteme giren bilgilerin (bilgi ve dil desteği gereksinimlerine uygun olarak) bilgisayar kullanılarak işlenmeye uygun bir forma getirilmesi;
   2. otomasyon nesnesinde yapılması gereken değişiklikler;
   3. oluşturulan sistemin TOR'da yer alan gerekliliklere uygunluğunun garanti edildiği otomasyon nesnesinin işleyişi için koşulların oluşturulması;
   4. sistemin işleyişi için gerekli alt bölümlerin ve hizmetlerin oluşturulması;
   5. personel alımı ve personel eğitimi için şartlar ve prosedür.
8. Belge Gereksinimleri
   1. GOST 34.201 gerekliliklerini ve sistem geliştiricisi ve müşteri tarafından kararlaştırılan müşterinin endüstrisinin bilimsel ve teknik belgelerini karşılayan geliştirilecek belge setlerinin ve türlerinin listesi; için düzenlenen belgelerin listesi makine ortamı; mikrofilme alma belgeleri için gereksinimler;
   2. ESKD ve ESPD gerekliliklerine uygun olarak sektörler arası uygulamanın bileşen öğelerini belgelemek için gereklilikler;
   3. yokluğu ile devlet standartları, sistem öğelerini belgelemek için gereksinimleri tanımlayan, ayrıca bu tür belgelerin bileşimi ve içeriği için gereksinimleri içerir.
9. Geliştirme kaynakları: belgeler ve bilgi materyalleri(fizibilite çalışması, tamamlanmış araştırma çalışmaları hakkında raporlar, yerli, yabancı analog sistemler hakkında bilgi materyalleri, vb.), TOR'un geliştirildiği ve sistem oluşturulurken kullanılması gereken.

TOR gereksinimlerinin türü ve bileşimi

Genellikle müşteri hedefi (anladığı gibi) ve kaynak kısıtlamalarını (zaman, para) belirler. Yüklenicinin görevi, her şeyden önce, gereksinimleri konu alanının diline çevirmek, görevi mümkün olduğunca eksiksiz ve yetkin bir şekilde formüle etmek ve çözme ihtiyacını haklı çıkarmaktır. Sonuç olarak, TOR aşağıdaki bilgileri içerecektir:

• Hedefler işlevsel biçim. Ürün yalnızca belirli bir malzeme taşıyıcısıdır. fonksiyonlar yerine getirilmesi belirlenen hedeflere ulaşmayı mümkün kılan (tatmin ihtiyaçlar). Ancak aynı işlev farklı cihazlar tarafından gerçekleştirilebilir. Bu nedenle, hedefin önemli bir göstergesinden ziyade işlevsel bir göstergesi, optimal çözümü bulmak için gerekli olan olası çözümlerin alanını genişletir. Ayrıca işlev, cihazın amacının özünü tanımlamak için daha açık bir terimdir. Hedeflerin netleştirilmesi ve bunlara karşılık gelen fonksiyonların atanması, TOR'un derlenmesi çalışmalarının en önemli kısmıdır;
• Verilen ihtiyaçları karşılayan işlevlerin performansı her zaman memnuniyetle bağlantılıdır. belirli gereksinimler(listeye bakınız standart gereksinimler ile teknik cihazlar), ürünleri daha çekici kılan, üretim ve operasyon vb. özelliklerini dikkate alır ve belirtir. Kolaylık sağlamak için gereksinimler türe göre üç gruba ayrılır:
  • koşullar belirli veri değerleri ile karakterize edilir (resmi olarak eşitlikler olarak gösterilebilirler). Örneğin ürünün kütlesi 10 kg olmalı, 40X çelik kullanılmalı, işlem yeri tundra olmalıdır. Koşulların önemli bir kısmı mevcut kaynakların değerlendirilmesi ile oluşur;
  • kısıtlamalar izin verilen veri alanını tanımlar (resmi olarak, bunlar tek taraflı veya iki taraflı eşitsizlikler olarak temsil edilebilirler). Örneğin, ürünün ağırlığı 10 kg'ı geçmemelidir, karbon çeliği kullanın;
  • kalite göstergeleri (optimizasyon kriterlerine dönüştürülür) yalnızca özelliklerin listesini ve tercih edilen değer için aramanın yönünü belirtir (maksimum veya minimum değer, örneğin, ürünün ağırlığı minimum olmalıdır ve bakım kolaylığı - maksimum ). özel anlam gösterge, yalnızca tasarım çalışması aşamasının veya tüm döngüsünün sonunda bilinir ve arama sürecinde bir tercih ölçüsü olarak hizmet eder. en iyi seçenek(son sürümü seçmenin temeli).

Tasarım süreci gibi, gereksinim yönetimi de yönetime tabidir. Bu prosedürler iyi yapılandırılmıştır, örneğin, yazılım gereksinimleri yönetimi.

Açıkça veya niteliksel olarak belirlenmemiş hedefleri ve gereksinimleri belirtmek için ayrıştırma yöntemi kullanılır.

Bir gereksinim sistemi oluştururken, aşağıdaki kaynakların analizi zorunludur:

• Müşterinin ve geliştiricinin emrinde olan kaynakların mevcudiyeti: finansal, üretim, insan, geçici. Tüm kaynaklar birbirine bağlıdır, örneğin proje finansmanını artırarak, geliştirme döneminde bir azalma elde etmek mümkündür. Erişilebilirlik derecesinin sonucu, seçilen modelin türünü etkileyen tasarım problemini çözme yöntemleri ve doğruluğu üzerinde kısıtlamaların getirilmesidir. Bu nedenle, sınırlı bir süre ile basitleştirilmiş yöntemler kullanarak tahmini hesaplamalar yaparlar veya hazır olanları kullanırlar. yazılım, standart yöntemler, tipik ekipman, standart ve satın alınan parçalar ve tertibatlar vb. Aynı zamanda, çözümün modeli, yöntemi ve doğruluğu, yüksek olsalar bile TOR gereksinimlerinin yerine getirilmesini sağlamalıdır.
• Örneğin teknolojik kompleksler (üretimler) tasarlanırken denetleme ve lisanslama makamlarının gereksinimlerini dikkate almak. Rusya Federasyonu yasalarına göre, herhangi bir üretim bölgesel bir işletme lisansı gerektirir. Ayrıca birçok sektör, denetim otoriteleri tarafından ruhsatlandırılmış ve onların denetimine tabidir. En sık kontrol edilenler bölgesel kuruluşlar Rostekhnadzor, Rosstandart, Rusya Bölgesel Kalkınma Bakanlığı (eski Gosstroy), Rospotrebnadzor, Rosprirodnadzor, Devlet Sınır Servisi, Rusya İçişleri Bakanlığı, Rostrud.
• Tasarlanan sistemin yaşam ortamı. Tasarlanan sistemin ve onu çevreleyen canlı ve cansız nesnelerin ve dış ortamın karşılıklı etkisini karakterize eden gereksinimleri belirler. Bunun için ana göstergeler, gelecekteki ürünlerin tüketim koşullarındaki teknik gerekliliklerde verilmiştir. Bu koşullar oldukça genel olarak karakterize edilebilir ve belirtilmesi gerekir.

TOR için gereksinimlerin bir listesinin hazırlanması

TOR üzerinde çalışmak bir dizi aşama içerir. Ve bu çalışmanın doğasında var olan belirsizlik, problemin daha genel bir ifadesinden ayrıntılı çalışmasına birkaç kez yinelemeli olarak geçirilmesine neden olur (tasarım, doğası gereği yinelemelidir ve başlangıçta dikkate alınmayanlar dikkate alınabilir. sonraki aşamalarda).

İlk önce Edison'un kendisine teknik bir problem nasıl koyduğuna dair bir hikaye verelim.

Edison, evde elektrikli aydınlatmanın geliştirilmesine başlamadan önce, gazlı aydınlatma (korna) ile fiyat, parlaklık ve rahatlık açısından hangi koşullarda rekabet edebileceğini araştırdı. Detayları inceledi gaz endüstrisi, merkezi bir elektrik santrali için bir plan ve evlere ve fabrikalara giden elektrik hatlarının bir şemasını geliştirdi. Ardından, buharla çalışan bir dinamo kullanarak lamba yapmak ve elektrik üretmek için gerekli olan bakır ve diğer malzemelerin maliyetini hesapladı. Veri analizi, lambanın sadece boyutlarını değil, aynı zamanda 40 sentlik rekabetçi fiyatını da belirledi. Ve ancak Edison, elektrik aydınlatması sorununu çözebileceğine ikna olduğunda, havanın dışarı pompalandığı bir cam topun içine yerleştirilmiş bir karbon filamanlı bir akkor lamba üzerinde çalışmaya başladı. Bir iplik malzemesi arayışında, yaklaşık 6.000 çeşit bitki lifini test etti.

Müşteri görevinin analizi

İlk görev müşteri tarafından verilir ve formda verilir. teknik gereksinimler. Bu gereklilikleri konu alanının diline çevirmek, sorunu olabildiğince eksiksiz ve yetkin bir şekilde formüle etmek, çözme ihtiyacını haklı çıkarmak, ilk verileri anlamak ve netleştirmek işin ilk aşamasıdır. Yüklenici bunu müşteri ile yakın temas halinde gerçekleştirir.

Aşağıdaki sorunları belirlemeli ve çözmekten kaçınmaya çalışmalısınız:

• sosyal ihtiyaçları karşılamayan görevler - suç, ahlak dışı, insanlık dışı. Kararları geliştiricinin vicdanına kalmış bir durumdur;
• yanlış belirlenmiş hedeflerle teknik sözde görevler. Bunlar zaten bir çözümü olan veya çözümleri için nesnel ön koşulları olmayan görevlerdir (erken görevler, ancak bu, çözmeyi reddetmenin psikolojik atalet veya diğer öznel nedenlerin sonucu olmaması için gerekçelendirilmelidir);
• kimerik görevler. Bunlar, başarısı fizik yasalarıyla çelişen (örneğin,% 100'den fazla verimliliğe sahip bir cihazın oluşturulması, anlık bir cihaz vb.) temelde hiçbir çözümü yoktur (bir filozofun taşı gibi).

TOR'u derlerken, başlangıç ​​gereksinimlerine önyargısız yaklaşmak önemlidir. Bunun için ihtiyacınız olan:

• belirtilen ihtiyaçların müşteri için gerçekten değerli olup olmadığından, ilk verilerin doğru olup olmadığından, olumsuz veya olumsuz olanlardan emin olmak için zararlı etkiler bu ihtiyacın gerçekleşmesi sürecinde ortaya çıkabilecek;
• ihtiyacın özünü bulun, oluşumunun kaynağını bulun;
• eski ürünün yeni ihtiyaçları karşılamak için kullanılmasını neyin engellediğini öğrenin.

Yeni geliştirme ihtiyacının ana nedeni, çelişkiler Arzu ve tatmin olasılığı arasında ihtiyaçlar. Çelişki yoksa, yeni ürünler yaratmadan ihtiyaç karşılanabilir. Çelişki yok gibi görünüyorsa, ancak mevcut çözüm uymuyorsa, bu, çelişkinin gerçekten var olduğu ve onu dikkatlice aramanız gerektiği anlamına gelir.

Çelişki ayrıştırılabilir, yani temel problemler şeklinde sunulabilir.

Çoğu durumda, bir prototip bilinmektedir: bir prototip veya müşteriyi tatmin etmeyi bırakan orijinal bir ürün. Bir prototipin varlığı çözümü basitleştirir, ancak yokluğu, her zaman en iyi sonuca yol açmayan önceden belirlenmiş çözümler biçiminde psikolojik atalet yaratmaz.

• veya varlığını unutun ve ilk ihtiyaçtan başlayarak teklif edin olası seçenekler en iyinin müteakip seçimi ile;
• ya IFR'yi kullanarak prototipi geliştirin;
• veya ihtiyacı yerelleştirin. Genellikle yetersiz çalışma, yalnızca bazı alt sistemlerin kusurlu olmasıyla ilişkilidir. Bu amaçla prototip, işlevsel bir özelliğe göre ayrıştırılır ve çelişki, temel problemler şeklinde sunulur. Temel problemleri prototipin belirli alt sistemleriyle ilişkilendirerek, "kusurlu" alt sistemler ortaya çıkar. Böylece, genel ve karmaşık bir problemi çözmekten daha basit bir özel probleme geçerler. Ancak özelliklerdeki iyileştirme derecesi düşük olabilir ve iyileştirilmiş alt sistemlerin öncekilerle eşleştirilmesinde sorunlar ortaya çıkabilir.

Tasarım hedeflerinin belirlenmesi

Geliştirme hedeflerinin netleştirilmesinden ve gerekçelendirilmesinden sonra ilgili işlevler atanır. Önyargılar ve psikolojik atalet, aramanın kapsamını daraltmaz ve müşteri, sorunu formüle ederek bir çözüm arayışının yönünü önceden belirlemez, işlevi genel ve tarafsız terimlerle formüle etmek istenir. Bu nedenle, “yıkmak” işlevini (örneğin, tahtalar) “bağlanmak” terimiyle değiştirmek daha iyidir; bu, doğal ilişkiden soyutlamamıza izin verir - çivilerle yıkmak ve daha geniş bir olası çözüm yelpazesi sunar. .

En eksiksiz ve doğru formülasyonu arama sürecinde, başlangıçta önerilenden nihai olana kadar bir işlevler zinciri (bir hedef ağacı) oluşturulur. Bu, “Bu neden gerekli?” Sorusunun cevabı ile yardımcı olur. (ve diğer yöntem soruları kontrol soruları). Çoğu durumda, gereksinimlerde verilen hedefin arkasında, birkaç işlevi (ardışık veya aynı anda) gerçekleştirme ihtiyacı vardır. Her biri için bir işlevler zinciri oluşturulmuştur.

Bir tür önlem alma ihtiyacının yanı sıra, bir eylemde bulunmama ya da olumsuz etkisi olan bir eylemde bulunma ihtiyacı da olabilir.

Toplanan bilgilerin işlenmesi

1. Genelleme ve soyutlama.
Bağlama ve özetleme ayrı parçalar böylece, mümkünse, olası değişiklikler dikkate alınarak geliştirilmekte olan nesne hakkında eksiksiz, açık ve özlü bir fikir elde edilir. Birbirini başka kelimelerle tekrarlayanlar veya özel bir durum da dahil olmak üzere mükerrer bilgiler kaldırılır.

Soyutlamanın amacı, problemi çözmenin yollarını önceden belirlemekten kaçınarak (psikolojik engeller oluşturmayacak şekilde) gereksinimleri formüle etmektir. "Güçlü" çözümler elde etmek için, gereksinimler sistemini güçlendirmeniz ve IFR'yi formüle ederek çelişkileri ağırlaştırmanız önerilir.

2. Tutarsızlık olup olmadığını kontrol edin.
Birkaç işlev varsa, bazıları eylemlerinde çelişkili olabilir (örneğin, su sıcak olmalıdır (demlemek için), ancak ellerinizi yakmamalıdır). Çelişkileri gidermek için buluşsal yöntemleri kullanmak etkilidir. Aynı zamanda, çelişkilerin ortadan kaldırılması, hem TOR'u hazırlama aşamasında (fonksiyonların formülasyonlarını değiştirme, eylemlerini zaman veya uzayda bölme, vb.) Hem de sonraki tasarım aşamalarında mümkündür.

Koşullar ve kısıtlamalar da tutarsızlıklar için kontrol edilmelidir. Dolayısıyla kısıtlamalar boş bir küme tanımlayabilir. Bu tür çelişkiler her zaman açık değildir: üst ve alt sınırlar hakkındaki bilgiler farklı zamanlarda gelebilir veya farklı yerler TK, örtük bir biçimde sunulmalıdır.

3. Koşullar, kısıtlamalar ve kalite göstergeleri için gereksinimlerin sınırlandırılması.
Gereksinimlerin göstergeler şeklinde temsil edilmesi, yüksek performanslı çözümler elde etmeyi mümkün kılar, ancak bu görevin çözülmesi daha zordur. Göstergeler olarak, en önemli özellikleri karakterize edenler seçilir (en iyi değerleri elde edebilmek için). Girdi koşulları için, yayılmanın büyüklüğünü değerlendirmek ve sınır değerleri belirlemek, yani bunları kısıtlamalar şeklinde sunmak gerekir.

4. Parametrelendirme.
Yargının doğruluğu ve seçimin doğruluğu, resmileştirilmiş veya resmi olmayan bir biçimde sunulup sunulmadıklarına bakılmaksızın, ilk gereksinimlerin özgüllük derecesine bağlıdır. Kesin sonuçlar için, tüm gereksinimler resmi bir forma çevrilmelidir, yani bunları karakterize eden parametreler, ayrıca ölçülebilen, kontrol edilebilen, hesaplanabilenler belirtilir. Bu aynı zamanda yinelenen gereksinimleri (aynı parametrelerle karakterize edilenler) vurgulamanıza ve bunları genelleştirmenize (toplam sayılarını, belirli özelliklerini azaltmak için genelleştirilmiş parametreleri tanıtmanıza) olanak tanır.

Optimal tasarım problemini çözerken, kalite göstergelerinin ölçütlere dayalı resmileştirilmiş bir forma indirgenmesi, yani sayısal bir ölçü verilmesi tavsiye edilir. Formülasyonları belirlemenin ana yöntemi, bir hedefler ağacının (VE veya VEYA-ağaçları) oluşturulmasıdır: ilk gösterge, parametre setleri tarafından benzersiz bir şekilde karakterize edilen temel kavramları ortaya çıkarmak için ayrıştırılır.

"Qualimetri" bilimi, nicel göstergeler aracılığıyla kaliteyi değerlendirme problemleriyle ilgilenir.

5. Gereksinimler listesinin kısaltılması.
Büyük miktarda bilgi, çözülmekte olan sorunun en eksiksiz resmini verebilmesine rağmen, kafada tutmak daha zordur ve sorunun çözümünü karmaşıklaştırır. Bilgileri makul bir miktara indirmek için (her belirli geliştiricinin yeteneklerine, finansal, organizasyonel, teknik ve geçici kaynaklarına uygunluğuna göre), sıralamalarını veya zorunlu, istenen ve önemsiz gruplara ayrılmasını kullanabilirsiniz. Zorunlu olanlar, memnuniyetsizliği çözüm seçimini önemli ölçüde etkileyenleri içerir. Bunlar işlevsel parametreler, sistemlerin ve parçalarının birbirine bağlanması için koşullar ve diğerleridir. Arzu edilen gereksinimler, seçenekleri kalite derecesine göre ayırt etmeyi mümkün kılar.

Lee Iacocca'nın sözlerini dikkate almakta fayda var: "... sorun şu ki Harvard'da okudunuz, tüm gerçekleri toplamadan hiçbir şey yapamayacağınız kafanıza kazındı. Bilgilerin %95'ine sahipsiniz ve eksik %5'i toplamak için altı aya daha ihtiyacınız olacak. Bu süre zarfında, tüm gerçekler modası geçmiş olacak çünkü piyasa çok daha hızlı gelişiyor. Hayattaki en önemli şey her şeyi zamanında yapmaktır. … asıl görev, sizin için mevcut olan tüm önemli gerçekleri ve bakış açılarını toplamaktır. Ancak bir noktada kararlı bir şekilde hareket etmeye başlamanız gerekiyor. Birincisi, çünkü en çok doğru kararçok geç kabul edilirse yanlış olduğu ortaya çıkar. İkincisi, çünkü çoğu durumda mutlak kesinlik diye bir şey yoktur. Hiçbir zaman bilgilerin %100'ünü toplayamayacaksınız. Ne yazık ki, olası tüm yanlış hesaplamaları ve kayıpları değerlendirene kadar hayat beklemeyecektir. Bazen rastgele ilerlemeniz ve yol boyunca hataları düzeltmeniz gerekir.

6. Gereksinimlerin tek bir belgede birleştirilmesi ve müşteri tarafından onaylanması.

Edebiyat

• Khoroshev A.N. Mekanik Sistem Tasarım Yönetimine Giriş: öğretici. - Belgorod, 1999. - 372 s. - ISBN 5-217-00016-3 Elektronik sürüm 2011

İş tanımı hem yüklenici hem de müşteri için önemlidir. Yüklenicinin müşterinin ne istediğini daha iyi anlamasına, müşterinin ani “isteklerine” karşı sigorta yapmasına ve işi tamamlama işini hızlandırmasına yardımcı olur. Müşteriye - tam olarak ne istediğini söylemek, kalite kontrolünü basitleştirmek, hizmetin tam maliyetini almak. Bir TOR'u nasıl düzgün bir şekilde hazırlayacağınızı ve onunla ne yapacağınızı daha sonra anlatacağız.

teknik görev nedir

İş Tanımı - gelecekteki bir ürün için tüm gereksinimleri yansıtan bir belge. Tüm teknik gereksinimleri açıklar. Tipik olarak, TOR'lar şu şekildedir: Metin belgesi, nadiren diğer biçimlerde.

TK, tüm web sitesi geliştiricileri tarafından kullanılır. Dizgiciler, programcılar, tasarımcılar için müşterinin gereksinimlerini daha iyi anlamaya ve beklentilerini karşılayan bir kaynak oluşturmaya yardımcı olur. Ek olarak, TK diğer tüm alanlarda kullanılır, örneğin - şu alanlarda:

• uygulama geliştirme;
• ev tasarımı;
• metin yazma ve diğerleri.

Görev tanımına göre çalışırsanız, anlaşmazlık ve uzayan dava riski en aza indirilir.

Teknik bir görev nasıl hazırlanır: site için teknik özelliklerin yapısı

Çalışmaya başlamadan önce:

• Referans şartlarını kimin yazacağına karar verin
• terimleri açıklayın
• Sübjektif terimlerden kaçının

İlk bakışta, sitenin teknik özelliklerinin müşteri tarafından yapılması gerektiği görülüyor., çünkü bir kaynak sipariş eder ve ondan talepte bulunur. Aslında, her ikisi de sürece katılmalıdır: müşteri gereksinimleri dile getirir ve icracı bunları özel, doğru ve net bir şekilde yazar. Örneğin, müşteri, tüm kullanıcılara uyarlanmış bir site istediğini söylüyor ve geliştirici, 4'ün altında uyarlanabilirlik gereksinimleri öngörüyor. Mevcut boyutlar- PC'ler, dizüstü bilgisayarlar, tabletler, akıllı telefonlar.

Terimlerin açıklaması - çok önemli nokta . Tüm son derece özel terimlerin en baştan açıklanması tavsiye edilir - müşteriler her zaman bodrum (alt bilgi), CMS, balığın ne olduğunu bilmezler. Açıklamalar ne kadar basit ve net olursa, TOR her iki taraf için de o kadar net olacaktır.

Öznel terimler gereksiz tartışmalara neden olabilir. "Tasarım güzel olmalı" yazmayın - güzellik kavramı herkes için farklıdır. Aynısı “uygun”, “kullanımı kolay”, “büyük” kalite sıfatları için de geçerlidir. Belirli sayılar ve parametreler kullanın: örneğin, renk şemasını veya öğelerin düzenini tanımlayın.

Teknik görevin yapısı herhangi biri olabilir. Örnek olarak, site için basit bir TOR yapısı sunuyoruz.

siteyi tanımla

Ne tür bir siteye ihtiyacınız olduğunu, kimin kullanacağını, ne için oluşturulduğunu bize bildirin. Örneğin, bir çevrimiçi mağazaya, bir ürünü satmak için bir açılış sayfasına veya 10 sayfalık bir kartvizit web sitesine ihtiyacınız olduğunu yazın. Tam sayıyı bilmiyorsanız yaklaşık sayfa sayısını belirtin.

Projenin belirli bir hedef kitlesi varsa, bunu açıklayın. Bu, müşterilere hitap edecek bir kaynak yaratmaya yardımcı olacaktır - örneğin, makalelerde veya tasarımlarda gençlere veya yaşlılara hitap eden uygun bir dil kullanmak.

Bana yapısından bahset

Yapıyı anlamadan normal bir site geliştirmek imkansızdır. Sitede hangi sayfaların olacağını açıklayın ve iç içe geçme düzeylerini gösterin. Bunu farklı şekillerde yapabilirsiniz:

• şema
• masa
• liste

Ana şey, sonunda menüde hangi sayfaların bulunacağı, nereye yönlendirileceği, her bölümün hangi ana sayfaya sahip olacağı açıktır. Akış şemalarını kullanmanızı öneririz - liste ve tablolardan daha basit ve okunması daha kolaydır, sitenin tüm yapısını birkaç saniye içinde değerlendirmeye yardımcı olurlar.

Blok diyagram şeklinde en basit yapıya bir örnek

Her sayfada ne olacağını açıklayın

Bize sitenin sayfalarını nasıl gördüğünüzü söyleyin. Her bir elemanın yerini açıkça göstermek için bunu bir prototip formatında yapmak arzu edilir. Gereksinimleri bir liste ile de tanımlayabilirsiniz, örneğin - sitenin başlığında ne olacağını, geri bildirim formunun nerede olduğunu, serbest yan sütunda ne olacağını söyleyin.

Sitenin tüm sayfaları yaklaşık olarak benzerse - örneğin, bir kartvizit sitesi oluşturmayı planlıyorsanız, iki prototiple yapabilirsiniz: ana sayfa ve diğer bölümler. Birkaç benzer sayfa grubu varsa - örneğin, bir çevrimiçi mağazanın kataloğundaki bölümler, makaleler içeren bir blog ve teslimat / montaj / kurulum hizmetlerinin açıklaması, her grup için kendi prototipinizi yapmak daha iyidir.

Sitenin ana sayfasının prototipine bir örnek: her şey basit, kullanışlı, anlaşılır

Tasarım talepleri yapın

Gelişmiş bir düzen varsa, harika - bunu referans şartlarına ekleyebilirsiniz. Değilse, renkler, kullanılan resimler, logolar için gereksinimleri açıklamanız gerekir. Örneğin:

• Tasarımda hangi kurumsal renklerin kullanılabileceğini ve hangi tonların kesinlikle kullanılmayacağını belirtin.
• Sitenin başlığında bulunması gereken bir logo sağlayın
• Sayfaların, menülerin, altbilgilerin, içeriğin tasarımı için kullanmak istediğiniz yazı tiplerini belirtin

Açık gereksinimler yoksa - yani, müşterinin kendisi site vizyonunu formüle edemezse, ona aralarından seçim yapması veya bireysel olarak bir düzen geliştirmesi için birkaç standart düzen sunabilir ve ardından üzerinde anlaşabilirsiniz. Bu, TOR'un onayından önce yapılmalıdır, aksi takdirde zevklerdeki farklılık projeyi önemli ölçüde geciktirebilir.

Araçlar, kod, barındırma, etki alanı için gereksinimleri açıklayın

Bu, hangi araçlarla çalışabileceğinizi ve hangilerini yapamayacağınızı önceden bilmek için gereklidir. Ayrı bir blokta tanımlayın:

• Hangi sitede olmalı - WordPress, Joomla, Modex vb.
• Hangi programlama dili kullanılabilir - PHP, JavaScript, HTML, diğerleri
• Sitenin hangi barındırmada ve hangi alan bölgesinde bulunması gerektiği, hangi alan adı kullanılabilir
• Hangi yazılım platformu kullanılabilir - .NET, OpenGL, DirectX
• Ve benzeri

İstemci kullanılan terimlerden hiçbir şey anlamıyorsa, WordPress'in Modex'ten, PHP'nin HTML'den, .ru bölgesindeki bir alan adının .com bölgesindeki bir alandan nasıl farklı olduğunu açıklayın. Birlikte, gereksinimleri müşteriye uyacak şekilde yapın.

Site gereksinimlerini belirtin

Varsayılan olarak, site tüm cihazların kullanıcıları için farklı tarayıcılarda çalışmalı, bilgisayar korsanlarının saldırılarına dayanmalı ve aynı anda 1000 kullanıcı ziyaret ettiğinde açık kalmalıdır. Ancak ayrı bir blokta yazmak daha iyidir. Belirtiniz:

• Sizin için kabul edilebilir site yükleme hızı veya standart bir değer - 1-5 saniye
• Tarayıcılar arası uyumluluk - sitenin hangi tarayıcılarda açılması gerektiğini açıklayın
• Duyarlılık - tasarımın uyması gereken ekran boyutlarını ve kullanılan cihazları belirtin
• Yük direnci - "yatmaması" için sitede aynı anda kaç kişi olmalıdır
• Hacker ve dDos saldırılarına karşı dayanıklılık: site küçük saldırılara dayanmalıdır

Site için senaryolar yazın

Kullanıcının siteyle nasıl etkileşime girmesi gerektiğini ve yanıt olarak kaynakta hangi eylemlerin gerçekleştirilmesi gerektiğini açıklayın. Bu, kullanıcıların eylemler arasında bir seçeneği varsa, basit bir numaralandırılmış liste veya dallı bir algoritma şeklinde yapılabilir. Çok sayıda etkileşimli hizmet varsa, her biri için bir komut dosyası yazın.

Sitenin en basit senaryosuna bir örnek

İçeriği kimin yaptığını öğrenin.

Bazı geliştiriciler metinleri kendileri yazar, birileri metin yazarlarından sipariş eder, biri balık kullanır. İçeriğin sağlanmasının geliştirme hizmetine dahil olup olmadığını hemen netleştirin. Öyleyse, örneğin aşağıdakiler için ek gereksinimleri hemen belirtebilirsiniz:

• - Advego, Text.ru, Content.Watch'a göre en az %95
• Bulantı (spam) - Advego'ya göre %10'dan veya Text.ru'ya göre %65'ten fazla değil
• Glavred için puan - en az 6.5 veya 7 puan

Elbette, farklı hizmetler her derde deva değildir, ancak "sulu" veya istenmeyen posta olma riskini en aza indirirler. Ek olarak, metinlerin kalitesini değerlendirmek için bu kadar doğru kriterler ortaya çıkıyor.

Şartları belirtin

Bu çoğu zaman unutulur. Referans şartlarının çoğu şartları belirtmelidir, aksi takdirde geliştirme birkaç ay, yarım yıl, yıllarca sürebilir. Yanlış ifade kullanmayın - örneğin, "bir ay içinde". Kesin tarihi yazın: örneğin 1 Aralık 2018.

Hayat kesmek:İşbirliği anlaşmasının bir eki olarak görev tanımını hazırlamak daha iyidir. Böylece sitenin gelişimi için tüm gereksinimleri giderirsiniz ve anlaşmazlık durumunda davayı mahkemede kazanabilirsiniz.

Unutmayın: Her TK'de birkaç ana blok olmalıdır:

• Hedefler ve hedefler - genel olarak TK'yi neden yarattığınız, ürünle ne yapmak istediğiniz hakkında
• Ürün ne olmalı - genel anlamda bir açıklama
• Teknik gereksinimler- evin alanı, metnin hacmi, uygulamanın işlevselliği vb.
• Son tarihler - anlaşmazlıkları ortadan kaldırmak için önemlidir.

Yazılım için teknik şartname hazırlama örneği

Yazılım oluşturmamız gerekiyor. Teknik gereksinimler - aşağıda.

Tanım: tüm yetkili sitelerde anahtar kelimeye göre makale aramak için bir program, yetkili sitelerin adreslerini manuel olarak girmeniz gerekir.

Yazılımın yapması gerekenler:bir anahtar kelime girdikten sonra, yetkili kaynaklar olarak önceden girilen sitelerdeki makaleleri bulur, şu biçimde bir eşleşme listesi görüntüler:

• Bağlantı
• Makale başlığı
• ana paragraf

10'dan fazla eşleşme varsa, sayfalara bölmeniz gerekir - her birinde 10.

Teknik gereksinimler:programlama dili - herhangi biri, önemli değil. Ana şey, programın daha sonra sonuçlandırılabilmesi ve çevrimiçi bir hizmet olarak sunulabilmesidir. İdeal olarak, hizmet 10 saniye aramalıdır.

Zamanlama: 15.09.2018 tarihine kadar.

Doğal olarak, bu TOR geliştirilebilir - bunu bir örnek olarak sağladık. Ve nasıl daha açık, daha basit, daha uygun hale getirmek için görev tanımları nasıl geliştirilebilir?

G O S D A R S T V E N N Y S T A N D A R T S O YU Z A S S R

Birleşik program dokümantasyonu sistemi	GOST 19.201-78 (ST SEV 1627-79)
TEKNİK GÖREV. İÇERİK VE TASARIM GEREKLİLİKLERİ
Program dokümantasyonu için birleşik sistem. Geliştirme için teknik şartname. İçerik ve sunum şekli için gereklilikler

kararname Devlet Komitesi 18 Aralık 1978 No. 3351 standartlarına göre SSCB, tanıtım dönemi belirlendi

01.01'den itibaren. 1980

Bu standart, bir program veya yazılım ürününün geliştirilmesi için teknik özelliklerin oluşturulması ve yürütülmesi için prosedürü belirler. bilgisayarlar, kompleksler ve sistemler, amaçları ve kapsamı ne olursa olsun.

Standart, ST SEV 1627-79 ile tamamen uyumludur.

1. GENEL HÜKÜMLER

1.1. Referans şartları, kural olarak, sayfa alanlarını doldurmadan GOST 2.301-68'e göre 11 ve 12 formatındaki sayfalarda GOST 19.106-78'e göre düzenlenir. Sayfa sayıları (sayfalar), sayfanın üst kısmında metnin yukarısına yazılır.

1.2. Onay sayfası ve baş sayfa GOST 19.104-78'e göre hazırlanır.

Bilgilendirme kısmı (özet ve içerik), değişiklik kayıt sayfası belgeye dahil edilmeyebilir.

1.3. Bir program veya yazılım ürünü geliştirmenin sonraki aşamalarında görev tanımlarında değişiklik veya eklemeler yapmak için bir zeyilname düzenlenir. Görev tanımına ekin koordinasyonu ve onayı, görev tanımı için belirlenen şekilde gerçekleştirilir.

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

• giriiş;
• gelişme gerekçeleri;
• geliştirme amacı;
• program veya yazılım ürünü için gereksinimler;
• yazılım belgeleri için gereksinimler;
• teknik ve ekonomik göstergeler;
• gelişim aşamaları ve aşamaları;
• kontrol ve kabul prosedürü;
• başvuruların referans şartlarına dahil edilmesine izin verilir.

Programın veya yazılım ürününün özelliklerine bağlı olarak, bölümlerin içeriğinin netleştirilmesine, yeni bölümlerin tanıtılmasına veya bazılarının birleştirilmesine izin verilir.

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

(Değiştirilmiş baskı, Rev. No. 1)

2.2. Geliştirmenin Temeli bölümü şunları içermelidir:

• geliştirmenin gerçekleştirildiği belge (belgeler);
• bu belgeyi onaylayan kuruluş ve onay tarihi;
• geliştirme konusunun adı ve (veya) sembolü.

(Değiştirilmiş baskı, Rev. No. 1)

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

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

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

(Değiştirilmiş baskı, Rev. 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, zamansal özellikler vb.

2.4.2. "Güvenilirlik gereksinimleri" alt bölümü, güvenilir çalışmayı sağlamak için gereksinimleri belirtmelidir (kararlı çalışmanın sağlanması, giriş ve çıkış bilgilerinin kontrolü, bir arızadan sonra kurtarma süresi, vb.).

2.4.3. “Çalışma koşulları” alt bölümünde, çalışma koşulları (ortam hava sıcaklığı, bağıl nem vb. Belirtilen özelliklerin yanı sıra hizmet türünü sağlaması gereken seçilen veri taşıyıcı türleri için), Gerekli miktar ve personel nitelikleri.

2.4.4. "Teknik araçların bileşimi ve parametreleri için gereklilikler" alt bölümünde, ana teknik özelliklerinin bir göstergesi ile gerekli teknik araçların bileşimi belirtilir.

2.4.5. "Bilgi ve program uyumluluğu için gereklilikler" alt bölümü, giriş ve çıkıştaki bilgi yapıları ve çözüm yöntemleri, kaynak kodları, programlama dilleri ve programın kullandığı yazılım araçları için gereksinimleri belirtmelidir.

Gerektiğinde bilgi ve programlar korunmalıdır.

(Değiştirilmiş baskı, Rev. No. 1)

2.4.6. "Etiketleme ve paketleme gereksinimleri" alt bölümünde Genel dava yazılım ürünü etiketlemesi, paketleme seçenekleri ve yöntemleri için gereksinimleri belirtin.

2.4.7. “Taşıma ve depolama gereksinimleri” alt bölümünde, yazılım ürünü için taşıma koşulları, saklama yerleri, saklama koşulları, depolama koşulları, çeşitli koşullar altında saklama süreleri belirtilmelidir.

2.5a. "Yazılım belgeleri için gereklilikler" bölümü, yazılım belgelerinin ön bileşimini ve gerekirse bunun için özel gereksinimleri belirtmelidir.

(Ek olarak tanıtıldı, Rev. No. 1).

2.5. "Teknik ve ekonomik göstergeler" bölümünde belirtilmelidir: gösterge niteliğinde ekonomik verim, 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ştirmenin aşamaları ve aşamaları" bölümünde, gerekli geliştirme aşamaları, işin aşamaları ve içeriği (geliştirilmesi, üzerinde anlaşmaya varılması ve onaylanması gereken program belgelerinin bir listesi), ayrıca kural olarak geliştirme zaman çerçevesi ve Uygulayıcıların kurulduğunu belirlemek.

2.7. "Kontrol ve kabul prosedürü" bölümünde, işin kabulü için test türleri ve genel şartlar belirtilmelidir.

2.8. Görev tanımının eklerinde, gerekirse şunları sağlayın:

• gelişmeyi doğrulayan araştırma ve diğer çalışmaların bir listesi;
• geliştirmede kullanılabilecek algoritma şemaları, tablolar, açıklamalar, gerekçeler, hesaplamalar ve diğer belgeler;
• diğer gelişme kaynakları.

Temmuz 1981'de onaylanan Değişiklik No. 1 ile yeniden düzenleme (Kasım 1987) (IUS 7-81)

Proje kapsamının belirlenmesi, teknik şartnamelerin geliştirilmesi

AT bu bölüm kısaca görev tanımlarının geliştirilmesi konusunu ele aldı (bundan böyle TOR olarak anılacaktır). İlk olarak, TK'nin bir tanımı verilmiş, TK'nin hem müşteri hem de yüklenici için avantajları açıklanmış ve TK'nin temel işlevleri sıralanmıştır. Ayrıca, TK'nın özünün ne olduğu ele alınmakta, TK'nın yapısı ve içeriği açıklanmakta ve TK'nın yapısına ilişkin örnekler de verilmektedir. Sonuç olarak, yenilikçi projelerin TOR'unun özellikleri not edilmiştir.

Yenilikçi bir proje için teknik şartname geliştirme görevleri, kendi özelliklerine sahip, prensipte herhangi bir teknik şartnamenin geliştirilmesinde olduğu gibi kaldığından, ilk önce teknik şartnamelerin bir bütün olarak geliştirilmesi konusu ele alındı.

Tanım

Bu noktada, yenilikçi bir proje için standart bir görev tanımı (TOR) tanımı bulunmadığına dikkat edilmelidir. mevcut veritabanında ulusal standartlar TK ile ilgili üç standart vardır. Hepsi bilgi teknolojisi alanına aittir:

GOST 19.201-78. Birleşik program dokümantasyonu sistemi. Teknik görev. İçerik ve tasarım gereksinimleri.

GOST 25123-82. Bilgisayar makineleri ve veri işleme sistemleri. Teknik görev. Yapım sırası, sunumu ve tasarımı.

GOST 34.602-89. Bilgi Teknolojisi. Otomatik sistemler için standartlar seti. Otomatik bir sistemin oluşturulması için referans şartları.

Örneğin, "GOST 19.201-78. Birleşik program dokümantasyonu sistemi. Teknik görev. İçerik ve tasarım için gereklilikler", aşağıdaki TOR tanımı verilmiştir: "Otomatik bir sistem için referans şartları - içinde onaylanmıştır. Vaktinden Otomatik bir sistemin geliştirilmesi için gerekli olan hedefleri, gereksinimleri ve temel girdi verilerini tanımlayan ve ekonomik verimliliğin ön değerlendirmesini içeren bir belge.

TK'nin aşağıdakilere izin verdiğini söylüyor:

yükleniciye - görevin özünü anlamak, müşteriye gelecekteki ürünün, yazılım ürününün veya otomatik sistemin "teknik görünümünü" göstermek;

müşteri - tam olarak neye ihtiyacı olduğunu anlamak için;

her iki taraf da - bitmiş ürünü sunmak;

yürütücüye - projenin uygulanmasını planlamak ve plana göre çalışmak;

müşteriye - yükleniciden ürünün TOR'da belirtilen tüm koşulları karşılamasını talep etmek;

yükleniciye - Görev Tanımında belirtilmeyen işleri yapmayı reddetmek;

müşteriye ve yükleniciye - bitmiş ürünün nokta nokta kontrolünü yapmak (kabul testi - yürütme testler);

değişen gereksinimlerle ilişkili hatalardan kaçının (oluşturmanın tüm aşamalarında ve aşamalarında, aşağıdakiler hariç). testler).

Bu nedenle, referans şartları, bir dizi gereksinimleri içeren ve hem geliştiricinin hem de müşterinin nihai ürünü sunmasına ve ardından gereksinimlere uygunluğu kontrol etmesine olanak tanıyan bir belgedir.

TOR ne kadar ayrıntılı olursa, o kadar az tartışmalı durumlar kabul testi sırasında müşteri ve geliştirici arasında ortaya çıkacaktır.

TK dört ana işlevi yerine getirir:

Yasal. TK yasal bir belgedir ve uygulama olarak müşteri ile yüklenici arasındaki sözleşmede yer alır.

organizasyonel. TK'nin yardımıyla, daha fazla çalışmayı düzene sokabilir, onu bir görev kuyruğuna (şemasına) dönüştürebilir ve gereksiz eylemler için çaba harcamayın.

bilgilendirici. İyi yazılmış bir Görev Tanımı, bir projeyi tamamlamak için ihtiyaç duyulan iyi bir bilgi kaynağı olabilir. TK'nin yapılandırılması, en kolay algılanan biçimde ve işi tamamlamak için gerekli miktarda gerçekten ilgi çekici bilgilere sahip olmanızı sağlar.

iletişimsel. Ayrıntılı bir TOR, yüklenicinin müşterinin ihtiyaçlarını daha iyi anlamasına ve her zevke uygun işleri gerçekleştirmesine yardımcı olur. Bu aynı zamanda proje onay sürecini de kolaylaştırır.

TK'nin Özü

TOR üzerinde çalışmak, bazı görevlerin çözümünün varsayıldığı ve bu belgede adım adım anlatıldığı anlamına gelir. TK her şey için geliştirilebilir: teknoloji, yeni malzeme, cihaz, web sitesi, program, standart, bir etkinliğin uygulanması vb.

Projenin uygulanması sırasında elde edilen nihai sonuçlar maddi (malzemeler, süreç, teknoloji), organizasyonel (norm, standart), bilimsel, teknik ve bilimsel ve metodolojik (tasarım belgeleri, araştırma raporu, eğitim programı), maddi olmayan ( patentler, monograflar, makaleler) ve diğer formlar.

TK'nin özü, görevin başarıyla tamamlanmasıdır. TOR ne kadar iyi ve iyi hazırlanırsa, görev o kadar etkili bir şekilde tamamlanacaktır. Ayrıca, ölçeğine bağlı değildir. TOR'un yanlış hazırlanması, örneğin sonucun tahmin edilemezliği, işin müşteri tarafından yapılması gerektiği gibi yapılmaması veya hiç yapılmaması gibi sonuçlara yol açabilir. İşin müşterisi istediğini alamayacak ve yapılan işin bedelini ödememe hakkına sahiptir.

TK üzerinde çalışmak, henüz birçok veri bilinmediğinden zor ve sorumlu bir aşamadır. Uzmanlara göre projenin başarısı %50-70 oranında, TOR'un geliştirme aşamasının nitelikli bir şekilde uygulanmasına bağlıdır.

Kural olarak, teknik özelliklerin geliştirilmesi aşamasından önce konu alanı, hesaplamalar ve modelleme çalışması yapılır.

TK üzerinde sorumlu çalışma, geliştiricilerinin görevi tamamlama senaryosunu görmelerini sağlayacaktır. Güçlü ve zayıf yönlerinizi, görevi tamamlama sürecini nasıl yaşayacağınızı açıkça anlayın. Kriterleri belirleyin, göstergeleri, özellikleri, miktarları belirleyin, kaynakları değerlendirin.

TK, müşteri ile kararlaştırılır veya ortaklaşa geliştirilir.

Önemine rağmen, TK'nin içeriği ve yapısı pratik olarak düzenleyici belgeler tarafından düzenlenmemiştir.

Genellikle müşteri hedefi (anladığı gibi) ve kaynak kısıtlamalarını (zaman, para) belirler. Yüklenicinin görevi, her şeyden önce, gereksinimleri konu alanının diline çevirmek, görevi mümkün olduğunca eksiksiz ve yetkin bir şekilde formüle etmek, çözme ihtiyacını haklı çıkarmak, ilk verileri anlamak ve netleştirmektir. Şartnamenin içeriği, her zaman belirli gereksinimlerin karşılanmasıyla bağlantılı olan, belirlenmiş ihtiyaçları uygulayan işlevlerin amaçları ve performansı ile ilgili bilgileri içermelidir.

Gereksinimlerle çalışmak yönetime tabidir. Belirsiz gereksinimler, gereksinimlerin farklı yorumlanmasına izin verdiğinden ve geliştirilmekte olan ürünün kalitesinin objektif bir değerlendirmesine izin vermeyeceğinden, çalışmadaki tüm katılımcılar arasında belirsizliğe neden olur.

Bir gereksinimler sistemi oluştururken, müşterinin ve geliştiricinin emrindeki kaynakların mevcudiyetini analiz etmek gerekir: finansal, üretim, insan, geçici ve ayrıca denetleme ve lisanslama makamlarının gereksinimlerini dikkate alarak, örneğin , teknolojik kompleksler (üretimler) tasarlarken. En sık kontrol edilenler, Rostekhnadzor, Rosstandart, Rospotrebnadzor, Rosprirodnadzor vb. bölgesel kuruluşlardır.

Aşağıdakiler, çeşitli kaynaklardan TK yapısının örnekleridir.

Örneğin, bir TK bölümleri içerebilir:

TK'nin konusu;

yapılan işin amacı;

raporlama gereksinimleri;

iş organizasyonu sırası;

Yukarıda belirtilen GOST 19.201-78'den bir örnek.

giriiş;

gelişme gerekçeleri;

geliştirme amacı;

program veya yazılım ürünü için gereksinimler;

yazılım belgeleri için gereksinimler;

teknik ve ekonomik göstergeler;

gelişim aşamaları ve aşamaları;

kontrol ve kabul prosedürü;

başvuruların referans şartlarına dahil edilmesine izin verilir.

Danışmanlık hizmetlerinin sağlanması için aşağıdaki TOR örneği

Genel Hükümler;

çalışmanın amacı;

adaylar için yeterlilik şartları.

"Perm şehrinde bir teknoloji ve yenilik parkının oluşturulması için bir konsept geliştirme, geliştirme stratejisi ve fizibilite çalışması" araştırma çalışmasının uygulanması için bir TOR örneği (bundan sonra Ar-Ge olarak anılacaktır)

araştırma için temel

icracı ve ortak sanatçılar

1. araştırma hedefleri

   ilk veri

   araştırma yapmak için temel gereksinimler

   araştırmanın uygulanması için takvim planı

   araştırma sonuçlarının amaçlanan kullanımı

   araştırma sonuçlarının teslimi ve kabulü için prosedür

Ar-Ge için TOR şablonunun yapısına bir örnek

İş için temel

yürütücü

çalışma şartları

çalışmanın amacı

Ar-Ge sonuçları

Geliştirme aşamasındaki ürünler

Teknik gereksinimler

Çalışma sonucunda ulaşılması gereken ana parametreler:

Temel tasarım gereksinimleri (varsa)

Teminat türlerine göre gereklilikler (varsa)

Standardizasyon, birleştirme, eşleşen nesnelerle uyumluluk ve değiştirilebilirlik için gereksinimler.

İnsan hayatı, sağlığı ve çevrenin korunması için güvenliğin sağlanması için gereklilikler

Güvenilirlik gereksinimleri (varsa)

Güvenilirlik ve dayanıklılık gereksinimleri.

Ergonomi ve teknik estetik gereksinimleri (varsa)

Çalıştırma gereksinimleri, kolaylık Bakım onarım ve sürdürülebilirlik (varsa)

Esneklik gereksinimleri (varsa)

Performans gereksinimleri (varsa)

Sertifika Gereksinimleri

Sektöre göre diğer gereksinimler ve özel gereksinimler

Patent saflığı ve patentlenebilirlik için gereklilikler

Belge Gereksinimleri

Eserlerin kabul sırası.

Bu nedenle, verilen örneklerdeki yapıyı analiz ederek, TK'nin yapısının ve içeriğinin yapılması gereken görev tarafından belirlendiği not edilebilir.

Yenilikçi bir proje için teknik özelliklerin geliştirilmesinin özellikleri

Yenilikçi projeler, bilimsel ve teknik fikirlerin yeni veya geliştirilmiş ürünlere ve ayrıca pratik faaliyetlerde kullanılan yeni veya geliştirilmiş teknolojik süreçlere veya sosyal hizmetlere yönelik yeni yaklaşımlara dönüştürülmesiyle ilişkili oldukları için benzersiz olaylardır. Daha önce hiç yapılmamış bir şey yapmak zorunda. Ve geçmiş deneyim, ne bekleyeceğine dair yalnızca sınırlı bir gösterge verebilir. Bu nedenle, yenilikçi projeler yüksek derecede belirsizlik ve risk içerir ve bu onların özelliğidir.

Yenilikçi bir projenin geliştirilmesi, projenin amaçlanan nihai fikrini elde etmek için çözümler bulmayı ve bu yenilikçi projenin uygulanması için zaman, kaynaklar ve sanatçılar tarafından birbirine bağlanacak bir dizi görev ve faaliyet yaratmayı amaçlamaktadır. Herhangi bir yenilikçi proje, uygulanması sırasında belirli bir yoldan geçer: bir fikir geliştirme aşamasından fikrin ilgisizliği aşamasına. Teknik şartnamelerin geliştirme aşaması, yenilikçi bir projenin ilk aşamasını ifade eder.

Yenilikçi bir projede, tamamen yeni ürün tüm parametreleri önceden planlamak zordur, bu nedenle esas olarak tanımlayıcı olan dinamik bir genişletilmiş TOR kullanılması önerilir.

Yeni bir ürün fikri ortaya çıktıktan sonraki ilk adım, ihtiyaç kataloğu müşteri gereksinimleri, yeni bir ürün için pazar bölümlendirmesi, normlar, standartlar, genel hedefler (pazar payı, maliyetler), pazara sunma süresi, yaşam döngüsü uzunluğu, genel risk değerlendirmesini içerebilir.

Gereksinimler kataloğunda belirtilen göstergeler, genişletilmiş görev tanımı adı verilen belgede belirtilmiştir.

İhtiyaç kataloğu “müşterilerin dilinde” derlenirse, genişletilmiş Görev Tanımı “işletmenin dilinde” olur. Genişletilmiş Görev Tanımı, geleneksel öğelere (çalışma kapsamı, raporlama, ilk veriler, parametre gereksinimleri vb.) ek olarak ve proje için iş planının bazı öğelerini (tahmini fiyatlandırma politikası, planlanan pazar payı, planlanan ciro vb.) içermelidir. .) .

Gereksinim kataloğu müşterinin bakış açısından oluşturulduğundan, gereksinim kataloğunun yazım dili de müşteri tarafından anlaşılabilir olacak şekilde seçilmiştir (belirli teknik ayrıntılar olmadan). İhtiyaç kataloğu, müşteri ihtiyaçlarına yanıt olarak işletmenin önerilerini yansıtır.

Genişletilmiş TOR şunları içerebilir:

1. Projenin tanımı

2. Projenin pazar ve ekonomik hedefleri

3. Zamanlama parametreleri

4. Teknik parametreler

5. Üretim parametreleri

8. Tasarım ve ergonomi gereksinimleri

9. Standartlar ve düzenlemeler

Bu nedenle, genişletilmiş bir TOR derlemenin ana görevi, geliştirilmekte olan ürün hakkında planlama yapılırken dikkate alınan en eksiksiz bilgileri toplamaktır.

Genişletilmiş TOR bilgisi, projenin sonucunu oluşturacak tüm bileşenlerin bir listesi olan ürün yapısı açısından ayrıca belirtilmiştir. Proje sonucu yapı planı, oluşturulan ürünün tüm bileşenlerini, bloklarını ve düğümlerini içerir.

İş Tanımının en önemli unsurları şunlardır: çalışmanın amacı, sonuçların kapsamı, çalışmanın içeriği, uygulama programı, teknik, ekonomik ve diğer göstergeler, işin gereklilikleri, seviye ve yöntem uygulanması, çalışmanın sonuçları, beklenen sonuçların bilimsel, bilimsel, teknik ve pratik değeri; sonuçların kullanım amacı ve türü, raporlama materyallerinin sunum şekli.

TK'nin yapıdaki yerini düşünün organizasyonda yenilik süreci(kuruluşta yenilik) göre.

Başlangıçta, inovasyon kavramı geliştirilmektedir. Hangi araştırma aşamasından önce gelir (kuruluş araştırması, yaklaşan yenilik faaliyetleri için performans göstergelerinin seçimi, yeniliklerin uygulanması için gerekli faaliyetlerin listesinin gerekçesi). Oluşturulan geliştirici ekibi tarafından inovasyon kavramı, sonraki tasarım için gerekli tüm gerekçeleri, başlangıç ​​ayarlarını ve parametreleri içermesi gereken yenilikçi bir projenin geliştirilmesi için bir göreve (TOR) dönüşür.

Yenilikçi bir projenin geliştirilmesi görevine dayanarak, daha sonra detaylı plan bireysel görevlerin geliştirilmesi ve çözümü ile bunların uygulanmasının izlenmesi için önlemler (son teslim tarihlerine göre kontrol noktaları, kontrol edilen parametrelerin bir listesi, kontrol kriterleri, vb.). Nitekim, görev tanımları, eylem planı, yenilikçi bir projenin geliştirilmesinin temelidir.

Projenin içeriği, planlanan faaliyetlerin tanımı ve düzenlemeleri, kaynakların optimal kullanımının hesaplanması, beklenen uygulama sonuçlarının bir değerlendirmesi, nicel değerlere getirildi. Yenilikçi bir projenin temeli, organizasyonel ve finansal bölümleridir. Bunu projenin adaptasyon ve uygulama aşamaları ve proje sonuçlarının analizi takip etmektedir.

İş Tanımı belge olarak onaylandığında, proje üzerindeki çalışmaların planlaması yapılır.

atik,

Ürün Yönetimi

• kurtarma Modu

Bu metin tamamen, yazarın kendisinin ve hepinizin, gelecekteki müşterilerinize, meslektaşlarınıza, akrabalarınıza ve tanıdıklarınıza soruya standart bir cevap şeklinde güvenle gönderebileceği kalıcı bir bağlantının varlığı uğruna oluşturulmuştur: "TK'nıza ihtiyacım var mı ve genel olarak bu nedir?"

Dedikleri gibi - “bin kelime yerine”, çünkü bu konuda Skype'ta 4-5 saat boyunca her seferinde evangeling yapmak zaten sıkıcı hale geliyor ve yıllar boyunca “Görev Şartları” tanımı altında açık saçma sapan küresel eğilim sadece yoğunlaşır.

Sorun

Gerçek şu ki, belirli bir formatın yanı sıra bir terimin açık ve anlaşılır bir tanımı olduğunda, kendi özetleri, prototipleri, icat edilmiş anketleri, açıklamaları ve basitçe gelen uygulamalar için tüm manipülasyonlar ve ikameler en azından profesyonelce görünmüyor. Bu nedenle, kavramımızın bilimsel tanımıyla başlıyoruz:

İş Tanımı - teknik bir nesnenin (ürün) tasarımı için orijinal belge. Görev Tanımı, geliştirilmekte olan nesnenin ana amacını, teknik özelliklerini, kalite göstergelerini ve teknik ve ekonomik gerekliliklerini, gerekli dokümantasyon (tasarım, teknolojik, yazılım vb.) özel gereksinimler olarak. İş tanımı yasal bir belgedir - tasarım işi için müşteri ve yüklenici arasındaki sözleşmeye bir ek dahil edildiğinden ve temeli olduğundan: amaç, hedefler, ilkeler dahil olmak üzere işin prosedürünü ve koşullarını belirler, Beklenen sonuçlar ve son tarihler. Yani, şu veya bu iş öğesinin yapılıp yapılmadığını belirlemenin mümkün olduğu nesnel kriterler olmalıdır. TOR'un metnindeki tüm değişiklikler, eklemeler ve açıklamalar müşteri ile anlaşmalı ve müşteri tarafından onaylanmalıdır. Bu aynı zamanda gereklidir, çünkü tasarım problemini çözme sürecinde yanlışlıklar veya hatalı ilk verilerin keşfedilmesi durumunda, geliştirmede yer alan tarafların her birinin suçluluk derecesini, meydana gelen kayıpların dağılımını belirlemek gerekli hale gelir. bununla bağlantı. Bilgi teknolojisi alanında bir terim olarak görev tanımı, icracıların bir yazılım ürününü geliştirmesi, uygulaması veya entegre etmesi için görevleri belirlemek için gerekli olan kapsamlı bilgileri içeren yasal olarak önemli bir belgedir. bilgi sistemi, web sitesi, portal veya diğer BT hizmeti.

Anlaşılır bir dile tercüme ediyoruz

1) İş Tanımı - görevi belirler. Bu bir prototip, eskiz, test, tasarım projesinden önce gelmesi gerektiği anlamına gelir, çünkü herhangi bir zihin haritası, veri akış şeması, mimari zaten belirli bir görevin yerine getirilmesidir, bu bir sorunun cevabıdır. Ve sorunun kendisi henüz tüm taraflarca sorulmadan, formüle edilmeden ve imzalanmadan önce - herhangi bir cevap a priori yanlış olacaktır, değil mi? Bu nedenle, herhangi bir proje üzerindeki herhangi bir çalışmanın başlangıcı, sorunun bir ifadesidir ve onu çözmek için bir düzine seçeneğin ana hatlarını çılgınca aramak değil.

2) Aslında, ilk noktadan itibaren mantıklı bir şekilde yeni bir tane geliyor - TK metninin kendisi, dünyadaki entropiyi artırmaya yönelik bu sonraki girişimin hangi iş hedeflerini açıkça formüle eden “Hedefler ve Hedefler” bölümü ile başlamalıdır. Herhangi bir sorunu çözmeyen, hiçbir şey elde etmeyen ve “sıkıntıdan” yapılan amaçsız bir görev, resmi olarak bir Görev Tanımı olarak kabul edilmez ve bundan böyle “sıradan bir kağıt parçası” statüsüne sahiptir.

3) Önerilen tasarım konseptinin veya etkileşimli prototipin veya hatta kullanıma hazır bir sitenin yukarıdaki iş sorununu çözüp çözmediğini nasıl anlayacaksınız? Hiçbir şey yapılamaz, tekrar tanıma dönmemiz gerekecek: “tanımlar ... beklenen sonuçları ve son tarihleri. Yani, şu veya bu iş öğesinin yapılıp yapılmadığını belirlemenin mümkün olduğu nesnel kriterler olmalıdır.” Yani, ruble, saniye, ton-kilometre veya santigrat derece cinsinden net ölçülebilir göstergeler olmadan TK olamaz. Özet, bir prototip veya başka bir saçma kağıt parçası olabilir, ancak İş Tanımı değil.

Bundan yola çıkarak, bu TOR'da, bu göstergeler alındığında, ölçüldüğünde ve taraflar el sıkıştığında veya projeyi yeniden çalışma için gönderdiğinde, “Kabul ve değerlendirme prosedürü” bölümünün olması gerektiği sonucuna varıyoruz.

4) İş Tanımı, müşterinin genel iş planı, iş geliştirme stratejisi ve pazar segmenti analizi ile mutlaka tutarlı olmalıdır. Tüm bunlar, doğru hedefleri belirlemenize, doğru ölçümler elde etmenize ve buna göre bitmiş bilgi ürününün kabulünü yeterince gerçekleştirmenize izin verecek. Müşteri tarafından bir iş planının olmaması, otomatik olarak İş Tanımı'nın profesyonelce yapılmamasını garanti eder.

Dış kaynaklı stüdyo, işletmenin iş hedeflerini ve ölçülebilir göstergelerini sahibinden daha iyi biliyor mu? Açıkçası hayır, bu da doğru TOR'un Yüklenicinin çalışanları tarafından değil, Müşteri temsilcileri tarafından yazılması gerektiği anlamına gelir. Oyuncunun kendine bir görev belirlemesi, sonra onu değerlendirmenin yollarını bulması ve sonunda yaptığı iş için kendisine son notu vermesi saçmadır. İdeal olarak, böyle bir “amatör faaliyet” olmamalıdır, ancak pratikte her yerde olan tam olarak budur ve bunun bir sonucu olarak İş Tanımı Şartları'nda yer almaz. Yardıma ihtiyaç duydu proje, çoğu zaman esasen hayali bir belgedir. Bu şekilde yapmayın.

5) Tamamlanmış TK'de yapılan her değişiklik paraya mal olmalıdır. Taraflardan biri fikrini değiştirdiği, yeterince uyumadığı, aniden para biriktirmeye karar verdiği vb. için “Projenizin Anayasasını” ücretsiz ve sonsuz olarak düzenleyemezsiniz. Görev Tanımında yapılacak her değişikliğin maliyeti de uygun bölümde önceden açıkça belirtilmelidir.

Bu arada, teoride aynı şekilde, tasarımdaki her değişiklik veya sayfalar veya işlevler listesinde değişiklik yapılması, değişiklik yapılmadan önce önceden ödenen net bir fiyata sahip olmalıdır. Şahsen, onaylanmış Görev Tanımındaki herhangi bir revizyonun toplam proje bütçesinin %30'u olarak tahmin edilmesini öneriyorum, ancak başka türlü yapabilirsiniz.

Görev Tanımında, geliştirme için zaman çerçevesini ve toplam bütçeyi ve ayrıca mevcut tüm kaynakların ve kısıtlamaların bir listesini önceden belirtmenin gerekli olduğunu belirtmeye değer mi? Hayır, bu çok açık olurdu.

Peki ne yapıyoruz? Ne için? Ne yaptığımızı nereden biliyoruz? Her pivotun değeri ne kadar? - Bir kağıda yazılan tüm bu soruların cevapları, en başarısız projeyi bile çıkarabilecek “gümüş kurşun”dur.

sınav soruları

İşte müşterilerden en sık sorulan soruların cevapları:

1) Dolayısıyla, İş Tanımı'nı yazmak için, aynı zamanda resmi GOST var? - Evet, hatta birkaç tane.

2) Ne, İş Tanımı gerekli sayfaların açıklamasını, butonların sayısını, kullanılan kitaplıkları, kılavuzları vb. içermiyor mu? - TOR'un kendisinde değil, ancak tüm bunları, elde edilen sonucu daha fazla değerlendirmek için yukarıdaki hedefler, kısıtlamalar ve yöntemlerle ayarlayarak, elbette Uygulamalara koyabilirsiniz. En azından gelecekteki tüm içeriği, en azından tipik karakterlerin bir tanımını yayınlayın - ancak görevin net bir ifadesi yerine değil, ondan sonra.

3) Yani belki ihtiyacım yok? - Belki de bugün binlerce site teknik şartname olmadan yapılıyor, tıpkı dünyadaki binlerce insanın doğuştan kör olarak mükemmel bir şekilde yaşaması gibi. Ancak nereye gittiğinizi görmek, bilinçli kararlar vermek ve elde edilen sonuçları bağımsız olarak değerlendirmek istiyorsanız, teknik özellikler olmadan yapamazsınız.

4) Yani siz ve Wikipedia, TK'nin müşteri tarafından oluşturulduğunu yazıyorsunuz. Ama nasıl bilmiyorum / zamanım yok / sadece kendim yapmak istemiyorum. Nasıl olunur? - Teknik özelliklerin geliştirilmesini, işinizi, görevlerini, hedef kitlesini ve ihtiyaçlarını oldukça iyi bilen ve aynı zamanda web geliştirmenin tüm aşamalarından tamamen haberdar olan üçüncü bir tarafa verin. Bu üçüncü taraf, bir tür “web noteri” olacak, yani, yüklenicinin ihtiyacınız olan göstergeleri hafife almayacağı veya son teslim tarihlerini geciktirmeyeceği ve müşterinin ulaşılabilir ölçümler belirleyeceği ve oluşturulanları öznel olarak değerlendirmeyeceği garantisi olacaktır. nihai kabulde ürün, hareket halindeyken daha önce kaydedilmiş olanları değiştirerek.

5) Peki ya TK yasal bir belgeyse, o zaman işverene dava açabilirim, ona ödeme yapmayıp, onuncu kez her şeyi yeniden yapmaya zorlayabilirim? - Belge doğru bir şekilde hazırlanmışsa, başarılarını değerlendirmek için hedefler ve metodoloji belirtilir; belge taraflarca imzalanmışsa ve Sözleşmede belirtilmişse (İş Tanımının kendisi bir sözleşme değildir), o zaman elbette yapabilirsiniz. Ancak her zamanki özet, prototipler, sanatsal yaratıcı düzen, FL'de Güvenli Anlaşma - artık yok.

6) Bana işin bir çeşit hücum veya çevikliğe göre yürütüleceğini söylüyorlar; bu da artık arkaik TK'ye ihtiyacım olmadığı anlamına geliyor. Bu doğru? - Kendiniz karar verin: Size anlaşılmaz bir kelime, açıkça maskelenen bir şey diyorlar ve şimdi, size aşina olmayan bir terime dayanarak, yasal olarak yetkin ve hedefler ve ölçülerle dolu bir belgeyi terk etmeyi teklif ediyorlar. Agile'ın kendisi "yıl sonuna kadar en az 10.000 ziyarete ulaşmak" veya "siteden bir ayda 25'ten fazla siparişe ulaşmak" gibi hedefler koyamaz - belirlenemez, sadece bir toplantı ve toplantı düzenleme yöntemidir. yeni organizasyon ilgisiz çalışanlar. Birkaç kez düşünün: “Gözlerinize toz mu atıyorlar?”. Aslında profesyonel TK, yeni çıkmış herhangi bir Scrum'a zarar veremez, ancak yardımcı olacağı kesindir.