Rup ish oqimlari va uml diagrammalari. Birlashgan psixologik rivojlanish jarayoni

Artefaktlar

Mahsulot qoldig'i bu ustuvorligi bo'yicha buyurtma qilingan, funksionallikka qo'yiladigan talablar ro'yxatini o'z ichiga olgan hujjat. Mahsulotning orqada qolishi - bu amalga oshirilishi kerak bo'lgan narsalarning ro'yxati. Ushbu ro'yxatdagi narsalar "hikoyalar" ( foydalanuvchi hikoyasi) yoki qoloq elementlar ( ortda qolgan narsalar). Mahsulot qoldig'i Scrum jarayonining barcha ishtirokchilari uchun tahrirlash uchun ochiq.

Rational Unified Process (RUP) Rational Software-ning eng yaxshi dasturiy ta'minotini ishlab chiqish metodologiyasidir. Ko'pgina muvaffaqiyatli dasturiy ta'minot loyihalari tajribasidan kelib chiqib, "Birlashgan jarayon" sanoatni ishlab chiqish usullari asosida murakkab dasturiy ta'minot tizimlarini yaratishga imkon beradi. RUP-ning asosiy ustunlaridan biri bu Unified Modeling Language (UML) yordamida modellarni yaratish jarayoni. Ushbu maqola UML diagrammalarini Ratsional dasturiy ta'minotni ishlab chiqish bo'yicha ish jarayoniga qo'llash haqida.

Hech kimga sir emaski, dasturiy ta'minotni yaratish murakkab jarayon bo'lib, bir tomondan ijodkorlik bilan juda bog'liq, boshqa tomondan, garchi yuqori rentabellikga ega bo'lsa-da, bu juda qimmatga tushadigan biznesdir. Bozordagi qattiq raqobat ishlab chiquvchilarni yanada samarali ish usullarini izlashga majbur qiladi. Dasturiy ta'minot tizimlarini yanada qisqa muddatlarda, arzonroq va sifatli ravishda yaratish orqali. Dasturlarning murakkabligi doimiy ravishda oshib boradi. Yaqin vaqtgacha dasturiy mahsulotlar yaqin kelajakda jismoniy shaxslar tomonidan yoki masalan, avtomatlashtirilgan korxonaning IT bo'limida yaratilishi mumkin edi.

Endi "tiz cho'kkan" dasturlarni yaratadigan yolg'iz odamlarga kichik kommunal xizmatlar maydoni va "og'ir" dasturiy mahsulotlar uchun turli xil kengaytma modullari qoladi. Kelajak dasturiy ta'minotni ishlab chiqishda sanoat yondashuviga tegishli. 1913 yilda Genri Ford birinchi avtomobil konveyerini ishga tushirgan va 90-yillarda xuddi shunday konveyer IT-texnologiyalar sohasida ishlatilgan. Jamoani rivojlantirish uchun ertami-kechmi yaratilishi kerak bo'lgan butunlay boshqacha yondashuv va boshqa metodika kerak.

