Бағдарламаларды әзірлеудің құрал-саймандары пәнінен дәрістер


Дәрістік сабақ конспектілері

Тақырып 1. Пән - стандарттары және өңдеу процессі. (4 сағат)

Дәріс №1. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС даму тарихы. (2 сағ)

Түсініктемелерді анықтау: программа, деңгейлері және категориялары (бағыттары) программалау, программаны өңдеу және аспаптары. Аспаптар, ол жұмысты орындау үшін арналған құралдар, яғни программаны өңдеу және тарату екі топқа бөлінеді аппараттық және программалық. Аппараттық - микропроцессорлар және қосылатын (сыртқы) құрылғылар. Программалық - олар жобалау методологиясымен анықталған, барлық жұмыстарды орындауға мүмкіндік беретін программалар. Беріліп отырған пән негізінен, компьютерге программаларды орнату және өңдеу үшін қолданылатын программалық аспаптық құралдарды оқып үйренуге арналған. Программалық өнімді (ПӨ) өңдеу көптеген бір-бірімен байланысқан әрекеттерден тұрады, олар:

- деректер моделін құру және есептеу әдістемесі;

- есептеуді қамтамасыздандыратын, функциональдық сипаттамасы;

- деректер құрылымын анықтау - компьютерде және алгоритмде көрсетілу моделі;

- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу алгоритмі) ;

- пайдаланушы интерфейсін сипаттау және анықтау;

- ПӨ қолдау құралдарын анықтау;

- есеп спецификациясы;

- тестілеу программасын қоса отырып, программа текстін жазу;

- программаның тестіленуі, трансляциясы және жөнделуі;

- қолдау кітапханаларын қосу және байланыстыру;

- орындау ортасын құру; орындамалық модулді орналастыру және жүктеу;

- орнатылған көмекті құру және өңдеуді құжаттау;

- орнатылатын (инсталляциялық) ПӨ пакетін құру.

Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған әрекеттер жиыны келесі этаптардан тұрады: - талаптарды анықтау; - жобалау; - программалау; - тестілеу; -ендіру.

Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі өңделіп және толықтырылып отырады - ол аспаптар, программаның өңделу процессін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.

Компьютер үшін программа - бұл программалау тілінде құрылған немесе жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін және тиімді, жылдам, сапалы, экономды жобалау мақсатында таңдалады.

Тіл деңгейі - программалау деңгейі. Тіл деңгейі - программалау деңгейі. Төменгідеңгейлі программалау - бұл микропроцессор деректер форматын және командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын программалау. Проблемалы - бағытталған программалау (текстуальды) - бұл деректер форматын және командаларын проблемалы - бағытталған тілдерде программалау. Визуальды программалау - бұл деректер форматын және командаларын программаларды өңдеудің визуальды құралдары арқылы программалау. Обьектілік немесе компоненттік программалау әртүрлі конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.

Командалық (атомарлы), құрылымдық, модульдік программалау - категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ, программалаудың бағытын анықтайды - ғылыми түрде, бизнес есептерін шешу үшін, обьектілер мен процесстерді басқару үшін, ақпараттарды көрсету және басқару үшін, Интернет пен қарым - қатынас жасау үшін, деректер қорымен қарым - қатынас жасау үшін және т. б. қолданылады.

Құрылымдық программалау концепциясы.

