12-Ma’ruza
Mavzu: Dasturiy ta’minot evolyutsiyasi. Evolyutsiya jarayonlari Eski tizimlar
Dasturiy ta’minotga xizmat ko‘rsatish
REJA:
Evolyutsiya jarayonlari
Eski tizimlar
Dasturiy ta’minotga xizmat ko‘rsatish
Tayanch so’zlar
Evolyutsiya jarayonlari
dasturiy ta'minot evolyutsiyasi dasturiy injiniringning muhim qismi ekanligini tushuntirish va ko'p yillar davomida ishlab chiqilgan dasturiy ta'minot tizimlarining katta bazasini saqlash muammolarini tavsiflashdan iborat. Ushbu bo'limni o'qib chiqqach, siz:
dasturiy ta'minot tizimlari foydali bo'lib qolishi uchun moslashishi va rivojlanishi kerakligini va dasturiy ta'minotning o'zgarishi va evolyutsiyasi dasturiy injiniringning ajralmas qismi sifatida ko'rib chiqilishi kerakligini tushunish;
eski tizimlar deganda nimani anglatishini va bu tizimlar biznes uchun nima uchun muhimligini tushunish;
eski tizimlarni bekor qilish, texnik xizmat ko'rsatish, qayta ishlab chiqish yoki almashtirish kerakligini hal qilish uchun qanday baholanishi mumkinligini tushunish;
dasturiy ta'minotga texnik xizmat ko'rsatishning har xil turlari va eski dasturiy ta'minot tizimlariga o'zgartirishlar kiritish xarajatlariga ta'sir etuvchi omillar haqida bilib oldilar.
Katta dasturiy ta'minot tizimlari odatda uzoq umrga ega. Masalan, harbiy yoki infratuzilma tizimlari, masalan, havo harakatini boshqarish tizimlari 30 yil yoki undan ko'proq umrga ega bo'lishi mumkin. Biznes tizimlari ko'pincha 10 yildan ortiq vaqtga ega. Korxona dasturiy ta'minoti katta mablag' talab qiladi, shuning uchun kompaniya o'z sarmoyasidan daromad olish uchun ko'p yillar davomida dasturiy ta'minot tizimidan foydalanishi kerak. Muvaffaqiyatli dasturiy ta'minot mahsulotlari va ilovalari ko'p yillar oldin yangi versiyalari bilan bir necha yilda bir marta chiqarilgan bo'lishi mumkin. Misol uchun, Microsoft Word dasturining birinchi versiyasi 1983 yilda taqdim etilgan, shuning uchun u 30 yildan ortiq vaqtdan beri mavjud.
Operatsion dasturiy ta'minot tizimlari o'z hayoti davomida foydali bo'lib qolishi uchun o'zgarishi kerak. Biznesdagi o'zgarishlar va foydalanuvchi kutgan o'zgarishlar dasturiy ta'minot uchun yangi talablarni keltirib chiqaradi. Dasturiy ta'minotning qismlari ish paytida topilgan xatolarni tuzatish, uni apparat va dasturiy platformadagi o'zgarishlarga moslashtirish va uning ishlashini yoki boshqa funktsional bo'lmagan xarakteristikani yaxshilash uchun o'zgartirilishi kerak bo'lishi mumkin . Dasturiy ta'minot mahsulotlari va ilovalari platformadagi o'zgarishlar va raqobatchilar tomonidan kiritilgan yangi xususiyatlarni engish uchun rivojlanishi kerak. Shunday qilib, dasturiy ta'minot tizimlari o'zlarining ishlash muddati davomida dastlabki foydalanishdan to yakuniy nafaqaga chiqishgacha moslashadi va rivojlanadi.
Korxonalar o'zlarining dasturiy ta'minotidan foyda olishni davom ettirishlari uchun o'zgartirishlari kerak. Ularning tizimlari muhim biznes aktivlaridir va ular ushbu aktivlarning qiymatini saqlab qolish uchun o'zgarishlarga sarmoya kiritishlari kerak. Shunday qilib, aksariyat yirik kompaniyalar yangi tizimlarni ishlab chiqishdan ko'ra mavjud tizimlarni saqlashga ko'proq mablag' sarflaydilar. Tarixiy ma'lumotlar shuni ko'rsatadiki, dasturiy ta'minot xarajatlarining 60% dan 90% gacha bo'lgan qismini evolyutsiya xarajatlari tashkil qiladi (Lientz va Swanson 1980; Erlikh 2000). Jons (Jones 2006) 2006 yilda Qo'shma Shtatlardagi ishlab chiqish bo'yicha xodimlarning taxminan 75 foizi dasturiy ta'minot evolyutsiyasi bilan shug'ullanganligini aniqladi va bu foiz yaqin kelajakda pasaymasligini taxmin qildi.
ta'minot tizimlari kengroq "tizimlar tizimi" ning bir qismi bo'lsa, dasturiy ta'minot evolyutsiyasi, ayniqsa, korporativ tizimlarda qimmatga tushadi . Bunday hollarda siz faqat bitta tizimdagi o'zgarishlarni ko'rib chiqa olmaysiz; shuningdek, ushbu o'zgarishlar tizim ildizlarining kengroq tizimiga qanday ta'sir qilishini tekshirishingiz kerak . Bitta tizimni o'zgartirish, uning muhitidagi boshqa tizimlar ham ushbu o'zgarishga dosh berish uchun rivojlanishi kerak bo'lishi mumkinligini anglatishi mumkin.
Shuning uchun, taklif qilinayotgan o'zgarishlarning tizimning o'ziga ta'sirini tushunish va tahlil qilish bilan bir qatorda, ushbu o'zgarish operatsion muhitdagi boshqa tizimlarga qanday ta'sir qilishi mumkinligini ham baholashingiz kerak. Xopkins va Jenkins (Xopkins va Jenkins 2008) dasturiy ta'minot tizimlari boshqa dasturiy ta'minot tizimlariga bog'liq bo'lgan muhitda ishlab chiqilishi va boshqarilishi kerak bo'lgan vaziyatlarni tasvirlash uchun " Browfield" dasturiy ta'minotini ishlab chiqish atamasini kiritdilar.
O'rnatilgan dasturiy ta'minot tizimlarining talablari biznes va uning muhiti o'zgarishi bilan o'zgaradi, shuning uchun o'zgarishlar va yangilanishlarni o'z ichiga olgan tizimlarning yangi nashrlari odatda muntazam ravishda yaratiladi. Demak, dasturiy ta'minot injiniringi spiral jarayon bo'lib, tizimning ishlash muddati davomida talablar, dizayn, amalga oshirish va sinovdan o'tkaziladi ( 9.1-rasm). Siz tizimning 1 - versiyasini yaratishdan boshlaysiz . Yetkazib berilgandan so'ng, o'zgartirishlar taklif etiladi va 2 -relizning rivojlanishi deyarli darhol boshlanadi. Haqiqatan ham, evolyutsiyaga bo'lgan ehtiyoj tizim ishga tushirilishidan oldin ham ayon bo'lishi mumkin, shuning uchun dasturiy ta'minotning keyingi versiyalari joriy versiya chiqarilishidan oldin ham ishlab chiqilishi mumkin.
So'nggi 10 yil ichida spiralning takrorlanishlari orasidagi vaqt keskin qisqardi.
9.1-rasm Rivojlanish va evolyutsiyaning spiral modeli
Dasturiy ta'minot evolyutsiyasining ushbu modeli, xuddi shu kompaniya butun umri davomida dasturiy ta'minot uchun javobgar bo'lganda qo'llaniladi. Rivojlanishdan evolyutsiyaga uzluksiz o'tish mavjud va dasturiy ta'minotni ishlab chiqishning bir xil usullari va jarayonlari dasturiy ta'minotning butun umri davomida qo'llaniladi . Ushbu yondashuv yordamida dasturiy mahsulotlar va ilovalar ishlab chiqiladi.
Biroq, maxsus dasturiy ta'minotning evolyutsiyasi odatda boshqa modelga amal qiladi. Tizim mijozi dasturiy ta'minotni ishlab chiqish uchun dasturiy ta'minot kompaniyasiga pul to'lashi va keyin o'z xodimlaridan foydalangan holda qo'llab-quvvatlash va evolyutsiya uchun mas'uliyatni o'z zimmasiga olishi mumkin. Shu bilan bir qatorda, dasturiy ta'minot mijozi tizimni qo'llab-quvvatlash va evolyutsiya qilish uchun boshqa dasturiy ta'minot kompaniyasiga alohida shartnoma berishi mumkin.
Rajlich va Bennett (Rajlich and Bennett 2000) biznes tizimlari uchun dasturiy ta'minot evolyutsiyasining hayot aylanishining muqobil ko'rinishini taklif qiladilar. Ushbu modelda ular evolyutsiya va xizmat ko'rsatishni ajratadilar. Evolyutsiya - bu dasturiy ta'minot arxitekturasi va funksionalligiga sezilarli o'zgarishlar kiritilgan bosqich. Xizmat ko'rsatish vaqtida faqat nisbatan kichik, ammo muhim o'zgarishlar amalga oshiriladi. Ushbu fazalar 9.2 -rasmda ko'rsatilganidek, bir-birining ustiga tushadi.
Rajlich va Bennetning fikriga ko'ra, dasturiy ta'minot birinchi marta muvaffaqiyatli qo'llanilganda, manfaatdor tomonlar tomonidan talablarga ko'plab o'zgartirishlar taklif qilinadi va amalga oshiriladi.
Bu evolyutsiya bosqichi. Biroq, dasturiy ta'minot o'zgartirilganda, uning tuzilishi yomonlashadi va tizim o'zgarishlari tobora qimmatlashadi. Bu ko'pincha apparat va operatsion tizimlar kabi boshqa atrof-muhit o'zgarishlari ham talab qilinganda bir necha yillik foydalanishdan keyin sodir bo'ladi. Hayotiy tsiklning ma'lum bir bosqichida dasturiy ta'minot sezilarli o'zgarishlar va yangi talablarni amalga oshirish kamroq va kamroq iqtisodiy samarador bo'ladigan o'tish nuqtasiga etadi. Ushbu bosqichda dasturiy ta'minot evolyutsiyadan xizmat ko'rsatishga o'tadi.
Xizmat ko'rsatish bosqichida dasturiy ta'minot hali ham foydalidir, lekin unga faqat kichik taktik o'zgarishlar kiritiladi. Ushbu bosqichda kompaniya odatda dasturiy ta'minotni qanday almashtirish mumkinligini ko'rib chiqadi. Yakuniy bosqichda dasturiy ta'minot hali ham ishlatilishi mumkin, ammo faqat muhim o'zgarishlar kiritiladi. Foydalanuvchilar o'zlari aniqlagan muammolarni hal qilishlari kerak. Oxir-oqibat, dasturiy ta'minot bekor qilinadi va foydalanishdan chiqariladi. Bu ko'pincha qo'shimcha xarajatlarga olib keladi, chunki ma'lumotlar eski tizimdan yangi almashtirish tizimiga o'tkaziladi.
Rasmiy yoki norasmiy tizimni o'zgartirish bo'yicha takliflar barcha tashkilotlarda tizim evolyutsiyasi uchun haydovchi hisoblanadi. O'zgartirish taklifida shaxs yoki guruh mavjud dasturiy ta'minot tizimiga o'zgartirishlar va yangilanishlarni taklif qiladi. Ushbu takliflar chiqarilgan tizimda joriy etilmagan mavjud talablarga, yangi talablar soʻrovlariga, tizim manfaatdor tomonlarning xatoliklar toʻgʻrisidagi hisobotlariga va tizimni ishlab chiqish guruhining dasturiy taʼminotni takomillashtirish boʻyicha yangi gʻoyalariga asoslanishi mumkin. O'zgarishlarni aniqlash va tizim evolyutsiyasi jarayonlari tsiklik bo'lib, tizimning butun umri davomida davom etadi (9.3-rasm).
9.3. rasm. Identifikatsiya va evolyutsiya jarayonlarini o'zgartirish
O'zgartirish taklifi qabul qilinishidan oldin, qaysi komponentlarni o'zgartirish kerakligini aniqlash uchun dasturiy ta'minotni tahlil qilish kerak. Ushbu tahlil xarajatlarni va o'zgarishlarning ta'sirini baholashga imkon beradi. Bu o'zgarishlarni boshqarishning umumiy jarayonining bir qismi bo'lib, u ham to'g'ri versiyalarini ta'minlashi kerak.
komponentlar har bir tizim versiyasiga kiritilgan. Men 25 -bobda o'zgartirish va konfiguratsiyani boshqarishni muhokama qilaman .
9.4 - rasmda dasturiy ta'minot evolyutsiyasi bilan bog'liq ba'zi tadbirlar ko'rsatilgan. Jarayon o'zgarishlarni tahlil qilish, chiqarishni rejalashtirish, tizimni amalga oshirish va tizimni mijozlarga chiqarish kabi asosiy tadbirlarni o'z ichiga oladi . Ushbu o'zgarishlarning narxi va ta'siri o'zgarishlar tizimga qanchalik ta'sir qilishini va o'zgartirishni amalga oshirish uchun qancha xarajat qilishini ko'rish uchun baholanadi.
Agar taklif qilingan o'zgartirishlar qabul qilinsa, tizimning yangi chiqarilishi rejalashtirilgan. Chiqarishni rejalashtirish paytida barcha taklif qilingan o'zgarishlar (nosozliklarni tuzatish, moslashish va yangi funksionallik) hisobga olinadi. Keyin tizimning keyingi versiyasida qaysi o'zgarishlarni amalga oshirish to'g'risida qaror qabul qilinadi . O'zgarishlar amalga oshirildi va tasdiqlandi va tizimning yangi versiyasi chiqariladi. Jarayon keyingi versiya uchun taklif qilingan yangi o'zgarishlar to'plami bilan takrorlanadi.
Rivojlanish va evolyutsiya integratsiyalashgan holatlarda, o'zgarishlarni amalga oshirish shunchaki rivojlanish jarayonining takrorlanishidir. Tizimga tuzatishlar ishlab chiqiladi, amalga oshiriladi va sinovdan o'tkaziladi. Dastlabki ishlab chiqish va evolyutsiya o'rtasidagi yagona farq shundaki, dasturning yangi nashrlarini rejalashtirishda etkazib berishdan keyin mijozlarning fikr- mulohazalarini hisobga olish kerak.
Turli jamoalar ishtirok etganda, rivojlanish va evolyutsiya o'rtasidagi muhim farq shundaki, o'zgarishlarni amalga oshirishning birinchi bosqichi dasturni tushunishni talab qiladi.
9.4-rasm Dasturiy ta'minot evolyutsiyasi jarayonining umumiy modeli
9.5-rasm O'zgartirishni amalga oshirish
Dasturni tushunish bosqichida yangi ishlab chiquvchilar dastur qanday tuzilganligini, u qanday funksionallikni taqdim etishini va taklif qilingan o'zgartirish dasturga qanday ta'sir qilishi mumkinligini tushunishlari kerak. Amalga oshirilgan o'zgartirish mavjud tizimga kiritilganda yangi muammolarni keltirib chiqarmasligiga ishonch hosil qilish uchun ular ushbu tushunchaga muhtoj.
Agar talablar spetsifikatsiyasi va dizayn hujjatlari mavjud bo'lsa, ular zarur bo'lgan o'zgarishlarni aks ettirish uchun evolyutsiya jarayonida yangilanishi kerak (9.5-rasm). Yangi dasturiy ta'minot talablari yozilishi va ular tahlil qilinishi va tasdiqlanishi kerak. Agar dizayn UML modellari yordamida hujjatlashtirilgan bo'lsa, ushbu modellar yangilanishi kerak. Taklif etilayotgan o'zgarishlar o'zgarishlarni tahlil qilish jarayonining bir qismi sifatida prototiplanishi mumkin, bunda siz o'zgartirishning oqibatlari va xarajatlarini baholaysiz.
Biroq, o'zgartirish so'rovlari ba'zan tezkor hal qilinishi kerak bo'lgan operatsion tizimlardagi muammolar bilan bog'liq. Ushbu shoshilinch o'zgarishlar uchta sababga ko'ra yuzaga kelishi mumkin:
Agar jiddiy tizim nosozliklari aniqlansa, uni normal ishlashni davom ettirish yoki xavfsizlikning jiddiy zaifligini bartaraf etish uchun tuzatish kerak.
Tizimning operatsion muhitidagi o'zgarishlar normal ishlashni buzadigan kutilmagan ta'sirga ega bo'lsa.
Tizimda ishlaydigan biznesda kutilmagan o'zgarishlar bo'lsa, masalan, yangi raqobatchilarning paydo bo'lishi yoki tizimga ta'sir qiluvchi yangi qonunchilikning kiritilishi.
Bunday hollarda, o'zgartirishni tezda amalga oshirish zarurati barcha dasturiy ta'minot hujjatlarini yangilay olmasligingizni anglatadi. Talablar va dizaynni o'zgartirish o'rniga, siz darhol muammoni hal qilish uchun dasturga favqulodda tuzatish kiritasiz (9.6-rasm). Bu erda xavf shundaki, talablar, dasturiy ta'minot dizayni va kod bir-biriga mos kelmasligi mumkin. Talablar va dizayndagi o'zgarishlarni hujjatlashtirmoqchi bo'lsangiz ham, dasturiy ta'minotga qo'shimcha favqulodda tuzatishlar kerak bo'lishi mumkin. Bular hujjatlardan ustun turadi. Oxir-oqibat, asl o'zgarish unutiladi va tizim hujjatlari va kodlari hech qachon qayta moslashtirilmaydi. Tizimning bir nechta ko'rinishlarini saqlash muammosi tezkor rivojlanish jarayonlari uchun asosiy bo'lgan kichik hujjatlar uchun dalillardan biridir.
Favqulodda tizimni ta'mirlash imkon qadar tezroq bajarilishi kerak . Tizim tuzilishiga kelsak, siz eng yaxshi yechimni emas, balki tez va samarali yechimni tanlaysiz. Bu dasturiy ta'minotning qarish jarayonini tezlashtiradi, shuning uchun kelajakdagi o'zgarishlar tobora qiyinlashadi va texnik xizmat ko'rsatish xarajatlari oshadi. Ideal holda, favqulodda kodni ta'mirlash amalga oshirilgandan so'ng, dasturning yomonlashishiga yo'l qo'ymaslik uchun yangi kodni qayta tiklash va yaxshilash kerak. Albatta, agar iloji bo'lsa, ta'mirlash kodi qayta ishlatilishi mumkin. Biroq, tahlil qilish uchun ko'proq vaqt mavjud bo'lganda, muammoning muqobil, yaxshiroq echimi topilishi mumkin.
9.6-rasm Favqulodda ta'mirlash jarayoni
3 -bobda muhokama qilingan Agile usullari va jarayonlari dastur evolyutsiyasi va dastur ishlab chiqish uchun ishlatilishi mumkin. Ushbu usullar bosqichma-bosqich rivojlanishga asoslanganligi sababli, tezkor rivojlanishdan postde livery evolyutsiyasiga o'tish muammosiz bo'lishi kerak.
Biroq, ishlab chiqish guruhidan tizim evolyutsiyasi uchun mas'ul bo'lgan alohida guruhga o'tkazish jarayonida muammolar paydo bo'lishi mumkin. Ikki potentsial muammoli vaziyat mavjud:
Rivojlanish guruhi tezkor yondashuvni qo'llagan bo'lsa-da, evolyutsiya guruhi rejaga asoslangan yondashuvni afzal ko'radi. Evolyutsiya jamoasi evolyutsiyani qo'llab-quvvatlash uchun batafsil hujjatlarni kutishi mumkin va bu kamdan-kam hollarda tezkor jarayonlarda ishlab chiqariladi. Tizimga o'zgartirishlar kiritilganda o'zgartirilishi mumkin bo'lgan tizim talablarining aniq bayonoti bo'lmasligi mumkin.
Rivojlanish uchun rejaga asoslangan yondashuv ishlatilgan bo'lsa-da, evolyutsiya jamoasi tezkor usullardan foydalanishni afzal ko'radi. Bunday holda, evolyutsiya guruhi avtomatlashtirilgan testlarni ishlab chiqishni noldan boshlashi kerak bo'lishi mumkin. Tizimdagi kod, agile rivojlanishida kutilganidek, qayta tahrirlanmagan va soddalashtirilmagan bo'lishi mumkin. Bunday holda, agile ishlab chiqish jarayonida foydalanishdan oldin kodni yaxshilash uchun ba'zi dastur reinjiniringi talab qilinishi mumkin.
Sinovga asoslangan ishlab chiqish va avtomatlashtirilgan regressiya testi kabi tezkor usullar tizimga o'zgartirishlar kiritilganda foydalidir. Tizimdagi o'zgarishlar foydalanuvchi hikoyalari sifatida ifodalanishi mumkin va mijozlar ishtiroki operatsion tizimda talab qilinadigan o'zgarishlarga ustuvor ahamiyat berishga yordam beradi. Bajarilishi kerak bo'lgan orqada qolgan ishlarga e'tibor qaratishning Scrum yondashuvi tizimdagi eng muhim o'zgarishlarga ustuvor ahamiyat berishga yordam beradi. Muxtasar qilib aytganda, evolyutsiya tezkor rivojlanish jarayonini davom ettirishni o'z ichiga oladi.
Rivojlanishda qo'llaniladigan tezkor usullar, dasturni ta'minlash va evolyutsiya qilish uchun ishlatilganda o'zgartirilishi mumkin. Foydalanuvchilarni ishlab chiqish guruhiga jalb qilish deyarli imkonsiz bo'lishi mumkin, chunki o'zgartirish takliflari manfaatdor tomonlarning keng doirasidan keladi. Favqulodda ta'mirlash bilan shug'ullanish uchun qisqa rivojlanish davrlarini to'xtatish va operatsion jarayonlarni buzmaslik uchun relizlar orasidagi bo'shliqni uzaytirish kerak bo'lishi mumkin.
Do'stlaringiz bilan baham: |