Rational Software Corporation (http: // www .rational .com) deyarli har qanday dasturiy mahsulotni yaratish bo'yicha ko'rsatmalar to'plami bo'lgan Rational Unified Process (RUP) deb nomlangan tuzilgan bilimlar bazasini ishga tushirdi. Eng yaxshi ishlanmalar tajribasini o'zlashtirgan holda, RUP dasturiy ta'minot tizimini o'z vaqtida, ma'lum bir funksionallik va ajratilgan byudjet doirasida olish uchun qachon, kim va nimani amalga oshirish kerakligini batafsil aytib beradi.

Birlashtirilgan jarayonni mijozlar talablarini dasturiy ta'minot tizimiga aylantirish uchun zarur bo'lgan ishlab chiquvchi kompaniyaning turli faoliyatlari yig'indisi deb hisoblash mumkin. Foydalanuvchilarga "mazmunli natijalar" beradigan va tizimdan ular kutgan narsani aniq bajaradigan tizim. Shuning uchun, jarayon tizimning foydalanish holatlari yoki boshqacha tarzda - oldingi holatlar tomonidan boshqariladi.

Mijozning talablarini o'z vaqtida amalga oshirish uchun Yagona jarayon takrorlanishlardan iborat bo'lgan bosqichlarga bo'linadi, shuning uchun jarayon takrorlanadigan va o'sib boruvchi deb ham ataladi. Har bir iteratsiya asosiy ishlarning tsiklidan o'tadi va ishlab chiquvchilarni yakuniy maqsadga olib keladi: dasturiy ta'minot tizimini yaratish. Takrorlashlar paytida loyihaning muvaffaqiyatli bajarilishi uchun zarur bo'lgan oraliq artefaktlar yaratiladi va dasturiy ta'minot tizimining takrorlanishdan takrorlanishga ko'payadigan ma'lum funktsiyalar to'plamini amalga oshiruvchi versiyasi. Jarayonning fazalari va asosiy ish oqimlari shakl. 1, shuningdek, fazalar uchun taxminiy mehnat xarajatlari berilgan.

anjir. 1 RUP bosqichlari va ish oqimlari

Shuni ta'kidlash kerakki, shakl. 1 faqatgina Yagona jarayonning asosiy faoliyatlarini ko'rsatadi. Masalan, diagrammani chalkashtirib yubormaslik uchun bu erda faoliyatni boshqarish faoliyati ko'rsatilmaydi.

Barcha dasturiy ta'minotni ishlab chiqish RUP-da artefaktlarni yaratish jarayoni sifatida ko'rib chiqiladi. Loyiha ishining har qanday natijasi, manba kodlari, ob'ekt modullari, foydalanuvchiga uzatiladigan hujjatlar, modellar bo'lsin, barcha loyiha artefaktlarining subklasslari. Loyiha guruhining har bir a'zosi o'z asarlarini yaratadi va ular uchun javobgardir. Dasturchi dasturni, menejer loyiha rejasini, tahlilchi tizim modellarini yaratadi. RUP sizga qachon, kim tomonidan va qanday artefakt yaratilishi, o'zgartirilishi yoki ishlatilishi kerakligini aniqlashga imkon beradi.

Loyiha artefaktlarining eng qiziqarli sinflaridan biri bu ishlab chiquvchilarga dasturiy ta'minot tizimining artefaktlarini aniqlash, tasavvur qilish, loyihalash va hujjatlashtirishga imkon beradigan modellardir. Har bir model ishlab chiqilayotgan tizimning o'ziga xos ko'rinishi bo'lib, muammolarni ajratish va echimlarni taklif qilish uchun mo'ljallangan. Modellarning o'zini o'zi ta'minlashi tahlilchi yoki ishlab chiquvchi boshqa manbalarga murojaat qilmasdan ma'lum bir modeldan barcha kerakli ma'lumotlarni olishini anglatadi.

Modellar kelajakdagi tizimni, uning ob'ektlarini va ularning o'zaro ta'sirini rivojlanishga katta mablag 'sarflashdan oldin ham ko'rib chiqishga imkon beradi, uni kelajakdagi foydalanuvchilarning tashqarisidan va ichkaridan ishlab chiquvchilarning ko'zlari bilan dastlabki kod satri yaratilishidan oldin ham ko'rishga imkon beradi. Ko'pgina modellar UML diagrammasi bilan ifodalanadi, siz UML haqida ko'proq o'qishingiz mumkin, masalan.

Birlashtirilgan modellashtirish tili 1980-yillarning oxiri va 1990-yillarning boshlarida, asosan, "uch do'st" ning Gredi Buch, Jim Rambo va Ivar Jakobsonning sa'y-harakatlari tufayli paydo bo'ldi. OMG hozirda ushbu tilni standart modellashtirish tili sifatida qabul qildi, bu ishlab chiquvchilarga modellarning grafik elementlarda aks ettirish uchun aniq yozuvlarini taqdim etadi, ular loyiha a'zolari tomonidan odatda qabul qilinadi va tushuniladi.

Ammo shuni unutmaslik kerakki, modellashtirish tili faqat yozuvlarni taqdim etadi - bu tizimni tavsiflash va modellashtirish uchun vosita, va birlashtirilgan jarayon ushbu vositadan foydalanish metodologiyasini, shuningdek Rational dan metodologiyani qo'llab-quvvatlash uchun boshqa vositalarni belgilaydi. UML-dan ma'lum bir metodologiyasiz foydalanish mumkin, chunki u jarayonga bog'liq emas va jarayonning qaysi varianti qo'llanilishidan qat'i nazar, siz diagrammalardan foydalangan holda ishlab chiqilgan qarorlarni hujjatlashtirishingiz va hosil bo'lgan modellarni namoyish qilishingiz mumkin.

Dasturiy ta'minot tizimi dasturchilar tomonidan yangi texnologiyalarni sinab ko'rish va loyiha menejeri uchun tajriba orttirish uchun emas, balki aniq foydalanuvchi muammolarini hal qilish uchun yaratilgan. Umuman olganda, foydalanuvchi rivojlanish jarayonida ob'ektga yo'naltirilgan yondashuvni, UML, RUPni ishlatasizmi yoki XP (ekstremal dasturlash) usuli yordamida tizim yaratasizmi, ahamiyati yo'q. Loyihaning ma'lum metodlari, texnologiyalaridan foydalanish, maqbul ichki tuzilishini yaratish avvalgi tajriba va o'z xohish-istaklariga asoslanib qaror qabul qiladigan ishlab chiquvchilar vijdonida qoladi. Biroq, foydalanuvchi uning talablarini e'tiborsiz qoldirganingiz uchun sizni kechirmaydi. Dasturiy ta'minot tizimi zamonaviy uslublar va texnologiyalardan foydalangan holda kamida o'n marta ishlab chiqilganmi, agar foydalanuvchi undan "mazmunli natija" deb nomlanadigan narsani ololmasa, sizning dasturiy ta'minotingiz muvaffaqiyatsiz tugaydi.

Shundan kelib chiqadiki, UML-ni shunchaki modaga asoslangan holda ishlatish, nafaqat rivojlanish muvaffaqiyatiga olib kelmaydi, balki qo'shimcha ravishda katta miqdordagi qo'shimcha adabiyotlarni o'rganishga muhtoj bo'lgan xodimlar va loyiha menejerlari tomonidan loyihada mehnat xarajatlari oshib borishi sababli norozilikni keltirib chiqarishi mumkin. va daromad ko'paymaydi. Ushbu texnologiyani amalga oshirishdan nimani olishni istayotganingizni aniq belgilashingiz va ushbu maqsadga rioya qilishingiz kerak. UML-dan foydalanish rivojlanish resurslarini tejashga imkon beradi, chunki u maket va prototiplarni yaratishda, taqqoslab bo'lmaydigan darajada kam mablag 'sarflashda tizim haqida tezroq tasavvurga ega bo'lishga imkon beradi.

Diagrammalar loyiha a'zolarining bir-biri bilan aloqasini osonlashtiradi va bu, ayniqsa, qimmatli bo'lib, tizimning oxirgi foydalanuvchilarini jarayonga jalb qiladi. Modellashtirish loyihaning xatarlarini kamaytirishga imkon beradi, chunki dasturchilar uchun noaniq natijaga borishdan ko'ra aniq va tushunarli bo'lgan har doim ham osonroqdir. Diagrammalar yaratish qurilishda loyihani yaratishga o'xshaydi - masalan, yozgi dachada shiypon qurishda siz buni qila olasiz, ammo bino qanchalik katta bo'lsa (bizning holatlarimizda) dasturiy ta'minot), buni amalga oshirish qanchalik qiyin bo'lsa va yakuniy natija shunchalik noaniq bo'lsa.

Men bir paytlar dasturiy ta'minot ishlab chiqaruvchi kompaniyada RUP seminarini o'n yil davomida bozorda juda muvaffaqiyatli bo'lgan, ammo ish jarayonida umuman modellashtirishdan foydalanmaydigan, lekin prototiplarga tayanadigan dars berganman. Zalda yigirmaga yaqin yosh va tajribali dasturchilar to'plandilar, ular menga RUP va UML haqida aytgan hamma narsani diqqat bilan tingladilar. Va ulardan biri diagramma misollari tushirilgan taxtaga qarab shunday dedi: "Bularning barchasi qiziqarli va ehtimol boshqa loyihalar uchun juda mos keladi," - dedi u, - lekin biz uzoq vaqtdan beri bularning barchasi holda ishlaymiz, chunki biz hali ham biz UML holda til topishdik, ehtimol bunga muhtoj emasmiz. "

Bu savol meni RUP va UML dasturlarini tatbiq etishda dasturiy ta'minot kompaniyasida yuz berishi kerak bo'lgan biznes jarayonlarining o'zgarishi sanoat korxonalarida axborot tizimini tatbiq etish kabi qiyin bo'lishi mumkin deb o'ylashga majbur qildi.Har qanday amalga oshirish stereotiplarni buzishdir. Dasturiy ta'minot ishlab chiqaruvchi kompaniya xodimlarining malakasi ancha yuqori bo'lganligi sababli, bunday odamlar uchun o'z qarashlaridan voz kechish "shunchaki o'liklardan" ko'ra qiyinroq, va yuzaga keladigan qiyinchiliklar va rad etishni protsessualdan ob'ektiv yo'naltirilgan fikrlashga o'tish bilan taqqoslash mumkin.

1. Talablarni aniqlash

Birlashtirilgan jarayon - bu foydalanuvchiga ta'sir o'tkazish stsenariylarini aks ettiradigan, ishlatishga mo'ljallangan jarayon. Aslida, bu foydalanuvchi dasturiy ta'minot tizimiga tashqi tomondan qarashi. Shunday qilib, rivojlanishning eng muhim bosqichlaridan biri, RUP ma'lumotlariga ko'ra, tizimning ishlashi uchun faqatgina foydalanuvchilar va tahlilchilarda bo'lishi mumkin bo'lgan barcha mumkin bo'lgan istaklarni to'plashdan iborat talablarni aniqlash bosqichi bo'ladi. Keyinchalik, bu ma'lumotlar tizimlashtirilishi va tuzilishi kerak bo'ladi, ammo hozirgi bosqichda foydalanuvchilar bilan suhbatlar paytida va hujjatlarni o'rganish paytida tahlilchilar kelajak tizimiga iloji boricha ko'proq talablarni to'plashlari kerak, bu birinchi qarashda ko'rinadigan darajada oson emas. Foydalanuvchilar ko'pincha oxirida nima olishlari haqida tasavvurga ega emaslar. Ushbu jarayonni osonlashtirish uchun tahlilchilar ish diagrammalaridan foydalanadilar (2-rasm)

shakl 2. Use Case diagrammasiga misol

Diagramma - bu tizim bilan o'zaro aloqada bo'lgan aktyorlarning (aktantlarning) aksi va dasturiy ta'minot ob'ektlarining ularning harakatlariga reaktsiyasi. Aktyorlar ham foydalanuvchi, ham ma'lumot uzatishi yoki qabul qilishi kerak bo'lgan tashqi agent bo'lishi mumkin. Case case belgisi tizimning tashqi stimulga ta'sirini aks ettiradi va aktant uchun nima qilish kerakligini ko'rsatadi.

Muayyan foydalanish holatlarini batafsil bayon qilish uchun Faoliyat diagrammasi qo'llaniladi, uning namunasi 3-rasmda keltirilgan.

anjir. 3 Faoliyat diagrammasi

Ish sxemasining soddaligi tahlilchilarga talablarni aniqlash jarayonida xaridorlar bilan osonlikcha aloqa o'rnatishga, tizimga qo'yiladigan cheklovlarni va tizimning javob vaqti, keyinchalik funktsional bo'lmagan talablar bo'limiga tushadigan individual talablarni bajarilishini aniqlashga imkon beradi.

Shuningdek, foydalanish holatlari diagrammasi sinov stsenariylarini yaratish uchun ishlatilishi mumkin, chunki foydalanuvchi tizimining barcha o'zaro ta'siri allaqachon aniqlangan.

Talablarni to'g'ri belgilash uchun ishlab chiquvchilar kelajakdagi tizim ishlaydigan kontekstni (domenning bir qismini) tushunishlari kerak. Buning uchun bitta masalaga turlicha yondoshadigan domen modeli va biznes modeli yaratiladi. Ko'pincha, bitta narsa yaratiladi: domen modeli yoki biznes modeli.

Ushbu modellarning farqi shundaki, domen modeli tizim ishlaydigan muhim tushunchalarni va ularning o'zaro munosabatlarini tavsiflaydi. Holbuki, biznes modeli tizim qo'llab-quvvatlashi kerak bo'lgan biznes jarayonlarini (mavjud yoki kelajakda) tavsiflaydi. Shuning uchun, ushbu model jarayonga jalb qilingan biznes ob'ektlarini belgilashdan tashqari, xodimlarni, ularning vazifalarini va bajarishi kerak bo'lgan harakatlarni belgilaydi.

Domen modelini yaratish uchun odatiy sinf diagrammasi ishlatiladi (6-rasm), ammo bu biznes modelini yaratish uchun etarli emasligi aniq. Bunday holda, biznes-jarayonlar mohiyatini aks ettiruvchi qo'shimcha belgilar bilan biznes-diagramma ishlatiladi - biznes aktant, biznesdan foydalanish holati, biznes sub'ekti va biznesni boshqarish. Ushbu model rivojlanish jarayonida yaratilgan keyingi modelga - tahlil modeliga ancha yaqin.

2. Tahlil

Tizim ishlaydigan talablar va kontekstni aniqlagandan so'ng, olingan ma'lumotlarni tahlil qilish vaqti keldi. Tahlil davomida ishlab chiquvchilarni arxitekturaga olib boradigan analitik model yaratiladi kelajakdagi tizim... Analitik model bu tizimning tashqi tomondan qanday ko'rinishini ko'rsatadigan case case modelidan farqli o'laroq, tizimga ichkaridan qarashdir.

Ushbu model tizimni qanday ishlab chiqish kerakligini, unda qanday sinflar bo'lishi kerakligini va ular bir-biri bilan qanday aloqada bo'lishlarini tushunishga imkon beradi. Uning asosiy maqsadi talablarni yig'ish bosqichida aniqlangan funksionallikni amalga oshirish yo'nalishini aniqlash va tizim arxitekturasining eskizini yaratishdir.

Keyinchalik yaratiladigan dizayn modelidan farqli o'laroq, tahlil modeli ko'proq kontseptual model bo'lib, faqat ishlab chiquvchilarni amalga oshirish sinflariga yaqinlashtiradi. Ushbu model case case modelida yuzaga kelishi mumkin bo'lgan qarama-qarshiliklarga ega bo'lmasligi kerak.

UML-dan foydalangan holda tahlil modelini namoyish qilish uchun "chegara sinfi", "shaxs", "boshqaruv" stereotiplari (xatti-harakatlar uslublari) bilan sinf diagrammasi va batafsil ma'lumot uchun hamkorlik diagrammalari (Hamkorlik) ishlatiladi (4-rasm). "Chegaraviy sinf" stereotipi tashqi aktantlar bilan o'zaro aloqada bo'lgan sinfni, "shaxs" - ma'lumotlar saqlanadigan sinflarni va "menejment" - sub'ektlarga so'rovlarni boshqaradigan sinflarni namoyish etadi.

shakl 4. Hamkorlik diagrammasiga misol

Xabarlarni raqamlash ularning tartibini bildiradi, lekin diagrammaning maqsadi xabarlar almashinish tartibiga qarash emas, balki sinflarning bir-biriga munosabatini tasavvur qilishdir.

Agar biz o'zaro ta'sir tartibiga e'tibor qaratadigan bo'lsak, unda uning yana bir vakili 5-rasmda ko'rsatilgan ketma-ketlik diagrammasi (Tartib) bo'ladi. Ushbu diagramma vaqt o'tishi bilan xabarlar almashinuvini ko'rib chiqishga, jarayon ketma-ketligini vizual ravishda namoyish etishga imkon beradi. Rational Rose kabi modellarni yaratish vositasidan foydalanganda ushbu ikki turdagi diagrammalar bir-biridan avtomatik ravishda yaratilishi mumkin (Rational Rose haqida ko'proq ma'lumot olish uchun, masalan, o'qishingiz mumkin).

Shakl: 5 ketma-ketlik namunasi

Ikkala diagrammadan qaysi birini birinchi yaratish kerakligi shaxsiy ishlab chiquvchining afzalligiga bog'liq. Ushbu diagrammalar bir xil jarayonning vakili bo'lganligi sababli, ularning ikkalasi ham ob'ektlar o'rtasidagi o'zaro ta'sirni aks ettirishga imkon beradi.

3. Dizayn

Tizimni yaratish jarayonining keyingi bosqichi dizayn bo'ladi, uning davomida ilgari yaratilgan modellar asosida dizayn modeli yaratiladi. Ushbu model tizimning jismoniy amalga oshirilishini aks ettiradi va sinflar va komponentlar darajasida yaratilayotgan mahsulotni tavsiflaydi. Tahlil modelidan farqli o'laroq, dizayn modeli amalga oshirish shartlari, ishlatilgan dasturlash tillari va tarkibiy qismlariga aniq bog'liqdir. Tizim arxitekturasini aniqroq tushunish uchun ushbu model iloji boricha rasmiylashtirilishi va yangilanib turishi kerak. hayot sikli tizimni rivojlantirish.

Dizayn modelini yaratish uchun UML diagrammalarining butun to'plamidan foydalaniladi: sinf diagrammasi (5-rasm), hamkorlik diagrammasi, o'zaro ta'sir diagrammasi va faoliyat diagrammasi.

6-rasm. Sinf diagrammasiga misol

Bundan tashqari, ushbu ish oqimi tarqatish diagrammasi asosida tarqatish modelini yaratishi mumkin. Bu tarmoqdagi qurilmalarning taqsimlanishini simulyatsiya qilish uchun eng oddiy diagramma turi. Ko'rsatish uchun protsessor va qurilma piktogrammalarining faqat ikkita versiyasi va ular orasidagi bog'lanishlar qo'llaniladi.

4. Amalga oshirish

Amalga oshirish jarayonining asosiy vazifasi - komponentlar ko'rinishidagi tizimni yaratish - dasturlarning manba kodlari, skriptlar, ikkilik fayllar, bajariladigan modullar va boshqalar. Ushbu bosqichda loyihalash modelining elementlari qanday amalga oshirilishini, qaysi sinflar aniq tarkibiy qismlarga kiritilishini tavsiflovchi amalga oshirish modeli yaratiladi. Ushbu model tanlangan dasturlash muhitida qabul qilingan tuzilish va modullarga bo'linish mexanizmlariga mos ravishda ushbu tarkibiy qismlarni tashkil etish usulini tavsiflaydi va komponent diagrammasi bilan ifodalanadi (7-rasm).

anjir. 7 Misol komponentlar diagrammasi

5. Sinov

Sinov jarayoni amalga oshirish natijalarini tekshiradi. Ushbu jarayon uchun test sinovlari, test protseduralari, test tarkibiy qismlaridan tashkil topgan, lekin UML diagrammasi xaritasiga ega bo'lmagan test modeli yaratiladi, shuning uchun biz bu haqda to'xtamaymiz.

6. Xulosa

Bu erda faqat Ratsional metodologiyaning asosiy jarayonlari muhokama qilingan. RUP juda keng va turli xil qit'alarda minglab odamlarni birlashtirgan tarqatiladigan dasturiy ta'minot loyihalariga qadar bir necha kishidan iborat dasturchilar dasturini yaratishdan tortib turli xil dasturiy ta'minot loyihalarini boshqarish bo'yicha ko'rsatmalar beradi. Biroq, ularning ulkan farqiga qaramay, UML bilan yaratilgan modellarni qo'llash usullari bir xil bo'ladi. Rivojlanishning turli bosqichlarida yaratilgan UML diagrammalarini dasturiy ta'minot loyihasining qolgan artefaktlari bilan ajratib bo'lmaydi va ko'pincha individual RUP jarayonlari o'rtasidagi bog'lanish hisoblanadi.

Muayyan diagrammalardan foydalanish to'g'risidagi qaror kompaniyaning rivojlanish jarayoniga bog'liq bo'lib, u birlashtirilgan deb nomlansa ham, muzlatilgan narsa emas. Ratsional nafaqat uni takomillashtirish va takomillashtirishni taklif qiladi, balki RUP ma'lumotlar bazasiga o'zgartirishlar kiritish uchun maxsus vositalarni taqdim etadi.

Ammo har qanday holatda ham UML-dan foydalanish birlashtirilgan jarayon bilan birgalikda bashorat qilinadigan natijani olish, ajratilgan byudjetni saqlash, loyiha ishtirokchilarining rentabelligini va yaratilgan dasturiy mahsulot sifatini oshirishga imkon beradi.

Kraxten. F. Kirish Ratsional birlashtirilgan jarayon . Ed. 2 - e. - M.: "Uilyams" nashriyoti, 2002. - 240 p.: Kasal.

Yakobson A., Booch G., Rambeau J. Birlashgan dasturiy ta'minotni ishlab chiqish jarayoni - Sankt-Peterburg: Piter, 2002. - 496 p.: Kasal.

Fowler M., Scott K. UML qisqacha. Ob'ektni modellashtirishning standart tilini qo'llash: Per. ingliz tilidan - M.: Mir, 1999. - 191 p., Ill.

Bek. E. Ekstremal dasturlash. - SPb.: Piter, 2002. - 224 p.: Kasal.

Trofimov S. CASE-texnologiyalari: Rational Rose-dagi amaliy ish.
Ed. 2 - M.: Binom-Press, 2002 - 288 p.

GOST 34.601-90 “AS. Yaratilish bosqichlari "AISni yaratishning quyidagi bosqichlari belgilanadi, ularni o'z navbatida bosqichlarga bo'lish mumkin:

· AISga qo'yiladigan talablarni shakllantirish;

· AIS kontseptsiyasini ishlab chiqish;

· Texnik topshiriq;

· Dastlabki loyihalash;

· Texnik loyiha;

· Ishchi hujjatlar;

· Foydalanishga topshirish.

Har bir bosqichda o'ziga xos dizayn hujjatlari to'plami va tizimning texnik va dasturiy ta'minot modullari amalga oshiriladi. Amaliyot shuni ko'rsatadiki, tizimni yaratish jarayoni iterativ va bosqichma-bosqich bo'ladi. UML mualliflari kontseptsiyani belgilab, buni ta'kidlaydilar dasturiy ta'minot va axborotni qo'llab-quvvatlashning yagona jarayoni ... Birinchi bosqichda umuman AUga qo'yiladigan talablar to'plami shakllangan bo'lsa-da, aslida u har doim boshida to'liq emas va keyingi bosqichlarda takomillashtiriladi. Bajarish kerak takrorlash, ya'ni alohida bosqichlarni va bosqichlarni to'liq yoki qisman takrorlash. Bundan tashqari, haqiqiy tizim ko'p funktsiyali va murakkabdir; shuning uchun u odatda quyi tizimlarga va vazifalarning alohida komplekslariga bo'linadi, ulardagi birinchi tizim, ikkinchisi va boshqalarning quyi tizimlari va vazifalarini ta'kidlaydi. Tizim yaratilmoqda bosqichma-bosqich, foydalanuvchilarning talablarini yanada puxta va yaxshiroq qondirish uchun dastlabki dizayn echimlarini almashtirish bilan funktsionallikni bosqichma-bosqich oshirish. Bu moliyaviy xavflarni kamaytiradi va yaratilishning so'nggi bosqichlarida vaqt va resurslarni tejaydi.

AIS uchun dasturiy ta'minot va axborot ta'minotini yaratish uchun UML metodologiyasidan foydalanilganda kelajak tizimining statik va dinamik xususiyatlarini aks ettiruvchi o'zaro bog'liq modellar to'plamini yaratish taklif etiladi:

· Case modelidan foydalaning;

· Tahlil modeli;

· Dizayn modeli;

· Joylashtirish modeli;

· Amalga oshirish modeli;

· Sinov modeli.