teknik görev"TOR", herhangi bir projenin geliştirilmesi için temel alınan bir belgedir. Ve görevin karmaşıklığı ve boyutu ne olursa olsun, ona her zaman açık ve anlaşılır bir Görev Tanımı eşlik etmelidir. Bu, her şeyden önce, sonuç olarak tam olarak görmek istediğini elde etmek için müşteri için gereklidir. Ancak icracının kendisinden ne istediğini anlamak için her zaman açıkça belirtilmiş bir görev talep etmesi de arzu edilir. Birçok kişi, daha sonra yanlış anlamalara, anlaşmazlıklara, çatışmalara ve kavgalara yol açan ayrıntılı bir teknik görev yazma gerçeğini görmezden gelir.

Okumanızı öneririz:

Ben, bu makalenin yazarı, hayatımda hem on binlerce dolarlık birkaç büyük projenin müşterisini hem de daha az pahalı olmayan siparişlerin uygulayıcısını ziyaret etmeyi başardım. Ciddi bir seviyeye ulaşmadan önce yüzlerce "TK" yi yeniden okumak ve sanatçı için birkaç düzine açıklama yapmak zorunda kaldım. Her seferinde teknik görevler daha net ve netti, bu da işin son halini hayal ettiğim şekilde elde etmeyi mümkün kıldı. Bu yazımda teknik bir görevin nasıl yazılacağından, ilk etapta nelere dikkat edilmesi gerektiğinden bahsetmek istiyorum. Müşteri ve müteahhit için neden nazik bir kelime üzerinde çalışmanın değil, her şeyi belgelemenin arzu edildiğini size de anlatacağım.

Neden müşteriye TK?

Bir müşteri olarak, siparişinizin son hali hakkında bir fikriniz var. Sadece hayat öyle bir şeydir ki, her insan aynı kelimeleri farklı şekillerde yorumlayabilir. Bu nedenle, özellikle müşteriler ve yükleniciler arasında sıklıkla sorunlar ortaya çıkar. Birincisi her şeyi bitirmedi, ikincisi doğru anlamadı ve sonuç herkesin düşündüğünden tamamen farklı. Görev tanımı, yapılan işi kabul edeceğiniz bir belgedir. Ve bir şey yanlış yapılırsa, bir şey kesinleşmez, bir şey tam olarak tamamlanmaz, o zaman her zaman referans şartlarından bir öğeye işaret edebilir ve gönderilen projeyi sonuçlandırma talebinizi haklı çıkarabilirsiniz. TK yoksa, söylediğinizi, yazdığınızı, bahsettiğinizi kanıtlamak pratik olarak imkansız olacaktır. Görev tanımının, hizmetlerin sağlanması için bir sözleşmenin bir tür prototipi olduğunu söyleyebiliriz. Büyük bir proje üzerinde çalışıyorsanız, görev tanımları ana sözleşmeye ek olarak gitmelidir. Tamamlanan işin kabul ve devir belgesini imzalarken, her şeyi orijinal TOR'da belirtilen iş miktarıyla mutlaka karşılaştırmalısınız.

Okumanızı öneririz:

Sanatçı için TK nedir?

Her şeyden önce, bu yapılması gerekenler konusunda rehberiniz. Müşteriler genellikle geliştirme sürecinde bir şey düşünür ve size gereksiz görevlerin performansını dayatmaya çalışır. Bedava çalışmak ister misin? Eminim değil. En başta kararlaştırılan miktarın, yalnızca iş tanımında belirtilen işin kapsamıyla ilgili olduğunu belirtin. Daha fazlası ayrı olarak ödenir. Ayrıca proje teslim edildiğinde, görevler ve bunların uygulanması hakkında rapor verebileceksiniz. Müşterinin işi tam olarak tamamlanmadığını savunarak kabul etmek istemediği anlara defalarca rastladım. Ancak ilk TK'yi yükseltmek, hiç kimsenin tartışılan görevleri belirlemediği ortaya çıktı. Bir kez daha vurguluyorum - teknik özellikler olmadan çalışmayın, çünkü müşterinin görüşü hava durumundan daha sık değişebilir ve her şeyi onlarca kez yeniden yapmak zorunda kalacaksınız, zamanınızı boşa harcıyor ve bunun için ek ödeme almıyorsunuz.

Yetkili bir teknik görev yazmaya nasıl başlanır

O halde, bu makalenin ana konusuna geçelim. Ardından, teknik bir görevin nasıl çizileceğinden ve kesinlikle hangi noktalara dikkat etmeniz gerektiğinden bahsedeceğiz. Anladığınız gibi, her TK benzersizdir ve tüm yönleri kapsayamayacağım. Bu nedenle, proje ve müşterinin kapsamı ne olursa olsun, sadece herhangi bir görevde olması gereken ana noktaları belirteceğim.