«Құрылымдық программалау - программалау методологиясы, жүйелік түрдегі талдауға негізделген, ПҚ тарату және жобалау. 70 - жылдардың басында пайда болды және соншалықты өміршең, сондықтан да осы күнге дейін пайдаланылады. Бұл технологияның негізі келесі тәртіптерден тұрады:

  • Қиын есептер кішірек бөліктерге бөлінеді, функциональды түрде негізінен басқарылатын есептер дұрыс. Әрбір есептің бір кірісі және бір шығысы болады. Бұл жағдайда программа ағымы көптеген есептер тобынан және түсінікті функционалдық тағайындамасынан құралады.
  • Есепте қолданылатын, басқарылатын құрылымның қарапайымдылығы және атомарлығы. Бұл, логикалық есеп минималды, функционалды толық қалыптасқан қарапайым басқарылатын құрылымнан тұруы керек екендігін көрсетеді.
  • Программаның өңделуі этап бойынша орындалады. Әрбір этапта шектелген есеп саны, нақты қойылған тапсырмасымен және есеп барысындағы оның атқаратын мәнімен, түсінікті қойылымы шешілуі керек. Егер ондай шамаға жетпесе, онда ол бұл этап өте үлкен және оны тағы басқа қадамдарға бөлу керек екендігін білдіреді.

Модулдік программалау концепциясы.

Құрылымдық технология сияқты мұнда да, модулдік программалау концепциясын бірнеше түсініктемелер және тәртіптер түрінде қалыптастыруға болады:

  • Есептің функциональдық декомпозициясы - үлкен есепті кіші есептерге бөлу, олар функциональды өзбектінше орындалатын ішкіесептер - модулдер. Модулдер өзара кіріс және шығыс деректерімен байланысқан.
  • Модуль - модулдік программалау концепциясының негізі. Әрбір модульдің функциональдық декомпозициясы бір кірісі және бір шығысы бар "қара жәшік" ретінде қаралады. Модульдік көзқарас программаның модернизациясын процесстің эксплуатациясы кезінде ешбір қатерсіз орындауға мүмкіндік береді және оны қолдап отырады. Қосымша модулдік программалау бір жобаның программасының әртүрлі бөліктерін әртүрлі программалау тілдерінде орындауға мүмкіндік береді, одан кейін компоновкалау құралдары арқылы оларды бір жүктемелеу модуліне біріктіреді.
  • Таратылатын шешімдер қарапйым және түсінікті болуы керек. Егер модульдің атқаратын қызметі түсініксіз болса, онда бастапқы немесе аралық декомпозиция есептері дұрыс, керек еткен дейгейде, сапалы жүрмегендігін білдіреді. Бұл жағдайда есепті қайта талдау керек, мүмкін, қайта бөлулер жасау, яғни ішкіесептерге бөлу жұмыстарын орындау керек болады. Жобада қиын орындалатын орындар кездессе, онда оларды жүйемен ойластырылған комментарилер арқылы құжаттау керек. Бұл процесс модулдердің жұмысының толық түсінікті, қызметтері анықталған және байланыстырылғанға дейін қайталана береді.
  • Модулдің барлық айнымалыларның қызметі комментерилердің көмегімен анықталуы және жазылуы керек.

Объектілі-бағыттылған парадигма.

ОБП идеясы негізінен осы деректерді өңдейтін процедураларды бір бүтін - обьектіге байланыстыру үшін жасалған. ОБП маңызды үш принцип негізінде құрылған, олар обьектілерге жаңа қасиеттер береді. Бұл принциптар ретінде инкапсуляция, мұрагерлену және полиморфизм алынады.

  • Инкапсуляция- Осы деректерді өңдеу алгоритмдері мен деректерді бір бүтінге біріктіру. ОБП деректері көлемінде - объект полесі, алгоритмдері - объектілік әдістер алынады. Полелер мен алгоритмдер іштен қолданылады, - жалпы, сырттан немесе тек обьект ішінде - соған тәуелді, ішкілер немесе байланысқан обьектілер - қорғалған.
  • Мұрагерлену- обьектілер қасиеті өздерінің мұрагерлерін туындайды және оларға өздерінің қасиеттерін үнсіздікпен ұсынады. Объект - мұрагерленуші, ол қасиеттерді толықтыра алады немесе басқамен оны ауыстыра (орынбастыра) алады.
  • Полиморфизм- туыстық обьектілердің қасиеттері (яғни бір объектіден тараған бір түбірі бар обьектілер) негізінен бір - біріне ұқсас, мәні жағынан бірдей проблемаларды әртүрлі әдістермен, оның уақытына және орналасу ретіне байланысты шешу.

