Tz nimani anglatadi? Xo'sh, "Texnik spetsifikatsiya" nima? Loyiha haqida umumiy ma'lumot


Mendan tez-tez so'rashadi: "Qanday qilib to'g'ri rivojlanish kerak texnik vazifa Uchun avtomatlashtirilgan tizim?. Texnik spetsifikatsiyalarni ishlab chiqish mavzusi doimiy ravishda turli forumlarda muhokama qilinadi. Bu savol shunchalik kengki, qisqacha javob berishning iloji yo'q. Shuning uchun men ushbu mavzu bo'yicha uzoq maqola yozishga qaror qildim. Maqola ustida ishlash jarayonida hammasini bir maqolaga to‘g‘rilab bo‘lmasligini angladim, chunki... Taxminan 50 sahifa bo'ladi va men uni 2 qismga bo'lishga qaror qildim:

  • Birinchi qismda " Texnik shartlarni ishlab chiqish. Bu nima, nima uchun kerak, qaerdan boshlash kerak va u qanday bo'lishi kerak? Mavzuning savollariga batafsil javob berishga harakat qilaman, texnik topshiriqning tuzilishi va maqsadini ko'rib chiqaman va talablarni shakllantirish bo'yicha ba'zi tavsiyalar beraman.
  • Ikkinchi qism " Texnik shartlarni ishlab chiqish. Talablarni qanday shakllantirish kerak? to'liq axborot tizimiga qo'yiladigan talablarni aniqlash va shakllantirishga bag'ishlanadi.