• Görev tanımının genel hükümleri

Bir tür teknik olarak karmaşık veya çok spesifik bir projeniz varsa, o zaman emin olun. Genel Hükümler bir sözlük olmalı - bir terimler ve tanımlar sözlüğü. Tabii ki, müşteri ve yüklenicinin birbirini anlaması ve belirli terminolojiyi sorunsuz bir şekilde anlaması çok iyidir. Ancak bu her zaman böyle değildir, bu nedenle belirli kelimelerin, ifadelerin, tanımların ne anlama geldiğini belirtmek daha iyidir. Belki de sözlük, cirolarınızdan bazılarını açıklamalıdır. Diyelim ki bir cümleyi biraz farklı yorumlayarak kullanıyorsunuz. Karışıklığı önlemek için hemen her şeyi yerine koyun.

Okumanızı öneririz:

Terimlerdeki anlayış eksikliğinin bir aydan fazla gecikmeye yol açtığı bir vaka yaşadım. Sonuç olarak, müşteri belirli kayıplara uğradı, ancak sorun yalnızca onun tarafındaydı. Bu nedenle, anlaşmazlıklara izin vermeyin. Proje geliştirmeye başlamadan önce terminolojiye karar verin.

• Proje hedefleri

Projenizin hangi hedeflere sahip olduğunu, neden oluşturulduğunu, nasıl çalışacağını, nihai sonucun ne olması gerektiğini referans şartlarında belirttiğinizden emin olun. Sanatçı projenin küçük bir bölümünde çalışsa bile yapısını, görevlerini, hedeflerini, teknik çözümlerini tam olarak anlamalıdır. Ne için? Yüklenicinin müşteriden tavsiye ve açıklama alması her zaman mümkün değildir ve hedeflere dönebilir, projenin ne için olduğunu anlayabilir ve bundan yola çıkarak işinizi yapmak için bazı önemsiz şeyleri yorumlamanızı istemek mantıklı değildir. Görev.

Sana bir örnek vereceğim. Yakın zamanda büyük bir internet projesi geliştirdik ve bir tasarım sipariş ettik. Tasarımcıya sitenin ne hakkında olacağı, hangi işlevlere sahip olacağı, ne yapması gerektiği, sitenin insanlara nasıl yardımcı olacağı söylendi. Genel olarak, sadece tasarımla ilgili olanı değil, her şeyi en küçük ayrıntısına kadar çiğnediler. Sonuç olarak, neredeyse hiç değişiklik gerektirmeyen bir düzen ve sitenin nasıl iyileştirileceği, nelerin eklenebileceği, nasıl daha çekici hale getirileceği konusunda bir düzine fikir elde ettik.

• İşlevsel gereksinimler

Müşteriye yönelik tüm gereksinimler iki türe ayrılabilir: işlevsel ve özel. Fonksiyonel Gereksinim- bunlar kendiniz görmek istediğiniz seçenekler. Bir İnternet sitesi örneğinden bahsedecek olursak, yükleniciye beğendiğiniz ve kendi başınıza görmek istediğiniz diğer projelerden işlevsel çözüm örnekleri vermelisiniz. Örneğin, teknik olarak beğenilen unsurları gördüler, tarif ettiler ve bir kişinin ne hakkında olduğunu net bir şekilde anlayabilmesi ve temel alabilmesi için hemen bir bağlantı verdiler.

Okumanızı öneririz:

Özel gereksinimler, atanan görevlerin yerine getirilmesi gereken gereksinimlerdir. Yine sitenin gelişimini temel alırsak, programlama dilini, özel yerleşim seçeneklerini, kodlamayı, bazı belirli stillerin kullanımını ve görmek istediğiniz her şeyi belirleyebilirsiniz. Böyle bir gereklilik yoksa, sözleşme şartlarınızı yerine getirirken neyi ve nasıl kullanacağına yüklenicinin kendi karar vermesine izin verin.

• Zamanlama

Başvuru şartlarında son tarihleri ​​belirttiğinizden emin olun. Her zaman küçük bir marjla alın, böylece yürütme hızı kaliteyi etkilemez. Her halükarda net bir son teslim tarihi ve başarısızlığın yaptırımları olmamalıdır. belirtilen son tarihler. Yüklenici, bunun yalnızca teknik görevlendirmenin bir noktası değil, gerçek bir kurulum olduğunu anlamalıdır, aksi takdirde mali veya diğer yaptırımlara maruz kalma riski vardır.

• Raporlama

Proje büyükse ve tamamlanması birkaç ay sürüyorsa, işi aşamalara ayırın ve her biri için net zaman dilimleri belirleyin. Belirli bir aşamanın tamamlanmasından sonra, yapılan işin raporlanmasını gerektirir. Bu, sanatçıyı iyi durumda tutacak, böylece birkaç ay yürümeyecek, avans yiyip içmeyecek ve ardından bir hafta içinde her şeyi kafa kafaya yapacak.