Программаны өңдеу үшін алынған аспап таңдалған деңгей негізімен, бағытымен, өңдеу категориясымен анықталады және текстуальды немесе визуальды түрде беріледі. Қазіргі заманғы программалау - компоненттік (объектілік), уақиғалық және визуальды болып алынады. Түсініктемені анықтайтын болсақ.

Программаны өңдеу мемлекеттік және шетелдік стандартқа сәйкес, өңдеуші ұсынған технологиялар мен әдістемелер немесе типтік программалар арқылы орындалады.

Аспаптық құралдардың классификациясы. Өңдеу процессі және таратылуының орны бойынша, уақытша принципі бойынша, қолданылатын технологиялары мен әдістемесі бойынша, продукт сапасы бойынша және т. б.

Пән мақсаты мен міндеттері. Силлабуста берілген.

Программаны өңдеу процедурасындағы аспаптық құралдардың орны мен атқаратын қызметі . Әрбір программаны өңдеу этабының өз аспаптар жиыны бар. Силлабуста барлық өңдеу қадамдары көрсетілген. Әрбір қадам өңдеу нәтижесімен анықталады - негізгі құжат болып, және қосымша құжат болып, этапты жабу алынады. Аспап, сәйкесінше, негізгі немесе қосымша болады.

Сапа мінездемесі және аспапты қолдану. Жазықтықтағы, уақытша, тұрақты, берік, қазіргі заманғы, интуитивті түсініктер, визуальды, статикалық және динамикалық, өңдеуді түзету және өзгертуді қамтамасыздандыру, нәтижеге байланысты, сәйкес стандарттар мен технологиялар, мақсатың орындалуымен және т. б.

Аспаптық құралдардың дамуына қысқаша түсініктеме. Этаптар 1960 - 1975 - 1985 - 2000 жылдар. Тілдер, компиляторлар, компоновщиктер, құрастырушылар, жүктемелегіштер, операциялық жүйелер, өңдеу құралдары және тестілеу, енгізу құралдары және программаны қолдау. Соңғы 20 жыл ішіндегі программалау тілдерінің даму схемасы.

Бақылау сұрақтары:

  1. Программа дегеніміз не?
  2. Аспап дегеніміз не?
  3. Программалаудың деңгейлері мен категорияларын атаңыз?

Дәріс №2. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын анықтау. RUP. (2 сағ)

Жобалау әдістер және программаның өміршендік циклын қамтамасыздандыру. Командалық және жеке жобалау және оған керекті аспаптар. Текстуальды және визуальды жобалау - технологиялары және әдістемесі, қолданатын аспаптары. Визуалды модельдеу дегеніміз не? Визуальды модельдеу (vіsual modelіng) - нақты өмірдің объектілері мен ұғымдарын көрсететін және өзі көрініс табатын абстракциялардың көмегімен проблемаларды қабылдау әдісі. Модельдеу проблемаларын талдау, барлық қызығушылығы бар жақтар арасында ақпараттардың алмасуы (қолданушылар, пәндік аумақтағы мамандар, аналитиктер, дизайнерлер және т. б. ), программалық қолданбалар мен мәліметтер базасын жобалау, және документацияны дайындау үшін пайдалы құрал болып табылады. Модельдеу талаптарын жақсы қабылдауға, жүйенің дизайн сапасын жақсартуға және оны басқару деңгейін жоғарылатуға өз септігін тигізеді. UML - объекті бағдарланған жүйелермен құрастырылатын мәндердің документациясын белгілеу мен көріністендіру үшін қолданылатын тіл.

