Mavzu: Dasturlarning grafli modellariga misollar Ishdan maqsad

Mavzu: Dasturlarning grafli modellariga misollar
Ishdan maqsad: Dasturiy ta’minotni talablarni ishlab chiqish bo`yicha ko`nikmaga ega bo`lish.
Nazariy qism:
Ellik yildan ortiq vaqt mobaynida kompyuter sanoatiga qaramasdan, ko'plab dasturiy ta'minot kompaniyalari dasturiy ta'minotga talablarni to'plash, hujjatlashtirish va boshqarishda katta kuch sarflamoqda. Foydalanuvchilarning etarli ma'lumotlari, to'liq shakllantirilmagan talablar, ularning keskin o'zgarishi va biznesning maqsadlari noto'g'ri tushunilgani IT-jamoalari ko'pincha loyihalarni muvaffaqiyatli bajarolmasliklarining asosiy sababidir. ekt. Ko'pgina ishlab chiquvchilar foydalanuvchi dasturiy ta'minotiga bo'lgan talablarni qanday qilib xotirjam va professional ravishda to'plashni bilishmaydi . Mijozlar ko'pincha dasturiy ta'minotga bo'lgan talablarni ishlab chiqishda ishtirok etishda sabrsiz bo'lishadi.
Ba'zida loyiha ishtirokchilari hatto "talab" nima ekanligi to'g'risida bir fikrga kela olishmaydi. Bir yozuvchining ta'kidlashicha , "Dasturchilar mijozlarning talablaridan ko'ra Kingsmen klassik" Lui Louining "so'zlarini yaxshiroq tushunishadi" (Peterson 2002). "Dasturiy ta'minotga bo'lgan talablarni ishlab chiqish" kitobining ikkinchi nashri ushbu kitob nashr etilishidan 10 yil oldin nashr etilgan. Yilda axborot texnologiyalari olamida, bu uzoq vaqt. Bu vaqt ichida ko'p narsa o'zgardi, lekin bir narsa o'zgarishsiz qoldi. So'nggi o'n yillikning asosiy tendentsiyalari: biznes tahlilini professional intizom deb e'tirof etish va Xalqaro sertifikatlash va Xalqaro talablar bo'yicha muhandislik kengashi kabi tashkilotlarni kengaytirish; ma'lumotlar bazalarida talablarni boshqarish va talablarni ishlab chiqishni qo'llab-quvvatlash, shu jumladan prototiplash, modellashtirish va simulyatsiya qilish vositalarini ishlab chiqishning yuqori darajasiga erishdi; chaqqon rivojlanish usullarini tarqatish va chaqqon loyihalarda talablar bilan ishlash uslublarini ishlab chiqish; Visual modellari faol foydalanish uchun talablarni bilim vakili. Bas, nima bo'ldi, balki o'zgardi?
Ushbu qismni muhim va muhim qiladigan ikkita narsa bor. Birinchidan, ko'plab dasturiy ta'minotlarni ishlab chiqish va hisoblash tizimlarini o'qitish dasturlarida talablarni ishlab chiqish muhimligiga etarlicha e'tibor qaratilmagan (bu ikkalasini ham anglatadi rivojlanishning o'zi va talablarni boshqarish). Ikkinchidan, dasturiy ta'minot sohasida ishlaydiganlarning ko'pchiligi bizning muammolarimizni texnik va texnologik echimlarga haddan tashqari qiziqishmoqda. Va foydalanish - Biz ba'zan
Tre-boradigan düşürülemezler aniqlash unutmasligimiz ustida dasturiy ta'minot ishlab chiqish loyiha va in-umumiy tizimlarida ish eng - odamlar o'zaro bog'liq, birinchi navbatda asoslangan. Ushbu faoliyatni avtomatlashtirish uchun hech qanday yangi sehrli fokuslar paydo bo'lmagan va bozorda jug'rofiy taqsimlangan odamlarga samarali o'zaro ta'sir o'tkazishga imkon beradigan vositalar mavjud. Ikkinchi nashrda taqdim etilgan dizayn va talablarni boshqarish uslublari hanuzgacha ishlaydi va turli xil dasturiy ta'minot ishlab chiqish loyihalarida qo'llanilishi mumkinligiga ishonamiz.
Iqtidorli ishbilarmon tahlilchi, menejer yoki mahsulot egasi ushbu texnikani o'ziga xos vaziyatga mos ravishda moslashtiradi va kengaytiradi. Ushbu uchinchi nashrda chaqqon loyihalarda talablar bilan ishlash bo'yicha bo'lim va boshqa boblarda ham ushbu boblarda tasvirlangan usullarni chaqqon rivojlanishda qanday qo'llash va moslashtirish kerakligi ko'rsatilgan. Dasturiy ta'minot ishlanmasi ko'p muloqot sifatida kamida o'z ichiga oladi , deb va odatdagi kompyuter ishi, lekin ko'pincha biz kompyuter ishiga e'tibor qaratamiz va muloqotga etarlicha e'tibor bermaymiz. Ushbu kitobda ushbu aloqani amalga oshirishning o'nlab usullari va dasturiy ta'minotni ishlab chiquvchilar, menejerlar, sotuvchilar va mijozlarga dasturiy ta'minotga bo'lgan talablarni ishlab chiqish bo'yicha amaliy amaliyotlarni amalga oshirishga yordam berish ta'riflangan . Kitobda talablarni shakllantirishda yuzaga keladigan barcha muammolarni hal qilishga va'da beradigan ekzotik yoki ishlab chiqilgan metodologiyalar emas, balki talablarni shakllantirishning asosiy "ajoyib usullari" tasvirlangan.
Ko'p sonli yon panellarda men talablarni shakllantirishda yuzaga keladigan odatiy vaziyatlarni aks ettiradigan real hayotiy misollar keltiraman. Ushbu kitobning birinchi nashri 1999 yilda nashr etilganidan beri , mualliflarning har biri ko'plab loyihalar ustida ishlagan va tijorat va davlat tashkilotlari xodimlari uchun dasturiy ta'minotga oid yuzlab seminarlar o'tkazgan. Biz ushbu usullar deyarli har qanday loyihaga mos kelishini angladik: kichik va katta miqyosda, yangi dasturlarni ishlab chiqish va mavjudlarini kengaytirish, mahalliy va taqsimlangan jamoalardan foydalanib, rivojlanishning an'anaviy va chaqqon usullaridan foydalanish. Bundan tashqari, ushbu texnikalar dasturiy ta'minotni ishlab chiqish sohasi bilan cheklanmaydi va jihozlar va tizimlarni loyihalash uchun mos emas. Dasturiy ta'minotni ishlab chiqishning har qanday boshqa usulida bo'lgani kabi, talablarni shakllantirishning qaysi usuli siz uchun yaxshiroq ekanligini tushunish uchun aql-idrokni ishlatishingiz kerak. va siz ustiga barpo o'z tajriba.
Loyihalaringizdagi to'g'ri odamlar bilan samarali aloqada bo'lishingizga yordam beradigan vositalar sifatida tasvirlangan usullardan foydalaning. Dasturiy ta'minot bilan bog'liq ko'plab muammolar odamlarning dasturiy ta'minotga bo'lgan talablarni to'plash, hujjatlashtirish, yarashtirish va o'zgartirish usullaridan foydalanishda nomukammallikdan kelib chiqadi . Fil va Mariya singari muammolar norasmiy ravishda ma'lumot to'plash, taxmin qilinadigan funktsionallik, noto'g'ri yoki noto'g'ri taxminlar , talablarning nomuvofiqligi va afsonaviy jarayonning o'zgarishi natijasida paydo bo'lishi mumkin. Ko'pgina tadqiqotlar shuni ko'rsatadiki, talablarni yig'ish bosqichida yo'l qo'yilgan xatolar dasturiy mahsulotdagi barcha nuqsonlarning 40-50 foizini tashkil etadi (Devis, 2005). Kam foydalanuvchi fikringiz va mijoz talablariga aniqlash va boshqarish kamchiliklarning loyiha qobiliyatsiz asosiy sababi bor. Ushbu ma'lumotga qaramay, ko'plab tashkilotlar hali ham samarasiz talablarni yig'ish usullaridan foydalanmoqdalar. Boshqa hech bir joyda, talablarni to'plash bosqichida bo'lgani kabi , loyihadagi barcha manfaatdor tomonlarning manfaatlari loyihaning muvaffaqiyati bilan chambarchas bog'liqdir. (Manfaatdor tomonlar to'g'risida ko'proq ma'lumot olish uchun 2-bobga qarang.) Loyihaning manfaatdor tomonlariga mijozlar, foydalanuvchilar, biznes-tahlilchilar, ishlab chiquvchilar va boshqalar kiradi. Jarayonning ushbu bosqichini yaxshi bajarganingizda, siz ajoyib mahsulotga ega bo'lasiz, mijozlarni xursand qilasiz va mamnun ishlab chiquvchilar.
Yilda Aks holda, anglashilmovchilik, umidsizlik va ishonch putur kelishmovchiliklarni duch mahsulot va uning qiymati. Talablar ishlab chiquvchilarning ham, loyiha menejerlarining ham harakatlariga asos yaratadi, shu sababli ushbu hujjatni yaratishda loyihadagi barcha manfaatdor tomonlar ishtirok etishlari kerak. Ammo talablarni ishlab chiqish va boshqarish bu juda og'ir jarayon! Bu erda tezkor yoki sehrli echimlar yo'q. Biroq, ko'plab tashkilotlar bir xil qiyinchiliklarga qarshi kurashmoqdalar, buning uchun turli xil vaziyatlarda ishlaydigan umumiy texnikani topishimiz mumkin. Ushbu kitobda o'nlab bunday usullar tasvirlangan. Ular mutlaqo yangi tizimlarni yaratish vositasi sifatida baholanadi, ammo ular loyihalarni takomillashtirish, almashtirish va qayta ko'rib chiqish (21-bobga qarang) va savdo-sotiqdan tashqari echimlarni tanlash (22-bobga qarang). Chaqaloq metodologiyadan so'ng iterativ jarayonni tanlagan jamoalar har bir bosqichda nima qilish kerakligini bilishlari kerak (20-bobga qarang). Ushbu bo'limda siz qanday qilishni o'rganasiz.  dasturiy ta'minotga talablarni to'plashda ishlatiladigan asosiy atamalarni tushunish;  mahsulotga bo'lgan talabni va boshqalarni ajratib olish ;  dizayn va boshqaruv talablarini farqlay olish ;  vaqti-vaqti bilan paydo bo'lishi mumkin, ayrim talablar bilan bog'liq muammolar ogohlantirish belgilarini aniqlash.
Kompyuter dasturlashining paydo bo'lishidan o'nlab yillar o'tgach, dasturiy ta'minot muhandislari hali ham talab nima ekanligi haqida bahslashmoqdalar . Biz ushbu munozarada qatnashmaymiz, balki biz o'zimizga foydali deb topadigan ta'riflar to'plamini taqdim etamiz . Maslahatchi Brayan Lourens talablar "dizayn tanlovini belgilovchi narsa" ekanligini ta'kidlaydi (Lourens, 1997). Bu yaxshi norasmiy ta'rif, chunki ushbu toifaga ko'plab ma'lumot turlarini kiritish mumkin. Va pirovardida, talablarni ishlab chiqishning barcha nuqtasi - bu mijozni qoniqtirishi kerak bo'lgan tegishli dizayn qarorlarini qabul qilishdir. Talabning yana bir ta'rifi shundaki, mahsulot manfaatdor tomonlarga foyda keltirishi kerak . Yomon emas, lekin juda aniq emas. Ian Sommerville va Pit Soyyer (1997) tomonidan berilgan ta'rif: Talablar bu bajarilishi kerak bo'lgan narsalarning spetsifikatsiyasi. Yilda bu tasvirlangan harakati Istemi, tizim xususiyatlari, yoki sifatlari. Ular tizimni ishlab chiqish jarayonida cheklovlar bo'lib xizmat qilishi mumkin. Ushbu ta'rif umumiy talablar deb ataladigan turli xil ma'lumot turlarini hisobga oladi . Talablar foydalanuvchilarning qarashlari va tizimning tashqi xatti-harakatlarini, shuningdek ishlab chiqaruvchining ba'zi ichki xususiyatlariga nisbatan nuqtai nazarini qamrab oladi . Ular muayyan sharoitlardagi tizimning xattiharakatlarini va tizimni foydali va hatto oxirgi operatorlar uchun yoqimli qiladigan xususiyatlarni o'z ichiga oladi. Diqqat! Loyihangizdagi barcha manfaatdor tomonlar talablar to'g'risida umumiy tushunchaga ega deb o'ylamang . Boshlang'ich ta'riflarni o'rnating, shunda barchangiz bir xil tilda gaplashasiz.
Odamdan og'zaki ravishda uzatiladigan ma'lumotni emas, balki almashish uchun foydalanish mumkin bo'lgan shaklda hayotiy talablar yozma yozuvining qiymatini tushunish muhimdir. Bir vaqtlar men ishlab chiqish guruhlari tez-tez o'zgarib turadigan loyihada ishlaganman. Asosiy mijoz har bir yangi jamoa unga: "Biz talablar haqida gaplashishimiz kerak" degan so'zlar bilan kelganidan norozi edi. Uning bu iltimosiga munosabati quyidagicha edi: “Men avvalgilarimga mening talablarim haqida aytib berdim. Shunday qilib, tizimni qurishni boshlang! "Afsuski, hech kim talablarni hujjatlashtirishga qiynalmadi, shuning uchun har bir yangi jamoa noldan boshlashi kerak edi. Hech bo'lmaganda, siz bir nechta elektron pochta xabarlari va ovozli pochta xabarlari, bir qator yopishqoq qaydlar, uchrashuv daqiqalari va mijozlarning suhbatlarining noaniq xotiralariga ega bo'lsangiz, "talabingiz bor" deb da'vo qilish mas'uliyatsizdir. Ushbu loyihaga talablar hujjatlari qanchalik to'liq bo'lishi kerakligini aniqlash uchun tahlilchi ehtiyotkorlik bilan yondashuvni ishlab chiqishi kerak. Shaklda 1-1, uchta asosiy talab hujjatlari ko'rsatildi: tushuncha va chegara hujjati, foydalanuvchi talablari to'g'risidagi hujjat va dasturiy ta'minotga talablar spetsifikatsiyasi. Har bir loyihada ushbu uchta alohida hujjatni yaratish har doim ham shart emas. Ko'pincha bir ma'lumotni, ayniqsa kichik loyihalarda birlashtirish maqsadga muvofiqdir. Biroq, siz ushbu uchta hujjat turli xil ma'lumotlarni o'z ichiga olganligini, loyihaning turli bosqichlarida, ehtimol hatto turli maqsadlarga ega va turli maqsadli auditoriyaga ega bo'lgan turli odamlar tomonidan ishlab chiqilganligini tushunishingiz kerak. Shakldagi model. 1-1 talablar to'g'risidagi ma'lumotlarning oddiy yuqoridan pastga qarab oqishini ko'rsatadi.
Aslida, foydalanuvchi, funktsional va biznesga oid tsikllar va takroriyliklar bo'lishi mumkin. Har safar kimdir yangi xususiyatni, odatiy talabni yoki funktsionallikni yaxshilashni taklif qilganda, tahlilchi "Bu loyihaga mos keladimi?" Degan savolni berishi kerak. Agar javob ha bo'lsa, talab spetsifikatsiyada bo'lishi kerak. Aks holda, hech bo'lmaganda joriy versiyada yoki iteratsiyada hech qanday talab bo'lmasligi kerak. Uchinchi mumkin bo'lgan javob: "Yo'q, lekin u biznes maqsadini qo'llab-quvvatlaydi, shuning uchun u spetsifikatsiyada bo'lishi kerak." Bunday holda, loyiha doirasi uchun mas'ul shaxs - kurator, menejer yoki loyiha menejeri - yangi talabni kiritish uchun joriy loyihani yoki iteratsiyani kengaytirishni tanlash kerak. Bu loyiha jadvali va byudjetiga ta'sir qiladigan va boshqa imkoniyatlarni qurbon qilishni talab qiladigan biznes qarori. O'zgarishlarni boshqarishning samarali jarayoni, shu jumladan ta'sirni tahlil qilish, "to'g'ri odamlar" biznesni qaror qabul qilishini, ular o'zgarishi kerak bo'lgan vaqt yoki resurs xarajatlari yoki savdolar hisobga olinishini ta'minlaydi.