Ayrıca yapılan işin gerçeği hakkında bir rapor olmalıdır. Ne yapıldı, ne kadar zaman harcandı, sanatçı hangi zorluklarla karşılaştı vb.

• Bir sorumluluk

Bir sözleşme düzenlerseniz, sorumlulukla ilgili madde içinde olacaktır. Yalnızca referans şartlarıyla sınırlıysanız, orada, son başvuru tarihlerini karşılayamamaktan, projeyi teslim etmemekten, çalışmanın nüanslarını sizin için kayıplara neden olan üçüncü taraflara ifşa etmekten sanatçının sorumlu olduğunu açıklamaya değer. Ne? Öncelikle kanuna uygun ama bazı ceza ve yaptırımlarınızı da kendiniz belirleyebilirsiniz.

Okumanızı öneririz:

Ve bu makalenin sonunda, bazı tavsiyelerde bulunmak istiyorum. kendi deneyimi teknik şartnamelerin hazırlanması ve alınması.

1. Spesifikasyon ayrıntılı olmalıdır. Her öğeyi, her öğeyi, her düğmeyi tanımlamaktan korkmayın. Her şey, her şey, her şey, mümkün olduğunca ayrıntılı olarak yazın. Titiz olmaktan korkmayın. Bir şeyi birkaç kez tekrarlamak ve çiğnemek, bitirmekten, fazladan ödemekten ve daha sonra rafine etmekten daha iyidir. Yazdığım son referans şartları sitenin gelişimi ile ilgiliydi. Büyüktü bilgi projesi. İlk önce bir tasarım geliştirdik ve ardından buna dayanarak programcılar için işlevsel bir görev tanımladık. Böylece, tüm TK'nin 54 sayfa A4 11 yazı tipi olduğu ortaya çıktı. Görev tanımı, yine 7 sayfa uzunluğunda olan ana sözleşmeye ek olarak gitti. Ancak bu kadar ayrıntılı bir TOR'da bile her şeyi hesaba katamadığımı söylemek istiyorum, çünkü geliştirme sürecinde üç tane daha imzalandı. ek anlaşmalar, bununla birlikte ödevin orijinal versiyonunda bazı ayarlamalar yaptım.
2. Referans şartları açık olmalıdır. Su gerekmez. Hepsi noktaya. Son teslim tarihi hakkında yazarsanız, belirli bir rakam, işlevsellik hakkında ise, ihtiyacınız olan işlevsel çözümlerin bir listesi vb.
3. Görev tanımınız bir dogma değil, görevleri tamamlamak için olası seçeneklerden yalnızca biridir. Dürüst olmak gerekirse, ben bir programlama uzmanı değilim. Evet, projenin yapısını, işlevselliğini, bazı teknik çözümleri düşünebilirim, ancak TOR'un son halini derlerken her zaman sanatçılara danışırım. Bir şey görebilirler, fikirlerini ifade edebilirler, öneride bulunabilirler. en uygun çözüm uygulamak.

Belki de bu yazıda anlatmak istediğim tek şey buydu. Yükleniciden ne istediğinizi açıkça anlarsanız, teknik bir görevi derlemek o kadar zor değildir. Tavsiyemi tekrar okuyabilir ve özel durumunuza uygulayabilirsiniz. İyi şanlar!

TK kavramı

İş Tanımı - ilk tasarım belgesi teknik nesne. 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.
Yeni bir şeyin yaratılması için kaynak belge olarak bir görev, ad, içerik, yürütme sırası vb. Farklı tüm faaliyet alanlarında mevcuttur (örneğin, inşaatta bir tasarım görevi, bir savaş görevi, ev ödevi, için sözleşme edebi eser vb.).

Uyarınca Medeni Kanun, tasarım, sonucu bir ürün olan sözleşmeli iş türlerinden biridir ( proje), yani, küme Proje belgeleri başka bir ürüne 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 " ve "Tasarım 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. Tedarikçi ve ürünlerin tüketicisi bir kuruluş (tüzel kişilik) veya belirli bir kişi (birey) olabilir.

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 (enstrüman, makine, aparat), kontrol sistemi, bilgi sistemi, normatif belgeler(örn. standart), vb.

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.

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),
• Ön tasarım,
• Ç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, çözme ihtiyacını gerekçelendirin, bu TOR'un ana hedefidir, 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ı

Tasarım sürecinde Karmaşık nesne(sistem), birkaç geliştiricinin katılımını gerektiren, 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 iyileş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 zorlayan ana nedenler, uygun özel bilgi veya sınırlı kaynaklar (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 döndüler. Fabrikaya vardığında, arabanın etrafında uzun süre yürüdü, 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
    • dahil olmak üzere, şu anda mevcut olan Tekniksel kabiliyetler ve kaynaklarınız
  • 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).

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

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

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

