И. Соммервилл - Инженерия программного обеспечения (1133538), страница 44
Текст из файла (страница 44)
Прототип создаегся, оценивается и модифицируется. Данные оценивапия прототипа используются для дальнейшей детализации спецификации. Когда системные требования сформированы, прототип больше не нужен. Существует различие между целями эволюционного и экспериментального прототипирования. ° Целью эволюционного прототипирования является поставка работающей системы конечномт пользователю. Это означает. что необходимо начать создание системы, 8.
Прототипирование программных систем 173 реализующей требования пользователя, которые наиболее понятны и которые имеют наивысший приоритет. Требования с более низким приоритетом и нечеткие требования реализуются по запросам пользователей. ° Целью экспериментального прототипирования является проверка н формирование системных требований. Здесь сначала создается прототип, реализующий те требования, которые сформулированы нечетко и с которыми необходимо "разобраться". Требования, которые сформулированы четко и понятно, не нуждшотся в прототипировании.
Другое важное различие между этими подходами касаетгл управления качеством разрабатываемой системы. Экспериментальные прототипы имеют очень короткий срок жизни. Они быстро меняются и для них высокая эксплуатационная надежность не требуется. Для экспериментального прототипа допускается пониженная эффективность и безотказность, поскольку прототип должен выполнить только свою основную функцию — по. мочь в понимании требований. В противоположность этому прототипы, которые эволюционируют в законченную систему, должны быть разработаны с такими же стандартами качества, что и любое другое программное обеспечение. Они должны иметь устойчивую структуру и высокую эксплуа.
тационную надежность. Они должны быть безотказны, эффективны и отвечать соответствующим стандартам. 8.1.1. Эволюционное прототипирование В основе эволюционного прототипирования лежит идея разработки первоначальной версии системы, демонстрации ее пользователям и последующей модификации вплоть до получения системы, отвечающей всем требованиям (рис. 8.8). Такой подход сначала использовался для разработки систем, которые трудно или невозможно специфицировать (например, систем искусственного интеллекта). В настоящее время он становится основной методикой при разработке программных систем.
Эволюционное прототипирование имеет много общего с методами быстрой разработки приложений и часто входит в эти методы как их составная часть (238, 348, 327, бь). Рис. 8З. Эвагювионкое пратепилкроелние Этот метод прототипирования имеет два основных преимущества. 1. Ускорение)км)ьабюжк сисэмнм. Как указывалось во введении, современные темпы из. менений в деловой сфере требуют быстрых изменений программного обеспечения.
В некоторых случалх быстрая поставка ПО, удобство и простота его использования 174 х1асть 11. Требования более важны, чем полный спектр функциональных возможностей системы или долгосрочные возможности ее сопровождения. 2. Взакмодекоззеке яааьзоеомеея с еистемого Участие пользователей в процессе разработ. ки означает, что в системе более полно будут учтены пользовательские требования. Между отдельнымн методами быстрой разработки ПО существуют различия, но все они имеют некоторые общие свойства. 1. Этапы разработки технических требований, проектирования и реазизации перемежаются. Не существует детальной системной спецификации, проектная документация обычно зависит от инструментальных средств, используемых для реализации системы.
Пользовательские требования определяют только наиболее важные характеристики системы. 2. Система разрабатывается пошагово. Конечные пользователи и др)тне лица, формирующие требования, участвуют на каждом зпаге проектирования и оценивания новой версии системы. Они могуг предлагать изменения и новые требования, которые будут реализованы в следующей версии системы. Я. Применение методов быстрой разработки систем (см.
раздел 8.2). Оии могут использовать инструментальные САЯЕ. средства и языки четвертого поколения. 4. Пользовательский интерфейс системы обычно создается с использованием интерактивных систем разработки (см. раздел 8.3), которые позволяют быстро спроектировать и создать интерфейс. Эволюционное прототипирование н методы, основанные на использовании детальной системной спецификации, отличаются подходами к верификации и аттестации систем. Верификация — процесс проверки системы на соответствие спецификации. Поскольку для прототипа нс создается подробной спецификации, его верификация невозможна. Аттестация системы должна показать, что программа соответствует тем целям, для которых она создавалась.
Аттестацию также трудно провести без детальной спецификации, поскольку нет четких формулировок целей. Конечные пользователи, участвующие в про. цессе разработки. мо~уг быть удовлетворены системой, в то время как другие пользователи — неудовлетвореиы, поскольку система не полностью соответствует тем целям, которые они неявно перед пей поставили. Верификацию н аттестацию сисгемы, разработанной с использованием эволюционного прототипирования, можно осуществить, если она в достаточной степени соответствует по.
ставленной цели и своему назначению. Это соответствие. конечно, нельзя измерить, можно сделать лия~ь субьектнвные оценки. Такой подход, как будет показано ниже, может породить проблемы, если программная система создаетсл сторонними организациями-разработчиками. Существует три основныс проблемы эволюционного прототипирования, которые необходимо учитывать, особенно при разработке больших систем с длительным сроком жизненного цикла. 1. 1))зоГмемм уяроаееяил.
Структура управления разработкой программных систем строится в соответствии с утвержденной моделью процесса создания ПО, где для оценивання очередного этапа разработки используются специальные контрольные проектные элементы (см. главу 4). Прототипы эволюционируют настолько быстро, что создавать контрольные элементы становится нерентабельно. Кроме того, быстрая разработка прототипа может потребовать применения новых технологиИ. В этом случае может возникнуть необходимость привлечения специалистов с более высокой квалибзикацией. 8.
Прототипирование программных систем 17з 2. Иройемм сопразолсдсккя пияимьс Из-за непрерывных изменений в прототипах изменяется также структура системы. Это означает, что система будет трудна для понимания всем, кроме первоначальных разработчиков. Кроме того, может устареть специальная технология быстрой разработки, которая использоваяась при создании прототипов. Поэтому могут возникнуть трудности при поиске людей, которые имеют знания, необходимые для сопровождения системы. 3. Проблемы заключенна кантуюкжав. Обычно контракт на разработку систем между заказчиком и разработчиками ПО основывается на системной спецификации.
При отсутствии таковой трудно составить контракт на разработку системы. Для заказчика может быть невыгоден контракт, по которому приходится просто платить разработчикам за время, потраченное на разработку проекта; также маловероятно. что разработчики согласятся на контракт с фиксированной ценой, поскольку оии не могут предвидеть все прототипы, которые потребуется создать в процессе раз. работки системы. Из этих проблем вытекает, что заказчики должны понимать, насколько эффективно эволюционное прототипирование в качестве метода разработки ПО.
Этот метод позволяет быстро создавать системы малого и среднего размера, при этом стоимость разработки снижается, а качество повышается. Если к процессу разработки привлекаются конечныс пользователи, то, вероятно, система будет соответствовать их реальным потребностям. Однако организации-разработчики, использующие этот метод, должны учитывать, что жизненный цикл таких систем будет относительно короток. При возрастании проблем с сопровождением систему необходимо заменить или полностью переписать. Для больших систем, когда к разработке привлекаются субподрядчики, на первый план выходят проблемы управления эволюционным прототипированием.
В этом случае лучше применять экспериментальное прототипирование. Пошаговая разработка (рис.8.4) позволяет избежать некоторых проблем, характерных для эволюционного прототипирования. Общая архитектура системы, определенная на раннем этапе ее разработки, выступает в роли системного каркаса. Компоненты системы разрабатываются пошагово, затем включаются в этот каркас. Если компоненты аттестованы и включены в каркас, ни архитектура, ни компоненты уже не меняются, за исключением случая, когда обнаруживаются ошибки. Ркс.
В.4. Покюсоеий прокессяспрпботки 176 хуасть П. Требования Процесс пошаговой разработки более управляем, чем эволюционное прототипирование, поскольку следует обычным стандартам разработки ПО. Здесь планы и документация создаются для каждого шага разработки системы, что уменьшает количество ошибок.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
