რა არის "ტექნიკური დავალება"? სტანდარტები და შაბლონები TK-სთვის განვითარების თემის სახელითა და სიმბოლოებით.

პაველ მოლიანოვი

გახსოვთ მერფის კანონი? თუ შეიძლება არასწორად გაგიგონ, აუცილებლად გაგიგებენ. ეს ეხება არა მხოლოდ ადამიანებს შორის კომუნიკაციას, არამედ საიტების შექმნისას. კლიენტს სურდა მეორე ფეისბუქი, მაგრამ მიიღო ფორუმი ახალგაზრდა ძაღლების მომშენებლებისთვის. დეველოპერმა ვერ გამოიცნო მომხმარებლის სურვილების სია - მან დაკარგა დრო.

ამ სახელმძღვანელოში მე გეტყვით, რა და რატომ უნდა დაწეროთ მითითების პირობებში. ამავდროულად, მე გაჩვენებთ, თუ როგორ არ უნდა დაწეროთ, რომ ტექნიკური სპეციფიკაციის შექმნა არ გადაიზარდოს ფუჭად.

სტატია სასარგებლო იქნება:

• ყველა, ვინც დაკავშირებულია საიტების შექმნასთან: დეველოპერები, დიზაინერები, განლაგების დიზაინერები.
• პროექტის მენეჯერები.
• ციფრული სტუდიების ხელმძღვანელები.
• მეწარმეები, რომლებიც გეგმავენ შეუკვეთონ საიტის განვითარება.

მასალის გამოსაყენებლად, მე შევაგროვე კომენტარები რამდენიმე დეველოპერისგან, დიზაინერისგან, პროექტის მენეჯერისგან და ციფრული სტუდიების მფლობელებისგან. ყველაზე ღირებული პირობა დამატებულია სტატიის ბოლოს. მოდი, გავარკვიოთ.

რა არის სპეციფიკაცია და რატომ არის საჭირო

ტექნიკური დავალება- ეს არის დოკუმენტი, რომელშიც ჩაწერილია მოთხოვნები საიტის მიმართ. რაც უფრო მკაფიო და დეტალურია ეს მოთხოვნები, მით უფრო კარგად ესმის პროცესის ყველა მონაწილე, როგორი უნდა იყოს ეს. ეს ნიშნავს, რომ შანსი იმისა, რომ ყველა შედეგით კმაყოფილი დარჩეს, იზრდება.

დავალებების ძირითადი მიზანია დარწმუნდნენ, რომ კლიენტი და შემსრულებელი ერთმანეთს სწორად ესმით.

ტექნიკური მახასიათებლების მრავალი უპირატესობა არსებობს. თითოეულ მხარეს აქვს თავისი.

სარგებელი კლიენტისთვის:

• გაიგე რაში იხდის ფულს და როგორი იქნება საიტი.თქვენ შეგიძლიათ დაუყოვნებლივ ნახოთ სტრუქტურა, გაიგოთ რა იმუშავებს და როგორ. გაარკვიე, ჯდება თუ არა ყველაფერი. თუ არა - არ არის პრობლემა, რომ შეიცვალოს განვითარების დაწყებამდე.
• იხილეთ შემსრულებლის კომპეტენცია.თუ მითითების პირობები გასაგები და გასაგებია, დეველოპერისადმი ნდობა იზრდება. თუ იქ ფაფა წერია, შეიძლება ღირდეს სირბილი და უკანმოუხედავად.
• დაზღვეული შემსრულებლის არაკეთილსინდისიერებისაგან.როდესაც საიტი მზად იქნება, მისი შემოწმება შესაძლებელია მითითების პირობების მიხედვით. არის თუ არა შეუსაბამობები? დეველოპერმა უნდა გაასწოროს ისინი. თუ ოფიციალურად ითანამშრომლებ და ხელშეკრულებას გააფორმებ, შეიძლება სასამართლოშიც კი აიძულო.
• შემსრულებლების ჩანაცვლების გამარტივება.თუ კლიენტი და დეველოპერი იჩხუბეს და გაიქცნენ, საიტის შექმნას შეიძლება დიდი დრო დასჭირდეს. როდესაც არის დეტალური ინსტრუქცია, ის შეიძლება გადავიდეს ახალ გუნდში - ის ბევრჯერ უფრო სწრაფად ჩაერთვება სამუშაოში.
• გაეცანით რთული პროდუქტის შემუშავების ღირებულებას.შეუძლებელია კომპლექსური ვებ სერვისის შემუშავების ზუსტი დროისა და ღირებულების დადგენა. ჯერ უნდა გესმოდეთ, როგორ იმუშავებს სერვისი და რა ფუნქციები ექნება მას. ამისათვის თქვენ უნდა მოამზადოთ ტექნიკური დავალება.

უპირატესობები შემსრულებლისთვის:

• გაიგეთ რა სურს მომხმარებელს.კლიენტს სვამს ათობით კითხვას, ნაჩვენებია მაგალითები, სთავაზობენ გადაწყვეტილებებს. შემდეგ ყველაფერი იწერება ერთ დოკუმენტში და კოორდინირებულია. თუ ყველაფერი რიგზეა - გაიხარე, სწორად გაიგე.
• კლიენტის უეცარი სურვილების სიის დაზღვევის მიზნით.ზოგჯერ არიან მომხმარებლები, რომლებსაც სურთ შეცვალონ დავალება ნახევრად. თუ თქვენ დათანხმდით და მოაწერეთ ხელი TOR-ს, ამის არ გეშინიათ. ამ შემთხვევაში სასამართლოც კი თქვენს მხარეს იქნება.
• აჩვენე შენი კომპეტენცია.კარგად მომზადებული ტექნიკური პირობები კლიენტს აჩვენებს დეველოპერების გამოცდილებას. თუ კომპანიას ეჭვი ეპარებოდა, ენდობოდა თუ არა საიტის განვითარებას, ეჭვები სავარაუდოდ გაქრება.
• Ფულის შოვნა.ზოგიერთი სტუდია და დეველოპერი გთავაზობთ ტექნიკური მახასიათებლების მომზადებას, როგორც ცალკე სერვისს.

• ხელი შეუწყოს და დააჩქაროს განვითარების პროცესი. კარგი TOR მიუთითებს საიტის სტრუქტურაზე, საჭირო ფუნქციებსა და ელემენტებზე თითოეულ გვერდზე. როდესაც ყველა მოთხოვნა უკვე თქვენს თვალწინ დგას, რჩება მხოლოდ კოდის შემუშავება და დაწერა.

ახლა მოდით გავარკვიოთ, როგორ დავწეროთ კარგი TOR, რომელიც ასრულებს ყველა ამ ფუნქციას.

მითითების პირობებს ადგენს შემსრულებელი

ზოგადად, ტექნიკური დავალების შესრულება ნებისმიერს შეუძლია. „ჩვენ გვჭირდება სავიზიტო ბარათის ვებგვერდი სტომატოლოგიური კლინიკისთვის“ - ეს უკვე ტექნიკური ამოცანაა. მაგრამ გააკეთებს თავის საქმეს? ძლივს.

კარგ TOR-ს ყოველთვის აკეთებს შემსრულებელი: პროექტის მენეჯერი ან დეველოპერი. ცხადია, ვებ დეველოპერს უფრო მეტი ესმის ვებსაიტების შექმნის შესახებ, ვიდრე კაფეს ან სტომატოლოგიური კლინიკის მფლობელს. ამიტომ მას მოუწევს პროექტის აღწერა.

ეს არ ნიშნავს იმას, რომ კლიენტი ქრება და ჩნდება ბოლოში და წერს: „ზბს, ვამტკიცებ“. მან ასევე უნდა მიიღოს მონაწილეობა პროცესში:

რა თქმა უნდა, მომხმარებელს შეუძლია დახატოს TK-ის საკუთარი ვერსია. შესაძლოა, ეს დააჩქარებს საბოლოო სამუშაოს შექმნის პროცესს. და, ალბათ, ეს ნაგავი აღმოჩნდება, რომელიც ჩუმად გადაყრილია სანაგვეში.

დაწერეთ ნათლად და ზუსტად

ეს რჩევა გამომდინარეობს სამუშაო პირობების მთავარი მიზნიდან – „დარწმუნდით, რომ კლიენტმა და კონტრაქტორმა სწორად გაიგეს ერთმანეთი“.

მითითების პირობები არ უნდა შეიცავდეს მაღალი ხარისხის ზედსართავ სახელებს: ლამაზი, საიმედო, თანამედროვე. მათი ნათლად გაგება შეუძლებელია. ყველას აქვს სილამაზისა და თანამედროვეობის საკუთარი კონცეფცია.

შეხედე. ბოლოს და ბოლოს, ვიღაცამ ჩათვალა, რომ ეს დიზაინი ლამაზი იყო და დაუშვა მისი გამოყენება მათ ვებსაიტზე:

იგივე - ბუნდოვანი ფორმულირებით, რაც თავისთავად არაფერს ნიშნავს:

• საიტი უნდა მოეწონოს მომხმარებელს.რა მოხდება, თუ ის ცუდ ხასიათზეა?
• საიტი უნდა იყოს მომხმარებლისთვის მოსახერხებელი.Რას ნიშნავს? მოსახერხებელი რისთვის?
• საიტი უნდა გაუძლოს მძიმე დატვირთვას. 10 ათასი ვიზიტორი? თუ 10 მილიონი?
• ხარისხის ექსპერტის შინაარსი.კარგად, თქვენ გესმით იდეა.

შეამოწმეთ ტექსტში ბუნდოვანება. თუ არის - გადაწერეთ. თქვენი ფორმულირება უნდა იყოს მკაფიო და ზუსტი:

• საიტი სწრაფად უნდა იტვირთებოდეს → საიტის ნებისმიერ გვერდს უნდა ჰქონდეს 80-ზე მეტი ქულა Google PageSpeed ​​Insights-ში.
• დიდი დატვირთვა → 50 ათასი ვიზიტორი ერთდროულად.
• მთავარ გვერდზე ნაჩვენებია სტატიების სია → მთავარ გვერდზე ნაჩვენებია ბოლო 6 გამოქვეყნებული სტატიის სია.
• მინიმალისტური მომხმარებლისთვის მოსახერხებელი სააბონენტო ინტერფეისი → დატოვეთ ელექტრონული ფოსტის ველი და ღილაკი გამოწერა → *დახატული ესკიზი*.

ჩვენ გავარკვიეთ ფორმულირება, მოდით გადავიდეთ სტრუქტურაზე.

შეიყვანეთ ზოგადი ინფორმაცია

გუნდის ყველა წევრმა სწორად უნდა გაიგოს, რას აკეთებს კომპანია და ვინ არის მისი სამიზნე აუდიტორია. რომ არავინ დაიბნა, სჯობს დანიშნოთ ტერმინების დასაწყისშივე.

და ასევე ღირს საიტის მიზნის მითითება და მისი ფუნქციონირების მოკლედ აღწერა - ისე, რომ არ მიიღოთ ონლაინ მაღაზია ბლოგის ნაცვლად.

ახსენით რთული ტერმინები

მითითების პირობების პირველი წესი არის ის, რომ ყველასთვის გასაგები უნდა იყოს, ვისთვის არის განკუთვნილი. თუ თქვენ აპირებთ ტერმინების გამოყენებას, რომლებიც თქვენს კლიენტს - საბავშვო სათამაშოების მაღაზიის მფლობელს - შეიძლება არ ესმოდეს, აუცილებლად აუხსენით. უბრალო ენით, არა კოპირება-პასტი ვიკიპედიიდან.

აღწერეთ ინსტრუმენტები და ჰოსტინგის მოთხოვნები

წარმოიდგინეთ, რომ 2 თვის განმავლობაში ქმნით მაგარი ვებსაიტს. თითოეული ეტაპი იყო კოორდინირებული კლიენტთან - ის აღფრთოვანებულია. ახლა კი სამუშაოს ჩაბარების დროა. თქვენ აჩვენებთ ადმინისტრაციულ პანელს და კლიენტი ყვირის: „ეს რა არის? მოდექსი?! მე მეგონა ამას გააკეთებდი WordPress-ზე!”

ასეთი პრობლემების თავიდან ასაცილებლად, აღწერეთ გამოყენებული ხელსაწყოები, ძრავები და ბიბლიოთეკები. ამავე დროს, მიუთითეთ მოთხოვნები ჰოსტინგისთვის. თქვენ არასოდეს იცით, ამას გააკეთებთ PHP-ში - და კლიენტს აქვს სერვერი .NET-ში.

ჩამოთვალეთ მოთხოვნები საიტისთვის

საიტი უნდა მუშაობდეს მიმდინარე ვერსიების ყველა ბრაუზერში და ყველა ტიპის მოწყობილობაზე. დიახ, ეს აშკარაა ნებისმიერი დეველოპერისთვის და ნებისმიერი მომხმარებლისთვის. მაგრამ უმჯობესია დაწეროთ, რათა დაიცვათ კლიენტი არაკეთილსინდისიერად შესრულებული სამუშაოსგან.

აქ დაწერეთ მოთხოვნები საიტის ჩატვირთვის სიჩქარის, დატვირთვის წინააღმდეგობის, ჰაკერების თავდასხმებისგან დაცვის და მსგავსი რამის მიმართ.

მიუთითეთ საიტის სტრუქტურა

დიზაინისა და განლაგების დახატვამდე საჭიროა კლიენტთან შეათანხმოთ საიტის სტრუქტურა.

ესაუბრეთ მომხმარებელს, გაარკვიეთ რა სჭირდება მას. შეკრიბეთ დეველოპერები, SEO-ები, მარკეტოლოგები, მთავარი რედაქტორი - და გადაწყვიტეთ რომელი გვერდებია საჭირო საიტზე. იფიქრეთ იმაზე, თუ როგორ იქნება ისინი ერთმანეთთან დაკავშირებული, საიდანაც შეგიძლიათ გადახვიდეთ.

თქვენ შეგიძლიათ აჩვენოთ სტრუქტურა სიის სახით, შეგიძლიათ დახაზოთ ბლოკ-სქემა. Როგორც შენ გირჩევნია.

ეს არის საიტზე მუშაობის ერთ-ერთი ყველაზე მნიშვნელოვანი ეტაპი. სტრუქტურა არის საფუძველი. თუ ის წარუმატებელი აღმოჩნდა, საიტი მრუდე აღმოჩნდება.

ახსენით რა იქნება თითოეულ გვერდზე

კლიენტმა უნდა გაიგოს, რატომ არის საჭირო თითოეული გვერდი და რა ელემენტები იქნება მასზე. ამის ჩვენების ორი გზა არსებობს.

Პროტოტიპი- უფრო ვიზუალური და ცალსახა გზა. კონტრაქტორი ხატავს თითოეული გვერდის ესკიზებს და ანიჭებს მათ მითითების პირობებს. კლიენტი ხედავს როგორი იქნება მისი მომავალი საიტის ინტერფეისი და ამბობს რა მოსწონს და რა უნდა შეიცვალოს.

ელემენტების ჩამოთვლაპროტოტიპის ზარმაცი ალტერნატივაა. უბრალოდ დაწერეთ რა ბლოკები უნდა იყოს გვერდზე და რას აკეთებენ ისინი.

ჩამოწერეთ საიტის გამოყენების სცენარები

თუ თქვენ აკეთებთ რაიმე სახის არასტანდარტულ ინტერფეისს, მხოლოდ სტრუქტურისა და გვერდის ესკიზების ჩვენება საკმარისი არ არის. მნიშვნელოვანია, რომ განხორციელების მთელმა ჯგუფმა და კლიენტმა გაიგოს, თუ როგორ გამოიყენებენ ვიზიტორები საიტს. სკრიპტები შესანიშნავია ამისთვის. სკრიპტის მონახაზი ძალიან მარტივია:

• მომხმარებლის მოქმედება.
• საიტის პასუხი.
• შედეგი.

რა თქმა უნდა, თუ თქვენ აკეთებთ სტანდარტულ სავიზიტო ბარათს ან სადესანტო გვერდს, თქვენ არ გჭირდებათ სკრიპტების დაწერა. მაგრამ თუ საიტზე არის რამდენიმე ინტერაქტიული სერვისი, ძალიან სასურველია.

წაიკითხეთ მეტი გამოყენების შემთხვევების შესახებ ვიკიპედიაში.

დაადგინეთ ვინ არის პასუხისმგებელი შინაარსზე

ზოგიერთი დეველოპერი დაუყოვნებლივ ქმნის საიტს შინაარსით. სხვებმა დაასვენეს თევზი. სხვებს შეუძლიათ ტექსტების დაწერა, მაგრამ დამატებითი საფასურით. ამაზე ნაპირზე შევთანხმდით და ინსტრუქციაში დააფიქსირეთ რა შინაარსი უნდა მოამზადოთ.

საკმაოდ რთულია ტექსტების ხარისხის შეფასების ობიექტური კრიტერიუმების გამომუშავება. სჯობს არ დაწეროთ არაფერი, გარდა „მაღალი ხარისხის, საინტერესო და გასაყიდი შინაარსისა, რომელიც სასარგებლოა სამიზნე აუდიტორიისთვის“. ეს ნაგავია, არავის სჭირდება.

დაზუსტება, რომ ყველა შინაარსი უნიკალური უნდა იყოს, სასარგებლოა. კლიენტის კიდევ ერთი დაცვა არაკეთილსინდისიერი შემსრულებლებისგან.

აღწერეთ დიზაინი (თუ შეგიძლიათ)

როგორც ტექსტის შემთხვევაში, რთულია საიტის დიზაინის შეფასების ობიექტური კრიტერიუმების გამომუშავება. თუ თქვენ და კლიენტი შეთანხმდით ფერთა სქემაზე, ჩაწერეთ. თუ აქვს ბრენდის წიგნი, რომელშიც ფონტებია რეგისტრირებული, მიუთითეთ ისინიც.

არ არის აუცილებელი ლამაზ და თანამედროვე დიზაინზე წერა. ეს არაფერს ნიშნავს, არ აქვს ძალა და საერთოდ ფუ.

დასკვნის ნაცვლად: მითითებების სტრუქტურა

სხვადასხვა ამოცანებისთვის, TOR-ის სტრუქტურა განსხვავებული იქნება. სისულელეა იგივე ტექნიკური მახასიათებლების გაკეთება ახალი სოციალური ქსელისთვის და საბითუმო სტაფილოების სადესანტო გვერდისთვის. მაგრამ ზოგადად, თქვენ გჭირდებათ ასეთი სექციები:

• ინფორმაცია კომპანიისა და სამიზნე აუდიტორიის, საიტის მიზნებისა და ამოცანების შესახებ.
• ტერმინების ლექსიკონი, რომელიც შეიძლება გაუგებარი იყოს კლიენტისთვის.
• Ტექნიკური მოთხოვნებისაიტის განლაგებასა და ფუნქციონირებას.
• გამოყენებული ტექნოლოგიების აღწერა და ჰოსტინგის მოთხოვნების ჩამონათვალი.
• საიტის დეტალური სტრუქტურა.
• გვერდების პროტოტიპები ან ელემენტების აღწერილობები, რომლებიც უნდა იყოს მათზე.
• არასტანდარტული ინტერფეისის გამოყენების სცენარები (სურვილისამებრ).
• კონტენტის სია, რომელსაც დეველოპერი აკეთებს.
• დიზაინის მოთხოვნები (სურვილისამებრ).

• პროგრამული უზრუნველყოფის მოთხოვნების სპეციფიკაციის შედგენის წესები. SRS არის შემდეგი ნაბიჯი მითითების პირობების ევოლუციაში. საჭიროა დიდი და რთული პროექტებისთვის.
• TOR-ის სტანდარტები და შაბლონები პროგრამული უზრუნველყოფის განვითარებისთვის. სხვადასხვა GOST-ების აღწერა და ტექნიკური მახასიათებლების შექმნის მეთოდოლოგიები.

