Методы и средства инженерии программного обеспечения

Стандартный подход к проектированию системы


 Разработка автоматизированных систем  (АС) выполнялась и выполняется на основе положений, представленных в  стандарте ГОСТ 34.601-90 (см. Приложение 2). Он состоит из стадий и этапов разработки АС, которые,  в зависимости от  особенностей  автоматизируемой системы,   можно объединять друг с другом или вообще не включать в процесс разработки. Основанием для разработки АС является  договор между разработчиком системы и ее заказчиком.

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

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

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

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

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

Таким образом, данный стандарт обеспечивает:

– концептуальное проектирование,  которое состоит  в уточнении и согласовании деталей требований;

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


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

Правила навигации должны учитывать традиции чтения слева - направо или наоборот.

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

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

При техническом проектировании системы  на основе модели представления требований и понятий объектно–ориентированного подхода проводится уточнение состава и содержания функций,  присущих им операций (методов), а также схем взаимодействия объектов.

Содержание операций, которые способны выполнять объекты, может быть раскрыто с помощью диаграмм потоков данных (см. тема 3.).

Взаимодействие объектов организовывается путем обмена  сообщений, в ответ на которые они выполняют соответствующие операции и изменяют свое состояние, или посылают сообщения другим объектам.

Для уточнения поведения объектов можно использовать ряд  диаграмм,  отображающих различные аспекты взаимодействия объектов. Такие диаграммы входят в состав метода UML.

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


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

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

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

 

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


Содержание раздела