Модельдің көмегімен біз керегі жоқ детальдарды қарастырмай-ақ бар назарымызды негізгіге аудара отырып, проблеманы оңайлатуымыз мүмкін. Абстракциялау мүмкіндігі - күрделік феноменін шешуге көмектесетін, адам интеллектісінің іргелі қасиеті. Мыңдаған жылдар барысында суретшілер, қол өнершілер және құрылысшылар нақты шығармашлық ойларды жүзеге асыру алдында түрлі модельдерді жобалау талпыныстарын жасаған. Бұл құбылыстар программалық қамтаманы жасау индустриясын айналып өткен жоқ. Күрделі программалық жүйені құрастыру үшін, автор оның қасиеттерін түрлі көзқарастар тарапынан абстракциялауға, белгілеулердің нақты жүйелерінің көмегімен модельдерді жобалауға, олардың бастапқы талаптарға сәйкестігін тексеріп алуға міндетті, тек содан кейін ғана жүйені жаңа функциялармен толықтыра отырып, модельді практикада жүзеге асыруға болады.

12207 стандарты - Программалық жүйенің өміршендік циклының процесстері (ПЖ ӨЦ) . Есептерді, жұмыстарды, процесстерді анықтайды. Кімге тағайындалғанын зерттейді. Нақты адаптация және шектеулер. Нормативті сілтемелер. Анықтамалар. Стандарттың қолданбалы қолдану - 5 негізгі, 8 қосымша, 4 ұйымдастыру процесстері. Өңдеу программасы - талаптардың талдануы, жобалау, программалау, жинау, тестілеу, орындау үшін енгізу, қабылдау. Этап бойынша жұмыстар тізімі. Этап бойынша жұмыстар мазмұны. Аспаптары.

Қазіріг заманғы аспаптық құралдар. Барлық өңдеу этаптарын визуализациялау. Визуальды технологиялар негізі. Өңдеу ортасы, обьектілер, компоненттер кітапханасы. Аспаптар дайындау фирмаларының талдануы. Талданудың интерфейстік құрамы. Интерфейс стандарттары. Қазіргі заманғы визуальды аспатардың құрамы. Программаларды өңдеу аспаптарының құрамын жобалаудың бірлік ұстанымдары және олардың әртүрлілігі.

RUP технологиясы, олардың өңдеу құжаттары және фазалары, аспаптары.

Rational Unified Process «Бүгінгі күнде ол ең көп кездесетін әдістемелердің бірі. Ол Rational Software копаниясымен өз өнімдерін қолдау үшін шығарылған, олар оннан көп деп есептелінеді (ең көп кездесетін өнімдеріне - Rational Rose және Requisite Proжатады) . RUP үш атақты адамдармен құрылған - бұлар Гради Буч, Ивар Якобсон және Джеймс Рамбо (Rumbaugh) . Олардың барлығы қиын программалық қамтаманы өндеуде үлкен жетістіктерге жеткен адамдар, оны RUP бейнесінен - ақ көруге болады. RUP Итеративтігі , қазіргі заманғы дамыған кез - келген процесс сияқты, ол да итеративті болып табылады. Бұл яғни, құрылатын жоба бірнеше итерациямен орындалатындығын көрсетеді. Әрбір итерация аяғында жұмыс жасайтын өнім версиясын алуға мүмкіндіктер бар, бірақ олардың функционалдығы толық емес. Одан кейін орындалатын итерацияларда функционалдылық толықтырылып отырады да, соңында дайын өнім ала аламыз. Итеративті өнім идеясынның процессін келесі түрде көрсетуге болады (сурет 1, қара) .

:
: Сурет. 1. Спиральдің әрбір бөлігі - итерация. Яғни жүйе функционалдығы біртіндеп өсіп отырады.