ეს არის ჩემი დაწერილი ნაწილის დასასრული. მაგრამ არის კიდევ ერთი - ექსპერტების კომენტარები, რომლებიც დაეხმარნენ სახელმძღვანელოს შექმნას. წაიკითხე, ისიც საინტერესოა.

დეველოპერის კომენტარები

მე ვესაუბრე რამდენიმე დეველოპერს, რათა გამეგო, როგორ წერენ სპეციფიკაციები. მათ მიკროფონს ვაძლევ.

უპირველეს ყოვლისა, კლიენტს სჭირდება TK - რათა მან გაიგოს, როგორი იქნება მისი საიტი და რაში იხარჯება ფული. თუ რამე არასწორად გაკეთდა, მას შეუძლია მიმართოს TK-ს და მოითხოვოს ხელახლა გაკეთება.

TOR შედგენილია პროექტის მენეჯერის მიერ კლიენტთან კომუნიკაციისა და დავალების დიზაინერთან განხილვის შემდეგ.

მსხვილი მომხმარებლები ხშირად ითხოვენ ძალიან დეტალურ ტექნიკურ მახასიათებლებს, რომლებიც აღწერს თითოეულ ღილაკს. პირიქით, მცირე კომპანიებს არ მოსწონთ ზედმიწევნითი 100-გვერდიანი დოკუმენტები. ის დიდხანს იკითხება და ადვილია რაიმე მნიშვნელოვანის გამოტოვება. უფრო ხშირად ვაკეთებთ მოკლე ტექნიკურ მახასიათებლებს 10-15 გვერდისთვის.

ჩვენ აღვნიშნავთ:

• ინფორმაცია კომპანიისა და საიტის დანიშნულების შესახებ.
• დიზაინის მოთხოვნები, ფერები.
• გამოყენებული ტექნოლოგიები და CMS.
• ვინ არის დაკავებული შინაარსით - ჩვენ თუ კლიენტი.
• საიტის სტრუქტურა თითოეულ გვერდზე.
• თითოეული გვერდის აღწერა. ჩვენ არ ვაკეთებთ პროტოტიპებს, მაგრამ ვაზუსტებთ, რა ელემენტები უნდა იყოს გვერდზე და როგორ უნდა იმუშაონ.

ბოლო 2 განყოფილება ყველაზე მნიშვნელოვანია. ისინი უზრუნველყოფენ იმის გაგებას, თუ როგორი იქნება საიტი და როგორ იმუშავებს.

ძალიან მნიშვნელოვანი პუნქტი - თქვენ არ შეგიძლიათ მხოლოდ დეველოპერებისთვის მითითებების მიცემა და იმედი გაქვთ, რომ ისინი ყველაფერს კარგად გააკეთებენ. TK არის საიტის მოთხოვნების ჩამონათვალი, ის ვერ შეცვლის კომუნიკაციას. მნიშვნელოვანია დავრწმუნდეთ, რომ გუნდის თითოეულ წევრს ესმის საერთო მიზანი და არა მხოლოდ ნაკადის მიხედვით დავალებების შესრულება. თუ რამე გაუგებარია - აუცილებელია ახსნა, განხილვა, დეტალური კომენტარების გაკეთება.

ხშირად გესმით მოსაზრება, რომ სამუშაო პირობების მომზადება GOST 34 (TK) შესაბამისად არა მხოლოდ შრომატევადი, არამედ უკიდურესად შემაშფოთებელია, რადგან თქვენ უნდა დაწეროთ უამრავი სისულელე, წყალი. მაგრამ დაფიქრდით: მთელი კვლევითი ინსტიტუტები მონაწილეობდნენ ამ GOST-ის შემუშავებაში, ეს იყო პროექტი სახელმწიფო დონეზე, შეაჯამა ასობით ავტომატიზაციის პროექტის, რთული პროექტების გამოცდილება. შეიძლება სისულელეები დაეწერათ?

სინამდვილეში, კომპეტენტური მიდგომით, GOST ბევრს ეხმარება არა მხოლოდ ტექნიკური მახასიათებლების შემუშავებაში, არამედ მთლიანად ავტომატიზაციის პროექტის განხორციელებისას (და არა მხოლოდ სახელმწიფო კონტრაქტებში, არამედ კომერციულ განვითარებაში). ჭკვიანმა ხალხმა დაწერა. მაგრამ იმისათვის, რომ ისარგებლოთ მათი შრომის ნაყოფით, თქვენ უნდა გაიგოთ არა მხოლოდ TK-ის, არამედ მთლიანად GOST 34-ის განზრახვა.

ამ სტატიაში ჩვენ გავაანალიზებთ GOST-ის ყველა მოთხოვნას პუნქტობრივად და ვცდილობთ, რომ ტექნიკური მახასიათებლების შემუშავება GOST 34-ის მიხედვით არა ტვირთად, არამედ დიდ დახმარებას გავხადოთ პროექტში.

1. რაზეა საუბარი სტატიაში

ხშირად გესმით მოსაზრება, რომ სამუშაო პირობების მომზადება GOST 34 (TK) შესაბამისად არა მხოლოდ შრომატევადი, არამედ უკიდურესად შემაშფოთებელია, რადგან თქვენ უნდა დაწეროთ უამრავი სისულელე, წყალი. მაგრამ დაფიქრდით: მთელი კვლევითი ინსტიტუტები მონაწილეობდნენ ამ GOST-ის შემუშავებაში, ეს იყო პროექტი სახელმწიფო დონეზე, განზოგადებული იყო ასობით ავტომატიზაციის პროექტის, რთული პროექტების გამოცდილება. შეიძლება სისულელეები დაეწერათ?

სინამდვილეში, კომპეტენტური მიდგომით, GOST ბევრს ეხმარება არა მხოლოდ ტექნიკური მახასიათებლების შემუშავებაში, არამედ მთლიანად ავტომატიზაციის პროექტის განხორციელების დროს (და არა მხოლოდ სახელმწიფო კონტრაქტებში, არამედ კომერციულ განვითარებაში). ჭკვიანმა ხალხმა დაწერა. მაგრამ იმისათვის, რომ ისარგებლოთ მათი შრომის ნაყოფით, თქვენ უნდა გაიგოთ არა მხოლოდ TK-ის, არამედ მთლიანად GOST 34-ის განზრახვა.

ყურადღება: ამ სტატიის მიზანია არა GOST-ის შეცვლა, არამედ მისი ზოგიერთი დებულების ახსნა.

2. ტექნიკური მახასიათებლების დამახასიათებელი ნიშნები GOST 34-ის მიხედვით

2.1. რა სტანდარტით არის შედგენილი TOR?

TK სტანდარტის სრული სახელწოდება GOST 34-ის მიხედვით ასეთია: GOST 34.602-89 „ინფორმაციული ტექნოლოგია (IT). სტანდარტების ნაკრები ავტომატური სისტემებისთვის. შექმნის მითითებები ავტომატური სისტემა».

თავად სტანდარტი იბეჭდება მხოლოდ 15 გვერდზე (დიახ, საკმაოდ ცოტა). ენა რუსულია, მართლა რუსულია და არა უცხო, კირილიცაზე ჩასმული. ანუ, თუ წინასწარ არ მიიყვანთ თქვენს თავში, არც GOST-ების ტექსტები და არც ფედერალური კანონები, არცერთი დისერტაცია არ არის გასაგები უბრალო მოკვდავისთვის, მაშინ სავსებით შესაძლებელია მისი წაკითხვა და გაგება, თუმცა ხშირად არა პირველად.

მართლაც, სტანდარტი იყენებს უამრავ ბუნდოვან ტერმინს. მაგალითად, რა იგულისხმება ენობრივ მხარდაჭერაში? გამოყენებული ცნებების გასარკვევად, იხილეთ GOST 34.003-90 „ინფორმაციული ტექნოლოგია (IT). სტანდარტების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. ტერმინები და განმარტებები“.

2.2. რატომ გვჭირდება GOST სამუშაო პირობებისთვის?

ალბათ, როცა რაიმე ახალი დოკუმენტის შედგენა გჭირდებათ, ინტერნეტში ეძებთ ასეთი დოკუმენტის შაბლონს ან სთხოვთ კოლეგებს. ასე რომ, დოკუმენტების ან პროცესების ნებისმიერი სტანდარტი არის შაბლონი. უფრო მეტიც, შაბლონი მნიშვნელოვნად ამარტივებს დოკუმენტის შემუშავებას: სტრუქტურა და შინაარსი უკვე გააზრებული გაქვთ თქვენთვის, გარდა ამისა, ისეთი მომენტებია გათვალისწინებული ისეთ შაბლონში, რომ არც კი გახსოვთ.

2.3. რა როლი აკისრია პროექტში მუშაობის პირობებს?

RD 50-682-89 სტანდარტის 1.7 პუნქტის თანახმად, „ტექნიკის პირობები არის მთავარი დოკუმენტი, რომლის მიხედვითაც ხდება AU-ს შექმნა და მისი მიღება მომხმარებლის მიერ“. და ეს მართლაც მთავარი დოკუმენტია. მასში უნდა იყოს აღწერილი ყველაფერი, რაც აუცილებელია სისტემის განვითარებისა და დანერგვისთვის.

TOR ადგენს სისტემის ზოგად იერსახეს, სამუშაოს ფარგლებს (განვითარების ჩარჩოს), ასევე განვითარებისა და მიღების პროცედურას. ყველაფერი იწყება TK-ით და ყველაფერი მთავრდება ამით. ეს დოკუმენტი იდეალურია იმისთვის, რომ თქვენმა კლიენტმა გაიგოს ამოცანის მნიშვნელობა და სირთულე და რაში იხდის ფულს.

უფრო მეტიც, TOR შედგენილია როგორც კონტრაქტორისთვის, ასევე მომხმარებლისთვის, რადგან ავტომატიზაციის პროექტს ახორციელებენ ორივე მხარის გუნდები. ნებისმიერ IT პროექტში არის დიდი რაოდენობით ორგანიზაციული აქტივობები, რომელთა განხორციელებაც გარეშე აქტიური მონაწილეობამომხმარებელს არ შეუძლია. აუხსენით ეს მომხმარებელს ყოველ შემთხვევაში, თორემ იქმნება შთაბეჭდილება, რომ მხოლოდ ფულის გადახდა და მშვიდად ჯდომა უწევთ: დაქირავებული ბიჭები ყველაფერს გააკეთებენ. შემდეგ კი პროექტი მარცხდება და იწყება დემონტაჟი. ზოგადად, ამ მხრიდან რეალური გუნდის გარეშე, არ ღირს პროექტის დაწყება.

არ შეადგინოთ ტექნიკური მახასიათებლები ფორმალურად. თუ არ იცით რა დაწეროთ, მაშინ ჯერ ნაადრევია ტექნიკური მახასიათებლების შემუშავება, არ გაქვთ სისტემის გაგება, თავად ავტომატური პროცესი, ავტომატიზაციის ობიექტი, ჯერ არ არის ნათელი. თქვენ უნდა შეადგინოთ, ამაზე სტატიის დასაწყისშივე ვისაუბრეთ.

2.4. რამდენად მოძველებულია GOST 34.602-89 და არის თუ არა ახალი სტანდარტები?

არა რამდენად მოძველებულია. თითქმის ვერ მოვახერხე არარელევანტური ნივთების პოვნა. და არცერთი მათგანი, ვინც ამტკიცებს, რომ GOST 34 მოძველებულია, არ შეუძლია ერთი მაგალითის მოყვანა (ალბათ, მათ უბრალოდ არ ჰქონდათ საკმარისი კვალიფიკაცია მის წასაკითხად?) ფაქტია, რომ GOST აღწერს ზოგად მიდგომას ავტომატიზაციის პროექტთან მიმართებაში, ეს ასე არ არის. საუბარი პროგრამირებაზე, GOST 34 არ არის ამაზე.

ისე, თუ ვსაუბრობთ სხვა სტანდარტებთან შედარებაზე, მაშინ განსაკუთრებული არაფერია შედარება. GOST 34 წარმოადგენს ავტომატიზაციის პროექტის ისეთ ფართო ხედვას, რომ დანარჩენი სტანდარტები არ ემთხვევა (ჩემი აზრით). დიახ, ისინი უფრო მარტივია (და, შესაბამისად, უფრო პოპულარული), მაგრამ სიღრმე არ არის იგივე. აქ არის სტანდარტების სია, რომლებიც გასათვალისწინებელია ავტომატიზაციის პროექტისთვის საკუთარი სტანდარტების შემუშავებისას:

• IEEE 830-1998. პროგრამული მოთხოვნების სპეციფიკაციების შედგენის მეთოდოლოგია.
• GOST R ISO/IEC 12207-2010. Საინფორმაციო ტექნოლოგია. სისტემის და პროგრამული უზრუნველყოფის ინჟინერია. პროცესები ცხოვრების ციკლიპროგრამული ინსტრუმენტები.
• ISO/IEC/IEEE 29148-2011. სისტემებისა და პროგრამული უზრუნველყოფის ინჟინერია - სასიცოცხლო ციკლის პროცესები - მოთხოვნების ინჟინერია.
• GOST R 54869-2011. Პროექტის მენეჯმენტი. პროექტის მენეჯმენტის მოთხოვნები.
• ისე, GOST სერია 34.

3. TOR-ის მომზადების ზოგადი პრინციპები GOST 34-ის შესაბამისად

3.1. რომელმა სპეციალისტმა უნდა შეადგინოს სამუშაო პირობები GOST 34-ის შესაბამისად?

ხშირად, დეველოპერები ბევრს იფიცებენ GOST 34-ის შესაბამისად ტექნიკური მახასიათებლების შედგენისას. რატომ? დიახ, რადგან ეს არ არის პროგრამისტების საქმე. მითითების პირობები GOST 34-ის მიხედვით, ზოგადად არ შეიძლება იყოს ნაჩვენები პროგრამისტებისთვის. ამისთვის არის ტექნიკური საპროექტო დოკუმენტაცია. სამუშაო პირობები არის მომხმარებელთან შეთანხმებული დოკუმენტი, რომელიც მუდმივად დგას პროექტის მენეჯერის მაგიდაზე. TOR პასუხობს ორ კითხვას: რა უნდა გააკეთოს სისტემამ და როგორ უნდა შეიქმნას. ტექნიკური პროექტი პასუხობს კითხვას: როგორ უნდა დაკმაყოფილდეს TOR-ის მოთხოვნები. მაგალითად, TOR-ში თქვენ განსაზღვრავთ, რომ ავტორიზაცია უნდა იყოს შესვლისა და პაროლით, ხოლო TP-ში თქვენ აწვდით ინტერფეისის განლაგებას, სკრიპტებს და მონაცემთა ბაზის სტრუქტურას. რატომ არის დაყოფა სხვადასხვა ეტაპად და რატომ არ უნდა დაუყოვნებლივ გააკეთოთ დავალება პროგრამისტებისთვის, იხილეთ ჩემი სტატიები და.

სამუშაო პირობები უნდა შეადგინოს ბიზნეს ანალიტიკოსმა, რადგან ის არის „მთარგმნელი“ მომხმარებელსა და განვითარების გუნდს შორის. ბიზნეს ანალიტიკოსის ამოცანაა გაიგოს რა სჭირდება მომხმარებელს და გამოხატოს გუნდისთვის გასაგები. და გამოხატეთ იგი ტექნიკური დავალების სახით. უფრო მეტიც, ბიზნეს ანალიტიკოსს მოეთხოვება არა მხოლოდ მოუსმინოს მომხმარებელს და მის თანამშრომლებს, არამედ გაარკვიოს ის, რაც მათ არ თქვეს (და ეს ჩვეულებრივ 50%-ზე მეტია). ამიტომ ანალიტიკოსმა კარგად უნდა იცოდეს ავტომატიზირებული პროცესები და თავისი ცოდნით შეავსოს ის ხარვეზები, რომლებიც დარჩა გამოკითხვის შედეგების მიხედვით.

3.2. რომელმა მხარემ უნდა შეადგინოს სამუშაო პირობები?

ძირითადად, სამუშაო პირობები შედგენილია კონტრაქტორის მიერ? რატომ?

არა მხოლოდ იმიტომ, რომ ის რეკომენდირებულია GOST 34-602-89 დანართში 1. ფაქტობრივად, მომხმარებელს, როგორც წესი, არ ჰყავს შესაბამისი სპეციალისტები. მაგრამ TK შევიდა უშეცდომოდშემუშავებული და დამტკიცებული კლიენტის მიერ. და აქ აუცილებელია დავრწმუნდეთ, რომ შეთანხმება არ არის ფორმალური. მე ყოველთვის ვცდილობ დაჟინებით მოვითხოვ, რომ ჩვენ, მომხმარებელთან ერთად, დეტალურად გავაანალიზოთ თითოეული ნივთი. თქვენი მიზანია კლიენტის ჩართვა პროექტში. წინააღმდეგ შემთხვევაში, ის არ ჩამოაყალიბებს თავის მოლოდინს სისტემიდან, რაც ნიშნავს, რომ ჯერ ერთი, უკმაყოფილო იქნება რაიმე შედეგით და მეორეც, ვერ შეძლებს საჭიროების შესრულებას. ორგანიზაციული ღონისძიებები.

3.3. რამდენად შორს შეგიძლიათ გადახვევა GOST 34-დან?

ყველა შაბლონსაც აქვს მნიშვნელოვანი მინუსი, არის შაბლონი. ანუ, ნაბიჯი მარჯვნივ და მარცხნივ არის უმაღლესი საზომი სოციალური დაცვა(როგორც ადრე ეძახდნენ სიკვდილით დასჯა).

სინამდვილეში, ყველაფერი ასე არ არის. ნებისმიერი პროცესის სტანდარტი (ანუ სტანდარტი არა ძეხვისთვის, არამედ ნებისმიერი აქტივობისთვის) იძლევა მხოლოდ ზოგად ინსტრუქციას, ტილოს. ის შექმნილია იმისთვის, რომ დაგეხმაროთ დაიმახსოვროთ რაიმე მნიშვნელოვანი, გადასცეთ გამოცდილება თაობებს და არა დროშებზე გადასატანად.

არ გჯერა? შემდეგ წაიკითხეთ GOST 34.602-89 პუნქტი 2.2 (სხვათა შორის, დეფისის შემდეგ ნომრები არის სტანდარტის ან მისი გამოცემის გამოქვეყნების წელი): ”დამოკიდებულია ავტომატიზაციის ობიექტის ტიპზე, დანიშნულებაზე, სპეციფიკურ მახასიათებლებზე და სამუშაო პირობებზე. სისტემის, ნებადართულია TOR-ის სექციების შედგენა განაცხადების სახით, დანერგვა დამატებითი, გამოირიცხოს ან გაერთიანდეს TK ქვესექცია. ასევე 1.2 პუნქტში. RD 34.698-90 ნათქვამია: ”დოკუმენტების შინაარსი საერთოა ყველა ტიპის AS-ისთვის და, საჭიროების შემთხვევაში, შეიძლება დაემატოს დოკუმენტების შემქმნელმა, შექმნილი AS-ის მახასიათებლების მიხედვით. შეიძლება შეიტანოს დოკუმენტებში დამატებითი სექციებიდა ინფორმაცია, შეაერთეთ და გამორიცხეთ სექციები.

ზოგადად, თუ ახერხებთ მხოლოდ ზოგადი ფრაზების მოყვანას, ყველაფრის კარგის წინააღმდეგ, ყველაფრის წინააღმდეგ, არაფერი დაწეროთ. წინააღმდეგ შემთხვევაში, სპეციალისტი, რომელიც კითხულობს დოკუმენტს, რომელიც შეხვდება ასეთ პასაჟებს, შეწყვეტს დოკუმენტის სერიოზულად აღქმას და მნიშვნელოვანი დებულებები გამოტოვებს. ნუ აწამებთ დოკუმენტის კითხვას!

