Yagona dasturiy ta'minotni ishlab chiqish jarayoni. Yagona rivojlanish jarayoni va ekstremal dasturlash

GOST 34.601-90 ga muvofiq “AS. Yaratish bosqichlari" AISni yaratishning quyidagi bosqichlarini belgilaydi, bu esa o'z navbatida bosqichlarga bo'linishi mumkin:

· AISga talablarni shakllantirish;

· AIS konsepsiyasini ishlab chiqish;

· texnik topshiriq;

· dastlabki loyihalash;

· texnik loyiha;

· ish hujjatlari;

· ishga tushirish.

Har bir bosqichda o'ziga xos loyiha hujjatlari to'plami va tizimning texnik va dasturiy modullarini amalga oshirish mavjud. Amaliyot shuni ko'rsatadiki, tizimni yaratish jarayoni iterativ va bosqichma-bosqichdir. UML mualliflari kontseptsiyani belgilashda buni ta'kidlaydilar yagona dasturiy ta'minot va axborotni ishlab chiqish jarayoni. Garchi birinchi bosqichda bir butun sifatida ASga qo'yiladigan talablar majmui shakllansa-da, aslida u har doim boshida to'liq bo'lmaydi va keyingi bosqichlarda aniqlashtiriladi. qilishim kerak iteratsiyalar, ya'ni alohida qadamlar va bosqichlarni to'liq yoki qisman takrorlash. Bundan tashqari, haqiqiy tizim ko'p funktsiyali va murakkabdir, shuning uchun u odatda quyi tizimlarga va alohida vazifalar to'plamiga bo'linadi, quyi tizimlar va birinchi bosqichning vazifalari, ikkinchisi va boshqalarni ajratib turadi. Tizim yaratilmoqda bosqichma-bosqich, dastlabki dizayn echimlarini foydalanuvchi talablariga yaxshiroq javob beradigan yanada rivojlanganlari bilan almashtirish bilan funksionallikni bosqichma-bosqich oshirish orqali. Bu moliyaviy xatarlarni kamaytiradi va yaratilishning yakuniy bosqichlarida vaqt va resurslar sarfini tejaydi.

AIS dasturiy ta'minoti va axborot ta'minotini yaratish uchun UML metodologiyasidan foydalanganda kelajakdagi tizimning statik va dinamik xususiyatlarini aks ettiruvchi bir-biriga bog'langan modellar to'plamini yaratish taklif etiladi:

· foydalanish namunasi;

· tahlil modeli;

· dizayn modeli;

· joylashtirish modeli;

· amalga oshirish modeli;

· sinov modeli.

Case Modelidan foydalaning foydalanish holatlari diagrammalarini va tegishli stsenariylarni o'z ichiga oladi, tizimning funktsional talablarini va foydalanuvchilar bilan o'zaro aloqada bo'lgan xatti-harakatlarini tavsiflaydi.

Tahlil modeli mantiqiy darajadagi foydalanish holatlarini amalga oshirish uchun umumiy sinf diagrammalarini, tegishli ketma-ketlik diagrammalarini va/yoki hamkorlik diagrammalarini o'z ichiga oladi va mantiqiy darajadagi foydalanish holatlari qanday amalga oshirilishining eskizidir.

Dizayn modeli tahlil modelining jismoniy amalga oshirilishining batafsil tasviri bo'lib, paket (quyi tizim) diagrammalarini, batafsil sinf diagrammalarini, ketma-ketlik diagrammalarini va/yoki hamkorlik diagrammalarini, holat diagrammalarini, turli darajadagi batafsillikdagi faoliyat diagrammalarini o'z ichiga oladi.

Joylashtirish modeli tizim ishlashi mumkin bo'lgan barcha tarmoq konfiguratsiyalarini aniqlaydigan dastlabki joylashtirish diagrammalarini o'z ichiga oladi. Joylashtirish sxemalari tarmoq tugunlarini, ulanish turlarini va faol tizim sinflarini tugunlar o'rtasida taqsimlashni ko'rsatadi.

Amalga oshirish modeli dizayn sinflari komponentlar sifatida qanday amalga oshirilishini tavsiflaydi. Shunga ko'ra, u komponent diagrammalarini, sinf (amalga oshirish) izlarini, batafsil joylashtirish diagrammalarini va tizim arxitekturasining tavsifini o'z ichiga oladi.

Sinov modeli test holatlari, sinov tartiblari va test komponentlarining tavsiflarini o'z ichiga oladi. U bajariladigan tizim komponentlarini sinash usullarini belgilaydi.

Modellarni qurish jarayonlarini AS yaratishning standartlashtirilgan bosqichlari bilan taqqoslaylik. Foydalanish namunasi AS uchun talablarni shakllantirish bosqichida qurilgan; tahlil modeli AS kontseptsiyasini ishlab chiqish bosqichida. Texnik spetsifikatsiyalar va dastlabki loyihalash bosqichida dizayn modeli quriladi. U texnik dizayn bosqichida takomillashtiriladi va joylashtirish modeli bilan to'ldiriladi. Ishchi hujjatlar bosqichida amalga oshirish va sinovdan o'tkazish modellari yaratiladi. Nihoyat, ishga tushirish bosqichida sinov modeli takomillashtiriladi va tizimning to'g'ri ishlashini davriy tekshirish va diagnostika qilish uchun mo'ljallangan ish paytida mos yozuvlar modeliga aylanadi.

1.5 UML tilining komponentlari

