И. Соммервилл - Инженерия программного обеспечения (1133538), страница 15
Текст из файла (страница 15)
Вместе с тем этот метод должен получ<ггь пи<рок<к распространенно в ХХ1 столетии, поскольку сборка систем из готовых или ранее использованных компопе< ггов значительно ускоряет разработку ПО. Эта модель рассматривается в главе 14. 3.1.1. Каскадная модель Это первая модель процесса создапил ПО, порождеппзл моделями других пил<спорных процессов [300). Опэ показана на рнс. 3.1.
Эту модель также иногда пазывшот м<щелью жпз. ненного цикла программного обеспечения' . Основныс прннциппэльныс этапы (стадпн) этой модели отражают все базовые виды делтельн ости, необходимые для создания ПО. Ж«юмиммый Яики м)ю<)тмммыи ай<<мимы<ми - вто <м<оиумми<вм м)юзы<ои, м)мтымиючмм и ми)м<мд «т мм мимва «дммивми <мчим<в и <тдаммм ПО ди и<и ма<ма<о мы<ада ми имсмизмващм<. 7аммм ма)<мимы.
".и<мим< ммый Бб Часть 1. Инженерия программного обеспечения: обзор 1. Лыализ и форчи)ювлнкл тргбэвлнкгь Путем консультаций с заказчиком ПО определя. ются функциональные воэможности, ограничения и цели создаваемой программной системы. 2. Проьктирэвлннг сигэюмы к программ«его обгсиечгнин. Процесс проектирования системы разбивает системные требования на требования, предъявляемые к аппаратным средствам, и требования к программному обеспечению системы. Разрабатывается общал архитектура системы. Проектирование ПО предполагает определение и описание основных программных компонентов и их взаимосвязей. 3.
Кодггрелтшг и ггюсяыгролаяиг лрогргммньммойулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каллдого модуля включает проверку его соответствия требованиям к данному модулю. 4. Сбэр«п и кмсти~ивпыкг сиолгмы. Отдельные программы и программные модули интегрируютсл и тсстируютсл в виде целостной системы. Проверяется, соответствует ли система своей спецификации. 5. Э«гллултлцил к сопровождение системы. Обычно (хотя и пе всегда) это самая длительная фаза жизненного цикла ПО. Система инсталлируется, и начинается период ее эксплуатации.
Сопровождение системы включает исправленглс ошибок, которые нс были обнаружены на более ранних этапах жизненного цикла, совершенствование системных компонентов и "подгонку" функциональных возможностей системы к новым требованиям. Рис. 3. П Жилюныый цикл нРаг)«глькного об«сил«гнил б принципе результат каждого этапа должен утверждаться документально (это как бы сигнал об окончании этапа). Тогда следующий этап ие может начаться до завершения пре. льнущего.
Однако на практике этапы ьго~уг перекрываться с постоянным перетеканием информации от одного этапа к другому. Например, на этапе проектирования может возникнуть необходимость уточнить системные требоазн ил либо на этапе кодирования могут выявиться проблемы, которые можно решить лишь на этапе проектирования, и тд. Процесс создания ч««л пО*'лвлагтгл йыгг ~и«)ю«им «ь«лт«гм, «гм мтулль я)ючеггл газдлния пО. В«кто с тлч «лг«пд«ую мьдмь мож«ь )ьпга«лт)ьиглльь «л«одну «глод««юг жилин«ого цьь«ла ПО.
— Прни. Ред. 3. Процесс создания программного обеспечения 57 ПО нельзя описать простой линейной моделью, так как ои неизбежно содержит послсдова. тельность повторлющихся процессов. Поскольку на каждом этапе проводятся определенные работы и оформляется сопутствующая документация, повторение этапов приводит к повторным работам н значительным расходам. Поэтому после небольшого числа повторений обычно "замораживаетсл" часть этапов создания ПО, например этап определения требований, но продолжается выполнение последующих этапов. Возникающие проблемы, решение которых требует возврата к "замороженным" этапам, игнорируются либо делаются попытки решить их программно.
"Замораживание" этапа определения требований может привести к тому, что разработанная система не будет удовлетворять всем требованиям заказчика Это также может привести к появлению плохо структурированной системы, если упущения этапа проектирования исправляются только с помощью проьраммистских хитростей. Последний этап жизненного цикла ПО (эксплуатация и сопровождение) — зто "полноценное" использование программной системы. На этом этапе могут обнаружиться ошибки, допущенные, например, на первом этапе формирования требований.
Могут также проявиться ошибки проектироваььия и кодирования, что может потребовать определения новых функциональных возможностей системы. С другой стороны, система постоянно должна оставаться работоспособной. Внесение пеобходимьлх изменений в программную систему может потребовать повторения некоторых или даже всех этапов процесса создания ПО. К недостаткам каскадной модели можно отнести негибкое разбиение процесса создания ПО иа отдельные фиксированные этапы. В этой модели определяющие систему решения принимаются на ранних этапах и затем их трудно отменить или изменить, особенно это относится к формированию системных требований.
Поэтому каскадная модель применяется тогда, когда требования формализованы достаточно четко и корректно. Вместе с тем каскадная модель хорошо отражает практику создания ПО. Технологии создания ПО, основанные на данной модели, используются повсеместно, в частности для разработки систем, входящих в состав больших инженерных проелтов. 3.1.2.
Эволюционная модель разработки Эта модель основана на следующей идее: разрабатываетсл первоначэлььшл версия программного продукта, которая передается на испытание пользователям, затем она дорабатывается с учетом мнения пользователей, получается промежуточная версия продукта, которал также проходит "испытание пользователем", снова дорабатывается и так несколько раз, пока не будет получен необходимый программный продукт (рис. 3.2).
Отличительной чертой ланной модели является то, что процессы специфицирования, разработки и аггсстации ПО выполнаютсл параллельно при постоянном обмене информацией между ними. Различают два подхода к реализации эволюционного метода разработки. 1. Подход лрайемлралуиьбаееиьк Здесь большую роль играет постолпная работа с заказчиком (или пользовкь елями) длл того, чтобы определить полную систему требование! к ПО, необходимую для разработки конечной версии продукта.
В рамках этого подхола вна. чало разрабатываются тс части системы, которые очевидны или хорошо специфицированы. Система эволюционирует (дорабатывается) путем добавления новых средств по мере их предложения заказчиком. 2. П)еататили)йеюанис Здесь целью процесса эволюционной разработки ПО явллется поэтапное уточнение требований заказчика и, следовательно, получение законченной спецификации, определлювгей разрабатываемую систему. Прототипа обычно строится для экспериментирования с той частью требований заказчика, которые сформированы нечетко или с внутренними противоречиями.
Пед еь(ююаюинаи айкчиа иаиилииикл да!еюлуюяий тфафаммимй модуль, )ьеалюуюяийь аюдюьиме фуии. Кии еаЫаеалмаю ПО. -Прню. Рел. 5В Частя 1. Инженерия программного обеспечения! обзор Парзанльяыз процзссы гоие, 3. 2, Эвол юпионипя лодел ь )газ)ггиготхи Более подробно подходы к эволюционной разработке рассматриваются в главе 8. где описаны различные технологии прототипирования систем.
Эволюционный подход часто более эффективен, чем подход, построенный на основе каскадной ьюдсли, особенно если требования заказчика мог)т меняться в процсссс разработки снстсмы. Достоинством процесса создания ПО, построенного на основс эволюционного подхода, является то, что здесь спецификация может разрабатываться постспснно, по мере того как заказчик (или пользователи) осознает и сформулирует тс задачи, которые должно решать программное обсспсчспис.
Вместе с тсм данный подход имеет и пскоторыс нсдостатки. 1. Многие этапы а(гопееса еогдпиия ПО ие дохумеитировпиы Менеджерам проекта создания ПО необходимо регулярно документально отслеживать выполпсинс работ. Но соли система разрабатывается быстро, то экономически нс выгодно документировать каждую версию систсмы. 2. Сипиелга часто получпетея плохо пгфукогу!ги)гаванной. Посгояпныс изменения в требованиях приводят к ошибкам и упущениям в струк!)рс ПО.
Со временем внесение изменений в систему становится все более сложным и затратным. 3. Чппло требуютгл сяевиплъиьм федспмп и оихиологии )Згм)тдотки ПО. Это вызвано необходимостью быстрой разработки всрсий программного продукта. Но, с другой сто. роны, это может привести к несовместимости некоторых применяемых средств и технологий, что, в свою очередь, требует наличия в команде разработчиков специалистов высокого уровня. Я думаю, что эволюционный подход наиболее присмлсм для разработки небольших програмлгпых систем (до 100 000 строк кола) и систем среднего размера (до 500 000 строк кода) с относительно коротким сроком жизни.
На больших долгоживущих системах слишком замстпо проявляются недостатки этого подхода. Для таких систем я рекомендую смс. шаниый подход к созданию ПО, который вобрал бы в себя лучшие черты каскадной и эволюционной молслсй разработки. При таком смешанном подхода для прояснения "темных мест" в системной спецификации можно использовать прототипирование. Часть системных компонентов, лля которых полностью определены требования. может создаваться на основе каскадной модели. Другие спстсмиыс компоненты, которые трудно поддаются специфицированию, например пользовательский иптсрфсйс, могут разрабатываться с использованном прототипирования.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