3.4. რატომ არის აღწერილი TOR-ში ამდენი მოთხოვნა GOST 34-ის მიხედვით, რომლებიც პირდაპირ არ არის დაკავშირებული სისტემის ფუნქციებთან?

მართლაც, 30 გვერდიან TOR-ში მხოლოდ 7-10 გვერდი შეიძლება დაეთმოთ ფუნქციებს. ამას აქვს ახსნა. ფაქტია, რომ GOST 34-ის დეველოპერებმა ავტომატიზაციის პროექტს სრულიად განსხვავებულად შეხედეს, ვიდრე ჩვენ. და ისინი უფრო სწორად, უფრო ყოვლისმომცველად გამოიყურებოდნენ.

ჯერ ერთი, TK-ის პირველ ნახევარში, ეს არ არის მხოლოდ ის, რომ ისინი მოცემულია ზოგადი ინფორმაციასისტემისა და ზოგადი მოთხოვნების შესახებ. აუცილებელია იმის გაგება, თუ რატომ იქმნება სისტემა, რა პროცესების ავტომატიზაცია ხდება, რა უნდა გაკეთდეს იმისათვის, რომ სისტემა იმუშაოს, რა გარეგნობა აქვს სისტემას. ერთი შეხედვით ბანალური რამ, მაგრამ მათ გარეშე გუნდის წევრები სხვადასხვა გზით გაიგებენ სამუშაოს მიზანს და მიზნის მიღწევის საშუალებებს. ჩვენთვის ძალიან მნიშვნელოვანია დავრწმუნდეთ, რომ ყველა მონაწილე ერთსა და იმავე ტალღაზე იყოს მორგებული და არა როგორც გედი, კიბო და პაიკი.

მეორეც GOST 34-ის შემდგენლებმა დაინახეს სისტემა, პირველ რიგში, როგორც ადამიანები, შემდეგ კი როგორც პროგრამული და აპარატურის კომპლექსი. აი, როგორ განსაზღვრავს GOST 34.003-90 ავტომატიზირებულ სისტემას: "სისტემა, რომელიც შედგება პერსონალისგან და ავტომატიზაციის ინსტრუმენტების კომპლექტისაგან მისი საქმიანობისთვის, რომელიც ახორციელებს ინფორმაციულ ტექნოლოგიას დადგენილი ფუნქციების შესასრულებლად." ამრიგად, საინფორმაციო სისტემა არის გაწვრთნილი პერსონალი, პროგრამული და აპარატურის კომპლექსი, ყველა ერთად. და მართლაც, წაართვით კომპიუტერები ბუღალტერებს, ისინი თავიანთ საქმეს გაჭირვებით შეძლებენ, თუმცა ქაღალდის რეესტრებით. მაგრამ 1C არ იმუშავებს დამოუკიდებლად ბუღალტერის გარეშე. აქედან გამომდინარეობს TOR-ის მრავალი განყოფილება, რომელიც ეძღვნება ორგანიზაციულ ღონისძიებებს. როგორც ამბობენ, IT სისტემის 20% არის IT, დანარჩენი ყველაფერი ორგანიზაციული ღონისძიებებია. ანუ TOR არის დოკუმენტი, რომელიც განსაზღვრავს ყველაფერს, რაც აუცილებელია სისტემის განსახორციელებლად, A-დან Z-მდე.

მესამე, ყურადღება მიაქციეთ GOST 34.602-89-ის სახელს: „ტექნიკის პირობები შექმნაავტომატური სისტემა". TK არ არის სისტემაზე, მაგრამ სისტემის შექმნაზე.Რა არის განსხვავება? განსხვავება ისაა, რომ TOR ადგენს არა მხოლოდ თავად სისტემის მოთხოვნებს, არამედ არეგულირებს მისი შექმნის პროცესს, ანუ დოკუმენტი შეიცავს მოთხოვნებს ყველა ორგანიზაციული ღონისძიებისთვის, რომელთა განხორციელება აუცილებელია შედეგის მისაღწევად. ყოველივე ამის შემდეგ, ავტომატიზაციის პროექტის განხორციელებისას, ხშირად საჭიროა მრავალი პროცესის აღდგენა, პერსონალის მომზადება და ტექნიკის მომზადება.

მეოთხე, TK არის დოკუმენტი, რომლის მონიშვნაც შესაძლებელია: გავითვალისწინეთ თუ არა ეს მოთხოვნა. შესაძლოა თქვენ მონიშნოთ 10 ველი წმინდა ავტომატურად, რადგან ეს იქნება სტანდარტული გადაწყვეტილებები. მაგრამ ტკიპის ნომერი 11 გამოავლენს ძალიან დიდი პრობლემა, და თუ ახლა გამოტოვებთ ამ პრობლემას, მაშინ ის გამოჩნდება სადღაც განხორციელების პროცესში, როდესაც ყველა ვადა და ბიუჯეტი უკვე განსაზღვრულია.

მეხუთეროგორც ზემოთ ვთქვით, შეიძლება გამოირიცხოს არასაჭირო ქვეპუნქტები, ეს დასაშვებია. მაგალითად, თუ დანამდვილებით იცით, რომ თქვენს განვითარებაში არაფერი შეიძლება იყოს დაპატენტებული, მაშინ რატომ შემოიტანეთ მოთხოვნები პატენტის გაფორმებისთვის? ეს ის შემთხვევა არ არის, როცა უწყლოდ და იქ არ არის და არა აქ.

3.5. რატომ ამბობენ სხვადასხვა განყოფილებები ერთსა და იმავეს?

მართლაც, ToR-ში არის ქვესექციები, რომლებიც მეტწილად იმეორებს სხვა ქვესექციების შინაარსს. მაგალითად, არსებობს მოთხოვნები ორგანიზაციული მხარდაჭერის და პერსონალის რაოდენობისა და კვალიფიკაციის შესახებ. ორივე პუნქტი ეხება პერსონალს. მაგრამ პირველ შემთხვევაში ჩვენ ვაწვდით ინფორმაციას ორგანიზაციული სტრუქტურის შესახებ: როგორი უნდა იყოს განყოფილებები, როგორ უნდა ჩამოყალიბდეს ურთიერთქმედება სხვა დეპარტამენტებთან. ვეთანხმები, ეს სულაც არ არის იგივე, რაც უბრალოდ პერსონალის რაოდენობისა და კვალიფიკაციის მოთხოვნები.

მაგრამ მცირე სისტემებისთვის საჭიროა მხოლოდ ერთი ან ორი ადმინისტრატორი და რამდენიმე მოდერატორი. ამ შემთხვევაში, ჩვენ უბრალოდ არაფერი გვაქვს აღსაწერი ორ ქვეთავში. შემდეგ გამოტოვეთ ერთი განყოფილება, ხოლო მეორეში მიუთითეთ მოთხოვნების სრული განცხადება.

3.6. საჭიროა თუ არა მაღალი ხარისხის ტექნიკური მახასიათებლების შედგენა?

მიუხედავად იმისა, რომ TK-ის დიზაინის მოთხოვნები მოცემულია GOST 34.602-89-ის მე-3 პუნქტში, მოდით ვთქვათ რამდენიმე სიტყვა ამ ასპექტის შესახებ.

რა თქმა უნდა, მთავარი შინაარსი. მაგრამ, ჯერ ერთი, ტანსაცმლით ხვდებიან და მეორეც, უმწერლობოდ დაწერილი ტექსტის წაკითხვა უჭირს ხტუნვის შრიფტით. მკითხველს უხარისხო დიზაინი გაუფანტავს და მათ შინაარსში ჩაღრმავება უფრო გაუჭირდება. ამიტომ, in ტექნიკური დოკუმენტებიმიღებულია მკაცრი შინაარსი და შეზღუდული ტერმინოლოგია, ფერადი გამონათქვამების გარეშე: მკითხველმა ყურადღება უნდა გაამახვილოს არსზე და არა მხატვრულ შემობრუნებებზე.

აქ არის რამდენიმე სურვილი დიდი დოკუმენტების დიზაინისთვის, როგორიცაა TK.

ჯერ ერთი, დიდ დოკუმენტში აუცილებელია სტილის გამოყენება და, გარდა აბზაცის შიგნით ხაზგასმისა და მონიშვნისა, არ შეცვალოთ შრიფტისა და აბზაცის პარამეტრები მხოლოდ ერთი ფრაგმენტისთვის. თუ შეცვლი, მაშინ სტილი.

მეორე, ნუ დაივიწყებთ ასეთებს საჭირო ელემენტები, როგორც ავტომატურად აწყობილი სარჩევი, ტერმინებისა და აბრევიატურების სია (კარგად, არ არის სიამოვნება იმის გამოცნობა, რას ნიშნავს ესა თუ ის აბრევიატურა), სათაურის გვერდი. ასევე სასურველია დოკუმენტის ვერსიების ჩამონათვალი, ცვლილებების ჩამონათვალი: ძალიან ადვილია მოგვიანებით თვალყური ადევნოთ, თუ რა თარიღებით გაიგზავნა ესა თუ ის ვერსია.

მეოთხე, თითოეული ინდივიდუალური მოთხოვნა უნდა იყოს ჩამოყალიბებული ცალკე დანომრილ აბზაცში. თუ ერთ ფრაგმენტში 2-3 მოთხოვნაა, მაშინ მხოლოდ პირველი იკითხება და ჩვენი ტვინი გამოტოვებს დანარჩენს. ToR არის დოკუმენტი, რომელშიც თითოეული აბზაცის მონიშვნა შესაძლებელია, დაკმაყოფილებულია თუ არა მოთხოვნა.

მეხუთე, არ დაზოგოთ ლინკების განთავსებაზე. ხანდახან კითხულობთ აბზაცს, სადაც მითითებულია რაიმე ფუნქცია ან მოთხოვნა და ვერ ხვდებით, არის ეს იგივე დოკუმენტიდან თუ სხვა. თუ აქედან, მაშინ რომელ განყოფილებაში. ამიტომ, შეეცადეთ მიმართოთ სხვა განყოფილებებს, თუ ისინი მოხსენიებულია მიმდინარე ტექსტში. ბუნებრივია, ბმულები უნდა იყოს ავტომატური.

გაითვალისწინეთ, რომ მკაცრი წესების მიხედვით, TK შედგენილია ჩარჩოს გარეშე (ეს განხილულია მე-3 პუნქტში), მაგრამ დანარჩენი დოკუმენტები - ჩარჩოთი. ეს დადგენილია GOST 24.301-80 "სისტემაში ტექნიკური დოკუმენტაცია ASU-ზე. Ძირითადი მოთხოვნებიშესრულებამდე ტექსტური დოკუმენტები(შესწორებები No1, 2)“. ეს სტანდარტი ადგენს ყველა დოკუმენტის შესრულების წესებს, გარდა TOR-ისა და წინაპროექტის ეტაპებზე შექმნილი დოკუმენტებისა. მიუხედავად იმისა, რომ მე პირადად არ მომწონს ჩარჩო არცერთ დოკუმენტში.

4. ნაწილი 1. „ზოგადი ინფორმაცია“ / გვ. 2.3 GOST 34.602-89/

ამ განყოფილებაში მოცემული ინფორმაციის უმეტესობას კომენტარი არ სჭირდება, ამიტომ ჩვენ ყურადღებას გავამახვილებთ მხოლოდ ზოგიერთ ქვესექციაზე.

ასე რომ, „დოკუმენტების ნუსხაში, რომლის საფუძველზეც იქმნება სისტემა“ ვგულისხმობთ კანონებს, ბრძანებებს ან შეთანხმებას. ასევე, სხვა TK შეიძლება იყოს ასეთი დოკუმენტი, თუ ჩვენ ვამუშავებთ TK ქვესისტემისთვის. ზოგადად, TOR-ში არის რამდენიმე განყოფილება, სადაც ჩამოთვლილია დოკუმენტები და ძალიან მკაფიოდ უნდა გვესმოდეს განსხვავებები მითითების პირობების ამ ნაწილების მიზნებს შორის.

ქვეგანყოფილება "რეგისტრაციის და მომხმარებლისთვის წარდგენის პროცედურა სისტემის (მისი ნაწილების) შექმნაზე მუშაობის შედეგების შესახებ, ინდივიდუალური ხელსაწყოების (ტექნიკა, პროგრამული უზრუნველყოფა, ინფორმაცია) და პროგრამული უზრუნველყოფისა და აპარატურის (პროგრამული და მეთოდოლოგიური) დამზადებისა და კორექტირების შესახებ. ) სისტემის სისტემები“ იძლევა ზოგად ინფორმაციას სამუშაოს მიღების შესახებ. მაგალითად, ის ფაქტი, რომ ჩვენ გადავცემთ დოკუმენტაციას და ვატარებთ სისტემის ტესტების სერიას. აქ მხოლოდ სამუშაოს შედეგების გადაცემის პროცედურას ვახსენებთ, ქვემოთ კი სხვა განყოფილებებში ეს თემა დეტალურადაა განხილული.

5. ნაწილი 2. „სისტემის შექმნის (განვითარების) მიზანი და ამოცანები“ / გვ. 2.4 GOST 34.602-89/

აქ ჩვენ უნდა გავიგოთ განსხვავება სისტემის შექმნის მიზანსა და მიზანს შორის. ძალიან ხშირად ეს ცნებები დაბნეულია. მაგალითად, წერენ, რომ სისტემის დანიშნულებაა პირადი ანგარიშის ავტომატიზაცია, მიზანი კი პირადი ანგარიშის შექმნაა. კარაქი ზეთი. ზოგიერთ შემთხვევაში, ეს ცნებები ემთხვევა, შემდეგ ჩაწერეთ მხოლოდ დანიშვნა.

დანიშვნასთან ერთად ყველაფერი ნათელია: ჩვენ ვაძლევთ ზუსტად ავტომატური აქტივობის ტიპს. მაგალითად, თუ ჩვენ ვქმნით წარმოების აღრიცხვის სისტემას, მაშინ ღირს აღრიცხვის ავტომატური ტიპების, ავტომატური ოპერაციების, ასევე ობიექტების მოტანა, რომელთა ავტომატიზაციაც მოსალოდნელია.

დანიშნულებით, ეს განსხვავებულია. მიზანი არის ის, რისთვისაც ჩვენ ვაკეთებთ პროექტს. ამას შეიძლება ეწოდოს ბიზნეს მიზნები. მე ხაზს ვუსვამ შემდეგ შესაძლო მიზნებს ავტომატიზაციის პროექტებისთვის:

1. გარე მოთხოვნების შესრულება (კანონის მოთხოვნები, სტანდარტი და ა.შ.)
2. ახლის ექსპლუატაციის უზრუნველყოფა ტექნოლოგიური პროცესი(მაგალითად, ვქმნით ონლაინ მაღაზიას, ვაწყობთ ახალ განყოფილებას, ახალ ბიზნესს).
3. საოპერაციო ხარჯების შემცირება (პერსონალის რაოდენობის შემცირება, გამომუშავების გაზრდა იგივე სიმძლავრის გამოყენებით, ეფექტურობის გაზრდა).
4. სამუშაოს ხარისხის გაუმჯობესება: შეცდომების რაოდენობის შემცირება, გადაწყვეტილების მიღების დაჩქარება.
5. რისკების შემცირება, საიმედოობის გაზრდა. ეს ეხება არა მხოლოდ ტექნიკურ მხარეს, არამედ საფრთხის აღმოფხვრას ავადმყოფობის ან ძირითადი, „შეუცვლელი“ თანამშრომლების სამსახურიდან გათავისუფლების შემთხვევაში.

GOST ასევე ამბობს, რომ აუცილებელია მიზნის მიღწევის შეფასების კრიტერიუმები, ანუ კონკრეტული ინდიკატორები. მაგალითად, ჩვენ გვყავს 3 ადამიანი დღეში მხოლოდ 20 შეკვეთას აგროვებს. სისტემის დანერგვის შემდეგ კი გვინდა ყველამ შეაგროვოს 20 შეკვეთა, ანუ სამჯერ მეტი. თუ იქ ასეთი მაჩვენებლები ცნობილია, მათ ამ პარაგრაფში წარმოგიდგენთ.

6. ნაწილი 3. „ავტომატიზაციის ობიექტის მახასიათებლები“ ​​/ გვ. 2.5 GOST 34.602-89/

ძალიან მნიშვნელოვანი და ამავე დროს ხშირად აღწერილი, ხშირად ფორმალურად განყოფილება. მიუხედავად იმისა, რომ, ჩემი აზრით, ეს არის ToR-ის ყველაზე მნიშვნელოვანი განყოფილება, ამის გარეშე ჩვენ უბრალოდ არ გვესმის, რა არის შექმნილი სისტემა.

ჯერ განვსაზღვროთ რა არის „ავტომატიზაციის ობიექტი“. თუ ჩვენ ავტომატიზირებთ საწყობს ან ქარხანას, ბუღალტრულ განყოფილებას, მაშინ ყველაფერი გასაგებია. მაგრამ თუ, მაგალითად, შევქმნით ახალს სოციალური ქსელი, მაშინ ობიექტი არ არსებობს. მაგრამ სინამდვილეში, ობიექტი უფრო სავარაუდოა, რომ ნიშნავს ავტომატიზებულ პროცესებს. და თუნდაც საწყობის შემთხვევაში, ჩვენ არ ვახორციელებთ თვით საწყობის ავტომატიზირებას (როგორ შეიძლება ავტომატიზირება მოახდინოს ყუთების შენახვა?), არამედ საწყობის პროცესებს.

თუ ამ განყოფილებას ფორმალურად მიჰყვებით, ის ძალიან წააგავს სისტემის დანიშნულების აღწერას და კიდევ ერთი წყლის ტბა გამოჩნდება ToR-ში, მაგრამ გაუგებარი იქნება, რა უნდა გააკეთოს სისტემამ.

ეს განყოფილება უნდა შეიცავდეს:

1. დამკვეთის აღწერა: მომხმარებლის საქმიანობა, ფილიალების რაოდენობა, თანამშრომლები. რა თქმა უნდა, აუცილებელია მომხმარებლის დახასიათება იმ ნაწილში, რომელიც პირდაპირ ეხება შექმნილ სისტემას.
2. ინფორმაცია სისტემის მომხმარებლების შესახებ: მომხმარებლების ტიპები, რა როლს ასრულებს სისტემა სხვადასხვა მომხმარებლისთვის.
3. ავტომატური ობიექტების აღწერა. მაგალითად, თუ ჩვენ ვახორციელებთ საწყობის ავტომატიზაციას, უნდა აღვწეროთ, თუ რამდენად დიდია ის, რამდენი დერეფანი, რა ფართო დერეფანი, რა თაროები, არის თუ არა ცალკე შეკრების ადგილი, რამდენი ადამიანი მუშაობს და რა მოვალეობები აქვთ. შემდეგ გავიგებთ, კონკრეტულად რას ვაწარმოებთ ავტომატიზაციას, როგორი უნდა იყოს საწყობის პროცესი და რა აღჭურვილობა გამოიყენება.
4. ავტომატური პროცესების აღწერა. რა თქმა უნდა, არ არის აუცილებელი პროცესების დეტალური აღწერა TOR-ში. მაგრამ ზოგადი სცენარების მიცემა აუცილებელია. მხოლოდ ამის შემდეგ ხდება ჩვენთვის ნათელი, რა ფუნქციები უნდა იყოს ხელმისაწვდომი.
5. დოკუმენტების ჩამონათვალი, რომელიც შეიცავს დეტალური აღწერაავტომატიზაციის ობიექტი.

