Системная инженерия ЛЕКЦИЯ 2. Лекция 2 Из рабочей учебной программы Тема Стандарты и нормативные руководства по системной и программной инженерии

• Название: Лекция 2 Из рабочей учебной программы Тема Стандарты и нормативные руководства по системной и программной инженерии
• Анкор: Системная инженерия ЛЕКЦИЯ 2.doc
• Дата: 20.10.2017
• Размер: 0.87 Mb.
• Имя файла: Системная инженерия ЛЕКЦИЯ 2.doc
• Тип: Лекция; #9614
• страница: 3 из 5

Модель прототипирования жизненного цикла разработки ПО

Ставшее классикой произведение Фреда Брукса (Fred Brook) под названием "Легендарный человек-месяц" (The Mythical Man-Month) сегодня столь же актуаль­но, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал:

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

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

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

Именно эта концепция построения экспериментальной, или прототипной сис­темы привела к возникновению "структурной", "эволюционной" модели быстрого прототипирования (RAD), и спиральной модели. В своей боле поздней, в равной степени полной плодотворных идей работе под названием "No Silver Bullet, the Essence and Accidents of Programming" Брукс считает, что большинство ошибок, возникающих при разработке ПО, все же связаны с неправильным пониманием концепции системы, а не с синтаксисом или логикой. Разработка ПО всегда будет трудной задачей, и мы никогда не найдем чудодейственную панацею или "сереб­ряную пулю". Он подчеркивает положительный момент в применении методов бы­строго прототипирования:

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

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

На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы разработки ПО, является разработка методов и средств для ускоренного прототипиро-вания систем как составляющей итеративной спецификации требований".

Уотте Хэмфри (Watts Humphrey), который известен как вдохновитель создания модели СММ, разработанной Институтом SEI, поддерживает Брукса в его подходе к важности требований и их разработки:

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

Определения прототипирования

Согласно Джону Коннэллу (Connell) и Линде Шафер (Shafer), эволюционным уско­ренным прототипом является "легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства сис­темы, благодаря которой пользователи данного приложения получают физическое пред­ставление о ключевых частях системы до ее непосредственной реализации; это — легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы" .

Бернард Боар (Bernard Boar) определил прототип как "метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конеч­ной системы — быстро и в требуемом контексте".

Описание структурной модели эволюционного прототипирования

Прототипирование — это процесс построения рабочей модели системы. Прототип — это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.

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

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

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

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

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

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

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

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

Преимущества структурной эволюционной модели быстрого прототипирования

При использовании структурной эволюционной модели быстрого прототипиро­вания для приемлемого проекта проявляются следующие преимущества:

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

Недостатки структурной эволюционной модели быстрого прототипирования:

• 
  модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе;
  

• 
  разработанные "на скорую руку" прототипы, в отличие от эволюционных уско­ренных прототипов, страдают от неадекватной или недостающей документации;
  
• 
  если цели прототипирования не согласованы заранее, процесс может превратить­ся в упражнение по созданию хакерского кода;
  
• 
  с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания.
  
• 
  иногда в результате использования модели получают систему с низкой рабочей харак­теристикой, особенно если в процессе ее выполнения пропускается этап подгонки;
  
• 
  при использовании модели решение трудных проблем может отодвигаться на бу­дущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип;
  
• 
  если пользователи не могут участвовать в проекте на итерационной фазе быст­рого прототипирования жизненного цикла, на конечном продукте могут отра­зиться неблагоприятные воздействия, включая проблемы, связанные с его каче­ственной характеристикой;
  
• 
  на итерационном этапе прототипирования быстрый прототип представляет со­бой частичную систему. Если выполнение проекта завершается досрочно, у ко­нечного пользователя останется только лишь частичная система;
  
• 
  несовпадение представлений заказчика и разработчиков об использовании прото­типа может привести к созданию другого пользовательского интерфейса;
  
• 
  заказчик может предпочесть получить прототип, вместо того, чтобы ждать появ­ления полной, хорошо продуманной версии;
  
• 
  если язык или среда прототипирования не сочетаются с производственным языком или окружением, всесторонняя реализация продукционной системы может быть задержана;
  
• 
  прототипирование вызывает зависимость и может продолжаться слишком долго. Нетренированные разработчики могут попасть в так называемый цикл "кодирование — устранение ошибок" (code-and-fix cycle), что приводит к дорого­стоящим незапланированным итерациям прототипирования;
  
• 
  разработчики и пользователи не всегда понимают, что когда прототип превра­щается в конечный продукт, все еще существует необходимость в традиционной Документации. Если она отсутствует, модифицировать модель на более поздних этапах может оказаться более дорогостоящим занятием, чем просто не восполь­зоваться созданным прототипом;
  
• 
  когда заказчики, удовлетворенные прототипом, требуют его немедленной поставки, перед менеджером программного проекта возникает соблазн пойти им навстречу;
  