Yagona modellashtirish tili UML(Unified Modeling Language) - ob'ektga yo'naltirilgan texnologiyadan foydalangan holda murakkab tizimlarni (shu jumladan dasturiy ta'minotni) belgilash, vizualizatsiya qilish, sozlash va hujjatlashtirish uchun ishlatiladigan vizual modellash tili.

UML metodologiyasida AS yaratishda Hein/Sarson va SADT metodologiyalaridan ma'lum bo'lgan tizimli tizim tahlilining tamoyillari qo'llaniladi:

· yuqoridan pastga bosqichma-bosqich ishlab chiqish;

· diagramma tuzish texnikasi;

· tavsiflar ierarxiyasi;

· dizayn yechimlari tavsifini qat'iy rasmiylashtirish;

· loyihani texnik amalga oshirish tafsilotlarisiz mantiqiy darajada dastlabki ishlab chiqish;

· mijozning tizim dizaynini tushunishi uchun mavzu sohasi nuqtai nazaridan kontseptual modellashtirish;

· asboblar bilan texnologik yordam (CASE tizimlari).

Tizimdagi jarayonlar samaradorligining taxminiy xarakteristikalarini olish uchun UMLda murakkab tizim modeli o'rganilishi mumkin.

AS dasturiy ta'minotini o'rnatish, amalga oshirish va sinovdan o'tkazish modellari va UMLda axborotni qo'llab-quvvatlash, tanlangan dasturlash muhitlaridan birida keyinchalik avtomatlashtirilgan dastur kodini yaratish bilan amaliy loyiha sifatida ishlatilishi mumkin.

Murakkab tizimning etarlicha to'liq modeli ikki jihatni aks ettirishi kerak:

-statik(strukturaviy) - tarkibiy qismlarning tarkibi, tuzilishi va ularning munosabatlari;

-dinamik(xulq-atvor) - tizimda sodir bo'ladigan yoki amalga oshirilishi kerak bo'lgan jarayonlarning mantiqiy tavsifi.

UML-da qabul qilingan modellarni aks ettirishning asosiy usuli bu matnli ma'lumotlar bilan ta'minlangan diagrammalar, shu jumladan OCL o'rnatilgan cheklash tilidagi ifodalar, shuningdek tizimni amalga oshirish uchun foydalaniladigan dasturlash va axborot so'rovlari tillari.

Modellashtirishning asosiy printsipi: tizim foydalanuvchi talablarini qondiradigan tarzda bir-biri bilan o'zaro ta'sir qiluvchi diskret ob'ektlar guruhi sifatida modellashtiriladi.

Statik model ob'ektlarning tuzilishini, turlarini va ob'ektlar orasidagi munosabatlarni belgilaydi. Dinamik model ob'ektlarning vaqt bo'yicha harakatlarini (ob'ektlar tarixi) va ularning o'zaro ta'sirini belgilaydi.

Asosan, UML diskret modellash tilidir, ya'ni u diskret hodisalar va holat o'zgarishlari tushunchasini o'z ichiga oladi. Uzluksiz jarayonlar taxminan diskretlashtirish orqali modellashtirilgan.

Model ikki jihatga ega: semantik axborot (semantika) va vizual tasvirlash (notatsiya).

UML tilidagi model ko'rinishlarining to'liq tarkibi 1-jadvalda keltirilgan

1-jadval – UMLda tizim modellarining ko'rinishi.

Tizimning eng keng tarqalgan kontseptual modeli - bu boshqa diagrammalarni qurish uchun boshlang'ich nuqtadir.

Barcha til diagrammalari qirralar (yoylar) bilan bog'langan uchlarini (geometrik raqamlarni) o'z ichiga olgan maxsus turdagi grafiklardir. Odatda tasvirning shkalasi va cho'qqilarning joylashuvi ayniqsa muhim emas, ammo ketma-ketlik diagrammasida vaqt o'qi kiritilgan va u erda u muhim ahamiyatga ega.

Bog'lanishlar tekislikda turli xil chiziqlar bilan ko'rsatilgan, raqamlar ichida matn yoziladi va ba'zi grafik belgilar cho'qqilar va ulanishlar yaqinida tasvirlanishi mumkin. UML kengaytmalari fazoviy diagrammalarga imkon beradi.

Tilda 4 turdagi grafik tuzilmalar mavjud:

· piktogrammalar (piktogrammalar);

· tekislikdagi grafik belgilar;

· yo'llar (chiziqlar);

· matn satrlari.

1.6 Kontseptual daraja. Case Modelidan foydalaning

Umuman olganda, ob'ektga yo'naltirilgan loyihalash jarayoni tizimli tizim tahlilining asosiy tamoyillariga muvofiq amalga oshiriladi: bizni bosqichma-bosqich darajadan bosqichga o'tkazadigan diagrammalar ierarxiyasini qurish bilan yuqoridan pastga loyihalash: kontseptual - mantiqiy - jismoniy (amalga oshirish)

Yuqori darajadagi diagramma OOSEda A. Jeykobson tomonidan taklif qilingan diagramma hisoblanadi foydalanish diagrammasi bir butun sifatida tizimlar. Aynan shu tizimning dastlabki kontseptual ko'rinishi bo'lib, quyidagi maqsadlarda qurilgan:

· modellashtirilgan fan sohasining umumiy chegaralari va kontekstini aniqlash;

· tizimning funktsional harakati va interfeysiga umumiy talablarni shakllantirish;

· dasturchilar va mijozlar - tizim foydalanuvchilari o'rtasidagi o'zaro munosabatlar uchun dastlabki hujjatlarni tayyorlash.

Modelning nuqtai nazari: tizimning tashqi foydalanuvchisi. Foydalanish diagrammasi aktyorlar, foydalanish holatlari va assotsiatsiyalarni o'z ichiga oladi.

Faol(aktyor, tashqi ob'ekt, aktyor) - tizim, quyi tizim yoki sinf bilan bevosita o'zaro aloqada bo'lgan xabar manbalari/qabul qiluvchilar sinfining mavhum tavsifi. Bu tavsif rollar foydalanuvchi (shaxs yoki boshqa tizim, quyi tizim, sinf) tizim bilan o'zaro aloqada o'ynagan. Asosan, bu ma'lum bir talabni talab qiladigan tizimga o'xshash ma'lumot so'rovlarining umumlashtirilishi xizmat(xizmatlar).

Aktyorni ma'lum bir shaxs yoki qurilma bilan aniqlash shart emas, garchi ular faqat bitta rolni bajarsa, bu printsipial jihatdan ba'zan mumkin. Ko'pincha - jismoniy - bu bir xil xizmatni olish uchun tizimga kiradigan turli xil odamlar va qurilmalar. Eng yuqori darajada, masalan, aktantlar operator, tizim ma'muri, ma'lumotlar bazasi ma'muri, oddiy foydalanuvchi yoki ba'zi qurilmalar sinfi bo'lishi mumkin.

Barcha mumkin bo'lgan faol moddalar foydalanuvchining tizim bilan o'zaro ta'sirining barcha mumkin bo'lgan usullarini (quyi tizim, sinf) ishlatadi. Tizimni amalga oshirishda faollar odamlar va jismoniy ob'ektlarda mujassamlanadi. Bir shaxs yoki jismoniy ob'ekt, o'zaro ta'sir qilish uslubiga qarab, bir nechta aktantlarni (turli rollarni) ifodalashi mumkin. Masalan, bitta shaxs operator va ma'lumotlar bazasi ma'muri, sotuvchi va xaridor va boshqalar bo'lishi mumkin.

Ko'pgina ASlarda odamlardan tashqari boshqa aktyorlar yo'q. Biroq, faollar tashqi tizim, kiritish-chiqarish qurilmasi yoki taymer bo'lishi mumkin (ko'pincha o'rnatilgan real vaqt tizimlarida mavjud). Foydalanish holatidagi faollar orasida biri alohida ajralib turadi asosiy aktyor(asosiy aktyor), tizim bilan ishlashni boshlaydi. Qolganlari ikkinchi darajali bo'lib, ular ham foydalanish jarayonida ishtirok etadilar, natijalarni oladilar va ba'zi bir oraliq ma'lumotlarni kiritadilar.

Mantiqiy va jismoniy darajalarda faollar sinflar misollari bo'lgan sinflar va ob'ektlar bilan ifodalanadi. Ajdod aktantiga ega bo'lgan barcha rollar va munosabatlar, atributlar va operatsiyalarni meros qilib olgan holda, aktantlar ierarxiyasini qurish mumkin. Tizimdagi ajdod aktantidan foydalanish e'lon qilingan joyda (almashtirish printsipi) har doim bola aktantining misoli ishlatilishi mumkin.

Aktsiyani diagrammalarda ikki shaklda ko'rsatish mumkin:

3. Stereotipning ichki belgisi bilan sinf belgisi (to'rtburchak).

4. Ko'proq standart: yozuvli "odam" (inson belgisi)

Aktiv tizimdan tashqarida va uning ichki tuzilishi aniqlanmagan. Bu xabarlarning manbai/qabul qiluvchisi.

Mijoz

Foydalanish holati(pretsedent, foydalanish holati) - aktantga uning so'rovlariga javoban taqdim etiladigan xizmat sinfining (xizmat funktsiyalarining) mavhum tavsifi.

Xizmat butun tizim, quyi tizim yoki sinf tomonidan taqdim etilishi mumkin. Shunday qilib, foydalanish holati tizim funksionalligi yoki xatti-harakatlarining ba'zi qismini modellashtirishni anglatadi. Foydalanish holati nomga ega va tashqi manba/qabul qiluvchiga (aktant) ko'rinadigan muayyan harakatlar ketma-ketligini bildiradi. Variantni amalga oshirishning ichki usuli yashirin va quyi darajadagi tafsilotlarda namoyon bo'ladi. hamkorlik diagrammasi. Har qanday sinf singari, foydalanish holatida ham atributlar va operatsiyalar mavjud bo'lib, ularning bajarilishi jismoniy qatlamda namoyon bo'ladi.

Foydalanish holati aktant tizim (quyi tizim, sinf) bilan boshlanadigan va tugaydigan xabarlarning butun ketma-ketligini o'z ichiga oladi. Shuning uchun, foydalanish holatlarini amalga oshirishning har qanday misoli har doim vaqt bo'yicha boshlanishi va hech bir faol ushbu parametr uchun xabar yubormaganda tugashiga ega. Bunga xato xabarlari, turli xil sozlamalar (alternativlar) bilan texnik xizmat ko'rsatish funksiyasini bajarish variantlari ham kiradi.

Foydalanish misoli - bu aktant instantsiyasidan birinchi xabar olgandan keyin boshlanadigan foydalanish holatining bajarilishi. Berilgan xabarga javoban, foydalanish holati muayyan harakatlar ketma-ketligini bajaradi, masalan, aktantning boshqa misollariga (nafaqat muallifga) xabar yuborish. O'z navbatida, ushbu faollar ushbu foydalanish misoliga xabarlar yuboradilar va o'zaro aloqa boshqa bunday xabarlar olinmaguncha davom etadi. Bu foydalanish holatining tugashini bildiradi.

Aktent va foydalanish holati o'rtasidagi munosabat ko'rsatilgan uyushma.

Diagrammada foydalanish holati ikki shaklda tasvirlangan:

1) ellips, ichiga ism qo'yiladi

2) to'rtburchak - har qanday sinf kabi

Mijoz

Sensor

Aktyorlar va foydalanish holatlari o'rtasida assotsiatsiya ulanishning yagona turi hisoblanadi. Bundan tashqari, u semantikaga ega kommutatsiya aloqasi, ya'ni xabarni uzatish odatda belgilanmaydi, chunki kontekst aktant va foydalanish holatlari belgisidan aniq. Ammo siz uni belgilashingiz va ulanishning ko'pligini ko'rsatishingiz mumkin:

Bank mijozi

Ko'plik(ko'plik) berilgan ulanishda ishtirok etuvchi sinfning o'ziga xos misollari sonini tavsiflaydi (bitta mijoz cheklanmagan miqdordagi kreditlar berishi mumkin).

Umuman uyushma ikki yoki undan ortiq model komponentlari o'rtasidagi munosabatdir. Aksariyat hollarda komponentlar ob'ektlarning ba'zi sinflari bo'lganligi sababli, assotsiatsiya namunasi shunchaki birlashma atributlari (xususiyatlari) bilan jihozlangan muayyan misollarga havolalarning tartiblangan ro'yxatidir.

Assotsiatsiya nomi, agar mavjud bo'lsa, noyob bo'lishi kerak. U assotsiatsiya ishtirokchilari bo'lgan sinflar o'rtasidagi munosabatlarning ma'nosiga ko'ra shakllanadi. Masalan, "Xodim da ishlaydi Bo‘lim”, “Menejer yakunlaydi Kompyuter" va boshqalar.

Uyushmalar o'zlari sinflar ( assotsiatsiya sinfi, assotsiatsiya sinfi), u ham sinf, ham assotsiatsiya xususiyatlariga ega. Bu sinfning misollari faqat ob'ektlarga havolalar emas, balki atribut (xususiyat) qiymatlariga ham ega bo'lgan ulanishlardir.

Uyushma a'zolari uning deyiladi qutblar. Barcha qutblar ulanishda ishtirok etgan sinflarning rollari bo'lib, ular alohida va ba'zi tartiblangan ro'yxatda keltirilgan bo'lishi mumkin. Aksariyat hollarda assotsiatsiyalar ikkilik (muayyan semantika bilan assotsiatsiyada ikkita rol) bo'ladi, lekin ular ham bo'lishi mumkin. n -ary. Bitta va bir xil sinf turli rollarda harakat qilishi mumkin, ya'ni bir vaqtning o'zida birlashmaning ikkita qutbida bo'lishi mumkin.

Ulanishlarning ko'pligi qutblarda ko'rsatilgan.

Tizimning ishlashi davomida ulanishlar paydo bo'lishi va yo'qolishi mumkin, ular birlashmaning qutblarida cheklovlar va tegishli predikatlar ko'rsatilishi mumkin;

Ba'zan ulanish faqat qutblardan birida o'zgaradi. Agar havolaning atributlari bo'lsa, ular operatsiyalar orqali o'zgartirilishi mumkin, ammo havola ishtirokchilariga havolalar o'zgarmaydi.

Assotsiatsiya 2 ta sinf chegaralarini birlashtiruvchi uzluksiz chiziq sifatida tasvirlangan, agar assotsiatsiya n-ary, keyin romb chiziladi (birikish belgisi):

		Ko'p uyushmalar - yig'ish
	Ikkilik assotsiatsiya

Foydalanish holatlari bir-biri bilan xabar almashmaydi va faqat munosabatlarda (bog'lanish) bo'lishi mumkin. kengaytmalar(uzaytirish) kiritish(shu jumladan) va umumlashtirishlar(umumlashtirish).

IN kengaytirish haqida foydalanish holati - mijoz asosiy ketma-ketlikning bir nuqtasidan boshlab qo'shimcha harakatlar ketma-ketligini kiritadi va bir nechta bunday "qo'shimchalar" bo'lishi mumkin. Bu nuqtalarning barchasi deyiladi kengaytirish nuqtalari.

Rational Unified Process (RUP) - Rational Software tomonidan yaratilgan eng yaxshi dasturiy ta'minot ishlab chiqish metodologiyalaridan biri. Ko'pgina muvaffaqiyatli dasturiy ta'minot loyihalari tajribasiga asoslanib, Yagona jarayon sanoatni rivojlantirish usullariga asoslangan murakkab dasturiy ta'minot tizimlarini yaratishga imkon beradi. RUP tayanadigan asosiy ustunlardan biri Yagona modellashtirish tili (UML) yordamida modellarni yaratish jarayonidir. Ushbu maqola Rational Software metodologiyasidan foydalangan holda dasturiy ta'minot tizimlarini ishlab chiqish ish jarayonida UML diagrammalaridan foydalanish haqida.

Hech kimga sir emaski, dasturiy ta'minotni yaratish murakkab jarayon bo'lib, u bir tomondan ijodkorlik bilan ko'p umumiyliklarga ega bo'lsa, ikkinchi tomondan, bu juda daromadli bo'lsa-da, ayni paytda qimmat biznesdir. Bozordagi shiddatli raqobat ishlab chiquvchilarni yanada samarali ish usullarini izlashga majbur qiladi. Dasturiy ta'minot tizimlarini tezroq, arzonroq va sifatliroq yaratish usullari. Dasturlarning murakkabligi doimiy ravishda oshib bormoqda. Yaqin vaqtgacha dasturiy mahsulotlar jismoniy shaxslar tomonidan yoki, masalan, avtomatlashtirilgan korxonaning IT bo'limida oldindan ko'rsatilgan muddatda yaratilishi mumkin edi.

Hozirgi vaqtda tizzada dasturlarni yaratadigan shaxslar kichik kommunal xizmatlar va "og'ir" dasturiy mahsulotlar uchun turli xil kengaytmalar modullari bilan qolmoqda. Kelajak dasturiy ta'minotni yaratishga sanoat yondashuviga tegishli. 1913 yilda Genri Ford birinchi avtomobil yig'ish liniyasini ishga tushirdi va 90-yillarda shunga o'xshash yig'ish liniyasi IT texnologiyalari sohasida qo'llanila boshlandi. Jamoani rivojlantirish butunlay boshqacha yondashuvni va ertami-kechmi yaratilishi kerak bo'lgan boshqa metodologiyani talab qiladi.

Rational Software Corporation (http://www.rational.com) deyarli har qanday dasturiy mahsulotni yaratish uchun keng qamrovli tavsiyalar to'plami bo'lgan Rational Unified Process (RUP) deb nomlangan tuzilgan bilimlar bazasini chiqardi. Eng yaxshi ishlanmalar tajribasini o'zlashtirgan RUP, dasturiy ta'minot tizimini o'z vaqtida, ma'lum bir funksionallik va ajratilgan byudjet doirasida tugatish uchun loyihada qachon, kim va nima qilish kerakligini batafsil aytib beradi.

Birlashtirilgan jarayonni mijozlar talablarini dasturiy ta'minot tizimiga aylantirish uchun zarur bo'lgan ishlab chiquvchi kompaniyaning turli xil faoliyati yig'indisi sifatida ko'rib chiqish mumkin. Foydalanuvchilarga "mazmunli natijalar" beradigan va ular tizimdan kutganlarini bajaradigan tizim. Shuning uchun jarayon tizimdan foydalanish holatlari yoki boshqacha tarzda - pretsedentlar bilan boshqariladi.

Mijozlarning talablarini o'z vaqtida amalga oshirish uchun Yagona jarayon iteratsiyalardan iborat bosqichlarga bo'linadi, shuning uchun jarayon iterativ va qo'shimcha deb ataladi. Har bir iteratsiya asosiy ish tsiklidan o'tadi va ishlab chiquvchilarni yakuniy maqsadga olib keladi: dasturiy ta'minot tizimini yaratish. Takrorlashlar davomida loyihani muvaffaqiyatli yakunlash uchun zarur bo'lgan oraliq artefaktlar va ma'lum funktsiyalar to'plamini amalga oshiradigan dasturiy ta'minot tizimining versiyasi yaratiladi, bu iteratsiyadan iteratsiyagacha oshadi. Jarayonning bosqichlari va asosiy ish oqimlari rasmda ko'rsatilgan. 1, u erda bosqichma-bosqich ishning taxminiy mehnat xarajatlari ham berilgan.

guruch. 1 RUP bosqichlari va ish oqimlari

Shuni ta'kidlash kerakki, rasmda. 1-rasmda faqat Yagona jarayonning asosiy ishi ko'rsatilgan. Misol uchun, diagrammani chalkashtirib yubormaslik uchun faoliyatni boshqarish faoliyati bu erda ko'rsatilmagan.

Barcha dasturiy ta'minotni ishlab chiqish RUPda artefaktlarni yaratish jarayoni sifatida ko'rib chiqiladi. Loyihaning har qanday natijasi, xoh u manba kodlari, ob'ekt modullari, foydalanuvchiga uzatiladigan hujjatlar, modellar - bu barcha loyiha artefaktlarining kichik sinflari. Loyiha jamoasining har bir a'zosi o'z artefaktlarini yaratadi va ular uchun javobgardir. Dasturchi dasturni yaratadi, menejer loyiha rejasini tuzadi va tahlilchi tizim modellarini yaratadi. RUP qachon, kim tomonidan va qanday artefakt yaratilishi, o'zgartirilishi yoki ishlatilishi kerakligini aniqlash imkonini beradi.

Loyiha artefaktlarining eng qiziqarli sinflaridan biri bu modellar bo'lib, ular ishlab chiquvchilarga dasturiy ta'minot tizimi artefaktlarini aniqlash, vizualizatsiya qilish, qurish va hujjatlashtirish imkonini beradi. Har bir model ishlab chiqilayotgan tizimning o'ziga xos ko'rinishi bo'lib, muammolarni tasvirlash va yechimlarni taklif qilish uchun mo'ljallangan. Modellarning o'zini-o'zi ta'minlashi analitik yoki ishlab chiquvchining boshqa manbalarga murojaat qilmasdan, ma'lum bir modeldan o'ziga kerakli barcha ma'lumotlarni olishi mumkinligini anglatadi.

Modellar kelajakdagi tizimni, uning ob'ektlarini va ularning o'zaro ta'sirini rivojlanishga katta mablag 'sarflashdan oldin ham ko'rib chiqishga imkon beradi, ular sizga kelajakdagi foydalanuvchilar ko'zlari bilan va hatto dastlabki kodning birinchi qatoridan oldin ishlab chiquvchilarni ko'rishga imkon beradi; yaratilgan. Ko'pgina modellar UML diagrammasi bilan ifodalanadi, masalan, UML haqida ko'proq o'qishingiz mumkin;

Yagona modellashtirish tili 80-yillarning oxiri va 90-yillarning boshlarida, asosan, "uch do'st" Gradi Bucha, Jim Rembo va Ivar Jeykobsonning sa'y-harakatlari tufayli paydo bo'ldi. Endi u OMG konsorsiumi tomonidan standart modellashtirish tili sifatida qabul qilingan bo'lib, u ishlab chiquvchilarga modellarni loyihadagi har bir kishi tomonidan umumiy qabul qilingan va tushunarli bo'lgan grafik elementlarda ko'rsatishga imkon beruvchi aniq belgi bilan ta'minlaydi.

Ammo shuni unutmasligimiz kerakki, modellashtirish tili faqat yozuvni ta'minlaydi - tizimni tavsiflash va modellashtirish vositasi va birlashtirilgan jarayon ushbu vositadan foydalanish metodologiyasini, shuningdek Rationalning boshqa metodologiyasini qo'llab-quvvatlash vositalarini belgilaydi. UML dan ma'lum bir metodologiyasiz foydalanish mumkin, chunki u jarayondan mustaqil va qaysi jarayon opsiyasi qo'llanilishidan qat'i nazar, ishlab chiqish jarayonida qabul qilingan qarorlarni hujjatlashtirish va yaratilgan modellarni ko'rsatish uchun diagrammalardan foydalanishingiz mumkin.

Dasturiy ta'minot tizimi dasturchilar uchun yangi texnologiyalarni sinab ko'rish va loyiha menejeri uchun tajriba orttirish uchun emas, balki foydalanuvchining muayyan muammolarini hal qilish uchun yaratilgan. Umuman olganda, ishlab chiqish jarayonida ob'ektga yo'naltirilgan yondashuv, UML, RUP dan foydalanasizmi yoki XP (ekstremal dasturlash) usulidan foydalangan holda tizim yaratasizmi, foydalanuvchining ahamiyati yo'q. Muayyan usullardan, texnologiyalardan foydalanish va loyihaning optimal ichki tuzilishini yaratish ishlab chiquvchilarning vijdoniga bog'liq bo'lib, ular oldingi tajriba va o'z xohishlariga ko'ra qaror qabul qiladilar. Biroq, foydalanuvchi o'z talablarini e'tiborsiz qoldirganingiz uchun sizni kechirmaydi. Dasturiy ta’minot tizimi eng ilg‘or uslub va texnologiyalar yordamida o‘n marta ishlab chiqilgan bo‘lsa ham, foydalanuvchi undan “mazmunli natija” deb atalmagan natijani ololmasa, dasturiy ta’minot loyihangiz ayanchli tarzda barbod bo‘ladi.

Bundan kelib chiqadiki, UML-ni o'ylamasdan qo'llash, moda bo'lgani uchun, nafaqat rivojlanishni muvaffaqiyatga olib keladi, balki katta hajmdagi qo'shimcha adabiyotlarni o'rganishi kerak bo'lgan xodimlar va loyiha menejerlari orasida norozilikni keltirib chiqarishi mumkin. loyiha bo'yicha mehnat xarajatlari oshadi va daromadlar o'smaydi. Ushbu texnologiyani amalga oshirishdan nimani olishni xohlayotganingizni aniq tushunishingiz va ushbu maqsadga amal qilishingiz kerak. UML-dan foydalanish ishlab chiqish resurslarini tejaydi, chunki bu tizim haqida tasavvurga ega bo'lish uchun sxemalar va prototiplarni yaratishdan ko'ra tezroq, beqiyos kamroq resurslarni sarflashga imkon beradi.

Diagrammalar loyiha a'zolarining bir-biri bilan muloqot qilishlarini osonlashtiradi va ayniqsa qimmatli bo'lgan narsa tizimning oxirgi foydalanuvchilarini jarayonga jalb qiladi. Modellashtirish sizga loyiha xatarlarini kamaytirishga imkon beradi, chunki dasturchilar uchun noaniq natijaga borishdan ko'ra aniq va tushunarli narsalarni qilish har doim osonroqdir. Diagrammalarni yaratish qurilishda loyihani yaratishga o'xshaydi - siz usiz ham qilishingiz mumkin, masalan, yozgi uyda shiypon qurishda, ammo bino qanchalik katta bo'lsa (bizning holatlarimizda dasturiy mahsulot), bu qanchalik qiyin bo'lsa. qilish va yakuniy natija qanchalik noaniq.

Men bir marta bozorda o'n yil davomida ancha muvaffaqiyatli bo'lgan, lekin ish jarayonida modellashtirishdan umuman foydalanmagan, balki prototiplarga asoslangan dasturiy ta'minot kompaniyasida RUP bo'yicha seminar o'tkazdim. Zalda yigirmaga yaqin yosh va tajribali dasturchilar yig'ildi, ular RUP va UML haqida aytganlarimni diqqat bilan tinglashdi. Ulardan biri misol diagrammalari bilan qoplangan taxtaga qarab shunday dedi: "Bularning barchasi qiziqarli va ehtimol boshqa loyihalar uchun yaxshidir," dedi u, "lekin biz bularning barchasisiz ancha vaqtdan beri ishlayapmiz, chunki biz Biz hali ham UMLsiz qildik, ehtimol bizga kerak emas."

Bu savol meni dasturiy ta'minot ishlab chiqaruvchi kompaniyada muqarrar ravishda ro'y berishi kerak bo'lgan biznes-jarayonlarning o'zgarishi sanoat korxonasida axborot tizimini joriy qilish kabi qiyin bo'lishi mumkin, deb o'yladi. Dasturiy ta'minotni ishlab chiquvchi kompaniya xodimlarining malakasi ancha yuqori bo'lganligi sababli, bunday odamlar uchun "oddiy odamlarga" qaraganda o'z qarashlaridan voz kechish qiyinroq va yuzaga keladigan qiyinchiliklar va rad etishni protsessualdan ob'ektga o'tish bilan taqqoslash mumkin. yo'naltirilgan fikrlash.

1.Talablarning ta'rifi

Birlashtirilgan jarayon - bu foydalanuvchilarning o'zaro ta'siri stsenariylarini aks ettiruvchi foydalanish holatlariga asoslangan jarayon. Aslida, bu foydalanuvchilarning dasturiy ta'minot tizimiga tashqi ko'rinishi. Shunday qilib, RUP ma'lumotlariga ko'ra, rivojlanishning eng muhim bosqichlaridan biri faqat foydalanuvchilar va tahlilchilarning xayoliga kelishi mumkin bo'lgan tizimning ishlashi uchun barcha mumkin bo'lgan istaklarni to'plashdan iborat bo'lgan talablarni aniqlash bosqichi bo'ladi. Keyinchalik, bu ma'lumotlarni tizimlashtirish va tizimlashtirish kerak bo'ladi, ammo bu bosqichda foydalanuvchilar bilan suhbatlar va hujjatlarni o'rganish orqali tahlilchilar kelajakdagi tizim uchun iloji boricha ko'proq talablarni to'plashlari kerak, bu birinchi qarashda ko'rinadigan darajada oddiy emas. Foydalanuvchilar ko'pincha oxirida nima olishlari kerakligini bilishmaydi. Ushbu jarayonni osonlashtirish uchun tahlilchilar foydalanish holatlari diagrammalaridan foydalanadilar (2-rasm).

2-rasm. Foydalanish misoli diagrammasiga misol

Diagramma - bu tizim bilan o'zaro aloqada bo'lgan aktyorlar (aktantlar) va dasturiy ta'minot ob'ektlarining ularning harakatlariga reaktsiyasi. Aktyorlar ham foydalanuvchilar, ham axborotni uzatishi yoki qabul qilishi kerak bo'lgan tashqi agentlar bo'lishi mumkin. Foydalanish holati belgisi tizimning tashqi kiritishga munosabatini aks ettiradi va faol uchun nima qilish kerakligini ko'rsatadi.

Muayyan foydalanish holatini batafsil bayon qilish uchun faoliyat diagrammasi qo'llaniladi, uning misoli 3-rasmda keltirilgan.

guruch. 3 Faoliyat diagrammasiga misol

Foydalanish diagrammasining soddaligi tahlilchilarga talablarni aniqlash jarayonida mijozlar bilan oson muloqot qilish imkonini beradi, tizimga qo'yiladigan cheklovlarni va individual talablarni amalga oshirishda, masalan, tizimning javob vaqti, keyinchalik ular ishlamaydigan bo'limga kiradi. talablar.

Foydalanish diagrammasi test stsenariylarini yaratish uchun ham ishlatilishi mumkin, chunki foydalanuvchilar va tizim o'rtasidagi barcha o'zaro aloqalar allaqachon aniqlangan.

Talablarni to'g'ri aniqlash uchun ishlab chiquvchilar kelajakdagi tizim ishlaydigan kontekstni (mavzu sohasining bir qismini) tushunishlari kerak. Buning uchun domen modeli va biznes modeli yaratiladi, ular bir xil masalaga turlicha yondashuvlardir. Ko'pincha bitta narsa yaratiladi: domen modeli yoki biznes modeli.

Ushbu modellar orasidagi farq shundaki, domen modeli tizim ishlaydigan muhim tushunchalarni va ularning bir-biri bilan aloqalarini tavsiflaydi. Holbuki, biznes modeli tizim qo'llab-quvvatlashi kerak bo'lgan biznes jarayonlarini (mavjud yoki kelajak) tavsiflaydi. Shu sababli, ushbu model jarayonga jalb qilingan biznes ob'ektlarini belgilashdan tashqari, ishchilarni, ularning mas'uliyatini va ular bajarishi kerak bo'lgan harakatlarini belgilaydi.

Domen modelini yaratish uchun oddiy sinf diagrammasi qo'llaniladi (6-rasm), lekin biznes modelini yaratish uchun bu etarli emasligi aniq. Bunday holda, biznes-jarayonlarning mohiyatini aks ettiruvchi qo'shimcha piktogrammalardan foydalangan holda foydalanish diagrammasi qo'llaniladi - bular tadbirkorlik sub'ekti, biznesdan foydalanish holati, tadbirkorlik sub'ekti va biznes boshqaruvi. Bu model ishlab chiqish jarayonida yaratilgan keyingi model – tahlil modeliga ancha yaqinroq.

2. Tahlil

Tizimning ishlashi uchun talablar va kontekstni aniqlagandan so'ng, olingan ma'lumotlarni tahlil qilish vaqti keldi. Tahlil jarayonida ishlab chiquvchilarni kelajakdagi tizim arxitekturasiga yo'naltiradigan analitik model yaratiladi. Analitik model - tizimning tashqi ko'rinishini ko'rsatadigan foydalanish misolidan farqli o'laroq, tizimning ichkaridan ko'rinishi.

Ushbu model sizga tizimni qanday loyihalash kerakligini, qanday sinflarga ega bo'lishi kerakligini va ular bir-biri bilan qanday munosabatda bo'lishi kerakligini tushunishga imkon beradi. Uning asosiy maqsadi - talablarni yig'ish bosqichida aniqlangan funksionallikni amalga oshirish yo'nalishini aniqlash va tizim arxitekturasini eskiz qilish.

Keyinchalik yaratilgan dizayn modelidan farqli o'laroq, tahlil modeli ko'proq kontseptual model bo'lib, faqat ishlab chiquvchilarni amalga oshirish sinflariga yaqinlashtiradi. Ushbu modelda oldingi modelda yuzaga kelishi mumkin bo'lgan qarama-qarshiliklar bo'lmasligi kerak.

UML yordamida tahlil modelini ko'rsatish uchun "chegara sinfi", "ob'ekt", "nazorat" stereotiplari (xulq-atvor namunalari) bo'lgan sinf diagrammasi va batafsillashtirish uchun hamkorlik diagrammasi qo'llaniladi (4-rasm). "Chegara sinfi" stereotipi tashqi faollar bilan o'zaro ta'sir qiluvchi sinfni, "ob'ekt" stereotipi ma'lumotlar ombori bo'lgan sinflarni va "nazorat" stereotipi ob'ektlarga so'rovlarni boshqaradigan sinflarni tasvirlaydi.

Shakl 4. Hamkorlik diagrammasining namunasi

Xabarlarni raqamlash ularning tartibini ko'rsatadi, lekin diagrammaning maqsadi almashilgan xabarlar tartibini hisobga olish emas, balki sinflarning bir-biri bilan aloqalarini aniq ko'rsatishdir.

Agar biz o'zaro ta'sir qilish tartibiga e'tibor qaratadigan bo'lsak, unda yana bir vakillik 5-rasmda ko'rsatilgan ketma-ketlik diagrammasi (Sequence) bo'ladi. Bu diagramma sizga jarayonning ketma-ketligini vizual ravishda ko'rsatib, vaqt o'tishi bilan xabarlar almashinuvini ko'rish imkonini beradi. Rational Rose kabi model yaratish vositasidan foydalanganda, ushbu ikki turdagi diagrammalar bir-biridan avtomatik ravishda yaratilishi mumkin (masalan, Rational Rose haqida ko'proq o'qishingiz mumkin).

Guruch. 5 Ketma-ketlik diagrammasiga misol

Ikki diagrammaning qaysi birini birinchi bo'lib yaratish qarori individual ishlab chiquvchining afzalliklariga bog'liq. Ushbu diagrammalar bir xil jarayonning tasviri bo'lganligi sababli, ularning ikkalasi ham ob'ektlar orasidagi o'zaro ta'sirni aks ettirishga imkon beradi.

3. Dizayn

Tizimni yaratish jarayonining keyingi bosqichi dizayn bo'lib, uning davomida avval yaratilgan modellar asosida dizayn modeli yaratiladi. Ushbu model tizimning jismoniy amalga oshirilishini aks ettiradi va yaratilgan mahsulotni sinf va komponentlar darajasida tavsiflaydi. Tahlil modelidan farqli o'laroq, dizayn modeli amalga oshirish shartlariga, dasturlash tillari va foydalaniladigan komponentlarga aniq bog'liqdir. Tizim arxitekturasini eng aniq tushunish uchun ushbu model iloji boricha rasmiylashtirilgan bo'lishi va butun tizimni ishlab chiqish hayoti davomida yangilanib turishi kerak.

Dizayn modelini yaratish uchun UML diagrammalarining butun majmuasi qo'llaniladi: sinf diagrammasi (5-rasm), hamkorlik diagrammasi, o'zaro ta'sir diagrammasi, faoliyat diagrammasi.

6-rasm. Sinf diagrammasining namunasi

Bundan tashqari, ushbu ish jarayoni Joylashtirish diagrammasi asosida amalga oshiriladigan joylashtirish modelini yaratishi mumkin. Bu tarmoqdagi qurilmalarni taqsimlashni modellashtirish uchun mo'ljallangan eng oddiy diagramma turi. Displey uchun protsessor va qurilma piktogrammalarining faqat ikkita varianti va ular orasidagi ulanishlar ishlatiladi.

4. Amalga oshirish

Amalga oshirish jarayonining asosiy vazifasi tizimni komponentlar - dasturning dastlabki kodlari, skriptlar, ikkilik fayllar, bajariladigan modullar va boshqalar shaklida yaratishdir. Ushbu bosqichda loyihalash modelining elementlari qanday amalga oshirilishini tavsiflovchi amalga oshirish modeli yaratiladi, qaysi sinflar aniq komponentlarga kiritiladi. Ushbu model tanlangan dasturlash muhitida qabul qilingan tuzilish va modullashtirish mexanizmlariga muvofiq ushbu komponentlarni tashkil qilish usulini tavsiflaydi va komponentlar diagrammasi bilan ifodalanadi (7-rasm).

guruch. 7 Komponentlar diagrammasi misoli

5. Sinov

Sinov jarayonida amalga oshirish natijalari tekshiriladi. Bu jarayon uchun test namunasi yaratiladi, u test holatlari, test protseduralari, test komponentlaridan iborat, lekin UML diagrammasi tasviriga ega emas, shuning uchun biz bu haqda to'xtalmaymiz.

6. Xulosa

Bu erda faqat Ratsional metodologiyaning asosiy jarayonlari ko'rib chiqildi. RUP juda keng bo'lib, turli xil dasturiy ta'minot loyihalarini amalga oshirish bo'yicha tavsiyalarni o'z ichiga oladi, bir necha kishidan iborat dasturchilar guruhi tomonidan dasturlarni yaratishdan tortib, turli qit'alarda minglab odamlarni birlashtirgan tarqatilgan dasturiy ta'minot loyihalarigacha. Biroq, ularning katta farqlariga qaramay, UML yordamida yaratilgan modellardan foydalanish usullari bir xil bo'ladi. Rivojlanishning turli bosqichlarida yaratilgan UML diagrammalari dasturiy ta'minot loyihasining qolgan artefaktlaridan ajralmas va ko'pincha individual RUP jarayonlari o'rtasidagi bog'liqlikdir.

Muayyan diagrammalardan foydalanish to'g'risidagi qaror kompaniyada tashkil etilgan rivojlanish jarayoniga bog'liq bo'lib, u birlashtirilgan deb ataladigan bo'lsa-da, muzlatilgan narsa emas. Rational nafaqat uni takomillashtirish va takomillashtirishni taklif qiladi, balki RUP ma'lumotlar bazasiga o'zgartirishlar kiritish uchun maxsus vositalarni ham taqdim etadi.

Ammo har qanday holatda ham, UML dan birlashtirilgan jarayon bilan birgalikda foydalanish prognoz qilinadigan natijaga erishish, ajratilgan byudjetni qondirish, loyiha ishtirokchilarining ta'sirini va yaratilgan dasturiy mahsulot sifatini oshirish imkonini beradi.

Kratchen. F. Kirish Ratsional birlashtirilgan jarayon . Ed. 2-chi - M.: Uilyams nashriyoti, 2002. - 240 pp.: kasal.

Jacobson A., Buch G., Rambo J. Birlashtirilgan dasturiy ta'minotni ishlab chiqish jarayoni - Sankt-Peterburg: Peter, 2002. - 496 pp.: kasal.

Fowler M., Scott K. UML qisqacha. Ob'ektni modellashtirishning standart tilini qo'llash: Transl. ingliz tilidan – M.:Mir, 1999. – 191 b., kasal.

Bek. E. Ekstremal dasturlash. – Sankt-Peterburg: Pyotr, 2002. – 224 b.: kasal.

TrofimovS. CASE texnologiyalari: Rational Roseda amaliy ish.
Ed. 2-chi - M .: Binom-Press, 2002 - 288 b.

Unified Process birlashgan modellash tilidan faol foydalanadi ( UML). Yadroda UML ishlab chiqish guruhiga dasturiy ta'minotni ishlab chiqish uchun zarur bo'lgan murakkab jarayonlarning xilma-xilligini soddalashtirilgan tarzda tushunishga imkon beruvchi model yotadi. Turli xil modellar ishlatiladi Birlashtirilgan jarayon, tizimni tasavvur qilish, uning tuzilishi va xatti-harakatlarini tavsiflash va ishlab chiqish jarayonida qabul qilingan qarorlarni hujjatlashtirish imkonini beradi.

Kelib chiqish tarixi

Ramkaning kelib chiqishi xodimning ishida yotadi Ericsson Ivar Jacobson, 1960-yillarning oxirida nashr etilgan. Jeykobson va uning hamkasblari ulkan telekommunikatsiya tizimlarini "bloklar" (keyinchalik "komponentlar" deb nomlanuvchi) qatlamlari yordamida modellashtirdilar: pastki qatlamlar yuqori qatlamlardan quyi tizimlar uchun asos bo'lib xizmat qildi. Jamoa tizim foydalanuvchilari bilan sodir bo'lishi mumkin bo'lgan "trafik holatlari" ni hisobga olgan holda pastki bloklarni qurdi. Aynan shu "hodisalar" foydalanish holatlarining prototipi bo'lib, keyinchalik ular kiritilgan UML. Jeykobsonning ishi, shuningdek, ishlatiladigan diagrammalarni yaratishga ilhom berdi UML, shu jumladan faoliyat va ketma-ketlik diagrammalari.

1987 yilda Jeykobson o'z kompaniyasiga asos soldi Ob'ekt AB va hamkorlar bilan birgalikda bir necha yil davomida loyiha va mahsulotni ishlab chiqishga sarfladilar E'tiroz. 1995 yilda Jeykobson "Kitobini nashr etdi. Ob'ektga yo'naltirilgan dasturiy ta'minot muhandisligi”, foydalanish holatlari orqali yakuniy mahsulotga aylantiriladigan mijozlar talablaridan kelib chiqqan holda ishlab chiqish jarayonini tavsiflaydi. Kitobning chiqarilishi yadroning onlayn versiyasining birinchi nashriga to'g'ri keldi Birlashtirilgan jarayon.

1995 yilda kompaniya Ob'ekt AB korporatsiya tomonidan qabul qilinadi Ratsional. Hamkasblar soni sezilarli darajada ko'payib, Jeykobson jarayonni kengaytira boshlaydi E'tiroz, uni loyihalarni boshqarish va ishlab chiqish vositalari bilan to'ldirish. Grady Booch va ishlagan Jeyms Rumbaugh bilan birga Ratsional Ilgari, Jeykobson "uch do'stlar" guruhining a'zosi bo'lib, u jarayonni yaratishga rahbarlik qilgan. Ratsional e'tiroz jarayoni (ROP), shuningdek tarqatish Birlashtirilgan jarayon uchun asos bo'ldi Birlashtirilgan modellashtirish tili.

Ishlash jarayonida ROP Va UML, korporatsiya Ratsional dasturiy ta'minotni ishlab chiqish vositalarini yaratish bilan shug'ullanadigan kompaniyalarning qo'shilishi va sotib olinishi davom etdi. Ushbu vositalar talablarni boshqarish ("RequisitePro"), umumiy test ("SQA"), ishlash testi, konfiguratsiyani boshqarish va o'zgarishlarni boshqarish imkoniyatlarini taqdim etdi. 1998 yilda Ratsional mahsulot nomini o'zgartiradi RUP, uning kontseptual yadrosi qolmoqda Birlashtirilgan jarayon.

Xususiyatlari

Birlashtirilgan jarayon asoslangan foydalanish holatlari, tizim bilan o'zaro aloqada bo'lgan bir yoki bir nechta aktyorlarni tavsiflash va jarayon ishtirokchilari uchun qimmatli natijalarni olish. Aynan foydalanish holatlari talablarni to'plash va muhokama qilishdan boshlab, tahlil qilish, loyihalash va amalga oshirishgacha bo'lgan butun rivojlanish jarayonini boshqaradigan asosiy harakatlantiruvchi kuchdir. Foydalanish holatlari tashqi o'quvchiga tushunarli bo'lishi uchun sodda va tushunarli tilda tasvirlangan.

Ga binoan Birlashtirilgan jarayon, rivojlanish jarayonining markazida yotadi arxitektura- butun tizimning asosiy tashkil etilishi. U statik va dinamik elementlarni, ularning o'zaro ta'sirini o'z ichiga olishi mumkin va mahsulot samaradorligi, kengaytirilishi, elementlarni qayta ishlatish qobiliyati va iqtisodiy va texnik cheklovlarni engib o'tishga yordam beradi. Loyiha jamoasi arxitektura tavsifi ustida ishlashni imkon qadar erta boshlaydi va rivojlanish jarayonida uni doimiy ravishda kengaytiradi va yaxshilaydi. Arxitektura muhim jihat hisoblanadi Birlashtirilgan jarayon bir qator sabablarga ko'ra, ularning kaliti nima sodir bo'layotganining to'liq rasmini ko'rish qobiliyati, ishlab chiquvchining sa'y-harakatlarini to'g'ri qo'llash, komponentlarni qayta ishlatish imkoniyatlarini osonlashtirish, tizimni ishlab chiqish va foydalanish holatlarini to'g'ri tanlashdir.

Uchinchi asosiy tamoyil Birlashtirilgan jarayon foydalanish hisoblanadi iterativ va inkremental yondashuv. Iteratsiyalar - bu tizimning yangi versiyasini ishga tushirish imkonini beruvchi miniatyura loyihalari. Takrorlash natijasi, tizimga kiritilgan o'zgartirishlar o'sish deyiladi. Xususan, iterativ yondashuv tizim arxitekturasini izchil takomillashtirish, talablarning doimiy o'zgarishini boshqarish va butun loyiha rejasini moslashuvchan tarzda sozlash imkonini beradi. Uzluksiz integratsiya tamoyiliga sodiqlik erta bosqichda yuzaga kelishi mumkin bo'lgan muammolarni aniqlash imkonini beradi. Bundan tashqari, iteratsiya texnik cheklovlar, arxitektura va o'zgaruvchan talablar bilan bog'liq xavflarni minimallashtirishga yordam beradi.

Rivojlanish bosqichlari

Oddiy loyiha uchun rivojlanish bosqichlarining nisbiy hajmi

Har bir rivojlanish tsikliga ko'ra Birlashtirilgan jarayon, to'rt bosqichdan iborat bo'lib, ular loyihaning muhim bosqichlari orasidagi vaqtni ifodalaydi, bu menejerlarga rivojlanish jarayonini davom ettirish, ish hajmi, byudjet va jadval bo'yicha muhim qarorlar qabul qilish imkonini beradi.

Ish oqimining turlari

Ichkarida Birlashtirilgan jarayon Har bir rivojlanish bosqichida ish jarayonlarining besh turi mavjud: talablar, tahlil, loyihalash, amalga oshirish va sinovdan o'tkazish.

Har bir jarayon loyiha jamoasining turli a'zolari tomonidan bajariladigan tadbirlar majmuidir. Shunday qilib, talablarni yig'ish jarayonlarining maqsadi tizim uchun asosiy funktsional talablarni aniqlash imkonini beradigan foydalanish holatlari modelini yaratishdir. Tahlil jarayonlari va tegishli model ishlab chiquvchilarga funktsional talablarni tuzish imkonini beradi; Dizayn jarayoni foydalanish holatlarining jismoniy bajarilishini tavsiflaydi va quyidagi model uchun mavhumlikdir. Amalga oshirish jarayoni va model dizayn elementlarining dasturiy ta'minot komponentlari, jumladan, manba kodi, dinamik kutubxonalar va boshqalar bilan qanday bog'liqligini tasvirlaydi. Testni tavsiflovchi oxirgi model qanday tizim testlari va birlik testlarini bajarish kerakligini va ishlab chiqish guruhi ularni qanday bajarishi kerakligini tushuntiradi.

Takrorlash va o'sish

Yagona jarayonda tavsiflangan bosqichlarning har biri quyidagilardan iborat iteratsiyalar, ular cheklangan muddatga ega miniatyura sub-loyihalari. Odatda, har bir iteratsiya ish jarayonining barcha besh elementini turli darajada o'z ichiga oladi. Takrorlash natijasi oshirish, mahsulotning oldingi versiyasiga nisbatan yaxshilanishlarni o'z ichiga olgan nashr.

Ratsional birlashtirilgan jarayon(RUP) - bu Rational Software tomonidan ishlab chiqilgan va sotiladigan dasturiy ta'minotni ishlab chiqish texnologiyasi asosidir. U dasturiy ta'minotni ishlab chiqish bo'yicha jahon ilg'or tajribalarini o'z ichiga oladi va dasturiy ta'minotni ishlab chiqish tashkilotida vazifalar va mas'uliyatlarni belgilash va boshqarishga intizomiy yondashuvni ta'minlaydi. Ushbu jarayonni qo'llash orqali dasturiy ta'minotni ishlab chiqish guruhlari o'zlarining oxirgi foydalanuvchilari ehtiyojlariga javob beradigan yuqori sifatli dasturiy ta'minotni yaratishlari va buni taxmin qilinadigan jadval va byudjet doirasida amalga oshirishlari mumkin.

RUP dasturiy ta'minot bo'yicha mutaxassislarga hozirgi eng yaxshi amaliyotlarni samarali qo'llash uchun yo'l-yo'riq beradi, masalan iterativ rivojlanish, ilova arxitekturaga asoslangan yondashuv, foydalanish holatlari, jarayonning barcha bosqichlarida xavflarni kamaytirish va dasturni doimiy tekshirish.

Ratsional yagona jarayon ko'plab muvaffaqiyatli loyihalardan to'plangan bir nechta asosiy tamoyillarga asoslanadi:

· Avvalroq asosiy xavf-xatarlarga hujum qilishni boshlang va uni doimiy ravishda bajaring, aks holda ular o'zlari sizga qarshi hujumga o'tadilar.

· Mijozlarning talablari bajarilishini ta'minlash.

· Diqqatni bajarilayotgan dasturga qarating.

· Loyihaning boshidanoq o'zgarishlarga moslash.

· Erta bajariladigan arxitekturani o'rnatish.

· Komponentlardan tizim yaratish.

· Bir jamoa bo'lib birgalikda ishlash.

· Sifatni o'ylash emas, balki hayot tarziga aylantiring.

RUP foydalanadi iterativ yondashuv Har bir iteratsiya talablarni bajarish, tahlil qilish, loyihalash, amalga oshirish va sinovdan o'tadi. Har bir iteratsiya oldingi takrorlash natijalariga asoslanadi va yakuniy mahsulotga bir qadam yaqinlashadigan bajariladigan dasturni ishlab chiqaradi.

RUP taqdim etadi takroriy rivojlanishga tizimli yondashuv, loyihani to'rt bosqichga bo'lish: Boshlanish, Loyihalash, Qurilish va Amalga oshirish. Har bir bosqich muhim bosqich deb ataladigan jarayonning nazorat nuqtasi bilan birga keladi, bunda keyingi bosqichning maqsadlariga erishish tekshiriladi va keyingi bosqichga o'tish (yoki o'tmaslik) to'g'risida qaror qabul qilinadi. Shunday qilib, RUPning to'rt bosqichining har biri muhim bosqichga va aniq belgilangan maqsadlarga ega. Bu maqsadlar qanday vazifalarni bajarish va qanday artefaktlarni yaratishni aniqlash uchun ishlatiladi. Har bir bosqich faqat bosqichning biznes maqsadlariga erishish uchun zarur bo'lgan narsalarga qat'iy e'tibor qaratadi.

Barcha jarayon elementlari - rollar, vazifalar, artefaktlar va tegishli tushunchalar, qo'llanmalar va andozalar nomli mantiqiy konteynerlarga guruhlangan Fanlar(fanlar). Standart RUP mahsulotida faqat to'qqizta intizom mavjud. Bularga quyidagilar kiradi: biznesni modellashtirish, talablarni boshqarish, loyihalarni boshqarish, o'zgarishlarni boshqarish va atrof-muhit.

Har bir jarayonning ish jarayoni: talablarni to'plash, tahlil qilish, loyihalash, amalga oshirish va sinovdan o'tkazish tegishli artefaktlar va tadbirlar to'plamini belgilaydi. Eslatib o'tamiz, artefakt bu hujjat, hisobot, bajariladigan element va boshqalar. Artefakt ishlab chiqarilishi, qayta ishlanishi yoki iste'mol qilinishi mumkin.

Model- artefaktning eng muhim turi. To'qqizta model taqdim etilgan bo'lib, ular birgalikda dasturiy ta'minot tizimlarini vizualizatsiya qilish, spetsifikatsiya qilish, loyihalash va hujjatlashtirish bo'yicha barcha echimlarni qamrab oladi:

· biznes modeli. Tizim yaratilayotgan tashkilotning mavhumligini belgilaydi;

· domen modeli. Tizimning kontekstual muhitini tuzatadi;

· Modeldan foydalanish holati. Tizim uchun funktsional talablarni belgilaydi.

· tahlil modeli. Tizim talablarini dizayn modeli nuqtai nazaridan izohlaydi;

· dizayn modeli. Muammoning domen lug'atini va uning echimini belgilaydi;

· joylashtirish modeli. Tizim ishlaydigan apparat topologiyasini belgilaydi;

· amalga oshirish modeli. Jismoniy tizimni yig'ish va amalga oshirish uchun ishlatiladigan qismlarni belgilaydi;

· sinov modeli. Tizimni sinab ko'rish uchun test holatlarini belgilaydi;

· jarayon modeli. Tizimdagi parallellik va sinxronizatsiya mexanizmlarini belgilaydi.

Texnik artefaktlar to'rtta asosiy to'plamga bo'lingan:

· talablar to'plami. tasvirlaydi Nima tizim bajarishi kerak;

· dizayn to'plami.

· ilovalar to'plami. Ishlab chiqilgan dasturiy ta'minot komponentlarini yig'ishni tavsiflaydi;

· joylashtirish to'plami. Taqdim etilgan konfiguratsiya haqida barcha ma'lumotlarni taqdim etadi.

Talablar to'plami U Use Case modeli, funktsional bo'lmagan talablar modeli, domen modeli, tahlil modeli va foydalanuvchi ehtiyojlarini ifodalashning boshqa shakllarini o'z ichiga olishi mumkin.

Dizayn to'plami dizayn modeli, test modeli va tizim mohiyatini ifodalashning boshqa shakllarini o'z ichiga olishi mumkin.

Amalga oshirish to'plami tizimni tashkil etuvchi dasturiy ta'minot elementlari haqidagi barcha ma'lumotlarni (dastur kodi, konfiguratsiya fayllari, ma'lumotlar fayllari, dasturiy ta'minot komponentlari, tizimni yig'ish ma'lumotlari) guruhlaydi.

Joylashtirish to'plami tizimni qadoqlash, jo'natish, o'rnatish va ishga tushirish haqidagi barcha ma'lumotlarni guruhlarga ajratadi.

Har bir texnologik jarayon bilan birga keladi xavf. Dasturiy ta'minotni ishlab chiqishda qoniqarsiz natija (BMT) bo'lishi mumkin: byudjetdan oshib ketish, past ishonchlilik, noto'g'ri ishlash va boshqalar. Xatarning ta'siri ifoda yordamida hisoblanadi

Xavf ko'rsatkichi = Ehtimollik (LP) * Yo'qotish (LP).

Risklarni boshqarish oltita harakatni o'z ichiga oladi:

1. Riskni aniqlash - loyihadagi xavf elementlarini aniqlash.

2. Risk tahlili - har bir xavf elementi uchun yo'qotish ehtimoli va hajmini baholash.

3. Risklar reytingi - xavf elementlarini ularning ta'sir darajasiga qarab tartiblash.

4. Risklarni boshqarishni rejalashtirish - xavfning har bir elementi bilan kurashishga tayyorgarlik.

5. Riskni hal qilish - xavf elementlarini yo'q qilish yoki hal qilish.

6. Risk monitoringi - xavf elementlarining dinamikasini kuzatish, tuzatish choralarini ko'rish.

Birinchi uchta harakat xavfni baholash bosqichiga, oxirgi uchta harakat xavfni nazorat qilish bosqichiga tegishli.

Risk manbalarining uchta toifasi mavjud: loyiha tavakkalchiligi, texnik risk va tijorat riski. Xavf elementlarini aniqlagandan so'ng, ularning dasturiy ta'minot loyihasiga ta'siri miqdorini aniqlash va mumkin bo'lgan yo'qotishlar haqidagi savollarni hal qilish kerak. Ushbu muammolar xavflarni tahlil qilish bosqichida ko'rib chiqiladi. Va nihoyat, har bir xavf elementini boshqarish rejasi, ya'ni har bir xavf elementini boshqarish uchun funktsiyalar to'plami dasturiy ta'minot loyihasining umumiy rejasiga kiritilgan.