მქონია შემთხვევები, როდესაც ამ განყოფილების აღწერას დასჭირდა TOR-ის განვითარების დროის ნახევარზე მეტი, რადგან დიდი დრო და სკრუპულოზური დრო სჭირდება სხვადასხვა ინფორმაციის შეგროვებას, გაანალიზებას და ყურადღებით აღწერას.

7. ნაწილი 4 სისტემური მოთხოვნები

TOR-ში არის ერთი გიგანტური განყოფილება GOST 34-ის მიხედვით: განყოფილება 4 "სისტემის მოთხოვნები". მას აქვს სამი ქვეგანყოფილება:

• ზოგადი სისტემის მოთხოვნები.
• მოთხოვნები სისტემის მიერ შესრულებული ფუნქციების (დავალებების) მიმართ.
• მოთხოვნები გირაოს ტიპებზე.

ამ ქვეპუნქტებს ცალკე განვიხილავთ.

7.1. ქვეპუნქტი 4.1. „მოთხოვნები მთლიანად სისტემის მიმართ“ / გვ. 2.6.1 GOST 34.602-89/

4.1 ქვეთავში „მოთხოვნები მთლიანად სისტემის მიმართ“ მოცემულია ე.წ. სხვადასხვა პარტიები.

სხვათა შორის, როგორც უკვე აღვნიშნეთ, შესაძლებელია ქვეგანყოფილებების დამატება და გამოტოვება. აქედან გამომდინარე, აქ მოცემული ნუმერაცია არის მიახლოებითი, ის ემსახურება სტატიის შიგნით ორიენტაციას.

7.1.1. პუნქტი 4.1.1. „მოთხოვნები სისტემის სტრუქტურისა და ფუნქციონირებისთვის“ / გვ. 2.6.1.1 GOST 34.602-89/

ეს პუნქტი საკმაოდ ვრცელია, ის უნდა მისცეს ზოგადი იდეასისტემის არქიტექტურის შესახებ. მოდით გავაანალიზოთ ეს მოთხოვნები უფრო დეტალურად.

1. ქვესისტემების ჩამონათვალი, მათი დანიშნულება და ძირითადი მახასიათებლები, მოთხოვნები იერარქიის დონეების რაოდენობაზე და სისტემის ცენტრალიზაციის ხარისხზე.

ამ დროს მე ჩვეულებრივ ციტირებს:

• შიდა სტრუქტურის სქემა (აპლიკაციის სერვერი, მონაცემთა შენახვის მოდული, სქელი კლიენტი მშობლიური აპლიკაციის სახით, საჯარო ვებ აპლიკაცია, ადმინისტრაციული პანელი, მობილური აპლიკაციები, ანგარიშის სერვერი) და გარე, დაკავშირებული სისტემები (სხვა მომხმარებელთა სისტემები, SMTP ფოსტის სერვერი, SMS დისტრიბუციის სერვისი, აკვეირინგ ბანკი, ონლაინ სალარო, კარტოგრაფიული სერვისი, მისამართის სერვისი, მისამართის გადამოწმების სერვისი ელფოსტადა ასე შემდეგ.);
• მოთხოვნები შემცირებული სტრუქტურის ელემენტებზე.

თუ თქვენ გეგმავთ მიკროსერვისის არქიტექტურას, მაშინ აზრი აქვს სერვისების ფუნქციონირების ჩამოთვლას და აღწერას.

სიცხადისთვის სასურველია მიმაგრება ბლოკის დიაგრამასისტემა მისი ნაწილების და მიმდებარე სისტემების აღნიშვნით, როგორც ნაჩვენებია ქვემოთ მოცემულ მაგალითებში.

... ან ასე:

2. მოთხოვნები სისტემის კომპონენტებს შორის ინფორმაციის გაცვლის მეთოდებსა და საშუალებებზე.

3. მოთხოვნები დაკავშირებულ სისტემებთან შექმნილი სისტემის ურთიერთკავშირების მახასიათებლებზე, მოთხოვნები მის თავსებადობაზე, ინფორმაციის გაცვლის ინსტრუქციების ჩათვლით (ავტომატურად, დოკუმენტების გაგზავნით, ტელეფონით და ა.შ.)

დღევანდელ გარემოში, ურთიერთქმედების უმეტესობა ხდება HTTP(S) პროტოკოლით. ეტყობა სხვა არაფერია დასაწერი. თუმცა, ეს ელემენტები შეიძლება იყოს იმდენად დიდი, რომ დანართებში იყოს შეტანილი. ისინი უნდა შეიცავდეს შემდეგ ინფორმაციას:

• გადაცემული ინფორმაციის სია, სულ მცირე ზოგადი აღწერა, რათა ზოგადად გავიგოთ, რატომ ვაერთიანებთ კონკრეტულ სისტემას;
• პროტოკოლების აღწერა (ან აღწერილობის ბმულები), განსაკუთრებით მოწყობილობების დამაკავშირებელ შემთხვევაში;
• ლოკალური ქსელების სტრუქტურა;
• მონაცემთა საჭირო სიჩქარე;
• მობილური ინტერნეტით ან WiFi-ით სარგებლობა;
• მონაცემთა გადაცემის არაავტომატური მეთოდების აღწერა.

4. მოთხოვნები სისტემის მუშაობის რეჟიმებზე.
ოპერაციულ რეჟიმებს შეიძლება ჰქონდეს რამდენიმე კლასიფიკაცია:

• მზადაა ოპერაციისთვის:ნორმალური რეჟიმი, გადაუდებელი რეჟიმი, შენარჩუნების რეჟიმი (მაგალითად, საგანგებო რეჟიმში, საიტზე უნდა იყოს ეკრანი, დატვირთვა უნდა გადავიდეს სხვა სერვერზე, სპეციალური შეტყობინებები უნდა იყოს ნაჩვენები API-ით ამ სისტემაში წვდომისას, ზოგიერთი ფუნქცია შეიძლება იყოს ხელმისაწვდომი იყოს შენარჩუნების რეჟიმში);
• სისტემის ნაწილების მუშაობისთვის მზადყოფნის მიხედვით:როგორ უნდა ფუნქციონირებდეს სისტემა, თუ, მაგალითად, ერთ-ერთი გარე ან შიდა სერვისი მიუწვდომელია;
• სამუშაო გრაფიკის მიხედვით: 24/7 ან ხუთი დღე (მინიმუმ ტექნიკური მხარდაჭერის მუშაობა ამაზეა დამოკიდებული);
• თუ შესაძლებელია, შეცვალეთ მონაცემები:ნახვის ან რედაქტირების რეჟიმი;
• მონაცემთა ხელმისაწვდომობის დონით და სისტემის ოპერაციებით:ავტორიზებული მომხმარებლის რეჟიმი, ადმინისტრატორის რეჟიმი, სტუმრის რეჟიმი (არაავტორიზებული მომხმარებლებისთვის);
• სისტემაში წვდომის საშუალებით:ვებ აპლიკაციის საშუალებით, სქელი კლიენტის მეშვეობით, მობილური აპლიკაციის საშუალებით (უნდა დაეთანხმოთ, რომ ფუნქციონირება შეიძლება ოდნავ განსხვავდებოდეს, ეს შეზღუდვები შეიძლება აღწერილი იყოს აქ);
• ურთიერთქმედების ტიპის მიხედვით:ინტერაქტიული (ინტერფეისის საშუალებით), ურთიერთქმედება კონფიგურაციის ფაილებში პარამეტრების შეცვლით ან სხვაგვარად, არაავტომატური (მაგალითად, ინფორმაცია გადაეცემა სხვა თანამშრომელს, რომელიც შეაქვს მონაცემებს სისტემაში, აღებულია ხელით წაკითხვები);
• ავტომატიზაციის ხარისხის მიხედვით:ავტომატური ან ნახევრად ავტომატური რეჟიმი, "მრჩეველი რეჟიმი";
• აპის ხილვადობა:დიალოგის ან ფონის რეჟიმი;
• სისტემაზე შესაძლო ზემოქმედების შესახებ:რეგულარული, ვარჯიში, ტესტის რეჟიმები.

5. სისტემის დიაგნოსტიკის მოთხოვნები.

მოთხოვნები უწყვეტი ან პერიოდული დიაგნოსტიკისთვის უნდა დაწესდეს სისტემებზე, რომლებიც დაფუძნებულია მიკროსერვისის (განცალკევებული) არქიტექტურაზე, სისტემებზე, რომლებიც მოიცავს აღჭურვილობას: სენსორებს, საკონტროლო სისტემებს, ტერმინალებს და ა.შ. რა თქმა უნდა, თუ შემუშავებულია მხოლოდ პროგრამული უზრუნველყოფა, რომელიც მუშაობს ერთ სერვერზე, განსაზღვრული მოთხოვნებიზედმეტი: და ასე რომ თქვენ იცით, თუ რამე შეწყვეტს მუშაობას.

6. სისტემის განვითარების, მოდერნიზაციის პერსპექტივები.

როგორც ჩანს, რა კავშირშია სისტემის განვითარების პერსპექტივები ქვეთავთან „სისტემის სტრუქტურისა და ფუნქციონირების მოთხოვნები“? მაგრამ წარმოიდგინეთ, ახლა თქვენ ქმნით ალფა ვერსიას 100 ადამიანისთვის და ერთ წელიწადში გსურთ გყავდეთ მილიონზე მეტი ერთდროულად მომხმარებელი მსოფლიოს სხვადასხვა კუთხეში. მაშინ დაუყოვნებლივ დაგჭირდებათ კლასტერული არქიტექტურის უზრუნველყოფა შექმნის ეტაპზე.

ან ახლა თქვენ მუშაობთ ერთი ორგანიზაციიდან და ექვს თვეში რამდენიმე მათგანი იქნება, ასე რომ თქვენ უნდა განჭვრიტოთ გაფართოების შესაძლებლობა.

სხვა სიტყვებით რომ ვთქვათ, ამ განყოფილებაში შეგიძლიათ დაწეროთ მოდერნიზაციის ყველა პერსპექტივა, მაგრამ განსაკუთრებით აღნიშნეთ ის, რაც აუცილებლად იმოქმედებს არქიტექტურაზე.

7.1.2. პუნქტი 4.1.2. „პერსონალის რაოდენობისა და კვალიფიკაციის მოთხოვნები“ /გვ. 2.6.1.2 GOST 34.602-89/

როგორც უკვე აღვნიშნეთ, ნებისმიერი ავტომატიზირებული სისტემა შედგება „პერსონალისგან და მისი საქმიანობის ავტომატიზაციის ინსტრუმენტების ნაკრებისგან“. აქედან გამომდინარე, TOR განსაზღვრავს პერსონალის მოთხოვნებს და მათ კვალიფიკაციას.

თუ თქვენ ავტომატიზირებთ კონკრეტულ საწარმოო ხაზს, მაშინ იცით თანამშრომლების რაოდენობა. მაგრამ ხშირ შემთხვევაში ეს დამოკიდებულია შესრულებული სამუშაოს მოცულობაზე. ამიტომ მიუთითეთ პოზიციები, სამუშაო განრიგი, სამუშაოს აღწერა (დაშვების უფლებების მინიჭებისთვის) და სავარაუდო კვალიფიკაცია. მინიმუმ, დაგჭირდებათ სისტემის ადმინისტრატორი და ოპერატორი, ხშირად მოდერატორი. შესაძლებელია, რომ მოგიწიოთ რამდენიმე ტიპის ოპერატორის უზრუნველყოფა სხვადასხვა დონის წვდომით.

გასაგებია, რომ პერსონალის მიმართ მოთხოვნებს ხშირად აწესებს მომხმარებელი, რატომ აყენებს მათ მაშინ? მაგრამ, ჯერ ერთი, ჩვენ უკვე ვთქვით, რომ TOR შედგენილია ორივე მხარისთვის და მეორეც, ამ გზით კონტრაქტორი დაცული იქნება: დაქირავების პირობა არ არის დაკმაყოფილებული, მაშინ რა სურს მომხმარებელს, თუ სისტემა არ არის დანერგილი?

7.1.3. პუნქტი 4.1.3. „მოთხოვნები დანიშვნის ინდიკატორებთან“ / გვ. 2.6.1.3 GOST 34.602-89/

ამ ქვეგანყოფილებაში ხშირად იწერება ის, რაც თქვენს გულს სურს, რადგან შესაძლო ინდიკატორების სია არ არის GOST-ის ტექსტში და მათი პოვნა ღია წყაროებში თითქმის შეუძლებელია. გთხოვთ გაითვალისწინოთ, რომ GOST-ში მოცემული „ადაპტაციის ხარისხი“, „მოდერნიზაციის საზღვრები“ და „ალბათურ-დროითი მახასიათებლები“, პირველ რიგში, მითითებულია ACS-სთვის (ავტომატური კონტროლის სისტემა) და მეორეც, მათი გაზომვა საკმაოდ რთულია. ამრიგად, ეს მახასიათებლები ყოველთვის არ არის შესაფერისი.

თუმცა, თავად ტექსტში „მიზნის ინდიკატორები“ განისაზღვრება, როგორც „პარამეტრები, რომლებიც ახასიათებენ სისტემის მიზნის შესაბამისობას“. თანამედროვე კომპიუტერულ სისტემებში, რაოდენობრივი მნიშვნელობები, რომლებიც ახასიათებს ამ სისტემას, ძირითადად დაკავშირებულია შესრულებასთან და მონაცემთა შენახვის შესაძლებლობებთან.

სამიზნე ინდიკატორები მოიცავს:

• სისტემაში ერთდროულად მომუშავე მომხმარებლების რაოდენობა;
• სერვერზე ერთდროულად შესრულებული მოთხოვნების რაოდენობა;
• განხორციელებული (რეგისტრირებული) ტრანზაქციების რაოდენობა დროის ერთეულზე;
• პასუხის დრო სხვადასხვა რაოდენობის ერთჯერადი მოთხოვნით და მუშა მომხმარებლებთან, დამუშავებული მონაცემების განსხვავებული მოცულობით (განსაკუთრებით ანგარიშებში ძიების და გაერთიანებისას);
• შენახული მონაცემების რაოდენობა (კერძოდ, სურათები და ვიდეო);
• მაქსიმალური დატვირთვის მიღწევისას დამატებითი გამოთვლითი სიმძლავრის დაკავშირების დრო;
• დამატებითი სიმძლავრის დაკავშირების დრო შენახული მონაცემების რაოდენობის მნიშვნელოვანი ზრდით.

ყველა ეს მახასიათებელი გავლენას ახდენს სერვერის აპარატურის არჩევანზე, აპლიკაციის სერვერის არქიტექტურაზე და DBMS-ზე, რელაციურ ან არარელაციურ DBMS-ზე, მიკროსერვისებზე და ა.შ.

7.1.4. პუნქტი 4.1.4. „სანდოობის მოთხოვნები“ /გვ. 2.6.1.4 GOST 34.602-89/

GOST-ის ტექსტი საკმარისად დეტალურად აღწერს რა უნდა იყოს მითითებული სანდოობის მოთხოვნებში. მიუხედავად ამისა, ამ სტანდარტით გათვალისწინებული საიმედოობის უზრუნველყოფის მიდგომის გასაგებად, უნდა შეისწავლოთ 27 სერიის GOST. უპირველეს ყოვლისა, ღირს გაეცნოთ ტერმინოლოგიას: ეს საკმარისი იქნება საიმედოობის კონცეფციის გასაგებად. , როგორ იზომება და რა არის გათვალისწინებული. ამიტომ, მიმართეთ GOST 27.002-89. ”სანდოობა ტექნოლოგიაში. Ძირითადი ცნებები. ტერმინები და განმარტებები“.

მთავარი კონცეფცია, რომელიც შეიძლება გამოყენებულ იქნას ავტომატიზირებულ სისტემებზე, არის ხელმისაწვდომობის მაჩვენებელი: 99%, 99,9%, 99,99%. „ცხრათა“ თითოეული რიცხვი უზრუნველყოფილია გარკვეული ზომებით.

რა ტექნიკურ გადაწყვეტილებებზე შეიძლება გავლენა იქონიოს ამ მოთხოვნებმა? ეს მოიცავს სარეზერვო სიმძლავრის რაოდენობას (ისინი განსხვავებულია) და ადგილზე ტექნიკური პერსონალის ხელმისაწვდომობას და არა მხოლოდ უწყვეტი კვების წყაროების გამოყენებას, არამედ დიზელის გენერატორების გამოყენებას, ასევე კავშირს ორი დამოუკიდებელი წყაროდან (კავშირი ელექტროენერგიაზე. ბადეები სანდოობის I ან II კატეგორიის მიხედვით).

7.1.5. პუნქტი 4.1.5. „უსაფრთხოების მოთხოვნები“ /გვ. 2.6.1.5 GOST 34.602-89/

ეს ქვეპუნქტი აღწერს უსაფრთხოების მოთხოვნებს აღჭურვილობის მუშაობისთვის (ინსტალაცია, ექსპლუატაცია და ექსპლუატაცია). ახლა ამ მოთხოვნებს უწოდებენ შრომის დაცვას და შეიცავს მე -12 სერიის GOST-ებს (SSBT - შრომის უსაფრთხოების სტანდარტების სისტემა). TOR-ში საკმარისია კიდევ ერთხელ ჩამოთვალოთ ეს სექციები, თუ ვინმე აპირებს სერიოზულად დაკავდეს უსაფრთხოებასთან.

7.1.6. პუნქტი 4.1.6. "მოთხოვნები ერგონომიკისა და ტექნიკური ესთეტიკისთვის" / გვ. 2.6.1.6 GOST 34.602-89/

აქ არის GOST-ის მოთხოვნები: ”ერგონომიკისა და ტექნიკური ესთეტიკის მოთხოვნები მოიცავს AS ინდიკატორებს, რომლებიც აკონკრეტებენ ადამიანისა და მანქანის ურთიერთქმედების საჭირო ხარისხს და პერსონალის სამუშაო პირობებს კომფორტს.”

როგორც წესი, ამ ეტაპზე წერენ, რომ სისტემას უნდა ჰქონდეს მოსახერხებელი და ლამაზი ინტერფეისი. მაგრამ როგორ გავზომოთ კომფორტი და სილამაზე? ამიტომ, ჩვენ ან გამოვტოვებთ ამ მოთხოვნას, ან ვამბობთ, რომ ინტერფეისი შეესაბამება მოგვიანებით შემუშავებულ დიზაინს, ან ვაძლევთ სტანდარტებს, მაგალითად, მობილური აპლიკაციების შემუშავების ე.წ. მასალის დიზაინიანდროიდისთვის და ადამიანის ინტერფეისის სახელმძღვანელო მითითებები iOS-ისთვის.

თქვენ ასევე შეგიძლიათ მიუთითოთ გადასვლების (დაწკაპუნებების) მაქსიმალური რაოდენობა ჩვენთვის განსაკუთრებით მნიშვნელოვანი გარკვეული ფუნქციების განხორციელებისას, მონაცემთა ძიების საშუალო სიჩქარე და ა.შ.

7.1.7. პუნქტი 4.1.7. „მობილურ დინამიკებისთვის ტრანსპორტირებადობის მოთხოვნები“ /გვ. 2.6.1.7 GOST 34.602-89/

ვთქვათ, რაღაც მოძველებული მოთხოვნა. ახლა ისინი არ ატარებენ სერვერებს სატვირთო მანქანებზე, როგორც ამას აკეთებდნენ დიდი კომპიუტერებით. თუმცა, წარმოიდგინეთ, რომ თქვენ გაქვთ რაიმე სახის სუპერ დაცვა, შიდა მარყუჟი DMZ-ის უკან და ... ლეპტოპის საშუალებით დისტანციურად მუშაობის აუცილებლობა. დიახ, VPN კონფიგურირებულია ნებისმიერ დროს, მაგრამ უმჯობესია, თუ ეს აისახება ადმინისტრაციის სახელმძღვანელოში, ხოლო შესაძლებლობა თავად არის გათვალისწინებული ქსელის კონფიგურაციით.