Durumda verilen verilerin nominal parametreler olduğuna dikkat edilmelidir, ancak bu parametrelerin izin verilen maksimum değerlerine göre ayarlanmış normalleştirilmiş değerlerini vermek daha doğru olacaktır (örneğin, ürünün kütlesi 9,8 ... 10.1 kg). Yani, pratikte koşullar olarak kabul edilenler, ikili eşitsizlikler biçimindeki kısıtlamalardır. Aralık genişliği, bu parametredeki toleransın bir sonucudur.

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, tasarım problemini çözme yöntemleri ve doğruluğu üzerinde kısıtlamaların getirilmesidir ve bu da seçilen modelin türünü etkiler. 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. yasalara uygun olarak Rusya Federasyonu herhangi bir üretim, bölgesel bir işletme lisansı almayı gerektirir. Ayrıca birçok üretim lisanslıdır. denetleme makamları ve onların denetimine tabidir. En sık kontrol edilenler bölgesel kuruluşlar Rostekhnadzor, Rosstandart, Rusya Bölgesel Kalkınma Bakanlığı (eski adıyla 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ı

Ana makale: Tasarım Yöntemleri

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.

Geliştirmeye başlamadan önce elektrikli aydınlatma Edison günlük hayatta gazlı aydınlatma (korna) ile fiyat, parlaklık ve rahatlık açısından hangi koşullarda rekabet edeceğine dair çalışmalar yaptı. 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 olanların neler olduğundan 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.

İhtiyacın ana nedeni yeni gelişme, mevcudiyet ç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 bağlantılıdır. 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 kontrol soruları yönteminin diğer 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 elleri 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 mekanda bölme vb.) ve 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ı zaman veya TK'nin farklı yerlerine yerleştirilebilir, örtük bir biçimde sunulabilir.

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 çok karakterize edenleri seçin önemli özellikler(mümkün olan en iyi değerleri elde etmek 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 setleriyle 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 toplayana kadar hiçbir şey yapamayacağınız kafanıza kazındı. Bilginin %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. … Ana 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. - - Telekomünikasyon konuları, temel kavramlar EN gereksinimlerin ifadesi... Teknik Çevirmenin El Kitabı

TEKNİK GÖREV- (TK) orijinal Beyaz kağıtçeşitli araştırmalar yapmak ve yeni (bkz.) ve yapılar tasarlamak için. Kural olarak, görev tanımı, geliştirilen işin aşamalarını gösterir. teknik döküman, kalite göstergeleri ve teknik ... ... Büyük Politeknik Ansiklopedisi

teknik görev- Sözleşmenin uygulanmasında gerçekleştirilecek görevleri tanımlamak ve tanımlamak için müşteri tarafından kullanılan 3.29 çalışma belgesi belgesi

İhlal etmeden ihtiyacınız olanı nasıl satın alırsınız antitröst yasası? Bu işte başarının anahtarı, iyi yazılmış bir teknik görevdir. Müşteriler tarafından hangi zımni ihlallerin gerçekleştirildiğini makaleyi okuyun.

AT Genel dava bir tedarik şartnamesi hazırlarken, müşteri, açıklanan nesnenin tam meçhullüğünü izlemeli, yani herhangi bir gereklilik ve hatta belirli ipuçları içermemelidir. ticari markalar, üreticilerin ve hatta malların menşe ülkesi.

Aslında, belirli bir alanda özel bilgi olmadan, tedarik nesnesinin tanımını, 44-FZ için görev tanımını doğru bir şekilde hazırlamak oldukça zordur. Bazı müşteriler, görev tanımlarının hazırlanması için hizmetlerin sağlanması için bir tedarik bile oluşturur. Ancak, satın alma nesnelerinin gereksinimlerini dikkatlice incelerseniz, bunları kendi gereksinimlerinizle karşılaştırırsanız ve 44-FZ'ye göre satın alma nesnesini tanımlama kurallarına kesinlikle uyursanız, bunu kendi başınıza yapmak oldukça mümkündür.

Ürünlerin etiketlenmesinde bazı özelliklerin şifrelendiği unutulmamalıdır. Örneğin, referans şartları "Classico 1KO.4" işaretli "kaldırım levhaları" malzemesini sağlar, referans şartları karo kalınlığı için herhangi bir gereklilik belirlemez. İşaretin kodunun çözülmesine göre kalınlığı 4 cm'dir (işaretin son hanesi cm cinsinden kalınlığı gösterir). Ancak temasın gerçekleştirilmesi sırasında 6 cm kalınlığında bir karo gerekli olduğu ortaya çıktı.Taşıyabileceği yük, karonun kalınlığına bağlıdır. Okuma yazma bilmeyen referans şartları, tatmin edici olmayan malzemenin satın alınmasına yol açtı gerekli gereksinimler. Bu nedenle, tüm malzemelerin etiketlerini referans şartlarında dikkatlice kontrol etmek ve malzemeler için tüm temel, önemli gereksinimleri belirtmek gerekir.

arzu edilir ürün açıklamalarını farklı sitelerden kopyalamayın. Açıklamadaki bilgiler güvenilir olmayabilir ve tek bir ürünün belirtilen gereksinimleri karşılamadığı ortaya çıktı. altında olma ihtimali yüksek verilen açıklama uyar tek mal. Bu bir rekabet kısıtlaması olarak kabul edilebilir.

Tüm performans gereksinimleri belirsiz olmamalıdır. Aksi takdirde, açıklama için çok fazla talep olacaktır. Çoğu zaman, çok sayıda istekle müşterinin zamanında gelemeyeceği görülür. son tarihler onlara esasa göre cevap verin ve görev tanımını değiştirmek için zaman olmayabilir. Buna dayanarak, bazen açıklamadaki müşteri, materyalleri belirtmeden yalnızca onay vermenin yeterli olduğunu belirtir. Bu da, işin yürütülmesinde hangi malzemelerin kullanılacağı uygulamadan net olmadığı için, tam olarak ihtiyaç duyulanı satın alma şansını azaltır.

Teknik özellikler için gereksinimleri tanımladıktan sonra bir başvuru hazırlamak için talimatlar yazmak daha iyidir. Talimat, katılımcının kafasını karıştırmamalı, ancak katılımcılardan gelen birçok talebi önlemek için görev tanımının gereksinimlerini belirtmelidir. Başvurunun hazırlanmasına engel teşkil eden talimatlara uyulmaması, potansiyel satın alma katılımcıları tarafından OFAS'a şikayet sunulmasına neden olabilir.

Referans şartlarında belirtilmesi gereken diğer gereksinimler nelerdir:

• Malların, işlerin, hizmetlerin garanti süresi ve (veya) kalitelerinin garanti edilmesi kapsamı. Müşteri, referans şartlarında en az bir garanti süresi belirlemelidir. Garanti süresiüretici firma.
• Malların garanti hizmetine.
• Ürünü çalıştırma maliyetine.
• Malların zorunlu montajı ve devreye alınması.
• Malların kullanımı ve bakımı ile ilgili kişilerin eğitimine.

Ana kurallar

1. Tedarik dokümantasyonunu hazırlarken kodlara dikkat edin. Tüm Rusya sınıflandırıcısının Tedarik konusuyla ilgili ürünler (OKPD2). Kullanılan kodun belirli tedarik nesnesiyle eşleşmesi gerekir.
2. 44-FZ hükümlerine ek olarak, görev tanımları hazırlanırken diğer yasal düzenlemelerin gereklilikleri de göz önünde bulundurulmalıdır, antitröst makamları, teknik standartlar ve standartlar (GOST, TU, SNiP, vb.).
3. Müşteri tarafından referans şartlarında talep edilen mal ve malzemeler, tedarik konusuna uygun olmalıdır ve bütçe belgeleri(Eğer biri varsa).
4. için satın alırken inşaat sözleşmesi ayrıca eklenmelidir kusurlu beyan, tahmin ve durumda sermaye inşaatı(yeniden yapılanma, elden geçirmek) proje belgelerinin eklenmesi de gereklidir.
5. Yeni mal ve malzeme satın almak istediğinizi belirtin (yani kullanılmamış, tamir edilmemiş, restore edilmemiş, restore edilmemiş). Aksi takdirde, müşteri kullanılmış malları teslim alabilir.

Yaygın sorular

Soru: Yedek parça temini için "orijinal" ibaresi yazılabilir mi?
Cevap: Garanti kapsamında olan bir üründen bahsediyorsak veya bu tür malların müşteri tarafından kullanılan mallarla etkileşimini sağlamanın yanı sıra makineler için yedek parça ve sarf malzemelerinin satın alınması durumunda da mümkündür. ve ekipman.

Soru:İhale tanımlama kodunun görev tanımında belirtilmesi zorunlu mudur?
Cevap: kimlik kodu tedarik, tedarik planında, programda, tedarik bildiriminde, kapalı bir yöntemle gerçekleştirilen tedarikçinin (yüklenici, yüklenici) seçimine katılma davetinde, tedarik belgelerinde, sözleşmede ve ayrıca sağlanan diğer belgelerde belirtilir. bundan Federal yasa. TOR'da belirtilmesi gerekli değildir.

Soru: Bir üreticiden mevcut 3 cihazlık bir sisteme bilimsel araştırma için bir cihaz satın almak gerekir. Çalışmadaki her şeyi tamamen birleştirmek gerekir. Bir eşdeğer arzu edilmez. Eşdeğerini yazıp üreticiyi belirtemez miyim? Sistem son derece özelleştirilebilir ve pahalıdır.
Cevap: Davanız “... diğer ticari markaların bulunduğu malların uyumsuzluğu ve bu tür malların müşteri tarafından kullanılan mallarla etkileşimini sağlama ihtiyacı dışında ...) kapsamına giriyorsa - diğer durumlarda yapabilirsiniz. - yapamazsın.