Итеративті өңдеудің артықшылықтары көп. Релиздердің көп бөлігі өнім сапасына ықпалын тигізеді, олар әрбір итерация сайын тестіленіп отырады. Яғни бастапқы тексерулер жүргізілгеннен кейін-ақ пайдаланушы күткен өнімді алуға мүмкіндіктер бар және өзгертулерді сол кезде енгізуге болады, егер ол қажет болса. Сонымен - қатар, жобаны жоспарлау да оңай, өйткені бірінші итерациядан кейін ақ ол түсінікті болады, және жобаны басқарушы келесі итерацияның аяқталу уақытын да алдын - ала жоспарлауға мүмкіндігі болады. Айта кететін жағдай, RUP-та процесстің итеративтілігін қатесіз жасауға болатындығы айтылмаған. Сондықтан RUP - ты бірінен кейін бірі орындалатын процесс үшін де қолдануға болады, яғни ондағы орындалу қадамдары бірінен-кейін-бірі орындалады, және дайын өнім соңында алынады. Соныдқтан RUP орнатқанда оның итеративтігіне және қатесіз орындалуына көңіл бөліп дұрыс ендіру керек. Пайдаланушы сценариі. Пайдаланушы сценариі (Use Case) - бұл белгілі бір операцияны орындау кезіндегі пайдаланушының әрекеттер тізбегінің сипаттамасы. Мысалы, жаңа құжат ашу үшін пайдаланушы сценариін жазуға болады және т. б. RUP пайдаланушы сценарилерімен басқарылады (немесе прецеденттер) . Пайдланушы сценарилері өңдеушілерге жүйе не жасауы және қалай жасауы керек екаедігін нақты айтып отыру мүмкіндік береді. Пайдланушы сценарилері жүйенің функционалдық спецификациясының бөлігі болып табылады. Негізінен мұндай сценарилер программаны өңдеу кезінде тигізетін пайдасы көп, өйткені олар:

тапсырыс бершіге және жалпыға түсінікті тіл болып табылады да тапсырыс беруші мен өңдеуші екеуін байланыстырушы бөлім болып табылады; программа жұмысының логикасындағы қателерді бастапқы жұмыс барысында табуға көмектеседі; тапсырыс берушінің программаға деген талаптарын нақты табуға көмектеседі; текстілік сценарилерді жазу үшін интерфейс өңдеушінің базасы болып табылады. RUP-тағы пайдланушы сценарилеріне ерекше орын берілген, ол процесс use-case driven деп аталады, яғни пайдланушының басқарушы сценарилері. RUP құрылымы Процесстің төрт фазасы бар:1. Зерттеу (Inception) 2. Жоспарды нақтылау (Elaboration) 3. Құру (Construction) 4. Ашып қарау (Transition) . Әрбір фазадағы негізгі көңіл әртүрлі процесстерге бөлінеді. Зерттеу фазасында талаптарды жинау және талдау жүргізіледі, Жоспарды нақтылау фазасында - жүйені жобалау және талаптарды талдау, құру фазасында - өңдеу және кодтау, ашып қарау фазасында - тестілеу және тарату. RUP әдістемесі негізгі 9 ағынға негізделіп жасалады: 1) Бизнес-талдау (керектіктің талдануы) ; 2) Талаптарды жинау және талаптарды басқару (талаптарды функционалдық спецификацияға ауыстыру) ; 3) Талдау және моделдеу (талаптарды программалық моделге ауыстыру) ; 4) Кодтау; 5) Тестілеу (программаның берілген талаптарға сәйкестігін тексеру) ; 6) Өзгертулерді және конфигурациясын басқару (өнімнің әртүрлі версияларындағы өзгерулерін тексеру) ; 7) Жобаны басқару ; 8) Өңдеу ортасын ұстану және құру; 9) Ашып қарау (өнімді беру немесе сату үшін керектінің барлығы) . RUP - тағы кез -келген өнім төрт фазадан өтеді. Осы фазалар арқылы барлық тоғыз ағын да өтеді. Әрбір фаза, өз кезегінде, итерацияларға бөлінеді. Егер, мысалға алатын болсақ, "Зерттеу" фазасындағы бірініші итерация болса, онда бұл итерациядағы негізгі көңіл бизнес-талдауға, талаптарды жинау мен моделдеуге, және кодтауға бөлінеді. Егер "Құру" фазасындағы соңғы бір итерациялардың бірін алтын болсақ, онда негізгі көңіл кодтауға, тестілеуге және конфигурацияны басқаруға бөлінеді. Басқаша айтсақ, жобаның дамуына байланысты әрбір итерациядағы кемшіліктер жойылады. Бұл әрине дұрыс, соңына қарай талдау мүлде керек болмайды, ал талаптарды жинауға кеш болады. Артефакт (Artefact) деп өнімді атаймыз, ол ПҚ өңдеу процессі кезіндеқұрылады және қолданылады. Мысалы, артефакт болып құжаттар, моделдер, орындалатын кодтар алынады. Артефакт мысалдары: пайдаланушы құралы, UML-дағы класстар диаграммасы және т. б. RUP-тың бөлінбейтін бөлігін артефакттар мен олардың атқаратын қызметтері толықтырады. Программаны өңдеу кезінде әртүрлі артефакттар құрылады, сол немесе басқа артефакттардың құрылуына оның атқаратын қызметтері жауапты болады. Мысалы, класстар диаграммасын "Архитектор" құрады, ал сценарилеін және тестіленуін "Тест дизайнерлері" жазады. Барлық визуальды моделдеу CASE-құралдарының көмегімен жүзеге асады. Оның негізін UML тілі құрады (Unified Modeling Language), ол таңқаларлық жағдай емес, өйткені UML RUP авторларымен ойлап табылған дүние.
Ең жақсы практикалар
RUP-тың өзі ең жақсы алты практикаға негізделген (best practices) :