Birinchidan, siz "Texnik spetsifikatsiyani qanday ishlab chiqish kerak?" Deganlarni qiziqtirgan savolni aniqlab olishingiz kerak. Gap shundaki, texnik shartlarni ishlab chiqishga yondashuv ko'p jihatdan u amalga oshirilayotgan maqsadlarga va kim tomonidan qo'llanilishiga bog'liq bo'ladi. Men qanday variantlar haqida gapiryapman:

  • Tijorat tashkiloti avtomatlashtirilgan tizimni joriy etishga qaror qildi. U o'zining IT xizmatiga ega emas va buni amalga oshirishga qaror qildi: Manfaatdor shaxs Texnik spetsifikatsiyani ishlab chiqishi va uni uchinchi tomonga ishlab chiqish uchun topshirishi kerak;
  • Tijorat tashkiloti avtomatlashtirilgan tizimni joriy etishga qaror qildi. U o'zining IT xizmatiga ega. Biz shunday qilishga qaror qildik: Texnik spetsifikatsiyani ishlab chiqish, keyin uni IT xizmati va manfaatdor tomonlar o‘rtasida kelishish va uni o‘z kuchimiz bilan amalga oshirish;
  • Davlat organi IT-loyihasini boshlashga qaror qildi. Bu erda hamma narsa juda xira, juda ko'p rasmiyatchiliklar, zarbalar, qisqartirishlar va hokazo. Men ushbu maqolada bu variantni ko'rib chiqmayman.
  • IT-kompaniyasi avtomatlashtirilgan tizimlarni ishlab chiqish va/yoki joriy etish bo'yicha xizmatlar ko'rsatadi. Bu eng ko'p qiyin ish, chunki siz turli sharoitlarda ishlashingiz kerak:

    Mijozning o'z nuqtai nazariga ega bo'lgan o'z mutaxassislari bor va ular Texnik spetsifikatsiyalarga aniq talablar qo'yadilar;

    • Texnik topshiriqlar ichki ishlab chiquvchilar uchun ishlab chiqilgan (mijozning ahamiyati yo'q);
    • Texnik topshiriqlar pudratchiga (ya'ni kompaniyaning shtatdagi dasturchilar guruhi yoki alohida mutaxassisga) topshirish uchun ishlab chiqilgan;
    • Olingan natija bo'yicha kompaniya va mijoz o'rtasida tushunmovchilik yuzaga keladi va kompaniya qayta-qayta savol beradi: "Texnik xususiyatlarni qanday ishlab chiqish kerak?" Balki, oxirgi holat Bu paradoksga o'xshaydi, lekin bu haqiqat.
    • Boshqa, kamroq tarqalgan variantlar ham mumkin;

O'ylaymanki, endi o'quvchida savollar bo'lishi kerak:

  • Nima uchun Texnik spetsifikatsiyalar har doim bir xil tarzda ishlab chiqilishi mumkin emas?;
  • Standartlar, usullar, tavsiyalar bormi? Ularni qayerdan olsam bo'ladi?
  • Texnik topshiriqni kim ishlab chiqishi kerak? Bu odam maxsus bilimga ega bo'lishi kerakmi?
  • Texnik topshiriq yaxshi yozilgan yoki yo'qligini qanday tushunish mumkin?
  • Uni kimning hisobidan ishlab chiqish kerak va hatto kerakmi?

Bu ro'yxat cheksiz bo'lishi mumkin. Men buni ishonch bilan aytyapman, chunki men 15 yildan beri professional rivojlanishdaman. dasturiy ta'minot, va Texnik spetsifikatsiyalar savoli siz ishlayotgan har qanday ishlab chiqish guruhida paydo bo'ladi. Buning sabablari boshqacha. Texnik topshiriqni ishlab chiqish mavzusini ko'tarib, men uni mavzuga qiziqqan barchaga 100% taqdim eta olmasligimni yaxshi bilaman. Ammo, ular aytganidek, "hamma narsani tartibga solishga" harakat qilaman. Mening maqolalarim bilan allaqachon tanish bo'lganlar, men boshqa odamlarning asarlaridan "nusxa ko'chirish" dan foydalanmasligimni, boshqa odamlarning kitoblarini qayta nashr qilmasligimni, ko'p sahifali standartlardan va Internetda o'zingiz topishingiz mumkin bo'lgan boshqa hujjatlardan iqtibos keltirmasligimni bilishadi, ularni o'zingizning daho fikrlaringiz sifatida o'tkazib yuboring. Faqat qidiruv tizimiga "Texnik spetsifikatsiyani qanday ishlab chiqish kerak" ni kiriting va siz juda ko'p qiziqarli, ammo, afsuski, takrorlanadigan narsalarni o'qishingiz mumkin. Qoidaga ko'ra, forumlarda aqlli bo'lishni yaxshi ko'radiganlar (shunchaki qidirib ko'ring!) O'zlari hech qachon to'g'ri Texnik spetsifikatsiyani tuzmaganlar va bu masala bo'yicha doimiy ravishda GOST tavsiyalarini keltirishgan. Va bu masalaga haqiqatan ham jiddiy munosabatda bo'lganlar odatda forumlarda o'tirishga vaqtlari yo'q. Aytgancha, biz GOST standartlari haqida ham gaplashamiz. Ishlagan yillarim davomida men ko'p variantlarni ko'rdim texnik hujjatlar, ham alohida mutaxassislar, ham taniqli jamoalar va konsalting kompaniyalari tomonidan tuzilgan. Ba'zan men ham ushbu faoliyat bilan shug'ullanaman: men o'zimga vaqt ajrataman va g'ayrioddiy manbalardan (masalan, bir oz aql kabi) qiziqarli mavzu bo'yicha ma'lumot qidiraman. Natijada, men "GazProm", "Rossiya temir yo'llari" va boshqa ko'plab hayvonlarning hujjatlarini ko'rishga majbur bo'ldim. qiziqarli kompaniyalar. Albatta, men ushbu hujjatlar menga ochiq manbalardan kelganiga yoki maslahatchilarning mas'uliyatsizligiga (Internetdagi ma'lumotlarni tarqatish) qaramay, men maxfiylik siyosatiga rioya qilaman. Shuning uchun men darhol aytaman: maxfiy ma'lumotlar, boshqa kompaniyalarga tegishli bo'lgan, men (kasbiy axloq) kelib chiqish manbalaridan qat'i nazar, baham ko'rmayman.

Texnik spetsifikatsiya nima?

Endi biz qiladigan birinchi narsa bu "Texnik spetsifikatsiya" qanday hayvon ekanligini aniqlashdir.

Ha, haqiqatan ham faoliyatning ushbu qismini (dasturiy ta'minotni ishlab chiqish) tartibga solishga harakat qiladigan GOSTlar va standartlar mavjud. Bir vaqtlar bu GOSTlarning barchasi tegishli va faol ishlatilgan. Endi bu hujjatlarning dolzarbligi haqida turli fikrlar mavjud. Ba'zilarning ta'kidlashicha, GOSTlar juda uzoqni ko'ra oladigan odamlar tomonidan ishlab chiqilgan va hali ham dolzarbdir. Boshqalar, ular umidsiz ravishda eskirgan deb aytishadi. Ehtimol, kimdir hozir haqiqat o'rtada deb o'ylagandir. Men Gyotening so'zlari bilan javob bergan bo'lardim: “Ular ikki qarama-qarshi fikr orasida haqiqat yotadi, deyishadi. Hech qanday holatda! Ular orasida muammo bor”. Demak, bu fikrlar orasida haqiqat yo'q. Chunki GOSTlar zamonaviy taraqqiyotning amaliy muammolarini ochib bermaydi, ularni tanqid qiluvchilar esa muqobil variantlarni taklif qilmaydi (o'ziga xos va tizimli).

E'tibor bering, GOST aniq ta'rifni ham bermaydi, faqat shunday deydi: "Atom elektr stantsiyasi uchun TK - bu avtomatlashtirilgan tizimni yaratish (ishlab chiqish yoki modernizatsiya qilish - keyin yaratish) talablari va tartibini belgilaydigan asosiy hujjat. atom elektr stansiyasini ishlab chiqish va uni ishga tushirilgandan keyin qabul qilish amalga oshiriladi.

Agar kimdir men aytayotgan GOSTlar bilan qiziqsa, ular mana:

  • GOST 2.114-95 bitta tizim dizayn hujjatlari. Texnik shartlar;
  • GOST 19.201-78 Dastur hujjatlarining yagona tizimi. Texnik vazifa. Tarkib va ​​dizaynga qo'yiladigan talablar;
  • GOST 34.602-89 Axborot texnologiyalari. Avtomatlashtirilgan tizimlar uchun standartlar to'plami. Avtomatlashtirilgan tizimni yaratish bo'yicha texnik topshiriqlar.

Vikipediyada ancha yaxshi ta'rif berilgan (garchi faqat dasturiy ta'minot uchun emas, balki umuman texnik xususiyatlar haqida): " Texnik vazifa- Bu asl hujjat dizayn uchun texnik ob'ekt. Texnik vazifa ishlab chiqilayotgan ob'ektning asosiy maqsadini, uning texnik va taktikasini belgilaydi spetsifikatsiyalar, sifat ko'rsatkichlari va texnik-iqtisodiy talablar, hujjatlarni yaratishning zarur bosqichlarini bajarish bo'yicha ko'rsatmalar (loyihaviy, texnologik, dasturiy ta'minot va boshqalar) va uning tarkibi, shuningdek, maxsus talablar. Yangi narsalarni yaratish uchun boshlang'ich hujjat sifatida vazifa nomi, mazmuni, bajarish tartibi va boshqalar bilan farq qiluvchi faoliyatning barcha sohalarida mavjud (masalan, qurilishdagi dizayn topshirig'i, jangovar topshiriq, uy vazifasi, shartnoma. adabiy asar va boshqalar). d.)"

Shunday qilib, ta'rifdan kelib chiqqan holda, Texnik spetsifikatsiyaning asosiy maqsadi ishlab chiqilayotgan ob'ektga, bizning holatlarimizda avtomatlashtirilgan tizimga qo'yiladigan talablarni shakllantirishdir.

Bu asosiy narsa, lekin yagona. Asosiy narsaga o'tish vaqti keldi: va'da qilinganidek, hamma narsani "javonlarga" qo'yish.

Talablar haqida nimani bilishingiz kerak? Barcha talablar turi va xususiyatlari bo'yicha bo'linishi kerakligini aniq tushunish kerak. Endi biz buni qanday qilishni o'rganamiz. Turlari bo'yicha talablarni ajratish uchun bizga GOST yordam beradi. U erda taqdim etilgan talablar turlari ro'yxati mavjud yaxshi misol qaysi turdagi talablarni hisobga olish kerak. Masalan:

  • Funktsionallik talablari;
  • Xavfsizlik va kirish huquqlariga qo'yiladigan talablar;
  • Xodimlarning malakasiga qo'yiladigan talablar;
  • …. Va hokazo. Siz ular haqida aytib o'tilgan GOSTda o'qishingiz mumkin (va quyida men ularni biroz batafsilroq ko'rib chiqaman).

Muvaffaqiyatli Texnik spetsifikatsiyaning asosiy omili aniq ishlab chiqilgan funktsional talablar ekanligi sizga ayon deb o'ylayman. Men aytgan ish va usullarning aksariyati ana shu talablarga bag‘ishlangan. Funktsionallik talablari texnik topshiriqni ishlab chiqish bo'yicha ishlarning murakkabligining 90% ni tashkil qiladi. Qolgan hamma narsa ko'pincha bu talablarni qoplaydigan "kamuflyaj" dir. Agar talablar noto'g'ri tuzilgan bo'lsa, unda qanday chiroyli kamuflyaj kiysangiz ham, muvaffaqiyatli loyiha chiqmaydi. Ha, rasmiy ravishda barcha talablar bajariladi (GOST J bo'yicha), texnik shartlar ishlab chiqilgan, tasdiqlangan va imzolangan va buning uchun pul olingan. Nima bo `pti? Va keyin eng qiziqarli qism boshlanadi: nima qilish kerak? Agar bu Davlat buyurtmasi bo'yicha loyiha bo'lsa, unda hech qanday muammo yo'q - byudjet shunday bo'ladiki, u hech kimning cho'ntagiga to'g'ri kelmaydi va amalga oshirish jarayonida (agar mavjud bo'lsa) hamma narsa aniq bo'ladi. Loyiha budjetlarining katta qismi Davlat buyurtmalariga aynan shunday sarflanadi (ular “TZ” yozgan, o‘nlab millionlarni yo‘qotgan, lekin loyihani amalga oshirmagan. Barcha rasmiyatchiliklar kuzatilgan, aybdorlar yo‘q, yangi mashina yaqinida. uy. Go'zallik!). Lekin biz gaplashamiz tijorat tashkilotlari, bu erda pul hisoblangan va boshqa natija kerak. Shuning uchun, keling, asosiy narsani, qanday qilib rivojlantirishni tushunaylik foydali va ishlaydigan Texnik spetsifikatsiyalar.

Men talablar turlari haqida aytdim, lekin xususiyatlar haqida nima deyish mumkin? Agar talablar turlari har xil bo'lishi mumkin bo'lsa (loyiha maqsadlariga qarab), u holda xususiyatlar bilan hamma narsa sodda, ulardan 3 tasi bor:

  1. Talab bo'lishi kerak tushunarli;
  2. Talab bo'lishi kerak xos;
  3. Talab bo'lishi kerak imtihon topshiruvchilar;

Bundan tashqari, oxirgi mulk oldingi ikkitasisiz mumkin emas, ya'ni. “lakmus testi”ning bir turi hisoblanadi. Agar talabning natijasini sinab ko'rish mumkin bo'lmasa, bu uning noaniq yoki aniq emasligini anglatadi. O'ylab ko'r. Talablarning mana shu uch xususiyatini egallashda mahorat va professionallik yotadi. Bu aslida juda oddiy. Buni tushunganingizda.

Bu Texnik spetsifikatsiya nima ekanligi haqidagi hikoyani yakunlaydi va asosiy narsaga o'tadi: talablarni qanday shakllantirish kerak. Lekin bu unchalik tez emas. Yana bir muhim jihat bor:

  • Texnik spetsifikatsiya qaysi tilda (tushunish qiyinligi nuqtai nazaridan) yozilishi kerak?
  • Turli funktsiyalar, algoritmlar, ma'lumotlar turlari va boshqa texnik narsalarning spetsifikatsiyalarini tavsiflash kerakmi?
  • Aytgancha, GOSTlarda ham eslatib o'tilgan texnik dizayn nima va u Texnik spetsifikatsiyalar bilan qanday bog'liq?

Bu savollarga javoblarda juda makkor narsa yashiringan. Shuning uchun nizolar ko'pincha talablarning etarliligi yoki yo'qligi, buyurtmachi va pudratchilar tomonidan hujjatning tushunarliligi, ortiqcha, taqdimot formati va boshqalar haqida kelib chiqadi. Texnik topshiriq va texnik loyiha o'rtasidagi chegara qayerda?

Texnik vazifa- bu mijozga tushunarli (oddiy, tanish) tilda tuzilgan talablarga asoslangan hujjat. Bunday holda, mijoz uchun tushunarli bo'lgan sanoat terminologiyasidan foydalanish mumkin va kerak. Texnik amalga oshirishning o'ziga xos xususiyatlari bilan bog'liqlik bo'lmasligi kerak. Bular. texnik spetsifikatsiya bosqichida, printsipial jihatdan, ushbu talablar qaysi platformada amalga oshirilishi muhim emas. Garchi istisnolar mavjud bo'lsa-da. Agar mavjud bo'lgan tizimni amalga oshirish haqida gapiradigan bo'lsak dasturiy mahsulot, keyin bunday havola sodir bo'lishi mumkin, lekin faqat ekran shakllari, hisobot shakllari, va hokazolar darajasida talablarni aniqlashtirish va shakllantirish, shuningdek, texnik topshiriqlarni ishlab chiqish amalga oshirilishi kerak biznes tahlilchisi. Va, albatta, dasturchi emas (agar u bu rollarni birlashtirmasa, bu sodir bo'ladi). Bular. bu shaxs Buyurtmachi bilan o'z biznesi tilida gaplashishi kerak.

Texnik loyiha- bu texnik topshiriqda belgilangan talablarni texnik jihatdan amalga oshirish uchun mo'ljallangan hujjat. Ushbu hujjat ma'lumotlar tuzilmalari, triggerlar va saqlangan protseduralar, algoritmlar va talab qilinadigan boshqa narsalarni tavsiflaydi. texnik mutaxassislar . Mijoz buni umuman o'rganishi shart emas (hatto bunday shartlar unga tushunarli bo'lmasligi mumkin). Texnik loyiha amalga oshiradi Tizim arxitektori(bu rolni dasturchi bilan birlashtirish juda normaldir). To'g'rirog'i, arxitektor boshchiligidagi OAJ mutaxassislari guruhi. Loyiha qanchalik katta bo'lsa, texnik topshiriqlar bo'yicha odamlar shunchalik ko'p ishlaydi.

Amalda bizda nima bor? Direktorga tasdiqlash uchun texnik atamalar, ma'lumotlar turlari va ularning qiymatlari tavsiflari, ma'lumotlar bazasi tuzilishi va boshqalar bilan to'ldirilgan texnik spetsifikatsiya taqdim etilganida tomosha qilish juda kulgili. U, albatta, tushunishga harakat qiladi, chunki u tasdiqlashi kerak. , qatorlar orasidagi tanish so'zlarni topishga harakat qilish va zanjir biznes talablarini yo'qotmaslik. Bu tanish holatmi? Va u qanday tugaydi? Qoidaga ko'ra, bunday texnik shartlar tasdiqlanadi, keyin amalga oshiriladi va 80% hollarda ular bajarilgan ish faktiga umuman mos kelmaydi, chunki ular o'zgartirishga qaror qilishdi, ko'p narsalarni qayta qilishdi, noto'g'ri tushunishdi, noto'g'ri o'ylashdi va hokazo. va h.k. Va keyin ishni topshirish seriyasi boshlanadi. "Ammo bu erda bizga kerak bo'lgan narsa emas", lekin "bu biz uchun ishlamaydi", "bu juda murakkab", "bu noqulay" va hokazo. Tanish eshitildimi?!! Bu menga tanish, o'z vaqtida zarba berishim kerak edi.

Xo'sh, bizda amalda nima bor? Ammo amalda bizda texnik topshiriq va texnik loyiha o'rtasida aniq chegara mavjud. U turli xil ko'rinishlarda TK va TP o'rtasida suzib yuradi. Va bu yomon. Bu rivojlanish madaniyati zaiflashgani sababli sodir bo'ladi. Bu qisman mutaxassislarning vakolatlari, qisman byudjetlar va muddatlarni qisqartirish istagi bilan bog'liq (oxir-oqibat, hujjatlar ko'p vaqt talab etadi - bu haqiqat). Texnik dizayndan alohida hujjat sifatida foydalanishga ta'sir qiluvchi yana bir muhim omil mavjud: tezkor ishlab chiqish vositalarining jadal rivojlanishi, shuningdek, ishlab chiqish metodologiyasi. Ammo bu alohida hikoya, men quyida bu haqda bir necha so'z aytaman.

Yana bir kichik, ammo muhim nuqta. Ba'zan Texnik topshiriqlar oddiy va tushunarli talablarning kichik qismi deb ataladi. Misol uchun, ba'zi shartlarga ko'ra ob'ektni qidirishni yaxshilash, hisobotga ustun qo'shish va hokazo. Bu yondashuv juda oqlanadi, nima uchun hayotni murakkablashtiradi. Ammo u yirik loyihalarda emas, balki kichik yaxshilanishlarda qo'llaniladi. Men buni dasturiy mahsulotlarga texnik xizmat ko'rsatishga yaqinroq deyman. Bunday holda, texnik topshiriq talabni amalga oshirish uchun aniq texnik echimni ham tavsiflashi mumkin. Masalan, “Falon algoritmga falon o‘zgartirish kiriting”, dasturchi uchun ma’lum bir protsedura va o‘ziga xos o‘zgarishlarni ko‘rsatadi. Bu texnik topshiriq va texnik loyihalar o'rtasidagi chegara butunlay o'chirilganda, chunki zarur bo'lmagan joyda qog'ozni shishirtirishning iqtisodiy maqsadga muvofiqligi yo'q va foydali hujjat yaratilgan. Va bu to'g'ri.

Texnik spetsifikatsiya umuman kerakmi? Texnik loyiha haqida nima deyish mumkin?

Men haddan tashqari qizib ketyapmanmi? Bu hech kimsiz mumkinmi Texnik spetsifikatsiyalar? Tasavvur qiling, bu mumkin (aniqrog'i, mumkin) va bu yondashuv ko'plab izdoshlarga ega va ularning soni ortib bormoqda. Qoidaga ko'ra, yosh mutaxassislar Scrum, Agile va boshqa tezkor rivojlanish texnologiyalari haqidagi kitoblarni o'qib chiqqandan keyin. Aslida, bu ajoyib texnologiyalar va ular ishlaydi, lekin ular tom ma'noda "texnik vazifalarni bajarish kerak emas" demaydi. Ular "minimal hujjatlar", ayniqsa keraksiz, Buyurtmachiga yaqinroq, aniqroq va tezroq natijalarni aytishadi. Ammo hech kim talablarni yozib olishni bekor qilmadi va bu erda aniq ko'rsatilgan. Aynan shu erda talablar men yuqorida aytib o'tgan uchta ajoyib xususiyatga asoslangan holda belgilanadi. Shunchaki, ba'zi odamlarning ongi shunday tuzilganki, agar biror narsani soddalashtirish mumkin bo'lsa, keling, uni butunlay yo'qlik darajasiga qadar soddalashtiraylik. Eynshteyn aytganidek " Buni iloji boricha sodda qiling, lekin undan oddiyroq emas." . Bu hamma narsaga mos keladigan oltin so'zlar. Shunday qilib Texnik vazifa kerak, aks holda siz muvaffaqiyatli loyihani ko'rmaysiz. Yana bir savol - uni qanday tuzish va u erda nimani kiritish kerak. Tez rivojlanish metodologiyalari nuqtai nazaridan, siz faqat talablarga e'tibor qaratishingiz kerak va barcha "kamuflyaj" ni bekor qilish mumkin. Aslida, men bunga qo'shilaman.

Texnik loyiha haqida nima deyish mumkin? Ushbu hujjat juda foydali va o'z ahamiyatini yo'qotmagan. Bundan tashqari, ko'pincha siz usiz qilolmaysiz. Ayniqsa, autsorsingni rivojlantirish bo'yicha ishlar haqida gap ketganda, ya'ni. autsorsing tamoyili bo'yicha. Agar buni qilmasangiz, siz o'ylagan tizim qanday bo'lishi kerakligi haqida ko'p narsalarni o'rganish xavfi ostida qolasiz. Xaridor u bilan tanishishi kerakmi? Agar u xohlasa, nega yo'q, lekin bu hujjatni turib olish va tasdiqlashning hojati yo'q, u faqat orqaga chekinadi va ishga aralashadi. Tizimni eng kichik detallarigacha loyihalash deyarli mumkin emas. Bunday holda siz texnik dizaynga doimiy ravishda o'zgartirishlar kiritishingiz kerak bo'ladi, bu juda ko'p vaqtni oladi. Va agar tashkilot og'ir byurokratik bo'lsa, unda siz barcha asablaringizni u erda qoldirasiz. Ushbu turdagi dizaynni qisqartirish men yuqorida aytib o'tgan zamonaviy tez rivojlanish metodologiyalari bilan bog'liq. Aytgancha, ularning barchasi klassik XP (ekstremal dasturlash) ga asoslangan - bu yondashuv allaqachon 20 yoshda. Shunday qilib, mijozga tushunarli bo'lgan yuqori sifatli Texnik spetsifikatsiyani yarating va texnik dizayndan foydalaning. ichki hujjat, tizim arxitektori va dasturchilar o'rtasidagi munosabatlar uchun.

Texnik dizayn haqida qiziqarli tafsilot: mavzuga yo'naltirilgan dizayn printsipi asosida ishlab chiqilgan ba'zi ishlab chiqish vositalari (masalan, 1C va shunga o'xshash) dizayn (hujjatlashtirish jarayonini nazarda tutadi) faqat butun quyi tizimlar o'rtasidagi o'zaro ta'sir zarur bo'lgan haqiqatan ham murakkab sohalarda talab qilinadi deb taxmin qiladi. Eng oddiy holatda, masalan, katalog yoki hujjat yaratish, faqat to'g'ri tuzilgan biznes talablari etarli. Buni ushbu platformaning mutaxassislar tayyorlash borasidagi biznes strategiyasi ham tasdiqlaydi. Agar qarasangiz Imtihon chiptasi mutaxassis (bu "dasturchi" emas, balki shunday deyiladi), shunda siz faqat biznes talablari borligini va ularni dastur tilida qanday amalga oshirish mutaxassisning vazifasi ekanligini ko'rasiz. Bular. Texnik loyiha hal qilish uchun mo'ljallangan muammoning bir qismini mutaxassis "o'z boshida" hal qilishi kerak (biz o'rta murakkablikdagi vazifalar haqida gapiramiz), bu erda va hozir, ma'lum rivojlanish va dizayn standartlariga rioya qilgan holda, ular yana shakllanadi. platformasi uchun 1C kompaniyasi. Shunday qilib, ish natijalari bir xil bo'lgan ikkita mutaxassisdan biri imtihondan o'tishi mumkin, ikkinchisi esa imtihondan o'ta olmaydi, chunki rivojlanish standartlarini qo'pol ravishda buzgan. Ya'ni, mutaxassislar shunday malakaga ega bo'lishi kerakki, ular tizim arxitektorlari ishtirokisiz mustaqil ravishda tipik vazifalarni loyihalashtira oladilar. Va bu yondashuv ishlaydi.

Keling, savolni o'rganishni davom ettiramiz: "Texnik topshiriqga qanday talablar kiritilishi kerak?"

Axborot tizimiga qo'yiladigan talablarni shakllantirish. Texnik topshiriqning tuzilishi

Darhol aniq aytaylik: biz axborot tizimiga talablarni shakllantirish haqida alohida gaplashamiz, ya'ni. biznes talablarini ishlab chiqish, biznes-jarayonlarni rasmiylashtirish bo'yicha ishlar va oldingi barcha konsalting ishlari allaqachon yakunlangan deb hisoblasak. Albatta, bu bosqichda ba'zi tushuntirishlar berilishi mumkin, ammo faqat tushuntirishlar. Avtomatlashtirish loyihasining o'zi biznes muammolarini hal qilmaydi - buni unutmang. Bu aksioma. Ba'zi sabablarga ko'ra, ba'zi menejerlar, agar ular dasturni sotib olsalar, tartibsiz biznesga buyurtma kelishiga ishonib, uni rad etishga harakat qilmoqdalar. Ammo aksioma aksiomadir, chunki u isbot talab qilmaydi.

Har qanday faoliyat kabi, talablarni shakllantirish bosqichlarga bo'linishi mumkin (va kerak). Hamma narsaning o'z vaqti bor. Bu og'ir intellektual ish. Va agar siz unga etarlicha e'tibor bermasangiz, natija mos bo'ladi. tomonidan ekspert baholashlari, Texnik topshiriqni ishlab chiqish narxi 30-50% bo'lishi mumkin. Men ham xuddi shunday fikrdaman. Garchi 50 - bu juda ko'p. Axir, Texnik spetsifikatsiya ishlab chiqilishi kerak bo'lgan oxirgi hujjat emas. Axir, texnik dizayn ham bo'lishi kerak. Ushbu o'zgarish loyiha guruhlari tomonidan ishlab chiqish jarayonida foydalaniladigan turli xil avtomatlashtirish platformalari, yondashuvlari va texnologiyalari bilan bog'liq. Misol uchun, agar biz C++ kabi klassik tilda rivojlanish haqida gapiradigan bo'lsak, unda batafsil texnik dizayn ajralmas hisoblanadi. Agar biz 1C platformasida tizimni amalga oshirish haqida gapiradigan bo'lsak, yuqorida ko'rganimizdek, dizayn bilan bog'liq vaziyat biroz boshqacha (garchi tizimni noldan ishlab chiqishda u klassik sxema bo'yicha ishlab chiqilgan bo'lsa ham).

Garchi talablar bayonoti asosiy qism bo'lsa-da Texnik spetsifikatsiyalar, va ba'zi hollarda u texnik xususiyatlarning yagona bo'limiga aylanadi, bu muhim hujjat ekanligiga e'tibor berishingiz kerak va u shunga mos ravishda tuzilishi kerak. Qayerdan boshlash kerak? Avvalo, siz tarkibdan boshlashingiz kerak. Tarkibni yozing va keyin uni kengaytirishni boshlang. Shaxsan men buni qilaman: avval tarkibni chizaman, maqsadlarni, barcha kirish ma'lumotlarini tasvirlayman, so'ngra asosiy qismga - talablarni shakllantirishga tushaman. Nega aksincha emas? Bilmayman, bu men uchun qulayroq. Birinchidan, bu vaqtning ancha kichik qismi (talablarga nisbatan), ikkinchidan, siz barcha kirish ma'lumotlarini tasvirlayotganda, siz asosiy narsaga moslashasiz. Xo'sh, kimga yoqadi. Vaqt o'tishi bilan siz o'zingizning Texnik spetsifikatsiya shablonini ishlab chiqasiz. Boshlash uchun men GOSTda tavsiflangan tarkibni olishni maslahat beraman. Bu kontent uchun juda mos! Keyin biz quyidagi uchta xususiyat bo'yicha tavsiyalarni unutmasdan, har bir bo'limni olamiz va tavsiflashni boshlaymiz: tushunarlilik, o'ziga xoslik va sinovdan o'tish. Nega men bunchalik qattiq turib oldim? Bu haqda keyingi bo'limda batafsil. Va endi men GOSTda tavsiya etilgan texnik xususiyatlarning o'sha nuqtalarini ko'rib chiqishni taklif qilaman.

  1. umumiy ma'lumot;
  2. tizimni yaratish (ishlab chiqish) maqsadi va maqsadlari;
  3. avtomatlashtirish ob'ektlarining xarakteristikalari;
  4. tizim talablari;
  5. tizimni yaratish bo'yicha ishlarning tarkibi va mazmuni;
  6. tizimni nazorat qilish va qabul qilish tartibi;
  7. tizimni ishga tushirish uchun avtomatlashtirish ob'ektini tayyorlash bo'yicha ishlarning tarkibi va mazmuniga qo'yiladigan talablar;
  8. hujjatlar talablari;
  9. rivojlanish manbalari.

Hammasi bo'lib 9 ta bo'lim, ularning har biri ham kichik bo'limlarga bo'lingan. Keling, ularni tartibda ko'rib chiqaylik. Qulaylik uchun men har bir element uchun hamma narsani jadval shaklida taqdim etaman.

1-bo'lim. umumiy ma'lumot.

GOST bo'yicha tavsiyalar
tizimning to'liq nomi va uning ramzi; Bu erda hamma narsa aniq: biz tizim qanday nomlanishini, uning qisqa nomini yozamiz
shartnomaning mavzu kodi yoki kodi (raqami); Bu muhim emas, lekin agar kerak bo'lsa, uni belgilashingiz mumkin
tizimni ishlab chiquvchi va buyurtmachi (foydalanuvchi) korxonalari (birlashmalari) nomi va ularning rekvizitlari; loyihada kim (qaysi tashkilotlar) ishlashini ko'rsating. Siz ularning rollarini ham belgilashingiz mumkin.Hatto bu qismni olib tashlashingiz mumkin (juda rasmiy).
tizim asosida yaratilgan hujjatlar ro‘yxati, bu hujjatlar kim tomonidan va qachon tasdiqlanganligi; Foydali ma'lumot. Bu erda talablarning ma'lum bir qismi bilan tanishish uchun sizga taqdim etilgan me'yoriy va ma'lumotnoma hujjatlarini ko'rsatishingiz kerak.
tizimni yaratish bo'yicha ishlarning rejalashtirilgan boshlanish va tugash sanalari; Vaqtni belgilash bo'yicha so'rovlar. Ba'zan ular bu haqda yozadilar texnik xususiyatlar , lekin ko'pincha bunday narsalar mehnat shartnomalarida tasvirlangan
ishni moliyalashtirish manbalari va tartibi to'g'risidagi ma'lumotlar; Muddatlar haqida oldingi paragrafda bo'lgani kabi. Davlat buyurtmalari uchun ko'proq tegishli (davlat xodimlari uchun)
tizimni (uning qismlarini) yaratish, individual vositalarni (apparat, dasturiy ta'minot, axborot) va dasturiy-texnik (dasturiy-uslubiy) komplekslarini ishlab chiqarish va sozlash bo'yicha ish natijalarini ro'yxatdan o'tkazish va buyurtmachiga taqdim etish tartibi. tizimi. Men bu fikrga ehtiyoj sezmayapman, chunki ... Hujjatlarga qo'yiladigan talablar alohida chiqariladi va qo'shimcha ravishda bir butun mavjud alohida bo'lim Tizimni "nazorat qilish va qabul qilish tartibi".

Bo'lim 2. tizimni yaratish (ishlab chiqish) maqsadi va maqsadlari.

GOST bo'yicha tavsiyalar Amalda bu haqda nima qilish kerak
Tizimning maqsadi Bir tomondan, maqsad oddiy. Lekin uni maxsus shakllantirish tavsiya etiladi. Agar siz "X kompaniyasida ombor hisobini yuqori sifatli avtomatlashtirish" kabi biror narsa yozsangiz, unda siz talablarning yaxshi shakllantirilishidan qat'i nazar, natijani tugagandan so'ng uzoq vaqt davomida muhokama qilishingiz mumkin. Chunki Xaridor har doim sifat deganda u boshqa narsani nazarda tutganini aytishi mumkin. Umuman olganda, siz bir-biringizning asablarini juda ko'p buzishingiz mumkin, lekin nima uchun? Darhol shunday yozgan ma'qul: "Tizim X kompaniyasidagi ombor yozuvlarini ushbu Texnik spetsifikatsiyada ko'rsatilgan talablarga muvofiq saqlash uchun mo'ljallangan."
Tizimni yaratish maqsadlari Maqsadlar, albatta, muhim bo'limdir. Agar biz uni o'z ichiga oladigan bo'lsak, unda biz ushbu maqsadlarni shakllantirishimiz kerak. Agar siz maqsadlarni shakllantirishda qiyinchiliklarga duch kelsangiz, unda ushbu bo'limni butunlay chiqarib tashlash yaxshiroqdir. Muvaffaqiyatsiz maqsadga misol: "Ta'minlang tez ishlov berish menejer tomonidan hujjatlar." Tez nima? Buni keyin cheksiz isbotlash mumkin. Agar bu muhim bo'lsa, unda qayta shakllantirish yaxshiroqdir bu maqsad shunga o'xshash: "Savdo menejeri 10 daqiqada 100 qatordan iborat "Tovarlarni sotish" hujjatini tuzishi kerak." Agar, masalan, menejer hozirda bunga bir soat vaqt ajratsa, bu kompaniya uchun juda ko'p va ular uchun muhim bo'lsa, shunday maqsad paydo bo'lishi mumkin. Ushbu formulada maqsad allaqachon talablar bilan kesishadi, bu tabiiydir, chunki Maqsadlar daraxtini kengaytirganda (ya'ni, ularni kichikroq bog'liq maqsadlarga bo'lish), biz allaqachon talablarga yaqinlashamiz. Shuning uchun, siz o'zingizni bezovta qilmasligingiz kerak.

Umuman olganda, maqsadlarni aniqlash, ularni shakllantirish va maqsadlar daraxtini qurish qobiliyati butunlay alohida mavzudir. Asosiy narsani eslang: agar bilsangiz, yozing, ishonchingiz komil bo'lmasa, umuman yozmang. Maqsadlarni belgilamasangiz nima bo'ladi? Siz talablarga muvofiq ishlaysiz, bu ko'pincha qo'llaniladi.

Bo'lim 3. Avtomatlashtirish ob'ektlarining xarakteristikalari.

4-bo'lim. Tizim talablari

GOST bunday talablar ro'yxatini aniqlaydi:

  • tizimning tuzilishi va ishlashiga qo'yiladigan talablar;
  • tizim xodimlarining soni va malakasiga hamda ularning ish tartibiga qo'yiladigan talablar;
  • maqsad ko'rsatkichlari;
  • ishonchlilik talablari;
  • xavfsizlik talablari;
  • ergonomika va texnik estetikaga qo'yiladigan talablar;
  • mobil dinamiklar uchun ko'chma talablar;
  • tizim komponentlarini ishlatish, texnik xizmat ko'rsatish, ta'mirlash va saqlashga qo'yiladigan talablar;
  • axborotni ruxsatsiz kirishdan himoya qilish talablari;
  • baxtsiz hodisalarda ma'lumotlarning xavfsizligiga qo'yiladigan talablar;
  • tashqi ta'sirlardan himoya qilish talablari;
  • uchun talablar patent tozaligi;
  • standartlashtirish va unifikatsiya qilish talablari;

Asosiysi, albatta, o'ziga xos talablarga ega (funktsional) bo'lim bo'lishiga qaramay, bu bo'lim ham katta ahamiyatga ega bo'lishi mumkin (va ko'p hollarda shunday). Nima muhim va foydali bo'lishi mumkin:

  • Malakaviy talablar. Rivojlanayotgan tizim mutaxassislarni qayta tayyorlashni talab qilishi mumkin. Bular kelajakdagi tizim foydalanuvchilari ham, uni qo'llab-quvvatlash uchun kerak bo'ladigan IT mutaxassislari ham bo'lishi mumkin. Ushbu masalaga etarlicha e'tibor bermaslik ko'pincha muammolarga aylanadi. Agar mavjud xodimlarning malakasi aniq etarli bo'lmasa, o'qitishni tashkil etish, o'quv dasturi, vaqt va boshqalarga qo'yiladigan talablarni belgilash yaxshiroqdir.
  • Axborotni ruxsatsiz kirishdan himoya qilish talablari. Bu yerda hech qanday izoh yo‘q. Aynan ma'lumotlarga kirishni cheklash talablari shu. Agar bunday talablar rejalashtirilgan bo'lsa, u holda ular funktsional talablar (tushunuvchanlik, o'ziga xoslik, sinovdan o'tish) bilan bir xil qoidalarga muvofiq, iloji boricha batafsilroq yozilishi kerak. Shuning uchun bu talablar funktsional talablar bo'limiga kiritilishi mumkin
  • Standartlashtirishga qo'yiladigan talablar. Agar loyiha uchun qo'llaniladigan dizayn standartlari mavjud bo'lsa, ular talablarga kiritilishi mumkin. Qoidaga ko'ra, bunday talablar Buyurtmachining IT xizmati tomonidan qo'yiladi. Misol uchun, 1C kompaniyasi dastur kodini loyihalash, interfeys dizayni va boshqalar uchun talablarga ega;
  • Tizimning tuzilishi va ishlashiga qo'yiladigan talablar. Bu erda tizimlarni bir-biri bilan integratsiyalash talablari tavsiflanishi mumkin va umumiy arxitektura tavsifi taqdim etiladi. Ko'pincha, integratsiya talablari odatda alohida bo'limga yoki hatto alohida Texnik spetsifikatsiyaga bo'linadi, chunki bu talablar ancha murakkab bo'lishi mumkin.

Boshqa barcha talablar unchalik muhim emas va ularni tavsiflash shart emas. Menimcha, ular faqat hujjatlarni og'irlashtiradi va kam amaliy foyda keltiradi. Va ergonomik talablarni umumiy talablar shaklida tasvirlash juda qiyin, ularni funktsional talablarga o'tkazish yaxshiroqdir. Masalan, "Faqat bitta tugmani bosish orqali mahsulot narxi haqida ma'lumot oling" talabi shakllantirilishi mumkin. Menimcha, bu ergonomikaga tegishli bo'lsa-da, hali ham aniq funktsional talablarga yaqinroq.Tizim tomonidan bajariladigan funktsiyalarga (vazifalarga) qo'yiladigan talablar Bu muvaffaqiyatni belgilaydigan asosiy va asosiy nuqta. Qolgan hamma narsa a'lo darajada bajarilgan bo'lsa va ushbu bo'lim "3" bo'lsa ham, loyihaning natijasi eng yaxshisi "3" bo'ladi yoki hatto loyiha umuman muvaffaqiyatsiz bo'ladi. Bu haqda biz axborot byulletenining 5-soniga kiritiladigan ikkinchi maqolada batafsil to'xtalamiz. Aynan shu nuqtada men aytib o'tgan “talablarning uchta xususiyati qoidasi” amal qiladi.Garov turlariga qo'yiladigan talablar.

GOST quyidagi turlarni belgilaydi:

  • Matematik
  • Axborot
  • Lingvistik
  • Dasturiy ta'minot
  • Texnik
  • Metrologik
  • Tashkiliy
  • Uslubiy
  • va boshqalar…

Bir qarashda bu talablar ahamiyatsizdek tuyulishi mumkin. Ko'pgina loyihalarda bu to'g'ri. Lekin har doim emas. Ushbu talablarni qachon tasvirlash kerak:

  • Qaysi tilni (yoki platformani) rivojlantirish bo'yicha qarorlar qabul qilinmagan;
  • Tizim ko'p tilli interfeysni talab qiladi (masalan, rus/ingliz)
  • Tizimning ishlashi uchun alohida bo'linma yaratilishi yoki yangi xodimlarni yollash kerak;
  • Tizimning ishlashi uchun Buyurtmachi ish usullarida o'zgarishlarga duch kelishi kerak va bu o'zgarishlar aniqlanishi va rejalashtirilishi kerak;
  • Har qanday uskuna bilan integratsiya kutiladi va unga talablar qo'yiladi (masalan, sertifikatlash, muvofiqlik va boshqalar).
  • Boshqa vaziyatlar ham mumkin, barchasi loyihaning aniq maqsadlariga bog'liq.

Bo'lim 5. Tizimni yaratish bo'yicha ishlarning tarkibi va mazmuni

Bo'lim 6. Tizimni nazorat qilish va qabul qilish tartibi

Ishlarni bosqichlar bo'yicha qabul qilish bo'yicha umumiy talablar (ishtirokchi korxona va tashkilotlar ro'yxati, joy va muddatlar), qabul qilish hujjatlarini muvofiqlashtirish va tasdiqlash tartibi; Ishni topshirish va tizimni tekshirish tartibi uchun javobgarlikni o'z zimmangizga olishingizni qat'iy tavsiya qilaman. Aynan shuning uchun ham sinovdan o'tish mumkin bo'lgan talablar kerak, ammo agar ishni qabul qilish va topshirish tartibi aniq ko'rsatilmagan bo'lsa, tizim yetkazib berilganda sinovdan o'tkaziladigan talablarning mavjudligi ham etarli bo'lmasligi mumkin. Misol uchun, umumiy tuzoq: tizim qurilgan va to'liq ishlaydi, lekin Mijoz negadir unda ishlashga tayyor emas. Bu sabablar har qanday bo'lishi mumkin: vaqt yo'q, maqsadlar o'zgardi, kimdir ishdan ketdi va hokazo. Va u shunday deydi: "Biz hali yangi tizimda ishlamaganimiz sababli, bu ishlayotganiga ishonchimiz komil emas". Shunday qilib, ish bosqichlarini to'g'ri aniqlashni va bu bosqichlarning natijalarini qanday tekshirishni o'rganing. Bundan tashqari, bunday usullar mijozga boshidanoq tushunarli bo'lishi kerak. Agar ular texnik shartlar darajasida o'rnatilgan bo'lsa, kerak bo'lganda siz har doim ularga murojaat qilishingiz va uzatish bilan ishni yakunlashingiz mumkin.

Tizimni ishga tushirish uchun avtomatlashtirish ob'ektini tayyorlash bo'yicha ishlarning tarkibi va mazmuniga qo'yiladigan talablar 7-bo'lim.

Kompaniya tomonidan qabul qilingan (yoki rejalashtirilgan) ma'lumotlarni kiritish uchun boshqa qoidalar ham bo'lishi mumkin. Masalan, shartnoma haqidagi ma’lumotlar ilgari istalgan shaklda matn qatori sifatida kiritilar edi, endi esa alohida raqam, alohida sana va hokazolar talab qilinadi. Bunday sharoitlar juda ko'p bo'lishi mumkin. Ulardan ba'zilari xodimlarning qarshiligi bilan qabul qilinishi mumkin, shuning uchun barcha bunday holatlarni ma'lumotlarni kiritish tartibiga qo'yiladigan talablar darajasida ro'yxatdan o'tkazish yaxshiroqdir.Avtomatlashtirish ob'ektiga kiritilishi kerak bo'lgan o'zgarishlar.

Avtomatlashtirish ob'ektining ishlashi uchun shart-sharoitlarni yaratish, bunda yaratilgan tizimning texnik shartlarda ko'rsatilgan talablarga muvofiqligi kafolatlanadi.Talab qilinishi mumkin bo'lgan har qanday o'zgarishlar. Masalan, kompaniyada mahalliy tarmoq, tizim ishlamaydigan eskirgan kompyuterlar parki mavjud emas.

Ehtimol, ba'zi kerakli ma'lumotlar qog'ozda ishlangan va endi uni tizimga kiritish kerak. Agar buni qilmasangiz, ba'zi modullar ishlamaydi va hokazo.

Ehtimol, biror narsa soddalashtirilgan, ammo endi batafsilroq e'tiborga olish kerak, shuning uchun kimdir ma'lum qoidalarga muvofiq ma'lumot to'plashi kerak.

Ushbu ro'yxat uzoq bo'lishi mumkin, loyihangizning o'ziga xos holatini ko'rib chiqing.Tizimning ishlashi uchun zarur bo'lgan bo'limlar va xizmatlarni yaratish;

Xodimlarni tayyorlash va o'qitish vaqti va tartibi biz bu haqda avvalroq gapirgan edik. Ehtimol, tizim ilgari mavjud bo'lmagan yangi tuzilma yoki faoliyat turi uchun ishlab chiqilmoqda. Tegishli kadrlar va hatto o'qitilganlar bo'lmasa, tizim qanchalik malakali qurilgan bo'lmasin, ishlamaydi.

8-bo'lim. Hujjatlarga qo'yiladigan talablar

Foydalanuvchi qo'llanmalari qanday taqdim etilishini ko'rib chiqing.

Ehtimol, Buyurtmachi korporativ standartlarni qabul qilgan, ya'ni biz ularga murojaat qilishimiz kerak.

Hujjatlar talablarini e'tiborsiz qoldirish ko'pincha loyihalarda eng kutilmagan oqibatlarga olib keladi. Misol uchun, hamma narsa bajarildi va hamma narsa ishlaydi. Foydalanuvchilar qanday ishlashni ham bilishadi. Hujjatlar haqida umuman kelishuv yoki suhbat bo'lmagan. Va to'satdan, ishni topshirayotganda, loyihada ishtirok etmagan, lekin ishni qabul qilishda ishtirok etgan Buyurtmachining top-menejerlaridan biri sizdan so'raydi: "Foydalanuvchi qo'llanmalari qayerda?" Va bu sizni foydalanuvchi qo'llanmalarining mavjudligi to'g'risida kelishib olishning hojati yo'qligiga ishontira boshlaydi, bu "albatta" go'yoki nazarda tutilgan. Va bu, u sizning ishingizni olishni xohlamaydi. Ko'rsatmalarni kimning hisobidan ishlab chiqasiz? Ko'pgina jamoalar allaqachon bu ilgakka tushib qolgan.

9-bo'lim. Rivojlanish manbalari

GOST bo'yicha tavsiyalar Amalda bu haqda nima qilish kerak
Hujjatlar ro'yxatga olinishi kerak va axborot materiallari(texnik-iqtisodiy asoslash, tugallangan tadqiqot ishlari bo'yicha hisobotlar, mahalliy va xorijiy analog tizimlar bo'yicha axborot materiallari va boshqalar), ular asosida texnik shartlar ishlab chiqilgan va tizimni yaratishda ulardan foydalanish kerak. Rostini aytsam, bu qo'shiq matniga yaqinroq. Ayniqsa, ular iqtisodiy samara va ob'ektiv hisoblash deyarli mumkin bo'lmagan boshqa narsalar haqida gapirganda. Bular. Albatta, bu faqat nazariy jihatdan qog'ozda ko'proq bo'ladi.

Shuning uchun, so'rov hisoboti va asosiy shaxslarning talablariga oddiygina murojaat qilish yaxshiroqdir.

Shunday qilib, biz texnik topshiriqga kiritilishi mumkin bo'lgan barcha bo'limlarni ko'rib chiqdik. Natijaga erishish uchun har qanday hujjat ishlab chiqilishi kerakligi sababli "mumkin" va "kerak" emas. Shuning uchun, agar ma'lum bir bo'lim sizni natijaga yaqinlashtirmasligi aniq bo'lsa, unda sizga kerak emas va unga vaqt sarflashingiz shart emas.

Ammo hech qanday vakolatli texnik shartlar asosiy narsasiz amalga oshirilmaydi: funktsional talablar. Shuni ta'kidlashni istardimki, amalda bunday texnik xususiyatlar yuzaga keladi va qanday qilib! Barcha bo'limlarda suvlarni ajratib turadigan raqamlar mavjud, tasvirlab bering Umumiy talablar umumiy ma'noda, va hujjat juda salmoqli bo'lib chiqadi va unda juda ko'p aqlli so'zlar mavjud va hatto Buyurtmachiga ham yoqishi mumkin (ya'ni, uni ma'qullaydi). Lekin unga ko'ra ishlamasligi mumkin, ya'ni. U kam amaliy foydalanishga ega. Ko'pgina hollarda, bunday hujjatlar texnik topshiriqlar uchun maxsus ko'p pul olish kerak bo'lganda tug'iladi, lekin u tez va tafsilotlarga sho'ng'imasdan amalga oshirilishi kerak. Va, ayniqsa, agar ish uzoqqa bormasligi yoki butunlay boshqa odamlar buni qilishlari ma'lum bo'lsa. Umuman olganda, faqat byudjetni, xususan, davlat byudjetini boshqarish uchun.

Ikkinchi maqolada biz faqat "Tizim talablari" 4-bo'limi haqida gapiramiz va aniqlik, o'ziga xoslik va sinovdan o'tish uchun talablarni shakllantiramiz.

Nima uchun talablar aniq, aniq va sinovdan o'tkazilishi kerak.

Chunki amaliyot shuni ko'rsatadiki, birinchi navbatda, mutaxassislar tomonidan ishlab chiqilgan texnik xususiyatlarning aksariyati talabga ega emas (haqiqatga mos kelmaydi) yoki ularni amalga oshirishi kerak bo'lgan kishi uchun muammoga aylanadi, chunki Xaridor noaniq shartlar va talablarni manipulyatsiya qilishni boshlaydi. Men qanday iboralarga duch kelganligi, bu nimaga olib kelganligi haqida bir nechta misollar keltiraman, keyin esa bunday muammolardan qochish bo'yicha tavsiyalar berishga harakat qilaman.

Talab turi

Noto'g'ri so'z

Texnik spetsifikatsiyalar yaratish uchun manba materialidir axborot tizimi yoki boshqa mahsulot. Shuning uchun texnik spetsifikatsiya (TK deb qisqartirilgan) birinchi navbatda asosiyni o'z ichiga olishi kerak texnik talablar mahsulotga va nima degan savolga javob bering bu tizim qilish kerak, qanday va qanday sharoitda ishlash kerak.

Qoida tariqasida, texnik shartlarni tuzish bosqichidan oldin ob'ektni yaratish bilan yakunlanadigan ob'ektni o'rganish amalga oshiriladi. analitik hisobot. Bu texnik topshiriq hujjatining asosini tashkil etuvchi analitik hisobot (yoki analitik eslatma).

Hisobotda mijozning talablari ko'rsatilishi mumkin bo'lsa umumiy ko'rinish va UML diagrammalari bilan tasvirlangan texnik xususiyatlar tizim uchun barcha funktsional va foydalanuvchi talablarini batafsil tavsiflashi kerak. Texnik tavsiflar qanchalik batafsil bo'lsa, shuncha kamroq munozarali vaziyatlar qabul qilish testi paytida mijoz va ishlab chiquvchi o'rtasida paydo bo'ladi.

Shunday qilib, texnik spetsifikatsiya ishlab chiquvchiga ham, mijozga ham yakuniy mahsulotni taqdim etish va keyinchalik talablarga muvofiqligini tekshirish imkonini beruvchi hujjatdir.

Texnik spetsifikatsiyalarni yozish uchun qo'llanma standartlari GOST 34.602.89 "Avtomatlashtirilgan tizimni yaratish uchun texnik shartlar" va GOST 19.201-78 "Texnik shartlar. Tarkib va ​​dizaynga qo'yiladigan talablar." Birinchi standart avtomatlashtirilgan tizimlarni ishlab chiquvchilar uchun, ikkinchisi dasturiy ta'minot uchun mo'ljallangan (biz ushbu seriyalar orasidagi farqni "GOST nima" maqolasida muhokama qildik).

Shunday qilib, biz quyida GOSTlarga muvofiq texnik xususiyatlar bo'lishi kerak bo'lgan bo'limlarning ro'yxati va tavsifini taqdim etamiz.

GOST 19.201-78 Texnik spetsifikatsiyalar. Tarkib va ​​dizaynga qo'yiladigan talablar

GOST 34.602.89 Avtomatlashtirilgan tizimni yaratish uchun texnik shartlar

1.Kirish

1. Umumiy ma'lumot

2. Rivojlanish sabablari

3. Rivojlanish maqsadi

2. Tizimni yaratish maqsadi va maqsadlari

3. Avtomatlashtirish obyektining xarakteristikasi

4. Dastur yoki dasturiy mahsulotga qo'yiladigan talablar

4. Tizim talablari

4.1. Funktsional talablar

4.2. Tizim tomonidan bajariladigan funktsiyalarga (vazifalarga) qo'yiladigan talablar

4.1. Butun tizimga qo'yiladigan talablar

4.1.1. Tizimning tuzilishi va ishlashiga qo'yiladigan talablar

4.1.3. Belgilangan manzil ko'rsatkichlari

4.2. Ishonchlilik talablari

4.1.4. Ishonchlilik talablari

4. 1.5. Xavfsizlik talablari

4. 1.6. Ergonomika va texnik estetikaga qo'yiladigan talablar

4.3. foydalanish shartlari

4.1.2. Tizim xodimlarining soni va malakasiga va ularning ishlash tartibiga qo'yiladigan talablar

4. 1.9. Axborotni ruxsatsiz kirishdan himoya qilish talablari

4. 1.10. Baxtsiz hodisalarda ma'lumotlarning xavfsizligiga qo'yiladigan talablar

4. 1.11. Tashqi ta'sirlardan himoya qilish uchun talablar

4. 1.12. Patentning tozaligiga qo'yiladigan talablar

4. 1.13. Standartlashtirish va unifikatsiya qilish talablari

4.4. Tarkibi va parametrlariga qo'yiladigan talablar texnik vositalar

4. 1.8. Tizim komponentlarini ishlatish, texnik xizmat ko'rsatish, ta'mirlash va saqlashga qo'yiladigan talablar

4.5. Axborot va dasturiy ta'minotning muvofiqligiga qo'yiladigan talablar

4.6. Belgilash va qadoqlash talablari

4.7. Tashish va saqlash talablari

4. 1.7. Mobil tizimlar uchun transport imkoniyati talablari

4.8. Maxsus talablar

4. 1.14. Qo'shimcha talablar

4.3. Garov turlariga qo'yiladigan talablar

5. Dastur hujjatlariga qo'yiladigan talablar

8. Hujjatlarga qo'yiladigan talablar

6. Texnik-iqtisodiy ko'rsatkichlar

7. Rivojlanish bosqichlari va bosqichlari

5. Tizimni yaratish bo'yicha ishlarning tarkibi va mazmuni

8. Nazorat va qabul qilish tartibi

6. Tizimni nazorat qilish va qabul qilish tartibi

7. Tizimni ishga tushirish uchun avtomatlashtirish ob'ektini tayyorlash bo'yicha ishlarning tarkibi va mazmuniga qo'yiladigan talablar

9.Rivojlanish manbalari

Shunday qilib, Texnik spetsifikatsiyalar hujjati, aslida, avtomatlashtirish ob'ektini analitik tadqiq qilish bosqichida aniqlangan loyihalashtirilgan mahsulotga qo'yiladigan barcha talablarni aks ettirishi kerak.

Yuqoridagi jadvalga asoslanib, biz texnik xususiyatlarning asosiy bo'limlarini ajratib ko'rsatishimiz mumkin:

  • Tizim (dastur) haqida umumiy ma'lumot;
  • Tizimning (dasturning) maqsadi, maqsad va vazifalari;
  • Tizim talablari (funktsional talablar, foydalanuvchi talablari, butun tizimga qo'yiladigan talablar va boshqalar);
  • Xavfsizlik turlariga qo'yiladigan talablar;
  • Hujjatlarga qo'yiladigan talablar;
  • Rivojlanish bosqichlari va bosqichlari;
  • Tizimni (dasturni) nazorat qilish va qabul qilish tartibi.

Umumiy ma'lumot
Texnik spetsifikatsiya hujjatining ushbu bo'limi tizimning to'liq nomini va hujjatlarni ishlab chiqishda foydalaniladigan barcha qisqartmalarni o'z ichiga olishi kerak.

Misol:

"IN ushbu hujjat Yaratilayotgan axborot tizimi “Ta’lim resurslariga kirishning yagona oynasi” deb nomlanadi, SW deb qisqartiriladi.
Ta’lim resurslariga kirishning yagona oyna tizimi ushbu hujjatda keyinchalik “Yagona oyna” yoki tizim deb nomlanishi mumkin”.

Shuningdek, bu erda siz ishlab chiqishda ishtirok etadigan tashkilotlar (mijoz va pudratchi) tafsilotlarini ko'rsatadigan kichik bo'limlarni kiritishingiz kerak.

Texnik spetsifikatsiyalar hujjatining "Ishlab chiqish asoslari" kichik bo'limida ushbu ish olib boriladigan asosiy hujjatlar ro'yxati keltirilgan. Masalan, u yoki bu davlat hukumati tomonidan topshirilgan tizim uchun Davlat organi, qonunlar, qarorlar va hukumat qarorlari ko'rsatilishi kerak.

Texnik spetsifikatsiyalar hujjatining ajralmas qismi, shuningdek, atamalar va qisqartmalar ro'yxati bo'lishi kerak. "Muddati" va "To'liq shakl" ikkita ustunli jadval shaklida atamalar va qisqartmalarni taqdim etish yaxshiroqdir.

Atamalar va qisqartmalar alifbo tartibida joylashtirilgan. Avvalo, rus tilidagi atamalar va qisqartmalarni, so'ngra ingliz tilidagilarni shifrlash odatiy holdir.

Tizimni yaratishning maqsadi va maqsadlari

Texnik spetsifikatsiya hujjatining ushbu bo'limi tizimni yaratish maqsadi va maqsadlarini o'z ichiga olishi kerak.

Misol:

"Ta'lim resurslariga kirishning yagona oynasi" axborot tizimi foydalanuvchilarga Rossiya Federatsiyasining ta'lim tizimi va ta'lim muassasalari funktsiyasini bajaradigan tashkilotlar to'g'risida to'liq, o'z vaqtida va qulay ma'lumotlarni taqdim etish uchun mo'ljallangan.

Tizimning asosiy maqsadi yagona axborot muhitini yaratish va ta’lim muassasalarining biznes jarayonlarini avtomatlashtirishdan iborat Rossiya Federatsiyasi.

“Yagona darcha” axborot tizimini yaratish quyidagilarni ta’minlashi kerak:

  • foydalanuvchilarni keng ko'lamli axborot resurslari bilan ta'minlash;
  • darajaga ko'taring axborot xavfsizligi;
  • bir qator biznes jarayonlarini optimallashtirish orqali ta’lim muassasalari va bo‘limlari faoliyati samaradorligini oshirish;
  • bo'lim ichidagi axborot tizimlari va xizmatlar o'rtasidagi o'zaro hamkorlik jarayoni samaradorligini oshirish.

Tizimning yaratilishi bo‘lim faoliyati samaradorligini oshirish natijasida operatsion xarajatlarni kamaytiradi”.

Tizim talablari

Texnik spetsifikatsiya hujjatining ushbu bo'limi tizimning asosiy funktsional talablarini tavsiflash uchun mo'ljallangan. Bu texnik spetsifikatsiyaning eng muhim qismidir, chunki u tizimni ishga tushirish jarayonida Buyurtmachi bilan kelishmovchiliklarda sizning asosiy argumentingiz bo'ladi. Shuning uchun uning yozilishiga juda ehtiyotkorlik bilan yondashish kerak.

Texnik topshiriq hujjatida avtomatlashtirish ob'ektini tahlil qilish bosqichida aniqlangan barcha talablar bo'lishi kerak. Funktsional talablarning tavsifi orqali oshkor etilishi kerak bo'lgan asosiy biznes jarayonlarini ajratib ko'rsatish yaxshidir.

Misol:

"4.1 Biznes jarayoni" Rossiya Federatsiyasining ta'lim muassasalari haqida ma'lumot berish

Ushbu biznes jarayonining quyidagi ishtirokchilari aniqlanadi:

Moderator - taqdim etilgan ma'lumotlarning to'g'riligi uchun javobgar bo'lgan bo'lim xodimi, tizimning texnik xizmat ko'rsatish xodimlarining bir qismi.

Foydalanuvchi Rossiya Federatsiyasi ta'lim muassasalarining ishi haqida ma'lumot olishi kerak bo'lgan fuqarodir.

4.1.1 Ro'yxatdan o'tish ta'lim muassasasi tizimda

Rossiya Federatsiyasining ta'lim muassasasini ro'yxatdan o'tkazish muassasaning mas'ul xodimi tomonidan amalga oshiriladi ("Hukumat qarori ...").

Ta'lim muassasasini ro'yxatdan o'tkazish jarayoni quyidagi bosqichlarni o'z ichiga oladi:

  • Muallif tashkilot haqida yozuv yaratadi;
  • Muallif tashkilot ma'lumotlarini kiritadi;
  • Tizim ma'lum bir tashkilot uchun litsenziyani tekshiradi
    • Agar ma'lumotlar bazasida litsenziya mavjud bo'lsa, tizim Muallifga ro'yxatdan o'tish muvaffaqiyatli o'tganligi haqida xabar yuboradi;
    • Agar maʼlumotlar bazasida litsenziya topilmasa, tizim ushbu tashkilot uchun litsenziya yoʻqligi toʻgʻrisida Muallifga xabar yuboradi”.

Vaqt bo'lsa, ushbu bo'limda keltirilgan ma'lumotlar Texnik topshiriq hujjatiga ilovada to'liqroq ochib berilishi kerak. Texnik spetsifikatsiyalar ilovasida siz ekran shaklini taqdim etishingiz va unda mavjud bo'lgan barcha hodisalarni (yaratish, ko'rish, tahrirlash, o'chirish va h.k.) tasvirlab berishingiz mumkin.

Butun tizimga qo'yiladigan talablar uning arxitekturasini barcha quyi tizimlarning tavsifi bilan oshkor qilishni o'z ichiga oladi. Texnik topshiriqning ushbu qismi tizimni boshqa mahsulotlar (agar mavjud bo'lsa) bilan integratsiya qilish talablarini tavsiflashi kerak. Bundan tashqari, texnik topshiriq quyidagilarni o'z ichiga olishi kerak:

  • tizimning ishlash rejimlariga qo'yiladigan talablar
  • maqsad ko'rsatkichlari
  • ishonchlilik talablari
  • xavfsizlik talablari
  • xodimlarning soni va malakasiga va ularning ish tartibiga qo'yiladigan talablar
  • axborotni himoya qilish talablari
  • baxtsiz hodisalarda ma'lumotlarning xavfsizligiga qo'yiladigan talablar
  • patentni rasmiylashtirish talablari
  • standartlashtirish va unifikatsiya qilish talablari
  • va hokazo.

Garov turlariga qo'yiladigan talablar

Texnik spetsifikatsiya hujjatining ushbu bo'limi matematik, axborot, lingvistik, dasturiy ta'minot, texnik va boshqa qo'llab-quvvatlash turlariga (agar mavjud bo'lsa) talablarni o'z ichiga olishi kerak.

Hujjatlarga qo'yiladigan talablar

Texnik spetsifikatsiyaning "Hujjatlarga qo'yiladigan talablar" bo'limi mijozga taqdim etilishi kerak bo'lgan dizayn va ekspluatatsion hujjatlar ro'yxatini o'z ichiga oladi.

Texnik spetsifikatsiyaning ushbu bo'limi funktsional talablarning tavsifi kabi muhimdir, shuning uchun siz "Buyurtmachi GOST 34 ga muvofiq barcha hujjatlar bilan ta'minlanishi kerak" iborasi bilan cheklanmasligingiz kerak. Bu shuni anglatadiki, siz barcha hujjatlar to'plamini, shu jumladan "Forma", "Pasport" va boshqalarni taqdim etishingiz kerak. GOST 34.201-89 da ko'rsatilgan ro'yxatdagi hujjatlarning aksariyati sizga ham, mijozga ham kerak emas, shuning uchun Texnik spetsifikatsiyalar hujjatini ishlab chiqish bosqichida ro'yxatni darhol kelishib olish yaxshiroqdir.

Minimal hujjatlar to'plami odatda quyidagilarni o'z ichiga oladi:

  • Texnik vazifa;
  • Dastlabki (texnik) loyihalash bayonnomasi;
  • Tushuntirish eslatmasi Texnik loyihaga;
  • Axborot bazasini tashkil etish tavsifi;
  • Foydalanuvchi qo'llanmasi;
  • Administrator uchun qo'llanma;
  • Test dasturi va metodologiyasi;
  • Qabul qilish sinovi hisoboti;
  • Bajarilgan ishlar haqida AKT

Texnik spetsifikatsiyalarda hujjatlar ro'yxatini jadval shaklida taqdim etish yaxshiroqdir, unda hujjatning nomi va uning asosida ishlab chiqilishi kerak bo'lgan standart ko'rsatilgan.

Rivojlanish bosqichlari va bosqichlari

Texnik topshiriq hujjatining ushbu bo'limi bajarilishi kerak bo'lgan ishning barcha bosqichlari haqida ma'lumot berishi kerak.

Bosqich tavsifi nomi, vaqti, ish tavsifi va yakuniy natijani o'z ichiga olishi kerak.

Tizimni nazorat qilish va qabul qilish tartibi

Texnik spetsifikatsiyalar hujjatining ushbu bo'limida qabul qilish sinovlari o'tkazilishi kerak bo'lgan hujjatni ko'rsatish kerak.

Agar kerak bo'lsa, texnik shartlar boshqa bo'limlar bilan to'ldirilishi yoki nomaqbul narsalarni olib tashlash orqali qisqartirilishi mumkin.

Texnik spetsifikatsiyalar tuzilishini o'zgartirganda, ziddiyatli vaziyatlarni oldini olish uchun hujjatni ishlab chiqishdan oldin mijoz bilan kelishilgan bo'lishi kerak.

Ushbu matn faqat doimiy havola mavjudligi uchun yaratilgan bo'lib, uni muallifning o'zi va barchangiz kelajakdagi mijozlaringiz, hamkasblaringiz, qarindoshlaringiz va tanishlaringizga savolga standart javob shaklida xavfsiz yuborishingiz mumkin: "Menga sizning texnik xususiyatlaringiz kerakmi va umuman nima?" Bu?"

Ular aytganidek - "ming so'z o'rniga", chunki har safar Skype-da ushbu mavzu bo'yicha 4-5 soat davomida xushxabar aytish zerikarli bo'lib bormoqda va "Texnik spetsifikatsiyalar" ta'rifiga ochiq-oydin bema'nilik kiritish global tendentsiyasi kuchaymoqda. yillar davomida.

Muammo

Gap shundaki, ma'lum bir format, shuningdek, atamaning aniq va tushunarli ta'rifi mavjud bo'lganda, uni o'zingizning qisqacha ma'lumotlaringiz, prototiplaringiz, tezda ixtiro qilingan anketalar, tavsiflar va oddiygina kiruvchi ilovalar bilan almashtirishlar ko'rinadi. hech bo'lmaganda professional bo'lmagan. Shuning uchun biz kontseptsiyamizning ilmiy ta'rifidan boshlaymiz:

Texnik spetsifikatsiyalar - original dizayn hujjati texnik ob'ekt(mahsulotlar). Texnik spetsifikatsiya ishlab chiqilayotgan ob'ektning asosiy maqsadini, uning texnik tavsiflarini, sifat ko'rsatkichlarini va texnik-iqtisodiy talablarini, hujjatlarni yaratishning zarur bosqichlarini (loyihalash, texnologik, dasturiy ta'minot va boshqalar) bajarish bo'yicha ko'rsatmalarni, shuningdek uning tarkibini belgilaydi. maxsus talablar sifatida. Texnik topshiriqlar huquqiy hujjat- buyurtmachi va pudratchi o'rtasidagi shartnomaga ariza qanday kiritilganligi dizayn ishi va uning asosi hisoblanadi: ish tartibi va shartlarini, shu jumladan maqsad, vazifalar, tamoyillar, kutilayotgan natijalar va muddatlarni belgilaydi. Ya'ni, ob'ektiv mezonlar bo'lishi kerak, unga ko'ra ma'lum bir ish bajarilgan yoki bajarilmaganligini aniqlash mumkin. Texnik spetsifikatsiyalar matnidagi barcha o'zgartirishlar, qo'shimchalar va tushuntirishlar buyurtmachi bilan kelishilgan va u tomonidan tasdiqlangan bo'lishi kerak. Bu, shuningdek, zarur, chunki agar dizayn muammosini hal qilish jarayonida dastlabki ma'lumotlardagi noaniqliklar yoki xatolar aniqlansa, ishlab chiqishda ishtirok etgan har bir tomonning aybdorlik darajasini aniqlash va u bilan bog'liq yo'qotishlarni taqsimlash zarur bo'ladi. bu bilan. Texnik topshiriq - bu axborot texnologiyalari sohasidagi atama sifatida, dasturiy mahsulot, axborot tizimi, veb-sayt, portal yoki boshqa AT xizmatlarini ishlab chiqish, joriy etish yoki integratsiya qilish bo'yicha ijrochilarga vazifalarni belgilash uchun zarur bo'lgan to'liq ma'lumotlarni o'z ichiga olgan yuridik ahamiyatga ega hujjat. .
Tushunarli tilga tarjima

1) Texnik topshiriq - u vazifani belgilaydi. Bu prototip, eskiz, test, dizayn loyihasidan oldin kelishi kerak degan ma'noni anglatadi, chunki har qanday zehn xaritasi, ma'lumotlar oqimi diagrammasi, arxitektura allaqachon ma'lum bir vazifaning bajarilishi, bu savolga javob. Va savolning o'zi hali barcha tomonlar tomonidan berilmagan, shakllantirilgan va imzolanmagan bo'lsa, har qanday javob apriori noto'g'ri bo'ladi, shunday emasmi? Shunday qilib, har qanday loyiha bo'yicha har qanday ishning boshlanishi uni hal qilishning o'nlab variantlari eskizlarini izlash emas, balki muammoni shakllantirishdir.

2) Aslida, birinchi nuqtadan yangisi mantiqan kelib chiqadi - TK matnining o'zi "Maqsadlar va vazifalar" bobidan boshlanishi kerak, unda dunyodagi entropiyani oshirishga qaratilgan ushbu so'nggi urinish qanday biznes maqsadlari ko'zda tutilayotganini aniq ifodalaydi. . Hech qanday muammoni hal qilmaydigan, hech narsaga erishmaydigan va "zerikkanlikdan" bajariladigan maqsadsiz vazifa rasmiy ravishda Texnik vazifa hisoblanmaydi va bundan buyon "oddiy qog'oz" maqomida.

3) Tavsiya etilgan dizayn kontseptsiyasi yoki interaktiv prototip yoki hatto foydalanishga tayyor veb-sayt yuqoridagi biznes muammosini hal qiladimi yoki yo'qligini qanday tushunasiz? Hech narsa qilish kerak emas, biz yana ta'rifga qaytishimiz kerak: "aniqlaydi ... kutilgan natijalar va muddatlar. Ya’ni, u yoki bu ish bajarilgan yoki bajarilmaganligini aniqlash mumkin bo‘lgan ob’ektiv mezonlar bo‘lishi kerak”. That is, technical specifications cannot exist without clear measurable indicators in rubles, seconds, ton-kilometers or degrees Celsius. Balki qisqacha ma'lumot, prototip yoki boshqa bema'ni qog'oz bo'lishi mumkin, ammo Texnik topshiriq emas.

Shu yerdan xulosa qilamizki, ushbu TORda xuddi shu ko'rsatkichlar olingan, o'lchangan va tomonlar qo'l silkitganda yoki loyihani qayta ishlashga yuborilganda "Qabul qilish va baholash tartibi" bo'limi bo'lishi kerak.

4) Texnik topshiriq mijozning umumiy biznes-rejasiga, biznesni rivojlantirish strategiyasiga va bozor segmenti tahliliga mos kelishi shart. Bularning barchasi sizga to'g'ri maqsadlarni qo'yish, aniq ko'rsatkichlarni olish imkonini beradi, keyinchalik ular tayyor ma'lumot mahsulotini adekvat qabul qilish uchun ishlatiladi. Buyurtmachidan biznes-rejaning yo'qligi avtomatik ravishda Texnik spetsifikatsiyalarning professional tarzda amalga oshirilishini kafolatlaydi.

Autsorsing studiyasi biznes maqsadlari va biznesning o'lchanadigan ko'rsatkichlarini egasidan yaxshiroq biladimi? Shubhasiz, yo'q, ya'ni to'g'ri texnik shartlar Pudratchining yollangan xodimlari tomonidan emas, balki Buyurtmachining vakillari tomonidan yozilishi kerak. Ijrochi o'z oldiga vazifa qo'yib, keyin uni baholash usullarini o'ylab topsa va oxirida bajarilgan ish uchun yakuniy baho qo'ysa, bu bema'nilik. Ideal holda, bunday "havaskorlik faoliyati" mavjud bo'lmasligi kerak, garchi amalda bu hamma joyda sodir bo'ladi, buning natijasida Texnik topshiriq hech qanday ta'sir ko'rsatmaydi. sizga kerak bo'lgan yordam loyiha, odatda, xayoliy hujjatdir. Bunday qilish kerak emas.

5) Tayyor texnik spetsifikatsiyaga har bir tuzatish pul sarflashi kerak. Tomonlardan biri o'z fikrini o'zgartirgani, etarlicha uxlamagani, to'satdan pulni tejashga qaror qilgani va hokazolar uchun siz "loyihangizning Konstitutsiyasini" erkin va cheksiz tahrirlay olmaysiz. Texnik spetsifikatsiyalardagi har bir o'zgarish narxi ham tegishli bobda oldindan aniq ko'rsatilishi kerak.

Aytgancha, nazariy jihatdan, xuddi shu tarzda, dizayndagi har bir tahrir yoki sahifalar yoki funktsiyalar ro'yxatiga kiritilgan o'zgartirishlar ushbu o'zgartirishni amalga oshirishdan oldin oldindan to'lanadigan aniq narxga ega bo'lishi kerak. Shaxsan men tasdiqlangan texnik spetsifikatsiyaning har qanday tahriri butun loyiha byudjetining 30 foiziga baholanishini taklif qilaman, ammo siz boshqacha qilishingiz mumkin.

Ta'kidlash joizki, texnik topshiriqda rivojlanish uchun vaqt va umumiy byudjet, shuningdek, barcha mavjud resurslar va cheklovlar ro'yxati oldindan ko'rsatilishi kerakmi? - Yo'q, bu juda aniq bo'ladi.

Xo'sh: Biz nima qilyapmiz? Sabab? Biz nima qilganimizni qanday tushunamiz? Har bir pivot qancha turadi? - qog'ozga yozilgan barcha savollarga javoblar hatto eng muvaffaqiyatsiz loyihani ham olib tashlaydigan "kumush o'q" dir.

Nazorat savollari
Va bu erda men mijozlarning eng ko'p beriladigan savollariga javoblarni sanab o'taman:

1) Xo'sh, texnik xususiyatlarni yozish uchun rasmiy GOST ham bormi? - Ha, hatto bir nechta.

2) Nima, Texnik spetsifikatsiyada kerakli sahifalar tavsifi, tugmalar soni, foydalanilgan kutubxonalar, ko'rsatmalar va boshqalar mavjud emasmi? - TORning o'zida emas, balki Ilovalarda bularning barchasini, albatta, yuqorida tavsiflangan maqsadlar, cheklovlar va erishilgan natijani baholash usullari bilan moslashtirishingiz mumkin. Hech bo'lmaganda kelajakdagi barcha tarkibni, hatto odatiy belgilarning tavsifini ham joylashtiring - lekin vazifaning aniq bayoni o'rniga emas, balki undan keyin.

3) Balki menga bunday kerak emasdir? - Ehtimol, bugungi kunda minglab saytlar umuman texnik shartlarsiz yaratilgandir, xuddi dunyoda minglab odamlar tug'ilishdan ko'r bo'lib yaxshi yashayotgani kabi. Ammo agar siz qaerga ketayotganingizni ko'rishni, ongli ravishda qaror qabul qilishni va olingan natijalarni mustaqil ravishda baholashni istasangiz, texnik xususiyatlarsiz qilolmaysiz.

4) Shunday qilib, siz va Vikipediya texnik spetsifikatsiya mijoz tomonidan yaratilganligini yozasiz. Lekin men bilmayman / vaqtim yo'q / men buni o'zim qilishni xohlamayman. Qanday bo'lish kerak? - Sizning biznesingiz, uning vazifalari, maqsadli auditoriyasi va ehtiyojlari bilan to'liq tanish bo'lgan va shu bilan birga veb-ishlab chiqishning barcha bosqichlari haqida puxta ma'lumotga ega bo'lgan uchinchi shaxsga texnik xususiyatlarni ishlab chiqishni autsorsing qiling. Ushbu uchinchi tomon o'ziga xos "veb-notarius" ga aylanadi, ya'ni pudratchi sizga kerak bo'lgan ko'rsatkichlarni kam baholamasligi yoki belgilangan muddatlarni kechiktirmasligi va mijoz erishilishi mumkin bo'lgan ko'rsatkichlarni o'rnatishi va yakuniy qabul qilishda kafolat bermasligiga kafolat beradi. yaratilgan mahsulotni sub'ektiv baholang, oldindan qayd etilganlarni parvoz talablariga o'zgartiring.

5) Va agar texnik tavsif qonuniy hujjat bo'lsa, men autsorserni sudga berishim mumkin, unga pul to'lamayman, uni o'ninchi marta hamma narsani qayta bajarishga majburlashim mumkinmi? - Hujjat to'g'ri tuzilgan bo'lsa, maqsadlar va ularga erishishni baholash metodikasi ko'rsatilgan; agar hujjat tomonlar tomonidan imzolangan bo'lsa va Shartnomada ko'rsatilgan bo'lsa (Texnik topshiriqning o'zi shartnoma emas) - unda, albatta, mumkin. Ammo odatiy qisqacha, prototiplar, badiiy-ijodiy tartib, FLda xavfsiz kelishuv - endi yo'q.

6) Ular menga ish qandaydir Scrum yoki Agile yordamida amalga oshirilishini aytishadi; demak, men endi eski texnik xususiyatga muhtoj emasman. Bu shunday? - O'zingiz uchun hukm qiling: ular sizni tushunarsiz so'z deb atashadi, ular aniq bir narsani niqoblaydilar va endi ular notanish atama asosida maqsadlar va ko'rsatkichlar bilan to'ldirilgan qonuniy vakolatli hujjatdan voz kechishni taklif qilishadi. Agile o'zi "yil oxirigacha kamida 10 000 tashrifga erishish" yoki "bir oy ichida saytdan 25 dan ortiq buyurtmalarga erishish" kabi maqsadlarni qo'ya olmaydi, bu shunchaki uchrashuvlar o'tkazish va yangi tashkilot ehtiyotsiz xodimlar. Bir necha bor o'ylab ko'ring: "Ular sizning ko'zingizga chang solmaydimi?" Aslida, professional texnik xususiyatlar har qanday yangi Scrumga zarar etkaza olmaydi, lekin u albatta yordam beradi.