Soru: Revizyon için referans terimlerinde dar göstergeleri belirtmek mümkün mü, örneğin, belirli bir renk şemasına sahip duvarların rengi, tavana bir alçıpan bileşimi örneği, eşdeğeri olmayan belirli bir karo koleksiyonu, estetik tercihlerden mi bahsediyorsunuz?
Cevap: Müşteriler, görev tanımlarını oluştururken 44-FZ sayılı Kanun'un 33. Maddesinin gerekliliklerine göre yönlendirilmelidir. Duvarların rengi müşterinin seçimidir, bu onun ihtiyacıdır, tedarikçi sayısını sınırlamaz. Tavandaki bir alçıpan kompozisyonunun bir düzeni, bir taslağı da bir müşterinin ihtiyacıdır, tüm sanatçılar belgelerde verilen düzeni tekrarlayabilecektir. Eşdeğeri olmayan bir karo koleksiyonu, 44-FZ sayılı Kanunun 33. maddesinin 1. fıkrasının ihlalidir: “İhale belgeleri, işin yürütülmesinde, hizmetlerin sağlanmasında, temini sözleşme konusu olmayan malları kullanmak. nerede ön koşul satın alma amacının tanımına "veya eşdeğeri" kelimelerinin dahil edilmesidir.

Belgede " teknik görev"(kısaltma TK) aşağıdaki bilgileri içerir: Programın amacı ve kapsamı, program için teknik, tekno-ekonomik ve özel gereksinimler, gerekli aşamalar ve geliştirme koşulları, test türleri.

