Жобалаудың микропроцессi: анықтама, мысалдар.
Жобаның улкендігіне қарамай аптасына бір рет өңдеушілерді жинап жумыстың орындалуы мен келесі аптаға жоспар түзу туралы жиналыс өткізу керек. Обьектіге бағытталған өңдеу, өңдеушілерге ойлануға уақыты болуымен сонмен қатар жаңартулар енгізуін қадағалайды.
Өткізіліп жатқан кездесулер қарапайым бірақ жобалаудың микропроцессінің тиімді мүмкіндігін және қауіпті жағдайларды көрсетеді. Бұндай кездесулердің шешімі кішкене жұмысты қарау болуы мүмкін, процесстің тиімді жүріп жатқанын қадағалау, ешқандай жоба өңдеушілердің қол қусырып, басқа жұмысшыларды күтіп отыруына жол бермейді. Бұл әсіресе обьектіге бағытталған жүйе үшін дұрыс. Жоба құрып кетуі де мүмкін, егер өңдеуші кілттік класстарды басқара алмаса.
Шектен тыс оптимистік жобалауға берілмеудің жолы- өңдеудің құралдары мен команданы " калибрлеу ". Қарапайым жобалаудың тапсырмалары келесідей болады. Алдымен менеджер өңдеушілердің күшін жүйенің спецификалық бөлігіне бағыттайды, мысалы реляциялық дерек қормен интерфейс үшін классты жобалау. Өңдеуші қажетті жағдайларды сүзгіден өткізеді және орындалу уақытын бағалайды, сондай-ақ менеджер жобалаудағы басқа әрекеттерін қадағалайды. Көбінесе бағалау шын болмайды, олар негізінен ең қолайлы уақытта болады. Бір өңдеуші бір аптада тапсырмаларды шешуге келісуі мүмкін, ал басқасы осы тарсырмаға бір ай сұрайды. Жұмыс шынымен аяқталғада екі өңдеушініңде үш апта уақыты кетуі мүмкін: бірінші өңдеуші тапсырманың қиындығын бағаламаған (көп программистерде болатын қателік), ал екінші өңдеуші тапсырманың қиындығын дәл бағалаған ( ол кәдімгідей уақытпен жұмыс уақытының айырмашылығын білген). Осындай жолмен ұжым сенім артуы мүмкін менеджерлерге өзінің "еселіктерді калибрлеу" мәлімдеген уақыттың сарапшылығын өңдеушілер қайта есептеу үшін қажет. Бұл менеджерлер өңдеушілерге сенбиді деген сөз емес, бірақ көп программистер жобалаудың тапсырмалары емес, техникалық мәселелерді шешуге негізделген. Менеджер өңдеушілерге қалай жобалау керек екенін үйретуі қажет.
Обьекттіге бағытталған өңдеу процесі айқынды калибрлеудің негізгі ұстанымдарын анықтауға көмектеседі. Итеративті дамудың әдісі жобаның басында менеджерлер әр өңдеушілердің жұмыс кестесін анықтауы және кезедесулерді жобалауы керек. Эволюциялық өңдеу кезінде ұжым мүшелері уақыт өте келе әр өңдеушінің шынайы талабын жақсырақ түсіне бастайды, ал өңдеушілер жұмыстың күрделілігін нақтырақ бағалай бастайды.
Жобалаудың макропроцессi: анықтама, мысалдар.
Жобалаудың макропрцесс нәтижесінің кестесінің құрылысымен тікелей байланысты.Кезекті релиздердің арасындағы уақытта команданың менеджерлері " егер қиындыққа сендер шабуыл жасамасандар, қиындық сендерге жасайды " деп қиындықты бағалау керек, пайда болған кедергілерге рұхсат беру және ары қарай микропроцесстің жаңа қадамымен жұмыс жасау, нәтижесінде жоспарды қанағаттандыратындай тұрақты жүйе алу керек. Жобалаудың осы деңгейі оптимистік кестелердің кесірінен көбінесе сәтсіз болып келеді. Жай программалық сұрақ деп қарастырылған өңдеу ұзақ уақытқа созылып кетеді, өңдеуші жүйенің бір бөлігімен айналысып жатканда, басқа бөлігі қалып қояды да, сосын дұрыс емес немесе түгел емес дайындалған класс алады. Ойламаған жерден пайда болған қателіктер мен программаның берілген уақытта орындалмауы ең қауіпті болып табылады. Алдыңғы қабылданған тактикалық шешімдерді құрбан ете отырып, бұларға төтеп беру.
Шектен тыс оптимистік жобалауға берілмеудің жолы- өңдеудің құралдары мен команданы " калибрлеу ". Қарапайым жобалаудың тапсырмалары келесідей болады. Алдымен менеджер өңдеушілердің күшін жүйенің спецификалық бөлігіне бағыттайды, мысалы реляциялық дерек қормен интерфейс үшін классты жобалау. Өңдеуші қажетті жағдайларды сүзгіден өткізеді және орындалу уақытын бағалайды, сондай-ақ менеджер жобалаудағы басқа әрекеттерін қадағалайды. Көбінесе бағалау шын болмайды, олар негізінен ең қолайлы уақытта болады. Бір өңдеуші бір аптада тапсырмаларды шешуге келісуі мүмкін, ал басқасы осы тарсырмаға бір ай сұрайды. Жұмыс шынымен аяқталғада екі өңдеушініңде үш апта уақыты кетуі мүмкін: бірінші өңдеуші тапсырманың қиындығын бағаламаған (көп программистерде болатын қателік), ал екінші өңдеуші тапсырманың қиындығын дәл бағалаған ( ол кәдімгідей уақытпен жұмыс уақытының айырмашылығын білген). Осындай жолмен ұжым сенім артуы мүмкін менеджерлерге өзінің "еселіктерді калибрлеу" мәлімдеген уақыттың сарапшылығын өңдеушілер қайта есептеу үшін қажет. Бұл менеджерлер өңдеушілерге сенбиді деген сөз емес, бірақ көп программистер жобалаудың тапсырмалары емес, техникалық мәселелерді шешуге негізделген. Менеджер өңдеушілерге қалай жобалау керек екенін үйретуі қажет.
Обьекттіге бағытталған өңдеу процесі айқынды калибрлеудің негізгі ұстанымдарын анықтауға көмектеседі. Итеративті дамудың әдісі жобаның басында менеджерлер әр өңдеушілердің жұмыс кестесін анықтауы және кезедесулерді жобалауы керек. Эволюциялық өңдеу кезінде ұжым мүшелері уақыт өте келе әр өңдеушінің шынайы талабын жақсырақ түсіне бастайды, ал өңдеушілер жұмыстың күрделілігін нақтырақ бағалай бастайды.