Har qanday loyihani ishlab chiqishda. Ushbu hujjat qanday tayyorlanadi? Bu maqolada muhokama qilinadi.

Texnik spetsifikatsiya - bu nima?

Loyihani ishlab chiqishni boshlashdan oldin, avvalo rejani tuzish kerak. Qurilish, tadbirkorlik, uy-joy ishi - mutlaqo har qanday mehnat sohasi tegishli reja ishlab chiqishni talab qiladi. Bunday holda, u yoki bu ish qanchalik murakkab yoki jiddiy ekanligi muhim emas. Texnik spetsifikatsiyalarni ishlab chiqish va, aslida, oddiy harakatlar rejasi bu erda asosiy bosqichdir.

Texnik topshiriq ish jarayonining har ikki tomoniga kerak: pudratchi va buyurtmachi. Ko'pincha bu ikki shaxs o'rtasida janjallar, nizolar va tushunmovchiliklar paydo bo'ladi. Yaxshi ishlab chiqilgan harakatlar rejasi har bir tomonning barcha majburiyatlarini qat'iy tartibga solishga yordam beradi.

Nima uchun mijozga texnik shartlar kerak?

Yuqorida aytib o'tilganidek, texnik xususiyatlarni ishlab chiqish har ikki tomon uchun ham foydali bo'lgan zaruriy jarayondir mehnat shartnomasi. Biroq, endi taqdim etilgan hujjat to'g'ridan-to'g'ri mijozga nima uchun kerakligi haqida gapirishga arziydi.