GOST'a göre, bu standart (Kasım 1987'de yeniden yayınlandı), bir programın 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.
Oluştururken son derece dikkatli ve dikkatli olmalıyız çünkü. genellikle ustaca (ve yetkin bir şekilde) hazırlanmış olan İş Tanımı, tüm çalışmaların başarısını belirler. Genellikle mümkün olduğu kadar çok sayıda çelişkili ve aşırı gereksinimde bulunmaya çalışan Müşteri ile kararlaştırılan İş Tanımı'dır. İnfazcının görevi ise tam tersine hayatı kendisi için kolaylaştırmaktır. Ancak her iki taraftaki imzalar atıldıktan sonra, herhangi bir şeyi tekrarlamak için çok geç.

Genel Hükümler

İş tanımı, kural olarak, sayfanın alanları doldurulmadan A4 ve / veya A3 formatındaki sayfalarda düzenlenir. Sayfa sayıları (sayfalar), sayfanın üst kısmına metnin yukarısına yapıştırılmıştır.
Bir program veya yazılım ürünü geliştirmenin sonraki aşamalarında teknik arka planda değişiklik ve eklemeler yapmak için buna bir zeyilname yayınlanır. Görev tanımına ekin koordinasyonu ve onayı, görev tanımı için belirlenen şekilde gerçekleştirilir.
Görev tanımı aşağıdaki bölümleri içermelidir:

• isim ve kapsam;
• geliştirme temeli;
• geliştirme amacı;
• program veya yazılım ürünü için teknik gereksinimler;
• teknik ve ekonomik göstergeler;
• gelişim aşamaları ve aşamaları;
• kontrol ve kabul prosedürü;
• uygulamalar.

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.

Bölüm: Ad ve kapsam

Bölümde Ad ve kapsam adını belirtmek 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.

Geliştirme temeli bölümünde, aşağıdakiler belirtilmelidir:

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

Örneğin, eğitim sürecinin özellikleri ile ilgili olarak, ders tasarımı ödevi, __.__ tarihli enstitü siparişi temel alınabilir. N ___. için, sözleşme __.__. N ___ için, vb.

Bölüm: Geliştirmenin amacı

Bölümde Geliştirmenin amacı programın veya yazılım ürününün işlevsel ve operasyonel amacı belirtilmelidir. Burada kendinizi bir veya iki kelime öbeği ile sınırlayabilirsiniz. Ana şey, bu programın ne için olduğunu açıkça tanımlamaktır.

Örneğin: Program, sürekli yazılım geliştiricisinin otomatikleştirilmiş iş istasyonunun (AWP) çekirdeğidir. lineer sistemler kullanıcının basit modelleri analiz etme problemlerini çözmesini sağlayan otomatik kontrol sistemi (ACS).

Bölüm: Program veya yazılım ürünü için teknik gereksinimler