7.1.8. პუნქტი 4.1.8. „მოთხოვნილება ექსპლუატაციის, მოვლის, შეკეთებისა და შენახვის შესახებ“ /გვ. 2.6.1.8 GOST 34.602-89/

ეს მოთხოვნები ვრცელდება კომპლექსის მოვლაზე ტექნიკური საშუალებები(სერვერები, ბუხარი, გადამრთველები, სამუშაო სადგურები და ა.შ.) თუ მოწყობილობა საჭიროებს რაიმე განსაკუთრებულ მოვლას, მაშინ ეს უნდა იყოს აღწერილი ამ განყოფილებაში. მაგალითად, თქვენ გაქვთ სპეციალური მოწყობილობა, რომელიც თვეში ერთხელ საჭიროებს დაკალიბრებას.

7.1.9. პუნქტი 4.1.9. „ინფორმაციის დაცვის მოთხოვნები არაავტორიზებული წვდომისგან“ / გვ. 2.6.1.9 GOST 34.602-89/

ინფორმაციის არაავტორიზებული წვდომისგან დაცვის თემა საკმაოდ ვრცელია, ისევე როგორც მისი უზრუნველყოფის ღონისძიებები. რა თქმა უნდა, როდესაც საქმე ეხება წვდომას პირადი ფართობივებსაიტზე და ამ საიტის ადმინისტრაციულ პანელში, ავტორიზაციის, პაროლის სირთულის და როლებზე დაფუძნებული წვდომის მოდელის მოთხოვნები საკმარისია. მაგრამ თუ ფინანსური სისტემა ან სისტემა სახელმწიფო საჭიროებებს, არის სპეციალური მოთხოვნები.

მნიშვნელოვანია აღინიშნოს, რომ ეს ქვეპუნქტი ითვალისწინებს არა მხოლოდ ზომებს, რომლებიც უნდა იქნას გამოყენებული სისტემის განვითარებისას, არამედ მისი ფუნქციონირებისთვის.

მაგალითად, ფინანსური სისტემებისთვის, უნდა იყოს გამოყენებული გადახდის ბარათების ინდუსტრიის მონაცემთა უსაფრთხოების სტანდარტი (PCI DSS). სისტემებისთვის, რომლებშიც ინახება პერსონალური მონაცემები, რუსეთის ფედერაციის მთავრობის 2012 წლის 1 ნოემბრის No1119 დადგენილება „პერსონალური მონაცემების საინფორმაციო სისტემებში მათი დამუშავებისას პერსონალური მონაცემების დაცვის მოთხოვნების დამტკიცების შესახებ“. შეიძლება არსებობდეს სხვა სტანდარტები თქვენს საგანში.

ზოგადად, დაცვის საშუალებები შეიძლება დაიყოს შემდეგ ტიპებად:

1. შექმნილი პროგრამული პროდუქტით გათვალისწინებული საშუალებები.
2. სისტემური ადმინისტრატორის მიერ მოწოდებული ზომები.
3. ფიზიკური დაცვის ზომები.
4. ზოგადი ორგანიზაციული ღონისძიებები.
5. პროგრამული უზრუნველყოფის შემუშავების პროცესში მიღებული ზომები.

1. შექმნილი პროგრამული პროდუქტით გათვალისწინებული დაცვის საშუალებები:

• მომხმარებლისთვის პაროლის მოთხოვნა, განსაკუთრებით ადმინისტრატორის როლის მქონე მომხმარებლებისთვის.
• წვდომის როლური მოდელის განხორციელება.
• გასაღების გამოყენების მოთხოვნა ელექტრონული ხელმოწერაკრიტიკული ოპერაციების შესასრულებლად.
• გარე სისტემებთან ურთიერთქმედებისთვის პასუხისმგებელი პროგრამული კომპონენტების გადატანა დემილიტარიზებულ ზონაში (DMZ).
• ღონისძიებებისა და მომხმარებლის ქმედებების რეგისტრაციის უზრუნველყოფა.

2. სისტემური ადმინისტრატორის მიერ მოწოდებული ზომები:

• Firewall-ების (firewalls) გამოყენება.
• გამოყენებული სერვისებისა და პროტოკოლების დოკუმენტაცია და მონიტორინგი.
• დემილიტარიზებული ზონის (DMZ) კონფიგურაცია.
• პორტატული კომპიუტერების გამოყენების წესებთან შესაბამისობის მონიტორინგი: შიდა ქსელთან დაკავშირება, firewalls-ის გამოყენება.
• გამორთეთ ნაგულისხმევი ანგარიშები აღჭურვილობისა და სისტემების ქსელთან დაკავშირებამდე.
• უსადენო მოწყობილობის დაყენება: დააყენეთ პაროლები და შეცვალეთ წვდომის ნაგულისხმევი პარამეტრები.
• დააინსტალირეთ განახლებები, რომლებიც ასწორებს იდენტიფიცირებულ აპარატურულ და პროგრამულ ხარვეზებს.
• უსაფრთხოების უზრუნველყოფა სისტემაში დისტანციური წვდომისას (მაგალითად, VPN-ის გამოყენებით).
• ანტივირუსული პროგრამული უზრუნველყოფის ინსტალაცია, განახლება და მუშაობის მონიტორინგი.
• განახორციელეთ პერიოდული ქსელის სკანირება და სკანირება მნიშვნელოვანი ცვლილებების განხორციელების შემდეგ.
• თითოეული თანამშრომლისთვის უნიკალური ანგარიშის მინიჭება, შეწყვეტილი თანამშრომლების წაშლილი ანგარიშების პერიოდული შემოწმება, პაროლების შეცვლა. ელექტრონული ხელმოწერის ჟეტონების გაცემა და რეგისტრაცია.
• მონაცემთა ბაზაში წვდომის შეზღუდვების კონფიგურაცია.
• დროის სინქრონიზაციის კონტროლი ყველა სერვერზე და სამუშაო სადგურზე (მოვლენის ჟურნალებში ჩაწერილი დროის სისწორის უზრუნველსაყოფად).
• მოვლენის ჟურნალის დაყენება.
• უკაბელო წვდომის წერტილებისა და სხვა აღჭურვილობის პერიოდული ინვენტარიზაცია, დაინსტალირებული პროგრამული უზრუნველყოფა.

3. ფიზიკური დაცვის ზომები:

• კრიტიკულ ობიექტებზე წვდომის შეზღუდვა.
• ქსელის კონექტორების გამორთვა საზოგადოებრივ ადგილებში.
• ვიდეოსათვალთვალო კამერების დაყენება კრიტიკულ ობიექტებზე.

4. ზოგადი ორგანიზაციული ღონისძიებები:

• უსაფრთხოების პოლიტიკის დამტკიცება და პერსონალის პერიოდული სწავლება ინფორმაციული უსაფრთხოების წესებში.
• უსაფრთხოების ინციდენტებზე რეაგირების პროცედურის განხორციელება.
• ეკრანზე ჩვენების შემოწმება ან სენსიტიური მონაცემების მოხსენება.
• ბეჯების გაცემა ყველა ვიზიტორზე, ვიზიტორთა თანმხლები კრიტიკულ ადგილებში ყოფნისას.
• დაქირავებული თანამშრომლების ყოვლისმომცველი შესწავლა.
• პროგრამულ უზრუნველყოფასთან და აპარატურასთან დაკავშირებული სერვისების მიმწოდებელი ორგანიზაციების მიერ უსაფრთხოების უზრუნველყოფა.

5. პროგრამული უზრუნველყოფის დამუშავების პროცესში მიღებული ზომები:

• პასუხისმგებელი პირების მიერ ცვლილებების კონტროლი პროგრამირების კოდი, კოდის შემოწმება ინფორმაციული უსაფრთხოების წესებთან შესაბამისობისთვის (ბუფერის გადინების კონტროლი, შეცდომების სწორი დამუშავება, საიტის სკრიპტების შემოწმება, წვდომის მექანიზმებში შეცდომებზე და ა.შ.)
• ძლიერი კრიპტოგრაფიის გამოყენება.
• დაიცავით უსაფრთხოების წესები საჯარო ვებ აპლიკაციებისთვის.
• თითოეული ცვლილების გაუქმების პროცედურის შემუშავება.
• ცვლილებების დოკუმენტაცია.

7.1.10. პუნქტი 4.1.10. „ინფორმაციის უსაფრთხოების მოთხოვნები ავარიების დროს“ /გვ. 2.6.1.10 GOST 34.602-89/

ამ განყოფილებაში მოცემულია შესაძლო ავარიების და წარუმატებლობის სია, რომელშიც დაცული უნდა იყოს ინფორმაციის უსაფრთხოება. ეს მოვლენები შეიძლება შეიცავდეს:

• დენის დაკარგვა;
• სერვერის უკმარისობა;
• შენახვის მოწყობილობის გაუმართაობა (მყარი დისკი).

7.1.11. პუნქტი 4.1.11. „გარე გავლენისგან დაცვის მოთხოვნები“ /გვ. 2.6.1.11 GOST 34.602-89/

ეს განყოფილება სასარგებლო იქნება, თუ სერვერები, სამუშაო სადგურები და სხვა აღჭურვილობა მოთავსებულია ცივ საწყობში ან, პირიქით, სამრეწველო ფართებიცხელი, მტვრიანი ან ნესტიანი ადგილები. ასევე ზოგჯერ ღირს ვიბრაციის, რადიაციის ან სხვა გავლენის გათვალისწინება.

7.1.12. ქვეპუნქტი 4.1.12. „საპატენტო სიწმინდის მოთხოვნები“ /გვ. 2.6.1.12 GOST 34.602-89/

თუ ეჭვი გეპარებათ, რომ გამოიყენებთ სხვა ქვეყნებში (ან ჩვენს ქვეყანაში) დაპატენტებულ ტექნოლოგიას და პატენტის მფლობელს შეუძლია პრეტენზია შეიტანოს სისტემის მფლობელის წინააღმდეგ, ეს პუნქტი მიუთითებს იმ ქვეყნების ჩამონათვალს, სადაც უნდა შეამოწმოთ. პატენტის სისუფთავე.

7.1.13. პუნქტი 4.1.13. „სტანდარტიზაციისა და გაერთიანების მოთხოვნები“ / გვ. 2.6.1.13 GOST 34.602-89/

ეს პუნქტი ასევე იშვიათად შეიცავს ტექნიკურ ინსტრუმენტებში პროგრამულ ინსტრუმენტებთან დაკავშირებით. მასში მითითებულია როგორც მოთხოვნები კონკრეტული ტექნოლოგიების გამოყენებისა და ერთიანი ფორმებიდოკუმენტები და კლასიფიკატორები.

ეს აღწერა განსაკუთრებით მნიშვნელოვანია, თუ თქვენ გაქვთ კონკრეტული მოთხოვნები გამოყენებული ფრეიმორების, დანამატების, პროტოკოლების, მოწყობილობების, მათემატიკური ალგორითმების, მესამე მხარის პროგრამული უზრუნველყოფის და ა.შ. მიმართ. უბრალოდ დაიმახსოვრე, რომელ ნაწილში და რა მიზნებისთვის უნდა იქნას გამოყენებული ეს ხელსაწყოები.

ასევე, ზოგჯერ გარკვეული კლასების სისტემებში ჩვეულებრივია მონაცემთა გაცვლის გარკვეული პროტოკოლების გამოყენება. მაგალითად, OCG სტანდარტები გამოიყენება გეოგრაფიულ საინფორმაციო სისტემებს შორის მონაცემთა გაცვლისთვის, ხოლო OCPP სტანდარტები გამოიყენება ელექტრო მანქანების დამტენი სადგურების მართვისთვის.

7.1.14. პუნქტი 4.1.14. „დამატებითი მოთხოვნები“ /გვ. 2.6.1.14 GOST 34.602-89/

ეს პუნქტი უნდა წაიკითხოთ GOST-ის ტექსტში. მას კომენტარები არ სჭირდება.

7.2. ქვეპუნქტი 4.2. „მოთხოვნები სისტემის მიერ შესრულებული ფუნქციების (დავალებების) მიმართ“ /გვ. 2.6.2 GOST 34.602-89/

ეს განყოფილება ცენტრალურია თანამედროვე კომპიუტერული სისტემებისთვის. სინამდვილეში, სისტემა იქმნება გარკვეული ფუნქციების შესასრულებლად. ხშირად უცხოური სტანდარტების საფუძველზე შექმნილი TK და საერთოდ არანაირი სტანდარტი შეიცავს მხოლოდ ამ განყოფილებას.

7.2.1. ფუნქციური აღწერის სტრუქტურა

პირველ რიგში, განიხილეთ სისტემის ფუნქციური მოთხოვნების სტრუქტურა: ქვესისტემა - ფუნქციების ერთობლიობა - ფუნქცია - ამოცანა. ამოცანა ფუნქციის ნაწილია და დავალება შეიძლება აღწერილი იყოს როგორც ცალკე ფუნქცია. მაგალითად, შესვლის ფუნქციისთვის, ჩვენ ერთ-ერთ ამოცანად ვიცავთ პაროლის შეყვანას. ჩვენ შეგვიძლია აღვწეროთ პაროლის შეყვანის პროცედურა, როგორც ცალკე ფუნქცია: სისწორის შემოწმება, პაროლის აღდგენა, მინიშნებების ჩვენება და ა.შ. კომპლექსი არის ის, რაც აერთიანებს ფუნქციებს. მაგალითად, „საბაზისო ინფორმაციის აღრიცხვა“, „აუქციონის ჩატარება“ და ა.შ. კომპლექსს აქვს ორი ან მეტი ფუნქცია.

თუ თქვენი სისტემა შედგება რამდენიმე ქვესისტემისგან, მაშინ მთავარ TOR-ში თქვენ უნდა მიაწოდოთ ქვესისტემების ფუნქციების სია და უკვე დეტალურად აღწეროთ ქვესისტემების ფუნქციონალური მოთხოვნები ცალკეულ TOR-ში ქვესისტემებისთვის (მათ ახლა ხშირად უწოდებენ ChTZ - კერძო ტექნიკური დავალება. ).

7.2.2. ფუნქციების სახეები მათი შესრულების თვალსაზრისით

სინამდვილეში, ყველა ფუნქცია (ან მათი ამოცანები; ფუნქცია შეიძლება შეიცავდეს რამდენიმე ამოცანას ერთდროულად) შეიძლება დაიყოს შემდეგ ტიპებად:

• ინფორმაციის შეყვანა. ზოგჯერ ასევე მოიხსენიება როგორც "ინფორმაციული აღრიცხვა".
• ინფორმაციის გამომავალი.
• ინფორმაციის ავტომატური დამუშავება.

7.2.3. ფუნქციების ტიპები მათი როლის მიხედვით

ფუნქციები შეიძლება იყოს ზოგადი ან სპეციალური. TO ზოგადი ფუნქციები, მაგალითად, ობიექტების სიებთან მუშაობა, ობიექტის ბარათთან მუშაობა, ინტერაქტიული რუქით მუშაობა. ეს ფუნქციები შეიძლება ეხებოდეს ყველა სპეციალურ ფუნქციას ან მის ნაწილს.

7.2.4. მოთხოვნაა და არა სცენარი

არ დაგავიწყდეთ, რომ TOR შეიცავს მოთხოვნებს სისტემისა და მისი შექმნის პროცესისთვის. არა სკრიპტები. TK პასუხობს კითხვას რა უნდა გააკეთოს სისტემამ. ტექნიკური პროექტი პასუხობს კითხვას HOW. თუ დაიწყებთ ტექნიკური განხორციელების დეტალურ აღწერას, მაშინ ჩაძირავთ დეტალებს და ვერ მოიტანთ სრული სიამოთხოვნები: ჩვენს ტვინს არ შეუძლია ერთდროულად იმუშაოს ფართო და დეტალურ რეჟიმში.

TOR და ტექნიკური პროექტის ფუნქციების სტრუქტურები შეიძლება ძალიან განსხვავებული იყოს: რამდენიმე ფუნქცია შეიძლება განხორციელდეს ერთ სცენარში და პირიქით.

7.2.5. ფუნქციური მოთხოვნების ფორმულირება

აქ მოცემულია რამდენიმე სახელმძღვანელო ფუნქციის აღწერილობის ფორმატირების შესახებ:

1. ფუნქციებისა და ამოცანების მოთხოვნები ჩვეულებრივ უნდა იყოს განთავსებული აპლიკაციაში. ამრიგად, დოკუმენტი ორგანულად იყოფა არაფუნქციურ და ფუნქციურ ნაწილებად. გარდა ამისა, აპლიკაციის დაბეჭდვა და ცალკე ნახვა ყოველთვის შესაძლებელია.
2. მოერიდეთ დიდ აბზაცებს. უმჯობესია, თუ მოთხოვნები დაიშლება აბზაცებად და ქვეპუნქტებად: უფრო ადვილია მათი აღქმა და მათი შესრულების კონტროლი (დაანიშნეთ ტიკი). თუ მოთხოვნილების ან ინფორმაციის ჩამონათვალია მოცემული, მიეცით იგი დანომრილი ან პუნქტიანი სიის სახით.
3. ფუნქციებისთვის, რომელთა დანიშნულებაც მათი სახელწოდებიდან არ ჩანს, აუცილებელია მიეთითოს მიზანი და გადასაჭრელი ამოცანა. IN წინააღმდეგ შემთხვევაში TK-ის შემდგენელიც კი რისკავს დაივიწყოს, რატომ აღწერა მან ესა თუ ის ფუნქცია.

7.2.6. ფუნქციის აღწერის მაგალითი

5.6. ავტომობილის რეგისტრაცია სისტემაში

გამოიყენება შემდეგი მოთხოვნები:

1) სისტემამ უნდა გაითვალისწინოს შემდეგი ზოგადი ინფორმაცია:

• სახელმწიფო სარეგისტრაციო ნიშანი (GRNZ);
• მფლობელის სახელი;
• მფლობელის მისამართი;
• მონაცემები ავტომობილის მონაცემების შეგროვების სერვისიდან (იხ. პუნქტი 3.3, დანართი B);
• შენიშვნა.

2) სისტემამ უნდა იძლეოდეს მგზავრობის საფასურის გადახდასთან დაკავშირებული შემდეგი ინფორმაციის გათვალისწინების შესაძლებლობა (აღნიშნული ინფორმაცია ინფორმაციული ხასიათისაა, პირდაპირ სარეგისტრაციო ბარათში შეცვლის შესაძლებლობას). მანქანასურვილისამებრ):

• მიმდინარე ავტომობილის კლასი (იხ. პუნქტი 3.3, დანართი A);
• მიმდინარე ტარიფი (იხ. პუნქტი 5.1, დანართი A);
• მიმდინარე კონტრაქტი (იხ. პუნქტი 5.5, დანართი A);
• ავტომობილის კლასი ყაზახეთის რესპუბლიკის შინაგან საქმეთა სამინისტროს სისტემის ინფორმაციის მიხედვით;
• ინფორმაცია პირადი ანგარიშისა და მისი სტატუსის შესახებ (იხ. პუნქტი 3.6, დანართი A);
• ინფორმაცია შემცირებული ტარიფის მქონე მანქანების რეესტრში ყოფნის შესახებ (იხ. პუნქტი 3.5, დანართი A).

3) სისტემამ უნდა დაუშვას ავტომობილის შესახებ ინფორმაციის რეგისტრაცია და შეცვლა შემდეგი გზებით:

• ხელით ოპერატორის მიერ;
• RFID ტეგების რეგისტრაციის სისტემიდან ინფორმაციის მიღებისას (იხ. პუნქტი 1.1, დანართი B);
• ავტომობილის იდენტიფიკაციისას GRNZ კამერის გამოყენებით.