• 
  на заказчиков могут неблагоприятно повлиять сведения об отличии между прото­типом и полностью разработанной системой, готовой к реализации;
  
• 
  на заказчиков может оказать негативное влияние тот факт, что они не располагают информацией о точном количестве итераций, которые будут необходимы;
  
• 
  на разработку системы может быть потрачено слишком много времени, так как итерационный процесс демонстрации прототипа и его пересмотр могут продолжаться бесконечно без надлежащего управления процессом. У пользователей может воз­никнуть стремление пополнять список элементов, предназначенных для прототи­пирования, до тех пор, пока проект ни достигнет масштаба, значительно превы­шающего рамки, определенные анализом осуществимости проектного решения;
  
• 
  при выборе инструментальных средств прототипирования (операционные систе­мы, языки и малопродуктивные алгоритмы) разработчики могут остановить свой выбор на менее подходящем решении, только чтобы продемонстрировать свои способности;
  
• 
  структурные методы не используются, чтобы не помешать выполнению анализа. При прототипировании необходимо провести "реальный" анализ требований, осуществить проектирование и обратить внимание на качество с целью создания программы, до­пускающей сопровождение, точно так же, как и в любой другой модели жизненного цикла (хотя на эти действия может понадобиться меньше времени и ресурсов).
  

Область применения структурной эволюционной модели быстрого прототипирования

Менеджер проекта может быть уверен в необходимости применения структурной эволюционной модели быстрого прототипирования, если:

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

Спиральная модель

Спиральная модель(рис.2)─ классический пример применения эволюционной стратегии конструирования.

Где, 1. начальный сбор требований и планирование проекта; 2. та же работа, но на основе рекомендаций заказчика; 3. анализ риска на основе начальных требований; 4. анализ риска на основе реакции заказчика; 5. переход к комплексной системе; 6. начальный макет системы; 7. следующий уровень макета; 8. сконструированная система; 9. оценивание заказчиком.

Как показано на рис. 11, спиральная модель определяет четыре действия, представляемые четырьмя квадрантами спирали:

·        планирование ─ определение целей, вариантов и ограничений;

·        анализ риска ─ анализ вариантов и распознавание (выбор) риска;

·        конструирование ─ разработка продукта следующего уровня;

·        оценивание ─ оценка заказчиком текущих результатов конструирования.

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

Спиральная модель жизненного цикла ИС реально отображает разработку программного обеспечения; позволяет явно учитывать риск на каждом витке эволюции разработки; включает шаг системного подхода в итерационную структуру разработки; использует моделирование для уменьшения риска и совершенствования программного изделия.



Рисунок 2. Спиральная модель
Недостатками спиральной модели являются:

·        новизна (отсутствует достаточная статистика эффективности модели);

·        повышенные требования к заказчику;

·        трудности контроля и управления временем разработки.

МОДЕЛЬ БЫСТРОЙ РАЗРАБОТКИ ПРИЛОЖЕНИЙ (RAPID APPLICATION DEVELOPMENT) RAD-ТЕХНОЛОГИЯ

В основе спиральной модели жизненного цикла лежит применение прототипной технологии или RAD-технологии (rapid application development ─ технологии быстрой разработки приложений). Основная идея этой технологии заключается в том, что ИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. При прототипной технологии сокращается число итераций, возникает меньше ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование ИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ИС все большее значение придается ведению общесистемного репозитария и использованию CASE-технологий.



RAD-технология обеспечивает экстремально короткий цикл разработки ИС. При полностью определенных требованиях и ограниченной проектной области RAD-технология позволяет создать полностью функциональную систему за очень короткое время (60-90 дней). Выделяют следующие этапы разработки ИС с использованием RAD-технологии:

1. бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Определяются ответы на вопросы: Какая информация руководит бизнес-процессом? Какая информация генерируется? Кто генерирует ее? Где информация применяется? Кто обрабатывает информацию?

2.       моделирование данных. Информационный поток отображается в набор объектов данных, которые требуются для поддержки деятельности организации. Определяются характеристики (свойства, атрибуты) каждого объекта, отношения между объектами;

3.       моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;

4.       генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации (CASE-средства);

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

Применение RAD имеет и свои недостатки, и ограничения:

·        большие проекты в RAD требуют существенных людских ресурсов (необходимо создать достаточное количество групп);

·        RAD применима только для приложений, которые можно разделять на отдельные модули и в которых производительность не является критической величиной;

·        RAD неприменима в условиях высоких технических рисков.

Улучшение процесса принятия решений в планировании, разработке, эксплуатации
RAD-технология обеспечивается наличием средств разработки графического пользовательского интерфейса и кодогенераторов. Такие инструментальные средства, как Oracle Designer/2000, JavaJbuilder 3, Linux, Visual C++, Visual Basic 6, SAS, и другие можно использовать в качестве средств для быстрой разработки приложений.