Майлингова О.Л., Манжелей С.Г., Соловская Л.Б. - Прототипирование программ на языке Scheme (1108536), страница 2
Текст из файла (страница 2)
1. Водопадная модель процесса разработкиВодопадная модель предполагает «фазированную» разработкупрограммного продукта. При этом определение требований выполняетсядо начала разработки системы (еще до проектирования), а проектирование(определение взаимодействия компонент системы) происходит до началакодирования. Все фазы разработки тщательно документируются, адокументация используется для тестирования и сопровождения системы.Таким образом, снижается стоимость разработки и сопровождения.Водопадную модель принято считать классической моделью разработки,но и она не является идеальной.
На практике не всегда возможно четкоразграничить фазы процесса разработки. Как правило, стоимостьпрограммного обеспечения превышает запланированную, системаизготавливается позже, чем требуется, к тому же не всегда надежно и всоответствии с потребности пользователей.Анализ моделей разработкиДля анализа различных моделей разработки за основу возьмем тот факт,что требования пользователя постоянно изменяются. Таким образом,разрабатываемая система должна стремиться к достижению постояннодвижущейся цели.Рис.
2. Изменениетребований к системе вовремениРис. 3. Функциональные возможностисистемы (приближение к требованиям) вовремени при использовании водопадноймодели разработкиПредставим рост требований пользователя прямой (Рис. 2). На осяхпреднамеренно не указан масштаб и единицы измерения, так как росттребований не является линейной и непрерывной во времени функцией.На Рис. 3 представлено, что происходит при традиционной разработкесистемы. В момент времени to возникает потребность в программномобеспечении и начинается его разработка при относительно неполномпонимании потребностей заказчика.
В момент времени t1 усилияразработчиков приводят к появлению работоспособной версии системы,которая не только не удовлетворяет потребностей времени t1, но она неудовлетворяет потребностей времени to, так как разработка началась доуточнения требований. Далее система совершенствуется (между t1 и t3), иудовлетворяет начальным требованиям (t2) и некоторым новым. В точкевремени t3 стоимость дальнейшего усовершенствования системы стольвелика, что принимается решение разработать новую систему (опять наосновании неточно понятых требований), ее разработка завершена вмомент времени U и цикл повторяется.Развитием (модификацией) водопадной модели стали модели,использующие прототипирование, повторное использование компонент иавтоматическую генерацию кода по спецификациям.Модели, использующие прототипированиеПод прототипированием понимается разработка некоторогопредварительного варианта системы с целью исследования некоторыхсвойств этой системы.
Часто основной целью создания прототипа являетсяполучение информации от пользователя о том, как по его представлениюсистема должна работать. На основе этой информации могут бытьизменены спецификации требований к системе, что способствуетувеличению гарантий правильности работы окончательного вариантасистемы.
Создание прототипа может также служить целям исследованиянекоторых проблемных задач, альтернативных решений, принятых припроектировании или реализации системы. Назначением прототипа обычноявляется получение требуемой информации как можно быстрее и сминимальными издержками, поэтому чаще всего при его созданиивнимание сосредоточивается на некоторых сторонах создаваемой системыпри полном игнорировании остальных сторон. Например, можносовершенно не обращать внимания на эффективность и рабочиехарактеристики системы и полностью отвлечься от некоторых функцийсистемы. Что же касается исследуемых с помощью прототипированияаспектов поведения системы, то тут созданный прототип должен бытьсовершенно реальным.
Таким образом, прототипирование может снижатьстоимость разработки за счет частичных реализаций системы.Концепция прототипирования открыла возможность для участияпользователей в процессе разработки системы, прежде всего, при анализетребований и спецификации системы. Основной проблемой начальных фазразработки системы является то, что пользователю по текстовомуописанию спецификации сложно представить реальное функционированиесистемы. Также сложно бывает понять, являются ли спецификацииполными и непротиворечивыми.
Более того, опыт показал, что ошибки,допущенные при анализе требований, обнаруживаются в последнююочередь, на этапе тестирования, и поэтому их исправление самое дорогое.Для решения этих проблем используются различные подходы,разрабатываются языки спецификаций, графические средства и ихкомбинации.
Но они больше помогают разработчику, чем пользователю.Быстрое прототипированиеПрототипирование на этапе спецификации требований решает некоторыепроблемы взаимопонимания пользователей и разработчиков. Имеяпрототип, пользователь может испытать систему. Если не разрабатыватьпрототип, то прототипом становится первая версия системы. Она будетзаменена другой, в которой будут исправлены ошибки первой.Рис. 4. Быстрое прототипированиеДля того чтобы прототип был эффективным инструментом, он долженудовлетворять следующим условиям:• прототип системы должен быть работающей системой, котораяпомогает понять, изучить, пересмотреть спецификацию требований;• прототип должен быть дешевле самой системы (не более 10%стоимости);• прототип должен быть разработан быстро (до утвержденияспецификации системы, так как цена ошибки растет со временем еепоявления).Использование быстрого прототипирования приводит к следующеймодели процесса разработки (Рис.
4).1. Предварительный анализ и спецификация требований.2. Разработка и реализация прототипа.3. Испытание прототипа.4. Итеративное уточнение прототипа.5. .Уточнение спецификации.6. Разработка и реализация окончательного варианта системы.Предварительный анализ и спецификация требований состоит изразработки спецификации, которая, по мнению разработчика,удовлетворяет требованиям заказчика.При разработке и реализации прототипа основное внимание уделяетсябыстроте реализации и минимизации стоимости. Это достигается за счетреализации, прежде всего пользовательского интерфейса, для того, чтобыпользователь получил представление о системе, тогда как эффективностьреализации функциональных возможностей пока не имеет значения.Прототип может быть реализован небольшим коллективом разработчиков.Язык реализации прототипа выбирается таким, чтобы на нем было удобнобыстро программировать. Например, для этой цели подходятинтерпретируемые языки, так как их использование ускоряет процесссборки и обнаружения ошибок.
Как правило, выбираются языки, имеющиевстроенные средства работы со сложными структурами данных. Также дляреализации прототипа выбирают инструментальную систему, в которойесть инструменты, способствующие быстрой реализации действующейсистемы. Существенным преимуществом является возможностьповторного использования компонент.Изучение прототипа. Каждый из пользователей может самостоятельноработать с прототипом и выражать свои замечания.
Для этого нужно вграфике разработки выделить время. Необходима обратная связь - учетзамечаний пользователей. Как правило, больше пользователей принимаетучастие в изучении прототипа, чем в изучении спецификации.Документация, требуемая для изучения прототипа не столь объемна, какдокументация системы.Итеративное уточнение прототипа. Желательно как можно быстреереагировать на замечания пользователя и модифицировать прототип. Иснова его отдавать для изучения пользователю. Итеративное уточнение иэксперименты с прототипом продолжаются в зависимости от стоимости,времени и замечаний.
Пока цена уточнения не достигнет предела.Уточнение спецификаций. На этапе уточнения прототипа уточняютсятребования пользователя, спецификации требований совершенствуются всоответствии с замечаниями пользователя и становятся базисом длядальнейшей разработки и реализации системы.Разработка, кодирование и тестирование системы происходят всоответствии со стандартной моделью процесса разработки. Основноевнимание при производстве основной системы уделяется, прежде всего,методам структурной разработки, структурного программирования,систематического тестирования и созданию полной документации.
Такимобразом, основное внимание направлено на обеспечение сопровождениясистемы.Инкрементное прототипированиеРассмотрим другой подход, при котором прототип составляет ядроразрабатываемой системы. При этом подходе сначала реализуется ядросистемы, ее основные функциональные возможности, а затем системапостепенно наращивается.Рис. 5. Инкрементное прототипированиеПреимуществом инкрементного прототипирования является приятныйдля разработчиков момент, что система уже функционирует.Наращиваемые версии системы могут быть использованы в качествепрототипа для тестирования основной части системы, пользовательскогоинтерфейса, или для тестирования ключевых алгоритмов.
Работающаячасть системы может быть использована для получения замечанийпользователя.Модель разработки с использованием инкрементного прототипирования(Рис. 5) включает следующие этапы.1. Анализ требований и спецификация.2. Разработка архитектуры - разбиение на модули и определениемежмодульных интерфейсов.3. Инкрементная реализация модулей. Детальная разработка каждогомодуля, который предполагается включить в систему. Кодирование итестирование модулей.4. Инкрементная интеграция модулей в систему. Тестированиевозникающих подсистем.5. Повторение шагов 3 и 4 для каждого приращения системы. В некоторыхслучаях происходит уточнение архитектуры.
Также могут уточнятьсяспецификации требований.6. Тестирование системы с точки зрения соответствия функциональнойспецификации.7. Прием в эксплуатацию - тестирование пользователями.После того, как разработана архитектура системы, детальнопроектируются все модули. Так как межмодульный интерфейс определенна этапе разработки архитектуры, каждый из модулей можетпроектироваться независимо.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