4) სისტემაში ახალი სატრანსპორტო საშუალების რეგისტრაციისას სისტემამ უნდა მოითხოვოს სატრანსპორტო საშუალების შესახებ მონაცემები სატრანსპორტო საშუალების შესახებ მონაცემების მისაღებად სამსახურში (იხ. პუნქტი 3.3, დანართი B). შესაძლებელი უნდა იყოს ინდივიდუალური ავტომობილის მითითებული დეტალების განახლება.

7.3. ქვეპუნქტი 4.3. „მოთხოვნები გირაოს სახეობებზე“ /გვ. 2.6.3 GOST 34.602-89/

უსაფრთხოების ტიპების მოთხოვნების განყოფილება, როგორც წესი, ხშირად არის მოყვანილი, როგორც GOST-ის მიხედვით TK-ის ჭარბი ოდენობის მაგალითი. რაც შეეხება იმას, უნდა იყოს თუ არა ყველა განყოფილება და ქვესექცია, მათ ახსოვთ პროგრამული უზრუნველყოფის შესახებ, რომლისთვისაც უმეტეს შემთხვევაში უბრალოდ დასაწერი არაფერია.

სინამდვილეში, ეს არის ძალიან მნიშვნელოვანი ქვეგანყოფილება, თუმცა ყველას არ ესმის მისი მიზანი. იგი აღწერს პირობებს, რომელთა გარეშე შეუძლებელია განხორციელდეს არც განვითარება და არც ექსპლუატაციაში გაშვება. ეს პირობები აღწერილია, როგორც "უზრუნველყოფა".

ამ ქვეგანყოფილების კითხვისას აინტერესებს რას გულისხმობდნენ სტანდარტის შემდგენელები „მათემატიკური მხარდაჭერა“, „ენობრივი მხარდაჭერა“, „ინფორმაციული მხარდაჭერა“ და ა.შ. პასუხები უნდა მოიძიოთ GOST 34.003-90-ში, სადაც ყველა ეს ტერმინი გაშიფრულია.

7.3.1. პუნქტი 4.3.1 „მათემატიკური მხარდაჭერა“ /გვ. 2.6.3.1 GOST 34.602-89/

წარმოიდგინეთ სიტუაცია, როდესაც თქვენ უნდა შექმნათ სისტემა, რომელშიც გსურთ განახორციელოთ საუკეთესო მარშრუტის ავტომატური გაანგარიშება. მარშრუტის გამოთვლა ღილაკი შეიძლება მარტივი ჩანდეს, მაგრამ მის უკან შეიძლება იყოს ძალიან რთული მათემატიკური ალგორითმები და გამოთვლები. გასაგებია, რომ არ ღირს ასეთი ალგორითმების შემუშავება, ამას პროფესიონალი მათემატიკოსები აკეთებენ. ასეთი ალგორითმების შემთხვევაში დადგენილია მათი შემუშავების ან მზა გამოყენების მოთხოვნები.

7.3.2. პუნქტი 4.3.2 „ინფორმაციული მხარდაჭერა“ /გვ. 2.6.3.2 GOST 34.602-89/

აღწერილობის კითხვისას ამ მოთხოვნას GOST-ის ტექსტში იქმნება შთაბეჭდილება, რომ ეს არის იმის გამეორება, რაც უკვე ითქვა სხვა განყოფილებებში. მაგალითად, რატომ კიდევ ერთხელ აღწერეთ მოთხოვნები „სისტემაში მონაცემთა ორგანიზების შემადგენლობის, სტრუქტურისა და მეთოდების“ და „სისტემის კომპონენტებს შორის ინფორმაციის გაცვლის შესახებ“ მოთხოვნების შესახებ? მაგრამ ჩვენ კვლავ გვავიწყდება, რომ სისტემის ქვეშ მყოფი GOST-ის შემდგენელებს ჰქონდათ არა მხოლოდ პროგრამული უზრუნველყოფა, არამედ ორგანიზაციული ღონისძიებების მთელი ნაკრები.

დანერგვისას აწყდებით ისეთ სიტუაციას, რომ მომხმარებელმა არ მიაწოდა ოპერატორი თავის მხრივ, რომელიც შეაქვთ რაიმე მონაცემს სისტემაში და ამავდროულად გეუბნებათ, რომ სისტემა არ მუშაობს. საერთო სიტუაცია? მაგრამ თუ მოთხოვნა ეწერა TOR-ში მოცემული შეყვანაუზრუნველყოს, შესაძლებელი იქნებოდა მომხმარებლის უშუალოდ და ამ პუნქტში მოხვედრა. ან სამუშაოსთვის გჭირდებათ მისამართების გარკვეულ კლასიფიკატორზე წვდომა და მომხმარებელი არ მოგცემთ მას.

ამრიგად, ამ პუნქტში აზრი აქვს შემომავალი ინფორმაციისა და ინფორმაციის არაავტომატური ფორმით გადაცემული მოთხოვნების დაზუსტებას. ინფორმაციის ავტომატური დამუშავება, DBMS-ის გამოყენება, ინფორმაციის გაცვლა სისტემაში სრულად არის აღწერილი სხვა განყოფილებებში.

7.3.3. პუნქტი 4.3.3 „ენობრივი მხარდაჭერა“ /გვ. 2.6.3.3 GOST 34.602-89/

ეს პუნქტი ითვალისწინებს:

• მოთხოვნები პროგრამირების ენების გამოყენების შესახებ (თუ არსებობს კონკრეტული პრეფერენციები);
• ინტერფეისის ენა (რა ენები, მრავალენოვანი ინტერფეისი);
• საპროექტო გუნდების კომუნიკაციის ენა, თარგმანის მოთხოვნები;
• მონაცემთა შეყვანისა და გამოტანის სხვა მახასიათებლები, ასეთის არსებობის შემთხვევაში: დაშიფვრა, სისტემასთან მომხმარებლის ურთიერთქმედების არასტანდარტული მეთოდები.

7.3.4. პუნქტი 4.3.4 „პროგრამული უზრუნველყოფა“ / პუნქტი 2.6.3.4 GOST 34.602-89/

ამ პუნქტში მოცემულია შეძენილი პროგრამული ინსტრუმენტების სია, თუ ისინი განისაზღვრება TOR-ის განვითარების ეტაპზე.

7.3.5. პუნქტი 4.3.5 "ტექნიკური მხარდაჭერა" / გვ. 2.6.3.5 GOST 34.602-89/

ნებისმიერი საინფორმაციო სისტემა ვერ იმუშავებს აპარატურის, სერვერების, ქსელების და ა.შ. როგორც წესი, მიზანშეწონილია ტექნიკურ დიზაინში შეიტანოთ აღჭურვილობის სპეციფიკური მახასიათებლების განსაზღვრა, მაგრამ TOR-ში შეიძლება მიეთითოს სავარაუდო შემადგენლობა, რათა მომხმარებელს ჰქონდეს წარმოდგენა სამომავლო ხარჯებზე.

7.3.6. პუნქტი 4.3.6 „მეტროლოგიური მხარდაჭერა“ / გვ. 2.6.3.6 GOST 34.602-89/

თუ იგეგმება სისტემაში სენსორებისგან მონაცემების მიღება, მაშინ აუცილებელია იმის გაგება, თუ რა საზომი ინსტრუმენტები იქნება გამოყენებული, რა სიზუსტე უნდა იყოს უზრუნველყოფილი საზომი ხელსაწყოებიუნდა იყოს თუ არა ეს თანხები დამოწმებული და დამოწმებული.

7.3.7. პუნქტი 4.3.7 „ორგანიზაციული მხარდაჭერა“ /გვ. 2.6.3.7 GOST 34.602-89/

წარმოიდგინეთ, რომ თქვენ ქმნით სისტემას ნულიდან. მაგალითად, ეს არის საწყობის მართვის სისტემა ახალი ლოგისტიკური კომპლექსისთვის. სხვა სიტყვებით რომ ვთქვათ, იქ მხოლოდ კედლებია. ან ახდენთ სისტემის განახლებას და ცვლილებების განსახორციელებლად საჭიროა შეცვალოთ ორგანიზაციული სტრუქტურა. ასეთ შემთხვევებში, თქვენ უნდა მიუთითოთ პირობები იმ პროცესების ორგანიზებასთან დაკავშირებით, რომლებშიც თქვენ მიერ მოწოდებული სისტემა რეალურად იმუშავებს.

7.3.8. პუნქტი 4.3.8 „მეთოდური მხარდაჭერა“ / გვ. 2.6.3.8 GOST 34.602-89/

ზოგჯერ სისტემის მართვა მოითხოვს პერსონალს გარკვეული განსაკუთრებული კომპეტენციების მქონე. ამ შემთხვევაში, TOR უნდა შეიცავდეს იმ მეთოდების, ნორმებისა და სტანდარტების ჩამონათვალს, რომლებსაც უნდა იცოდნენ თანამშრომლები, რომლებიც ურთიერთობენ სისტემასთან.

7.3.9. სხვა სახის გირაო

ყოველი ახალი TOR-ის შემუშავებისას უნდა გაითვალისწინოთ რა დაგჭირდებათ წარმატებით შესვლისთვის კომერციული ოპერაცია. მაგალითად, მე ხშირად ვწერ მოთხოვნებს იურიდიული მხარდაჭერაროდესაც გამოყენებული სამართლებრივი სქემა ბოლომდე არ არის განსაზღვრული და მისმა განვითარებამ შეიძლება გავლენა მოახდინოს განხორციელებაზე. .

8. მე-5 ნაწილი „სისტემის შექმნაზე (განვითარებაზე) მუშაობის შემადგენლობა და შინაარსი“ / გვ. 2.7 GOST 34.602-89/

ეს განყოფილება არის ორგანიზაციული და ხშირად შედის ხელშეკრულებაში. თუმცა, ეს ინფორმაცია ToR-ში შეიძლება დაზუსტდეს.

არსებითად, ეს არის განვითარებისა და განხორციელების მოკლე გეგმა. მისი შედგენისას მე ჩვეულებრივ ვაძლევ ცხრილს, რომელიც აჩვენებს ყველა ან რამდენიმე შემდეგ სვეტს:

• სცენის სახელწოდება (ქვესცენა).
• ნამუშევრების შინაარსი ( მოკლე აღწერა, დავალებების სია).
• სამუშაოს შედეგი (დამტკიცებული დოკუმენტები, შემუშავებული და წარმოდგენილი გადაწყვეტილებები).
• დიზაინის, სამუშაო ან ანგარიშგების დოკუმენტაცია.
• პასუხისმგებელი (ვინ ასრულებს ეს სამუშაო: დამკვეთი, კონტრაქტორი ან სხვა პირი). თუ ორივე მხარემ უნდა მოიტანოს ერთობლივი შედეგი, მითითებულია როლები.
• ხანგრძლივობა (ვადები, თარიღები, დროის დასაწყისი).

ამ განყოფილების შინაარსის მაგალითი ნაჩვენებია ქვემოთ მოცემულ ცხრილში.

სცენა	ნამუშევრების შინაარსი	მიღების პროცედურა და დოკუმენტები	Დროის განაწილება	პასუხისმგებელი
1. ტექნიკური სამუშაოების მომზადება (TOR)	სისტემის ფუნქციონალური და არაფუნქციური მოთხოვნების შემუშავება	ToR დამტკიცება	წინასწარი გადახდის დღიდან 60 დღე. მომხმარებელი იძლევა პირველ ვარიანტს დასამტკიცებლად 45 დღეში	დეველოპმენტი - კონტრაქტორი; მოწონება - დამკვეთი
2. საინჟინრო დიზაინი (TP)	სისტემის მუშაობის სცენარების შემუშავება და ვებ აპლიკაციის ინტერფეისის განლაგება	დოკუმენტის დამტკიცება "ავტომატური ფუნქციების აღწერა"	TOR-ის დამტკიცების დღიდან 60 დღე. მომხმარებელი იძლევა პირველ ვარიანტს დასამტკიცებლად 45 დღეში	შემსრულებელი
	ვებსაიტის და მობილური აპლიკაციების კორპორატიული იდენტობის შემუშავება	კორპორატიული პირადობის დადასტურება		დამკვეთი
	საიტის შინაარსის განვითარება (საჯარო ვებ აპლიკაცია)	შევსების დამტკიცება		დამკვეთი
	საჯარო ვებ აპლიკაციის დიზაინის განლაგების შემუშავება	დიზაინის განლაგების დამტკიცება		შემსრულებელი
	საჯარო მობილური აპლიკაციების დიზაინის განლაგების შემუშავება	დიზაინის განლაგების დამტკიცება		შემსრულებელი
	SMS აგრეგატორის შერჩევა, სერვერის მოდულით გაცვლის წესების მომზადება	დიზაინის განლაგების დამტკიცება		კლიენტი, კონტრაქტორის რეკომენდაციების შესაბამისად
3. პროგრამული უზრუნველყოფის დამუშავება	სერვერის მოდულის, მონაცემთა შენახვის მოდულის და ფაილების შენახვის მოდულის შემუშავება		TP-ის დამტკიცების დღიდან 100 დღე	განვითარება - კლიენტი. კონტრაქტორი აწვდის მონაცემებს დირექტორიების შევსებისთვის
	ადმინისტრაციული პანელის განვითარება	მიღება ხდება ტესტირების პროცესში		დამკვეთი
	სტატიკური ვებსაიტის შემუშავება (საჯარო ვებ აპლიკაცია)	მიღება ხდება ტესტირების პროცესში		შემსრულებელი
	საჯარო ვებ აპლიკაციისა და სერვერის მოდულის ინტეგრაციის შემუშავება	მიღება ხდება ტესტირების პროცესში		შემსრულებელი
	iOS მობილური აპლიკაციების შემუშავება (სერვერის მოდულთან ინტეგრაციის ჩათვლით)	მიღება ხდება ტესტირების პროცესში		შემსრულებელი
	მობილურის განვითარება ანდროიდის აპები(სერვერის მოდულთან ინტეგრაციის ჩათვლით)	მიღება ხდება ტესტირების პროცესში		შემსრულებელი
	სამუშაო და ოპერატიული დოკუმენტაციის შემუშავება	დოკუმენტის დამტკიცება: - „წინასწარი ავტონომიური გამოცდების პროგრამა და მეთოდები“. - „წინასწარი კომპლექსური გამოცდების პროგრამა და მეთოდოლოგია“. - "ექსპერიმენტული ოპერაციის პროგრამა"		შემსრულებელი
4. წინასწარი ავტონომიური ტესტები	- არაფუნქციურ მოთხოვნებთან შესაბამისობის შემოწმება (დიზაინი). - დოკუმენტაციის ნაკრების შემოწმება. - სისტემის სიჯანსაღის შემოწმება, მიმდებარე (გარე) სისტემებთან ურთიერთობის გარეშე.	წინასწარი ავტონომიური გამოცდების ოქმის დამტკიცება	განვითარების დასრულებიდან 14 დღე
5. წინასწარი კომპლექსური ტესტები	- დაკავშირებულ გარე სისტემებთან ურთიერთქმედების შემოწმება. - გაუმჯობესება და ხელახალი ტესტირება ხარვეზების აღმოფხვრამდე	წინასწარი კომპლექსური გამოცდების ოქმის დამტკიცება	ოფლაინ ტესტირების დასრულებიდან 14 დღე	შემსრულებელი - ტესტირება. დამკვეთი - ინფრასტრუქტურის მომზადება და ტესტების ორგანიზება
6. საცდელი ოპერაციისთვის მომზადება	- სისტემის განლაგება ინდუსტრიულ სერვერებზე. - მომზადების სამუშაოების კომპლექტის განხორციელება (დაწვრილებით იხილეთ პუნქტი 7 მოთხოვნები სისტემის ექსპლუატაციაში ჩასატარებლად ავტომატიზაციის ობიექტის მომზადებაზე მუშაობის შემადგენლობისა და შინაარსის შესახებ)	არანაირი მიღება	წინასწარი ტესტების დასრულებიდან 5 დღე	პროგრამული ნაწილის მომზადება და საცნობარო წიგნების შევსება - დამკვეთი. კონტრაქტორი აწვდის მონაცემებს დირექტორიების შევსებისთვის და აწყობს MA
7. საცდელი ოპერაცია	- ოპერაცია, რომელშიც მონაწილეთა მცირე რაოდენობაა (რამდენიმე აუქციონი მეგობრებს შორის). - გაუმჯობესება და ხელახალი ტესტირება ხარვეზების აღმოფხვრამდე	საცდელი ოპერაციის პროტოკოლი (შეცდომების ჟურნალი და მათი გამოსწორების შედეგები)	30 დღე	შემსრულებელი - ხარვეზების აღმოფხვრა. დამკვეთი - OE
8. სამრეწველო (კომერციული) ექსპლუატაციაში გაშვება	იხილეთ საცდელი ოპერაციისთვის მომზადების ეტაპი	არანაირი მიღება	პროგრამული ნაწილის მომზადება და საცნობარო წიგნების შევსება - 10 დღე	პროგრამული ნაწილის მომზადება და საცნობარო წიგნების შევსება - დამკვეთი. კონტრაქტორი ახორციელებს სამრეწველო ექსპლუატაციის ორგანიზაციას
9. სამრეწველო (კომერციული) საქმიანობა	სამრეწველო ოპერაცია	არანაირი მიღება

9. მე-6 ნაწილი „სისტემის მონიტორინგისა და მიღების პროცედურა“ / გვ. 2.8 GOST 34.602-89/

ამ განყოფილებაში დეტალურად არის აღწერილი მომხმარებლის მიერ სისტემის მიღების პროცესი: რა ტესტები უნდა ჩატარდეს, რა შედის ამ ტესტებში, რომელი დოკუმენტების მიხედვით ჩატარდება ტესტირება, როგორ შედგენილი და აღმოფხვრილი იქნება კომენტარები.

9.1. ქვეპუნქტი 6.1. „სისტემისა და მისი კომპონენტების ტიპები, შემადგენლობა, მოცულობა და ტესტირების მეთოდები“ / გვ. 2.8.1 GOST 34.602-89/

როგორც წესი, აქ მიგითითებთ ტესტების ჩამონათვალს და აღვნიშნავ, რომ ტესტირების მეთოდები მოცემულია დოკუმენტში „ტესტის პროგრამა და მეთოდები“, რომელიც არის ძირითადი ტესტის შემთხვევების, ტესტირების სცენარების აღწერა.

მოდით უფრო ახლოს მივხედოთ ტესტების ტიპებს. ტესტების სახეები, მათი შემადგენლობა, დოკუმენტების მოთხოვნები დადგენილია GOST 34.603-92 „საინფორმაციო ტექნოლოგია. ავტომატური სისტემების ტესტირების სახეები. ამიტომ, ამ განყოფილებისა და ტექნიკური პროექტის შემუშავებისას, აუცილებლად მიმართეთ ამ სტანდარტს, აქ განვმარტავთ მხოლოდ ძირითად პუნქტებს.

შევეცადოთ გაერკვნენ, რა არის ტესტები:

1. ტესტები იყოფა შემდეგ ტიპებად:

• წინასწარი.
• გამოცდილი ოპერაცია.
• მიღება.

2. წინასწარი (და ნაწილობრივ მისაღები) ტესტები, თავის მხრივ, იყოფა:

• ავტონომიური (მიმდებარე სისტემებთან ინტეგრაციის გარეშე).
• კომპლექსი (დაკავშირებულ სისტემებთან ერთად).

რატომ იყოფა ცდები სხვადასხვა ეტაპად? პირველ რიგში, იმის გამო, რომ GOST 34.603-92 არ გამოყოფს შიდა და გარე მიღებას, ტესტების ნაწილი შეიძლება განხორციელდეს მომხმარებლის გარეშე. მეორეც, ნაწილ-ნაწილ აღწერილია თანმიმდევრული ტესტირების პროცესი და შემდეგ ყველაფერი კომპლექსში.

