Talablar, IA, flowchart tayyorlash

1. Kirish: rejalashtiruvchi 'ekran' emas, 'jarayon'ni loyihalashda

IT sohasynda xizmat rejalashtiruvchining roli ko'pincha "sketch chizadigan va ekran chizadigan odam" deb noto'g'ri tushuniladi. Dizayn vositalaridan foydalangan holda tugmachalarni joylashtirish va wireframeni yaratish eng ko'zga tashlanadigan ish hisoblanadi.

Biroq, vizual ekran rejalashtiruvchi tomonidan aniqlangan ko'plab mantiq va siyosatlarning nihoyat yuzaga kelgan 'natijasi'dir. Aslida rejalashtiruvchining roli biznesning noaniq talablarini ishlab chiqish va dizayn bo'yicha mumkin 'struktural til'ga tarjima qilish, xizmatning boshlanishidan tortib ishga tushirish oldidagi QA gacha butun mahsulot muddatini (Product Life Cycle) diqqat bilan boshqarishdir.

Kema ma'lumotlarini boshqarish uchun yangi xizmatni to'g'ridan-to'g'ri qurib, rejalashtirishning 3 ta asosiy ustunidan talablar, IA, flowchart orqali muammoni hal etish va o'sish tarixini baham ko'rishga harakat qilaman.

2. Talablar tahlili va aniqlash: ekran to'ldirishga shoshilgan kunlarda aniqlangan SRSning asosiy qismlari

Loyihani amalga oshirayotganda, amaliyot yoki mijozlardan "ushbu ekranda bunday ma'lumotlar ko'rsatilishini buyurish", "ushbu funksiyani ham qo'shishni so'rash" kabi ko'plab talablar olishimiz mumkin. Rejalashtirishning dastlabki bosqichlarida men ham bu talablarni ekranga juda shoshilib joylashtirishga harakat qildim. Avvaliga tugmachalarni yaratib va input qutilarini joylashtirishga kirishib, talablarni vizualizatsiya qilishga ko'p e'tibor berdim. Lekin yangi loyihani boshqarayotganimda, rejalashtirish jarayonini chuqur qayta ko'rib chiqsam, bu jarayon talablar aniqlanishining asosi ekanligini angladim.

2.1 Talablar tahlilining 4 bosqichli jarayoni

Amaliyotda men ushbu noaniqlikni aniqlikka o'zgartirish uchun 4 bosqichli jarayondan o'tdim: tadqiqot, talablarni aniqlash va tahlil qilish, talablarni aniqlash, talablarni tekshirish va boshqarish.
[1. Tadqiqot] ➔ [2. Talablarni aniqlash/tahlil qilish] ➔ [3. Talablarni aniqlash] ➔ [4. Talablarni tekshirish/boshqarish]

• Tadqiqot

• Loyihani amalga oshirish zarurligini va resurslarga nisbatan amalga oshirish mumkinligini (Texnik/Biznes Tadqiqoti) ko'rib chiqamiz.

• Talablarni aniqlash va tahlil qilish

• Amaliyot (foydalanuvchi) dan ishlab chiqmoqchi bo'lgan tizimning funktsiyalari to'g'risida ma'lumotlarni eshitamiz va tartibga solamiz. Rejalashtiruvchi pasiv ravishda yozib olish emas, balki zarur bo'lgan ma'lumotlarni teskari so'rab, foydalanuvchi nuqtai nazaridan ssenariy ko'rinishida foydalanish holatlarini (Use Case) aniqlashi kerak.

• Talablarni aniqlash

• Tahlil qilingan ssenariy asosida tizimning ish faoliyatini tasvirlaydigan funktsional (Functional) va tizimning xususiyatlari, cheklovlari, unumdorligiga aloqador bo'lmagan (Non-Functional) qismlarini aniqlab, aniqlik bilan yozib beramiz.

• Talablarni tasdiqlash va boshqarish

• "Mijoz nima xohlayotganini bilish", "Rivojlantirish mumkinmi", "Sinov orqali tasdiqlash mumkinmi" turli qismlar (rivojlantirish/dizayn/ishbilarmonlik) nuqtai nazarlarini tekshirib, fikr-mulohazalarni aks ettiradi. Keyinchalik o'zgarish tarixini (o'zgartirish sanasi, o'zgartirish elementlari va boshqalar) doimiy ravishda kuzatib boradi.

Talablarni tahlil qilishda e'tibor berish kerak bo'lgan jihatlar

Talablarni tahlil qilish jarayonida men his qilgan amaliy e'tibor berilishi lozim bo'lgan jihatlar mavjud.