Bu bölüm aşağıdaki alt bölümleri içermelidir:

• performans gereksinimleri;
• 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.

Başka bir deyişle, özelliklerin başladığı yer burasıdır. Programın ne yapması gerektiğini ve nasıl görünmesi gerektiğini açıklar.

Bölüm: Fonksiyonel özellikler için gereklilikler.

Burada, gerçekleştirilen işlevlerin bileşimi, giriş ve çıkış verilerinin organizasyonu, zamansal özellikler vb. Belirtilmelidir.

Örneğin : Program izin vermelidir ... hesaplamaya ... inşa etmeye ... yaratmaya ...

İlk veriler: belirli bir ...

Çıktı verileri: grafiksel ve metinsel bilgiler - sistem analizinin sonuçları ...; metin dosyaları - ... hakkında raporlar, sistemin durumunu teşhis eder ve meydana gelen hataları bildirir.

güvenilirlik gereksinimleri. Güvenilir çalışmayı sağlamak için gereksinimler (kararlı çalışmanın sağlanması, giriş ve çıkış bilgilerinin kontrolü, arıza sonrası kurtarma süresi vb.) belirtilmelidir.

Burada bir şeyi "tahmin etmek" zor. En iyi durumda, programınızın yalnızca kesinlikle doğru verilerle çalıştığı bir değişken geçebilir. Genellikle Müşteri bunu kabul etmez, ancak deneyebilirsiniz.

Örneğin: Program, çalışma algoritmasına uygun olarak incelenen grafiğin belirli bir genişletilmiş insidans matrisi ile çalışmalı, ilk veriler yanlış belirtildiğinde hata mesajları vermeli, kullanıcıya sağlanan yetenekler çerçevesinde etkileşimli modu desteklemelidir. .

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

Bu noktada, genellikle zorluklar ortaya çıkmaz. Ne yazık ki, kullanıcının profesyonelliği ile ilgili nokta, zorunlu olarak Müşteri tarafından ima edilmektedir. Bu, elbette, programınızda hata bulmanın başka bir nedenidir. Ancak burada kendinizi "Programın çalışma koşulları IBM PC ve uyumlu PC'lerin çalışma koşullarıyla örtüşüyor", "Program profesyonel olmayan bir kullanıcı için tasarlanmalıdır" gibi ifadelerle sınırlayabilirsiniz. vb.

Teknik araçların bileşimi ve parametreleri için gereklilikler. belirtmek gerekli kompozisyon teknik özelliklerini gösteren teknik araçlar.