Shuni ta'kidlash kerakki, texnik xususiyatlar faqat mijoz tomonidan ishlab chiqilgan. Bu o'ziga xos harakatlar rejasi, xizmatlar ko'rsatish bo'yicha shartnoma. Ushbu hujjat yordamida ijrochilar o'zlarining mehnat funktsiyalarini, shuningdek, ulardan aniq nima talab qilinishini aniq belgilashlari mumkin. Ko'rib chiqilayotgan hujjat har doim eng yuqori sifat va ehtiyotkorlik bilan ishlab chiqilishi kerak. Shunday qilib, mijoz barcha asosiy tezislar va fikrlarni hisobga olishi, shuningdek, qarama-qarshi masalalardan qochishi kerak. Agar hujjat to'g'ri tuzilgan bo'lsa, mijoz har doim norozi pudratchini shartnomaning muayyan bandiga ko'rsatishi mumkin.

Nima uchun pudratchiga texnik shartlar kerak?

Pudratchi har qanday ishni boshlashdan oldin texnik shartlarning namunalarini oladi. Ishchi hujjatdagi barcha fikrlarni diqqat bilan o'qib chiqishi kerak. Ushbu qadam mijoz tomonidan manipulyatsiyadan qochishga yordam beradi. Shunday qilib, ko'plab boshliqlar xodimlardan texnik topshiriqda muhokama qilinmagan narsalarni talab qilishlari mumkin.