• Mazmunni iloji boricha batafsil tahlil qilish: 'Kirish funksiyasi kerak' emas, balki 'qanday vosita bilan, qanday istisno qaytarlash kiritilishi'gacha chuqurlashish kerak.

• Haqiqiy ish olib boruvchining atamalarida bevosita yozish: Muloqot xatolarini kamaytirish maqsadida dastlab domen mutaxassisi yoki haqiqiy ishlovchilarning ishlatadigan so'zlarini bevosita arxivlash kerak.

• Yozma ko‘rsatma va tasdiqlash: Tahrirlangan ma'lumotlar albatta elektron pochta yoki rasmiy hamkorlik vositalari orqali muvofiq shaxslar bilan ulashilib, oxirgi tasdiq olinishi kerak. Bu kelajakda yuz berishi mumkin bo'lgan doira aniqlash (Scope) mojarolarini oldini oluvchi mudofaa chizig'i bo'ladi.

2.2 Talablar belgisi (SRS) tuzilishi va yozish misoli

Talablar belgisi (Software Requirement Specification) "sistemani qanday (How) bajarish haqida emas, balki nimalarni (What) bajarish haqida" yozilgan hujjatdir.

• Asosiy tuzilma elementlari: Talab ID, tasnif/element, batafsil ma'lumot, talab qiluvchi/talab sanasi, ahamiyati (ustuvorligini), qiyinligi, qabul qilinishi, mas'ul shaxs, mas'ul shaxsning fikri, izoh

Talablar belgisi bo'yicha amaliy qo'llanma misoli

Talablar hujjatini ko'rib chiqish ro'yxati

Quyidagi ro'yxat orqali talablar to'g'ri tartiblanganligini tekshirishingiz mumkin.

• [ ] Barcha talablar noaniq emas va aniq, konkretmi?

• [ ] Oddiy oqimdan tashqari, istisno vaziyatlari va xato ishlov berish aniq ravishda kiritilganmi?

• [ ] Hozirgi infratuzilma va resurslar bilan texnik jihatdan amalga oshirish mumkinmi?

• [ ] Sinov natijasi haqiqat/yolg'on bo'yicha aniq ajratiladigan sinov qilinadigan mezonlar taqdim etilganmi?

• [ ] Bitta talab boshqa talablar bilan mantiqan to'qnashmaydimi?

• [ ] Shaxsiy ma'lumotlarni himoya qilish to'g'risidagi qonun va xavfsizlik hamda qoidalarni bajarganligini inobatga olganmizmi?

• [ ] Milestone'ga muvofiq ustuvorlik (yuqori/o'rta/past) tegishli ravishda belgilanganmi?

3. Xizmat strukturasini loyihalash (IA, flowchart)

3.1 Axborot tuzilmasi (IA, Information Architecture)

Endi xizmatning umumiy ekran va menyu strukturasini tizimli ravishda loyihalashni boshlaymizAxborot tuzilmasi (IA, Information Architecture)tasdiqlash bosqichiga o'tamiz. Bo'sh holatda katta kemalar ma'lumotlari bilan to'qnashganda, foydalanuvchi tizim ichida yo'qolmasligi uchun katta menyu va kichik menyuni klassifikatsiya qilib, guruhlab chuqur (Depth) tuzilmani tuzish jarayoni zarur edi.

• Depth loyihalash qoidalari:Foydalanuvchi murakkabligini pasaytirish va charchoqni kamaytirish maqsadida, iloji boricha barcha menyular 3Depth dan pastbo'lishini loyihalash prinsipi sifatida olayapmiz. Albatta, kema boshqaruvi tizimidagi murakkab tuzilma kabi holatlarda bosqichma-bosqich ko'rsatish kerak bo'lgan ekranlar ko'payishi mumkin, lekin shuningdek aniq mantiqiy asosda Depth'ni minimal darajada saqlashga harakat qilinishi kerak.

• Ekran ID qoida qoidalari:IA'ga ro'yxatga olingan har bir sahifa o'ziga xos ekran ID'sini oladi.

