Преподаватель который помогает студентам и школьникам в учёбе.

Основы проектирования программ. Этапы создания программного обеспечения

Содержание:

Введение

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

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

1. Этапы создания программного обеспечения

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

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

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

1.1. Модели жизненного цикла программного обеспечения

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

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

Объектом исследования является программное обеспечение.

Предметом исследования является процесс проектирования программного обеспечения.

Целью работы является исследование процесса проектирования программного обеспечения.

Для достижения поставленной цели необходимо решить ряд задач:

Изучить модели жизненного цикла создания программного обеспечения.
Рассмотреть стандарты и подходы к разработке программных продуктов.
Дать характеристику этапам создания программных продуктов.
Изучить сущность процесса проектирования программного обеспечения.
Описать виды проектирования программного обеспечения.
Рассмотреть свойства модели программного продукта.
Этапы создания программного обеспечения
Модели жизненного цикла программного обеспечения

Процесс создания программного обеспечения – это достаточно сложный и нелинейный процесс. Не существует одного четкого подхода к разработке программного обеспечения. Однако были разработаны стандарты, которые регламентируют этот процесс. К таким стандартам относят российский стандарт ГОСТ 34.601 «Стадии создания автоматизированных систем» и зарубежный стандарт ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств».

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

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

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

Рисунок 1. Структура каскадной модели жизненного цикла программного обеспечения.

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

Техническое задание;
Эскизный проект;
Технический проект;
Рабочую программу.

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

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

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

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

Итерационную модель также называют моделью с промежуточным контролем или моделью с циклическим повторением фаз. Структура итерационной модели представлена на рисунке 2.

Рисунок 2. Итерационная модель жизненного цикла программного обеспечения.

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

Спиральная модель жизненного цикла программного продукта является классическим примером применения эволюционной стратегии разработки программных средств. Модель была разработана Б. Боэмом в 1988. Основу модели составляют лучшие свойства каскадной модели жизненного цикла с учетом процесса макетирования, к которым был добавлен новый элемент – анализ риска, который отсутствовал в этих моделях. Спиральная модель состоит из четырех этапов, которые представлены четырьмя квадрантами спирали. Структура спиральной модели представлена на рисунке 3.

Рисунок 3. Схема спиральной модели жизненного цикла разработки ПО.

Рассмотрим этапы спиральной модели:

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

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

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

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

1.3 Стандарты, регламентирующие процесс разработки программного обеспечения

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

Рекомендуемый состав стадий жизненного цикла программного обеспечения регламентируют стандарты ISO, которые описывают технологические процессы. Стандарт ISO/IEC 12207:2008 «System and software engineering – Software life cycle processes» определяет общую структуру жизненного цикла ПО в виде трехуровневой модели, элементами которой являются процессы, виды деятельности, задачи. Процессы объединены в четыре группы: основные процессы, поддерживающие процессы, организационные процессы, адаптация. Процессы состоят из отдельных видов деятельности.

Стандарт ISO/IEC 15288:2008 «Разработка систем и программного обеспечения – Процессы жизненного цикла систем» рассматривает программно-аппаратную систему как единое целое. Стандарт предлагает рассматривать структуру жизненного цикла ПО как набор групп процессов, каждый из которых описывается набором результатов, и каждый из результатов достигается при помощи набора различных видов деятельности. Эффективность разработки ПО в целом зависит от точности и корректности формулировки требований к программному продукту.

Правила работы с требованиями к программному обеспечению рассматриваются в стандарте IEEE 830-1998 «Recommended practice for software requirements specifications». Стандарт регламентирует состав документации для фиксирования требований к ПО, а также дает определение характеристикам, которыми должен обладать правильно составленный набор требований.

Стандарт IEEE 1233-1998 «Guide for developing system requirements specifications» дает описание правилам построения требований для программно-аппаратных систем в целом, а также определяет необходимые свойства и атрибуты набора требований. Согласно стандарту, процесс разработки требований включает определение, организацию, представление и модификацию требований.

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

Рассмотрим стандарты, которые регламентируют процесс проектирования архитектуры АИС. Стандарт IEEE 1016-1998 «Recommended Practice for Software Design Descriptions» описывает принципы разработки непосредственно архитектуры АИС, а не ее компонентов.