Итеративтік өңдеу Тлаптарды басқаруМодулдік архитектураны қолдану Визуальды моделдеу Сапасын тексеру Өзгертулерді бақылау Олар RUP-тың бөлінбейтін бөлігі болып табылмайды, бірақ оларды процессті құру кезінде ұстанған дұрыс деп есептелінеді.

Итеративтік өңдеу бастапқы стадияларда жұмыс жасайтын дайын өнім версиясын алуға мүмкіндік береді және қателерін табуға болады, сонымен қатар, нәтижесінде арынған өнімнің сапасы да жақсы болады, өйткені база өнімде қанша итерация болса сонша рет тестіленеді.

Талаптарды басқару - ол қиын немесе қиын емес өнімдерді алу кезіндегі маңызды бір процесстердің бірі. Бұған байланысты өнім, тапсырыс берушінің талаптарына сәйкестендіріледі. Аспаптық қастамасыздандыру Requisite Pro - ның көмегімен шешіледі.

Теория жүзінде модульдік құрылым кодты қайта қолдануға болады, және жүйе иілгіш болады деп айтылған. Ал практика жүзінде мұны тарату мүмкін емес.

Визуальдық моделдеу жүйенің өсетін қиындықтарымен тиімді күресуге мүмкіндік береді. Моделдер негізінен, жүйенің не істейтіндігін және қалай істейтіндігін түсіну үшін пайдаланылады. Сонымен қатар, моделдер өңдеушілердің арасындағы коммуникация құралы болып табылады, біріқ ол үшін ол барлығына да түсінікті болу керек. Міне осы үшін RUP-та UML қолданылады, ол өңдеушілерге бір тілде сөйлеуге мүмкіндік береді. Аспаптық қолдау Rational Rose - пен қамтамасыздандырылады.

Өнім сапасы - бұл да оның маңызды мініздемесінің бірі. Айтылғандай, RUP - мүмкіндігінше сапа дейгейіне бағытталға, бірақ адаптация процессінде, егер адаптация сәтті болмаса, онда бұл сапамен байланысты әдістемеде проблемалар тууы мүмкін. Аспаптық ұстанымдар бірнеше программалармен қамтамасыздандырылуы мүмкін олар: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot.

Өзгерулерді бақылап отыру тапсырыс берушінің талаптарының өзгерулеріне және сыртқы құрылғы өзгерістеріне тез жауап беруге мүмкіндік береді. RUP-тың процесстері болады, олар өзгерулерді тиімді бақылауға мүмкіндік береді. Аспаптық ұстанымдар келесі прогрммалармен қамтамасыздандырылуы мүмкін олар: Rational ClearCase және Rational ClearQuest.

