მობილური აპის backend და admin panel: შესყიდვის ჩარჩო
მობილური აპის backend-ისა და ადმინისტრაციული პანელის დაკვეთის ჩარჩო მონაცემების, როლების, ოპერაციებისა და მიღების ტესტის მიხედვით.
Backend და admin panel მომხმარებლის გზას უნდა ემსახურებოდეს: რა მონაცემი იქმნება, ვინ ცვლის მას და როგორ ჩანს შეცდომა. შეთავაზებაში „პანელი შედის“ ამის შესამოწმებლად საკმარისი არ არის.
თუ გსურთ ეს რუკა თქვენი აპის იდეას დაუკავშიროთ, aiAPP-ის პროექტის განხილვაში მიუთითეთ მომხმარებლის გზა და ოპერაციის პასუხისმგებელი.
სერვერის როლი მობილურ აპში
backend არის ის ნაწილი, რომელიც მომხმარებლის ტელეფონსა და ბიზნესის მონაცემებს შორის წესებს, ავტორიზაციას და გარე კავშირებს ამუშავებს. აპის ეკრანი შეიძლება აჩვენებდეს შეკვეთას, ჯავშანს ან სტატუსს, მაგრამ backend-ს უნდა ჰქონდეს პასუხი, ვინ ხედავს ჩანაწერს, ვინ ცვლის მას და როგორ ინახება ცვლილება. ეს პასუხისმგებლობა ეკრანის დიზაინში არ ჩანს.
admin panel კი ოპერატორის ან მენეჯერის სამუშაო ადგილია. ის შეიძლება მოიცავდეს მომხმარებლების, კატალოგის, სტატუსების, განაცხადების, ანგარიშებისა და კონფიგურაციის მართვას. ყველა ეს ფუნქცია საჭირო არ არის. პანელი უნდა აჩვენებდეს იმ მოქმედებებს, რომლებიც აპის პირველ გზას ამთავრებს ან უსაფრთხოდ ამოწმებს.
N&T Software-ის შეთავაზებაში ადმინისტრაციული პანელი მომხმარებლებისა და კონტენტის მართვას უკავშირდება. ეს ერთი მომწოდებლის შეთავაზებაა და aiAPP-ის მზა ფუნქციას არ ადასტურებს.
სერვერის მონაცემთა რუკა
დაიწყეთ ობიექტებით და არა ცხრილების სახელებით. ჩამოწერეთ მომხმარებელი, განაცხადი, შეკვეთა, პროდუქტი, ჯავშანი, შეტყობინება ან სხვა ობიექტი, რომელიც ბიზნესის გადაწყვეტილებაში მონაწილეობს. თითოეულს დაურთეთ მფლობელი, სტატუსები, შექმნის წყარო, ცვლილების უფლება, წაშლის ან არქივის წესი და ის ეკრანი, სადაც გამოიყენება.
- იდენტიფიკაცია: რა უნიკალური ნიშნით ცნობთ ჩანაწერს?
- სტატუსი: რომელი მდგომარეობებიდან რომელში შეიძლება გადასვლა?
- როლი: ვინ ქმნის, ამოწმებს, ცვლის ან აუქმებს?
- მტკიცებულება: რა ინახება, რათა ცვლილების მიზეზი მოიძებნოს?
- გარე კავშირი: რომელი სისტემა აწვდის ან იღებს მონაცემს?
თუ ოპერატორი ტელეფონის ნომერს ასწორებს, უნდა ჩანდეს ძველი და ახალი მნიშვნელობის მფლობელი, უფლებამოსილი როლი და შესაძლო შეტყობინება. თუ კლიენტი ჯავშანს აუქმებს, პანელმა და აპმა ერთი და იგივე წესით უნდა იცოდნენ, რა ხდება თავისუფალ დროში და გადახდის სტატუსში. წინააღმდეგ შემთხვევაში backend მხოლოდ მონაცემთა საცავი ხდება და არა სანდო ოპერაციული წესრიგი.
ადმინისტრაციული პანელის მოცულობა
პანელის ფარგლები დააკავშირეთ ბიზნესის მოქმედებებთან. ჩამოწერეთ სია, ძებნა, ფილტრი, დეტალის ნახვა, შექმნა, ცვლილება, დამტკიცება, გაუქმება, ექსპორტი და ანგარიშის ნახვა მხოლოდ მაშინ, როცა ამ მოქმედებას კონკრეტული მფლობელი ჰყავს. ცარიელი სია, შეცდომა, კონფლიქტი და ხელმიუწვდომელი მონაცემი ცალკე მდგომარეობებად ჩაწერეთ.
როლები არ უნდა შემოიფარგლოს „ადმინის“ ერთი ანგარიშით. გამოყავით ოპერატორი, მენეჯერი, ფინანსური მიმომხილველი და ტექნიკური პასუხისმგებელი, თუ მათ სხვადასხვა გადაწყვეტილება აქვთ. აღწერეთ რომელი სვეტი, ჩანაწერი ან ფუნქცია არ უნდა დაინახოს თითოეულმა როლმა. გაზიარებული პაროლი არ არის მართვის მოდელი და handover-ის შემდეგ მყიფე დამოკიდებულებას ქმნის.
რით განსხვავდება backend, admin panel და CMS?
| ნაწილი | მთავარი სამუშაო | მყიდველის საკონტროლო კითხვა |
|---|---|---|
| Backend | წესები, მონაცემები, ავტორიზაცია და ინტეგრაციები | როგორ იცავს და ამოწმებს სისტემა ჩანაწერს? |
| Admin panel | ოპერატორის ყოველდღიური მართვა და დამტკიცება | რომელ მოქმედებას ასრულებს კონკრეტული როლი? |
| CMS | წინასწარ განსაზღვრული კონტენტის რედაქტირება | არის თუ არა კონტენტი ერთადერთი სამართავი ობიექტი? |
ერთი პროექტი შეიძლება სამივე ნაწილს იყენებდეს, მაგრამ ისინი ერთმანეთს არ ანაცვლებს. CMS-ის არსებობა არ ნიშნავს, რომ ჯავშნის კონფლიქტი, გადახდის დაბრუნება ან მენეჯერის დამტკიცება უსაფრთხოდ იმართება. შეთავაზებაში თითოეულ ნაწილს ცალკე პასუხისმგებლობა და მიღების ტესტი დაურთეთ.
როგორ მიიღოთ backend და პანელი?
მიღების ტესტი დაიწყეთ ერთი სრული გზით. შექმენით ჩანაწერი აპში, ნახეთ იგი შესაბამის როლში, შეცვალეთ დასაშვები ველით, უარყავით აკრძალული მოქმედება, გამოიწვიეთ შეცდომა და გადაამოწმეთ ჟურნალში. შემდეგ გაიმეორეთ გზა მეორე პლატფორმის აპში, თუ სამუშაოს მოცულობაში iOS და Android ორივე შედის.
სთხოვეთ მომწოდებელს აჩვენოს ტესტური მონაცემის წაშლა ან ანონიმიზაცია, ანგარიშის ექსპორტის ფორმა და უფლებების შეცვლის კვალი. მიღება არ არის მხოლოდ ის, რომ პანელი „იხსნება“. საჭიროა გასაგები მტკიცებულება, რომ ბიზნესის წესები სწორ როლზე მუშაობს და შეცდომა ოპერატორისგან არ იმალება.
რა უნდა მოამზადოთ პირველ შეხვედრამდე?
- დაწერეთ მომხმარებლის ერთი გზა ტელეფონიდან საბოლოო გადაწყვეტილებამდე.
- ჩამოწერეთ მონაცემთა ობიექტები, სტატუსები და თითოეული მფლობელი.
- განსაზღვრეთ ადმინისტრაციული როლები და აკრძალული მოქმედებები.
- მიუთითეთ ინტეგრაციები, მათი ანგარიშის მფლობელი და შეცდომისას fallback.
- შეადგინეთ მიღების სცენარები, ჟურნალის მოლოდინი და handover-ის სია.
თქვენი აღწერა გაუგზავნეთ aiAPP-ის პროექტის განხილვას. სამუშაო ფორმატის გვერდი დაგეხმარებათ კომერციული საკითხების გამიჯვნაში, ინტეგრაციების აღწერა კი ცალკე დაგანახებთ იმას, რაც კონკრეტულ პროექტში უნდა შეთანხმდეს.
რომელი backend შეცდომები იმალება დემოში?
დემო ხშირად აჩვენებს მხოლოდ იდეალურ მონაცემს და ერთ ადმინს. პრაქტიკაში პრობლემა ჩნდება დუბლირებული ჩანაწერის, პაროლის დაკარგვის, გარე სერვისის დაგვიანების, არასაკმარისი უფლებისა და წაშლის მოთხოვნის დროს. თუ ეს გზები სამუშაოს მოცულობაში არ წერია, შეთავაზებების რეალური სამუშაო მოცულობით შედარება ვერ მოხერხდება.
მეორე შეცდომაა ყველა ფუნქციის „სურვილისამებრ“ დატოვება. backend-ის არქიტექტურას სტატუსები, ავტორიზაცია და მონაცემთა სიცოცხლის ციკლი თავიდანვე სჭირდება. მესამეა ადმინისტრაციული წვდომის გადადება გადაცემამდე. ბიზნესმა პროექტის განმავლობაში უნდა იცოდეს, ვის ეკუთვნის ანგარიშები და სად ინახება დოკუმენტაცია.
რა შეზღუდვები რჩება?
ადმინისტრაციული პანელი ვერ ჩაანაცვლებს ბიზნესის პასუხისმგებელ მფლობელს. სწორად დაწერილი როლი ვერ გაასწორებს არაზუსტ მონაცემს ან წინააღმდეგობრივ წესს. კონკრეტული cloud, მონაცემთა ბაზა, მონიტორინგი, სარეზერვო ასლი და რეაგირების დონე ცალკე არქიტექტურულ და სახელშეკრულებო გადაწყვეტილებებს მოითხოვს.
aiAPP-ის მიმდინარე პროდუქტი ახალი მობილური აპის შექმნას ფარავს, მაგრამ ამ გვერდზე არც უნივერსალური backend და არც მზა admin panel არ არის დაპირებული. საბოლოო მოცულობა უნდა დაეყრდნოს თქვენს გზას, მონაცემებს, როლებსა და მიღების ტესტს.
ხშირად დასმული კითხვები
ყველა მობილურ აპს სჭირდება admin panel?
არა. თუ ბიზნესს არ აქვს ოპერატორის მიერ მონაცემის, სტატუსის ან კონტენტის მართვის საჭიროება, ცალკე პანელი შეიძლება ზედმეტი იყოს.
CMS საკმარისია ჯავშნების აპისთვის?
ჩვეულებრივ, არა. ჯავშნის სტატუსი, დროის კონფლიქტი, უფლებები და შეტყობინება backend-ის წესებსა და ოპერაციულ ეკრანებს მოითხოვს.
რა არის backend-ის მიღების მტკიცებულება?
მტკიცებულებაა წინასწარ დაწერილი სცენარი, სადაც ჩანაწერი იქმნება, სწორი როლი ხედავს მას, აკრძალული მოქმედება იბლოკება და ცვლილების კვალი ინახება.
დაკავშირებული მასალა
- მობილური აპის მოთხოვნების ჩეკლისტი
- დეველოპერის შერჩევის კრიტერიუმები
- aiAPP-ის სამუშაოს მოცულობის განხილვა
- ინტეგრაციების სამუშაო საზღვარი
- უსაფრთხოების მიმდინარე ინფორმაცია
გამოყენებული წყაროები
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.