Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Жобаны кезеңдік кезеңдерде модельдеу
Modelling a project in sequential phases
Суарна модельдемесі – даму қызметтерін сызықтық, кезеңдік бөліктерге бөлу, яғни олар бір-біріне тікелей жүзеге асырылады, мұндағы әрбір кезең алдыңғы кезеңнің нәтижелеріне тәуелді және міндеттердің мамандануына сәйкес келеді. Бұл әдіс итеративті және икемді әдістердің арасында ең азы болып саналады, себебі прогресс көбінесе бір бағытта ("суарна сияқты төменге") тұжырымдама, бастама, талдау, жобалау, құрылыс, сынақ, енгізу және техникалық қолдау кезеңдері арқылы жүзеге асырылады. Суарна модельдемесі – бағдарламалық жасақтаманы дамытуда қолданылған ең алғашқы SDLC әдісі. Суарна даму модельдемесі өндіріс және құрылыс салаларында пайда болды, онда жоғары құрылымдалған физикалық ортада жобалау өзгерістері даму процесінің басында-ақ тым қымбатқа түсетіні анықталды. Бағдарламалық жасақтаманы дамыту үшін алғаш рет қабылданған кезде, білімге негізделген шығармашылық жұмыстар үшін танылған баламалар болған жоқ.
The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development. The waterfall development model originated in the manufacturing and construction industries, where the highly structured physical environments meant that design changes became prohibitively expensive much sooner in the development process. When first adopted for software development, there were no recognized alternatives for knowledge based creative work.
Тарих
Бағдарламалық жасақтауда осындай фазаларды пайдалануды сипаттайтын алғашқы таныстырылымды Герберт Д. Бенингтон 1956 жылғы 29 маусымда Цифрлық компьютерлер үшін озық бағдарламалау әдістері туралы симпозиумда өткізді. Бұл презентация SAGE бағдарламалық жасақтамасын әзірлеу туралы болды. 1983 жылы мақала Бенингтонның алғы сөзімен қайта жарияланды, онда фазалар тапсырмалардың мамандануына сәйкес ұйымдастырылғаны және процесс шын мәнінде жоғарыдан төменге қатаң түрде орындалмағаны, бірақ прототипке байланысты екендігі түсіндірілді. Алайда, ол тек процесстің соңында ғана сынақ жүргізілгендіктен, оның "қауіпті және сәтсіздікке алып келуі мүмкін" деп сипаттаған үлкен кемшіліктері бар деп ойлады. "Шарлауық" терминін ең ертерек 1976 жылы Белл мен Тейердің мақаласында қолданған болуы мүмкін. 1985 жылы АҚШ Қорғаныс министрлігі бағдарламалық қамтамасыз етуді әзірлеуші мердігерлермен жұмыс істеу үшін DOD STD 2167 стандартында шарлауық үлгіні қабылдады. Бұл стандарт бағдарламалық жасақтаманы әзірлеудің қайталануларын "бағдарламалық жасақтаманы әзірлеу циклының тізбектелген фазалары" деп атады және мердігер "келесі алты фазаны қамтитын бағдарламалық жасақтаманы әзірлеу циклын іске асыруға тиіс: Бағдарламалық талаптарды талдау, Алдын ала жобалау, Егжей-тегжейлі жобалау, Кодтау және Бөлімдік сынау, Интеграция және Сынау" деп мәлімдеді.
The first known presentation describing use of such phases in software engineering was held by Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956. This presentation was about the development of software for SAGE. In 1983 the paper was republished with a foreword by Benington explaining that the phases were on purpose organized according to the specialization of tasks, and pointing out that the process was not in fact performed in a strict top down fashion, but depended on a prototype. However, he also felt it had major flaws stemming from the fact that testing only happened at the end of the process, which he described as being "risky and invites failure". The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer. In 1985, the United States Department of Defense adopted the waterfall model in the DOD STD 2167 standard for working with software development contractors. This standard referred for iterations of a software development to "the sequential phases of a software development cycle" and stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".
Сын
Клиенттер жұмыс істейтін бағдарламалық жасақтаманы көрмей, өздерінің нақты талаптарын білмей қалуы мүмкін, соның салдарынан талаптарын өзгертеді, бұл қайта жобалауға, қайта әзірлеуге және қайта сынауға, сондай-ақ шығындардың өсуіне алып келеді. Дизайнерлер жаңа бағдарламалық өнім немесе мүмкіндікті жобалау кезінде болашақта туындауы мүмкін қиындықтарды болжастыра алмайды. Мұндай жағдайда, жаңадан ашылған шектеулерді, талаптарды немесе проблемаларды ескермейтін дизайнды жалғастырудың орнына, оны қайта қараған дұрыс. Ұйымдар клиенттерден нақты талаптардың жетіспеушілігін жою үшін жүйелік талдаушыларды қолданыстағы қолмен жүзеге асырылатын жүйелерді зерттеуге және олардың қызметін талдап, оларды қалай алмастыруға болатынын анықтауға тартады. Бірақ тәжірибеде жүйелік талдау мен бағдарламалауды қатаң түрде бөліп қарастыру қиын. Өйткені, кез келген күрделі жүйені іске асыру барысында жүйелік талдаушы ескермеген мәселелер мен ерекше жағдайлар сөзсіз анықталады. Таза "шарлауық" үлгісімен байланысты туындаған проблемаларға жауап ретінде "Сашими (үстіңгі жағынан жабатын кезеңдері бар шарлауық), кіші жобалары бар шарлауық және тәуекелді азайту шарлауық" сияқты өзгертілген шарлауық үлгілері енгізілді.
Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs. Designers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems. Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between systems analysis and programming. This is because implementing any non trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider. In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction."