I. Nazariy qism >II. Amaliy qism

1-Dedline

Reja:

I. Nazariy qism

II. Amaliy qism

III. Xulosa

Muhammadqodirov Muhiddin–– 651-18.

Use Case Diagram

Foydalanish holatlarining diagrammasi eng sodda tarzda foydalanuvchining tizim bilan o'zaro munosabati va foydalanuvchi o'rtasidagi munosabatlarni aks ettiruvchi foydalanish hisoblanadi. Foydalanish holatlarining diagrammasi tizim foydalanuvchilarining har xil turlarini va turli xil foydalanish holatlarini aniqlashi mumkin va ko'pincha boshqa diagrammalar bilan birga keladi. Foydalanish holatlari aylana yoki ellips bilan ifodalanadi.

Ilova

Foydalanish holatining o'zi har qanday imkoniyat haqida ko'p tafsilotlarni o'rganishi mumkin bo'lsa-da, foydalanish sxemasi tizimning yuqori darajadagi ko'rinishini ta'minlashga yordam beradi. Bundan oldin aytilgan edi "Ish diagrammalaridan foydalanish bu sizning tizimingiz uchun chizmalardir". [1] Ular tizim aslida nima qilishi kerakligini soddalashtirilgan va grafik tasvirlashni ta'minlaydi.

Ularning soddaligi sababli, foydalanish jadvallari manfaatdor tomonlar uchun yaxshi aloqa vositasi bo'lishi mumkin. Chizmalar haqiqiy dunyoga taqlid qilishga va manfaatdor tomonlarga tizim qanday ishlab chiqilishini tushunishga imkon beradi. Siau va Li, vaziyatlar sxemalarini umuman ishlatish uchun kerak bo'lgan vaziyat mavjudligini yoki keraksizligini aniqlash uchun tadqiqotlar o'tkazdilar. Aniqlanishicha, foydalanish holatlarining diagrammalari tizimning maqsadini soddalashtirilgan tarzda manfaatdor tomonlarga etkazishgan va ular "sinf diagrammalariga qaraganda to'liqroq talqin qilingan". [2]

Ish diagrammalaridan foydalanishning maqsadi shunchaki tizimning yuqori darajadagi ko'rinishini ta'minlash va talablarni tomonlar nuqtai nazaridan manfaatdor tomonlarga etkazishdir. Tizimning to'liq funktsional va texnik ko'rinishini ta'minlash uchun qo'shimcha sxemalar va hujjatlardan foydalanish mumkin.
Agile dasturiy ta'minoti

Dasturiy ta'minotni ishlab chiqishga dasturiy ta'minotni ishlab chiqarishga turli xil yondashishlar kiradi, ular asosida talablar va echimlar o'zini o'zi tashkil etuvchi va funktsional guruhlar va ularning mijozlari (mijozlari) / oxirgi foydalanuvchilari (lar) ning birgalikdagi sa'y-harakatlari natijasida yuzaga keladi. [1] U adaptiv rejalashtirishni, evolyutsion rivojlanishni, erta tug'ilishni va doimiy takomillashtirishni qo'llab-quvvatlaydi va o'zgarishlarga tez va moslashuvchan javob qaytarishni rag'batlantiradi.

Agile (ba'zan yozilgan Agile) atamasi [3], shu nuqtai nazardan, Agile dasturiy ta'minotini ishlab chiqish Manifesti tomonidan ommalashtirilgan. Ushbu manifestda ilgari surilgan qadriyatlar va printsiplar Scrum va Kanban singari dasturiy ta'minotni ishlab chiqish doiralarining keng doirasidan kelib chiqqan va qo'llab-quvvatlangan. [5] [6]

Chaqqon amaliyotlar va qadriyatlarni qabul qilish dasturiy ta'minot bo'yicha mutaxassislar, jamoalar va tashkilotlarning chaqqonligini yaxshilaganligi haqida juda ko'p dalillar mavjud bo'lsa-da, ba'zi bir empirik tadqiqotlar bu dalilni shubha ostiga qo'ydi.

Tarixi.

Iterativ va bosqichma-bosqich rivojlanish usullarini 1957 yil boshlarida ko'rish mumkin, [9] evolyutsion loyihani boshqarish [10] [11] va moslashuvchan dasturiy ta'minotni ishlab chiqish [12] 1970-yillarning boshlarida paydo bo'lgan. [13]

1990-yillarda, tanqidchilar haddan tashqari tartibga solingan, rejalashtirilgan va mikro boshqariladigan deb tasvirlangan og'ir vaznli usullarga (masalan, sharsharalarga) nisbatan engil dasturiy ta'minotni ishlab chiqish usullari rivojlandi. Bularga quyidagilar kiradi: 1991 yildan boshlab tezkor dasturlar (RAD); 1994 yildan boshlab birlashtirilgan jarayon (UP) va dinamik tizimlarni ishlab chiqish usuli (DSDM); Skrum, 1995 yildan; 1996 yildan boshlab Crystal Clear va ekstremal dasturlash (XP); va bularning barchasiga asoslangan rivojlanish 1997 yildan beri. Garchi bularning barchasi Agile Manifesti nashr etilishidan oldin paydo bo'lgan bo'lsa-da, hozir ularni birgalikda dasturiy ta'minotni ishlab chiqish usullari deb atashadi. Shu bilan birga, ishlab chiqarish [16] va aerokosmik sohalarda ham shunga o'xshash o'zgarishlar ro'y berdi. [17]

2001 yilda ushbu o'n ettinchi dasturiy ta'minot ishlab chiqaruvchilari Snoubirdagi (Yuta shtati) dam olish maskanida yig'ilishib, ushbu engil rivojlanish usullarini muhokama qilishdi: Kent Bek, Vard Kanningem, Deyv Tomas, Djef Sazerland, Ken Shvaber, Jim Xossmit, Alistair Kokbern, Robert S. Martin, Mayk Bidl , Arie van Bennekum, Martin Fouller, Jeyms Grenning, Endryu Xunt, Ron Jeffri, Jon Kern, Brayan Marik va Stiv Mellor. Ular birgalikda Agile Software Development Manifestini nashr etishdi. [4]

2005 yilda Cockburn va Highsmith boshchiligidagi guruh dasturiy ta'minotni boshqarish dasturlarini ishlab chiqish usullariga muvofiq boshqarish uchun loyihani boshqarish printsiplari, Bosh vazirning o'zaro bog'liqlik deklaratsiyasini [18] yozdi.

2009 yilda Martin bilan birga ishlaydigan guruh, dasturiy ta'minotni ishlab chiqish tamoyillarini, dasturiy ta'minotni ishlab chiqarishni rivojlantirish manifestini, professional dastur va mahoratga muvofiq dasturiy ta'minotni ishlab chiqishni boshqarish uchun yozdi.

2011 yilda Agile Alliance Agile Practice qo'llanmasini (2016 yilda Agile lug'ati deb o'zgartirilgan) yaratdi, [19] tezkor amaliyotlar, atamalar va elementlarning ishchi ta'riflari, shuningdek, sharhlar va tajriba qo'llanmalarining rivojlanayotgan ochiq manbali to'plami. chaqqon amaliyotchilarning butun dunyo hamjamiyati.
Agile dasturiy ta'minotini ishlab chiqish uchun manifest
Dasturiy ta'minotni ishlab chiqish uchun tezkor dasturlar

Dasturiy ta'minotni ishlab chiqish va boshqalarga bu kabi ishlarni amalga oshirishda qo'shma tajribaga asoslanib, manifestning o'n etti a'zosi o'zlarini qadrlashlarini aytdilar:

• 
  Jarayonlar va vositalar bo'yicha shaxslar va o'zaro munosabatlar
  
• 
  Keng qamrovli hujjatlar ustida ishlaydigan dasturiy ta'minot
  
• 
  Shartnoma muzokaralari bo'yicha mijozlar bilan hamkorlik qilish
  
• 
  Rejaga muvofiq o'zgarishlarga javob berish
  

Ya'ni chapdagi narsalar o'ngdagi narsalarga qaraganda ko'proq qadrlanadi.

Skott Ambler tushuntirganidek:

Asboblar va jarayonlar muhimdir, ammo vakolatli odamlarning samarali ishlashi muhimroqdir.

Yaxshi hujjatlar odamlarga dasturiy ta'minot qanday yaratilganligini va undan qanday foydalanishni tushunishda yordam beradi, ammo ishlab chiqishning asosiy maqsadi hujjatlar emas, balki dasturiy ta'minot yaratishdir.

Shartnoma muhim, ammo mijozlar bilan yaqindan ishlash uchun kerakli narsalarni topish uchun uni almashtirmaydi.

Loyihaning rejasi juda muhim, ammo texnologiya yoki atrof-muhitdagi o'zgarishlarni, manfaatdor tomonlarning ustuvorliklarini va odamlarning muammo va uning echimini tushunishini hisobga oladigan darajada qattiq bo'lmasligi kerak.

Ba'zi mualliflar "Agile Alliance" nomli notijorat tashkilotini tuzdilar, u manifestning qadriyatlari va printsiplariga muvofiq dasturiy ta'minotni ishlab chiqishni qo'llab-quvvatlaydi. Jim Highsmith, Agile Alliance nomidan manifestni tanitib, dedi.

Agile harakati bu anti-metodologiya emas, aslida ko'pchiligimiz so'z metodologiyasiga bo'lgan ishonchni tiklashni xohlaymiz. Biz muvozanatni tiklamoqchimiz. Biz changyutgichli korporativ omborida ba'zi diagramma berish uchun emas, balki modellashtirishni boshlaymiz. Biz hujjatlarni o'z ichiga olamiz, lekin hech qachon ishlamaydigan va kamdan-kam ishlatiladigan tomlarning yuzlab sahifalarini emas. Biz rejalashtirmoqdamiz, lekin turbulent muhitda rejalashtirish chegaralarini bilamiz. "Xakerlar" sifatida XP yoki SCRUM yoki boshqa har qanday Agile metodologiyasini qo'llab-quvvatlovchilar ikkala metodologiyani ham, xaker atamasining asl ta'rifini ham bilishmaydi.

- Jim Highsmit, Tarix: Agile Manifesti [21]

Dasturiy ta'minotni ishlab chiqish tamoyillari

Dasturiy ta'minotni ishlab chiqarishga bag'ishlangan manifest 12 o'n tamoyilga asoslanadi: [22]

• 
  Mijozlarni qimmatbaho dasturiy ta'minotni erta va uzluksiz etkazib berish orqali qondirish.
  
• 
  O'zgarish talablarini xush kelibsiz, hatto kech rivojlanishda ham.
  
• 
  Tez-tez ishlaydigan dasturlarni etkazib berish (oylar emas, balki haftalar)
  
• 
  Ishbilarmon odamlar va ishlab chiquvchilar o'rtasidagi yaqin, kunlik hamkorlik
  
• 
  Loyihalar ishonchga sazovor bo'lgan odamlar atrofida quriladi
  
• 
  Yuzma-yuz gaplashish eng yaxshi aloqa shakli (qo'shma joylashuv)
  
• 
  Ishlaydigan dasturiy ta'minot taraqqiyotning asosiy o'lchovidir
  
• 
  Barqaror rivojlanish, doimiy sur'atni saqlab turishga qodir
  
• 
  Texnik mukammallik va yaxshi dizaynga doimiy e'tibor
  
• 
  Oddiylik - bajarilmagan ish hajmini oshirish san'ati juda muhimdir
  
• 
  Eng yaxshi me'morchiliklar, talablar va dizaynlar o'zini o'zi tashkil etuvchi jamoalardan kelib chiqadi
  

Doimiy ravishda, jamoa qanday qilib yanada samaraliroq bo'lishni o'ylaydi va shunga mos ravishda moslashtiradiIterativ, bosqichma-bosqich va evolyutsion tahri

Chaqqon rivojlanish usullarining aksariyati mahsulotni ishlab chiqish ishini oldindan rejalashtirish va dizayn hajmini minimallashtiradigan kichik o'sishga ajratadi. Qaytarishlar yoki sprintlar - bu odatda bir dan to'rt haftagacha davom etadigan qisqa vaqt oralig'i (vaqt qutilari). Har bir iteratsiya barcha funktsiyalarda ishlaydigan o'zaro faoliyat funktsional guruhni o'z ichiga oladi: rejalashtirish, tahlil qilish, loyihalash, kodlash, birlik sinovlari va qabul qilish testlari. Iteratsiya oxirida ishlaydigan mahsulot manfaatdor tomonlarga namoyish etiladi. Bu umumiy xavfni minimallashtiradi va mahsulotga tez o'zgarishlarga moslashish imkonini beradi. [23] Iteratsiya bozorni chiqarishni kafolatlash uchun etarli funktsiyani qo'shmasligi mumkin, ammo maqsad har bir iteratsiyaning oxirida mavjud bo'lgan (minimal xatolar bilan) mavjud bo'lishdir. [24] Mahsulotni yoki yangi xususiyatlarni chiqarish uchun bir necha marta takrorlanish talab qilinishi mumkin. Dasturiy ta'minot taraqqiyotning asosiy o'lchovidir.

Birgalikda joylashish printsipi shundaki, bir jamoada ishlaydigan ishchilar birlashishni birlashtirib, bir jamoa sifatida identifikatsiyani yaxshilash va aloqani yaxshilash uchun kerak. Bu, oq doska oldida, yuzma-yuz muloqotga imkon beradi, bu odatda savol va javoblar telefon, doimiy chat, wiki yoki elektron pochta orqali vositachilanganda olinadigan tsikl vaqtini qisqartiradi. [26]

Rivojlanishning qaysi uslubiga rioya qilinmasin, har bir jamoa o'z mijozining vakilini o'z ichiga olishi kerak (Scrum-dagi "Mahsulot egasi"). Ushbu shaxs manfaatdor tomonlar tomonidan ularning nomidan ish olib borishga rozi bo'ladi va ishlab chiquvchilar iteratsiya davomida savollarga javob berishga tayyor bo'lish majburiyatini oladi. Har bir iteratsiyaning yakunida, manfaatdor tomonlar va mijoz vakili investitsiyalarning daromadliligini (ROI) optimallashtirish va mijozlar ehtiyojlari va kompaniyaning maqsadlariga muvofiqligini ta'minlash maqsadida taraqqiyotni qayta ko'rib chiqadilar va ustuvorliklarni qayta baholaydilar.

Chaqqon dasturiy ta'minotni ishlab chiqishda, ma'lumot radiatori (odatda katta hajmdagi) fizik displey bo'lib, uni ishlab chiquvchilar jamoasi yaqinida joylashgan bo'lib, undan o'tgan odamlar ko'rishlari mumkin. Unda mahsulotni ishlab chiqish holati to'g'risida so'nggi ma'lumotlar keltirilgan. [27] [28] Jamoani o'z mahsulotlarini ishlab chiqarishning hozirgi holati to'g'risida xabardor qilish uchun qurilgan yorug'lik indikatoridan ham foydalanish mumkin.

Juda qisqa geribildirim halqa va moslashuv tsikli Edit

Chaqqon dasturiy ta'minotni ishlab chiqarishda keng tarqalgan belgi - bu kunlik turish (Scrum doirasida kundalik skrum). Qisqa majlisda, jamoa a'zolari bir-birlariga oldingi kuni jamoaning iteratsiya maqsadi bo'yicha nima qilganliklari, bugungi kunda ushbu maqsadga erishish uchun nima qilishni rejalashtirishlari va ular maqsadga erishishda qanday to'siqlar va to'siqlar bo'lishlari haqida bir-birlariga hisobot berishadi. [29]

Sifat yo'nalishiEdit

Uzluksiz integratsiya, avtomatlashtirilgan blok sinovi, juft dasturlash, test asosida ishlab chiqish, dizayn namunalari, xulq-atvor asosida ishlab chiqish, domenga asoslangan dizayn, kodni qayta ishlash va boshqa texnikalar kabi maxsus vositalar va texnikalar ko'pincha mahsulot sifatini oshirish va oshirish uchun ishlatiladi. chaqqonlik. [30] Bu boshida loyihalashtirish va qurish sifatiga bog'liq va mijozlar uchun dasturiy ta'minotni istalgan nuqtada yoki hech bo'lmaganda har iteratsiyaning oxirida namoyish eta olish qobiliyatiga ega.

FalsafaEdit

An'anaviy dasturiy injiniring bilan taqqoslaganda, tezkor dasturiy ta'minot asosan murakkab tizimlar va dinamik, noaniq va nochiziqli xususiyatlarga ega mahsulotni ishlab chiqishga qaratilgan. Aniq hisob-kitoblar, barqaror rejalar va bashoratlarni ko'pincha erta bosqichlarda topish qiyin va ularga bo'lgan ishonch past bo'lishi mumkin. Chaqqon amaliyotchilar qiymat dalillarini olishdan oldin zarur bo'lgan ishonchni pasaytirishga harakat qiladilar. Talablar va dizayn paydo bo'lishi kerak. Old tomondan katta texnik xususiyatlar, ehtimol, bunday hollarda ko'p chiqindilarni keltirib chiqarishi mumkin, ya'ni iqtisodiy jihatdan maqsadga muvofiq emas. Ushbu asosiy dalillar va yillar davomida erishilgan yutuqlar va muvaffaqiyatsizliklardan o'rganilgan tajriba, moslashuvchan, iterativ va evolyutsion rivojlanishni rivojlantirishga yordam berdi.

Rivojlanish usullari moslashuvdan bashorat qilishgacha bo'lgan doimiylikda mavjud. Chaqqon dasturiy ta'minotni ishlab chiqish usullari ushbu doimiylikning moslashuv tomonida. Adaptiv rivojlanish usullaridan biri kalitlarni rejalashtirishga siljigan to'lqinli yondashuv bo'lib, bu bosqichlarni aniqlaydi, ammo ularga erishish yo'lida moslashuvchanlikni qoldiradi va bosqichlarning o'zlarini o'zgartirishga imkon beradi.

Agile dasturiy ta'minotini ishlab chiqish: BurnUp Chart, SimulTrain loyihasini boshqarish simulyatsiyasida mijozlar uchun yaratilgan qiymat dinamikasini (hikoya nuqtalari) ko'rsatadi.
II. Amaliy qism.



III. Xulosa

Men ushbu amaliy mashg’ulotni bajarish davomida UML haqida ko’plab ma’lumotlarga ega bo’ldim. Quyida xulosa o’rnida Martin Fowlerning UML haqida so’zlarini keltirib o’tishni ma’qul ko’rdim.

UML haqida gapirganda, men taxminan 13 ta turli diagramma turlarini o'z ichiga olgan ko'plab odamlar (uchta amigos, Rumbaugh, Booch va Jacobson eng ko'p ko'rinadigan) tomonidan yaratilgan tizim haqida o'ylayman. Ehtimol, Rational Unified Process (RUP) orqali tasvirlangan rivojlanishning hayot aylanish davriga bog'liq bo'lishi mumkin, ammo mavjud diagrammalar sonini hisobga olgan holda, biz asosiy dasturiy ta'minotni ishlab chiqishda nimani nazarda tutamiz? Menimcha, vaziyatni ishlatish diagrammalaridan foydalangan holda talablardan boshlash va holatlardan foydalanishni boshlaymiz. Ko'pchilik Agile ishlab chiquvchilari hikoya kartalari bilan qasam ichishadi, bu ham ajoyibdir. Foydalanish holatlarining diagrammasiga ega bo'lsak va vaziyatlarni ishlatsak, biz tizimni taqsimlash bo'yicha biror narsaga egamiz va, ehtimol, tarqatish diagrammasi yoki paketlar diagrammasi qismlarni aniqlash uchun juda erta emas. Faoliyat, ketma-ketlik va sinf diagrammasi juda batafsil ma'lumot beradi va dizaynni asosiy usulda ko'rsatish uchun juda past darajada bo'lishi mumkinmi? UMLning ta'rifi shundaki, advokatlar barcha diagrammalarni taqdim etishini kutadilar. Agar siz blok diagrammasini yoki ma'lumotlar oqimining diagrammasini ishlatmoqchi bo'lsangiz, ular ehtimol siz o'z diagrammalaridan biriga ushbu diagrammalarning tuzilgan dizayndagi qoldiqlari va biz yaratishga intilayotgan ob'ektga yo'naltirilgan dekompozitsiya bilan chalkashliklari borligi haqida rag'batlantirishi mumkin. Shaxsan, sizning maqsadlaringizga qanday qilib qanday qilib boshlashingiz va samarali tarzda harakat qilishingiz kerakligini ko'rsatadigan har qanday diagramma yoki yozma rejaga ega bo'lishingiz kerak deb o'ylayman.