Въведение
Линеен последователен модел на софтуерното инженерство, понякога известен като „традиционен жизнен цикъл“ или „модел на водопад“, линейният последователен модел предлага систематични, последователни методи за разработка на софтуер (въпреки че най-ранният модел на водопад, предложен от Уинстън Ройс [Roy70], поддържа цикъл на обратна връзка, повечето на организациите, които използват модела на процеса, се считат за строго линейни), започвайки от системно ниво, след това анализиране, проектиране, кодиране, тестване и поддръжка.
Моделирайте основното мислене
The core idea of the waterfall model is to simplify the problem according to the process, and the implementation and design of the function will be separated, which is easy to divide and cooperate. Separate logic implementation with physical implementation. The software life cycle is divided into six basic activities such as planning, demand analysis, software design, program writing, software testing and operation maintenance, and specify their own fixed order, such as waterfall, step by step. whereabouts.
Моделът на водопада е най-ранният модел за разработка на софтуер, който играе важна роля в софтуерното инженерство, което осигурява основната рамка за разработка на софтуер. Процесът е да се получи работният обект на събитието като вход от предишната дейност и да се използва този вход за внедряване на съдържанието на събитието, което трябва да бъде завършено, за да се дадат резултатите от работата на събитието и да се предаде на следващата дейност като изход . Същевременно се прави преглед на изпълнението на тази дейност. Ако потвърдите, продължете със следващото събитие; в противен случай върнете събитието отпред, дори повече. Моделът на водопада е безполезен за текущо променящите се елементи.
Системно/информационно инженерство и моделиране
Тъй като софтуерът винаги е голям системен (или бизнес) компонент, трябва да установите нуждите на всички системни компоненти и след това някои подмножества се присвояват на софтуера. Цялата система е базирана на софтуер и други компоненти като хардуер, хора и интерфейси на бази данни. Системното инженерство и анализ включват изискване за събиране на системно ниво, както и малка част от анализ и проектиране на горния слой. Информационните проекти включват търсене на стратегически бизнес клас и бизнес сектори.
Анализ на търсенето на софтуер
Процесът на събиране на искания е особено централизиран към софтуера. За да разбере същността на програмата, софтуерният инженер („Аналитик“) трябва да разбере информацията за софтуера и функционалността, поведението, производителността и интерфейса на търсенето. Системните изисквания и софтуерните изисквания подлежат на документиране и преглед с потребителите.
Дизайн: Дизайнът на софтуера всъщност е многоетапен процес, фокусиращ се върху четирите напълно различни свойства на програмата: структура на данните, софтуерна архитектура, представяне на интерфейса и подробности за процеса (алгоритъма). Процесът на проектиране преобразува търсенето в софтуерно представяне и качеството му може да бъде оценено преди кодиране. Подобно на търсенето, дизайнът също е документация и е част от софтуерната конфигурация.
генериране на код: Дизайнът трябва да бъде преобразуван в машинно четима форма. Тази стъпка е за изпълнение на тази задача. Ако дизайнът е изразен в детайли, генерирането на код може да се извърши автоматично.
Тест: След като се генерира код, можете да започнете тестване на програмата. Процесът на тестване се фокусира върху вътрешната логика на софтуера - гарантира, че всички изявления са тествани, както и външни функции - тоест, стартиране на теста за откриване на грешки и гарантиране, че дефинираният вход може да произведе същия изход, както се очаква.
Поддръжка: Софтуерът неизбежно иска да се промени след доставката (възможно изключение е вграденият софтуер). Промени ще настъпят в следните случаи: Когато възникне грешка; когато софтуерът трябва да се адаптира към промените във външната среда (например поради новата операционна система или периферни устройства); или когато потребителят иска да подобри функцията или производителността. Софтуерната поддръжка повтаря предишните фази, разликите в нея са за съществуващи процедури, а не за нови програми.
Последователността и зависимостта между линейния последователен модел
1) Последователността и зависимостта между етапа, проектът се изпълнява в определен ред от началото до края; моделът на водопада се ръководи от документи, всеки етап не е интерситивен.
2) Строгата оценка на фазата трябва първо да извърши стриктна оценка, за да влезе в следващия етап.
3) Първоначалният период на развитие трябва да бъде ясно посочен.
4) Дълъг цикъл на развитие, риск.
Недостатъци на линейния последователен модел
1) Повечето от действителните проекти са трудни за изпълнение в реда, даден в този модел, а този модел е итеративен, което е лесно. Това причинява голям хаос от малки промени.
2) В много случаи клиентът е трудно да изрази реално търсене и този модел е задължителен, този модел не е "добре дошъл", за да има проблем с erliness.
3) Клиентът иска да изчака до края на цикъла на разработка, може да види тестовата версия на програмата, работеща и когато откриете голяма грешка, това може да предизвика паника у клиента и последствията от резултата може да са катастрофални . на.
4) често се сблъсква със задачата, чакаща други членове да завършат своята зависимост от началото и края на процеса, възможно е да прекарате дълго време от времето за разработка. Да "блокира държавата".
Предимства на линейния последователен модел
1) Предоставя шаблон, който прави методите за анализ, дизайн, кодиране, тестване и поддръжка могат да имат общо в този шаблон. ръководство.
2) Въпреки че има много дефекти, това е много по-добре от представянето на произволно състояние в разработката на софтуер.