Buradaki en önemli şey, bir yandan hiçbir şeyi unutmamak ve her şeyi öngörmek (aksi takdirde, monokrom ekranlı ve faresiz bazı IBM PC / XT'leri kaydıracaklar) ve diğer yandan, aşırıya kaçmayın. artan gereksinimler aksi takdirde Müşteri daha uzlaşmacı bir Yüklenici bulacaktır.

Örneğin: EGA (VGA) grafik adaptörüne sahip IBM PC uyumlu bir PC'ye ihtiyacınız var. Gerekli disk alanı - en az 600 KB, boş alan miktarı rasgele erişim belleği- en az 400 Kb. Bir EMS sürücüsüne ve bir fareye sahip olmak arzu edilir.

Bilgi ve yazılım uyumluluğu için gereksinimler. Özellikler önceki paragraftakiyle aynıdır. Burada giriş ve çıkışta bilgi yapıları ve çözüm yöntemleri, kaynak kodları, programlama dilleri için gereksinimler belirtilmelidir. Gerektiğinde bilgi ve programlar korunmalıdır.

Örneğin: Program, MS DOS sürüm 3.3 veya üzeri sürümlerde bağımsız olarak çalışmalıdır. Temel programlama dili Turbo Pascal 6.0'dır.

Etiketleme ve paketleme gereksinimleri ile nakliye ve depolama gereksinimleri oldukça egzotiktir. Genel durumda, bir yazılım ürününü etiketleme gereksinimleri, paketleme seçenekleri ve yöntemleri burada belirtilmiştir. Taşıma ve depolama gereksinimlerinde ise yazılım ürünü için taşıma koşulları, saklama yerleri, saklama koşulları, saklama koşulları, çeşitli koşullarda saklama süreleri belirtilmelidir.

Özel gereksinimler çok sorumlu bir şeydir. Bunlardan mümkün olduğunca kaçınmak en iyisidir. Ve hemen duyurun.

Örneğin: özel gereksinimler programın zaman özellikleri sunulmamıştır. Programın kapasitif özellikleri için özel bir gereklilik yoktur.

Teknik ve ekonomik göstergeler. Bir programcı için bu en zor öğe her zaman orada değildir. Öncelikle, amacınız yapılan çalışmanın muazzam etkinliğini ve önemini haklı çıkarmak olduğunda gereklidir. Bu öğe genellikle Müşteri için çok iyi çalışır. En azından, zamanlama için en iyi gerekçe budur ve para toplamı gelişim.

Bu bölüm şunları belirtmelidir: tahmini maliyet etkinliği, tahmini yıllık talep(örneğin: yılda bir bütün olarak kompleksin tahmini çağrı sayısı 365 çalışma seansıdır), geliştirmenin en iyi yerli ve yabancı örnekler veya analoglarla karşılaştırıldığında ekonomik avantajları.

Ek olarak, tanımlanması arzu edilir tahmini maliyeti programın geliştirilmesi ve programlamanın karmaşıklığının belirlenmesi.

Geliştirme aşamaları ve aşamaları (bu aşağıda daha ayrıntılı olarak tartışılacaktır), gerekli geliştirme aşamalarını, aşamaları ve çalışma kapsamını (geliştirilmesi, kararlaştırılması ve onaylanması gereken program belgelerinin bir listesi) ve ayrıca bir kural olarak belirler. , geliştirme zaman çizelgesi ve icracıları belirler.

Standart adımlar burada açıklanmıştır. Ana şey, zamanlamayı doğru bir şekilde belirlemektir. Mümkünse aşamaları zamana (ve miktara) göre eşit olarak dağıtmaya çalışın. Tüm projelerin son aşamaya gelmediğini unutmayın. Ve raporlar her aşamada olmalıdır. Ayrıca, çalışma projesinin en çok zaman alacağını unutmayın. Belgeleri zamanında tamamlamak için zamanınız yoksa, Müşteri, tüm sonuçlarıyla birlikte çalışmayı kabul etmeme hakkına sahiptir.

Ana ve vazgeçilmez aşamalar ve aşamalar, görev tanımının kendisi, taslak tasarım, teknik ve çalışma tasarımlarıdır.

Ön tasarım. Bu aşamada girdi ve çıktı verilerinin yapıları ayrıntılı olarak geliştirilir ve sunum şekli belirlenir. Gelişmiş Genel açıklama algoritma, algoritmanın kendisi, programın yapısı. Programın geliştirilmesi ve uygulanması için bir eylem planı geliştirilmektedir.

Teknik proje. Sorunu çözmek için geliştirilmiş algoritmanın yanı sıra ilk bilgileri kontrol etme yöntemlerini içerir. Ayrıca hata işleme araçları geliştirir ve teşhis mesajları yayınlar, ilk verilerin sunum biçimlerini ve teknik araçların konfigürasyonunu belirler.

Çalışma projesi. Bu aşamada programın programlanması ve hatalarının ayıklanması, program dokümanlarının, programların ve test yöntemlerinin geliştirilmesi gerçekleştirilir. Test ve hata ayıklama örnekleri hazırlanıyor. Dokümantasyon ve grafik materyal tamamlanır. Genellikle programın geliştirilmesi sırasında aşağıdaki belgelerin hazırlanması gerektiği belirtilir:

Program metni;

Programın açıklaması;

Program ve test metodolojisi;

Uygulamanın açıklaması;

Kullanım kılavuzu.

Bunlar standart gereksinimlerdir. Müşteri, bu listenin tamamının gönderilemeyeceğini kabul ederse, bu, sizinle ve ürününüzle ilgili niyetlerinin ciddi olmadığı anlamına gelir.

Grafikler mevcut olabilir veya olmayabilir. Özellikle çalışmanızın sonuçlarını rapor etmeyecekseniz. Ama için ciddi projeler bu öğe gereklidir.

Örneğin: Programın geliştirilmesi sırasında aşağıdaki grafik materyali hazırlanmalıdır:

Teknik ve ekonomik göstergeler;

Program yapısı;

Programın giriş verilerinin sunum formatı;

Algoritmanın genel şeması (2 sayfa);
o temel hesaplama algoritmaları;
programın nasıl çalıştığına dair bir örnek.

Kontrol ve kabul prosedürü bölümünde, test türleri ve Genel Gereksinimler işi kabul etmek. Mümkünse bu paragrafta "Müşteri tarafından sağlanan ekipman üzerinde geliştirmenin kontrol ve kabulünün yapıldığını" belirtin, aksi takdirde ekipmanı yanınızda getirmeniz gerekebilir.

Örneğin: Geliştirmenin kontrolü ve kabulü, kontrol testleri ve hata ayıklama örnekleri temelinde gerçekleştirilir. Bu, tüm program işlevlerinin yürütülmesini kontrol eder.
Görev tanımının Eklerinde, gerekirse:
gelişmeyi doğrulayan araştırma ve diğer çalışmaların bir listesi;

Algoritma şemaları, tablolar, açıklamalar, gerekçeler, hesaplamalar ve geliştirmede kullanılabilecek diğer belgeler;

Diğer gelişim kaynakları.