შევეცადოთ აღვწეროთ ტესტირების პროცესი მარტივი სიტყვებით:

1. სისტემის ნაწილების წინასწარი ავტონომიური ტესტირება.სისტემის ნაწილების ტესტირება ხდება ცალკე, თუ შემადგენლობაში არის რამდენიმე ქვესისტემა ან დიდი მოდული. როგორც წესი, ასეთი ტესტირება ტარდება ავტონომიურად, ანუ დაკავშირებულ სისტემებთან ინტეგრაციის გარეშე. თუ სისტემა მარტივია, ეს ნაბიჯი შეიძლება უსაფრთხოდ გამოტოვოთ.

2. მთლიანი სისტემის წინასწარი ავტონომიური ტესტები.მთელი სისტემა ტესტირება ხდება კომპლექსში ოფლაინ რეჟიმში, ანუ მიმდებარე სისტემებთან ინტეგრაციის გარეშე. მიმდებარე სისტემებთან დაკავშირებული ფუნქციები არ არის შემოწმებული. ექსტრემალურ შემთხვევებში იდება „სტუბები“ (ინტეგრაციის ემულაცია) ან მონაცემთა ბაზა წინასწარ ივსება მონაცემებით, რომლებიც უნდა მოდიოდეს. გარე წყაროები.

3. წინასწარი კომპლექსური ტესტები.სისტემა ტესტირება ხდება კომპლექსურ რეჟიმში, ანუ მეზობელ სისტემებთან ურთიერთქმედებაში. ამ ფორმით, სისტემა გადაეცემა მომხმარებელს საცდელი ექსპლუატაციისთვის.

4. საცდელი ოპერაცია. OE შეიძლება განხორციელდეს სხვადასხვა რეჟიმში. საუკეთესოა რეალურ მონაცემებზე მუშაობა, რეალურ მომხმარებლებთან და რეალურ ამოცანებთან. მხოლოდ ამ ტიპის ტესტირება დარწმუნდება, რომ სისტემა ნამდვილად მუშაობს. ნაკლოვანებები აღმოიფხვრება საცდელი ოპერაციის დროს.

5. მისაღები ტესტები.ეს არის ბოლო სახის შემოწმება. შეგიძლიათ მითხრათ, რატომ არ გადაიქცევა საცდელი ოპერაცია, ყველა ხარვეზის აღმოფხვრის შემდეგ, შეუფერხებლად სამრეწველო ექსპლუატაციაში? ეს ჩვეულებრივ ხდება. ყოველივე ამის შემდეგ, მაღალმა ბიძებმა უნდა დაინახონ, რომ სისტემა ნამდვილად მუშაობს, რომ "შეგრძნონ". მათთვის, ამისთვის მაღალი საკომისიოდა მისაღები ტესტები არის განკუთვნილი. ამრიგად, მისაღები ტესტები განსხვავდება წინასწარი ტესტებისგან, პირველ რიგში, კომისიის სტატუსით.

ასევე ამ პუნქტში მითითებულია დოკუმენტები, რომლებშიც მოცემულია ტესტის მეთოდები:

• ამისთვის წინასწარი და მისაღები ტესტებიეს არის "წინასწარი (მიმღები) ტესტირების პროგრამა და მეთოდები". დოკუმენტის შედგენის ინსტრუქცია შეიცავს ორ სტანდარტს ერთდროულად. მოკლედ - GOST 34.603-92-ში (პუნქტები 2.2.2 და 4.1) და უფრო დეტალურად - RD 50-34.698-90 „სახელმძღვანელო. Საინფორმაციო ტექნოლოგია. სტანდარტებისა და გაიდლაინების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. მოთხოვნები დოკუმენტების შინაარსისთვის.
• ამისთვის საცდელი ოპერაციაგათვალისწინებულია დოკუმენტი "ექსპერიმენტული ოპერაციული პროგრამა", რომლის შინაარსი მოცემულია GOST 34.003-90-ის 3.1 პუნქტში. ასევე აუცილებელია დაინიშნოს „საცდელი ოპერაციების ჟურნალის“ გამოყენება (იხ. GOST 34.603-92 პუნქტი 3.2), რომელშიც შეიტანება ხარვეზები და მათი აღმოფხვრის შედეგები.

9.2. ქვეპუნქტი 6.2. „სამუშაოს ეტაპობრივად მიღების ზოგადი მოთხოვნები“ /გვ. 2.8.2 GOST 34.602-89/

ამ განყოფილებაში მე ჩვეულებრივ აღვნიშნავ:

1. ვის ტერიტორიაზე და ვის აღჭურვილობაზე ჩატარდება გამოცდები: დამკვეთი თუ კონტრაქტორი.
2. ზოგადი აღწერა იმის შესახებ, თუ როგორ ჩატარდება ტესტები (მაგ., დოკუმენტების ტესტირება, მომხმარებლის ინტერფეისის ელემენტების არსებობა, სცენარების შემუშავება).
3. მონაწილეთა სია.
4. დოკუმენტების სია, რომლითაც შედგენილია ტესტის შედეგები:
   • წინასწარი და მისაღები ტესტებისთვის ეს არის ტესტის ანგარიში, რომელშიც ჩამოთვლილია შემოწმებები და მათი შედეგები.
   • საცდელი ოპერაციისთვის - საცდელი ოპერაციების ჟურნალი.

10. მე-7 ნაწილი „მოთხოვნები სამუშაოს შემადგენლობისა და შინაარსის შესახებ ავტომატიზაციის ობიექტის სისტემის ექსპლუატაციაში გასაშვებად მოსამზადებლად“ / გვ. 2.9 GOST 34.602-89/

ამ სექციაში აღწერილ პროცესს ხშირად უწოდებენ განლაგებას. გთხოვთ გაითვალისწინოთ, რომ ეს ნამუშევრები ასევე მოცემულია განყოფილებაში. მაგრამ მე-5 ნაწილში ისინი მხოლოდ მოკლედ არის ნახსენები, აქ მოცემულია დეტალური აღწერა.

ობიექტის მომზადებისას, როგორც წესი, უნდა შესრულდეს შემდეგი სამუშაოები:

1. საჭიროების შემთხვევაში რეორგანიზაცია, ახალი კადრების დაკომპლექტება.
2. ტრენინგი.
3. ვებ აპლიკაციებისთვის: საიტის ზოგადი სექციების შემუშავება და მომხმარებლის შეთანხმება (პერსონალური მონაცემების დამუშავებაზე თანხმობა).
4. დირექტორიების და სხვა საწყისი ინფორმაციის შევსება.
5. მონაცემთა გადაცემა ძველი სისტემიდან.
6. სისტემის განლაგება ინდუსტრიულ სერვერებზე.
7. დაკავშირებულ სისტემებთან ინტეგრაციის დაყენება.
8. წვდომის სისტემის დაყენება და ანგარიშების შექმნა.

ზოგიერთი პუნქტი დეტალურად უნდა იყოს აღწერილი, განსაკუთრებით მონაცემთა გადაცემისა და დირექტორიების შევსების კუთხით.

11. მე-8 ნაწილი „დოკუმენტაციის მოთხოვნები“ / გვ. 2.10 GOST 34.602-89/

არ განიხილოთ დოკუმენტები ფორმალურად. დოკუმენტები არის პროექტის მენეჯმენტი, პროექტის სამუშაო პროცესი. თქვენ არ შეგიძლიათ შეინახოთ ყველაფერი თქვენს თავში, ხოლო პროექტის წარმატება დამოკიდებულია დოკუმენტების ხელმისაწვდომობაზე და ხარისხზე. რა თქმა უნდა, არსებობს დოკუმენტები "წონისთვის" და მათ შესაბამისად უნდა მოექცნენ, მაგრამ ზოგადად, მშვიდ და მოწესრიგებულ რეჟიმში დოკუმენტაციის გარეშე, პროექტი ვერ განხორციელდება.

ავტომატიზაციის პროექტის დოკუმენტაცია GOST 34-ის შესაბამისად რეგულირდება შემდეგი სტანდარტებით:

• GOST 34.201-89 დოკუმენტების ტიპები, სისრულე და აღნიშვნები ავტომატური სისტემების შექმნისას.
• RD 50-34.698-90 გაიდლაინები. Საინფორმაციო ტექნოლოგია. სტანდარტებისა და გაიდლაინების ნაკრები ავტომატური სისტემებისთვის. ავტომატური სისტემები. დოკუმენტის შინაარსის მოთხოვნები.
• ტექნიკური პირობებისთვის - GOST 34.602-89, რომელსაც ახლა განვიხილავთ.

პირველი სტანდარტი (GOST 34.201-89) უზრუნველყოფს დოკუმენტაციის ჩამონათვალს და სტრუქტურას. მეორე - RD 50-34.698-90 - მიუთითებს შემდეგი დოკუმენტების შინაარსზე:

• პროექტებისა და ტექნიკური პროექტების დოკუმენტები.
• საპროექტო ეტაპებზე შემუშავებული დოკუმენტები.
• ორგანიზაციული და ადმინისტრაციული დოკუმენტები (აქტები, ოქმები და ა.შ.)

11.1 დოკუმენტაციის სტრუქტურის მახასიათებლები

სიის შედგენისას საჭირო საბუთებიჩვეულებრივ გადახედეთ RD 50-34.698-90 და აირჩიეთ საჭირო. ამავდროულად, ბევრი შეცდომაა დაშვებული, რადგან დოკუმენტაციას აქვს საკმაოდ რთული სტრუქტურა, რომელიც აღწერილია GOST 34.201-89-ში.

შევეცადოთ გამოვყოთ რამდენიმე წესი, რომლებიც დაგეხმარებათ დოკუმენტების სიის შედგენაში.

1. თითოეულ ეტაპს აქვს საკუთარი დოკუმენტაციის ნაკრები.

თითოეულ ეტაპს აქვს საკუთარი დოკუმენტაციის ნაკრები. ამის გაგება ძალიან მნიშვნელოვანია. არ არის აუცილებელი საოპერაციო დოკუმენტების შემუშავების განსაზღვრა დიზაინის ეტაპებზე და პირიქით. გამოდის წმინდა ფორმალური ფურცლები, რომლებზეც დიდ დროს დახარჯავთ. და თუ "მომხმარებლის სახელმძღვანელო" ჩვეულებრივ არ არის შედგენილი სისტემის განვითარების დასრულებამდე (თუმცა მე შევხვდი ასეთ ფიგურებს), მაშინ "ავტომატური ფუნქციების აღწერა", რომელიც ჩვეულებრივ შეიცავს პროგრამისტებისთვის სკრიპტებს, მუდმივად შედგენილია განვითარების დასრულების შემდეგ. . ასევე, RD 50-34.698-90-ის წაკითხვისას შეიძლება შეიქმნას შთაბეჭდილება, რომ ზოგიერთი დოკუმენტის შინაარსი ერთმანეთს ემთხვევა: ეს ასევე განპირობებულია იმით, რომ დოკუმენტები განკუთვნილია სხვადასხვა ეტაპებზე.

იმის გამო, რომ ზოგიერთი დოკუმენტი შეიძლება შემუშავდეს ამა თუ იმ ეტაპზე, განმეორების თავიდან აცილების მიზნით, GOST 34.201-89 ცალკე გთავაზობთ, მაგალითად, დოკუმენტების ჩამონათვალს, რომლებიც შეიძლება გაიცეს როგორც ტექნიკური დიზაინის, ასევე სამუშაო დოკუმენტაციის ეტაპზე, და ცალ-ცალკე - დოკუმენტების სია თითოეული ამ ეტაპისთვის ცალ-ცალკე. ამრიგად, ერთ-ერთი ეტაპისთვის დოკუმენტების სიის შედგენისას, უნდა გადახედოთ დოკუმენტების სიებს სტანდარტის რამდენიმე განყოფილებაში.

რომ არ დავბნეულიყავი გავაკეთე Excel ცხრილი, რომელშიც, ფილტრების გამოყენებით, შეგიძლიათ დაუყოვნებლივ აჩვენოთ დოკუმენტების სრული სია კონკრეტული ეტაპისთვის.

2. დოკუმენტები იყოფა თემებად (პროექტის ნაწილებად).

GOST 34 შეიცავს დოკუმენტებს, რომლებიც აღწერს სისტემურ გადაწყვეტილებებს, ასევე ორგანიზაციულ, ტექნიკურ, მათემატიკურ, პროგრამულ უზრუნველყოფას, ინფორმაციის მხარდაჭერას (ვისაუბრეთ მხარდაჭერის ტიპებზე). RD 50-34.698-90-ში ეს დოკუმენტები მოცემულია ზუსტად დაყოფილი პროექტის ნაწილების მიხედვით (თემები). ყოველთვის ყურადღება უნდა მიაქციოთ ამას, რათა დადგინდეს დოკუმენტის მიზანი.

3. დოკუმენტები შეიძლება გაერთიანდეს.

GOST 34.201-89 ცალსახად ნათქვამია, თუ რომელ შემთხვევებში შედის ერთი დოკუმენტი მეორეში. ეს ისე კეთდება, რომ არ დარჩეს გადაგვარებული დოკუმენტები, ერთი ან ორი გვერდიანი. თუ რაიმეს აღწერაა საჭირო, მაგრამ მოცულობა ძალიან მცირეა, უმჯობესია ტექსტი სხვა დოკუმენტში შეიტანოთ. უმეტეს შემთხვევაში, არსებობს დოკუმენტი, როგორიცაა " განმარტებითი შენიშვნატექნიკურ პროექტს“, რომელშიც შეიძლება დაემატოს სექციები.

4. საოპერაციო და საპროექტო შეფასებები ცალ-ცალკე ხაზგასმულია.

GOST 34.201-89-ის შემდგენელები ცხრილის ცალკეულ სვეტებში, საოპერაციო და საპროექტო შეფასებებში მითითებული დოკუმენტების ჩამონათვალით.

საპროექტო ხარჯთაღრიცხვა მოიცავს სამშენებლო და ელექტრო სამუშაოების მარეგულირებელ დოკუმენტებს: ხარჯთაღრიცხვას, შესყიდვის გეგმებს, ნახაზებს და ელექტრო დიაგრამებს.

ოპერატიული დოკუმენტები მოიცავს დოკუმენტებს, რომლებიც ხელმძღვანელობენ სისტემის გამოყენებასა და შენარჩუნებას: სახელმძღვანელოები და ინსტრუქციები, მასალებისა და მონაცემების სია, დოკუმენტები, რომლებიც შეიცავს ინფორმაციას მუშაობის დროს დარღვევის შესახებ.

11.2 დოკუმენტების ჩამონათვალის მახასიათებლები

როგორც ადრე აღნიშნეთ, მუშაობის ეტაპების აღწერისას, ასევე მოცემულია დოკუმენტაციის ჩამონათვალი. დოკუმენტების ორმაგი სია მოცემულია მარტივი მიზეზის გამო: საკმარისი არ არის დოკუმენტის სახელის მითითება, ასევე აუცილებელია მისი მიზნის ახსნა და მიცემა. შემაჯამებელი(რა თქმა უნდა, აზრი არ აქვს „მომხმარებლის სახელმძღვანელოს“ შინაარსის მითითებას). წინააღმდეგ შემთხვევაში, შეუძლებელი იქნება იმის დადგენა, თუ რა მნიშვნელობა აქვს კონკრეტულ დოკუმენტს პროექტის მენეჯმენტში. GOST GOST და თითოეულ პროექტზე დოკუმენტების შინაარსი და როლი შეიძლება განსხვავდებოდეს. გარდა ამისა, სია შეიძლება შეიცავდეს დოკუმენტებს, რომლებიც არ არის რეგულირებული GOST 34-ით, რომლებიც საჭიროებენ დაზუსტებას უშეცდომოდ.

დოკუმენტაციის წესებში, მე ჩვეულებრივ ვაძლევ ცხრილს შემდეგი სვეტებით:

• სცენა.
• დოკუმენტის სათაური.
• შენიშვნა: მითითებულია განვითარების სტანდარტი, მიზანი, შეჯამება და დოკუმენტის ძირითადი მახასიათებლები.

11.3 დოკუმენტების ჩამონათვალის მაგალითი

რთული სისტემის განსახორციელებლად დიდი პროექტისთვის, შეიძლება საჭირო გახდეს დოკუმენტაციის საკმაოდ დიდი ჩამონათვალი. ასეთი სიის მაგალითი მოცემულია ქვემოთ მოცემულ ცხრილში.

12. მე-9 ნაწილი „განვითარების წყაროები“ / გვ. 2.11 GOST 34.602-89/

როგორც ჩანს, ეს არის ოფიციალური განყოფილება, მაგრამ ძალიან სასარგებლო. წარმოიდგინეთ სიტუაცია, როდესაც გახსოვთ, რომ წაიკითხეთ რაიმე სტატია TOR-ის შემუშავებისას და რატომღაც გჭირდებათ მისი პოვნა, მაგალითად, რაღაცის გარკვევა ან თქვენი გადაწყვეტილებების დასაბუთება. მაგრამ თქვენ აბსოლუტურად არ გახსოვთ არც მისი სახელი და არც სად ინახებოდა. ამიტომ, როდესაც ვიყენებ რაიმე სასარგებლო მასალას, აუცილებლად ვაქცევ მათ სიაში. და ტექსტში დავდე სქოლიო წყაროს მითითებით.

თუ ბევრი წყაროა, მაშინ ისინი უნდა დაიყოს ქვესექციად, მაგალითად:

• შემუშავებული სისტემის ანალოგების (პროტოტიპების) აღმწერი მასალები.
• მასალები, რომლებიც აღწერს სისტემის ზოგად იდეას. ხშირად, ეს დოკუმენტები შედგენილია წინასწარი დიზაინის ეტაპებზე და ისინი ჩვეულებრივ მოხსენიებულია განყოფილებაში "ავტომატიზაციის ობიექტის მახასიათებლები".
• მასალები პროექტის შემუშავებისთვის: გამოყენებული GOST სერიის 34 სია, გამოყენებული სტანდარტები პროექტის მენეჯმენტისთვის.
• ძირითადი პროცესის განხორციელებასთან დაკავშირებული მასალები: კანონების, სტანდარტების, შინაგანაწესებისა და ბრძანებების ჩამონათვალი, რომლებიც ადგენენ ავტომატიზებული პროცესების განხორციელების წესებს.
• ზოგადი და ინფორმაციული უსაფრთხოების მოთხოვნების შემცველი მასალები და სტანდარტები.

დასკვნა

რა თქმა უნდა, სამუშაო პირობების მომზადება GOST 34-ის შესაბამისად არ შეიძლება ეწოდოს მარტივი და მარტივი. და არა იმიტომ, რომ GOST ცუდია, უბრალოდ GOST გაიძულებს იფიქრო მთელი პროექტის განმავლობაში, დახატო ყველა წვრილმანი. მაგრამ კარგად დაწერილი TOR არის პროექტის წარმატების ნახევარი.

დაწერეთ კომენტარებში, თუ ფიქრობთ, რომ საჭიროა რაიმეს გარკვევა ან დამატება. აუცილებლად შევიტან ცვლილებებს სტატიაში.

ახლახან მომმართეს, რომ მიმეწოდებინა სტანდარტების მითითება (TOR) ავტომატური სისტემების (AS) და პროგრამული უზრუნველყოფის (SW) განვითარებისთვის. ასე რომ, ვფიქრობ, ახლა წავალ Yandex-ში, ვიპოვი შესაფერის სტატიას და გამოგიგზავნი. მაგრამ იქ არ იყო! მე ვერ ვიპოვე ერთი სტატია, რომელშიც ჩამოთვლილია TK სტანდარტები, შაბლონების და მზა დოკუმენტების მაგალითების ჩათვლით. მე მომიწევს საკუთარი სტატიის გაკეთება...

