Мои Конспекты
Главная | Обратная связь

...

Автомобили
Астрономия
Биология
География
Дом и сад
Другие языки
Другое
Информатика
История
Культура
Литература
Логика
Математика
Медицина
Металлургия
Механика
Образование
Охрана труда
Педагогика
Политика
Право
Психология
Религия
Риторика
Социология
Спорт
Строительство
Технология
Туризм
Физика
Философия
Финансы
Химия
Черчение
Экология
Экономика
Электроника

Модель пошаговой разработки





Помощь в ✍️ написании работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

В каскадной модели создания ПО определение требований осуществляется совместно с заказчиком до начала проектирования системы, точно так же системная архитектура должна быть создана до начала непосредственной реализации (кодирования) системы. Изменения в требованиях, сделанные на этапе написания кода, ведут к необходимости выполнения по­вторных работ по проектированию и кодированию системы. Вместе с тем к достоинствам каскадной модели можно отнести простоту управления процессом создания ПО (в рамках данной модели), а также наличие отдельных этапов проектирования и реализации, что при­водит к созданию вполне работоспособных систем, в которых учтены все изменения в спе­цификации, сделанные уже во время самого процесса разработки ПО. В отличие от каскад­ной, в эволюционной модели можно отложить принятие окончательных решений о специ­фикации и структуре системы, однако это может привести к созданию плохо структурирован­ной системы, которая будет также трудна в сопровождении.

Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель (рис. 3.6) была предложена Миллсом (Mills, [240]) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увели­чить для заказчика временной период окончательного принятия решения обо всех дета­лях системных требований.

Незавершенная система Рис. 3.6. Модель пошаговой разработки

В процессе пошаговой разработки заказчик сначала в общих чертах определяет те сер­висы (функциональные возможности), которые должны присутствовать у создаваемой системы. При этом устанавливаются приоритеты, т.е. определяется, какие сервисы более важны, а какие — менее. Также определяется количество шагов разработки, причем на ка­ждом шаге должен быть получен системный компонент, реализующий определенное под­множество системных функций. Распределение реализации системных сервисов по шагам разработки зависит от их приоритетов. Сервисы с более высокими приоритетами реали­зуются первыми.

Последовательность шагов разработки определяется заранее до начала их выполне­ния. На первых шагах детализируются требования для сервисов, затем для их реализации (на последующих шагах) используется один из подходящих способов разработки ПО. В ходе их реализации анализируются и детализируются требования для компонентов, кото­рые будут разрабатываться на более поздних шагах, причем изменение требований для тех компонентов, которые уже находятся в процессе разработки, не допускается.

После завершения шага разработки получаем программный компонент, который пе­редается заказчику для интегрирования в подсистему, реализующую определенный сис­темный сервис. Заказчик может экспериментировать с готовыми подсистемами и компо­нентами для того, чтобы уточнить требования, предъявляемые к следующим версиям уже готовых компонентов или к компонентам, разрабатываемым на последующих шагах. По завершении очередного шага разработки полученный компонент интегрируется с ранее произведенными компонентами; таким образом, после каждого шага разработки система приобретает все большую функциональную завершенность. Общесистемные функции в этом процессе могут реализоваться сразу или постепенно, по мере разработки необходи­мых компонентов.

В описываемой модели не предполагается, что на каждом шаге используется один и тот же подход к процессу разработки компонентов. Если создаваемый компонент имеет хо­рошо разработанную спецификацию, то для его создания можно применить каскадную модель. Если же требования определены нечетко, можно использовать эволюционную модель разработки.

Процесс пошаговой разработки имеет целый ряд достоинств.

Заказчику нет необходимости ждать полного завершения разработки системы, чтобы получить о ней представление. Компоненты, полученные на первых шагах разработки, удовлетворяют наиболее критическим требованиям (так как имеют наибольший приоритет) и их можно оценить на самой ранней стадии создания системы.

Заказчик может использовать компоненты, полученные на первых шагах разработки, как прототипы и провести с ними эксперименты для уточнения требований к тем компонентам, которые будут разрабатываться позднее.

Данный подход уменьшает риск общесистемных ошибок. Хотя в разработке от дельных компонентов возможны ошибки, но эти компоненты должны пройти соответствующее тестирование и аттестацию, прежде чем их передадут заказчику.

Поскольку системные сервисы с высоким приоритетом разрабатываются первыми, а все последующие компоненты интегрируются с ними, неизбежно получается так, что наиболее важные подсистемы подвергаются более тщательному всестороннему тестированию и проверке. Это значительно снижает вероятность программных ошибок в особо важных частях системы.

Вместе с тем при реализации пошаговой разработки могут возникнуть определен­ные проблемы. Компоненты, получаемые на каждом шаге разработки, имеют относи­тельно небольшой размер (обычно не более 20 000 строк кода), но должны реализовать какую-либо системную функцию. Отобразить множество системных требований к ком­понентам нужного размера довольно сложно. Более того, многие системы должны об­ладать набором базовых системных свойств, которые реализуются совместно различ­ными частями системы. Поскольку требования детально не определены до тех пор, по­ка не будут разработаны все компоненты, бывает весьма сложно распределить общесистемные функции по компонентам.

В настоящее время предложен метод так называемого экстремального программиро­вания (extreme programming), который устраняет некоторые недостатки метода пошаго­вой разработки. Этот метод основан на пошаговой разработке малых программных ком­понентов, реализующих небольшие функциональные требования, постоянном вовлече­нии заказчика в процесс разработки и обезличенном программировании (см. главу 23). В статье [31] описан метод экстремального программирования и приведено несколько от­четов о его успешном применении, однако подобные отчеты можно привести для всех ос­новных методов разработки ПО.

 

Доверь свою работу ✍️ кандидату наук!
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой



Поиск по сайту:







©2015-2020 mykonspekts.ru Все права принадлежат авторам размещенных материалов.