Стандарт ISO/IEC 42010 IEEE Std 1471-2000 «System and software engineering – Recommended practice for architectural description of software-intensive systems». Представляет архитектуру системы в виде комплекса представлений, которые отражают структуру ПО с разных точек зрения. В соответствии со стандартом каждое представление архитектуры должно фиксировать отраженные в нем взгляды и интересы, причины, обуславливающие необходимость такого рассмотрения системы, несоответствия между элементами одного представления или между различными представлениями, а также различную служебную информацию.

Стандарт ISO 9001:2000 «Quality management systems – Requirements» определяет требования к качеству программного продукта, а также правила его обеспечения. Стандарт ISO/IEC 90003:2004 «Software engineering – Guidelines for the application of ISO 9001:2000 to computer software» описывает положения по применению стандарта ISO 9001:2000 к программному обеспечению. Также этот стандарт помогает определить набор техник и процедур, которые будут применяться для осуществления контроля и обеспечения качества разрабатываемых программ.

Отечественной разработкой стал стандарт ГОСТ 34. Согласно этому стандарту жизненный цикл процесса разработки АИС делится на следующие этапы:

Формирование требований к АС.
Разработка концепции АС.
Техническое задание.
Эскизный проект.
Технический проект.
Рабочая документация.
Ввод в действие.
Сопровождение АС.

У этого стандарта есть один недостаток: стандарт является старым. В этом стандарте заложены устаревшие представления об архитектуре АИС. Примерами этого являются следующие утверждения:

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

Так же существуют следующие стандарты разработки АИС:

«Custom Development Method» методика компании «Oracle», применяемая для разработки прикладных информационных систем. Этот метод является технологическим материалом, детализированным до уровня шаблонов проектной документации, рассчитанной на применение в проектах компании. Согласно этому стандарту при разработке программного обеспечения применяется классическая модель жизненного цикла программного продукта.

Стандарт «Rational Unified Process» (RUP) представляет разработку программного обеспечения в виде итеративной модели жизненного цикла, который включает следующие фазы: начало, исследование, построение и внедрение. Каждая фаза жизненного цикла АИС может разбиваться на этапы, называемые итерациями. В результате осуществления этих этапов происходит выпуск версий программного продукта для внутреннего или внешнего использования. Прохождение процесса разработки через четыре этапа называют циклом разработки. Каждый цикл разработки завершается генерацией версии системы. Если после версия системы не удовлетворяет требованиям пользователя, то разработанный продукт продолжает свое развитие и проходит те же этапы разработки.

Стандарт «Microsoft Solution Framework» (MSF) похож на стандарт «RUP» тем, что делит разработку программного обеспечения на четыре фазы: анализ, проектирование, разработка, стабилизация. Эта модель является итерационной, что предполагает использование объектно-ориентированного подхода при моделировании системы. Стандарт «MSF» в сравнении со стандартом «RUP» больше ориентирован для разработки бизнес- приложений.

Стандарт «Extreme Programming» (XP) был создан в 1996 году и является самым новым среди рассмотренных стандартов. Основу этого стандарта составляет командная работа, с организацией эффективной коммуникацией между заказчиком и разработчиков во время всей разработки АИС. При этом разработка АИС проводится с использованием последовательно разрабатываемых прототипов АИС.

1.4 Характеристика этапов создания программных продуктов

Рассмотренные стандарты разработки программного обеспечения объединяет наличие следующих стадий:

Анализ требований к проекту.
Проектирование.
Реализация.
Тестирование продукта.
Внедрение и поддержка.

Общая схема этапов процесса разработки программного обеспечения представлена на рисунке 4.

Рисунок 4. Процесс разработки программного обеспечения.

Дадим характеристику каждой стадии разработки программного обеспечения.

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

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

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

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

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

На стадии проектирования осуществляется разработка следующих проектных решений:

Выбор платформы, на которой будет осуществляться функционирование системы языка или языков реализации;
Назначение требований к пользовательскому интерфейсу;
Определение наиболее подходящей СУБД.

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

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

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

Внутренней организации программного обеспечения;
Пользовательского интерфейса;
Разграничения доступа.

Результатом этого этапа является рабочая версия продукта.

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

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

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

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

Установку и настройку программного обеспечения.
Процесс обучения пользователей.
Собственно эксплуатацию системы.
Основы проектирования программного обеспечения

2. Сущность процесса проектирования программного обеспечения

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

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

Как правило, процесс проектирования программных продуктов делится на два этапа:

предварительное проектирование;
детальное проектирование.

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

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