ასე რომ, ძირითადი სტანდარტები, მეთოდოლოგიები და ცოდნის კოდები, სადაც მითითებულია TK ან SRS (პროგრამული უზრუნველყოფის (ან სისტემის) მოთხოვნების სპეციფიკაცია):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK და ა.შ.

GOST 34

GOST 34.602-89 მითითება ავტომატური სისტემის შესაქმნელად არეგულირებს TOR-ის სტრუქტურას სისტემის შესაქმნელად, რომელიც მოიცავს პროგრამულ უზრუნველყოფას, აპარატურას, პროგრამულ უზრუნველყოფასთან მომუშავე ადამიანებს და ავტომატიზირებულ პროცესებს.

GOST 34-ის მიხედვით, მითითების პირობები უნდა შეიცავდეს შემდეგ ნაწილებს:

1. ზოგადი ინფორმაცია
2. სისტემის შექმნის (განვითარების) მიზანი და მიზნები
3. ავტომატიზაციის ობიექტების მახასიათებლები
4. სისტემური მოთხოვნები
5. სისტემის შექმნაზე მუშაობის შემადგენლობა და შინაარსი
6. სისტემის კონტროლისა და მიღების პროცედურა
7. სამუშაოს შემადგენლობისა და შინაარსის მოთხოვნები სისტემის ამოქმედებისთვის ავტომატიზაციის ობიექტის მოსამზადებლად.
8. დოკუმენტაციის მოთხოვნები
9. განვითარების წყაროები

TOR-ის შემუშავებისას სამთავრობო პროექტებიროგორც წესი, მომხმარებლები ითხოვენ ამ კონკრეტულ სტანდარტთან შესაბამისობას.

GOST 19

”GOST 19.xxx ერთი სისტემაპროგრამის დოკუმენტაცია (ESPD)” არის კომპლექსი სახელმწიფო სტანდარტები, პროგრამების (ან პროგრამული უზრუნველყოფის) და პროგრამული დოკუმენტაციის შემუშავების, დიზაინისა და მიმოქცევის ურთიერთდაკავშირებული წესების დაწესება. იმათ. ეს სტანდარტი ეხება კონკრეტულად პროგრამული უზრუნველყოფის შემუშავებას.
GOST 19.201-78 მითითების პირობების მიხედვით, მოთხოვნები შინაარსისა და დიზაინის მოთხოვნების შესახებ უნდა შეიცავდეს შემდეგ განყოფილებებს:

1. შესავალი;
2. განვითარების საფუძველი;
3. განვითარების მიზანი;
4. მოთხოვნები პროგრამის ან პროგრამული პროდუქტის მიმართ;
5. მოთხოვნები პროგრამულ დოკუმენტაციასთან;
6. ტექნიკური და ეკონომიკური მაჩვენებლები;
7. განვითარების ეტაპები და ეტაპები;
8. კონტროლისა და მიღების ბრძანება;
9. აპლიკაციები.

ბუნებრივია, GOST 34 (და 19) უკვე მოძველებულია და მე არ მომწონს მათი გამოყენება, მაგრამ სტანდარტების სწორი ინტერპრეტაციით, შეგიძლიათ მიიღოთ კარგი TK, იხილეთ დასკვნა.

IEEE STD 830-1998

830-1998 სტანდარტის საკმაოდ კარგი განმარტება - IEEE რეკომენდირებული პრაქტიკა პროგრამული უზრუნველყოფის მოთხოვნების სპეციფიკაციებისთვის მოცემულია მის აღწერაში:

აღწერილია კარგად დაწერილი პროგრამული უზრუნველყოფის მოთხოვნების სპეციფიკაციის (SRS) შინაარსი და ხარისხის მახასიათებლები და მოწოდებულია რამდენიმე SRS შაბლონი. ეს რეკომენდირებული პრაქტიკა მიზნად ისახავს შემუშავებული პროგრამული უზრუნველყოფის მოთხოვნების ჩამოყალიბებას, მაგრამ ასევე შეიძლება გამოყენებულ იქნას საკუთრების და კომერციული პროგრამული პროდუქტების შერჩევაში დასახმარებლად.

სტანდარტის მიხედვით, სამუშაო პირობები უნდა შეიცავდეს შემდეგ ნაწილებს:

1. შესავალი

• 1. დანიშვნა
• 2. ფარგლები
• 3. განმარტებები, აკრონიმები და შემოკლებები
• 4. ბმულები
• 5. მიმოხილვა

2. ზოგადი აღწერა

• 1. პროდუქტის ურთიერთქმედება (სხვა პროდუქტებთან და კომპონენტებთან)
• 2. პროდუქტის მახასიათებლები (მოკლე აღწერა)
• 3. მომხმარებლის მახასიათებლები
• 4. შეზღუდვები
• 5. ვარაუდები და დამოკიდებულებები

3. დეტალური მოთხოვნები (შეიძლება ორგანიზებული იყოს სხვადასხვა გზით, მაგ.)

• 1. მოთხოვნები გარე ინტერფეისებისთვის
  • 1. მომხმარებლის ინტერფეისები
  • 2. აპარატურის ინტერფეისები
  • 3. პროგრამული ინტერფეისები
  • 4. ურთიერთქმედების ინტერფეისები
• 2. ფუნქციური მოთხოვნები
• 3. შესრულების მოთხოვნები
• 4. დიზაინის შეზღუდვები (და მითითებები სტანდარტებზე)
• 5. არაფუნქციური მოთხოვნები(სანდოობა, ხელმისაწვდომობა, უსაფრთხოება და ა.შ.)
• 6. სხვა მოთხოვნები

4. აპლიკაციები
5. ანბანური ინდექსი

სინამდვილეში, დამწყებთათვის საკმაოდ რთულია იმის გაგება, თუ რა უნდა შეიცავდეს ამ განყოფილებებს ზემოაღნიშნული სტრუქტურის მიხედვით (როგორც GOST-ის შემთხვევაში), ასე რომ თქვენ უნდა წაიკითხოთ თავად სტანდარტი, რომელიც. თუმცა ინგლისურად. ენა.

ისე, ვინც ბოლომდე წაიკითხა, არის ბონუსი: TK-ის მაგალითი, რომელიც დავწერე მრავალი წლის წინ (ახლა უბრალოდ დიდი ხანია არ ვმუშაობ ანალიტიკოსად და სხვა უფრო წარმატებული მაგალითები აკრძალულია საზოგადოებისთვის გაიხსნება NDA-ს მიერ).

• იური ბულუის პრეზენტაცია პროგრამული უზრუნველყოფის მოთხოვნების კლასიფიკაცია და მისი წარმოდგენა სტანდარტებსა და მეთოდოლოგიაში.
• ავტომატიზირებული მოთხოვნების ანალიზი ინფორმაციული სისტემები. ლექცია 11: დოკუმენტაციის მოთხოვნები.
• პროგრამული უზრუნველყოფის მოთხოვნების სპეციფიკაციის შედგენის წესები (წაიკითხეთ კომენტარებით)
• TOR-ის მაგალითები და სხვა დოკუმენტაცია ეკონომიკური განვითარების სამინისტროსთვის AS-ის განვითარებისათვის
• GOST-ოვსკის მართვის სტილი. გაპერტონის სტატია TK– სთან სწორი მუშაობის შესახებ GOST– ის მიხედვით
• დოკუმენტის შაბლონები ბიზნეს ანალიტიკოსებისთვის

რა არის ტექნიკური დავალება? როგორ გავაკეთოთ ეს და რატომ არის საჭირო? მაგალითები, ნიმუშები, რჩევები და ხრიკები.

როგორც ჩანს, რა კარგია, როცა მშვენივრად გესმის. მან წარმოთქვა რამდენიმე ფრაზა და აი, ის, რაც თქვენ წარმოიდგინეთ. სამწუხაროდ, ეს ასე არ მუშაობს.

ინფორმაციის აღქმის პრობლემა მარადიულია. "გატეხილი ტელეფონის" ეფექტი ჩვეულებრივი მოვლენაა. და რა უნდა თქვათ, თუ უბრალოდ არ იცით როგორ დააყენოთ დავალება? დიახ, ეს ასევე ხდება და თქვენ უნდა იმუშაოთ როგორმე, მაგრამ როგორ? იმისათვის, რომ თქვენ მიერ დასახული ამოცანების შედეგებმა დააკმაყოფილოს თქვენი მოლოდინი, დაწერეთ მითითების პირობები.

რა არის ტექნიკური დავალება

სამუშაო პირობები (ან TOR) - დოკუმენტი, რომელიც შეიცავს მომხმარებლის მოთხოვნებს კონტრაქტორის მიერ მიწოდებულ პროდუქტებზე ან მომსახურებაზე. მარტივი სიტყვებით: მინდა ასე და ისე, რომ შვიდი ერთმანეთის პერპენდიკულარული ხაზი იყოს, ზოგიც წითელში და ზოგი უფერო (ამ თემაზე ვიდეო მასალის ბოლოს, გირჩევთ უყუროთ).

დიზაინის განყოფილება

ამ დოკუმენტს შეუძლია მიიღოს ერთი A4 გვერდი ან მთელი ტომი, ეს ყველაფერი დამოკიდებულია მასში შეტანილ ამოცანებსა და სურვილებზე. მაგალითად, შეგიძლიათ დაწეროთ ტექნიკური დავალება მცირე სადესანტო გვერდისთვის (ერთგვერდიანი საიტი) ან კომპლექსური პროგრამული უზრუნველყოფისთვის მანქანური სწავლისა და სხვა ფუნქციებით.

რატომ გჭირდებათ ტექნიკური დავალება

• შემსრულებელთათვის დავალების დასაყენებლად.
• დეტალურად აღწეროთ რისი მიღება გსურთ ბოლოს.
• შევთანხმდეთ მუშაობის თანმიმდევრობაზე.
• სამუშაოს შეფასება და მიღება განხორციელების შემდეგ.
• To ... (დაამატეთ თქვენი ვარიანტები კომენტარებში).

სინამდვილეში, ტექნიკური ამოცანის გაცილებით მეტი დანიშვნა და უპირატესობაა, ვიდრე ზემოთ მოცემულ სიაში. პირადად ჩემთვის, მთავარი ამოცანა, რომელსაც TK წყვეტს, არის იმის განხორციელება, რაც მჭირდება, მინიმალური გადახრებით მოლოდინებიდან (ჩემი მოლოდინები).

TK-ის წყალობით, ყოველთვის შეგიძლიათ იკითხოთ განხორციელების დროის, ფულის და საბოლოო პროდუქტის ან სერვისის დეკლარირებულ მახასიათებლებთან შესაბამისობის შესახებ.

სინამდვილეში, ეს არის სერიოზული დოკუმენტი, რომელიც შედგენილია დამკვეთისა და კონტრაქტორის მიერ. იქამდე, რომ დაწესებულია მხარეთა ჯარიმები და ვალდებულებები. არსებობს მთელი რიგი GOST, წაიკითხეთ მეტი Habré-ზე.

ტექნიკური მახასიათებლების შემუშავება

თუ ვსაუბრობთ თამაშზე „ზრდასრული გზით“, მაგალითად, განვითარების მითითების პირობებზე მობილური აპლიკაციაან საიტი, მაშინ ეს ცალკე სამუშაორისთვისაც დიდ ფულს იხდიან. თქვენ მოყავთ ადამიანი, როგორც წესი, ყოფილი ან ამჟამინდელი მთავარი ტექნიკური დირექტორი და სთხოვთ მათ დაგეხმაროთ.

წვერი არჩევითია

პროექტის/დავალებების მოცულობიდან გამომდინარე, ეს ადამიანი აგროვებს თქვენს ყველა „სურვილების სიას“, თარგმნის მათ ტექნიკურ ენაზე, შესაძლოა მოამზადოს ესკიზები (როგორ უნდა გამოიყურებოდეს დაახლოებით) და მოგცემთ. დასრულებული დოკუმენტი. შემდეგ ამ დოკუმენტს გადასცემთ შემსრულებლებს (გუნდს თქვენი კომპანიის შიგნით ან აუთსორსინგისთვის), ეთანხმებით ფულს, პირობებს და შეუდგები სამუშაოს.

რჩევა: CTO უნდა იყოს თქვენს გუნდში, წინააღმდეგ შემთხვევაში თქვენ დიდი ალბათობით ვერ შეამჩნევთ რაიმეს განხორციელების პროცესში. თქვენ უბრალოდ არ გაქვთ საკმარისი ცოდნა ყველაფრისთვის. ვინ მონაწილეობდა TK-ის დაწერაში, ის ამოწმებს.

რა არის სპეციფიკაცია

ყველაფერი დამოკიდებული იქნება თქვენს მიერ არჩეულ შაბლონზე (მე მივცემ რამდენიმე ბმულს შაბლონებზე/მაგალითებზე ცოტა მოგვიანებით), მაგრამ არის ძირითადი ბლოკები, რომლებიც შედის მითითების პირობებში:

1. პროექტის/დავალების აღწერა. მოკლედ ვწერთ რა სახის პროექტი ან დავალება უნდა შესრულდეს.
2. მიზანი და მიზნები. რა არის პროექტის მიზნები.
3. მოთხოვნები. დიზაინი, მახასიათებლები, ტექნოლოგიები, რომლებიც საჭიროა.
4. სამუშაოების აღწერა. რა, როდის და როგორ გაკეთდება.
5. კონტროლისა და მიღების პროცედურა. როგორ მიიღება სამუშაო, რა შეიძლება ჩაითვალოს დასრულებულად.
6. აპლიკაციები. ესკიზები, ესკიზები, პროტოტიპები.

სამუშაოს ღირებულება, როგორც წესი, ამოღებულია ხელშეკრულების ცალკე დანართში, მაგრამ ეს ხდება მაშინ, როდესაც მხარეები განსაზღვრავენ თანხებს თავად მითითებების პირობებში.

მაპატიეთ კითხვა რომ შემეშალა. შემოუერთდი ჩემს ტელეგრამის არხს. სტატიების ახალი განცხადებები, ციფრული პროდუქტების განვითარება და ზრდის ჰაკი, ყველაფერი იქ არის. Გელოდები! Ჩვენ ვაგრძელებთ ...

დავალებების მაგალითები

მიუხედავად იმისა, რომ ტექნიკური მახასიათებლების შემუშავება რთული პროცესია, მაგრამ ძალიან საინტერესო. თქვენი ამოცანაა ხელახლა შექმნათ საბოლოო შედეგის სურათი და შემდეგ აღწეროთ იგი ნაწილებად.

ჩემი ერთ-ერთი ტექნიკური მახასიათებლის მაგალითი Smart TV აპლიკაციის განახლებისთვის. უფრო რთული და რთული პროდუქტების ამოცანები უკვე შედგენილი იყო ტექნიკური განყოფილების კოლეგების დახმარებით. თავისუფლად სთხოვეთ დახმარება თქვენს თანამოაზრეებს, ჩართეთ ისინი პროცესში რაც შეიძლება ხშირად. და არ დაგავიწყდეთ გაცემა უკუკავშირი! არაფერია იმაზე უარესი, ვიდრე დროისა და ძალისხმევის ინვესტირება რაიმეში შედეგების ცოდნის გარეშე. გვითხარით, რამდენად სასარგებლო იყო ადამიანის რჩევა თქვენს საქმიანობაში, წინააღმდეგ შემთხვევაში ეს ცალმხრივი თამაშია.

მითითება ონლაინ მაღაზიის განვითარებისთვის

ტექნიკური პირობები მობილური აპლიკაციის შემუშავებისთვის

TK საიტზე

ToR სერვისებისთვის/განახლებისთვის

თუ მეტი ნიმუში გჭირდებათ, უბრალოდ დაგუგლეთ.

მთავარი რეკომენდაციაა ამის გაკეთება. უბედურება ისაა, რომ დედის სიზარმაცე ყველას სძლევს და მისთვის წინააღმდეგობის გაწევა ადვილი არ არის. შეკრიბეთ მთელი თქვენი ნება მუშტში და დაიწყეთ მითითებების წერა, უბრალოდ დაწერეთ და არ გაჩერდეთ. არ ინერვიულოთ, რომ ეს არ გამოდგება "იდეალურად", მე გამოვავლენ საიდუმლოს, ეს არ ხდება. უბრალოდ დაწერე, ყოველ ჯერზე უკეთესი და უკეთესი იქნება.

ასეც უნდა იყოს

ტექნიკური მახასიათებლების დაწერის ჩემი პირველი საფუძვლები რამდენიმე წლის წინ გამოჩნდა. ვმუშაობდი დიზაინერებთან და დასახული მაქვს სარეკლამო კამპანიებისთვის კრეატივის შექმნა. არათანმიმდევრული სურვილი და ეს გადაიზარდა ფუჭად დაკარგულ დროსა და ახსნა-განმარტებებში. დროთა განმავლობაში, დავალებების დაყენებამ დაიწყო გადაქცევა ერთგვარ სემანტიკურ ბლოკად, შემდეგ კი ერთგვარ ტექნიკურ ამოცანად.

მაგალითად, დავალების "Like ღილაკი საიტზე":

1. აღწერა: თქვენ უნდა შექმნათ "Like" ღილაკი ჩვენს ვებსაიტზე.
2. მიზანი და მიზნები: მომხმარებლის ჩართულობა, მასალების გაცემა/რეიტინგი მოწონებების რაოდენობის მიხედვით.
3. მოთხოვნები: ასეთი დიზაინი (მაგალითად: ბმული რაღაც მსგავსზე), ფუნქციონალობა (ნებისმიერ მომხმარებელს შეუძლია შეაფასოს სურათი და მოიწონოს იგი, საიტის სისტემა ითვალისწინებს მოწონებების რაოდენობას და ცვლის მასალების გამომუშავებას), ტექნოლოგია (ხელმისაწვდომია საიტის დესკტოპის და მობილური ვერსიები).
4. სამუშაოს აღწერა: დახაზეთ ღილაკების 3 განლაგება (შესრულების თარიღი: 10/01/17), შეიმუშავეთ მასალების გაცემის სისტემა ლაიქების მიხედვით (თარიღი: 10/14/17), ფუნქციის ტესტირება (თარიღი: 10/16/17) , გამოშვება (თარიღი: 17/10/17)
5. სამუშაოების მიღება: მომხმარებელი აწკაპუნებს like ღილაკს, სისტემა ითვლის დაწკაპუნებას, იცვლება მასალების მიწოდება.
6. აპლიკაციები: ესკიზები, ესკიზები, პროექტების მაგალითები, სადაც მუშაობს მსგავსი ფუნქცია.

დატოვეთ თქვენთვის ის მონაკვეთები და სტრუქტურის ნაწილები, რომლებიც საჭიროა თქვენი ამოცანებისთვის. მაგალითად, მეექვსე ბლოკი "აპლიკაციები" შეიძლება აღწერილი იყოს ფუნქციურ მოთხოვნებში. მთავარი რჩევა: ამა თუ იმ გზით აღწერეთ დავალება მითითების სტრუქტურის მიხედვით. ამგვარად, არ გამოტოვებთ მნიშვნელოვან მომენტებს და თავს იხსნით ზედმეტი კითხვებისგან და გაამარტივებთ კოლეგების ცხოვრებას.

აი შენ წადი

ჩვენ გავაანალიზეთ რა არის ტექნიკური ამოცანა და როგორ უნდა გავაკეთოთ ეს. ახლა თქვენ გაქვთ შესაძლებლობა მკაფიოდ და მკაფიოდ დასახოთ მიზნები, მიაწოდოთ თქვენი აზრები სხვა ადამიანებს და დაზოგოთ დრო დამატებითი განმარტებებისთვის. იმედი მაქვს, ახლა იცით, რა უნდა გააკეთოთ ამ ყველაფერთან.