Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Бағдарламалық жасақтаманы әзірлеу тәсілі, онда іске асыруды бастамас бұрын жоба толықтай аяқталып, жетілдіріледі.
A software development approach where the design is perfected before implementation
Алдын ала үлкен жобалау (BDUF) – бағдарламаны іске асыруды бастамас бұрын бағдарламаның жобасы аяқталып, толықтырылуы тиіс бағдарламалық жасақтаманы әзірлеу тәсілі. Ол көбінесе бағдарламалық жасақтаманы әзірлеудің каскадтық моделімен байланысты. Алдын ала үлкен жобалау (BDUF) синонимдері – алдын ала үлкен модельдеу (BMUF) және алдын ала үлкен талаптар (BRUF). Бұлар ынтымақты әзірлеудегі қате тәсілдер ретінде қарастырылады.
Big design up front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development. Synonyms for big design up front (BDUF) are big modeling up front (BMUF) and big requirements up front (BRUF). These are viewed as anti patterns within agile software development.
Қарсы дәлелдер
Сыншылар (әсіресе, жедел бағдарламалық жасақтаманы әзірлеушілер) BDUF өзгеріп отыратын талаптарға нашар бейімделеді және BDUF дизайнерлердің кең ауқымды прототиптеусіз және кемінде іске асыруға инвестиция жасамай-ақ, проблемалық аймақтарды болжай алады деп санайды. Масштабты жобалар үшін пайдаланушылардың талаптары алғашқы нәтижелерге сүйене отырып нақтылануы керек, ал бизнестің қажеттіліктері үлкен жобалар аяқталудан гөрі жылдам өзгеріп, жүйе дайын болған кезде «Үлкен жобалау» ескіріп қалады. Олар сондай-ақ жоспарлауға кеткен уақыт пен ақауды түзетуге қажетті уақыт арасындағы тепе-теңдікті сақтау қажет екенін айтады. Бұл кейде «талдау парализі» деп аталады. Егер жоспарлаудың құны түзету құнынан жоғары болса, онда жоспарлауға жұмсалған уақыт босқа кетеді. Үздіріссіз енгізу, автоматты жаңартулар және осыған байланысты идеялар өндірістегі ақаулардың құнын айтарлықтай төмендетуге тырысады, осылайша оларды бастапқы жоспарлауға қарағанда жұмыс істеу кезінде түзету арзанға түседі. Шындығында, жұмыс істеу кезінде түзетулер жобалау кезінде түзетулерге қарағанда әлдеқайда қымбат, сондықтан даму барысында жиі демонстрациялар мен пайдаланушылардың пікірлері сияқты Жедел әдістерді қолдану арқылы мәселелерді шешу өте маңызды. Пайдаланушылардың пікірлерін пайдаланып бағдарламалық жасақтаманы жақсарту, әдетте, BDUF арқылы жүйенің барлық аспектісін болжауға және құжаттауға тырысудан арзан. Сонымен қатар, көптеген жобаларда толыққанды жазбаша (немесе тіпті жақсы белгілі) талаптар жетіспейді. Сондықтан BDUF-та көптеген болжамдар жасалады, олар кейіннен жалған болып шығады, бірақ олар жобаланып, тіпті кодталған болуы мүмкін.
Critics (notably those who practice agile software development) argue that BDUF is poorly adaptable to changing requirements and that BDUF assumes that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation. For substantial projects, the requirements from users need refinement in light of initial deliverables, and the needs of the business evolve at a pace faster than large projects are completed in making the Big Design outdated by the time the system is completed. They also assert that there is an overhead to be balanced between the time spent planning and the time that fixing a defect would actually cost. This is sometimes termed analysis paralysis. If the cost of planning is greater than the cost of fixing then time spent planning is wasted. Continuous deployment, automatic updates, and related ideas seek to substantially reduce the cost of defects in production so that they become cheaper to fix at run time than to plan out at the beginning. In reality, run time fixes are vastly more costly than design fixes, so it is critical to use Agile methods such as frequent demonstrations and user feedback during development to fix issues during the development cycle. Improving software with the benefit of user feedback is generally less expensive than trying to anticipate and document every aspect of a system with BDUF. Also, in most projects there is a significant lack of comprehensive written (or even well known) requirements. So in BDUF a lot of assumptions are made that later prove to be false but are designed and possibly already coded.