Pudratchi barcha kerakli nuqtalarni va to'lov miqdorini aniqlab berishi kerak. Shunday qilib, siz bunga ishonch hosil qilishingiz kerak naqd pul to'lovlari faqat hujjatda ko'rsatilgan fikrlarga taalluqlidir. Aks holda, e'tiborsiz ijrochilar bepul ishlashi mumkin.

Shunday qilib, ijrochi imkon qadar tez-tez texnik xususiyatlarning namunalariga e'tibor qaratishi kerak. Bu unga keraksiz muammolar va tushunmovchiliklardan qochishga yordam beradi.

Hujjatni tuzishni boshlash

Hujjatni to'ldirishni qaerdan boshlashim kerak? Ish uchun texnik topshiriq har doim umumiy qoidalar va maqsadlardan boshlanishi kerak. Nima kiritilgan Umumiy holat? Birinchidan, kichik lug'at. Albatta, unday emas majburiy shart. Biroq, agar hujjat tor yo'naltirilgan bo'lsa va shuning uchun ma'lum terminologiya bilan to'ldirilgan bo'lsa, unda kichik lug'atni biriktirishga arziydi. Har holda, bu buyurtmachi va pudratchi o'rtasidagi o'zaro tushunish yo'lidagi yana bir qadam bo'ladi. Ikkinchidan, umumiy qoidalar shartnoma taraflari to'g'risidagi ma'lumotlarni o'z ichiga olishi kerak.

