Определение технологии конструирования. Методы, средства, процедуры технологии конструирования. Классический жизненный цикл. Макетирование. Стратегии конструирования ПО(модели ЖЦ)

Тема:Методы проектирования

Вопросы:

1.                   Определение технологии конструирования     

2.                   Методы технологии конструирования

3.                   Средства технологии конструирования

4.                   Процедуры технологии конструирования

5.                   Классический жизненный цикл

6.                   Макетирование

7.                   Стратегии конструирования ПО(модели ЖЦ)

Технология конструирования программного обеспечения

•               Технология конструирования программного обеспечения (ТКПО) — система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах .

•               Различают методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

•               планирование и оценка проекта;

•               анализ системных и программных требований;

•               проектирование алгоритмов, структур данных и программных структур;

•               кодирование;

•               тестирование;

•               сопровождение.

•               Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

•               Процедуры являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процедуры определяют:

•               порядок применения методов и утилит;

•               формирование отчетов, форм по соответствующим требованиям;

•               контроль, который помогает обеспечивать качество и координировать изменения;

•               формирование «вех», по которым руководители оценивают прогресс.

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

Классический жизненный цикл

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970) .

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

Охарактеризуем содержание основных этапов.

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

•               Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.

•               Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

•               Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

•               Анализ требований относится к программному элементу — программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

•               Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Кодирование состоит в переводе результатов проектирования в текст на языке программирования.

Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений:

•               исправление ошибок;

•               адаптация к изменениям внешней для ПО среды;

•               усовершенствование ПО по требованиям заказчика.

Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе но не в разработке новой программы.

Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

1)            реальные проекты часто требуют отклонения от стандартной последовательности шагов;

2)            цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

3)            результаты проекта доступны заказчику только в конце работы.

Макетирование

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

•               Основная цель макетирования — снять неопределенности в требованиях заказчика.

•               Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.

•               Модель может принимать одну из трех форм:

•               1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

•               2) работающий макет (выполняет некоторую часть требуемых функций);

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

Как показано на рис. 1.2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Рис. 1.3. Последовательность действий при макетировании

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки макетирования:

заказчик может принять макет за продукт;

разработчик может принять макет за продукт.

Стратегии конструирования ПО(Модели жизненного цикла)

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

•               Стандарт ISO/IEC 12207 не предлагает конкретные модель жизненного цикла и методы разработки ПП. Положения стандарта являются общими для любых моделей жизненного цикла, методов и технологий разработки ПП.

Модель

быстрой

разработки

приложений

Проектные группы небольшие (3 ...7 человек) и составлены из высококвалифицированных специалистов.

Уменьшенное время цикла разработки (до 3 мес) и улучшенная производительность. Повторное использование кода и автоматизация процесса разработки

Многопро-

ходная

модель

Быстро создается работающая система. Уменьшается возможность внесения изменений в процессе разработки.

Невозможен переход от текущей реализации к новой версии в течение построения текущей частичной реализации

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

Охватывает каскадную модель. Расчленяет фазы на меньшие части. Позволяет гибко выполнять проектирование. Анализирует риски и управляет ими. Пользователи знакомятся с ПП на более раннем этапе благодаря прототипам

•               Наибольшее распространение получили следующие модели жизненного цикла разработки ПП:

Название

Характеристики

Каскадная модель

Прямолинейная и простая в использовании. Необходим постоянный жесткий контроль за ходом работы.

Разрабатываемое программное обеспечение не доступно для изменений

V-образная модель

Простая в использовании. Особое значение придается тестированию и сравнению результатов фаз тестирования и проектирования

Модель

прототипирования

Создается «быстрая» частичная реализация сис­темы до составления окончательных требований. Обеспечивается обратная связь между пользо­вателями и разработчиками в процессе выпол­нения проекта.

Используемые требования не полные

•               каскадная модель, или «водопад» (Waterfall model); V-образная модель (V-shaped model); модель прототипирования (Prototype model); модель быстрой разработки приложений, или RAD-модель (RAD — Rapid Application Development model);

Каскадная модель

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

Преимущества каскадного способа:

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

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

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

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

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

V-образная модель

•               Данная модель основана на систематическом подходе к проблеме, для решения которой определены четыре базовых шага: анализ, проектирование, разработка и обзор. При выполнении анализа осуществляются планирование проекта и составление требований. Проектирование разделяется на высокоуровневое и де­тальное (низкоуровневое). Разработка включает в себя кодирова­ние, а обзор — различные виды тестирования.

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

•               На модели хорошо просматриваются взаимосвязи между аналитическими фазами и фазами проектирования, которые пред-

  шествуют кодированию и тестированию. Штриховые стрелки показывают, что эти фазы надо рассматривать параллельно.

•               Модель включает в себя следующие фазы: составление требований к проекту и планирование — определяются системные требования и выполняется планирование работ;

•               составление требований к продукту и их анализ — составляется полная спецификация требований к программному продукту;

•               высокоуровневое проектирование — определяются структура ПП, взаимосвязи между основными его компонентами и реализуемые ими функции;

•               детальное проектирование — определяется алгоритм работы каждого компонента;

•               кодирование — выполняется преобразование алгоритмов в го­товое программное обеспечение;

•               модульное тестирование — выполняется проверка каждого ком­понента или модуля ПП;

•               интеграционное тестирование — осуществляются интеграция ПП и его тестирование;

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

•               эксплуатация и сопровождение — запуск ПП в производство. На этой фазе в ПП могут вноситься поправки и может выполняться его модернизация.

Преимушества V-образной модели:

•               большая роль придается верификации и аттестации ПП, начи­ная с ранних стадий его разработки, все действия планируются;

•               предполагаются аттестация и верификация не только самого ПП, но и всех полученных внутренних и внешних данных;

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

Кроме перечисленных достоинств модель обладает и рядом недостатков:

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

•               Данную модель целесообразно использовать при разработке программных продуктов, главным требованием для которых является высокая надежность.

Модель прототипирования (рис. 3.4) позволяет создать прототип ПП до или в течение этапа составления

требований к ПП.

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

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

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

•               Модель прототипирования обладает целым рядом преимуществ:

•               взаимодействие заказчика с

•               разрабатываемой системой начи­нается на раннем этапе;

•               благодаря реакции заказчика на прототип сводится к миниму­му число неточностей в требованиях;

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

•               в процессе разработки всегда можно учесть новые, даже не­ожиданные требования заказчика;

•               прототип представляет собой формальную спецификацию, воп­лощенную в ПП;

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

•               заказчик всегда видит прогресс в процессе разработки ПП; возможность возникновения противоречий между разработчи­ками и заказчиками сведена к минимуму;

•               уменьшается число доработок, что снижает стоимость разра­ботки:

•               возникающие проблемы решаются на ранних стадиях, что рез­ко сокращает расходы на их устранение;

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

•               Кроме указанных достоинств модели прототипирования присутсвует и целый ряд недостатков:

•               решение сложных задач может отодвигаться на будущее;

•               заказчик может предпочесть получить прототип, а не закон­енную полную версию ПП;

•               прототипирование может неоправданно затянуться;

•               перед началом работы неизвестно, сколько итераций придется выполнить.

•               Модель прототипирования рекомендуется применять в следующих случаях:

•               требования к ПП заранее неизвестны,

•               требования не постоянны или неудачно сформулированы;

•               требования необходимо уточнить;

•               нужна проверка концепции;

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