• 1~2 Depth menyu nomi qisqartmalari:Katta menyuning inglizcha nomini 2 ta katta harf bilan qisqartirib foydalanamiz. (masalan: A'zolik boshqaruvi ➔ MB)

• Chuqun mãnózi kodi:Chuqun mãnózi raqamlar bilan ajratib, ekran orasida qoidalar beriladi. (masalan: MB_01, MB_01_01)

• Ekran shakli ajratish qisqartmasi:Tafsilotlarga qarab shakl (Ro'yxat, Tafsilot, Popup va boshqalar) suffix sifatida qo'shib ajratish ham mumkin.

• Mutlaq qoidalar:ID hech qachon takrorlanmasligi kerak, rejalashtirish o'zgarishi tufayli ma'lum ID o'zgartirilsa yoki o'chirilsa ham, ushbu IDni boshqa ekranlarda qayta ishlatmaslik tarix boshqaruvining tamoyili hisoblanadi.

• IA asosiy tarkibiy qismlari:Tasnif, xizmat chuqurligi (1/2/3), xizmat ekrani raqami, ekran ID, sahifa ta'rifi va talablar, batafsil ma'lumotlar, jarayon bosqichlari (kutish/rejalashtirilmoqda/tugallandi)

3.2 Flowchart (Oqim chizmasi)

Oqim chizmasi ekran va funksiyalardan foydalanib, foydalanuvchining harakat yo'nalishi va tizimning qayta ishlash jarayonini sxemalashtiruvchi hujjatdir. Foydalanuvchi qanday jarayon orqali xizmatlardan foydalanishi va tizim ichida qanday ishlashi haqida bir qarashda tushunishga yordam beradi.

Xususan, men olib borgan kemalar boshqaruv xizmatiga rejalashtirish jarayonida, ko'plab ekranlar o'zaro bog'langan holda ishlaydi yoki murakkab ma'lumot istisno holatlari doimiy ravishda yuzaga kelardi. Dastlab, eskicha uslubda storyboard (ekran loyihasi) wireframing yonida matnda istisno holatlarini qandaydir uzun va batafsil yozsangiz ham, reja maqsadimni 100% yetkazish juda qiyin edi.

Ushbu muammoni hal qilish uchun, xalqaro standart belgilari (boshlanish, jarayon, qaror tarmog'i va boshqalar)ga amal qilgan oqim chizmasini chizib, dasturchilarga birga yetkazdim. Foydalanuvchining harakat yo'nalishlari chalkash bo'lmasligi uchun shart tarmog'iga (romb) qarab oqimni aniq tarzda tekislashtirishga e'tibor qaratdim.

Oqim chizmasini yozish jarayonida rioya qilinishi zarur bo'lgan xalqaro standart qoidalar

• Standart belgilardan foydalanish:Boshlanish/tugash (yumaloq to'rtburchak), jarayon (to'rtburchak), taqqoslash/qaror (romb) va boshqalar xalqaro standart belgilarga qat'iy rioya etiladi.

Vakolatli xalqaro flovchart shakli (ISO 5807 xalqaro standarti)

• Qiziqishning oqimi: Foydalanuvchi yo'nalishi umumiy ravishda chapdan o'ngga yoki yuqoridan pastga tabiiy ravishda o'tishi kerak.

• Qaror bo'yicha ajratish: Raqamli (taqqoslash/qaror) belgisidan foydalanilganda, natija odatda Yes bo'lsa pastki o'q, No bo'lsa chap/o'ng o'q bilan ko'rsatiladi.

• Kiruvchi va chiquvchi tamoyillar: Taqqoslash va qaror bo'yicha kiruvchi va chiquvchi o'tkazgichlar har doim mantiqiy ravishda aniq bo'lishi kerak va jarayon bo'yicha oqimni murakkab qilib o'rnatmaslik uchun bir tarmoqli bo'lishi kerak.

• Tavsiya etilgan vositalar: Amaliyotda Draw.io, Visio, Axure yoki so'nggi paytlarda katta mashhurlikka ega bo'lib turgan Figma va Mirodan foydalaniladi.

4. Xulosa: Mustahkam ramka kamchiliksiz xizmat yaratadi

Kema ma'lumotlari xizmatini rejalashtirganda, rejalashtiruvchi oddiygina 'ekran chizuvchi' emas, balki qat'iy 'mantiq' va o'zaro 'jarayon'ni quruvchi deb hisoblash kerak.Tizim arxitektoriyaqinroqdir.

Agar dastlab ekran dizayniga hayratda bo'lgan bo'lsak, bu katta ma'lumot xizmatini hech qachon boshlamaymiz. Oldinda talablarni tozalab, IA yordamida ramka tuzib va flovchart orqali yo'nalishni aniq belgilash natijasida ishlash mumkin edi.

Bu maqolada xizmatning yuqori tushunchalari va tuzilishini mustahkam qurganimizda, keyingi postda shunday tuzilmalarga asoslanib dizaynerlar va dasturchilar bilan muloqot qilish uchun yakuniy loyiha 'Yakuniy ekran loyihasi (story board)' ni yaratish tajribamni baham ko'rmoqchiman. Qo'shimcha ravishda, xizmatni ishga tushirishdan oldin mahsulot sifatini maksimal darajada oshirish maqsadida o'z qo'lim bilan test (QA) o'tkazish jarayonida olingan amaliy tajribamga qaytaman.

Ryu