Texnik topshiriqning maqsadlari qanday? Ehtimol, taxmin qilish qiyin emas. Shunday qilib, qanday loyiha ishlab chiqilayotgani, nima uchun kerakligi va yakuniy natijaga qanday erishish mumkinligi haqida qisqacha ma'lumot berish kerak. Barcha vazifalar va maqsadlar imkon qadar batafsil va aniq tasvirlangan bo'lishi kerak. Ushbu yondashuv shartnoma taraflari o'rtasida o'zaro tushunishni o'rnatishga yordam beradi.

Talablar va muddatlar

IN majburiy ishni bajarish uchun har qanday texnik shartlar ma'lum talablarni o'z ichiga olishi kerak, shuningdek, aniq muddatlari. Vaqt bilan hamma narsa nisbatan aniq. Shuni ta'kidlash kerakki, biroz zahiraga vaqt ajratish yaxshiroqdir. Bundan tashqari, buyurtmani bajarish tezligi sifatga ta'sir qilmasligi kerak. Agar pudratchi belgilangan muddatlarni buzgan bo'lsa, shartnomada ushbu holat uchun muayyan sanktsiyalar bo'lishi kerak.

Talablar haqida nima deya olasiz? Xaridor barcha talablar ikkita asosiy turga bo'linganligini yodda tutishi kerak: maxsus va funktsional. Funktsional talablar ma'lum darajada vizual va majoziydir. Bular mijoz ko'rishni xohlagan ma'lum tasvirlar, elementlar, eskizlar. Maxsus talablar qat'iy tartibga solinadi, aniq vazifalar va bajarish usullarini ko'rsatadi. Tabiiyki, maxsus bo'lganlar sezilarli darajada ustun bo'lishi kerak. IN aks holda ijrochi undan nimani xohlashlarini to'liq tushunmasligi mumkin.