идентификацию подсистем;
определение основных принципов управления подсистемами;
взаимодействие подсистем.

Рисунок 5. Информационные связи процесса проектирования.

К процессу предварительного проектирования относятся следующие типы деятельности:

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

В результате осуществления стадии структурирования системы получаются следующие виды моделей:

модель хранилища данных;
модель клиент-сервер;
трехуровневая модель;
модель абстрактной машины.

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

Рисунок 6. Модель хранилища данных.

Клиент-серверная модель используется для проектирования распределенных систем, в которых компоненты системы распределены по серверам. Для передачи данных в клиент-серверных системах применяются сетевые протоколы, например, протокол TCP/IP. Структура клиент-серверной модели представлена на рисунке 7.

Рисунок 7. Клиент-серверная модель.

Развитием клиент-серверной модели является трехуровневая модель. Структура трехуровневой модели представлена на рисунке 8.

Рисунок 8. Трехуровневая модель.

Трехуровневая модель, согласно рисунку, включает следующие уровни: графический интерфейс пользователя, уровень бизнес-логики и реляционную СУБД.

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

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

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

Рисунок 9. Модель абстрактной машины.

Модель является совокупностью следующих слоев:

Операционная система;
СУБД;
Управление объектом;
Управление версиями.

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

Рассмотрим модели управления. Выделяют следующие виды моделей управления:

модель централизованного управления;
модель событийного управления.

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

Модель вызов-возврат.
Модель менеджера, используемая в системах параллельной обработки.

Структура модели «Вызов-возврат» представлена на рисунке 10.

Рисунок 10. Структура модели «Вызов-возврат».

На рисунке 11 представлена структура модели менеджера.

Рисунок 11. Структура модели менеджера.

В модели событийного управления системой управление осуществляется внешними событиями. Существуют следующие виды моделей событийного управления:

широковещательная модель;
модель, управляемая прерываниями.

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

Рисунок 12. Структура широковещательной модели.

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

Рисунок 13. Структура модели, управляемой прерываниями.

Рассмотрим процесс декомпозиции подсистем на модули. Различают следующие модели модульной декомпозиции:

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

Выбор способа декомпозиции подсистемы на модули зависит от сложности разбиваемой подсистемы.

2.1 Этапы проектирования программного продукта

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

Эскизный проект системы.
Техническое проектирование.
Рабочий проект системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап технического проектирования включает в себя следующие стадии:

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

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

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

В состав комплекта документ, содержащих общесистемные проектные решения входят следующие документы:

ведомость технического проекта;
пояснительная записка к техническому проекту;
описание автоматизируемых функций;
ведомость покупных изделий;
описание постановки задач (комплекса задач);
локальный сметный расчет;
проектная оценка надежности системы.

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

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

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

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

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

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

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

В результате разработки рабочего проекта системы получается комплект документов, в состав которого входят:

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

2.2 Свойства модели программного продукта

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

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

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

Рисунок 14. Закрытость модулей программных продуктов.

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

Таким образом можно заключить, что принцип информационной закрытости означает следующее:

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

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

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

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

Связность модуля (Cohesion) – это свойство, показывающее меру зависимости модулей программного продукта друг от друга. Связность — это внутреннее свойство модуля. Степень связности модуля является прямо пропорциональной результату проектирования.

Для измерения степени связности модулей используют понятие силы связности (СС). Различают 7 степеней связности:

Связность по совпадению (СС=0) – когда в модуле отсутствуют явно выраженные внутренние связи.
Логическая связность (СС=1) – когда части модуля объединены по принципу функционального подобия.
Временная связность (СС=3) – когда части модуля не являются связанными, но необходимы в один и тот же период работы системы.
Процедурная связность (СС=5) – когда части модуля связаны порядком выполняемых действий, реализующих некий сценарий поведения.
Коммуникативная связность (СС=7) – когда части модуля связаны по данным (работают с одной и той же структурой данных).
Информационная (последовательная) связность (СС=9), в которой выходные данные одной части используются как входные в другой части модуля.
Функциональная связность (СС=10), в которой части модуля вместе реализуют одну функцию.

Определить степень связности модуля можно по следующему алгоритму:

Если модуль является единичной проблемно-ориентированной функцией, то уровень связности является функциональным.
Если действия внутри модуля связаны, то перейти к пункту 3. Если действия внутри модуля никак не связаны, то перейти к пункту 6.
Если действия внутри модуля связаны данными, то перейти к пункту 4. Если действия внутри модуля связаны потоком управления, перейти к пункту 5.
Если порядок действий внутри модуля важен, то уровень связности — информационный. В противном случае уровень связности — коммуникативный.
Если порядок действий внутри модуля важен, то уровень связности — процедурный. В противном случае уровень связности — временной.
Если действия внутри модуля принадлежат к одной категории, то уровень связности — логический. Если действия внутри модуля не принадлежат к одной категории, то уровень связности — по совпадению.

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

Правило параллельной цепи: Если все действия модуля имеют несколько уровней связности, модулю присваивают самый сильный уровень связности.
Правило последовательной цепи: Если действия в модуле имеют разные уровни связности, то модулю присваивают самый слабый уровень связности.

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

Количественно сцепление измеряется степенью сцепления (СЦ). Различают следующие виды сцепления:

Сцепление по данным (СЦ=1). Модуль А вызывает модуль В. Все входные и выходные параметры вызываемого модуля – простые элементы данных.
Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных.
Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В, посылая ему управляющие данные.
Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.
Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных.
Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (через его точку входа).

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

Рисунок 15. Иерархическая структура программной системы.

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

Высотой называют количество уровней управления;
Шириной называют максимальное из количеств модулей, размещенных на уровнях управления.

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

Заключение

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

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

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

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

Список литературы

ISO/IEC 10746-2:1996, Information technology — Open Distributed Processing — Reference Model: Foundations.3.2.5.
ISO/IEC 15288:2008 «Разработка систем и программного обеспечения – Процессы жизненного цикла систем».
ГОСТ 34 «Информационная технология. Комплекс стандартов на автоматизированные системы».
Беккер Й., Велкова Л. Менеджмент процессов. / Й. Беккер, Л. Велкова - М.: Эксмо, 2014. 384с.
Венделева М.А. Информационные технологии управления: учебное пособие для бакалавров: по специальности «Менеджмент организации» / М.А. Венделева, Ю.В. Вертакова. - Москва : Юрайт, 2012. 462 с.
Киселев Г.М. Информационные технологии в экономике и управлении: учебное пособие для вузов / Г.М. Киселев, Р.В. Бочкова, В.И. Сафонов. - Москва : Дашков и К, 2012. 268 с.
Корнейчук Б.В. Информационная экономика: учеб. пособие / Б.В. Корнейчук. - Санкт-Петербург [и др.] : Питер, 2016. 394 с.
Ловцев Д.А. Информационная теория эргасистем. / Д.А. Ловцев. М.: ВАРВСН, 2013. 124 с.
Меняев. М.Ф. Основы разработки программного обеспечения / М.Ф. Меняев. — М.: Омега-Л, 2015. 458 с.
Острейковский, В.А., Полякова, И.В. Информатика. Теория и практика / В.А. Острейковский, И.В. Полякова. — М.: Оникс, 2014. 608 с.
Попов, В.Л. Управление инновационными проектами: Учебное пособие / В.Л. Попов. - М.: Инфра-М, 2013. 336 с.
Пятков М.А. Экономика информационных технологий / М.А. Пятаков М.:Наука, 2012. 335 с.
Романова Ю.Д. Информатика и информационные технологии / Ю.Д. Романова. — М.: Эксмо, 2014. 592 с.
Румянцева, Е.Л., Слюсарь, В.В. Информационные технологии / Е.Л. Румянцева, В.В. Слюсарь. - М.: Инфра-М, 2007. 256 с.
Соболь Б.Ф. Информатика / Б.В. Соболь. - Ростов-на-Дону: Феникс, 2013. 446 с.
Степанов, А.Н. Информатика/А.Н. Степанов. - СПб.: Питер, 2016. 684с.
Тронин Ю.Н.Информационные системы и технологии в бизнесе / Ю.Н. Тронин. - Москва : Альфа-Пресс, 2015. 236 с.
Хакен Г. Информация и самоорганизация/Г.Хакен. М.: Мир, 2013. 240с.
Хубаева Г.Н. Информатика / Г.Н. Хубаева. - Ростов-на-Дону: МарТ, 2012. 288 с.
Шуремов, Е.Л., Чистов Д.В., Лямова Г.В. Информационные системы управления предприятиями / Е.Л. Шуремов, Д.В. Чистов, Г.В. Лямова. - М.: Изд-во «Бухгалтерский учет», 2012. 112 с.