Меню
Главная
Авторизация/Регистрация
 
Главная arrow Информатика arrow Архитектура и проектирование программных систем

ПРОЕКТИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ И ЦЕЛЕЙ ПРОГРАММНОГО ПРОДУКТА

Процесс проектирования как последовательная трансляция требований, предъявляемых к системе

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

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

По многолетнему опыту крупных организаций - разработчиков программных систем (как зарубежных, так и отечественных), разработке технического задания должна предшествовать оценка осуществимости программной системы, которая необходима заказчику. Как отмечает автор книги [19], обычно заказчик выдает 2-3 страницы текста задания и сразу же просит оценить время выполнения заказа и его стоимость. Нередки случаи, когда целые коллективы ошибаются в 5-10 раз и попадают в кабалу или теряют профессиональную репутацию. Чтобы избежать такой ситуации, нужно предложить заказчику оформить начальный договор на 2-4 недели, с тем чтобы 2-3 системных аналитика разобрались в задаче, с помощью каких-либо инструментальных средств выполнили декомпозицию системы на компоненты, прикинули объем этих компонентов, время их реализации и другие параметры проекта.

Об этом говорит и опыт создания программных систем, накопленный в ранних проектах. Так, Г. Майерс отмечает, что не столь уж невероятно встретить документ, в котором требования формулируются в следующей форме: «Обеспечить максимальную надежность, эффективность, адаптируемость, общность и безопасность системы, минимизируя стоимость и время разработки, требуемую память и время реакции терминала» [10]. Ясно, что такого рода постановки задачи бессмысленны. Поэтому разработка реального технического задания на создание программной системы является сложным, трудоемким и достаточно затратным процессом, требующим проведения в ряде случаев серьезных научных и инженерных исследований.

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

На рис. 4.1 представлена модель процессов проектирования типичной большой программной системы, предложенная в своей основе более 30 лет назад и до сих пор не потерявшая актуальности [11]. Заметим, что модель не зависит от методологии проектирования, все указанные в ней действия должны выполняться в той или иной форме независимо от языка программирования, писал ли исходные требования пользователь или заказчик, использовалось ли технология ООП, САБЕ-средства ит.д.

На первом шаге формулируется предварительная постановка задачи и составляется перечень требований, т.е. четкое определение того, что пользователь ожидает от готового продукта. Часто заказчик (пользователь) составляет этот перечень самостоятельно. В ряде случаев это делает разработчик в результате бесед с пользователем - или исследуя его потребности, или оценивая эти потребности самостоятельно. Здесь заключены большие возможности для ошибок. Например, заказчик не может адекватно сформулировать свои потребности, они могут быть неправильно поняты разработчиком или не учтены в полном объеме.

После предварительной постановки задачи и ее согласования разрабатывается концепция проекта. Концепция (от лат. сопсерйо - «понимание, система») - определенный способ понимания, трактовки какого-либо предмета, явления, процесса, основная точка зрения на предмет и др., руководящая идея для их систематического освещения.

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

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

Рис. 4.1. Модель процессов проектирования большой

программной системы

На основе разработанной концепции подготавливается техническое задание на разработку программной системы. ТЗ включает в себя выполнение следующих работ:

  • 1) проведение аналитического обследования предприятия;
  • 2) разработка функциональных и нефункциональных требований к ПС;
  • 3) разработка (учет) требований к базовому ПО;
  • 4) разработка (учет) требований по оборудованию, операционной системе, системному программному обеспечению и др.

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

Третий шаг - выполнение предварительного внешнего проекта высокого уровня. На этом шаге определяется взаимодействие с пользователем (оператором), но не рассматриваются многие детали проекта, например форматы ввода-вывода данных. На этом шаге цели программно-

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

  • 1. Детальное внешнее проектирование - определение взаимодействия с пользователем до мельчайших подроОностеи.
  • 2. Разработка архитектуры системы - разложение ее на множество подсистем, программ или компонентов и определение сопряжении между ними.

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

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

Следующий шаг- внешнее проектирование модулей (компонентов) - точное определение всех сопряжений модулей и проектирование логики каждого компонента.

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

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

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

(4.1)

Здесь приняты следующие обозначения:

  • 2- предварительная постановка задачи на разработку ПС;
  • Р2 параметры (характеристика) задачи;
  • Ь2 — язык описания задачи;
  • РЯ, - процедура трансляции на /-м этапе перевода, / — 1,2, ...;
  • • УУ- количество различных этапов разработки системы;
  • ТЯ, - требования, предъявляемые к программной системе;
  • ТЯХ 77?у и ТЯп[ ;
  • • Г/?/ -функциональные требования, предъявляемые к системе;
  • ТЯ„/- нефункциональные требования, предъявляемые к системе;
  • Ь„. - язык описания требований;
  • • С, - цели программной системы (программного продукта);
  • Ьс - язык описания целей;
  • Ах - архитектура программной системы;
  • ЬА - язык описания архитектуры программной системы;
  • • 5 - код разработанной программной системы;
  • Р5 - параметры кода программной системы;
  • Ьм - машинный язык.

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

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

Сложность - основная причина ошибок перевода и одна из главных причин ненадежности программных систем [5, 11]. В общем случае сложность объекта является функцией взаимодействия между его компонентами. Сложность архитектуры системы определяется связями между подсистемами. Сложность проекта ПС - функция связи между модулями (как ее оценить, рассмотрим ниже). Сложность отдельного модуля - функция связи между его командами.

В борьбе со сложностью применимы две концепции общей теории систем. Первая - независимость. В соответствии с этой концепцией для

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

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

К этим двум концепциям Г. Майерс [11] предлагает добавить третью: проявление связей всюду, где они возникают (точнее сказать, выявление результатов или возможных последствий этих связей). Основная проблема многих больших ПС - огромное количество независимых побочных эффектов, создаваемых компонентами системы. Из-за них систему зачастую невозможно понять. И можно быть уверенным, что систему, в которой нельзя разобраться, трудно проектировать даже с минимальной гарантией надежности.

Проектное решение любого уровня имеет некоторую внутреннюю организацию, или форму. Для минимизации сложности нужен метод проявления этой формы, с тем чтобы в соответствии с ней разбить проект на части. При внешнем проектировании разбиение системы в соответствии с ее внутренней формой в [6] считается концептуальной целостностью системы.

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

Разработчик слабо знает обстановку (или вовсе не знает), в которой находится пользователь, с какими трудностями он сталкивается и как будет применять программную систему. Бывает, что в проектировании операционной системы участвуют люди, никогда не использовавшие такие системы. Есть разработчики языков высокого уровня, никогда не пробовавшие реализовать прикладную программу на языке высокого уровня [11]. Это может привести к серьезным ошибкам в программной системе. Единственный способ избежать этих ошибок - поддерживать прочный контакт с пользователем в течение всего цикла разработки системы.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Пред   СОДЕРЖАНИЕ   След >
 

Популярные страницы