Mas'uliyat va hisobot berish

Mutlaqo har qanday namunaviy texnik xususiyatlar biroz batafsilroq bo'lishi kerak bo'lgan yana ikkita muhim element haqida gapirishga arziydi. Biz tomonlarning javobgarligi va javobgarlik haqida gapiramiz. Ushbu elementlarning har biri nimani anglatadi?

Hisobotni bosqichma-bosqich yaratish tavsiya etiladi, ayniqsa texnik topshiriqlar katta bo'lsa. Ishning ma'lum bir bosqichi tugallangandan so'ng, hisobot taqdim etilishi mumkin (talab qilinadi). Bundan tashqari, bunday tizim ijrochini yaxshi holatda saqlashga imkon beradi. Aks holda, u oxirgi daqiqada hamma narsani qila oladi va shuning uchun juda sifatsiz.

Tomonlarning javobgarligi haqida nima deyish mumkin? Darhol shuni ta'kidlash kerakki, bunday band majburiy emas. Biroq, ko'plab mijozlar hali ham turli xil qonunbuzarliklar uchun jarimalar, jarimalar va sanktsiyalarning asosiy turlarini tartibga solishni zarur deb bilishadi. Xarid qilish, tashish va hokazolar uchun texnik shartlar kabi hujjatlarda javobgarlikning asosiy elementlarini ko'rsatish tavsiya etiladi.