RUP қалыптастыру. RUP адаптацияланатын процесс болып табылады, яғни оларды керекті бір команданың немесе керекті бір жобаның пайдалануына байланысты құрауға болады. Сонымен қатар, мұны жасау керек те, өйткені мұнсыз RUP-ты пайдалану тиімділігі нөлге талпынады. RUP 2000-да, мысалы, 30-дан астам ролдер және 50-ден астам артефактар бар. Шындығында, егер команда 5 адамнан тұрса, онда ондағы барлық ролдерді шығару және барлық артефакттарды құру мүмкін емес. Негізі команда неғұрлым аз болса, соғұрлым процесс жеңіл болады. Яғни минимум артефакттар құрып, минимум ролдерді енгізу керек.

Сонымен RUP процессті қалыптастыруға мүмкіндік береді. RUP-тың жалпы сипаттамасынан сапалы өнім шығару үшін және бюджет аймағында болатын, командада қолданылатын керек процесстер, ролдер және артефакттарды алу керек. Мысалы, талаптарды басқаруды алатын болсақ. RUP-тың жалпы сипаттамасында келесі артефакттар бар: талаптарды басқару жоспары, пайдаланушы сценарилерінің моделі, жүйенің талаптарының спецификациясы, көріністер, талаптар репозиториі. Кішкентай жоба үшін талаптар спецификациясы да және жеке сценарилер де жеткілікті. Ал үлкен жоба үшін репозиторий міндетті түрде қажет, өйткені онсыз талаптарды өзгертулер мен оларды бақылау жүйелік аналитиктің жұмысын қиындатады. Бірақ RUP-ты бір нақты жоба үшін қалыптастыру - нетривиальды есеп. Егер ол жұмысты бұрын RUP енгізумен жұмыс жасамаған адам жасаса, онда орындалатын есепті алу мүмкін емес. Негізі, RUP өте қиын әдістеме деп есептелінеді, оны негізінен үлкен командалар үшін қолданған жақсы. RUP-тың жұмысын жеңілдететін бір әдістемелердің бірі бұл dX. Rational Unified Process (RUP) әдістемесі келесі процесстерден тұрады (Workflows) :

... жалғасы

Сіз бұл жұмысты біздің қосымшамыз арқылы толығымен тегін көре аласыз.
Ұқсас жұмыстар
ИНФОРМАТИКАНЫҢ ТЕОРИЯЛЫҚ НЕГІЗДЕРІ ПӘНІНЕН ЭЛЕКТРОНДЫҚ ОҚУ ҚҰРАЛЫН ӘЗІРЛЕУ
Электрондық оқулықтың сипаттамасы
Кәсіпкерлік қызметтің түрлері, тәуекелділік
ЭЛЕКТРОНДЫ КӨМЕКШІ ҚҰРАЛ ЖАСАУ НЕГІЗДЕРІ
Android ОЖ
Информатикада Adobe Photoshop программалық оқыту құралын үйрету технологиясы
Электрондық оқулықтың құрылымы
ЭЛЕКТРОНДЫҚ ОҚУЛЫҚТЫ ҚҰРУ ТЕХНОЛОГИЯСЫ
«Ақпараттық менеджмент және сапалы басқару» пәні бойынша электронды-әдістемелік құралды құрастыру
Delphi Windows жүйесінде программалаудың ыңғайлы құралы
Пәндер



Реферат Курстық жұмыс Диплом Материал Диссертация Практика Презентация Сабақ жоспары Мақал-мәтелдер 1‑10 бет 11‑20 бет 21‑30 бет 31‑60 бет 61+ бет Негізгі Бет саны Қосымша Іздеу Ештеңе табылмады :( Соңғы қаралған жұмыстар Қаралған жұмыстар табылмады Тапсырыс Антиплагиат Қаралған жұмыстар kz