Texnik shartlarni ishlab chiqish

Har qanday texnik topshiriq (ta'minot, qurilish, tashish va boshqalar uchun) juda malakali va samarali tarzda tuzilishi kerak. Bu, birinchi navbatda, kelajakda bo'lmasligi uchun kerak sud jarayonlari, tomonlar o'rtasidagi tushunmovchiliklar tufayli nizolar va nizolar. Va ikkinchidan, oddiy qulaylik uchun. Har bir mijoz texnik shartlarni to'g'ri tuzishga qodir emas. Ko'pincha bu ish uchun advokatlar yollanadi, garchi buni qilishning ma'nosi yo'q.

Siz bir nechta oddiy qoidalarni eslab qolishingiz kerak:

  • shartnoma batafsil va batafsil bo'lishi kerak (ammo bo'rttirib ko'rsatishning hojati yo'q; kamida bitta pudratchi talablar bo'yicha ko'p jildli sharhlarni o'qishni xohlashi dargumon);
  • shartnoma tushunarli, chalkashliklarsiz va keraksiz ma'lumotlarsiz bo'lishi kerak;
  • vazifa qandaydir dogma bo'lmasligi kerak; Shuni esda tutish kerakki, bu qat'iy tartibga solingan bo'lsa ham, bu faqat ko'rsatmadir - bu texnik xususiyatlar uchun texnik xizmat yoki daraxt ekish.

Yuqorida keltirilgan barcha maslahatlar haqida gapirish mumkin bo'lgan narsalarning faqat kichik bir qismi. Biroq, siz hali ham mijozlarga bir nechta ko'rsatmalar berishingiz mumkin. Shunday qilib, texnik topshiriq (texnik xizmat ko'rsatish yoki qurilish uchun) shablonga muvofiq qurilishi mumkin. Bu shablonni biror joydan olish shart emas; Shunday qilib, agar xizmatlarni ko'rsatish uchun shartnoma yozish juda keng tarqalgan ish bo'lsa, unda o'zingiz uchun bir nechta klişe yaratish unchalik qiyin bo'lmaydi.

Standartlarni tekshirish qanchalik muhimligini esga olish kerak: u GOST, normativ yoki huquqiy hujjatlar, mahalliy aktlar va hokazo.